Н

3.4.3. Концептуальне проектування бази даних та оптимізація її структури

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

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

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

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

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

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

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

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

3.4.4. Оптимізація структури бази даних

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

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

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

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

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

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

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

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

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

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

Рис. 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.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)