Četvrta normalna forma
Za DB model možemo reći da ispunjava uslove četvrte normalne forme ako za svaku ne trivijalnu višeznačnu zavisnost A→→ B postoji funckionalna zavisnost A→C za svaki atribut C u modelu, odnosno A je superključ. Prevedeno na srpski, svaka zavisnost je po ključu.
U realnom životu treća ili BC normalna forma su uglavnom dovoljne. Pregledao sam za života mnogo DB modela (jedna od stvari koje Platinum korisnici MySQL supporta imaju je schema & query review – gde im mi pregledamo/prepravimo db model i upite) i mogu reći da u 99.99% slučajeva DB model koji ne zadovoljava četvrtu normalnu formu ne zadovoljava je “sa razlogom”, tj. nedostatak vezanosti po ključu je odsutna iz prostog razloga što se ista u samoj aplikaciji jako retko koristi te je nekada optimalnije nemati ključ i imati sporiji upit jednom mesečno nego imati ključ i opteretiti sistem održavanjem tog ključa.
Kako smo izašli iz funkcionalnih odnosa koji su bitni za normalizaciju do BC normalne forme, moraćemo napraviti novi primer kako bi smo objasnili četvrtu normalnu formu. Možda je primer mogao da bude bolji, ali ja nisam prosvetni radnik niti pretendujem na tu poziciju pa kome se ne sviđa neka napiše bolje :D. Recimo da imamo advokatske kancelariju od kojih se
- pera zna kriminalno pravo i nekretnine
- pera poznaje nekoga u prvom i drugom opštinskom
- žika zna kriminalno pravo
- žika poznaje nekoga u drugom i trećem opštinskom
kada to sve pomnozimo, dobijemo ključ:
pera, kriminalno, prvi opstinski
pera, kriminalno, drugi opstinski
pera, nekretnine, prvi opstinski
pera, nekretnine, drugi opstinski
žika, kriminalno, drugi opstinski
žika, krimilano, treći opstinski
Ova tabela (ključ iz nekoliko tabela) ima dve ne trivijalne višeznačne zavisnosti [KO] →→ [ŠTA] i [KO] →→ [GDE], dakle, kada dođe klijent i prezentuje slučaj bitno je ko ima vezu u sudu gde se sudi i ko ima znanje o materiji o kojoj se sudi. Ove ne trivijalne višeznačne zavisnosti nad poljem koje nije superključ (KO) dovode do anomalije da ako žika nauči nekretnine moramo da dodamo to u 2 nova sloga. Da bi izbegli ovu anomaliju, ovu veznu tabelu (ključ) razbijamo u 2 tabele (ključa) [KO] [ŠTA] i [KO] [GDE]
Kako bi to prikazali i diagramom evo ga DB model u trećoj normalnoj formi, i onda taj isti u četvrtoj normalnoj formi.
Treća normalna forma
Četvrta normalna forma
10 Responses to “Četvrta normalna forma”
pedja - May 11, 2009
Licno kod mene je opredeljivanje izmedju 3NF i 4NF zavisi od slucaja, tj od izvestaja. Jer nekad treba da su ti podaci STA i GDE povezani nekad ne, pa bi tesko bilo razdvojiti ih.
PS nisam ni znao da znam za 4NF to je izgleda urodjeno :)
Bogdan Kecman - May 11, 2009
Ako su STA i GDE u direktnoj vezi onda je prica potpuno drugacija posto ako su STA i GDE u direktnoj vezi veza od KO ka bilo kom od ta dva (STA ili GDE) definise i vezu sa onim drugim, dakle ako je X→Y i Y→Z onda X→Z sledi i nije ga potrebno zasebno definisati … to se radi do 3nf i sa 4nf nema veze. 4nf ima veze samo ako je X→YZ tj X→→Y ali u slucaju gde za svako Z postoko X→Z.
Navedeni primer (sa KO, STA, GDE) sa primerom DB modela u trcoj i cetvrtoj normalnoj formi je potpuno isti po tipu podatka koji moze da sacuva, razlika je samo u normalizaciji. Jedan od dva navedena modela ne moze da da “Vecu slobodu” ili “bolje objasni” model. Razlika je samo u nivou normalizacije te “nekad treba da su ti podaci STA i GDE povezani nekad ne, pa bi tesko bilo razdvojiti ih” ne stoji iz prostog razloga sto je veza STA i GDE nedostajuca.
P.S. sto se tice “urodjenog dela” … potpuno se slazem :) … kada pogledam modele koje sam modelirao pre nego sam cuo za normalizaciju i normalne forme, normalizovani su svi preko cetvrte forme ..
Dejan Topalović - May 15, 2009
I ja licno u praksi rijetko srecem slucajeve, gdje je potrebna visa normalizacija od 3 NF…
Koji alat koristis za ER dijagrame?
Bogdan Kecman - May 15, 2009
Oni stari diagrami (1-3nf) su radjeni u ErWin-u (4.1 ako se dobro secam). To sam koristio do skoro, od skoro koristim iskljucivo MySQL WorkBench ( http://dev.mysql.com/workbench/ ). Ovi diagrami (plavi) su iz njega. WorkBench ima i ostale notacije, cak za razliku od vecine drugih moze da ima jednu notaciju za entitete a drugu za relacije i slicno .. prilicno lepo radi – ko nije probao – savetujem da obavezno proba. ( http://www.mysql.rs/tag/workbench/ )
MM - December 11, 2009
ako 3nf dodamo kolone u tablici ko_has_sta, dali je baza u 3nf?
Bogdan Kecman - December 11, 2009
sta dodas gde ?
MM - December 11, 2009
znači tabeli “ko_has_sta” sa prve slike dodamo neke kolone.
Bogdan Kecman - December 11, 2009
to ce verovatno ubiti normalizaciju
MM - December 11, 2009
http://northwind.bi4ce.com/Portals/0/Images/NorthwindDB.gif
dali je ovo ok kod OrderDetails?
kako bi se ova baza prevela u 3nf?
MM - December 11, 2009
@8 odgovor
zar je kod 3nf, zabranjeno u veznoj tabeli imati dodatne kolone?
ako ovise o nekoj koja je dio primarnog ključa?
kao što je količina u OrderDetails kod te baze
Leave a Reply