Normalizacija baza podataka

Sadraj
Normalizacija baze podataka ......................................................................................................................... 2
Funkcionalna zavisnost ......................................................................................................................................................................3
Anomalije ...........................................................................................................................................................................................5
Tehnike normalizacije ........................................................................................................................................................................6
Forme normalizacije...........................................................................................................................................................................7
Prva normalna forma ..........................................................................................................................................................................7
Problem sa nestandardnim atributima ...........................................................................................................................................8
Druga normalna forma .......................................................................................................................................................................9
Trea normalna forma ......................................................................................................................................................................10
Praktian primjer normalizacije .......................................................................................................................................................11
Svoenje modela na prvu normalnu formu .................................................................................................................................11
Svodjenje modela na drugu normalnu formu ..............................................................................................................................12
Svoenje modela na treu normalnu formu ................................................................................................................................13
Primjer i analiza anomalija ...............................................................................................................................................................14
1NF i anomalije ..........................................................................................................................................................................14
2NF ..........................................................................................................................................................................................14
3NF .........................................................................................................................................................................................15
Dalje normalizovanje .......................................................................................................................................................................15
Razlozi zbog kojih se moe odustati od normalizacije................................................................................................................16
Dodatak: Procedure i algoritmi ........................................................................................................................................................17
GENERAL PROCEDURE FOR ACHIEVING A NORMALIZED SET OF RELATIONS ......................................................17
Algoritam 2NF normalizacije .....................................................................................................................................................18
Algoritam 3NF normalizacije .....................................................................................................................................................18

Normalizacija baze podataka

Normalizacija baze podataka je proces efikasnog organizovanja podataka u bazi podataka. Normalizacija je
tehnika dizajna baze podataka kojom se na osnovu izvjesnih kriterijuma odreuje sadraj tabela (tj.koje
kolone treba da obuhvataju tabele i njihova struktura kljua).
Normalizacija baze podataka je postupak kojim se iz danog modela bez podataka nastoji otkloniti potreba za
viestrukim ponavljanjem istih podataka (redudansa podataka). Naime, osim to (nekorisno) troi prostor,
viestruko zapisivanje istog podatka oteava (i/ili onemoguava) mijenjanje sadraja baze podataka.
Osnovna ideja je da se eliminie nepotrebno dupliranje ne-kljunih podataka u tabelama te da se tako smanji
veliina prostora koju baza zauzima na disku i da su podaci logino uskladiteni.
Cilj normalizacije moemo izraziti rijeima: Baza podataka treba biti oblikovana tako da se svaki podatak
upisuje samo jednom (ili: samo na jednom mjestu). Dva osnovna cilja procesa normalizacije su:
1. Eliminisanje redudantnih podataka (skladitenje istih podataka na vie mjesta u bazi podataka)
2. Osiguravanje da su zavisnosti podataka logine (u jednoj tabeli se nalaze samo povezani podaci)
Odnosno, osnovni cilj relacionog modela podataka je da odgovarajua baza podataka koja:
1. ne sadri redundansu,
2. se moe jednostavno koristiti i mjenjati.
Pod redundansom podrazumjevamo viestruko memorisanje iste informacije u bazi podataka. Potpuno
eliminisanje redundanse podataka u bazi podataka je skoro nemogue ostvariti. Realni cilj pri projektovanju
baze podataka je kontrolisana redundansa podataka.
Bitna osobina koja se oekuje od normalizacije je reverzibilnost tj. da ne smije doi do gubitka informacija
sadranih u polaznoj relaciji. Polazei od skupa normalizovanih relacija, mora biti mogua rekonstrukcija
polazne nenormalizovane relacije.
Jedan od kljunih ciljeva relacione baze podataka je da se sprijei nepotrebno dupliranje podataka.
U stvari, ovo je jedan od glavnih razloga zato se koriste relacione baze podataka, a ne fajlovi, koji podatke
skladite u jednoj tabeli.
Ponekad se klasa ili objekat dizajnira korektno (zavisi koji model podataka se koristi), a u relacionoj emi se
tek uoi problem.
Normalne forme daju formalne kriterije prema kojima se utvruje da li model podataka ispunjava prethodne
zahtjeve. Normalizacija je proces provjere uslova normalnih formi i po potrebi svoenje eme relacije na
oblik koji zadovoljava isti.
Normalizacija je proces primjene skupa pravila na postojei dizajn baze, uglavnom da bi se postigla
minimalna redudansa podataka.
Uobiajeno se normalizacija predstavljaju kao proces od tri koraka, koji se vezuje za normalne forme, koje
se mogu obaviti u skoro algoritamskom poretku.
U praksi, ee se pravila postepeno primjenjuju, dok se ema svake relacije ne razvije na nain na koji se
dobija iz dijagrama E-R modela ili nekog drugog modela (npr. UML).
Konana struktura tabela treba da bude ista bez obzira koji se metod (ili kombinacija metoda) primenjuje.
Teorija normalizacije nije nita drugo nego formalizacija nekih intuitivno prihvatljivih principa o
"zdravom" oblikovanju eme. Ukoliko ve na poetku dobro uoimo sve potrebne entitete, atribute i veze,
tada nam nikakva daljnja normalizacija nee biti potrebna. No ako je polazna relaciona ema bila loe
oblikovana, tada e postupak normalizacije ispraviti te greke.

Funkcion
nalna zav
visnost
ut ili skup attributa koji ppredstavljaju nadklju zaa
Loa funkccionalna zavvisnost se deeava kada ppostoji atribu
neke atributte, ali ne i zaa cijelu relaciiju. Ovakvi aatributi se nazzivaju podkljjuevi (subkkey) relacije.
Koncept fu
unkcionalne zavisnosti (functional dependencyy) izuzetno je kotistan za rad sa strukturamaa
podataka.
Ako je datta torka T i dva skupa njenih atribbuta, {X1.. .Xn
.
} i {Y1... Yn} (ti skupovi ne moraju bitii
meusobno iskljuivi. Skup
S
Y je fun
nkcionalno zzavisan od sk
kupa X ako, za svaku leggalnu vrijedn
nost u skupuu
X, postoji saamo jedna leegalna vrijed
dnost u skupuu Y.
m
Funkcionalnnu zavisnoost izmeu skupova atributa moete
predstaviti kao na slici. U tekstu
u se funkciionalna zav
visnost
izraava kaoo XY, to se ita kao X
funkcionaalno odreujee Y.
vaka torka koja
k
sadri istu vrijedn
nost atributaa
Na primjerr, u relaciji prikazanoj na predhoddnoj slici, sv
{CategoryN
Name}, imae istu vrijeednost i atrributa {Desccription}. Zbog toga m
moemo rei da atributt
CategoiyNaame funkcionnalno odreuj
uje atrribut D
Description.
Imajte u viidu da funkccionalna zav
visnost ne vvai uvijek i u suprotn
nom smjeru:: poznavanjee vrijednostii
atributa Desscription ne omoguava
o
nam
n da utvrddimo i odgov
varajuu vrijeednost atribuuta CategoiyN
Name.
Dijagrami ffunkcionalnee zavisnosti obino
o
su jasnni sami po seebi.
U praktiniim aplikacijjama, funkciionalna zaviisnost je zg
godan oblik da se izrazzi neto to
o je prilinoo
razumljivo samo po sebbi: svaka relaacija e uvijeek imati odreeeni skup attributa ije suu vrijednostii jedinstvenee
u svakoj torrci; ako su tee vrijednosti poznate,
p
moggu se odreditti i vrijednossti atributa kooje nisu jedin
nstvene.
Prema tome, ako imam
mo torku {X
X, Y}, gdje je {X} kan
ndidat za kllju, onda aatributi {Y} moraju bitii
funkcionalnno zavisni odd {X}; to proizlazi iz defiinicije kandid
data za klju.
Ako {X} nij
ije kandidat za
z klju i fun
nkcionalna zaavisnost nijee trivijalna (tjj. {Y} nije ppodskup od {X}), relacijaa
e obaveznoo sadrati izvvjesnu redun
ndantnost i biie potrebno normalizovaanje.
Atribut moe biti funkciionalno zavisstan ili u odnnosu na drug
gi atribut ili u odnosu na kkombinaciju atributa.
Nije mogue odrediti niivo normalizacije DB moodela bez razzumevanja meusobnih
m
fu
funkcionalnih
h zavisnosti
atributa kojii ine isti.

na zavisnost
Trivijalna ffunkcionaln
Trivijalna fu
funkcionalna zavisnost je funkcionalnna zavisnost atributa
a
prem
ma supersetu sebe.
unkcionalna zavisnost
Potpuna fu
Atribut je ppotpuno funnkcionalno zavistan od sseta atributa X ako je funkcionalno
f
o zavistan od
d X ali nijee
funkcionalnno zavistan ni
n od jednog podskupa
p
setta X.
3

Tranzitivnaa zavisnost
Tranzitivna zavisnost jee indirektna zavisnost
z
gdjje AC sam
mo zato to AB
A
i BC..

Vieznanaa zavisnost
Vieznana zavisnost je
j potpuna veza dva s eta atributa u relaciji. Za razliku od potpunee zavisnosti,,
utni u relacijii te je vieznaana zavisno
ost specijalnii
vieznana zavisnost zaahjteva da odreeni tuplovvi butu prisu
sluaj tuple--generisane zavisnosti.
z
Ova
O vrsta zavvisnosti igra ulogu kod eetvrte normaalne forme.
Vezna zaviisnost
t
od koojih svaka im
ma podskupp
Entitet T jee vezno zavvistan ako see moe rekrreirati vezivaanjem vie tabela
atributa entiiteta T.
Za zadatu rrelaciju R, atribut
a
B od
d R je funkccionalno zav
visan o atrib
butu A od R (oznaka: A B) akoo
vrijednost ood A jednoznnano odreu
uje vrijednosst od B. Dak
kle ako u isto
o vrijeme poostoje u R dv
vije n-torke s
jednakom vvrijednou A,
A tada te n-to
orke moraju imati jednak
ku vrijednostt B.
Analogna ddefinicija prim
mijenjuje se i za sluaj kaad su A i B slloeni atribu
uti (dakle skuupovi atributaa).
Kao primjeer, razmotriimo sljedeu
u (loe oblikoovanu) relaciiju:
IZVESTAJ ( BR INDEKS
SA, BR ISPITA
A, NASLOV_
_ISPITA, IME
E_NASTAVNIIKA,
BR_SOB E_
_NAST AVNI KA, OCJENA
A ).

Pretpostavim
mo da svakki ispit ima jednog
j
nastaavnika, a sv
vaki nastavn
nik jednu soobu. Navodim
mo neke odd
funkcionalnnih zavisnostti:

Za zadatu rrelaciju R, atribut

a
B od R je potpunno funkcionaalno zavisan
n o (sloenom
m) atributu A od R akoo
vrijedi: B jee funkcionalnno zavisan o A, no B nijee funkcionaln
no zavisan nii o jednom prravom podsk
kupu od A.
Svaki atribuut relacije je funkcionalno
o zavisan o kkljuu, no ta zavisnost nee mora biti pootpuna.
Na primjer OCJENA je potpuno fun
nkcionalno zzavisna o priimarnom klju
uu (BR_ IN
NDEKSA, BR
R_ISPITA). S
druge stranne, NASLOV__ISPITA, IM
ME_NASTAVN
VNIKA i BR_
_SOBE_ NAS
STAVNIKA su parcijaln
no zavisni o
kljuu, buduui da su zavvisni samo o BR_ISPITA,, a ne i o BR_
_INDEKSA.
Za BR_SOB
BE_NASTAV
VNIKA se kae da je trranzitivno zavisan
z
o BR_ISPITA,
B
bbudui da je zavisan o
IME_NASTA
TAVNIKA, kooji je opet zav
visan o BR_IISPITA.
Parcijalne i tranzitivnee zavisnosti mogu uzrokkovati problleme kod manipulisanja
m
a s podacim
ma, pa ih jee
poeljno ukkloniti.

Anomalije
Jednostavno korienje i mijenjanje podataka podrazumjeva prije svega spreavanje anomalija odravanja
podataka. Pod anomalijama odravanja podataka podrazumjevamo:
1. anomaliju dodavanja,
2. anomaliju brisanja,
3. anomaliju promjene.
Anomalija dodavanja (unoenja) javlja se u onim sluajevima kada su informacije o svojstvima jednog
objekta memorisane u bazi podataka kao dio opisa nekog drugog objekta.
Na primjer, u okviru opisa nastavnika memorisane su informacije o predmetu koji predaje ili katedre na kojoj
radi. Informacije o predmetu, odnosno katedri, nije mogue unijeti u bazu podataka sve dok ne postoji
bar jedan nastavnik koji taj predmet predaje, odnosno, dok ne postoji najmanje jedan nastavnik koji na toj
katedri radi.
Anomalija brisanja je inverzija anomalije dodavanja.
Neka su u okviru opisa svojstava nastavnika memorisane informacije o predmetu koji predaje. Svakim
brisanjem opisa nastavnika brie se i jedna kopija podataka o predmetu koji predaje. Kada se obriu podaci o
posljednjem nastavniku koji predaje neki predmet, bie obrisana i poslednja kopija podataka o predmetu. S
obzirom na to da pri brisanju podataka o nastavniku ne mislimo na druge posljedice, na ovaj nain mogue
je unititi podatke o predmetu, koji su potrebni i vani.
Anomalija promjene (auriranja) javlja se u sluaju kada promjenu podataka o jednom objektu treba izvriti
na vie od jedne kopije podataka.
Razmotrimo ponovo prethodni primjer gdje su podaci o predmetu i katedri memorisani u okviru opisa
nastavnika. U bazi podataka u jednom trenutku postoji toliko opisa katedre koliko nastavnika radi na toj
katedri.
Ako treba promjeniti podatke o opisu katedre (na primjer, naziv katedre), tada tu promjenu treba izvriti na
onoliko mjesta koliko nastavnika radi na toj katedri.
Ako se promjena ne izvri na svim kopijama nastaje situacija u kojoj o istom svojstvu jednog objekta
imamo vie razliitih tvrdnji od kojih bar jedna nije istinita.
Ovakvo stanje smatramo nekonzistentnom bazom podataka.

Tehnike normalizacije
Postoje sledee dve tehnike normalizacije:
1. Horizontalna normalizacija.
2. Vertikalna normalizacija,
Horizontalnom normalizacijom relacija se rastavlja na podskupove n-torki fragmente relacije koji
zadovoljavaju odreene uslove. Horizontalna normlizacija zasniva se na operacijama selekcije i unije.
Sama tehnika se koristi kod distribuiranih baza podataka.
Kod distribuiranih baza podataka relacija ne mora u potpunosti biti memorisana na jednoj lokaciji. Fragmenti
relacije memoriu se na pojedinim lokacijama, to bi se moglo koristiti za samu normalizaciju.
Vertikalna normalizacija je postupak kojim se proizvoljna nenormalizovana ema relacije transformie u
skup manjih i normalizovanih ema relacija.
Vertikalna normalizacija zasniva se na operacijama projekcije i prirodnog spajanja.
1. Pomou operacije projekcije relaciju vertikalno razbijamo na dve ili vie manjih relacija. Pri tome,
dolazi do cjepanja svake pojedine n-torke u relaciji.
2. Operaciju prirodnog spajanja koristimo da bi dokazali reverzibilnost, tj. da bi rekonstruisali polaznu,
nenormalizovanu relaciju.
Postoje sljedee dvije varijante vertikalne normalizacije:
1. normalizacija sintezom,
2. normalizacija dekompozicijom,
Normalizacija sintezom polazi od skupa obiljeja i od skupa zavisnosti zadatih na tom skupu obiljeja.
Postupak se ne izvodi u koracima ve se direktno formiraju relacione eme koje ispunjavaju uslove
zahtjevane normalne forme.
Normalizacija dekompozicijom zapoinje od proizvolje nenormalizoovane relacione eme i izvodi se u
koracima. Svakim korakom normalizacije relaciona ema prevodi se u viu normalnu formu, tako da se
polazni skup obiljeja deli u dva skupa i od svakog formira posebna relaciona ema.
Svaki korak normalizacije mora biti reverzibilan.
Vertikalna normalizacija dekompozicijom je najee koritana tehnika normalizacije, pa emo i mi
analizirati samo ove tehnike.
O normalizaciji se obino govori u obliku formi, a ovdje emo opisati samo prve tri forme mada se koriste i
ostale, sloenije forme (etvrta, peta, Boyce-Codd forma).

Forme no
ormalizaccije
Kratke i uprrotene definnicije prve trii normalne fo
forme bi glasile:
1.normalnaa formasvi entiteti moraju imati jeddinstveni iden
ntifikator (kllju) koji se m
moe sastojaati od jednogg
ili vie atribbuta. Svako polje
p
u tabelii mora sadraavati samo jeednu vrijedn
nost (atributi moraju biti jednostavni
j

ne smiju bitti sastavljeni od vie atrib

buta)
2.normalnaa formasvi atributi koji nisu dio kljuua moraju u potpunosti zavisiti o njeemu
3.normalnaa formasvi atributi koji nisu dio kljuua ne smiju
u biti meuso
obno zavisni
Osnovna prravila normalliziranih tabeela:
1. svakko polje tabeele trebalo bii predstavljatti jedinstven tip informaccije
2. svakka tabela moora imati prim
marni klju kkoji se sastoji od jednog ili
i vie polja u tabeli
3. za ssvaku jedinsttvenu vrijedn
nost primarnnog kljua mora postojatii jedna i sam
mo jedna vrijeednost u biloo
kojooj koloni poddataka, a ta se
s vrijednost mora odnositi na subjekt tabele
4. morra postojati mogunost
m
promjene biloo kojeg poljaa (osim polja u primarnom
m kljuu) bez utjecaja naa
biloo koje drugo polje.
Sa aspekta ddizajna baze podataka to znai da poddatke treba organizovati
o
tako da sve kkolone koje ne pripadajuu
primarnom kljuu zavise samo od iitavog primaarnog kljua.
Druga praviila kojih se treba
t
pridrav
vati u dizajnnu baze podaataka su dobrra, konzistent
ntna, logika, puna imenaa
za tabele i kkolone, kao i upotreba pu
unih rijei u ssamoj bazi podataka.
Standardne normalne forme
f
su ad
ditivne, dakkle ako je neki
n
model sveden na treu norm
malnu formu,,
automatski jje u drugoj i prvoj normaalnoj formi.

Prva norrmalna forrma
Prva normaalna forma odnosi
o
se naa grupisanje slinih podaataka u odvo
ojene tabele i definisanje primarnogg
kljua za svvaku tabelu.
Prva normaalna forma (1NF) postavllja dva osnovvna pravila za
z organizovaanu bazu poddataka:
1. Elim
minisanje duuplih kolona iz
i iste tabelee
2. Kreeiranje poseebne tabele za istu grrupu povezaanih podataaka i identiifikovanje svakog
s
redaa
jediinstvenom koolonom (prim
marni klju)
umije: svakii
To je istovrremeno i najjjednostavnijii i najtei konncept modellovanja podaataka. Principp se lako razu
atribut torrke mori saadrati sam
mo prostu ((atomsku) vrijednost.
v
To
T znai daa u tabeli treba
t
unositii
pojedinanee vrijednosti,, ne grupe ili kompozitnee objekte.
mi ako su sk
kalarni svi domeni
d
u kojjima su defiinisani njenii atributi.
Relacija je u prvoj norrmalnoj form
Za svoenjee relacije na 1NF, treba razloiti svakku ne-atomsk
ku vrijednost.
Ali ta je tano prosta vrrijednost?
U relaciji prikazanoj na
slici, atribuut Items (stavvke)
oigledno
sadri
v
vie
vrijednosti (tj. nije proost),
to znai daa relacija nijje u
U ovojj relaciji Item
ms nije skalarran
prvoj normaalnoj formi.
k
kao s inonim za prost
p
podatak. Slino maatmatici gdjje su skalarii
Pojam skallar se ovdje (kod BP) koristi
veliine kojje moemo izraziti
i
samo
o jednim poddatkom i meeusobno se mogu usporreivati sam
mo po jednojj
koordinatnooj osi, takoi kod
k baza ska
alarni podataak bi trebao imati
i
samo jeednu odrednnicu.
Prva normaalna forma odnosi se naa grupisanje slinih pod
dataka u odvo
ojene tabele i definisanje primarnogg
kljua za svvaku tabelu.
7

ardnim atributima
Problem sa nestanda
nom primjeruu (gdje se normalizacija
n
a
Meutim, too nije uvijekk tako oigledno i jednoostavno kao u predhodn
gotovo sam
ma namee).
Npr. datumii su nezgodnna oblast. On
ni se sastoje ood tri kompo
onente: dana,, mjeseca i ggodine. Da li bi ih trebaloo
uvati kao ttri odvojena atributa
a
ili kaao kombinacciju?
Do odgovorra moete dooi jeino na osnovu
o
semanntike prostorra problema koji razmatraate.
Ako va sisstem najee koristi svee tri komponnente datum
ma zajedna datum treba dda bude skallarni atribut..
Ukoliko sisttem ee obbrauje komp
ponente datuuma pojedinaano, bolje jee da ih uvatte u bazi pod
datci zasebnee
atribute. Naa primjer, mooda vam je dan nebitann, a zanimam
m samo mjeseec i godina. Ili, moda su vam vanii
samo dan i m
mesec. ali nee i godina. Takvi sluajevvi nisu ba eesti, ali posto
oje.
U specifinom sluaju datuma,
d
budu
ui da prograamiranje datu
umske aritbu
uter nije jednnostavno, olaakaete sebii
ivot ako daatumske atriibute kao tip podataka D
DateTime (daatum/vreme) koji kombinnuje sve tri komponentee
datuma pluss vreme.
Meutim, aatributi tipa DateTime mogu
m
biti uzr
zrok problem
ma kada se porede
p
pojeddinane kom
mponente. Too
naroito vai kada u pollju zanemaru
ujete komponnentu vremen
na.
Jo jedna ooblast u kojjoj ljudi imaaju problemaa s neskalam
mim (sloenim) vrijdnosttima jesu iffre (codes) i
indikatori ((flags).
Mnoge kom
mpanije dodeeljuju ifre predmeta
p
ili referentne oznake
o
koje su izraunatte vrijednostti. npr. netoo
nalik na RE
EF0010398, to
bi moglo
o znaiti da jee u pitanju prvi
p predmet zapoet marrta 1998. god
dine. Iako jee
malo vjerovvatno da e kompanija prihvatiti
p
da mijenja svojja pravila naa va zahtjevv, bila bi loa ideja da u
svom modelu podataka pokuate da pojedinanoo manipuliette dijelovimaa referentne ooznake.
Dugorono je znatno lake
l
da dijeelove referenntne oznake uvate kao
o zasebne atr
tribute: (VrsttaReference,,
RedniBrojP
Predmeta, Mjjesec, Godin
na). S takvim
m rjeenjem, odreivanje narednog brroja predmetta otvorenogg
u datoj godiini svodi se na
n jednostavaan upit nad j ednim atribu
utom i ne zah
htjeva dodataan rad. To zn
naajno utiee
na perform
manse, naroiito u klijentt/server okruuenjima, gdje za izdvaajanje vrijeddnosti iz sreedine nekogg
atributa mooe biti potreebno da se svaki
s
zapis ppojedinano ispituje na lokalnom kllijentskom raaunarima (ii
prenosi puteem mree), a ne na serveru baze podaataka.
Jo jedna vrsta neskaalarnog atrib
buta s kojim
m ljudi im
maju problem
ma jeste jeddnobitni in
ndikator. U
konvencionnalnim okruenjima za programiranje
p
e, uobiajen
na praksa je da se vie vvrijednosti lo
ogikog tipaa
grupie u jeednu rije i da se zatim tee vrijednosti uuitavaju i isspituju pomo
ou operatoraa nad bitovim
ma.
U konvenciionalnim okrruenjima zaa programiraanje, to je potpuno
p
prihvatljivo. U rrelacionim okruenjima,
o
,
nije. Ne saamo to se time naruav
va prva norm
malna formaa, ve je to izuzetno nezzgrapno i - uglavnom neefikasno.
Naalost, too je vrsta ogranienja
o
koje
k
je estto nametnuto
o iz istorijsk
kih razloga. Ako imate bilo kakvuu
mogunost izbora po tom
m pitanju, neemojte kodiirati vie od jednog podatka u jedann atribut.
Kad moratee da radite s nasljeenom
m strukturom
m podataka, uvijek moeete da raspakkujete podattke i da objee
verzije unessete u skup zapisa.
z
Postoji jo jjedna vrsta neskalarnih
n
vrijednosti
v
o kojima treb
ba voditi rau
una kada isppitujete da li je relacija u
prvoj normaalnoj formi, a to su grupee koje se ponnavljaju.
Na
N slici je prrikazana je relacija
r
In
nvoice (fakttura). Nekoo je u
nekom trenuutku odluio da
ku
upcima neee biti dozvoljjeno da
Ovaj modeel podataka ograniava
o
broj
b artikalaa koje kupac moe da kuppi
ku
upe vie od ttri razliita artikla.
a
Pitam se dda li je prethhodno razgo
ovarao o tom
me s direkto
orom prodaje? To je gootovo sigurn
no vjetakoo
ogranienjee koje je nam
metnuo sistem
m, a ne sam nnain poslov
vanja. Vjetaaka sistemskka ogranien
nja veoma suu
loa, a u ovoom sluaju i besmislena.
Jo jedan primjer grupee koja
se ponavlja prikazanje na
slici. Greeki nije tako
oigledna, a mnogi usppjeni
sistemi naapravljeni suu na
Ovvo je grupa koja
k se ponavvlja
osnovu slinnih modela.
8

Meutim, too je zapravo ista strukturaa kao ona naa predhodnoj slici i uzrok
k je istih probblema.
Zamislite kaako bi izgleddao upit kojii treba da utvvrdi kor. artiikli premailii plan za viee od 10 proccenata u biloo
kom trenutkku prvog trom
meseja.
ema relacij
ije je u 1NF, ako se moee prikazati u obliku potpune dvodimeenzionalne taabele i ako su
u vrijednostii
(jednostavni)
atributa u ssvakoj n-torrki relacije pojedinani
p
i) podaci ili se vrijednos
osti atributa ne mogu see
prikazati u oobliku pod-taablela

Druga no
ormalna fforma
Relacija je u Drugoj noormalnoj form
mi (2NF) akko je u 1NF i svi njeni neekljuni atribbuti funkcion
nalno zavisee
od primarnoog kljua (neekljuni atrib
buti su atribuuti koji nisu kandidati
k
za klju, niti dioo kandidata za klju)
Smjetanje podataka u drugu
d
normaalnu formu saastoji se od premjetanja
p
u druge tabeele onih podaataka koji suu
zavisni sam
mo od dijela kljua.
k
Osnovni zahhtjevi 2NF suu
1. Ukllanjanje podsskupova pod
dataka koji see nalaze u vie redova i njihovo
n
smet
tanje u poseb
bne tabele.
2. Kreeiranje veza izmeu
i
novih
h tabela i tabbela sa kojim
ma su spojenee korienjem
m spoljnih klj
ljueva
Dakle, 2NF
F ima za cilj smanjenje
s
ko
oliine reduddantnih podaataka, tako tto se oni izvvlae iz tabeele, stavljajuu
u nove tabele i kreiraju veze
v
izmeu
u ovih tabela..
Na primjer, klju na slicci
ProductNam
me (naziv arttikla),
SupplierNam
me (naziv
dobavljaa))}, ali polje
SupplierPhooneNumber
(telefonski bbroj dobavljaaa) zavisi
samo od atrributa SuplierName,
a ne od cijellog kombinoovanog
kljua.

a
relacije treba da budu zavisnii od cijelog kljua
k
Svi atributi
Ve smo naapomenuli da
d je posljediica toga reduundantnost, a posljedica redundantnoosti mogu biti neprijatnii
problemi oddravanja uskklaenosti po
odataka.
Ovo predstavlja
p
bbolji model.
d
druguu
Logiki gledano,, da biste dobili
norm
malnu formu,, pokuajte da
d izbjegnetee
da dv
va razliita eentiteta Products (artikli))
i Sup
ppliers (dobaavljai) predsstavite istom
m
relaciijom.
Ako entitete predstavite odvojenim
m
relaciijama, time ete ne samo
o eliminisatii
redun
ndantnost, ve ete dobiti i
mehaanizam za skkladitenje po
odataka kojee
na drugi nain nee biste mogli da unesete.

U primjeru na slici, posttaje mogue da podatke o odreenom

m dobavljau unesete prij e nego to up
piete ijedann
podatak o aartiklima kojee vam on dob
bavlja. To nee bi bilo mog
gue u prvoj relaciji zatoo to nijedna komponentaa
primarnog kkljua ne mooe da se izosstavi.
9

Trea no
ormalna fo
orma
Relacija je u treoj norrmalnoj form
mi ako je u ddrugoj norm
malnoj formi i ako su svvi atributi koji
k nisu dioo
nijednog klljua meussobno nezav
visni, (ako svvi njeni neklljuni atributi netranzitivvno zavise od primarnogg
kljua).
Osnovni zahhtjevi 3NF
1. Tabbela je u 1NF
F i 2NF
2. Ukklonjene su kolone
k
koje nisu
n potpuno zavisne od primarnog
p
klljua.
Praktino ppostavlja se pitanje:
p
Da lii postoje koloone koje ne zavise
z
u potp
punosti od prrimarnog klju
ua?
Trea norm
malna forma sastoji
s
se od uklanjanja ssvih podatak
ka u tabelamaa koji ne zavvise jedino od primarnogg
kljua. Drugim rijeimaa, treba zadrrati samo p odatke koji su zavisni od
o primarnogg kljua, a one
o koji nisuu
treba premjeestiti u nove tabele i form
mirati primarrni klju za njih.
n

ormalnoj form
rmi
Ova relacijaa nije striktnno u treoj no
Dvije relacij
ije prikazanee na slici ispo
od su tehnikki su ispravniije
O
Ova relacija je u treojj
noormalnoj forrmi

Jedina stvaarna prednost koju pruaa ovo rjeennje jeste mo

ogunost da se automatsski potrai odgovarajui
o
i
potanski bbroj pri unoenju novih zapisa, to korisniku ttedi nekoliko pritisaka nna tastere. To
T nije takoo
zanemarljivva prednost, ali vjerovatn
no postoje boolji naini daa se objezbedi takva funk
nkcionalnost, u kojoj nijee
potrebna doodatna operaccija spajanja relacija kad god se referrencira odre
ena adresa.
I ovde je issti princip kaao i pri dono
oenju svih ddrugih odluk
ka tokom postupka modeelovanja pod
dataka: kad i
kako ete reealizovati treeu normalnu
u formu mo ete odrediti samo
s
na osno
ovu semantikke modela.
Nemogue jje navesti prravila koja bi
b uvijek vaila, ali postoje odreenee smjernice. Trebalo bi da napravitee
zasebnu relaaciju u sljedeeim sluajev
vima:
Enttitet je vaan dio modela, ili
Poddaci se esto mijenjaju, illi
modela.
Siguurni ste da ee vam to pru
uiti odreenee tehnike prrednosti pri realizovanju
r
Potanski brojevi se mijjenjaju, ali ne
n esto, a u veini sistem
ma nisu samii po sebi vani. Osim tog
ga, odvojenaa
tabela potaanskih brojevva ne bi bila praktina u veini aplikacija iz stvarrnog ivota zzbog razliitih pravila zaa
odreivanjee potanskih brojeva
b
(u SAD).
10

Praktian primjer normalizacije

Daemo primjer kako da od neureene (nenormalizovane) baze dobijemo model u 3NF formi.
Krenuemo od jednostavne strukture; imamo spisak lanova foruma koji imaju nekakvo znanje o raznim
materijama. Neki lanovi znaju o muzici, neki o hardware-u dok se neki bolje snalaze sa linux-om; naravno,
postoje i oni koji vrlo dobro poznaju i hardware i muziku. Primjer jednostavne tabele bi izgledao ovako:
TABELA:KOMPLET
Id
korisnik
1
Pera Peri
2
Mika Miki
3
ika iki
4
Mali Perica
5
Mali ika

Zivi
Srbija
Srbija
Srbija
Srbija
BiH

Znanje
Audio
Video
Audio, Video, Hardware,, Windows
Audio, Video, Baze, Hardware, Windows, Linux, Programiranje
Programiranje, Hardware

Ovo je tipian primjer loe dizajnirane baze sa samo jednom tabelom u kojoj se nalaze svi podaci.
Ako elimo da saznamo koji korisnik zna video moramo proi kroz sve korsnike, provjeriti sadraj polja
znanje i pregledati prilino nepregledno polje znanje te otkriti da li dotini korisnik zna video ili ne.
Mane ovakve organizacije su oigledne (brzina, preglednost) te je ovo vrlo nepraktian nain za uvanje
informacija.
Svoenje modela na prvu normalnu formu
Razdvajanje repetitivnih podataka u zasebne tabele nau strukturu dovodi u prvu normalnu formu.
Iz naeg primjera (gdje je sve bilo nagurano u istu tabelu), dobijamo 2 odvojene tabele:
Id
1
2
3
4
5

TABELA: KORISNIK
Korisnik
Zivi
Pera Peri
Srbija
Mika Miki
Srbija
ika iki
Srbija
Mali Perica
Srbija
Mali ika
BiH

Znaje_ID
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

11

TABELA: ZNANJE
korisnik_ID Znanje_IME
1
Audio
2
Video
3
Audio
3
Video
3
Hardware
3
Windows
4
Audio
4
Video
4
Baze
4
Hardware
4
Windows
4
Linux
4
Programiranje
5
Hardware
5
Programiranje

Svodjenje modela na drugu norm

malnu form
mu
Ako pogleddamo tabelu ZNANJE iz prethodn og primjera gdje smo sv
veli model nna prvu norm
malnu formu,,
primjetiem
mo da nam see podaci dup
pliciraju. Za razliku od taabele KORISNIK gdjee atribut KO
ORISNIK_ID
D
definie slogg tabele, u taabeli KORISNIK slog deefiniu KORIISNIK_ID i ZNANJE_ID
Z
D atributi zajedno. Ovo u
nekim sluaajevima moe da ima smisla, ali u naem sluaju, gdje im
me znanja realno nije ni u kakvojj
relaciji sa kkorisnikom i bezrazlono
o se multipliccira u tabeli, moemo zak
kljuiti da naam se podacci duplirajuu
to se odraava na prosttor potreban za uvanje isstih, oteava i usporava operacije
o
sa bbazom.
Ako na prim
mjer elite da
d promjenitte ime jednoog znanje (na primjer elite da A
Audio postaane Rad saa
zvukom) m
morate to im
me promjenitti na vie m
mjesta, umjessto samo naa jednom (annomalija pri promjeni)..
Dalje, pretppostavite da mali

perica ode sa foruuma; u tom slluaju treba obrisati

o
sve sslogove vezaane za njega;;
u tom sluaju, potpunoo e nestati referenca dda je znanjee Linux postojalo na forumu (an
nomalija prii
brisanju).
Da bi ste zaaobili ove annomalije, pottrebna vam j e druga norrmalna form
ma.
Da bi razvili nau bazzu u drugu no
ormalnu form
mu, potrebno
o je da razdvo
ojimo atributte koji zavisee od oba
kljua koji ddefiniu tabeelu ZNANJE
E. Rezultat e biti dve taabele:
TABELA: KORISN
NIK_ZNANJ
JE
ZNANJE_ID
Z
KO
ORISNIK_ID
1
1
2
2
1
3
2
3
3
3
4
3
1
4
2
4
3
4
4
4
5
4
6
4
7
4
3
5
7
5

TABEL
LA: ZNANJE
E
ZNANJJE_ID
ZNANJE_
_IME
1.
Audio
2.
Video
3.
Hardware
4.
Windows
5.
Baze
6.
Linux
7.
Programiraanje

12

modela na ttreu norm

malnu formu
u
Svoenje m
Ako pogleddamo malo bolje
b
tabelu KORISNIK
K iz primjera za drugu normalnu foormu, videeemo da iakoo
ispunjava i prvu i druguu normalnu formu,
fo
atribuut ZIVI nijee direktno zaavistan od ID
D-a korisnikaa (primarnogg
kljua). Da bi postigli treu
t
normallnu formu, taaj podatak mora
m
da se odvoji
o
u zaseebnu tabelu. Zato? Akoo
uzmemo naa primjer da mali zikicaa napusti foorum, te se slogovi
s
koji njega
n
definiu obriu, neestae trag o
BIH (anoomalija pri brisanju)
b
ili ako Srbija ponovo prromjeni ime u Ua Srbiija sa okolin
nom, to imee
moramo proomjeniti na vie
v od jedno
og mjesta (an
nomalija prii promjeni). Razlaganje nna treu norm
malnu formuu
zahjteva da podatak o Z
ZIVI prebaccimo u zasebban entitet.

TABELA: DRZAVA
DRZAVA
A_ID
DRZAVA_IM
ME
1
Srbija
2
BiH

KORISN
NIK_ID
1
2
3
4
5

13

TAB
BELA: KORIISNIK
KORISNIK_IM
ME
peera peric
miika mikic
zik
kica zikic
maali perica
maali zikica

DRZAVA_ID
1
1
1
1
2

Primjer ii analiza a
anomalija
a
Analiza annomalija i formalna
fo
primjena relaccionoh raun
na je kompleksan probblem koji see najbolje i
najjednostavvnije usvajaa praksom. Primjer
P
i koomentari koji slijede su dovoljno illustrativani za
z shvatanjee
principa kojji se trebaju potovati
p
da bi mogli dizzajnirati bazu
u podataka.
1NF i anom
malije
Neka na poetku imamoo nenormalizzovanu bazu koje jednosttavno atomiziramo i svvedemo na 1N
NF.

INSERT annomalije Nee moe se dodati predmett bez lekcije

UPDATE aanomalije Prrilikom prom
mjene podataaka predmetaa P1, moraju se izmjeniti dva reda tab
bele.
DELETE annomalije Akko izbriemo
o P3, briemoo i N2.
2NF
1NF nije u 22NF Postoji FZ{Predmet, Lekcija} {Nastavniik, Odjel}
ali i{Predm
met} {Nastaavnik, Odjel}
Nastavnik i Odjel u parcijalnoj zavisnosti ood primarno
og kljua.svoenje na 22NF preko objanjenjaa
funkcionalnne zavisnosti:

1NF

Rjeeni prooblemi sa 2N
NF
Problemi u 1NF
INSERT N
Ne moe se dodati
d
predm
met bez Lekccije.
UPDATE Izmjena poddataka nastav
vnika za preddmet P1,
mora se uraaditi u dva zaapisa (reda).
DELETE Ako se izbriie P3, brie se iN2.
U 2NF prvaa dva problem
ma su otklonj
njena, ali ne i trei

14

Preostali prroblemi u 2N
NF
INSERT anomalije
Ne moe se dodati nastaavnik koji ne predaje
nijedan pred
dmet.
UPDATE an
nomalije
Da bi promiijenili odjel nnastavniku N1
N moraju se
izmijeniti 2 reda.
DELETE an
nomalije
Ako se obrie P3 brie ssei N2

3NF

Problemi u 2NF
INSERT annomalije- Ne moe se dod
dati nastavnikk koji ne preedaje nijedan
n predmet.
UPDATE aanomalije Da
D bi promijeenili odjel nasstavniku N1 moraju se izzmijeniti 2 reeda.
DELETE annomalije Akko se obrie P3 brie sei N2.
U 3NF svi oovi problemii su rijeeni(zza ovu relacij
iju ali 3NF i dalje moee imati anom
malije!)

Dalje norrmalizova
anje
Prve tri norm
malne formee bile su opissane u Coddoovoj prvobitn
noj formulacciji relacionee teorije. U velikoj veinii
sluajeva onne su dovoljnne.
Vie normaalne forme suu bazirane naa drugoj vrstii zavisnosti.
etvrta norm
malna formaa uklanje viee-vrjednosnee zavisnosti.
Peta normallna forma ukklanja zavisnosti udruivaanja.

pojednost
tavljeno:

Prvu norm
malna for
rma (1NF):
: Relacij a zadovol
ljava 1NF ako je vrijednos
st svakog
g
atributa jednostru
uka i nedjeljiva.
Prva normalnna forma (1NF)
F)
postavlja najoosnovnija pravvila za organizo
ovanu bazu poddataka:
Eliminisanje dduplih kolona iz iste tabele
Kreiranje possebne tabele zaa istu grupu povezanih podaataka i identifi
fikovanje svako
og reda jedins
nstvenom kolon
nom (primarnii
klju)
Druga nor
rmalna form
ma: Relaci
ija je u d
drugoj nor
rmalnoj for
rmi (2NF) ako je u 1NF i ako
o
su svi neprimarni atributi
a
potpuno
p
fun
nkcionalno
o zavisni o primarno
om kljuu.
Relacija je u D
Drugoj normallnoj formi (2N
NF) ako je u 1N
NF i svi njeni nekljuni
n
atribu
uti
funkcionalno zavise od prim
marnog kljua (nekljuni atribbuti su atributii koji nisu kand
didati za klju,, niti dio kandiidata za klju)
Trea nor
rmalna form
ma: Relaci
ija je u t
treoj nor
rmalnoj for
rmi (3NF) ako je u 2NF i ako
o
ne sadri
i tranziti
ivne zavis
snosti. Pr
reciznije,
, relacija
a R je u 3NF ako za svaku
u
funkcionalnu zavisn
nost X A u R, tak
kvu da A nije
n
u X, vrijedi: X sadri klju
k
za R
ili je A primarni atribut.
a
Uklonjene su kolone koje nisu potpuno zaavisne od prim
marnog kljua.
Postoji i pobooljana 3NFa se zove i Boycee-Coddova noormalna forma (BCNF).
Relacija je u Boyce
e-Codd-ovo
oj normalno
oj formi (BCNF)
(
ako
o je svaka njena det
terminanta
a
i kandida
at za klju
. Oito relacija
r
k
koja je u BCNF tako
e i u 2NF
F i 3NF. No
N postoje
e
relacije koje su u 3NF, no nisu
n
u BCNF
F.
Norme 4NF i 5NF su prvennstveno od teorrijskog znaajaa, jer je teko u praksi nai relacije
r
koje jeesu u BCNF, a nisu u 4NF i
5NF.

15

Razlozi zbog kojih se moe odustati od normalizacije

Za veinu praktinih primjera dovoljno je relacije normalizovati do 3NF. Ponekad je potrebno neku
relaciju i dalje normalizovati do BCNF ili 4NF. Peta normalna forma, koja se takoe navodi u literaturi, nije
od praktinog znaaja.
Postoje razlozi zbog kojih ponekad moemo odustati od pune normalizacije.
Pogledajmo dva takva razloga.
1.Sloeni atribut .
Deava se da nekoliko atributa u relaciji ine cjelinu koja se u aplikacijama nikad ne rastavlja na sastavne
djelove.
Na primjer, posmatrajmo relaciju KUPAC ( PREZIME IME, POTANSKI_BROJ, GRAD, ULICA ) .
Strogo govorei, GRAD je funkcionalno zavisan o POTANSKI_BROJ, pa relacija nije u 3NF. No mi znamo
da POTANSKI BROJ, GRAD i ULICA ine cjelinu koja se zove adresa.
Budui da se podaci iz adrese koriste i auriraju "u paketu", ne moe doi do prije pominjanih anomalija.
Nije preporuljivo razbijati ovu relaciju na dvije.
2.Efikasno itanje podataka .
Normalizacijom se velike relacije razbijaju na mnogo manjih. Kod itanja je esto potrebno podatke iz
malih relacija ponovo sastaviti u vee n-torke. Uspostavljanje veza medu podacima u manjim relacijama
traje znatno due nego itanje podataka koji su ve povezani i upisani u jednu veliku relaciju.
Projektant baze podataka treba da procjeni kada treba provesti normalizaciju do kraja a kada ne.
Za tu procjenu je vano razumjevanje znaenja podataka i naina kako e se oni koristiti.

16

Dodatak: Procedure i algoritmi

GENERAL PROCEDURE FOR ACHIEVING A NORMALIZED SET OF RELATIONS
1.Identify the attributes of the database.
2. Group related attributes into relations.
3. Identify the candidate keys for each relation.
4. Select the most useful primary key from among the set of candidate keys.
5. Identify and remove all repeating groups.
The result is a relation in 1NF.
6. If any of the resulting relations have identical primary keys, then combine them into a single relation.
7. Identify all functional dependencies between the attributes of a relation and its primary key.
8.Decompose the relations to a form where each nonkey attribute is dependent on all the attributes of the key. Do this
by taking projections of the 1NF relation that eliminate any non full functional dependencies.
The result is a set of relations in 2NF.
9. If any of the resulting relations have identical primary keys, then combine them into a single relation.
10. Identify any transitive dependencies in the relations decomposed to this point.
1. Examine relations for dependencies among nonkey attributes.
2.Examine relations for dependencies among key within the primary key.
11. Remove transitive dependencies by decomposition. Do this by taking projections of the 2NF relations produced by
steps 8 and 9 that eliminate any transitive functional dependencies.
The result is a set of relations in 3NF.
12. If any of the resulting relations have identical primary keys, then combine them into a single relation if and only if
no transitive dependencies result from the combination.
13. Remove any remaining functional dependencies from the 3NF set of relations. Do this by taking projections of the
3NF relations produced by steps 8 and 9 that eliminate any remaining functional dependencies where the determinant is
not a candidate key.
The result is a set of relations in BCNF.
14. Remove any multivalued dependencies that are not also functional dependencies. Do this by taking projections of
the BCNF relations produced by step 13.
The result is a set of relations in 4NF.
15. The likelihood that any join dependencies not implied by the candidate keys remain by this point is virtually nil. If
you can identify any such relations, then take projections of them to eliminate the non-implied join dependencies.
The result is a set of relations in 5NF.
16. Particularly for temporal data, but sometimes to eliminate nulls as well, take projections to 6NF.
17. End of procedure.

17

alizacije
Algoritam 2NF norma

Algoritam 3NF norma

alizacije

18