3.5 Нормалізація відношень методом декомпозиції
Для отримання відношення в НФБК проведемо послідовність операцій декомпозиції на основі правил декомпозиції [12].
Розглянемо попереднє універсальне відношення R: (<ID_Готелю, ID_Відвідувача, ID_Працівника, ID_Оплати, ID_Скарги>, Назва_готелю, Кількість_зірок, Кількість_вільних_місць, Адреса_готелю, ПІБ_відвідувача, Телефон_відвідувача, Пошта_відвідувача, Місто_проживання, ПІБ_працівника, Робочий_час, Телефон_працівника, Вид_оплати, Сума_оплати, Відсоток_знижки, Зміст_скарги).
Відношення R1 та R2:
R1 (<ID_Оплати>, Вид_оплати, Сума_оплати, Відсоток_знижка);
R2 (<ID_Готелю, ID_Відвідувача, ID_Працівника, ID_Скарги>, ID_Оплати, Назва_готелю, Кількість_зірок, Кількість_вільних_місць, Адреса_готелю, ПІБ_відвідувача, Телефон_відвідувача, Пошта_відвідувача, Місто_проживання, ПІБ_працівника, Робочий_час, Телефон_працівника, Зміст_скарги).
Відношення R3 та R4:
R3 (<ID_Відвідувача>, ПІБ_відвідувача, Телефон_відвідувача, Пошта_відвідувача, Місто_проживання, ID_Оплати);
R4 (<ID_Готелю, ID_Працівника, ID_Скарги>, ID_Відвідувача, Назва_готелю, Кількість_зірок, Кількість_вільних_місць, Адреса_готелю, ПІБ_працівника, Робочий_час, Телефон_працівника, Зміст_скарги).
Відношення R5 та R6:
R5 (<ID_Працівника>, ПІБ_працівника, Робочий_час, Телефон_працівника);
R6 (<ID_Готелю, ID_Скарги>, ID_Відвідувача, ID_Працівника, Назва_готелю, Кількість_зірок, Кількість_вільних_місць, Адреса_готелю, Зміст_скарги).
Відношення R7 та R8:
R7 (<ID_Готелю>, Назва_готелю, Кількість_зірок, Кількість_вільних_місць, Адреса_готелю);
R8 (<ID_Скарги>, ID_Відвідувача, ID_Працівника, ID_Готелю, Зміст_скарги).
Відношення R9 та R10:
R9 (<ID_Скарги>, Зміст_скарги, ID_Відвідувача);
R10 (<ID_Готелю, ID_Відвідувача>);
R11 (<ID_Працівника, ID_Готелю>).
Відношення R1, R3, R5, R7, R9, R10, R11 знаходяться в НФБК, що свідчить про закінчення процедури декомпозиції. Кінцеві відношення знайдені за допомогою методу декомпозиції, мають наступний вигляд:
R1 (<ID_Оплати>, Вид_оплати, Сума_оплати, Відсоток_знижки);
R3 (<ID_Відвідувача>, ПІБ_відвідувача, Телефон_відвідувача, Пошта_відвідувача, Місто_проживання, ID_Оплати);
R5 (<ID_Працівника>, ПІБ_працівника, Робочий_час, Телефон_працівника);
R7 (<ID_Готелю>, Назва_готелю, Кількість_зірок, Кількість_вільних_місць, Адреса_готелю);
R9 (<ID_Скарги>, Зміст_скарги, ID_Відвідувача);
R10 (<ID_Готелю, ID_Відвідувача>);
R11 (<ID_Працівника, ID_Готелю>).
Розглянемо функціональні залежності, які присутні між атрибутами універсального відношення, що описує предметну область «Готель» (Рисунок 3.6).
Рисунок 3.6 – Діаграма функціональної залежності
3.6 Оцінка спроектованих нфбк відношень
Для перевірки НФБК-відношень на предмет наявності невиявлених проблем використовуються наступні кроки:
1. Складаються списки функціональних залежностей дня кожного відношення і перевіряються таким чином щоб одна і таж функціональна залежність не з'являлася більше, ніж в одному відношенні, а також потрібно довести можливість отримання підсумкового набору функціональних залежностей з мінімального покриття за допомогою правил виведення. Якщо хоча б одна з перевірок виявиться недостовірною, прийдеться аналізувати процес проектування для виявлення помилок або розглянути інші варіанти проектування.
2. Здійснюється перевірка на присутність надлишкових відношень. Відношення являється надлишковим якщо:
всі його атрибути можуть бути знайдені в одному або другому відношенні набору, що проєктується;
всі його атрибути можуть бути знайдені в відношенні, котре може бути отримане з інших відношень запропонованого проектного набору за допомогою серії JOIN – операцій над цими відношеннями.
3. Розгляд відношень з практичної точки зору. Вивчається характер використання відношень в базі даних, що проектується і визначається чи будуть вони підтримувати ті типи операцій відновлення та запити, котрі передбачається використовувати. Розглянувши кінцеві відношення даної бази даних, можна встановити, що одна і таж функціональна залежність не з’являється більш чим в одному відношенні. Набір функціональних залежностей є мінімальним. Аналіз відношень показує, що не можна вказати серед них жодного, всі атрибути якого були би підмножиною атрибутів іншого відношення. Крім того, неможливо об’єднати будь-які два відношення так, щоб у результаті були отримані всі атрибути третього відношення. В кінцевому результаті, після застосування методу декомпозиції, отримані наступні кінцеві відношення:
Оплата: (<ID_Оплати>, Вид_оплати, Сума_оплати, Відсоток_знижки);
Відвідувач: (<ID_Відвідувача>, ПІБ_відвідувача, Телефон_відвідувача, Пошта_відвідувача, Місто_проживання, ID_Оплати);
Працівник: (<ID_Працівника>, ПІБ_працівника, Робочий_час, Телефон_працівника);
Готель: (<ID_Готелю>, Назва_готелю, Кількість_зірок, Кількість_вільних_місць, Адреса_готелю);
Скарга: (<ID_Скарги>, Зміст_скарги, ID_Відвідувача);
Відвідувач-Готель: (<ID_Готелю, ID_Відвідувача>);
Працівник-Готель: (<ID_Працівника, ID_Готелю>).
Усі таблиці, що розроблені на основі цих відношень, подано у додатку А. Зв’язки між наведеними таблицями представлені на схемі даних у додатку Д.