Normalizacija baza podataka
Sadržaj
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
Treća normalna forma ......................................................................................................................................................................10
Praktičan primjer normalizacije .......................................................................................................................................................11
Svođenje modela na prvu normalnu formu .................................................................................................................................11
Svodjenje modela na drugu normalnu formu ..............................................................................................................................12
Svođenje modela na treću normalnu formu ................................................................................................................................13
Primjer i analiza anomalija ...............................................................................................................................................................14
1NF i anomalije ..........................................................................................................................................................................14
2NF „ ..........................................................................................................................................................................................14
3NF… .........................................................................................................................................................................................15
Dalje normalizovanje .......................................................................................................................................................................15
Razlozi zbog kojih se može 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
1
Normalizacijabazepodataka
Normalizacija baze podataka je proces efikasnog organizovanja podataka u bazi podataka. Normalizacija je
tehnika dizajna baze podataka kojom se na osnovu izvjesnih kriterijuma određuje sadržaj tabela (tj.koje
kolone treba da obuhvataju tabele i njihova struktura ključa).
Normalizacija baze podataka je postupak kojim se iz danog modela bez podataka nastoji otkloniti potreba za
višestrukim ponavljanjem istih podataka (redudansa podataka). Naime, osim što (nekorisno) troši prostor,
višestruko zapisivanje istog podatka otežava (i/ili onemogućava) mijenjanje sadržaja baze podataka.
Osnovna ideja je da se eliminiše nepotrebno dupliranje ne-ključnih podataka u tabelama te da se tako smanji
veličina prostora koju baza zauzima na disku i da su podaci logično uskladišteni.
Cilj normalizacije možemo izraziti riječima: 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 (skladištenje istih podataka na više mjesta u bazi podataka)
2. Osiguravanje da su zavisnosti podataka logične (u jednoj tabeli se nalaze samo povezani podaci)
Odnosno, osnovni cilj relacionog modela podataka je da odgovarajuća baza podataka koja:
1. ne sadrži redundansu,
2. se može jednostavno koristiti i mjenjati.
Pod redundansom podrazumjevamo višestruko memorisanje iste informacije u bazi podataka. Potpuno
eliminisanje redundanse podataka u bazi podataka je skoro nemoguće ostvariti. Realni cilj pri projektovanju
baze podataka je kontrolisana redundansa podataka.
Bitna osobina koja se očekuje od normalizacije je reverzibilnost tj. da ne smije doći do gubitka informacija
sadržanih u polaznoj relaciji. Polazeći od skupa normalizovanih relacija, mora biti moguća rekonstrukcija
polazne nenormalizovane relacije.
Jedan od ključnih ciljeva relacione baze podataka je da se spriječi nepotrebno dupliranje podataka.
U stvari, ovo je jedan od glavnih razloga zašto se koriste relacione baze podataka, a ne fajlovi, koji podatke
skladište u jednoj tabeli.
Ponekad se klasa ili objekat dizajnira korektno (zavisi koji model podataka se koristi), a u relacionoj šemi se
tek uoči problem.
Normalne forme daju formalne kriterije prema kojima se utvrđuje da li model podataka ispunjava prethodne
zahtjeve. Normalizacija je proces provjere uslova normalnih formi i po potrebi svođenje šeme relacije na
oblik koji zadovoljava isti.
Normalizacija je proces primjene skupa pravila na postojeći dizajn baze, uglavnom da bi se postigla
minimalna redudansa podataka.
Uobičajeno se normalizacija predstavljaju kao proces od tri koraka, koji se vezuje za normalne forme, koje
se mogu obaviti u skoro algoritamskom poretku.
U praksi, češće se pravila postepeno primjenjuju, dok se šema svake relacije ne razvije na način na koji se
dobija iz dijagrama E-R modela ili nekog drugog modela (npr. UML).
Konačna struktura tabela treba da bude ista bez obzira koji se metod (ili kombinacija metoda) primenjuje.
Teorija normalizacije nije ništa drugo nego formalizacija nekih intuitivno prihvatljivih principa o
"zdravom" oblikovanju šeme. Ukoliko već na početku dobro uočimo sve potrebne entitete, atribute i veze,
tada nam nikakva daljnja normalizacija neće biti potrebna. No ako je polazna relaciona šema bila loše
oblikovana, tada će postupak normalizacije ispraviti te greške.
2
Funkcion
nalnazav
visnost
ut ili skup attributa koji ppredstavljaju nadključ zaa
Loša funkccionalna zavvisnost se deešava kada ppostoji atribu
neke atributte, ali ne i zaa cijelu relaciiju. Ovakvi aatributi se nazzivaju podkljjučevi (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
međusobno isključivi. 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 između skupova atributa možete
predstaviti kao na slici. U tekstu
u se funkciionalna zav
visnost
izražava kaoo X→Y, što se čita kao „X
„ funkcionaalno određujee Y“.
vaka torka koja
k
sadrži istu vrijedn
nost atributaa
Na primjerr, u relaciji prikazanoj na predhoddnoj slici, sv
{CategoryN
Name}, imaćće istu vrijeednost i atrributa {Desccription}. Zbog toga m
možemo reći da atributt
CategoiyNaame funkcionnalno određuj
uje atrribut D
Description.
Imajte u viidu da funkccionalna zav
visnost ne vvaži uvijek i u suprotn
nom smjeru:: poznavanjee vrijednostii
atributa Desscription ne omogućava
o
nam
n da utvrddimo i odgov
varajuću vrijeednost atribuuta CategoiyN
Name.
Dijagrami ffunkcionalnee zavisnosti obično
o
su jasnni sami po seebi.
U praktičniim aplikacijjama, funkciionalna zaviisnost je zg
godan oblik da se izrazzi nešto što
o je priličnoo
razumljivo samo po sebbi: svaka relaacija će uvijeek imati odreeđeni 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 sadržati izvvjesnu redun
ndantnost i biiće potrebno normalizovaanje.
Atribut možže biti funkciionalno zavisstan ili u odnnosu na drug
gi atribut ili u odnosu na kkombinaciju atributa.
Nije moguđđe odrediti niivo normalizacije DB moodela bez razzumevanja međusobnih
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 A→C sam
mo zato što A→B
A
i B→C..
Višeznačnaa zavisnost
Višeznačna zavisnost je
j potpuna veza dva s eta atributa u relaciji. Za razliku od potpunee zavisnosti,,
utni u relacijii te je višeznaačna zavisno
ost specijalnii
višeznačna zavisnost zaahjteva da određeni tuplovvi butu prisu
slučaj 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 može rekrreirati vezivaanjem više 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 jednoznnačno određu
uje vrijednosst od B. Dak
kle ako u isto
o vrijeme poostoje u R dv
vije n-torke s
jednakom vvrijednošću A,
A tada te n-to
orke moraju imati jednak
ku vrijednostt B.
Analogna ddefinicija prim
mijenjuje se i za slučaj kaad su A i B slloženi atribu
uti (dakle skuupovi atributaa).
Kao primjeer, razmotriimo sljedeću
u (loše 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 (složenom
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 kključu, no ta zavisnost nee mora biti pootpuna.
Na primjer OCJENA je potpuno fun
nkcionalno zzavisna o priimarnom klju
uču (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
ključu, buduući da su zavvisni samo o BR_ISPITA,, a ne i o BR_
_INDEKSA.
Za BR_SOB
BE_NASTAV
VNIKA se kaže da je trranzitivno zavisan
z
o BR_ISPITA,
B
bbudući 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
poželjno ukkloniti.
4
Anomalije
Jednostavno korišćenje i mijenjanje podataka podrazumjeva prije svega sprečavanje anomalija održavanja
podataka. Pod anomalijama održavanja podataka podrazumjevamo:
1. anomaliju dodavanja,
2. anomaliju brisanja,
3. anomaliju promjene.
Anomalija dodavanja (unošenja) javlja se u onim slučajevima 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 moguće 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 briše se i jedna kopija podataka o predmetu koji predaje. Kada se obrišu podaci o
posljednjem nastavniku koji predaje neki predmet, biće obrisana i poslednja kopija podataka o predmetu. S
obzirom na to da pri brisanju podataka o nastavniku ne mislimo na druge posljedice, na ovaj način moguće
je uništiti podatke o predmetu, koji su potrebni i važni.
Anomalija promjene (ažuriranja) javlja se u slučaju kada promjenu podataka o jednom objektu treba izvršiti
na više 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 izvršiti na
onoliko mjesta koliko nastavnika radi na toj katedri.
Ako se promjena ne izvrši na svim kopijama nastaje situacija u kojoj o istom svojstvu jednog objekta
imamo više različitih tvrdnji od kojih bar jedna nije istinita.
Ovakvo stanje smatramo nekonzistentnom bazom podataka.
5
Tehnikenormalizacije
Postoje sledeće dve tehnike normalizacije:
1. Horizontalna normalizacija.
2. Vertikalna normalizacija,
Horizontalnom normalizacijom relacija se rastavlja na podskupove n-torki – fragmente relacije koji
zadovoljavaju određene 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 memorišu se na pojedinim lokacijama, što bi se moglo koristiti za samu normalizaciju.
Vertikalna normalizacija je postupak kojim se proizvoljna nenormalizovana šema relacije transformiše u
skup manjih i normalizovanih šema relacija.
Vertikalna normalizacija zasniva se na operacijama projekcije i prirodnog spajanja.
1. Pomoću operacije projekcije relaciju vertikalno razbijamo na dve ili više 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 sljedeće dvije varijante vertikalne normalizacije:
1. normalizacija sintezom,
2. normalizacija dekompozicijom,
Normalizacija sintezom polazi od skupa obilježja i od skupa zavisnosti zadatih na tom skupu obilježja.
Postupak se ne izvodi u koracima već se direktno formiraju relacione šeme koje ispunjavaju uslove
zahtjevane normalne forme.
Normalizacija dekompozicijom započinje od proizvolje nenormalizoovane relacione šeme i izvodi se u
koracima. Svakim korakom normalizacije relaciona šema prevodi se u višu normalnu formu, tako da se
polazni skup obilježja deli u dva skupa i od svakog formira posebna relaciona šema.
Svaki korak normalizacije mora biti reverzibilan.
Vertikalna normalizacija dekompozicijom je najćešće korištana tehnika normalizacije, pa ćemo i mi
analizirati samo ove tehnike.
O normalizaciji se obično govori u obliku formi, a ovdje ćemo opisati samo prve tri forme mada se koriste i
ostale, složenije forme (četvrta, peta, Boyce-Codd forma).
6
Formeno
ormalizaccije
Kratke i uprroštene definnicije prve trii normalne fo
forme bi glasile:
1.normalnaa forma–svi entiteti moraju imati jeddinstveni iden
ntifikator (klljuč) koji se m
može sastojaati od jednogg
ili više atribbuta. Svako polje
p
u tabelii mora sadržaavati samo jeednu vrijedn
nost (atributi moraju biti jednostavni–
j
–
ne smiju bitti sastavljeni od više atrib
buta)
2.normalnaa forma–svi atributi koji nisu dio kljuuča moraju u potpunosti zavisiti o njeemu
3.normalnaa forma–svi atributi koji nisu dio kljuuča ne smiju
u biti međuso
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 više polja u tabeli
3. za ssvaku jedinsttvenu vrijedn
nost primarnnog ključa 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 mogućnost
m
promjene biloo kojeg poljaa (osim polja u primarnom
m ključu) bez utjecaja naa
biloo koje drugo polje.
Sa aspekta ddizajna baze podataka to znači da poddatke treba organizovati
o
tako da sve kkolone koje ne pripadajuu
primarnom ključu zavise samo od čiitavog primaarnog ključa.
Druga praviila kojih se treba
t
pridržav
vati u dizajnnu baze podaataka su dobrra, konzistent
ntna, logička, puna imenaa
za tabele i kkolone, kao i upotreba pu
unih riječi u ssamoj bazi podataka.
Standardne normalne forme
f
su ad
ditivne, dakkle ako je neki
n
model sveden na treću norm
malnu formu,,
automatski jje u drugoj i prvoj normaalnoj formi.
Prvanorrmalnaforrma
Prva normaalna forma odnosi
o
se naa grupisanje sličnih podaataka u odvo
ojene tabele i definisanje primarnogg
ključa 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 najteži konncept modellovanja podaataka. Principp se lako razu
atribut torrke mori saadržati sam
mo prostu ((atomsku) vrijednost.
v
To
T znači daa u tabeli treba
t
unositii
pojedinačnee 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 svođenjee relacije na 1NF, treba razložiti svakku ne-atomsk
ku vrijednost.
Ali šta je taččno prosta vrrijednost?
U relaciji prikazanoj na
slici, atribuut Items (stavvke)
očigledno
sadrži
v
više
vrijednosti (tj. nije proost),
što znači daa relacija nijje u
U ovojj relaciji Item
ms nije skalarran
prvoj normaalnoj formi.
k
kao s inonim za prost
p
podatak. Slično maatmatici gdjje su skalarii
Pojam skallar se ovdje (kod BP) koristi
veličine kojje možemo izraziti
i
samo
o jednim poddatkom i meeđusobno se mogu usporređivati 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 sličnih pod
dataka u odvo
ojene tabele i definisanje primarnogg
ključa za svvaku tabelu.
7
ardnimatributima
Problemsanestanda
nom primjeruu (gdje se normalizacija
n
a
Međutim, too nije uvijekk tako očigledno i jednoostavno kao u predhodn
gotovo sam
ma nameće).
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 možete dooći jeino na osnovu
o
semanntike prostorra problema koji razmatraate.
Ako vaš sisstem najčešćće koristi svee tri komponnente datum
ma zajedna datum treba dda bude skallarni atribut..
Ukoliko sisttem češće obbrađuje komp
ponente datuuma pojedinaačno, bolje jee da ih čuvatte u bazi pod
datci zasebnee
atribute. Naa primjer, moožda vam je dan nebitann, a zanimam
m samo mjeseec i godina. Ili, možda su vam važnii
samo dan i m
mesec. ali nee i godina. Takvi slučajevvi nisu baš čeesti, ali posto
oje.
U specifičnom slučaju datuma,
d
budu
ući da prograamiranje datu
umske aritbu
uter nije jednnostavno, olaakšaćete sebii
život ako daatumske atriibute kao tip podataka D
DateTime (daatum/vreme) koji kombinnuje sve tri komponentee
datuma pluss vreme.
Međutim, aatributi tipa DateTime mogu
m
biti uzr
zrok problem
ma kada se porede
p
pojeddinačne kom
mponente. Too
naročito važži kada u pollju zanemaru
ujete komponnentu vremen
na.
Još jedna ooblast u kojjoj ljudi imaaju problemaa s neskalam
mim (složenim) vrijdnosttima jesu šiffre (codes) i
indikatori ((flags).
Mnoge kom
mpanije dodeeljuju šifre predmeta
p
ili referentne oznake
o
koje su izračunatte vrijednostti. npr. neštoo
nalik na RE
EF0010398, što
š bi moglo
o značiti da jee u pitanju prvi
p predmet započet marrta 1998. god
dine. Iako jee
malo vjerovvatno da će kompanija prihvatiti
p
da mijenja svojja pravila naa vaš zahtjevv, bila bi lošša ideja da u
svom modelu podataka pokušate da pojedinačnoo manipulišette dijelovimaa referentne ooznake.
Dugoročno je znatno lakše
l
da dijeelove referenntne oznake čuvate kao
o zasebne atr
tribute: (VrsttaReference,,
RedniBrojP
Predmeta, Mjjesec, Godin
na). S takvim
m rješenjem, određivanje 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
načajno utičee
na perform
manse, naročiito u klijentt/server okruuženjima, gdje za izdvaajanje vrijeddnosti iz sreedine nekogg
atributa moože biti potreebno da se svaki
s
zapis ppojedinačno ispituje na lokalnom kllijentskom raačunarima (ii
prenosi puteem mreže), 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 okružženjima za programiranje
p
e, uobičajen
na praksa je da se više vvrijednosti lo
ogičkog tipaa
grupiše u jeednu riječ i da se zatim tee vrijednosti uučitavaju i isspituju pomo
oću operatoraa nad bitovim
ma.
U konvenciionalnim okrruženjima zaa programiraanje, to je potpuno
p
prihvatljivo. U rrelacionim okruženjima,
o
,
nije. Ne saamo što se time narušav
va prva norm
malna formaa, već je to izuzetno nezzgrapno i - uglavnom neefikasno.
Nažalost, too je vrsta ograničenja
o
koje
k
je čestto nametnuto
o iz istorijsk
kih razloga. Ako imate bilo kakvuu
mogućnost izbora po tom
m pitanju, neemojte kodiirati više od jednog podatka u jedann atribut.
Kad moratee da radite s nasljeđenom
m strukturom
m podataka, uvijek možeete 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 raču
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 odluččio da
ku
upcima nećee biti dozvoljjeno da
Ovaj modeel podataka ograničava
o
broj
b artikalaa koje kupac može da kuppi
ku
upe više od ttri različita artikla.
a
Pitam se dda li je prethhodno razgo
ovarao o tom
me s direkto
orom prodaje? To je gootovo sigurn
no vještačkoo
ograničenjee koje je nam
metnuo sistem
m, a ne sam nnačin poslov
vanja. Vještaačka sistemskka ograničen
nja veoma suu
loša, a u ovoom slučaju i besmislena.
Još jedan primjer grupee koja
se ponavlja prikazanje na
slici. Greeški nije tako
očigledna, a mnogi usppješni
sistemi naapravljeni suu na
Ovvo je grupa koja
k se ponavvlja
osnovu sličnnih modela.
8
Međutim, 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 premašilii plan za višee od 10 proccenata u biloo
kom trenutkku prvog trom
mesečja.
Šema relacij
ije je u 1NF, ako se možee prikazati u obliku potpune dvodimeenzionalne taabele i ako su
u vrijednostii
(jednostavni)
atributa u ssvakoj n-torrki relacije pojedinačni
p
i) podaci ili se vrijednos
osti atributa ne mogu see
prikazati u oobliku pod-taablela
Drugano
ormalnafforma
Relacija je u Drugoj noormalnoj form
mi (2NF) akko je u 1NF i svi njeni neeključni atribbuti funkcion
nalno zavisee
od primarnoog ključa (neeključni atrib
buti su atribuuti koji nisu kandidati
k
za ključ, niti dioo kandidata za ključ)
Smještanje podataka u drugu
d
normaalnu formu saastoji se od premještanja
p
u druge tabeele onih podaataka koji suu
zavisni sam
mo od dijela ključa.
k
Osnovni zahhtjevi 2NF suu
1. Ukllanjanje podsskupova pod
dataka koji see nalaze u višše redova i njihovo
n
smešt
štanje u poseb
bne tabele.
2. Kreeiranje veza između
i
novih
h tabela i tabbela sa kojim
ma su spojenee korišćenjem
m spoljnih klj
ljučeva
Dakle, 2NF
F ima za cilj smanjenje
s
ko
oličine reduddantnih podaataka, tako štto se oni “izvvlače” iz tabeele, stavljajuu
u nove tabele i kreiraju veze
v
između
u ovih tabela..
Na primjer, ključ na slicci
ProductNam
me (naziv arttikla),
SupplierNam
me (naziv
dobavljača))}, ali polje
SupplierPhooneNumber
(telefonski bbroj dobavljaača) zavisi
samo od atrributa —SuplierName,
a ne od cijellog kombinoovanog
ključa.
a
relacije treba da budu zavisnii od cijelog ključa
k
Svi atributi
Već smo naapomenuli da
d je posljediica toga reduundantnost, a posljedica redundantnoosti mogu biti neprijatnii
problemi oddržavanja uskklađenosti po
odataka.
Ovo predstavlja
p
bbolji model.
d
druguu
Logiččki gledano,, da biste dobili
norm
malnu formu,, pokušajte da
d izbjegnetee
da dv
va različita eentiteta Products (artikli))
i Sup
ppliers (dobaavljači) predsstavite istom
m
relaciijom.
Ako entitete predstavite odvojenim
m
relaciijama, time ććete ne samo
o eliminisatii
redun
ndantnost, već ćete dobiti i
mehaanizam za skkladištenje po
odataka kojee
na drugi način nee biste mogli da unesete.
U primjeru na slici, posttaje moguće da podatke o određenom
m dobavljaču unesete prij e nego što up
pišete ijedann
podatak o aartiklima kojee vam on dob
bavlja. To nee bi bilo mog
guće u prvoj relaciji zatoo što nijedna komponentaa
primarnog kključa ne moože da se izosstavi.
9
Trećano
ormalnafo
orma
Relacija je u trećoj norrmalnoj form
mi ako je u ddrugoj norm
malnoj formi i ako su svvi atributi koji
k nisu dioo
nijednog klljuča međussobno nezav
visni, (ako svvi njeni neklljučni atributi netranzitivvno zavise od primarnogg
ključa).
Osnovni zahhtjevi 3NF
1. Tabbela je u 1NF
F i 2NF
2. Ukklonjene su kolone
k
koje nisu
n potpuno zavisne od primarnog
p
klljuča.
Praktično ppostavlja se pitanje:
p
Da lii postoje koloone koje ne zavise
z
u potp
punosti od prrimarnog klju
uča?
Treća norm
malna forma sastoji
s
se od uklanjanja ssvih podatak
ka u tabelamaa koji ne zavvise jedino od primarnogg
ključa. Drugim riječimaa, treba zadrržati samo p odatke koji su zavisni od
o primarnogg ključa, 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 trećoj no
Dvije relacij
ije prikazanee na slici ispo
od su tehničkki su ispravniije
O
Ova relacija je u trećojj
noormalnoj forrmi
Jedina stvaarna prednost koju pružaa ovo rješennje jeste mo
ogućnost da se automatsski potraži odgovarajući
o
i
poštanski bbroj pri unoššenju novih zapisa, što korisniku šttedi nekoliko pritisaka nna tastere. To
T nije takoo
zanemarljivva prednost, ali vjerovatn
no postoje boolji načini 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
ošenju svih ddrugih odluk
ka tokom postupka modeelovanja pod
dataka: kad i
kako ćete reealizovati treeću normalnu
u formu mož ete odrediti samo
s
na osno
ovu semantikke modela.
Nemoguće jje navesti prravila koja bi
b uvijek važžila, ali postoje određenee smjernice. Trebalo bi da napravitee
zasebnu relaaciju u sljedeećim slučajev
vima:
• Enttitet je važan dio modela, ili
• Poddaci se često mijenjaju, illi
modela.
• Siguurni ste da ćee vam to pru
užiti određenee tehničke prrednosti pri realizovanju
r
Poštanski brojevi se mijjenjaju, ali ne
n često, a u većini sistem
ma nisu samii po sebi važžni. Osim tog
ga, odvojenaa
tabela poštaanskih brojevva ne bi bila praktična u većini aplikacija iz stvarrnog života zzbog različitih pravila zaa
određivanjee poštanskih brojeva
b
(u SAD).
10
Praktičanprimjernormalizacije
Daćemo primjer kako da od neuređene (nenormalizovane) baze dobijemo model u 3NF formi.
Krenućemo 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 tipičan primjer loše dizajnirane baze sa samo jednom tabelom u kojoj se nalaze svi podaci.
Ako želimo da saznamo koji korisnik zna “video” moramo proći kroz sve korsnike, provjeriti sadržaj polja
“znanje” i pregledati prilično nepregledno polje “znanje” te otkriti da li dotični korisnik zna “video” ili ne.
Mane ovakve organizacije su očigledne (brzina, preglednost…) te je ovo vrlo nepraktičan način za čuvanje
informacija.
Svođenjemodelanaprvunormalnuformu
Razdvajanje repetitivnih podataka u zasebne tabele našu strukturu dovodi u prvu normalnu formu.
Iz našeg 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
Svodjenjemodelanadrugunorm
malnuform
mu
Ako pogleddamo tabelu “ZNANJE” iz prethodn og primjera gdje smo sv
veli model nna prvu norm
malnu formu,,
primjetićem
mo da nam see podaci dup
pliciraju. Za razliku od taabele “KORISNIK” gdjee atribut KO
ORISNIK_ID
D
definiše slogg tabele, u taabeli KORISNIK slog deefinišu KORIISNIK_ID i ZNANJE_ID
Z
D atributi zajedno. Ovo u
nekim slučaajevima možže da ima smisla, ali u našem sluččaju, gdje im
me “znanja” realno nije ni u kakvojj
relaciji sa kkorisnikom i bezrazložno
o se multipliccira u tabeli, možemo zak
ključiti da naam se podacci “duplirajuu
što se odražžava na prosttor potreban za čuvanje isstih, otežava 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 više m
mjesta, umjessto samo naa jednom (annomalija pri promjeni)..
Dalje, pretppostavite da “mali
“
perica”” ode sa foruuma; u tom sllučaju treba obrisati
o
sve sslogove vezaane za njega;;
u tom sluččaju, potpunoo će nestati referenca dda je znanjee “Linux” postojalo na forumu (an
nomalija prii
brisanju).
Da bi ste zaaobišli ove annomalije, pottrebna vam j e druga norrmalna form
ma.
Da bi “razvili” našu bazzu u drugu no
ormalnu form
mu, potrebno
o je da razdvo
ojimo atributte koji zavisee od oba
ključa koji ddefinišu 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
modelanattrećunorm
malnuformu
u
Svođenjem
Ako pogleddamo malo bolje
b
tabelu “KORISNIK
K” iz primjera za drugu normalnu foormu, videćeemo da iakoo
ispunjava i prvu i druguu normalnu formu,
fo
atribuut “ZIVI” nijee direktno zaavistan od ID
D-a korisnikaa (primarnogg
ključa). Da bi postigli treću
t
normallnu formu, taaj podatak mora
m
da se odvoji
o
u zaseebnu tabelu. Zašto? Akoo
uzmemo naa primjer da “mali zikicaa” napusti foorum, te se slogovi
s
koji njega
n
definiššu obrišu, neestaće trag o
“BIH” (anoomalija pri brisanju)
b
ili ako “Srbija”” ponovo prromjeni ime u “Uža Srbiija sa okolin
nom”, to imee
moramo proomjeniti na više
v od jedno
og mjesta (an
nomalija prii promjeni). Razlaganje nna treću 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
Primjeriianalizaa
anomalija
a
Analiza annomalija i formalna
fo
primjena relaccionoh račun
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 poštovati
p
da bi mogli dizzajnirati bazu
u podataka.
1NFianom
malije
Neka na poččetku imamoo nenormalizzovanu bazu koje jednosttavno „atomiziramo“ i svvedemo na 1N
NF.
INSERT annomalije Nee može se dodati predmett bez lekcije
UPDATE aanomalije Prrilikom prom
mjene podataaka predmetaa P1, moraju se izmjeniti dva reda tab
bele.
DELETE annomalije Akko izbrišemo
o P3, brišemoo 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 ključa.svođenje na 22NF preko objašnjenjaa
funkcionalnne zavisnosti:
1NF
Rješeni prooblemi sa 2N
NF
Problemi u 1NF
INSERT – N
Ne može 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 izbriiše P3, briše se iN2.
U 2NF prvaa dva problem
ma su otklonj
njena, ali ne i treći
14
Preostali prroblemi u 2N
NF
INSERT anomalije
Ne može 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 obriše P3 briše ssei N2
3NF Problemi u 2NF
INSERT annomalije- Ne može 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 obriše P3 briše sei N2.
U 3NF svi oovi problemii su riješeni(zza ovu relacij
iju – ali 3NF i dalje možee imati anom
malije!)
Daljenorrmalizova
anje
Prve tri norm
malne formee bile su opissane u Coddoovoj prvobitn
noj formulacciji relacionee teorije. U velikoj većinii
slučajeva onne su dovoljnne.
Više normaalne forme suu bazirane naa drugoj vrstii zavisnosti.
Četvrta norm
malna formaa uklanje višee-vrjednosnee zavisnosti.
Peta normallna forma ukklanja zavisnosti udruživaanja.
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 ključu.
Relacija je u D
Drugoj normallnoj formi (2N
NF) ako je u 1N
NF i svi njeni neključni
n
atribu
uti
funkcionalno zavise od prim
marnog ključa (neključni atribbuti su atributii koji nisu kand
didati za ključ,, niti dio kandiidata za ključ)
Treća nor
rmalna form
ma: Relaci
ija je u t
trećoj nor
rmalnoj for
rmi (3NF) ako je u 2NF i ako
o
ne sadrži
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 sadrži ključ
k
za R
ili je A primarni atribut.
a
Uklonjene su kolone koje nisu potpuno zaavisne od prim
marnog ključa.
Postoji i pobooljšana 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č
č. Očito 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 značajaa, jer je teško u praksi naći relacije
r
koje jeesu u BCNF, a nisu u 4NF i
5NF.
15
Razlozizbogkojihsemožeodustatiodnormalizacije
Za većinu praktičnih primjera dovoljno je relacije normalizovati do 3NF. Ponekad je potrebno neku
relaciju i dalje normalizovati do BCNF ili 4NF. Peta normalna forma, koja se takođe navodi u literaturi, nije
od praktičnog značaja.
Postoje razlozi zbog kojih ponekad možemo odustati od pune normalizacije.
Pogledajmo dva takva razloga.
1.Složeni atribut .
Dešava 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, POŠTANSKI_BROJ, GRAD, ULICA ) .
Strogo govoreći, GRAD je funkcionalno zavisan o POŠTANSKI_BROJ, pa relacija nije u 3NF. No mi znamo
da POŠTANSKI BROJ, GRAD i ULICA čine cjelinu koja se zove adresa.
Budući da se podaci iz adrese koriste i ažuriraju "u paketu", ne može doći do prije pominjanih anomalija.
Nije preporučljivo 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 veće n-torke. Uspostavljanje veza medu podacima u manjim relacijama
traje znatno duže 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 važno razumjevanje značenja podataka i načina kako će se oni koristiti.
16
Dodatak:Procedureialgoritmi
GENERALPROCEDUREFORACHIEVINGANORMALIZEDSETOFRELATIONS
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
Algoritam2NFnorma
Algoritam3NFnorma
alizacije
18
© Copyright 2024 Paperzz
