Пълната функционална зависимост е състояние на нормализиране на базата данни, което се равнява на стандарта за нормализиране на втората нормална форма (2NF). Накратко, това означава, че тя отговаря на изискванията на First Normal Form (1NF), а всички не-ключови атрибути са напълно функционално зависими от първичния ключ.
Това не е толкова сложно, колкото може да звучи. Нека разгледаме това по-подробно.
Обобщение на първата нормална форма
Преди да може база данни да е напълно функционална зависима, тя трябва първо да се съобрази с първата нормална форма.
Всичко това означава, че всеки атрибут трябва да притежава единична, атомна стойност.
Например, следващата таблица прави не отговарят на 1NF, защото служителят Tina е свързан с две места, и двете в една клетка:
| Служител | местоположение |
|---|---|
| Джон | Лос Анжелис |
| Тина | Лос Анджелис, Чикаго |
Разрешаването на този дизайн може да повлияе отрицателно върху актуализациите или записите на данни. За да се осигури съответствие с 1NF, пренареждайте таблицата така, че всички атрибути (или колонни клетки) да съдържат една единствена стойност:
Първо съответствие с нормалния формат
Но 1NF все още не е достатъчно, за да се избегнат проблеми с данните.
Как 2NF работи за осигуряване на пълна зависимост
За да бъде напълно зависима, всички непризнати ключови атрибути трябва да зависят от първичния ключ. (Не забравяйте, че ключовият атрибут на кандидат е всеки ключ (например първичен или чужд ключ), използван за уникално идентифициране на запис на база данни.
Дизайнерите на бази данни използват обозначение, за да опишат зависимите взаимоотношения между атрибутите:
Ако атрибут А определя стойността на B, ние пишем товаA -> B- това означава, че B е функционално зависим от А. В тази връзка A определя стойността на B, докато B зависи от А.
Например, в следното Отделения на служителите таблицата, EmployeeID и DeptID са двата класа кандидати: EmployeeID е първичният ключ на таблицата, докато DeptID е чужд ключ.
Всеки друг атрибут - в този случай EmployeeName и DeptName - трябва да зависи от първичния ключ, за да получи неговата стойност.
| EmployeeID | Име на служителя | DeptID | DeptName |
|---|---|---|---|
| Emp1 | Джон | Dept001 | Финанси |
| Emp2 | Тина | Dept003 | търговски |
| Emp3 | Карлос | Dept001 | Финанси |
В този случай таблицата не е напълно зависима, защото, докато EmployeeName зависи от основния ключ EmployeeID, DeptName зависи вместо DeptID. Това се казва частична зависимост .
За да направим тази таблица в съответствие с 2NF, трябва да разделяме данните на две таблици:
| EmployeeID | Име на служителя | DeptID |
|---|---|---|
| Emp1 | Джон | Dept001 |
| Emp2 | Тина | Dept003 |
| Emp3 | Карлос | Dept001 |
Премахваме атрибута DeptName от Служители таблицата и да създадете нова таблица Катедри :
| DeptID | DeptName |
|---|---|
| Dept001 | Финанси |
| Dept002 | Човешки ресурси |
| Dept003 | търговски |
Сега отношенията между таблиците са напълно зависими или в 2NF.
Защо пълната зависимост е важна
Пълната зависимост между атрибутите на базата данни спомага за гарантирането на целостта на данните и предотвратява аномалиите в данните.
Например разгледайте таблицата в горната част, която се придържа само към 1NF. Тук отново е:
| Служител | местоположение |
|---|---|
| Джон | Лос Анжелис |
| Тина | Лос Анжелис |
| Тина | Чикаго |
Тина има две записи. Ако актуализираме едно, без да осъзнаваме, че има две, резултатът би бил несъвместими данни.
Или, ако искаме да добавим служител на тази маса, но все още не знаем местоположението? Може да бъдем забранени дори да добавим нов служител, ако атрибутът "Местоположение" не позволява стойности NULL.
Пълната зависимост не е цялата картина, обаче, когато става дума за нормализиране. Трябва да сте сигурни, че вашата база данни е в трета нормална форма (3NF).
