Popolna funkcionalna odvisnost je stanje normalizacije baz podatkov, ki je enako normalizacijskemu standardu Second Normal Form (2NF) . Na kratko, to pomeni, da izpolnjuje zahteve prve navadne oblike (1NF), vsi ne-ključni atributi pa so popolnoma funkcionalno odvisni od primarnega ključa.
To ni tako zapleteno, kot se morda zdi. Oglejmo si to podrobneje.
Povzetek prve normalne oblike
Preden je lahko baza podatkov popolnoma odvisna od funkcionalnosti, mora najprej izpolnjevati prvo običajni obrazec .
Vse to pomeni, da mora vsak atribut imeti eno samo atomsko vrednost.
Naslednja tabela na primer ni v skladu z 1NF, ker je zaposleni Tina povezana z dvema lokacijama, obe v eni sami celici:
Zaposleni | Lokacija |
---|---|
John | Los Angeles |
Tina | Los Angeles, Chicago |
Omogočanje tega oblikovanja bi lahko negativno vplivalo na posodobitve ali vnose podatkov. Da bi zagotovili skladnost z 1NF, prerazporedite tabelo tako, da imajo vsi atributi (ali celice stolpcev) eno vrednost:
Zaposleni | Lokacija |
---|---|
John | Los Angeles |
Tina | Los Angeles |
Tina | Chicago |
Toda 1NF še vedno ni dovolj, da bi se izognili težavam s podatki.
Kako deluje 2NF za zagotavljanje popolne odvisnosti
Če želite biti popolnoma odvisni, morajo biti vsi ključni atributi, ki niso možni, odvisni od primarnega ključa. (Ne pozabite, da je atribut ključa ključa kateri koli ključ (na primer primarni ali tuji ključ), ki se uporablja za enolično identifikacijo zapisa baze podatkov.
Oblikovalci baz podatkov uporabljajo zapis za opis odvisnih razmerij med atributi:
Če atribut A določi vrednost B, pišemo to A -> B - kar pomeni, da je B funkcijsko odvisen od A. V tem razmerju A določi vrednost B, medtem ko je B odvisna od A.
V tabeli zaposlenih oddelkov , na primer EmployeeID in DeptID sta na primer ključi kandidata: EmployeeID je primarni ključ tabele, medtem ko je DeptID tuji ključ.
Vsak drug atribut - v tem primeru sta EmployeeName in DeptName - mora biti odvisen od primarnega ključa, da dobi njegovo vrednost.
Zaposleni ID | Ime zaposlenega | DeptID | DeptName |
---|---|---|---|
Emp1 | John | Dept001 | Finance |
Emp2 | Tina | Dept003 | Prodaja |
Emp3 | Carlos | Dept001 | Finance |
V tem primeru tabela ni popolnoma odvisna, ker je ime EmployeeName odvisno od primarnega ključa EmployeeID, zato je DeptName namesto DeptIDa odvisna. To se imenuje delna odvisnost .
Da bi bila ta tabela v skladu z 2NF, moramo podatke ločiti v dve tabeli:
Zaposleni ID | Ime zaposlenega | DeptID |
---|---|---|
Emp1 | John | Dept001 |
Emp2 | Tina | Dept003 |
Emp3 | Carlos | Dept001 |
Odstranimo atribut DeptName iz tabele Zaposleni in ustvarimo novo tabelo Oddelki :
DeptID | DeptName |
---|---|
Dept001 | Finance |
Dept002 | Človeški viri |
Dept003 | Prodaja |
Zdaj so odnosi med tabelami popolnoma odvisni ali pa v 2NF.
Zakaj je popolna odvisnost pomembna
Popolna odvisnost med atributi baze podatkov pomaga zagotoviti celovitost podatkov in preprečiti nepravilnosti podatkov.
Na primer, upoštevajte tabelo v zgornjem poglavju, ki se drži samo 1NF. Tukaj je spet:
Zaposleni | Lokacija |
---|---|
John | Los Angeles |
Tina | Los Angeles |
Tina | Chicago |
Tina ima dva zapisa. Če posodabljamo enega, ne da bi ugotovili, da sta dva, bi bili rezultati neskladni.
Ali pa, če želimo dodati zaposlenega v to tabelo, a lokacije še ne poznamo? Morda bomo onemogočili, da celo dodamo novega zaposlenega, če atribut lokacije ne dovoljuje vrednosti NULL.
Celotna odvisnost ni celotna slika, čeprav je pri normalizaciji. Zagotoviti morate, da je vaša baza podatkov v tretji navadni obliki (3NF).