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

Розглянемо таблицю “СПІВРОБІТНИКИ”, що отримана після приведення первинної таблиці до другої нормальної форми. Для цієї таблиці існує функціональний звязок між полями “Код співробітника” та “Зарплата”, але цей функціональний звязок є транзитивним.

Функціональна залежність атрибутів Х та Y відношення R називають транзитивною, якщо існує такий атрибут Z, що існують функціональні залежності X => Z та Z => Y, але відсутня функціональна залежність Z => X.

Транзитивність залежностей полів “Код співробітника” та “Зарплата” означає, що заробітна плата природньо є характеристикою не співробітника, а посади, яку він займає. В результаті ми не можемо внести в БД інформацію, що характеризує заробітну плату посади, до тих пір, а ж поки не зявиться хоча б один співробітник, що займає цю посаду (тому що первинний ключ не може приймати невизначене значеення). При вилученні кортежу, що описує останнього співробітника, який займає цю посаду, ми лишаємся також інформації, що відповідає посаді. Крім того, щоб узгодженим чином змінити зарплату, що відповідає цієї посаді, ми повинні попередньо знайти всі записи, що описують співробітників, які займають таку посаду.

Таким чином, в таблиці “СПІВРОБІТНИКИ” як і раніше існують аномалії. Їх можливо усунути шляхом подальшій нормалізації – приведення БД до третьої нормальної форми.

Відношення R знаходиться в третій нормальній формі в тому і тільки в тому випадку, якщо воно знаходиться в другій нормальній формі і кожен неключевий атрибут нетран­зи­тивно залежить від первинного ключа.

Для того, щоб перейти від другої до третьої нормальної форми, потрібно виконати наступні кроки:

1. Визначити всі поля (чи групи полів), від яких залежать інші поля.

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

3. Вилучити переміщені поля з первинної таблиці, залишивши лише ті з них, які стануть зовнішніми ключами.

Зауваження. Треба звернути увагу на то, що ми додали ще один новий атрибут – “Код посади”, який є первинним ключом для відношення “ПОСАДА” і зовнішнім ключом для відношення “СПІВРОБІТНИКИ”. Додавання нових атрибутів при нормалізації дозволяє получати таблиці з простими первинними ключами, що полегшує виконання операцій звязування таблиць. Як правило, такі первинні ключі є штучними.

Приведемо БД, що розглядається як приклад, до третьої нормальної формию Для цього поділемо таблицю “СПІВРОБІТНИКИ” на дві – “СПІВРОБІТНИКИ” та “ПОСАДИ” (мал. 22).

		Код співробітника Код посади Код фізичної особи Статус Дата прийому Дата звільнення
	Код співробітника Код фізичної особи Посада Розряд Зарплата Статус Дата прийому Дата звільнення
		Код посади Посада Розряд Зарплата

Мал. 22. Приведення БД до третьої нормальної форми

На практиці треття нормальна форма схем відношень в більшості випадків достатня, і приведенням до третьої нормальної форми процес проектування реляційної БД можна закінчити. Тому ту не будуть розглядатися інші нормальні форми, тим більш що в роботі вони викоритовуються дуже рідко.

Мал. 23. Структура БД, приведена до третьої нормальної форми

Поиск по сайту: