Ett fullständigt funktionellt beroende är ett tillstånd av databas normalisering som motsvarar normaliseringsstandarden för Second Normal Form (2NF). I korthet betyder detta att det uppfyller kraven i First Normal Form (1NF), och alla icke-nyckelattribut är helt funktionellt beroende av primärnyckeln.
Det här är inte så komplicerat som det kanske låter. Låt oss se mer på det här.
Sammanfattning av första normala formuläret
Innan en databas kan vara fullständigt funktionellt beroende måste den först uppfylla First Normal Form.
Allt detta innebär att varje attribut måste hålla ett enda atomvärde.
Till exempel gör följande tabell inte följa 1NF, eftersom arbetstagaren Tina är länkad till två platser, båda i en enda cell:
| Anställd | Plats |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles, Chicago |
Att tillåta denna design kan påverka datauppdateringar eller poster negativt. För att säkerställa 1NF-överensstämmelse, omordna bordet så att alla attribut (eller kolumnceller) har ett enda värde:
Första Normal Form Compliance
Men 1NF är fortfarande inte tillräckligt för att undvika problem med data.
Hur 2NF arbetar för att säkerställa fullständig beroende
För att vara helt beroende måste alla icke-kandidatnyckelfunktioner bero på den primära nyckeln. (Kom ihåg att en kandidatnyckelattribut är någon nyckel (till exempel en primär eller utländsk nyckel) som används för att unikt identifiera en databaspost.
Databasdesigners använder en notering för att beskriva de beroende förhållandena mellan attribut:
Om attribut A bestämmer värdet på B skriver vi dettaA -> B- vilket betyder att B är funktionellt beroende av A. I detta förhållande bestämmer A värdet av B, medan B beror på A.
Till exempel i följande Medarbetaravdelningar tabell, EmployeeID och DeptID är båda kandidatnycklarna: EmployeeID är tabellens primära nyckel medan DeptID är en främmande nyckel.
Alla andra attribut - i detta fall, EmployeeName och DeptName - måste bero på den primära nyckeln för att få sitt värde.
| Anställnings-ID | Anställd Namn | DeptID | DeptName |
|---|---|---|---|
| Emp1 | John | Dept001 | Finansiera |
| Emp2 | Tina | Dept003 | försäljning |
| Emp3 | Carlos | Dept001 | Finansiera |
I det här fallet är inte tabellen helt beroende av att, medan Medarbetarnamn beror på den primära nyckeln EmployeeID, beror DeptName istället på DeptID. Det här kallas delvis beroende .
För att denna tabell ska överensstämma med 2NF måste vi separera data i två tabeller:
| Anställnings-ID | Anställd Namn | DeptID |
|---|---|---|
| Emp1 | John | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Vi tar bort attributet DeptName från anställda bord och skapa ett nytt bord avdelningar :
| DeptID | DeptName |
|---|---|
| Dept001 | Finansiera |
| Dept002 | Personalavdelning |
| Dept003 | försäljning |
Nu är relationerna mellan borden helt beroende, eller i 2NF.
Varför fullständigt beroende är viktigt
Fullständigt beroende av databasattribut bidrar till att säkerställa dataintegritet och undvika dataavvikelser.
Tänk på tabellen i avsnittet ovan som bara följer 1NF. Här är det, igen:
| Anställd | Plats |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | chicago |
Tina har två poster. Om vi uppdaterar en utan att inse att det finns två, skulle resultatet bli inkonsekventa data.
Eller, om vi vill lägga till en anställd i den här tabellen, men vi känner ännu inte till platsen? Vi kanske inte tillåts att tillägga en ny anställd om platsattributet inte tillåter NULL-värden.
Fullständigt beroende är dock inte hela bilden, när det gäller normalisering. Du måste vara säker på att din databas finns i tredje normala formuläret (3NF).
