Лекція 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. Нормалізувати відношення – розбити одне відношення на декілька, із метою ліквідації проблем, що можуть трапитися при вставці, вилученні і модифікації даних. Нормалізація відношення виконується у тому числі і для ліквідації явної надлишковості даних.

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

В процесі проектування РБД необхідно розв'язати компроміс між 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	-	-	-