Основними складовими елементами інфологічної моделі є такі: інформаційна сутність, реквізит, зв'язок.

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

Кожна інформаційна сутність описується певним набором реквізитів.

Якщо зовнішнє подання можна формувати у вигляді взаємопов'язаних документів, то інфологічне подання даних більш зручно описувати у вигляді діаграм "сутність" - "зв'язок", або E/R діаграм.

Інформаційні сутності зображаються прямокутниками і зв'язуються між собою лініями, при цьому зв'язки несуть певне суттєве навантаження. Наприклад, матеріали ЗБЕРІГАЮТЬСЯ на складі.

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

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

В цьому випадку інфологічна модель (спрощена схема) матиме вигляд, як на рис.3.1.

Рис.3.1. Інфологічна модель автоматизованого обліку матеріальних цінностей

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

Перш ніж виконати концептуальне проектування, необхідно вибрати СУБД. Кожна конкретна СУБД накладає ряд обмежень на побудову логічної моделі даних, тому на­самперед необхідно вивчити специфіку і особливості СУБД, виявити всі фактори, які можуть вплинути на логічну модель БД.

Основними факторами, що впливають на концептуальне проектування з боку СУБД, є такі:

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

2.Особливості фізичної організації даних у середовищі вибраної СУБД. Наприклад, структура БД в середовищах СУБД Paradox, DataEase чи dBASE-системах являє собою сукупність взаємозв'язаних файлів у форматах, відповідно, *.dt, *.dbm чи *.dbf. При цьому усі інші структурні елементи, такі як форми та звіти, також зберігаються в окремих фай­лах.

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

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

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

В результаті концептуального проектування можна отримати кілька варіантів побудови концептуальної моделі даних. Тому важливим моментом є оцінка отриманих моделей і вибір найбільш оптимального варіанта.

Отримані реляційні відношення БД мають відповідати формам нормалізації. Е.Ф.Кодд виділив три нормальні форми (скорочена назва - 1НФ, 2НФ і 3НФ). Існує ще підсилена 3НФ – нормальна форма Бойса-Кодда (БКНФ). Зараз вже відомі і визначені 4НФ і 5НФ.

У результаті нормалізації необхідно досягти виконання таких умов:

· усі атрибути відношень мають бути атомарними, тобто неподільними;

· усі атрибути у відношенні повинні мати унікальні імена;

· групування атрибутів має забезпечувати мінімальне дублювання даних;

· повинні бути забезпечені процедури обробки і поновлення атрибутів без ускладнень і аномалій;

· між атрибутами не повинно бути небажаних функціональних залежностей.

Концептуальна модель проекту БД для автоматизованого обліку матеріальних цінностей матиме наступний вигляд (рис. 3.2).

Рис. 3.2. Концептуальна модель автоматизованого обліку матеріальних цінностей.

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

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

Отриману логічну модель БД потрібно оцінити з точки зору відповідності наявним машинним ресурсам. У разі невідповідності цим обмеженням потрібно здійснити перепроектування БД.

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

У моделі, що наведена на рис. 3.2, між структурованими таблицями: "НАДХОДЖЕННЯ", "ВИТРАТИ" і "ЗАЛИШОК" зв'язок організується за однаковим значенням атрибуту "номенклатурний номер матеріалу".

Атрибутом зв'язку для таблиць: "НАДХОДЖЕННЯ", "ВИТРАТИ" "ЗАЛИШОК" і "СКЛАД" може бути "Номер складу".

З урахуванням характеристик реквізитів (табл.3.3) формується структура таблиць “НАДХОДЖЕННЯ” (табл. 3.4) та “ВИТРАТИ” (табл. 3.5) у відповідності до концептуальної моделі автоматизованого обліку матеріальних цінностей.

Таблиця 3.4.

Структурована таблиця „НАДХОДЖЕННЯ”

Таблиця 3.5.

Структурована таблиця „ВИТРАТИ”

• ⇐ Назад
• 8
• 9
• 10
• 11
• 12
• 13
• 141516
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• Далее ⇒