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

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

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

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

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

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

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

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

Надходження		Витрати
Залишок		Склад

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

Концептуальне проектування бази даних

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

НАДХОДЖЕННЯ			ВИТРАТИ
Номер приймального акта			Номер накладної на відпуск
Дата створення документа			Дата виписки накладної
Назва матеріалу			Назва матеріалу
Номенклатурний номер			Номенклатурний номер
матеріалу			матеріалу
Номер рахунку			Номер рахунку
Номер			Номер
складу			складу
Одиниця виміру			Отримувач (підрозділ організації)
Кількість			Одиниця виміру
Ціна			Належить відпустити
Сума			Кількість відпущеного
			Ціна
			Сума
			Номер запису в картотеці складу
СКЛАД			ЗАЛИШОК
Номер			Номер
складу			складу
Адреса складу			Дата
Прізвище відповідальної особи			Назва матеріалу
			Номенклатурний номер
			матеріалу
			Одиниця виміру
			Кількість
			Ціна
			Сума
			Підрозділ організації
			Номер рахунку

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

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

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

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

Таблиця 3.4.

Структура сутності „НАДХОДЖЕННЯ”

№ п/п	Назва реквізиту	Іденти­фікатор	Тип рек­візиту	Особли­вості	Формат реквізиту	Джерело	При-мітка
1.	Номенклатурний номер	номенкл.	число	ціле	9(5)		Унік.
2.	Номер складу	склад	число	ціле	9(3)
3.	Назва товару	товар	текст	літери	А(20)
4.	Одиниця виміру	одиниця	текст	змішані символи	Х(8)
5.	Кількість	кількість	число	дійсне	9(5)
6.	Ціна	ціна	число	дійсне	9(5)
7.	Сума	сума	число	дійсне	9(5).9(2)	кількість * ціна	Розрах.
8.	Прийняв (прізвище, ініціали)	прийняв	текст	літери	А(20)
9.	Дата прийому	дата	текст	змішані символи	Х(10)

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

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

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

Опис полів модельного проекту БД здійснюється у відповідності з характеристиками реквізитів, які подані в таблицях 3.4 і 3.5.

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

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

«НАДХОДЖЕННЯ»; «ВИТРАТИ»; «ЗАЛИШОК»; «СКЛАД».

Таблиця 3.5.

Структура сутності „ВИТРАТИ”

№ п/п	Назва реквізиту	Ідентифі- катор	Тип рек­візиту	Особли­вості	Формат реквізиту	Джерело	При­мітка
1.	Номенклатурний номер	номенкл.	число	ціле	9(5)		Унік.
2.	Номер складу	склад	число	ціле	9(3)
3.	Назва товару	товар	текст	літери	А(20)
4.	Одиниця виміру	одиниця	текст	змішані символи	Х(8)
5.	Належить відпустити	належить	число	дійсне	9(5)
6.	Відпущено	відпущ.	число	дійсне	9(5)
7.	Ціна	ціна	число	дійсне	9(5)
8.	Сума	сума	число	дійсне	9(5).9(2)	відпущено * ціна	Розрах.
9.	Відпустив (прізвище, ініціали)	відпустив	текст	літери	А(20)
10.	Отримав (прізвище, ініціали)	отримав	текст	літери	А(20)
11.	Дата видачі	дата	текст	змішані символи	Х(10)

На даний час існують технології автоматизованого проектування програмного забезпечення, так звані CASE-технології (Computer Assisted Software Enginieering), прикладами яких можуть бути продукти Designer/2000 (Oracle), EasyCASE (Evergreen) та багато інших. CASE-технології дозволяють будувати не тільки ER-діаграми, але й специфічні ключі, індекси, обмеження, SQL-коди для створення об’єктів БД, що дозволяє їх застосовувати для проектування багатовимірних БД.

Питання для самоперевірки

1. Які особливості має позадачний підхід щодо формування даних в файлових системах?

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

3. Що входить до функціональних обов’язків користувачів інформаційної системи?

4. Охарактеризуйте структурні компоненти зовнішнього рівня подання даних АІС.

5. Охарактеризуйте структурні компоненти інфологічного рівня подання даних АІС.

6. Охарактеризуйте структурні компоненти концептуального рівня подання даних АІС.

7. Охарактеризуйте структурні компоненти внутрішнього рівня подання даних АІС.

8. Які особливості має проектування БД на зовнішньому рівні АІС?

9. Які особливості має проектування БД на інфологічному рівні АІС?

10. Які особливості має проектування БД на концептуальному рівні АІС?

11. Які особливості має реалізація БД на внутрішньому рівні АІС?

12. Які вимоги ставляться до СКБД при створенні АІС?

13. Як здійснюється оптимізація логічної структури БД?