Skip to content

Fullt funktionellt beroende i databasnormalisering

5 de juli de 2021
GettyImages 167132255 5a43c8b77d4be8003619e14d

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).