Друга нормальна форма (2нф)

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

Функціональні залежності (від fdl до fd6) відносини Property_Inspection з первинним ключем (Property_No, IDate) показані на мал. 6.8. Ці залежності можна представити в іншому виді:

Після виявлення функціональних залежностей процес нормалізації може бути продовжений. Спочатку варто знайти наявні часткові залежності від первинного ключа і тим самим перевірити, чи не знаходиться ці відношення в другій нормальній формі (2НФ). Відразу ж можна помітити, що атрибут об'єкта нерухомості PAddress частково залежить від частини первинного ключа, а саме від атрибута Property_No (ця залежність позначена як fd2). Тоді як атрибути ITime, Comments, Staff_No, SName, Car_Reg цілком функціонально залежать від усього первинного ключа в цілому (атрибути Property_Nо і IDate) (ця залежність позначена як fdl). Звернете .увага на те, що, хоча для, детермінанта функціональної залежності Staff_No, IDate -> Car_Reg (ця залежність позначена як fd4) досить використовувати тільки атрибут IDate первинного ключа, на даному етапі нормалізації ця залежність ще не усувається, оскільки зазначений детермінант, також включає інший атрибут, що не входить до складу первинного ключа, мається на увазі атрибут Staff _No. Інакше кажучи, ця залежність не повністю залежить від частини первинного ключа, а тому не порушує вимог 2НФ.

Наявність часткової залежності (Pr6perty_Mo -> PAddress) указує на те, що відношення Property_Inspection не знаходиться в другій нормальній формі. Для перетворення цього відношення в другу нормальну форму буде потрібно створити нові відносини так, щоб атрибути,, що не цілком функціонально залежать від первинного ключа, були зв'язані тільки з відповідної, частиною ключа.

Відношення Property_Inspectton може бути перетворене в другу нормальну форму шляхом видалення часткової залежності з цього відношення за допомогою створення двох нових відносин Prop і Prop_Inspection. Обоє цих відносини знаходяться в другій нормальній формі, тому що атрибути, що не входять у первинний ключ, функціонально залежать від первинного ключа цих відносин. Уміст цих відносин представлене в табл. 6.22 і 6.23 відповідно, а опис має наступний вид:

P rop (Property_No, Address) Prop_Inspection (Property_No, IDate, ITirne, Comments, Staff_No, CName, Car_Reg)

Третя нормальна форма (знф)

Нормалізація 2НФ - відношень з одержанням ЗНФ - відносин включає усунення транзитивних залежностей. При наявності транзитивних залежностей варто видалити транзитивно залежні атрибути з цього відношення і помістити їх у нове відношення разом з копією їхнього детермінанта. У відносинах Prop і Prop_Inspection варто виявити і проаналізувати наявні функціональні залежності. Результати цієї роботи показані нижче.

Відношення Prop

fd2 Property_No -> PAddress Відношення Prop_Inspection

fdl Property_No, IDate -> ITime, Comments, Staff_No, SName, Car_Reg fd3 Staff_No -> CName fd4 Staff_No, IDate -> Car_Reg

fd5* Car_Reg, IDate, ITime -> Property_No, Comments, Staff _No, SName

fd6* StaffJto, IDate, ITime -> Property_No, Comments

Оскільки відношення Prop не містить транзитивних залежностей від первинного ключа, воно вже знаходиться в третій нормальній формі (ЗНФ). Однак, хоча всі не вхідні в первинний ключ атрибути відносини Prop_Inspection функціонально залежать від первинного ключа, атрибут SName також залежить від атрибута Staff_No (ця залежність позначена як fd3). Це приклад транзитивної залежності, що виникає у випадку, якщо не вхідний у первинний ключ атрибут залежить, від іншого атрибута, що теж не входить у первинний ключ. Слід також зазначити, що у випадку функціональної залежності Staff_No, IDate -> Car_Reg (ця залежність позначена як fd4) не вхідний у первинний ключ атрибут Car_Reg частково залежить від не вхідного в первинний, ключ атрибута Staff_No. На цій стадії нормалізації ми не будемо усувати цю залежність, оскільки частина детермінанта цієї залежності містить атрибут, що входить у первинний ключ IDate. Інакше, говорячи, ця залежність не цілком, транзитивно залежить від атрибутів, що не входять: у первинний ключ, а тому вона не порушує вимог ЗНФ. (Інакше кажучи, як описано в розділі 6.8.1, при розгляді всіх потенційних ключів відносини наявність залежності Staff_No, IDate -> Car_Reg у ЗНФ допускається, оскільки атрибут Car_Reg входить у первинний ключ, тому що він є .частиною потенційного ключа (Car_Reg, IDate, ITime) вихідного відношення Property_Inspection.)

Для перетворення відносини Property_InBpection у ЗНФ необхідно усунути транзитивну залежність Staff_No -> SName. Транзитивна залежність усувається шляхом створення двох нових відносин Staff і Prop_Inspect

Staff (Staff_No, SName)

Prop_Inspect (Property No, IDate. ITime, Coimments, Staff_No, Car Reg)

В ідносини Staff і Prop_Inspect знаходяться в третій нормальній формі, оскільки жоден їхній атрибут, що не входить у первинний ключ, не залежить цілком від іншого атрибута, що не входить у первинний ключ. Уміст відносин Staff і Prop_Inspect представлене в табл. 6.24 і 6.25 відповідно.

Таким чином, представлене в табл. 6.21 вихідне відношення Property_Inspection у процесі нормалізації було перетворено, у три ЗНФ - відносини, що мають наступний вид:

Prop (Property_No, PAddress)

Staff (Staff_No, SName)

Prop_Inspect (Property_No, IDate, ITime. Comments, Staff_No, Car_Reg)