En fuld funktionel afhængighed er en tilstand af database normalisering, der svarer til normaliseringsstandarden for anden normal form (2NF). Kort sagt betyder det, at det opfylder kravene i First Normal Form (1NF), og alle ikke-nøgleattributter er fuldt funktionelt afhængige af primærnøglen.
Dette er ikke så kompliceret, som det måske lyder. Lad os se nærmere på dette.
Resumé af første normale formular
Før en database kan være fuldt funktionel afhængig, skal den først overholde Første Normal Form.
Alt dette betyder, at hver attribut skal indeholde en enkelt atomværdi.
For eksempel gør følgende tabel ikke overholde 1NF, fordi medarbejderen Tina er knyttet til to steder, begge i en enkelt celle:
| medarbejder | Beliggenhed |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles, Chicago |
Tilladelse af dette design kan påvirke dataopdateringer eller -indgange negativt. For at sikre overholdelse af 1NF skal du omarrangere bordet, så alle attributter (eller kolonneceller) har en enkelt værdi:
Første Normal Form Compliance
Men 1NF er stadig ikke nok til at undgå problemer med dataene.
Hvordan 2NF arbejder for at sikre fuld afhængighed
For at være fuldt afhængig skal alle ikke-kandidatnøgleattributter afhænge af primærnøglen. (Husk, at en kandidatnøgleattribut er en hvilken som helst nøgle (for eksempel en primær eller en udenlandsk nøgle), der bruges til at identificere en databasepost entydigt.
Databasedesignere bruger en notation til at beskrive de afhængige relationer mellem attributter:
Hvis attribut A bestemmer værdien af B, skriver vi detteA -> B- hvilket betyder, at B er funktionelt afhængig af A. I dette forhold bestemmer A værdien af B, mens B afhænger af A.
For eksempel i det følgende Medarbejderafdelinger tabel, EmployeeID og DeptID er begge kandidatnøgler: EmployeeID er bordets primære nøgle, mens DeptID er en fremmednøgle.
Enhver anden attribut - i dette tilfælde, EmployeeName og DeptName - skal afhænge af den primære nøgle for at opnå dens værdi.
| Medarbejder-ID | Ansattes navn | DeptID | DEPTNAME |
|---|---|---|---|
| EMP1 | John | Dept001 | Finansiere |
| Emp2 | Tina | Dept003 | Salg |
| Emp3 | Carlos | Dept001 | Finansiere |
I dette tilfælde er tabellen ikke fuldt afhængig, fordi medarbejdernavnet afhænger af den primære nøgle EmployeeID, afhænger DeptName i stedet på DeptID. Dette kaldes delvis afhængighed .
For at gøre denne tabel i overensstemmelse med 2NF, skal vi adskille dataene i to tabeller:
| Medarbejder-ID | Ansattes navn | DeptID |
|---|---|---|
| EMP1 | John | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Vi fjerner DeptName attributten fra medarbejdere bord og opret en ny tabel Afdelinger :
| DeptID | DEPTNAME |
|---|---|
| Dept001 | Finansiere |
| Dept002 | Menneskelige ressourcer |
| Dept003 | Salg |
Nu er forholdet mellem tabellerne helt afhængige, eller i 2NF.
Hvorfor fuld afhængighed er vigtig
Fuld afhængighed mellem databaseattributter hjælper med at sikre dataintegritet og undgå dataanomalier.
Se for eksempel tabellen i ovenstående afsnit, der kun overholder 1NF. Her er det igen:
| medarbejder | Beliggenhed |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Tina har to optegnelser. Hvis vi opdaterer en uden at indse, at der er to, vil resultatet være inkonsekvente data.
Eller hvad hvis vi vil tilføje en medarbejder til denne tabel, men vi kender endnu ikke lokationen? Vi må måske ikke tillades at tilføje en ny medarbejder, hvis placeringsattributten ikke tillader NULL-værdier.
Fuld afhængighed er dog ikke hele billedet, når det kommer til normalisering. Du skal sørge for, at din database er i tredje normale formular (3NF).
