Č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

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

Treća normalna forma

Četvrta normalna forma

Četvrta normalna forma

VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)
Četvrta normalna forma, 10.0 out of 10 based on 4 ratings

10 Responses to “Četvrta normalna forma”

  1. 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 :)

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. 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 ..

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  3. 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?

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  4. 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/ )

    VN:F [1.9.22_1171]
    Rating: 5.0/5 (1 vote cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  5. MM - December 11, 2009

    ako 3nf dodamo kolone u tablici ko_has_sta, dali je baza u 3nf?

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: -1 (from 1 vote)
  6. Bogdan Kecman - December 11, 2009

    sta dodas gde ?

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  7. MM - December 11, 2009

    znači tabeli “ko_has_sta” sa prve slike dodamo neke kolone.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  8. Bogdan Kecman - December 11, 2009

    to ce verovatno ubiti normalizaciju

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  9. 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?

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  10. 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

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

Leave a Reply