Методичні рекомендації та завдання до контрольної роботи №3 з дисципліни «Інформаційні системи та технології» - polpoz.ru o_O
Главная
Поиск по ключевым словам:
страница 1страница 2
Похожие работы
Название работы Кол-во страниц Размер
Контролін г методичні рекомендації щодо самостійної роботи та контрольні... 1 418.97kb.
Науково-технічна бібліотека укрдазт інформує про нові надходження... 1 76.24kb.
Методичні вказівки та індивідуальні завдання 3 482.24kb.
Методичні вказівки та контрольні завдання до вивчення дисципліни... 3 702.3kb.
Методичні рекомендації для проведення уроків з використанням цієї... 4 940.42kb.
Методичні вказівки до виконання контрольної роботи та індивідуальні... 5 365.58kb.
Методичні рекомендації щодо підготовки до семінарських занять із... 1 333.15kb.
Методичні рекомендації щодо забезпечення самостійної роботи студентів... 1 347.11kb.
Методичні вказівки до самостійної роботи студентів з дисципліни 5 1574.82kb.
Методичні вказівки та контрольні завдання 1 335.38kb.
Методичні вказівки до самостійної роботи студентів та виконання контрольної... 6 848.34kb.
Аналізуючих функцій 1 232.02kb.
1. На доске выписаны n последовательных натуральных чисел 1 46.11kb.

Методичні рекомендації та завдання до контрольної роботи №3 з дисципліни «Інформаційні - страница №1/2

МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ

ОДЕСЬКИЙ НАЦІОНАЛЬНИЙ ПОЛІТЕХНІЧНИЙ УНІВЕРСИТЕТ

Інститут бізнесу, економіки та інформаційних технологій

Кафедра інформатики та управління захистом інформаційних систем


Борисенко Ірина Іванівна

МЕТОДИЧНІ РЕКОМЕНДАЦІЇ ТА ЗАВДАННЯ

ДО КОНТРОЛЬНОЇ РОБОТИ №3

з дисципліни

«Інформаційні системи та технології»

Одеса ОНПУ – 2011

МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ

Одеський національний політехнічний університет

Інститут бізнесу, економіки та інформаційних технологій

Кафедра інформатики та управління захистом інформаційних систем

Борисенко Ірина Іванівна



МЕТОДИЧНІ РЕКОМЕНДАЦІЇ ТА ЗАВДАННЯ

ДО КОНТРОЛЬНОЇ РОБОТИ №3

з дисципліни

«Інформаційні системи та технології»
для студентів спеціальності 6.03060101 – «Менеджмент організацій», та 6.03060104 – «Менеджмент зовнішньоекономічної діяльності»

напряму підготовки

6.030601 – «Менеджмент»

заочної форми навчання

1 курсу 2 семестру

Розглянуто та затверджено на засіданні

кафедри ІУЗІС

Протокол № ________ від___________201 р.

Одеса ОНПУ – 2011

Методичні вказівки до лабораторних робіт за темою «Інформаційні системи та технології» за курсом «Менеджмент» для студентів спеціальностей 6.03060101 та 6.03060104. / Укл. І. І. Борисенко – Одеса: ОНПУ, 2010−28c.


Укладач: І. І. Борисенко

ЗМІСТ


ЗАГАЛЬНІ ПОЛОЖЕННЯ
Економічна система підприємства охоплює економічні процеси і зв’язки в обороті виробничих фондів. Цей процес є безперервним, цілеспрямованим, що потребує відповідного управління економічною системою та контролю за її функціонуванням. Управління економічною системою здійснюється на інформаційному рівні за допомогою перетворення та використання потоків інформації, що функціонують усередині системи і надходять до неї із зовнішнього середовища. Ринкова економіка потребує розгалуженої мережі фінансово-кредитних органів (ФКО), які обслуговують переміщення грошових потоків і потоків цінних паперів. Найпоширенішими з них є банки, інвестиційні фонди та компанії, довірчі товариства, страхові організації. Особливістю діяльності ФКО є наявність множинних зв’язків із суб’єктами підприємницької діяльності, значні обсяги аналізованої інформації, що характеризується мінливістю, оперативністю, необхідністю актуалізації.

Однією з умов ефективної роботи ФКО та організацій будь-якої форми господарювання є перехід до безпаперової технології оброблення економічної та зокрема фінансово – кредитної інформації з використанням сучасних економіко-математичних методів, тобто створення автоматизованих інформаційних систем. Саме вони, будучи цілісними, динамічними ІС дають змогу виробляти науково обґрунтовані управлінські рішення.

Тематика контрольної роботи стосується інформаційних систем об’єктів народного господарювання. Метою виконання контрольної роботи є перевірка теоретичних знань щодо структури інформаційної системи існуючих господарчих підприємств та вміння самостійної організації інформаційної системи стосовно поставленої задачі.


  1. Вимоги до виконання контрольної роботи

Контрольна робота оформлюється на стандартних аркушах формату А4, матеріал відображують з однієї сторони аркуша зі стандартними відступами. При виконанні роботи з використанням ПЕВМ використовують шрифт Times New Roman, розмір 14, полуторним інтервалом. Загальні вимоги щодо оформлення роботи мають відповідати Державному стандарту України ДСТУ 3008-95 «Документація. Звіти у сфері науки і техніки. Структура і правила оформлення», на підставі «Положення про організацію навчального процесу у вищих навчальних закладах» (наказ Міністерства освіти України №161 від 2.06.93р.). Роботу зшивають і здають викладачеві на перевірку, у випадку позитивної рецензії відбувається обов’язковий захист роботи, в противному разі викладач повертає студенту роботу на доробку, вказуючи на допущені помилки. Для допомоги студентові у виконанні контрольної роботи, викладачем проводяться необхідні консультації відповідно до графіку навчального процесу впродовж семестру.



Контрольна робота №3 передбачає комплексне практичне завдання, яке полягає у проектуванні інформаційної системи та її реалізації у середовищі СУБД Access. Звіт про виконання контрольної роботи повинен містити:

1. Зміст.

2.Постановку задачі, що відповідає варіанту.

3. Технологічну схему процесу, відображеного у постановці задачі.

4. Інформаційний список документів.

5. Родовидовий список реквізитів вхідних документів.

6. Родовидовий список реквізитів вихідних документів.

7. Словник даних.

8. Ескізи вхідних та вихідних документів.

9. Опис локальних задач.

10. Локальні інфологічні моделі.

11. Глобальну інфологічну модель.

12. Даталогічну модель.

13. Структуру та вміст файлів автоматизованої ІС.

14. Копії екранів основних режимів автоматизованої системи.

15. У додатку повинен бути представлений, як мінімум один звіт. («Звіт про рух матеріалів на складі», «Звіт про надходження матеріалів за певний період», тощо).

16. Використана література.



  1. Теоретична основа та приклад побудови інформаційної системи

Початковим етапом автоматизації інформаційної системи (ІС) є її аналіз, який зводиться до обстеження об’єкту автоматизації – підприємства, підрозділу, відділу, під час якого складають схему технологічного процесу.

Далі збирають й аналізують вхідні та вихідні документи. Аналіз вихідних документів дає можливість установити основні функції підсистеми і джерела формування реквізитів цих документів. Відповідно визначають перелік реквізитів, джерела надходження, способи та шляхи одержання вхідних документів. Далі складають за певною формою інформаційний список вхідних і вихідних документів, які фігурують в межах відокремленої підсистеми (Табл.1), розробляють схему документообігу між її підрозділами у вигляді схеми технологічного процесу або алгоритму оброблення інформації чи у вигляді схеми бізнес –процесу.

Таблиця 1

Інформаційний список документів

Якщо оброблення інформації не було автоматизованим і логіка цього процесу або предметна технологія не повинна змінюватися, тобто не передбачається докорінна зміна бізнес-процесів на підприємстві, то схема оброблення інформації відображає наявну предметну технологію.

За докорінної реконструкції бізнес-процесів або розроблення оригінального проекту уточнюють форми документів, їхній реквізитний склад, а також склад кінцевих користувачів підсистем, документообіг, організаційні та правові моменти оброблення інформації. У цьому разі схема оброблення інформації відповідає новій предметній технології або новому бізнес-процесу.

Вхідні та вихідні документи аналізують на наявність реквізитів, що перетинаються. З цією метою складають родовидові списки елементів даних окремо для вихідних і вхідних документів за певною формою. (табл. 2)



Таблиця 2

Родовидовий список реквізитів вихідних (вхідних) документів


Зі списків вилучають елементи, що дублюються, синоніми, омоніми, елементи, які обчислюються. Родовидовий список включає згруповані за видом реквізити документів. Наприклад, перелічуються разом усі дати, потім усі коди та ін. Це спрощує процедуру вилучення елементів, що дублюються, синонімів, омонімів, елементів, які обчислюються.

Після цього родовидові списки вхідних і вихідних документів порівнюють з метою вилучення з розгляду елементів даних, які не є актуальними для підсистеми. У словник даних , складений за формою (Табл. 3), необхідно внести реквізити, спільні для обох списків, з урахуванням тих, які потрібні для формування реквізитів вихідних документів.
Таблиця 3

Словник даних

За результатами попередніх етапів відокремлюють локальні задачі виконання окремих функцій у розроблюваній підсистемі. З цією метою схему оброблення інформації розбивають на локальні задачі. Головна умова при відокремленні задач полягає в тому, щоб у межах однієї задачі оброблявся один набір даних з однією метою. Після цього складають таблицю зв’язків “Задача – дані” за формою (Табл.4) , яку потім використовують при побудові локальних ER-діаграм.



Таблиця 4

Таблиця зв’язків “Задача-дані”

Для задоволення інформаційних потреб усіх користувачів в автоматизованій ІС існує банк даних (БнД) — один з основних компонентів інформаційного забезпечення ІС, який ще називають системою бази даних, що не змінює смислове навантаження цього поняття. Інформаційним ядром цієї системи є база даних (БД).

Наступним етапом є формулювання вимог до розроблюваної БД. Після цього розробляють ескізи вхідних і вихідних документів. У такий спосіб забезпечується доповнення основних функцій розробленої підсистем.
Оцінювання доцільності розробки інформаційної системи
Цей етап характерний саме для розробки ІС, а не БД. Результати роботи на цьому етапі є вихідними для проектування БД як основної складової інформаційного забезпечення.

Раніше виконана робота дає можливість прийняти попередні рішення за видами забезпечення (математичне, технічне, програмне, організаційне, правове, ергономічне) і принципово оцінити доцільність розроблення підсистеми ІС.

Принципово важливими є вибір технічного та програмного забезпечення як середовища розробки й експлуатації підсистеми, що проектується. Технічні засоби вибираються з урахуванням очікуваного обсягу інформації, складності задач і вимог замовника. Зокрема, вибирають локальний або розподілений варіант ІС. Цей вибір принципово визначає діапазон спільного програмного забезпечення (ОС і мов програмування), БД та СУБД.

Лінгвістичне забезпечення пов’язане з вибором мовних засобів конкретної СУБД, мови видачі повідомлень і мови, якою вносять записи в БД.

Методичне забезпечення визначає реорганізацію документообігу з метою максимального підвищення ефективності оброблення інформації при застосуванні засобів автоматизації

Організаційне забезпечення пов’язане зі структурною реорганізацією підрозділів підприємства при зміні функцій виконавців внаслідок автоматизації та встановлення регламенту робіт розробників ІС і користувачів.

Правове забезпечення є сукупністю норм, зафіксованих у різноманітних директивних та нормативних актах щодо порядку створення й експлуатації ІС.

До ергономічного забезпечення належить сукупність користувачів ІС.

Усі прийняті рішення є попередніми, але вони дають змогу оцінити фінансові та часові витрати на розроблення і провадження ІС, дійти висновку щодо доцільності подальшої роботи.
Побудова концептуальної моделі БД
Концептуальна модель (схема БД) є формальним поданням ІС на понятійному рівні, тобто загальною логічною структурою БД. Завдання концептуального інфологічного проектування полягає в одержанні логічної моделі БД у термінах об’єктів ІС та зв’язків між ними, що не залежить від конкретної СУБД й узагальнює інформаційні вимоги потенційних користувачів ІС.

Розрізняють два основних методи концептуального інфологічного проектування: низхідне проектування (метод формулювання та аналізу сутностей) і висхідне проектування (метод синтезу атрибутів). Ці методи недостатньо формалізовані, єдиних правил використання їх не існує.

Найпридатнішим для практичного застосування є перший метод. Він складається з двох етапів проектування БД: ідентифікації та моделювання локальних інформаційних структур БД у вигляді локальних ER-діаграм і побудови глобальної інформаційної моделі — глобальної ER-діаграми.

Проектування локальних інформаційних структур
Локальні інформаційні структури відповідають локальним задачам.

У процесі проектування ER – діаграми для локальної задачі доцільно керуватися кількома евристичними правилами.



Правило 1. В локальній задачі не рекомендується виділяти більше семи типів сутностей. Графічно тип сутностей в нотації П. Чена зображується у вигляді пойменованого прямокутника. Найменування заноситься у називному відміннику однини.

Правило 2. Кожен тип сутності повинен мати певний ідентифікатор: первинний ключ (один чи кілька атрибутів, що однозначно ідентифікують конкретний об’єкт ) та атрибути опису. Первинний ключ має бути унікальним для всієї БД і коротким (якщо його вибирають із можливих ключів). За відсутності такого ключа його розробляють і потім вводять у словник даних. Графічно атрибути типів сутностей зображують в овалах, які зв’язуються з прямокутниками. Ключ на діаграмі підкреслюють.

Наприклад, тип сутності “Виріб”, як показано на рис.1, характеризується набором таких атрибутів: “Назва виробу”, “Параметр 1”, “Параметр 2”, “Параметр 3”, “Параметр 4”, “Кількість”, “Ціна”. Якщо ці атрибути, крім атрибутів “Кількість” та “Ціна”, незалежні, то їх сукупність єдиним способом визначає конкретний екземпляр сутності “Виріб” і тому є можливим складним ключем. Для розв’язання задачі обліку виробів такий ключ незручний, через що його замінюють (навіть при ручному обробленні інформації) коротким еквівалентом “Код виробу”.







Рис 1. Відображення типу сутності виріб на ER-діаграмі.
Правило 3. Зв’язок між типами сутностей відбиває фактичну або можливу взаємодію між ними, а також динаміку взаємодії між екземплярами сутностей . Графічно зв’язок зображують у вигляді пойменованого ромба з обов'язковим позначенням типу асоціативності (1:1, 1:М, М:М). Найменування зв’язку має відображати його зміст і бути коротким.

Зв’язок типу 1:1. Він передбачає, що на кожному складі можуть зберігатися вироби одного типу (ідентифікуються власним кодом) у певній кількості. Кожен із виробів може зберігатися лише на одному складі, тобто склад визначає виріб, на якому зберігаються вироби одного типу з однаковими параметрами. ER – діаграму цього фрагмента БД зображено на Рис.2.
Р
ис 2.
ER – діаграма фрагмента БД “Склад — Виріб” з типом зв’язку 1:1
Зв’язок типу 1:М. Цей тип зв’язку означає, що на кожному складі зберігається багато різних виробів, але вироби кожного типу зберігаються лише на одному складі. В цьому разі склад визначає тип виробу. Наприклад, склад процесорів, склад модулів пам'яті, склад устаткування для мереж тощо. При цьому всі вироби можуть мати різні параметри. ER – діаграму цього фрагмента БД показано на Рис. 3.





Рис.3. ER- діаграма фрагмента БД “Склад — Виріб” з типом зв’язку 1:М.
Зв’язок типу М:М. Він свідчить про те, що на кожному складі може зберігатися багато

виробів, причому кожен виріб може зберігатися на багатьох складах. Наприклад, склади комерційних організацій зберігають різноманітні вироби, які можуть бути розміщені на багатьох складах в різних кількостях. Крім того, ціна одного й того самого виробу може бути різною (залежати, скажімо, від відстані від складу до місця доставки). ER- діаграму цього фрагмента БД зображено на рис. 4.



Рис. 4. ER- діаграма фрагмента БД “Склад — Виріб” з типом зв’язку М:М
Правило 4. Тільки при зв’язку типу М:М можуть бути дані перетину, тобто дані, що одночасно належать з’єднуваним типам сутностей. Такі дані є атрибутами зв’язку. У зв’язку типу М:М (див. Рис. 4) даними перетину є атрибути зв’язку “Кількість” та “Ціна”.

Правило 5. Розрізняють унікальні сутності, що не залежать від жодних сутностей в межах ІС конкретної задачі, та залежні (породжені) сутності. Це важливо враховувати при встановленні зв’язку між типами сутностей.

У зв’язку типу 1:1 (див. Рис.2) сутності “Склад” та “Виріб” залежать одна від одної. Яку з них вважати породжувальною, а яку породженою, можна зробити висновок тільки після уточнення постановки задачі. Точкою входу в таку модель даних може бути будь-яка з сутностей. У даному разі породжувальною можна вважати сутність “Склад”, а породженою – “Виріб”.

У зв’язку типу 1:М (див. Рис. 3) сутність “Склад” є породжувальною, а сутність “Виріб” – породженою.

У зв’язку типу М:М сутності “Склад” та “Виріб” є незалежними (автономними). Зв’язок між ними встановлюється тоді, коли конкретний екземпляр виробу потрапляє на конкретний склад.



Проектування глобальної інфологічної моделі
Проектування глобальної інфологічної моделі даних полягає в інтеграції локальних інформаційних структур, здобутих на попередньому етапі.

При об’єднанні локальних інформаційних структур у глобальну використовують поняття: ідентичність, агрегація, узагальнення.



Ідентичністьоднакове семантичне значення двох або більше об’єктів моделі.

Наприклад, об’єкти “Фірма – виробник” і “Фірма – постачальник” у межах певної ІС можуть належати до однієї категорії, тобто бути ідентичними. Наступний приклад, пов’язаний із

фрагментом БД ІС обліку випуску на ринок продукції фірм-виробників, ілюструє рис 5.

Зв’язки “Пропозиція на продаж” і “Випуск на ринок” та їхні атрибути ідентичні й мають бути об’єднані в один зв’язок з новими атрибутами, це є прикладом того, що при складанні родо – видових списків реквізитів документів, а також словника даних були виявлені н
е всі синоніми.


Рис. 5. Перший варіант діаграми фрагмента БД ІС обліку випуску продукції на ринок
Графічне відображення даних є більш наочним і дає змогу під іншим кутом зору виконати аналіз ІС. Після корекції діаграми необхідно повернутися до словника даних й уточнити склад його елементів.



Рис. 6. Другий варіант ER-діаграми фрагмента БД ІС обліку випуску продукції на ринок
Агрегаціяабстракція даних, що дає змогу трактувати сукупність різноманітних за природою об’єктів як новий об’єкт.

Наприклад, сукупність об’єктів “Студент”, “Дисципліна”, “Викладач”, “Оцінка” в межах певної ПС може бути подана у вигляді агрегованого об’єкта “Екзамен” з атрибутами “Студент”, “Дисципліна”, “Викладач”, “Оцінка”.



Узагальнення — абстракція даних, що дає змогу трактувати клас різних подібних типів об’єктів як один пойменований узагальнений тип об’єкта.

Наприклад, при організації БД ІС міської товарно-сировинної біржі дані про брокерів міських брокерських контор, які укладають угоди купівлі-продажу певного товару, недоцільно зберігати в різних масивах і відповідно зображати у вигляді окремих типів сутностей, оскільки кожний брокер у день торгів може бути і продавцем, і покупцем. Цей варіант моделі, показаний на рис. 7, характеризується необґрунтованим дублюванням даних.



Рис 7. Перший варіант ER-діаграми фрагмента БД ІС товарно-сировинної біржі.
Доцільно, використавши поняття узагальнення, зберігати єдиний масив даних про брокерів, а угоду зобразити у вигляді петлі зв'язку між брокерами, як це показано на Рис.8.

Наступний приклад — використання узагальнення при об’єднанні різних типів сутностей — стосується організації БД ІС обліку лізингових контрактів, коли підприємства – рентери укладають угоди на довгострокову оренду устаткування, що належить підприємству – ліссору. Тип сутності “Ліссор” подібний до типу сутності “Рентер” (вони описуються однаковими атрибутами). Тому , в даному разі використовують принцип узагальнення для об'єднання цих типів сутностей в одну – “Підприємство”. Зв’язок “Лізинговий контракт” відображає укладення лізингової угоди. Тип сутності “Устаткування” підпорядкований типу сутності “Підприємство”. При цьому під устаткуванням залежно від постановки задачі обліку можна розуміти як множину видів устаткування, що пропонується для укладання угоди, так і устаткування, яке фактично становить предмет угоди. У такому разі ER-діаграма включає цикл зв'язку між типами сутностей “Підприємство” й “Устаткування”, як це показано на Рис. 9.


Проектування реалізації бази даних
Точно розмежувати інфологічний і фізичний етапи проектування БД досить важко через відсутність установленої термінології. Тому прийнято вважати, що на етапі інфологічного проектування дані розглядають без урахування специфіки СУБД, що використовується, а особливості її структури на етапі фізичного проектування, на якому одержують СУБД — орієнтовану схему БД, прийнято називати проектуванням реалізації.





Рис. 8. Другий варіант ER-діаграми фрагмента БД ІС товарно-сировинної біржі.



Рис 9. ER – діаграма фрагмента БД ІС обліку лізингових контрактів.
Проектування реалізації БДперехід до даталогічної концептуальної моделі даних (СУБД – орієнтованої моделі).

Інфологічна концептуальна модель є більш загальною, порівняно з даталогічною концептуальною моделлю, відображенням стану інформаційної системи. Даталогічна модель потребує більш детального опису стану об’єктів і зв’язків між ними через необхідність відображення моделі даних у пам’яті обчислювальної системи. Тут можуть з’явитися додаткові об’єкти зберігання в БД. Наприклад, ER-діаграму фрагмента БД ІС обліку переміщення матеріалів на складі, що відображає поставку матеріалів сторонніми організаціями і реалізацію надлишків матеріалів стороннім організаціям, можна зобразити двома варіантами. Перший з н
их показано на рис. 10. Дії “Одержання” та “Реалізація” подано різними зв’язками.


Рис. 10. Перший варіант ER-діаграми фрагмента БД ІС обліку переміщення матеріалів
Другий варіант цього фрагмента зображено на рис. 11. Контакти зі сторонніми організаціями тут подано у вигляді одного зв’язку “Зовнішня операція” з додатковим атрибутом “Код операції”, не зафіксованим у словнику даних. Атрибут може набувати двох значень: 1 – “Одержання” і 0 – “Реалізація”. Другий варіант фрагмента має переваги над першим. Вони зумовлені тим, що замість двох масивів — зв’язок між типами сутностей “Матеріал” і “Зовнішня організація” використано лише один – “Зовнішня операція”. Новий атрибут “Код операції” не спричиняє істотної надмірності.





Рис. 11. Другий варіант ER-діаграми фрагмента БД ІС обліку переміщення матеріалів
На концептуальному інфологічному рівні можливим є використання як першого, так і другого варіантів ER-діаграми. Перехід до більш раціональної моделі можна виконати на даталогічному рівні, на якому відбувається уточнення та оптимізація структури БД.

На етапі проектування реалізації БД також можливим є доповнення одержаної інформаційної моделі інформаційними структурами (у вигляді ER-діаграм), що зумовлено додатково виявленими запитами до БД.

Надалі цей етап проектування є переходом від одержаної концептуальної інфологічної моделі до даталогічної або СУБД- орієнтованої моделі даних.

Графічно даталогічна модель є відображенням інфологічної. У ній тип сутності зображують у вигляді поіменованого прямокутника, кожна клітина якого відповідає атрибуту сутності. Ключ підкреслюється. Зв’язки між записами відображають у вигляді спрямованих ліній з зазначенням типів зв’язку 1:1, 1:М, М:М. Дані перетину при зв’язку типу М:М указуються поруч із лінією зв’язку.

Переходячи до даталогічної моделі даних, варто керуватися такими евристичними правилами.

Правило 1. Складна мережна модель є найпоширенішою моделлю даних, оскільки вона відображає складність зв’язків між об’єктами інформаційної системи. Тому, як правило, даталогічна концептуальна модель даних відображається у вигляді складної мережної моделі.

Даталогічну модель стосовно задачі обліку переміщення матеріалів, що відповідає другому варіанту фрагмента ER-діаграми (див. Рис. 11), показано на рис. 12. Це неоднорідна складна мережна модель.



Правило 2. Від складної мережної моделі здійснюється перехід до простої мережної моделі. При цьому позбавляються зв’язків типу М:М, вводячи додатковий запис, який обов’язково повинен містити ключі записів, що з’єднуються.

Н
а рис. 13 зображено неоднорідну просту мережну модель, що відповідає складній моделі на рис. 12.



Р
ис. 12.
Даталогічна модель фрагмента БД ІС обліку переміщення матеріалів у вигляді складної мережі

Рис. 13. Даталогічна модель фрагмента БД ІС обліку переміщення матеріалів у вигляді

простої мережі



П
равило 3.
При усуненні “залежності від шляху” в ієрархічних фрагментах моделі даних у породжені записи включають ключі породжувальних записів. Якщо екземпляри породжених записів ураховують у межах породжуючих записів, то первинним ключем породженого запису стає складний ключ. Він складається з первинного ключа породжуючого запису та первинного атрибута породженого запису.
Рис. 14. Ієрархічна даталогічна модель фрагмента БД ІС обліку виробів на складі з залежним записом “Виріб”
На рис. 14 показано ієрархічну даталогічну модель фрагмента БД ІС обліку виробів на складі, що відповідає ER-діаграмі (рис. 3). У даному випадку атрибут породженого запису “Код виробу” означає нумерацію виробів у межах кожного складу.

П
ісля усунення “залежності від шляху”, як це показано на рис. 15, ключ породженого запису “Виріб” стає складним. Він складається з ключа породжувального запису “Склад” і коду виробу на складі.



Рис. 15. Ієрархічна даталогічна модель фрагмента БД ІС обліку виробів на складі з незалежним записом “Виріб”
Первинний ключ породжувального запису надходить до породженого запису і стає зовнішнім ключем, необхідним для з’єднання записів за запитами до БД. Результатом усунення “залежності від шляху” є те, що всі записи в моделі даних стають автономними, незалежними від породжувальних записів.

Правило 4. У мережній моделі поняття “породжувальний” і “породжений” записи умовні, тому що точкою входу в ній може бути будь-який запис. Вважати записи породжувальними та породженими можна тільки після вибору точки входу. Тоді “залежність від шляху” усувають так само, як і в ієрархічній структурі даних.

У прикладі з фрагментом БД, зображеному на рис. 13, запис “Зовнішня операція” містить ключі породжувальних записів, тому в цій моделі залежності від шляху немає.

Приклад, який показано на рис. 16, ілюструє просту мережну модель із залежним записом. Це фрагмент БД ІС обліку матеріалів на складі свідчить, що кожен матеріал залежить певним чином від постачальника та складу.





Рис. 16. Даталогічна модель БД ІС обліку матеріалів на складі з залежним записом “Матеріал”
Запис “Матеріал” стане автономним, якщо міститиме ключі записів “Склад” та Фірма-постачальник” або як зовнішні ключі, або як компоненти складного первинного ключа “Код постачальника” + “Код складу” + “Код матеріалу”. Рис 17 ілюструє останній варіант ключа запису “Матеріал”.

Рис. 17. Даталогічна модель фрагмента БД ІС обліку матеріалів на складі з незалежним записом “Матеріал”
Правило 5. Фрагменти структури, що містять цикли та петлі, спрощують по-різному залежно від типу зв’язку між типами сутностей. За наявності зв’язків типу М:М у циклі або в петлі вводять додатковий запис із ключами записів, які з’єднуються.

Стосовно фрагмента БД ІС товарно-сировинної біржі (див. Рис 8) даталогічна модель даних є складною мережею (рис. 18).

На рис. 19 показано даталогічну просту мережну модель даних, в якій усунено зв’язок типу М:М і залежність від шляху. Ця модель відповідає складній мережній моделі даних, яку зображено на рис 18. Атрибути “Код контори 1” та “Код контори 2” належать домену “Код контори” і визначають коди контор брокера-продавця та брокера-покупця товару. Атрибути “Код брокера 1” та “Код брокера 2” належать домену “Код брокера” і визначають коди брокера-продавця та брокера-покупця, у своїх конторах. Запис “укладання угоди” має складний ключ. Перші два атрибути запису визначають брокера-продавця, два наступних — брокера-покупця, п’ятий — код товару.

Стосовно фрагмента БД ІС обліку лізингових контрактів (див. Рис. 9) даталогічна модель є неоднорідною складною мережною (рис. 20).

На рис. 21 зображено просту мережну модель даних, в якій усунено зв’язок типу М:М і залежність від шляху. Ця модель відповідає складній мережній моделі даних, яку показано на рис. 20.

Р
ис. 18.
Даталогічна складна мережна модель даних фрагмента БД ІС товарно-сировинної біржі
Первинний ключ запису “Лізинговий контракт” є складним: “Код підприємства 1” + “Код підприємства 2” + Код устаткування” + “Дата контракту”. Атрибути “Код підприємства 1” та “Код підприємства 2” належать домену “Код підприємства” і визначають код ліссора та код рентера відповідно.

Р
ис. 19.
Даталогічна проста мережна модель даних фрагмента БД ІС товарно-сировинної біржі





Рис. 20. Даталогічна модель фрагмента БД ІС обліку лізингових контрактів у вигляді складної мережі
Р
ис. 21.
Даталогічна модель фрагмента БД ІС обліку лізингових контрактів у вигляді простої мережі

Правило 6. Після того як усі записи даталогічної моделі даних стали автономними, тобто незалежними від породжувальних записів, вони можуть бути подані у вигляді схем окремих відношень. Даталогічна реляційна модель даних містить набір схем відношень або записів, які графічно не пов’язані між собою. Схему відношення зображують у вигляді вектора. Назва вектора відповідає назві запису. В дужках через кому іде перелік імен атрибутів. Первинний ключ підкреслюють.

Правило 7. Даталогічна реляційна модель даних має складатися з набору схем відношень. Відношення цієї моделі мають бути зведені як мінімум до третьої нормальної форми.

Правило 8. Первинні ключі відношень використовуються при проектуванні унікальних первинних ключових або індексних файлів, за допомогою яких здійснюється пошук даних у пам’яті обчислювальної системи.

Правило 9. У відношенні порядок атрибутів у складному ключі не має значення, а при проектуванні індексного або ключового файла порядок полів, що відповідають цим атрибутам, має принципове значення. Сортування даних ключа виконується спочатку за першим атрибутом, а в межах однакових екземплярів першого атрибута ключа — за наступним атрибутом і т.д.

Правило 10. Одержану даталогічну модель аналізують з метою оптимізації (зокрема ,оцінюється ефективність схеми БД за обсягом оброблення).

Кожна прикладна задача характеризується частотою виконання та кількістю звернень LRA (Logical records access) до логічних записів БД. Кількість LRA може бути оцінена за даними таблиці “Задача — дані” та даними про частоту виконання кожної прикладної задачі.

Загальна кількість LRA в усіх прикладних задачах є одним з основних критеріїв ефективності схеми БД. LRA характеризує загальну кількість звернень до фізичних записів БД, що містяться в зовнішній пам’яті. Чим вищий цей показник у системі, тим нижча швидкість оброблення. Тому прикладна задача з найбільшим значенням LRA має бути досліджена з метою вдосконалення структури даних, зменшення частоти виконання, вирішення питання про доцільність оптимізації зберігання записів у процесі експлуатації БД. Останню обставину особливо важливо враховувати тоді, коли файл даних через великий розмір повністю не вміщується в оперативній пам’яті. Вибірка записів такого файла, відсортованого за ключем, може забирати багато часу. Це зумовлено тим, що близькі за ключем записи можуть фізично знаходитись на диску на значній відстані один від одного. Такі файли треба час від часу перезаписувати, заздалегідь проіндексувавши їх за первинним ключем. Це мінімізує час оброблення записів. За результатами аналізу розроблюють пропозиції щодо вдосконалення схеми БД і режимів оброблення даних.
Приклад проектування бази даних інформаційної системи “Формування замовлень на товари на фірмі”
Постановка задачі
Торгівельно-посередницька фірма має намір автоматизувати процес формування замовлень на товари. БД, що проектується, разом з обчислюваною системою, СУБД, словником даних й адміністратором БД відіграють роль забезпечувальної підсистеми ІС процесу збирання та оброблення інформації про постачальників і товари на фірмі, а також формування замовлень на товари.

Традиційно товари обирають службовці фірми вручну за каталогами та рекламними проспектами фірм-постачальників. Протягом перших трьох днів тижня службовець фірми обирає з каталогів і рекламних проспектів інформацію про товари та фірми, які можуть зацікавити адміністрацію, і вносить її у зведену таблицю товарів 7, що пропонується для продажу.



Таблиця 5

Зведена таблиця запропонованих для продажу товарів.

PCIRAM-32HDD 2,5 ГбайтТе саме0001Те самеТе самеТе самеТе саме2210010425.01.010004Прин-терLX-1050А3Pin 15Ciri-lic0001_”__”__”__”_232010345-55-90262520525.01.010003Penti-umПро-центДата0001ПК 386/7 DX-40ISARAM 4HDD 80 МбайтSVGA 14” 0001«Эпі-центр»61024, вул. Пу-шкін-ська, 8ІвановНазва поста-чаль-никаАдреса фірми поста-чаль-никаІм’я мене-джераТеле-фон фірми Рей-тингЦіна товару у.о. Кільк./Код товару

Pro-200


І.І.

зн.


Назва товару

Пара-метр 1

Пара-метр 2

Пара-метр 3

Назва товаруКод фірми-постачальникаНазва фірми-постачальникаКількість замовленого товару, шт.000125.01.01………………………………………...Пара-метр 4Код поста-чаль-ника

Раз на тиждень службовець фірми — експерт з відбору товарів відбирає зі зведеної таблиці 5 товари для придбання за таким принципом: вибирається товар, потім — постачальник цього товару ( з урахуванням вартості товару, знижки, рейтингу фірми-постачальника); вказується кількість товару, що купується. Результати заносять у таблицю за формою табл. 6. Описаний процес є процесом формування кошика замовлень, який включає замовлення на товари елітної групи фірмам-постачальникам із досить високим рейтингом на світовому ринку або замовлення на товари за нижчими цінами та з більшим процентом знижки на вартість товару.



Таблиця 6

Таблиця замовлення товарів
Код товару

ПК 386/7 DX-40

0001

“Епіцентр”

100

0005

Принтер Epson

0001

Те саме

100

0011

CD-ROM

0001

_”_

300

0002

ПК 386 SX-80

0002

“Джин”

150

0007

Принтер Star

0002

Те саме

150

0010

CD-ROM

0003

“Гейзер”

800

Після цього спеціальний службовець, який займається оформленням замовлень, вибирає зі сформованого кошика дані про постачальників і замовлені в них товари, присвоює кожному замовленню номер (на фірмі прийнято наскрізну нумерацію замовлень протягом року), проставляє дату замовлення (як правило, поточну дату), заповнює та друкує картку замовлення за формою, показаною на рис. 22. Далі пакет замовлень готується для відправки фірмам-постачальникам.

Рекламні проспекти і каталоги фірм-постачальників товарів поновлюють у середньому один раз на квартал, причому фірми-постачальники подають рекламу в різний час. Тому дані, що заносяться в зведену таблицю помічають датою. Щодня вводиться до 100 рядків. З них приблизно 80 стосуються нових товарів, а 20 — нових фірм-постачальників. При цьому вносять інформацію приблизно про 240 товарів та 60 фірм-постачальників. Експерт відбирає до кошика замовлень до 2000 товарів від приблизно 20 фірм-постачальників.

Всього формують щотижня до 20 карток замовлень на приблизно 200 товарів. Після підготовки карток до відправлення кошик замовлень повністю очищають, тобто щотижня готують нову табл. 6. Інформацію про відправлені замовлення переносять до архіву замовлень та зберігають протягом року. Після закінчення кварталу дані в зведеній таблиці повністю поновлюють.

Обсяг накопичених за квартал даних приблизно становить:

100рядків x 3 дні x 4 тижні x 3 міс. = 3600 записів, з них нових товарів стосуються приблизно 240 од. x 4 тижні x 3 міс. = 2880 записів, а нових фірм-постачальників - 60 фірм-постачальників x 4тижні x 3 міс. = 720 записів.

Обсяг даних, що накопичились у кошику замовлень (див. табл. 6), приблизно становить:

200 од. * 20 фірм-постачальників = 4000 записів.

Після співбесід із службовцями фірми були складені інформаційний список документів, що оброблялися вручну (табл. 7), і схема існуючого технологічного процесу оброблення інформації на фірмі (Рис. 23).


ЗАМОВЛЕННЯ №001 Дата:01/04/2001

ФІРМА-ПОСТАЧАЛЬНИК ФІРМА-ЗАМОВНИК

Код фірми: 0001 Код фірми:0088

Назва фірми: ”Епіцентр” Назва фірми: “Істина”


Адреса: Х-23, вул. Наталіївська, 8 Адреса: Х-86, вул. Шекспіра, 8

Менеджер: Харитоненко М.І. Менеджер:Сміляченко І.І.

Тел.: 45-55-99 Тел.: 88-88-88

ЗАМОВЛЕНІ ТОВАРИ



Код товару

Назва товару

Ціна товару, у.о.

Кількість замовленого, товару, шт.

Вартість замовленого товару, у.о.

0011

CD-ROM

160

300

48000

0001

ПК 386/ DX-40

625

100

62500

0005

Принтер Epson

320

100

32000

Підсумок за товарами: 142500 у.о.

Підсумок з урахуванням знижки: 135125 у.о.

Плата за доставку (5%): 7125 у.о.

ПДВ (20%): 27025 у.о.



Разом (вартість замовлення): 169275 у.о.




Рис.22 Картка замовлення

Ретельне оброблення зібраної інформації та врахування запитів потенційних користувачів ІС є основою забезпечення функціональної повноти БД.

Елементи даних з наведених нижче документів зіставляють з функціями схеми. З цією метою спочатку складають родо-видові списки вихідних і вхідних документів та словник даних.

Родо-видовий список елементів даних для вихідних документів наведено в табл. 10, для вхідних — у табл. 11.



Таблиця 7

Інформаційний список документів

пор.

Назва документа

Тип документа

1.

Таблиця даних із каталогів товарів і рекламних проспектів (табл. 7)

Вхідний

2.

Таблиця кошика замовлень (табл. 8)

Вихідний

3.

Картка замовлення (26)

Те саме





Рис.23 Схема існуючого технологічного процесу оброблення інформації на фірмі.

Таблиця 8

Родо-видовий список елементів даних вихідних документів

пор.

Назва елемента

Фактичний/обчислюваний

Призначення

1.

Адреса фірми

Фактичний

Адреса фірми постачальника

2.

Вартість товару

Обчислюваний

Вартість замовлених товарів

3.

Дата замовлення

Фактичний

Дата оформлення замовлення

...

...

...

...

Таблиця 9

Родо-видовий список елементів даних вхідних документів

пор.

Назва елемента

Фактичний/обчислюваний

Призначення

1.

Адреса фірми

Фактичний

Адреса фірми постачальника

2.

Дата замовлення

Те саме

Дата оформлення замовлення

3.

Знижка

_”_

Розмір знижки (%) залежно від розміру партії товару

...

...

...

...

Кожен із наведених родо-видових списків аналізують з метою вилучення з них елементів, що дублюються, омонімів, синонімів, елементів, які обчислюються. Наявність омонімів усувається доданням пояснень типу “Код фірми” і “Код товару”, ”Кількість товару, що визначає розмір знижки” і “Кількість товару, що купується”. У словник даних включається підмножина даних, утворена перетином двох зазначених множин. Словник даних наведено в табл. 10.



Таблиця 10
следующая страница >>


izumzum.ru