Puna funkcionalna ovisnost je stanje normalizacije baze podataka koja odgovara normalizacijskom standardu drugog normalnog oblika (2NF). Ukratko, to znači da zadovoljava zahtjeve prvog normalnog obrasca (1NF), a svi atributi koji nisu ključni funkcioniraju potpuno funkcionalno od primarnog ključa.
Ovo nije tako komplicirano kao što može zvučati. Pogledajmo to detaljnije.
Sažetak prvog normalnog oblika
Prije nego što baza podataka može biti u potpunosti funkcionalno ovisna, najprije se mora pridržavati Prvi normalni obrazac.
Sve to znači da svaki atribut mora imati jedinstvenu atomsku vrijednost.
Na primjer, u sljedećoj tablici ne u skladu s 1NF, jer je zaposlenik Tina povezan s dvije lokacije, oboje u jednoj ćeliji:
| Zaposlenik | Mjesto |
|---|---|
| Ivan | Los Angeles |
| Tina | Los Angeles, Chicago |
Dopuštanje ovog dizajna moglo bi negativno utjecati na ažuriranja podataka ili unose. Kako bi se osigurala usklađenost s 1NF, preraspodijelite tablicu tako da sve atribute (ili ćelične ćelije) imaju jednu vrijednost:
Prva usklađenost uobičajenih oblika
Ali 1NF još uvijek nije dovoljan da izbjegne probleme s podacima.
Kako funkcionira 2NF kako bi se osiguralo potpuno ovisno
Da bi bili u potpunosti ovisni, svi ključni atributi koji nisu kandidati moraju ovisiti o primarnom ključu. (Imajte na umu da je ključni ključ atributa bilo koji ključ (na primjer, primarni ili strani ključ) koji se koristi za jedinstveno identificiranje zapisa baze podataka.
Dizajneri baze podataka koriste bilješku za opisivanje zavisnih odnosa između atributa:
Ako atribut A određuje vrijednost B, ovo pišemoA -> B- što znači da B funkcionalno ovisi o A. U ovom odnosu, A određuje vrijednost B, dok B ovisi o A.
Na primjer, u nastavku Odjeli zaposlenika tablica, EmployeeID i DeptID su ključni kandidati: EmployeeID je primarni ključ tablice dok je DeptID strani ključ.
Svaki drugi atribut - u ovom slučaju, EmployeeName i DeptName - mora ovisiti o primarnom ključu kako bi dobio svoju vrijednost.
| EmployeeID | Ime zaposlenika | DeptID | DeptName |
|---|---|---|---|
| Emp1 | Ivan | Dept001 | Financije |
| Emp2 | Tina | Dept003 | Prodajni |
| Emp3 | Carlos | Dept001 | Financije |
U tom slučaju, tablica nije u potpunosti ovisna jer, iako EmployeeName ovisi o primarnom ključu EmployeeID, DeptName umjesto toga ovisi o DeptID-u. Ovo se zove djelomična ovisnost .
Kako bi ova tablica bila u skladu s 2NF, moramo razdvojiti podatke u dvije tablice:
| EmployeeID | Ime zaposlenika | DeptID |
|---|---|---|
| Emp1 | Ivan | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Ukloni atribut DeptName iz zaposlenici tablice i stvoriti novu tablicu odjeli :
| DeptID | DeptName |
|---|---|
| Dept001 | Financije |
| Dept002 | Ljudski resursi |
| Dept003 | Prodajni |
Sada su odnosi između tablica u potpunosti ovisni, ili u 2NF.
Zašto je puna ovisnost važna
Potpuna ovisnost između atributa baze podataka pomaže u osiguravanju cjelovitosti podataka i izbjegavanja anomalija podataka.
Na primjer, razmislite o tablici u prethodnom odjeljku koji se pridržava samo 1NF. Evo, opet:
| Zaposlenik | Mjesto |
|---|---|
| Ivan | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Tina ima dva zapisa. Ako ažuririmo jedan, a da ne shvatimo da postoje dva, rezultat bi bili nedosljedni podaci.
Ili, što ako želimo dodati zaposlenika u ovu tablicu, ali još uvijek ne poznajemo lokaciju? Možda nam nije dopušteno čak dodati novi zaposlenik ako atribut lokacije ne dopušta NULL vrijednosti.
Punu ovisnost nije cijela slika, međutim, kada je riječ o normalizaciji. Morate biti sigurni da je baza podataka u trećem normalnom obrascu (3NF).
