Пълната функционална зависимост е състояние на нормализиране на базата данни, което се равнява на стандарта за нормализиране на втората нормална форма (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 от таблицата Employees и създаваме нова таблица Департаменти :
DeptID | DeptName |
---|---|
Dept001 | Финанси |
Dept002 | Човешки ресурси |
Dept003 | търговски |
Сега отношенията между таблиците са напълно зависими или в 2NF.
Защо пълната зависимост е важна
Пълната зависимост между атрибутите на базата данни спомага за гарантирането на целостта на данните и предотвратява аномалиите в данните.
Например разгледайте таблицата в горната част, която се придържа само към 1NF. Тук отново е:
Служител | местоположение |
---|---|
Джон | Лос Анжелис |
Тина | Лос Анжелис |
Тина | Чикаго |
Тина има две записи. Ако актуализираме едно, без да осъзнаваме, че има две, резултатът би бил несъвместими данни.
Или, ако искаме да добавим служител на тази маса, но все още не знаем местоположението? Може да бъдем забранени дори да добавим нов служител, ако атрибутът "Местоположение" не позволява стойности NULL.
Пълната зависимост не е цялата картина, обаче, когато става дума за нормализиране. Трябва да сте сигурни, че вашата база данни е в трета нормална форма (3NF).