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

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

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

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

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

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

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

з дисципліни

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

Одеса ОНПУ – 20111

МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ Одеський національний політехнічний університет

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

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

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

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

з дисципліни

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

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

напряму підготовки6.030601 – «Менеджмент»заочної форми навчання

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

Розглянуто та затверджено на засіданні кафедри ІУЗІС

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

Одеса ОНПУ – 2011

2

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

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

ЗМІСТ

ЗАГАЛЬНІ ПОЛОЖЕННЯ....................................................................................................................41.Вимоги до виконання контрольної роботи...................................................................................52.Теоретична основа та приклад побудови інформаційної системи...........................................63.Варіанти завдань..............................................................................................................................34Перелік рекомендованої літератури................................................................................................37

3

ЗАГАЛЬНІ ПОЛОЖЕННЯ

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

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

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

4

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. Використана література.

5

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

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

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

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

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

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

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

Таблиця 2 Родовидовий список реквізитів вихідних (вхідних) документів

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

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

Таблиця 3Словник даних

6

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

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

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

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

Оцінювання доцільності розробки інформаційної системи

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

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

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

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

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

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

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

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

витрати на розроблення і провадження ІС, дійти висновку щодо доцільності подальшої роботи.

Побудова концептуальної моделі БД

7

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

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

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

Проектування локальних інформаційних структур

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

кількома евристичними правилами.Правило 1. В локальній задачі не рекомендується виділяти більше семи типів

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

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

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

Рис 1. Відображення типу сутності виріб на ER-діаграмі.

Правило 3. Зв’язок між типами сутностей відбиває фактичну або можливу взаємодію між ними, а також динаміку взаємодії між екземплярами сутностей . Графічно зв’язок

8

зображують у вигляді пойменованого ромба з обов'язковим позначенням типу асоціативності (1:1, 1:М, М:М). Найменування зв’язку має відображати його зміст і бути коротким.

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

Рис 2. ER – діаграма фрагмента БД “Склад — Виріб” з типом зв’язку 1:1

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

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

9

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

Рис. 4. ER- діаграма фрагмента БД “Склад — Виріб” з типом зв’язку М:М

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

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

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

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

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

Проектування глобальної інфологічної моделі

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

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

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

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

1

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

не всі синоніми.

Рис. 5. Перший варіант діаграми фрагмента БД ІС обліку випуску продукції на ринок

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

Рис. 6. Другий варіант ER-діаграми фрагмента БД ІС обліку випуску продукції на ринок

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

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

1

“Студент”, “Дисципліна”, “Викладач”, “Оцінка”.Узагальнення — абстракція даних, що дає змогу трактувати клас різних подібних

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

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

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

Доцільно, використавши поняття узагальнення, зберігати єдиний масив даних про брокерів, а угоду зобразити у вигляді петлі зв'язку між брокерами, як це показано на Рис.8.

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

Проектування реалізації бази даних

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

1

орієнтовану схему БД, прийнято називати проектуванням реалізації.

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

Рис 9. ER – діаграма фрагмента БД ІС обліку лізингових контрактів.

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

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

1

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

них показано на рис. 10. Дії “Одержання” та “Реалізація” подано різними зв’язками.

Рис. 10. Перший варіант ER-діаграми фрагмента БД ІС обліку переміщення матеріалів

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

Рис. 11. Другий варіант ER-діаграми фрагмента БД ІС обліку переміщення матеріалів

1

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

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

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

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

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

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

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

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

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

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

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

1

простої мережіПравило 3. При усуненні “залежності від шляху” в ієрархічних фрагментах моделі

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

Рис. 14. Ієрархічна 16 даталогічна модель фрагмента БД ІС обліку виробів на складі з залежним записом “Виріб”

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

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

Рис. 15. Ієрархічна 16 даталогічна модель фрагмента БД ІС обліку виробів на складі з незалежним записом “Виріб”

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

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

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

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

1

Рис. 16. Даталогічна модель БД ІС обліку матеріалів на складі з залежним записом “Матеріал”

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

Рис. 17. Даталогічна модель фрагмента БД ІС обліку матеріалів на складі з незалежним записом “Матеріал”

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

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

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

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

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

1

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

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

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

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

1

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

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

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

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

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

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

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

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

1

схеми БД і режимів оброблення даних.

Приклад проектування бази даних інформаційної системи “Формування замовлень на товари на фірмі”

Постановка задачі

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

Традиційно товари обирають службовці фірми вручну за каталогами та рекламними проспектами фірм-постачальників. Протягом перших трьох днів тижня службовець фірми обирає з каталогів і рекламних проспектів інформацію про товари та фірми, які можуть зацікавити адміністрацію, і вносить її у зведену таблицю товарів 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ІвановНазва поста-чаль-никаАдреса фірми поста-чаль-никаІм’я

Назва товару Пара-метр 1 Пара-метр 2 Пара-метр 3

2

мене-джераТеле-фон фірми Рей-тингЦіна товару у.о. Кільк./Код

товару

Pro-200

І.І.

зн.

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

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

ПК 386/7 DX-40 0001 “Епіцентр” 100

2

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

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

Код товару

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 фірм-постачальників. Експерт відбирає до кошика

2

замовлень до 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.

2

Таблиця 7

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

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

Вхідний

2. Таблиця кошика замовлень (табл. 8) Вихідний3. Картка замовлення (26) Те саме

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

Таблиця 8

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

№ пор. Назва елемента Фактичний/обчислюваний Призначення

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

2. Вартість товару Обчислюваний Вартість замовлених товарів

3. Дата замовлення Фактичний Дата оформлення замовлення

... ... ... ... Таблиця 9

2

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

№ пор. Назва елемента Фактичний/обчислюваний Призначення

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

2. Дата замовлення Те саме Дата оформлення замовлення

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

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

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

Таблиця 10

Словник даних№ пор.

Назва елемента Ідентифікатор Тип і довжина

Призначення

1. Адреса фірми ADR_SUP C(50) Адреса фірми-постачальника

2. Дата замовлення DAT D(8) Дата оформлення замовлення

3. Знижка REBATE N(2) Розмір знижки (%) залежно від розміру партії товару

... ... ... ... ...Родо-видові списки зручно складати відразу у вигляді спеціальних файлів БД з ключовим

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

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

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

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

Задача 1Перегляд каталогів та рекламних проспектів і заповнення табл. 5. Блоки 1 та 2 (див. рис.

23). У задачі використовуються дані каталогів і рекламних проспектів. Мета - заповнити таб. 5.Задача 2Формування кошика замовлень (див. табл. 6). Блок 3 (див. рис 23). У задачі

використовуються дані табл. 5 про товари, фірми- постачальники і кількість товарів, що замовляються. Мета — формування списку товар - постачальник для реальних замовлень.

Задача 3Формування карток замовлень конкретним фірмам-постачальникам згідно з кошиком

2

замовлень. Блок 4 (див. рис. 23). У задачі використовують дані кошика замовлень. Мета — формування карток замовлень конкретним фірмам-постачальникам на конкретні товари.Результати аналізу інформаційної системи зведено в таблицю зв'язку “Задача-дані” (табл. 11). Таблиця 11

Таблиця зв'язку “Задачі — дані”№ пор.

Назва задачі Тип Частота виконання

Обсяг Відділ Елементи даних

1. Перегляд каталогів та рекламних проспектів заповнення табл. 7

Виробнича Щодня 100 рядків

№1 1,3 - 5,7 - 10,12 - 18

2. Формування кошика замовлень (див. табл. 8)

Те саме Щотижня 1 кошик Те саме

1,3 - 10,12 - 18,

3. Формування карток замовлень (див. рис. 26)

Те саме Те саме 20 карток _”_ 1-18

2

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

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

Перше локальне подання моделі даних стосується рядового службовця, який займається обробленням каталогів і рекламних проспектів та заповненням табл. 5. Він же перевіряє і виправляє дані у тимчасовому масиві. Редагування даних у файлах самої бази виконує її адміністратор. У першому локальному поданні моделі даних виділяють типи сутностей “Постачальник” і “Товар”. Атрибутами, що ідентифікують екземпляри цих сутностей, є їхні коди. Решта атрибутів указаних сутностей має описовий характер. Зв'язок між зазначеними типами сутностей має назву “Пропозиція”. Тип асоціації цього зв'язку М:М. У зв'язку є власні атрибути (дані перетину), які одночасно належать типам сутностей “Постачальник” та “Товар”. ER- діаграму першого локального подання моделі даних зображено на рис. 25.

Друге локальне подання моделі даних стосується експерта, який формує кошик замовлень і перевіряє правильність його заповнення. Тут виділяються типи сутностей “Постачальник” і “Товар” з атрибутами, показаними на рис 26.

Третє локальне подання моделі даних стосується службовця, який оформляє замовлення. Тут до сутностей і зв'язків першого подання моделі даних додають нові, пов'язані з формуванням кошика замовлень. Тип сутності “Товар” у цьому разі включає не всі товари з табл. 5, а тільки ті, які вибрано експертом для придбання (звідси й назва “Вибраний товар”). ER-діаграму третього локального подання моделі даних показано на рис. 27. Тут тип сутності “Постачальник” включає не всіх постачальників з табл. 5, а тільки тих, які постачають відібрані для придбання товари (звідси й назва “Вибраний постачальник”).

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

2

Рис. 25. ER-діаграма першого локального подання моделі даних

Рис. 26. ER-діаграма другого локального подання моделі даних

сутності “Постачальник”. Тому недоцільно виділяти окремі типи сутностей “Вибраний товар” і “Вибраний постачальник”. Метод узагальнення при об'єднанні вказаних локальних подань дає змогу залишити тільки типи сутностей “Постачальник” та “Товар”.Глобальну ER-діаграму (або глобальну інфологічну модель даних) показано на рис. 29.

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

2

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

Рис. 27. ER-діаграма третього локального подання моделі даних.

Наступне припущення було по`вязане з тим, що нумерація замовлень оновлюється після очищення кошика замовлень наприкінці кожного тижня. Відповідно обсяг БД можна з'ясувати тільки після уточнення структури відношень реляційної даталогічної моделі даних.

Передбачуваний обсяг БД можна оцінити в такий спосіб. Існує тимчасовий файл TEMPOR з полями, що відповідають структурі табл.5. Максимальна кількість його рядків — 10.Передбачувана ємність пам'яті для цього файла становить: 10 од. Товару/день х 200 байт = 2 Кбайт.

Існує файл БД, в якому зберігається інформація про товари і фірми-постачальники з полями, що відповідають структурі табл.5. Інформація в ньому накопичується протягом кварталу. Приблизна ємність пам'яті для нього становить :

100 рядків/день * 3 дні * 4 тижні* 3 міс. * 200 байт = 720 Кбайт.Існує файл кошика замовлень з полями, що відповідають структурі табл. 6. Інформація в

ньому накопичується протягом кількох днів. Приблизна ємність пам'яті для нього становить :200 од. товару/тиждень * 61 байт = 12,2 Кбайт.

Заголовна частина файла складається з власне заголовка, опису структури та кінця заголовка. Оскільки заголовна частина, як правило, має незначний розмір порівняно з сумарним розміром записів, її можна не враховувати. Отже, для файлових даних потрібно мати ємність пам'яті : 2 + 720 + 12,2 = 734,2 Кбайт

Таку саму ємність пам'яті займають файли страхової копії. Ємність пам'яті, необхідної для ключових, індексних, інших допоміжних файлів, та пам'яті для процедур оброблення даних, становить приблизно 200 Кбайт. Текстовий файл REP_ORD з даними звіту потребує ємності пам'яті максимум 20 Кбайт. Таким чином, передбачувана максимальна ємність зовнішньої

2

Рис. 28. Результат об'єднання першого та другого локальних подань моделі даних.

пам'яті, потрібної для розроблюваної БД, становить: 2 * 734,2 + 20 + 200 = 1690 Кбайт = 1,69 Мбайт

Рис. 29. Глобальна ER-діаграма.

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

ОС;

3

драйверів зовнішніх периферійних пристроїв (CD-ROM, модем та ін.); програм антивірусного захисту; програм архівації та упаковки файлів; текстових редакторів; інших допоміжних програм обслуговування комп'ютера.

Програми організації робочого середовища під керуванням OС Windows 98/2000 потребують приблизно 170 Мбайт (мінімальний комплект) ємності пам'яті комп'ютера.

Вимоги до технічного забезпечення. Ця ІС може бути реалізована в автономному варіанті навіть на основі комп'ютера типу IBM PC/XT. Проте слід мати на увазі, що комп'ютер Pentium з тактовою частотою 300 Мгц і більше та ємністю оперативної пам'яті 64 Мбайт цілком доступний за вартістю навіть для дрібної приватної фірми. Такий комп'ютер надає користувачеві Windows 98/2000 або Windows NT 4.0 з використанням широкого спектра програмних продуктів Microsoft Office.

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

У даному разі можна зупинитися на варіанті комп'ютера Pentium II 300 Мгц з оперативною пам'яттю ємністю 64 Мбайт та зовнішньою пам'яттю ємністю близько 4 Гбайт, дисплеєм SVGA і принтером типу Laser Jet HP.

Вимоги до ПЗ. Для розв'язання розглядуваної задачі за допомогою вибраних технічних засобів доцільно мати OС Windows 98/2000 та типовий набір ПЗ фірми Microsoft.

Для програмної реалізації задачі цілком підходить СУБД Visual Fox Pro 6.0 як одна з найпопулярніших при розв'язуванні задач подібного класу завдяки високим швидкодії, рівню автоматизації програмування та спадкоємності версій. Надалі середовище СУБД не буде потрібним, оскільки задачу можна оформити як EXE-модуль.

Проектування реалізації бази даних

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

Формулювання СУБД - орієнтованої логічної структури, або даталогічної концептуальної моделі БД. На цьому етапі виконується перетворення інфологічної моделі ПС на даталогічну модель.

Наявність зв'язків між сутностями типу М:М дає змогу подати ER-діаграму у вигляді складної мережної моделі даних, показаної на рис. 30.

Для усунення зв'язку типу М:М у модель даних вводять додаткові записи. Дані перетину, що належать обом типам сутностей, будуть атрибутами додаткових записів. Завдяки цьому складна мережа зводиться до простої мережної моделі. На рис. 31 зображено даталогічну просту мережну модель даних. У цій моделі кожній сутності відповідає окремий запис. Крім того, наявні записи-зв'язки “Замовлення” та “Ціна-знижка”. В моделі відсутня залежність від шляху, кожен запис є автономним і може бути поданий як елемент реляційної даталогічної моделі даних.

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

3

детермінанту репрезентовано сукупністю атрибутів: “Назва фірми”, “Адреса фірми”. Обидві ключові детермінанти є можливими ключами, інші ключові детермінанти відсутні; тому відношення знаходиться у третій посиленій нормальній формі. Множинні зв’язки між атрибутами відсутні. Відношення є таким, що не зводиться, і вільним від аномалій включення, вилучення та коректування даних.

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

Відношення “Ціна - знижка” знаходиться в першій нормальній формі. Непервинний атрибут “Знижка” залежить від складного ключа “Код товару + Код фірми – постачальника + Кількість, що зумовлює знижку”, непервинний атрибут “Ціна” - від частини цього ключа “Код товару + Код фірми - постачальника”. У цьому випадку порушено вимогу другої нормальної форми про повну функціональну залежність непервинних атрибутів від будь-якого можливого ключа. Під час роботи з цим відношенням можуть виникати аномалії операцій включення, вилучення і редагування даних. Наприклад, поки не буде внесений розмір знижки на замовлення, не можна вносити інформацію про ціну товару. При вилученні єдиного запису з певною знижкою буде вилучена інформація про ціну товару постачальника. Такі самі проблеми виникають при редагуванні даних. Тому треба виконати проеціювання цього відношення.

Рис. 30. Даталогічна складна мережна модель даних

Перша проекція — відношення ЦІНА (Код товару, Код фірми-постачальника, Ціна) має первинний ключ “Код товару + Код фірми-постачальника” і непервинний атрибут “Ціна”, що функціонально повно і нетранзитивно залежить від ключа.

Друга проекція — відношення ЗНИЖКА (Код товару, Код фірми-постачальника, Кількість/знижка, Знижка) має первинний ключ “Код товару + Код фірми-постачальника + Кількість/знижка” і непервинний атрибут “Знижка”, що функціонально повно і нетранзитивно залежить від ключа.

Здобуті відношення “Ціна” і “ЗНИЖКА” знаходяться у другій і третій нормальних формах. Інші ключові детермінанти, крім первинних ключів, у них відсутні. Тому обидва відношення знаходяться у посиленій третій нормальній формі. У цих відношеннях відсутні множинні зв’язки між групами даних. Відношення “ЦІНА” та “ЗНИЖКА” є такими, що не зводяться, і позбавлені аномалій включення, вилучення, редагування.

Операція природного з’єднання цих відношень дає змогу відновити початкове

3

відношення “Ціна-знижка”, оскільки вони мають спільні атрибути “Код товару”, “Код фірми-постачальника”, які у відношенні “ЦІНА” складають первинний ключ.

Рис. 31. Даталогічна проста мережна модель даних

Відношення ЗАМОВЛЕННЯ (№ замовлення, Код товару, Код фірми-постачальника, Дата замовлення, Кількість у замовленні) знаходиться в першій, другій та третій нормальних формах. Непервинний атрибут “Кількість у замовленні” залежить від двох можливих ключів: “Дата замовлення + Код фірми-постачальника + Код товару” та “Дата замовлення + № замовлення + Код товару, які перетинаються по атрибутах “Дата замовлення + Код товару”. Транзитивних залежностей немає. Проте існує залежність атрибута “№ замовлення” від ключової детермінанти “Код фірми-постачальника + Дата замовлення”. Отже, у відношенні “Замовлення” кількість ключових детермінантів перевищує кількість можливих ключів, тому воно не знаходиться у третій посиленій нормальній формі і потребує декомпозиції на такі проекції:

КІЛЬКІСТЬ ЗАМОВЛЕННЯ (Дата замовлення, Код фірми-постачальника, Код товару, Кількість у замовленні);

ЗАМОВЛЕННЯ (Дата замовлення, Код фірми-постачальника, № замовлення).Атрибут “№ замовлення” є сурогатним ключем — порядковим номером фірм-

постачальників у кошику замовлень.Ключем у відношенні “Кількість замовлення” є “Дата замовлення + Код фірми-

постачальника + Код товару”, а ключем у відношенні “Замовлення” - “Дата замовлення + Код фірми-постачальника”.

Неключові атрибути цих відношень функціонально повно і нетранзитивно залежать від можливих ключів. Тому відношення перебувають у третій нормальній формі. Інші ключові детермінанти в них відсутні. Отже, вони перебувають у третій посиленій нормальній формі. Множинні зв’язки в них відсутні. Відношення не потребують зведення і позбавлені аномалій включення, вилучення та редагування даних. Операція природного з’єднання цих проекцій дає змогу відновити початкове відношенні “Замовлення”.

Даталогічна реляційна модель, або схема БД, складається з набору відношень, що не зводяться:

ПОСТАЧАЛЬНИК (Код фірми-постачальника, Назва фірми, Адреса, Ім’я менеджера, Телефон, Рейтинг);

3

ТОВАР (Код товару, Назва товару, Параметр 1, Параметр 2, Параметр 3, Параметр 4);ЦІНА (Код товару, Код фірми-постачальника, Ціна);ЗНИЖКА (Код товару, Код фірми-постачальника, Кількість / знижка , Знижка);КІЛЬКІСТЬ ЗАМОВЛЕННЯ (Код товару, Код фірми-постачальника, Дата замовлення,

Кількість замовлення);ЗАМОВЛЕННЯ (Код фірми-постачальника, Дата замовлення, № замовлення);ФАЙЛ (Ім’я файлу, Кількість записів, Розмір, Дата створення, Ім’я розробника);ПОЛЕ (Ім’я поля, Тип, Довжина, Точність);ЗВ’ЯЗОК (Ім’я файлу, Ім’я поля).У прийнятих у словнику даних позначеннях зазначені відношення мають такий вигляд:ПОСТАЧАЛЬНИК (COD_SUP, NAM_SUP, ADR_SUP, MANAGER, TEL_SUP,

REP_SUP);ТОВАР (COD _ G , NAME_G, PAR1_G, PAR2_G, PAR3_G, PAR4_G) і так далі для усіх

відношень.

3

3. Варіанти завдань

Визначення номера варіанту завдання: три останні цифри шифру студента поділити на 20 і додати до залишку від ділення 1.

Варіант 1. Специфіка діяльності фірми «Альфа» така, що вона має дуже обмежене коло господарських операцій. Відповідно на фірмі застосовується спрощена схема бухгалтерського обліку:– ведеться хронологічний запис операцій в регістрі, що має назву «Журнал реєстрації господарських операцій». Для кожного номера операції зазначаються номер документа, зміст операції та сума, а також проведення за відповідними рахунками;– план рахунків фірми містить такі рахунки:склад засобів: 05-виробничі запаси; 20-основне виробництво; 41-товари; 50-каса; 51-розрахунковий рахунок; 76-розрахунки з дебіторами;джерела формування засобів: 85-статутний фонд; 60-розрахунки з кредиторами; 68-розрахунки з бюджетом;– один раз на місяць бухгалтерія складає баланс.Потрібно виконати постановку задачі, яка б дала змогу автоматизувати ведення Бухгалтерського обліку на фірмі «Альфа».

Варіант 2. Підприємство «Бета» має три склади, на які надходять матеріали від 200 постачальників. Надходження оформляється приймальними актами, в яких зазначаються кількість, ціна і вартість матеріалу, що надійшов. Щоденно зі складів відпускаються матеріали в цехи основного виробництва. Відпуск оформляється накладною, в якій зазначаються цех-покупець, кількість та сума відпущених матеріалів. Бухгалтерія веде облік руху матеріалів на складах, одержуючи два види документів:

– відомість руху матеріалів за місяць (залишок- надходження- витрати- залишок);

– реєстр документів за добу.

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

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

Варіант 4. Підприємство «Дельта» постачає випущену продукцію покупцям за договорами. Усього договорів за рік може бути близько 1000. Номенклатура виробів становить 100 найменувань. У договорі зазначається дата поставки. Фактична поставка може мати дату, що відрізняється від договірної. Відділ маркетингу повинен контролювати виконання поставок за договорами. Потрібно виконати постановку задачі, яка б дала змогу автоматизувати процес одержання відомостей про відхилення у постачанні.

Варіант 5. З метою розробки автоматизованої підсистеми обліку використання обладнання на підприємстві на сервері БД потрібно зберігати дані про цехи, обладнання цехів, продукцію, що виготовляється на підприємстві, дані про використання обладнання. Обладнання закріплено за цехами, кожний вид обладнання використовується при виробництві багатьох видів продукції і

3

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

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

Варіант 7. З метою розробки автоматизованої підсистеми обліку виконання робіт робітниками підприємства на сервері БД потрібно зберігати дані про робітників, види робіт, міри складності кожного виду роботи, виконання робіт. При цьому кожному виду роботи відповідає кілька мір складності, а кожна міра складності – певному виду роботи. Тарифна ставка залежить від міри складності роботи. Кожний робітник виконує різні види робіт різної складності, а кожний вид роботи різної міри складності виконується різними робітниками. Облік робітників і видів робіт виконується в межах підсистеми, яка розробляється, облік мір складності роботи виконується в межах кожного виду роботи.

Варіант 8. З метою розробки автоматизованої підсистеми обліку обслуговування клієнтів банку на сервері БД потрібно зберігати дані про міста України, філіали банку, що знаходяться в різних містах, клієнтів банку, обслуговуванні їх у філіалах банку. При цьому в кожному місті може бути кілька філіалів і клієнт може обслуговуватися в будь-якому філіалі банку. Кожний клієнт має один розрахунковий рахунок у своєму банку. Облік міст, філіалів банку та клієнтів виконується в межах підсистеми, яка розробляється.

Варіант 9. З метою розробки автоматизованої підсистеми маркетингових досліджень на сервері БД підприємства-виробника багатьох видів продукції потрібно зберігати дані про підприємства-конкуренти, що випускають аналогічну продукцію, про саму продукцію, про підприємства-споживачі цієї продукції, а також про її реалізацію на ринку. При цьому кожне підприємство-виробник випускає і реалізує безліч видів продукції багатьом підприємствам-споживачам. Кожен вид продукції випускається багатьма підприємствами-виробниками та реалізується багатьом споживачам. Кожен споживач купує безліч видів продукції різних виробників. Ціна однієї і тієї самої продукції у різних виробників може бути різною. Облік підприємств-виробників продукції, підприємств-споживачів виконується в межах підсистеми, що розробляється.

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

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

3

таким чином, щоб була можливість розраховувати відомості про замовленні книжки з вказівкою причини їх відсутності в бібліотеці, та про читачів – боржників ( вважати заборгованістю 15 діб з дня видачі книжки).

Варіант 12. Організуйте базу даних ІС обліку лізингових контрактів, коли підприємства – рентери укладають угоду на довгострокову оренду устаткування, що належать підприємству – ліссору.

Варіант 13. Організуйте БД ІС проектного бюро. В межах даної ІС треба зберігати дані про службовців, проекти, які вони розробляють та замовників проектів. Кожний службовець може брати участь в розробці декількох проектів і тим паче один конкретний проект розробляє декілька службовців. Замовники також можуть замовити більше ніж один проект.

Варіант 14. Організуйте БД ІС, яка веде облік стану рахунків клієнтів після введення платіжних документів, вкладів та зняття коштів з рахунків . В межах ІС проводиться щоденне складання сальдового балансу банку.

Варіант 15. Організуйте БД ІС страхового агентства. Страхові агенти укладають з клієнтами договори на страхування майна, особисте страхування, страхування відповідальності. Кожний агент працює не з одним клієнтом і кожен клієнт може укласти угоди різних видів. В рамках ІС повинен вестись облік договорів на страхування та облік страхових випадків.

Варіант 16. З метою розробки автоматизованої підсистеми обліку обслуговування клієнтів магазину з продажу комп’ютерної техніки на сервері БД потрібно зберігати дані про замовлені та продані товари, а також надані послуги з доставки техніки і її гарантійного ремонту. Кожний покупець може замовити та купити декілька видів техніки. Врахувати той випадок, коли покупець може повернути товар з причин його несправності.

Варіант 17. Управління мебельної фабрики має намір автоматизувати процес отримання матеріалів від постачальників, їх рух в цехи та отримання матеріалів з цехів у разі виявлення залишків. Матеріал фабрика отримує від декількох постачальників.

Варіант 18. Косметологічно-оздоровчий центр має намір автоматизувати облік клієнтів. Кожний клієнт може відвідувати декілька секцій та отримувати декілька послуг. Деякі працівники центру можуть надавати декілька послуг. Постійним клієнтам надається знижка.

Варіант 19. Торговельно-посередницька фірма має намір автоматизувати процес відправки товарів з одної країни в іншу. В межах підсистеми повинна накопичуватися інформація про відправників, товарах, декларантах, одержувачах. Однаковий товар може надходити від різних фірм-відправників однієї країни і транспортуватися різним фірмам-замовникам іншої країни. Фірма-відправник постачає декілька видів товарів. Фірма-замовник одержує декілька видів товарів.

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

3

Перелік рекомендованої літератури

1. Інформаційні системи і технології. Посібник за редакцією доктора економічних наук, професора В.С. Пономаренко. Київ, видавництво центр «Академія», 2002.-542с.

2. Проектування економічних систем. Посібник за редакцією доктора економічних наук, професора В.С. Пономаренко. Київ, видавництво центр «Академія», 2002.-454с.

3. Гордієнко І.В. Інформаційні системи і технології в менеджменті: навч.-метод.посібн. для сам ост. вивч. дисц. / І.В. Гордієнко. 2-ге вид. перероб. і доп. – К.: КНЕУ, 2003. – 259 с.

4. Гужва В.М. Інформаційні системи і технології на підприємствах: навч. посіб. / В.М. Гужва. – К: КНЕУ, 2001. – 400 с.

3