Ett fullständigt funktionellt beroende är ett tillstånd av databasnormalisering som motsvarar normaliseringsstandarden för Second Normal Form (2NF). Kort sagt betyder det att den uppfyller kraven i First Normal Form (1NF), och alla icke-nyckelattribut är helt funktionellt beroende av den primära nyckeln. Det här är inte så komplicerat som det kan låta. Låt oss titta på detta mer detaljerat.
Sammanfattning av första normala formuläret
Innan en databas kan vara helt funktionellt beroende måste den först följa First Normal Form. Allt detta innebär att varje attribut måste ha ett enda atomvärde. Följande tabell överensstämmer till exempel inte med 1NF eftersom den anställde 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-efterlevnad, ordna om tabellen så att alla attribut (eller kolumnceller) har ett enda värde:
| Anställd | Plats |
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Men 1NF räcker fortfarande inte för att undvika problem med data.
Hur 2NF fungerar för att säkerställa fullständigt beroende
För att vara helt beroende måste alla icke-kandidatnyckelattribut bero på primärnyckeln. Ett attribut för kandidatnyckel är vilken nyckel som helst (till exempel en primär eller främmande nyckel) som används för att identifiera en databaspost unikt. Databasdesigners använder en notation för att beskriva de beroende relationerna mellan attribut: Om attribut A bestämmer värdet på B, skriver vi detta A -> B, vilket innebär att B är funktionellt beroende av A. I detta förhållande bestämmer A värdet på B, medan B beror på A. Till exempel i följande medarbetaravdelningar tabell, Anställnings-ID och DeptID är båda kandidatnycklarna: Anställnings-ID är tabellens primära nyckel medan DeptID är en utländsk nyckel. Alla andra attribut – i det här fallet Anställd Namn och Avdelningsnamn— Måste bero på den primära nyckeln för att få sitt värde.
| Anställnings-ID | Anställd Namn | DeptID | Avdelningsnamn |
| Emp1 | John | Avdelning 001 | Finansiera |
| Emp2 | Tina | Avdelning003 | Försäljning |
| Emp3 | Carlos | Avdelning 001 | Finansiera |
I det här fallet är tabellen inte helt beroende eftersom, medan EmployeeName beror på den primära nyckeln Anställnings-ID, den Avdelningsnamn beror istället på DeptID. Detta kallas partiellt beroende. För att denna tabell ska överensstämma med 2NF, måste vi dela upp data i två tabeller: en anställdstabell och en avdelningstabell. Här är tabellen Anställda:
| Anställnings-ID | Anställd Namn | DeptID |
| Emp1 | John | Avdelning 001 |
| Emp2 | Tina | Avdelning003 |
| Emp3 | Carlos | Avdelning 001 |
Vi tar bort Avdelningsnamn attribut från tabellen anställda och skapa en ny tabellavdelningar:
| DeptID | Avdelningsnamn |
| Avdelning 001 | Finansiera |
| Avdelning 002 | Personalavdelning |
| Avdelning003 | Försäljning |
Nu är förhållandena mellan tabellerna helt beroende, eller i 2NF.
Varför fullständigt beroende är viktigt
Fullt beroende av databasattribut hjälper till att säkerställa dataintegritet och undvika dataavvikelser. Tänk till exempel på tabellen i avsnittet ovan som endast 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å, blir resultatet inkonsekventa data. Eller, vad händer om vi vill lägga till en anställd i den här tabellen, men vi vet inte platsen ännu? Vi kan inte tillåtas att till och med lägga till en ny anställd om Plats attribut tillåter inte NULL-värden. Fullt beroende är dock inte hela bilden när det gäller normalisering. Du måste se till att din databas har tredje normalform (3NF).
