Лекція 5

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

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

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

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

Таблиця 6

Відношення ОДЕРЖУВАЧ 1:

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

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

Таблиця 7

Відношення ОДЕРЖУВАЧ 2:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблиця 8

Код_одержувача	Назва_одержувача	Код_ЄСР	Код_вантажу	Найм_вантажу	Маса_вантажу
1010	Мех. з-д	4500	11232 11569 12454 13127	Метізи Рейки Дріт Прокат	152 49 68 312
1234	Ф-ка	4607	11232 12454 13127	Метізи Дріт Прокат	142 36 98
1425	Мех. з-д	4671	11569 12454 13127	Рейки Дріт Прокат	152 371 1125
1537	ЗБК	4607	12454	Дріт	632
1572	Будтрест	4500	11232 11569	Метізи Рейки	254 136