Приклад 6.1. Функціональні залежності

Розглянемо атрибути Staff_Nо і Position відносини Staff, представленого в табл. 6.1. Знаючи значення атрибута Staff_No (наприклад, 'SL21'), можна визначити посада, займану цим співробітником ('Manager'). Інакше кажучи, атрибут Position функціонально залежить від атрибута Staff_No, як показано на рис, 6.2а. Однак, з мал. 6.2б видно, що зворотне твердження невірне, оскільки атрибут Staff_No функціонально не залежить від атрибута Position. Іншими словами, кожен співробітник може займати тільки, одну посаду, однак може бути не скільки співробітників з однаковими посадами.

З в'язок між атрибутами Staff_No і Position відноситься до типу 1:1, оскільки для кожного номера співробітника мається тільки одна посада. А зв'язок між атрибутами Position і Staff_Nо має тип 1:М, тому що існує відразу кілька номерів співробітників які займають ту саму посаду. У даному прикладі атрибут Staff_No є детермінантом функціональної залежності Staff_No-->Position.

Приклад 6.2. Функціональні залежності відносини Staff_Branch

Розглянемо функціональні залежності відносини Staff_Branch, представленого в табл. 6.3.

Staff_No --> SName

Staff_No --> SAddress

Staff_No--> Position

Staff_No --> Salary

Staff_No --> Branch_No

Staff_No --> BAddress

Staff_No --> Tel_No

Branch_No -->BAddress

Branch_No-->Tel_No

BAddress-->Branch_No

BAddress-->Tel_No

Tel_No-->BranchNo

Tel_No-->BAddress

У відношенні Staff_Branch існує 13 функціональних залежностей, у яких атрибути Staff_No, Branch_No, BAddress і Tel_No відіграють роль детермінантів. (У даному випадку передбачається, що кожне відділення компанії володіє тільки одним телефоном). Нижче показаний альтернативний формат представлення цих же функціональних залежностей.

Staff_No -> SName, SAddress, Position,.Salary, Branch_No, BAddress, Tel_No

Branch_No -> BAddress, Tel_No

Baddress -> Branch_No, Tel_No

Tel_No -> Branch_No, BAddress

Для виявлення потенційних ключів відносини Staff_Branch необхідно знайти атрибут (чи групу атрибутів), що унікальним образом ідентифікує кожен рядок цього відношення. Якщо відношення володіє декількома потенційними ключами, то потрібно вибрати серед них; той, котрий стане первинним ключем відносини (див. роздягнув 3.2.5). Всі атрибути, що не є частиною первинного ключа, повинні функціонально залежати від нього. Єдиним потенційним ключем відносини Staff_Branch, а виходить, і його первинним ключем, є атрибут Staff_Nо, тому що всі інші атрибути цього відношення функціонально залежать від Staff_No. Хоча атрибути Branch_No, BAddress і Tel_No є детермінантами цього відношення, вони не є його потенційними ключами. Концепція функціональної залежності є центральним поняттям процесу нормалізації, що розглядається в наступних розділах.

6.4. Процес нормалізації

Нормалізація - це формальний метод аналізу відносин на основі їхнього первинного ключа (чи потенційних ключів, як у випадку НФБК) і існуючих функціональних залежностей. Він включає ряд правил, що можуть використовуватися для перевірки окремих відносин таким чином, щоб уся база даних могла бути нормалізована до бажаного ступеня нормалізації. Якщо деяка вимога не задовольняється, то відношення, що порушує дану вимогу, повинне бути декомпозовано на відносини, кожне з який (окремо) задовольняє усім вимогам нормалізації.

Найчастіше нормалізація здійснюється в трохи що послідовно виконуються етапів, кожний з який відповідає деякій нормальній формі, що володіє відомими властивостями. У ході нормалізації формат відносин стає усе більш строгим і менш уразливим стосовно аномалій відновлення. При роботі з реляційною моделлю даних важливо розуміти, що тільки задоволення вимог першої нормальної форми (1НФ) обов'язково для створення відносин прийнятної якості. Всі інші форми можуть використовуватися за бажанням проектувальників. Однак, для того щоб уникнути аномалій відновлення, описаних у розділі 6.2, нормалізацію рекомендується виконувати як мінімум до ЗНФ.

Н а мал. 6.3 показана схема процесу нормалізації і продемонстрований взаємозв'язок між різними нормальними формами. Видно, що одні 1НФ - відношення можуть знаходитися в 2НФ, інші 2НФ – відношення - в ЗНФ і т.д.

У наступних розділах процес нормалізації показаний на прикладі перетворення даних, що у вихідному стані мали вид форми табличного формату з рядками і стовпцями. Важливо відзначити, що в главі 7 "Методологія концептуального проектування баз даних", представлена методика концептуального проектування бази даних, відповідно до якої рекомендується, у першу чергу розібратися зі зв'язками між даними подібної форми за допомогою технології ER-моделювання, описаної в главі 5, "Модель "сутність-зв'язок"". Однак у цій главі технологія ER-моделювання не використовується, а досягнення розуміння змісту даних в обговорюваній формі відбувається безпосередньо в процесі нормалізації.