C, PHP, VB, .NET

Домейн-ключ нормалната форма в общи линии не се ползва в практиката и рядко се изучава дори в университетите. При нея се дефинират множества от допустими стойности чрез таблици. Обикновено е много по-подходящо въпросните ограничения да се правят в приложния софтуер, чрез CHECK ограничения или с тригери. Въпреки това за пълнота ще ги разгледам техниката за тази нормализация и тук.

Нека е дадена следната таблица:

+--------------+---------------+----------+-----------+
| professor_id | name          | position | contract  |
+--------------+---------------+----------+-----------+
|            1 | Иван Иванов   | асистент | срочен    |
|            2 | Димитър Илиев | доцент   | постоянен |
|            3 | Тодор Пенков  | професор | постоянен |
+--------------+---------------+----------+-----------+

В таблицата е записано кой преподавател на каква работна позиция работи и на какъв вид трудов договор работи. Позициите са асистент, главен асистент, доцент и професор, а договорите са срочни и постоянни. Проблемът тук е породен от законодателството на Република България и по-точно „Закон за развитие на академичния състав“. В него има следния текст:

Чл. 17. (Изм. - ДВ, бр. 101 от 2010 г.) Висшите училища и научните организации назначават лица на длъжност „асистент“ на срочен трудов договор.

Оказва се, че в закона не е позволено даден преподавател да е назначен на длъжност асистент и заедно с това да е на постоянен трудов договор. Най-често в практиката програмистите решават проблема чрез съответен код с проверки в приложната програма – не разчитат на промени в дизайна на базата от данни. Въпреки това бихме могли да направим преработка на таблицата чрез нейна декомпозиция, която да гарантира, че този проблем няма да се получи никога:

+--------------+---------------+-----------+
| professor_id | name          | position  |
+--------------+---------------+-----------+
|            1 | Иван Иванов   |         1 |
|            2 | Димитър Илиев |         5 |
|            3 | Тодор Пенков  |         3 |
+--------------+---------------+-----------+

+--------------+---------------+-----------+
| position_id  | name          | contract  |
+--------------+---------------+-----------+
|            1 | асистент      |    срочен |
|            2 | гл. асистент  |    срочен |
|            3 | гл. асистент  | безсрочен |
|            4 | доцент        |    срочен |
|            5 | доцент        | безсрочен |
|            6 | професор      |    срочен |
|            7 | професор      | бецсрочен |
+--------------+---------------+-----------+

Идеята очевидно е да опишем всички възможни позиции и от тук насетне да позволяваме на даден преподавател да заема само избрана конкретна от тях (припомняме, че външен ключ може да приема само стойност, която е равна на съответната по свързания първичен ключ). При положение, че в новата таблица позиция „асистент на постоянен договор“ не съществува, няма да има и как да се назначи преподавател на такава. Това, което направихме, е че създадохме ново множество от допустими стойности (домейн) за позицията на преподавателите, които са точно седем на брой. При това забележете, че не пречи работните позиции да се променят и допълват при смяна на законодателството – това е нещо, което е плюс спрямо решението с проверки в кода на софтуера, защото при него ще се налага препрограмиране на софтуерни продукти. Показаната декомпозиция е привеждането в ДКНФ. Тази нормална форма е по-специална от другите, защото при нея не се дефинират строги и категорично ясни правила, по които да се извърши нормализацията. Дефиницията на ДКНФ гласи следното:

Една релация е в ДКНФ ако всяко ограничение по нея е логическо следствие от дефиницията на нейния първичен ключ и на домейна на атрибутите ѝ.

Тук е важно да се дефинира добре думата „ограничение“ (на английски „constraint”). Авторът Fagin (1981) е имал предвид множествата от допустими стойности, правилата на външен и първичен ключ, функционални и множествени зависимости. Това обаче не включва т.нар. „времеви масиви с информация“ (temporal data) и ограничения свързани с промени на информацията, за които се говори при шеста нормална форма.

Трябва да знаем, че не всяка релация може да бъде приведена в ДКНФ. Ако например приложим ограничение за студентите, което гласи „не можете да записвате повече от четири избираеми учебни предмета за един семестър“, това ще значи, че в евентуалната таблица, в която правим записи за това кой студент какъв предмет е записал, ние трябва да възпрем въвеждането на повече от четири реда с комбинации между факултетен номер и уникален номер на семестър. Подобно ограничение не е следствие от дефиницията за първичен ключ и няма нищо общо с допустимите стойности на колоните на таблицата – следователно това ограничение довежда до нарушаване на ДКНФ и е невъзможност таблицата да се приведе до тази нормална форма.

Както вече казах, няма категоричен алгоритъм за привеждане на релация в ДКНФ. Процесът на нормализация до тази нормална форма е по-скоро творчески, отколкото научен. Такива казуси също рядко се разискват в училище. Хубаво е обаче да се знаят и учителят да има готовност да отговаря на евентуално възникнали въпроси около тях. Понякога учениците добиват чувството, че трябва да се „престарават“ в това да не допускат въвеждане на невалидна информация в таблиците. Именно в такива случаи е възможно да се достигне до питане по проблем, който се разрешава единствено с ДКНФ и учителят трябва да има основна идея за неговото решение.