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

4.1. Цілі проектування рбд

Ціль 1. Забезпечити можливість збереження всіх необхідних даних у РБД. Необхідно визначити всі атрибути, що потрібно помістити в РБД. За умови, що всього таких атрибутів нараховується не більше 20, на початку проектування РБД всі вони залучаються в одне відношення.

Ціль 2. Вилучити явної надлишковості даних. Для того щоб позбавитись явної надлишковості даних потрібно розрізняти поняття дублювання та надлишкового дублювання даних (чи, інакше кажучи, неявної та явної надлишковості даних). Розглянемо 2 відношення

Таблиця 6 – Відношення ОДЕРЖУВАЧ 1:

Код одержувача	Станція
1423	Запоріжжя 1
1248	НДВузол
1537	Запоріжжя 1

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

Таблиця 7 – Відношення ОДЕРЖУВАЧ 2:

Код одержувача	Станція	Код станції
1423	Запоріжжя 1	46070
1248	НДВузол	45000
1537	Запоріжжя 1	46070

Тут є надлишкове дублювання даних: втрачений код станції примикання одержувача 1423 можна дізнатися по назві станції примикання іншого одержувача 1537. Це приклад явної надлишковості даних.

Надлишкове дублювання даних потрібно прагнути виключити з відношення в процесі проектування РБД.

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

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

В процесі проектування РБД необхідно розв’язати компроміс між 3-ю і 4-ю цілями.

4.2. Універсальне відношення

Відповідно до першої цілі процес проектування РБД розпочинається зі складання відношення, в яке залучаються всі потрібні для зберігання у РБД атрибути.

Якщо в РБД лише одне відношення, то це відношення називають універсальним.

Розглянемо етап складання універсального відношення на прикладі.

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

1. Код_одержувача – ціле число, унікальне для кожного одержувача.

2. Назва_одержувача – символьний атрибут, кожний одержувач має одну назву, але одна назва може бути у декількох одержувачів (за кодом одержувача можна знайти його назву, зворотна операція неможлива).

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

4. Код_вантажу – ціле число, кожний вантаж має унікальний код, кожний одержувач може одержувати декілька різних вантажів.

5. Найм_вантажу – символьний атрибут, кожний код вантажу має єдине відповідне найменування вантажу, кожному найменуванню відповідає єдиний код вантажу.

6. Маса_вантажу – ціле число, кожний одержувач одержує вантаж одного найменування і визначеної маси (значення маси можуть повторюватися).

Запишемо в таблицю зразок даних про навантаження за минулу добу:

Таблиця 8

Код одержувача	Назва одержувача	Код станції	Код вантажу	Найм. вантажу	Маса вантажу
1010	Мех. з-д	45000	11232 11569 12454	Метізи Рейки Дріт	152 49 68
1234	Ф-ка	46070	11232 12454	Метізи Дріт	142 36
1425	Мех. з-д	46710	11569 12454	Рейки Дріт	152 371
1537	ЗБК	46070	13127	Прокат	632
1572	Будтрест	45000	-	-	-