En full funksjonell avhengighet er en tilstand av database normalisering som tilsvarer normaliseringsstandarden for Second Normal Form (2NF). Kort sagt betyr dette at det oppfyller kravene til First Normal Form (1NF), og alle ikke-nøkkelattributter er fullt funksjonelt avhengig av primærnøkkelen.
Dette er ikke så komplisert som det kan høres ut. La oss se nærmere på dette.
Sammendrag av første normal form
Før en database kan være fullt funksjonell avhengig, må den først overholde First Normal Form.
Alt dette betyr at hvert attributt må inneholde en enkelt atomverdi.
For eksempel, gjør følgende tabell ikke oppfyller 1NF, fordi ansatt Tina er knyttet til to steder, begge i en enkelt celle:
| Ansatt | plassering |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles, Chicago |
Å tillate dette designet kan påvirke dataoppdateringer eller oppføringer negativt. For å sikre overholdelse av 1NF, omordne bordet slik at alle attributter (eller kolonneceller) har en enkelt verdi:
Første Normal Form Compliance
Men 1NF er fortsatt ikke nok til å unngå problemer med dataene.
Hvordan fungerer 2NF for å sikre full avhengighet
For å være fullt avhengig, må alle ikke-kandidatnøkkelattributter avhenge av primærnøkkelen. (Husk at en kandidatnøkkelattributt er en hvilken som helst nøkkel (for eksempel en primær eller utenlandsk nøkkel) som brukes til å identifisere en databaseoppføring unikt.
Databasedesignere bruker en notasjon for å beskrive de avhengige forholdene mellom attributter:
Hvis attributt A bestemmer verdien av B, skriver vi detteA -> B- som betyr at B er funksjonelt avhengig av A. I dette forholdet bestemmer A verdien av B, mens B avhenger A.
For eksempel, i det følgende Medarbeideravdelinger tabell, EmployeeID og DeptID er begge kandidatnøkler: EmployeeID er tabellens primærnøkkel mens DeptID er en fremmednøkkel.
Ethvert annet attributt - i dette tilfellet, EmployeeName og DeptName - må avhenge av primærnøkkelen for å oppnå verdien.
| Ansatt ID | Arbeidstakers navn | DeptID | DEPTNAME |
|---|---|---|---|
| Emp1 | John | Dept001 | Finansiere |
| Emp2 | Tina | Dept003 | salgs~~POS=TRUNC |
| Emp3 | Carlos | Dept001 | Finansiere |
I dette tilfellet er tabellen ikke helt avhengig fordi, mens Medarbeidernavn avhenger av primærnøkkelen EmployeeID, avhenger DeptName i stedet på DeptID. Dette kalles delvis avhengighet .
For å gjøre dette tabellen i samsvar med 2NF, må vi skille dataene i to tabeller:
| Ansatt ID | Arbeidstakers navn | DeptID |
|---|---|---|
| Emp1 | John | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Vi fjerner DeptName-attributtet fra medarbeidere bord og opprett et nytt bord avdelinger :
| DeptID | DEPTNAME |
|---|---|
| Dept001 | Finansiere |
| Dept002 | Menneskelige ressurser |
| Dept003 | salgs~~POS=TRUNC |
Nå er forholdet mellom bordene fullt avhengige, eller i 2NF.
Hvorfor full avhengighet er viktig
Full avhengighet mellom databaseattributter bidrar til å sikre dataintegritet og unngå dataavvik.
For eksempel, se tabellen i seksjonen ovenfor som bare overholder 1NF. Her er det igjen:
| Ansatt | plassering |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Tina har to poster. Hvis vi oppdaterer en uten å innse at det er to, vil resultatet være inkonsekvente data.
Eller hva om vi vil legge til en ansatt i dette bordet, men vi kjenner ennå ikke plasseringen? Vi kan ikke tillates å til og med legge til en ny medarbeider dersom plasseringsattributtet ikke tillater NULL-verdier.
Full avhengighet er ikke hele bildet, men når det gjelder normalisering. Du må sørge for at databasen er i Tredje Normal Form (3NF).
