Normalizacija i Relacione Baze

8/10/2019 Normalizacija i Relacione Baze

1/37

UNIVERZITET SINERGIJA BIJELJINA

FAKULTET ZA POSLOVNU INFORMATIKU

DIPLOMSKI RAD

KandidatMilo Nikoli

BIJELJINA, 2013


2/37

UNIVERZITET SINERGIJA BIJELJINA

FAKULTET ZA POSLOVNU INFORMATIKU

Kandidat : Milo Nikolibroj indeksa 26/2008

DIPLOMSKI RAD br.Naziv rada : RELACIONE BAZE PODATAKA I TEHNIKE NORMALIZACIJE

Cilj rada :Teze :

1. Uvod2. Struktura relacione baze podataka3. Normalizacija4. Denormalizacija5. Praktian primjer6. Zakljuak

Dekan :Profesor dr Duan Regodi, dipl. in.Mentor :Profesor dr Mladen Veinovi, dipl. in.Datum uruivanja :

Bijeljina, 2013


3/37

SADRAJ

1. Uvod.22. Struktura relacione baze podataka...3

2.1Model relacione baze podataka..5

2.2

Relacije u bazi podataka72.3Atributi...82.4Kandidat klju, primarni klju, spoljni klju.82.5Ogranienja i pravila integriteta podataka.....9

3. Normalizacija.103.1Anomalije unosa, auriranja i brisanja.103.2Funkcionalna zavisnost113.3Prva normalna forma133.4Druga normalna forma.143.5Trea normalna forma..163.6Bojs/Kodova normalna forma..16

3.7

etvrta normalna forma...184. Denormalizacija.194.1esto pridruivane tabele.194.2Izvjetaji...204.3Preslikane tabele..204.4Razdvajanje tabela...204.5Spajanje tabela.214.6Redundantni podaci.214.7Ponavljajue grupe...224.8Izvedeni podaci234.9Hijerarhijske tabele..23

4.10

Preoptereeni tipovi podataka245. Praktian primjer baze podataka25

5.1Rijenik podataka.255.2Relacioni model...285.3Dijagram konteksta, prvi i drugi nivo dekompozicije.325.4Model objekti-veze..34

6. Zakljuak7. Literatura35


4/37

I - UVOD

Kroz istoriju je termin baza podataka dobijao razna znaenja. Najprije je bio koriten da oznaijednu tabelu, ili kako se to ranije nazivalo datoteku. Zatim je oznaavao samo skup odreenihtabela, bez uvoenja pravila nad uskladitenim podacima. Kako e tabele biti povezane zavisi od

modela baze podataka koji se koristi. Ranije su se koristili modeli poput hijerarhijskog (datotekepovezane vezom roditelj/naslednik , gdje svaki naslednik moe imati najvie jednog roditelja, aroditelj moe imati vie naslednika) i mreni model (gdje je vrsta veze bila vlasnik/lanovi,veoma slino kao u hijerarhijskom s tim to ovdje svaki lan moe imati vie od jednogvlasnika). Problem navedenih sistema bio je nepreglednost a posebno izostanak fleksibilnosti.Zbog toga je dodavanje novih modula i analiza podataka oduzimala ogromno vrijeme strunjaka,sa nedovoljno dobrim rezultatima, a naposletku stalne dorade infomracionih sistema kotale suprevie novca.

Danas se pod terminom baza podataka podrazumijeva kolekcija meusobno povezanih podatakauskladitenih sa minimumom ponavljanja (redundanse) koju koriste zajedno, svi procesi obrade

u sistemu. Edgar F. Kod je tokom rada za IBM

1

1960-tih prouavao teorije ure

enja podataka,gdje je primjetio da se matematike teorije i pravila mogu upotrebiti za postavljanje osnove za

skladitenje podataka. U toku rada izumio je relacioni model podataka to je objavio u svom raduiz 1970 A Relational Model of Data for Large Shared Data Banks2, ime postavlja paradigmurelacione baze podataka. Relacioni model podataka bio je veliki iskorak naprijed, jer omoguavavezu izmeu datoteka na nivou kolone u datotekama(tabelama). Da bi ostvarili vezu meutabelama u relacionom modelu potrebno je samo da imaju minimum jedan zajedniki atribut, toini relacioni model veoma fleksibilnim.

___________________1 International Business Corporation, multinacionalna amerika kompanija koja se bavi proizvodnjom hardvera,razvojem softvera, davanjem usluga itd.2 - "A Relational Model of Data for Large Shared Data Banks", Kodov rad objavljen u mjesenom magazinuCommunications of ACM, 1970 godine.


5/37

II - STRUKTURA RELACIONE BAZE PODATAKA

Dolazak do relacione baze podataka podrazumijeva kreiranje modela podataka, najprijekonceptualnog, a zatim i fizikog, iz kojeg bi se, na kraju, dobila relaciona baza podataka.

Modelovanje podataka je proces nastanka modela podataka, apstrakcijom realnog sistema.Model objekti-veze pripada generaciji najpotpunijih modela podataka, jer podrava sve vrsteapstrakcija i daje semantiki zadovoljavajui opis sloenog sistema. Relacioni model podataka jedanas najrasprostranjeniji model podataka jer za njega postoji dosta komercijalno raspoloivihsistema za upravljanje bazama podataka.

Svaka baza podataka nastaje iz modela podataka. Model podataka je intelektualno sredstvo zaprikazivanje objekata sistema, njihovih atributa i meusobnih veza (statikih karakteristikasistema) preko logike strukture baze podataka. Svaki model podataka posjeduje tri osnovnekomponente:

a)

Struktura modela skup koncepata za opisivanje objekata sistema, njihovih atributa imeusobnih vezab) Ogranienja semantika ogranienja na vrijednost podataka koja se ne mogu predstaviti

samom strukturom modela, a koja u svakom trenutku moraju biti zadovoljena (pravilaintegriteta)

c) Operacije operacije nad konceptima strukture podataka, pod definisanimogranienjima, preko kojih je mogue opisati dinamiku sistema u modelima procesa.

Pri tome, model podataka treba da zadovolji dva bitna kriterijuma:

- da posjeduje koncepte pogodne za modeliranje realnih sistema- da se njegovi koncepti, struktura, ogranienja i operacije mogu jednostavno

implementirati na raunaru

U odnosu na to kako zadovoljavaju ove kriterijume, i na koliinu znanja o realnom svijetu kojase moe ugraditi u model podataka, modeli podataka se mogu podeliti u generacije. Postojesledee tri generacije modela podataka:

1. Modeli podataka I generacije2. Modeli podataka II generacije3. Modeli podataka III generacije

1. Za modele podataka I generacije je karakteristino da je svaki konvencionalni programskijezik zaseban model podataka. Podaci se modeluju koritenjem koncepata kojima datijezik raspolae. Modeli podataka I generacije i na njima zasnovani programski jezici nisudovoljno pogodni za modelovanje realnog sistema, pa im je praktina upotrebaograniena.

2. Modeli podataka II generacije za prezentaciju podataka koriste naprednije koncepte negomodeli podataka I generacije, ali koriste iste apstrakcije kao i modeli podataka Igeneracije. Moe se definisati baza podataka kao skup meusobno povezanih podataka. Ipored toga to su semantiki bogatiji od modela podataka I generacije, ne mogu dati


6/37

semantiki zadovoljavajui opis sloenog sistema. Ovoj generaciji pripadaju sledeimodeli podataka:

- funkcionalni model podataka- hijerarhijski model podataka- mreni model podataka

-

klasini relacioni model podatakaVrlo vana injenica je da postoji niz komercijalnih sistema za upravljanje bazama podataka

(SUBP), koji su zasnovani na modelima podataka ove generacije.3. Modeli podataka III generacije sadre koncepte generalizacije i agregacije, kao i sve vrste

apstrakcija. Od svih modela podataka, modeli podataka III generacije posedujumehanizme za najbolji opis realnog sistema, a korisniku su razumljivi. Ovoj generacijipripadaju sledei modeli podataka :

- model objekti-veze,- binarni model podataka,- proireni relacioni model podataka,- SDM-IBM,

-

model podataka semantikih mrea,-

semantiki model podataka,- Petrijeve mree,- model semantikih asocijacija,- D-graf model.Ovi modeli su danas uglavnom bez razvijenog komercijalnog sistema za upravljanje bazompodataka.

Relaciona baza podataka je baza podataka zasnovana na relacionom modelu podataka.Moglo bi se rei i da je relaciona baza podataka skup meusobno povezanih tabela, podataka kojise sadre u tim tabelama. Svaka tabela predstavlja jednu relaciju, koja posjeduje svoje atribute,skupove vrijednosti, koje mogu uzeti pojedina atribute i koja moe biti u direktnoj vezi sadrugim relacijama. Teorija relacionog modela kae da redovi u tabeli ne posjeduju implicitniporedak. To znai da je poredak fleksibilan i da se moe naznaiti prilikom konstruisanja upitaza bazu podataka. Kao u sluaju redova ni kolone ne moraju imati predodreen poredak, zbogtoga se kae da relaciona baza prua logiku nezavisnost podataka.


7/37

Slika1 : Logiki model relacione baze podataka sa relacijama, kreiran u IBM Rational Software Architect

2.1 Model relacione baze podataka

Da bi se model okarakterisao kao relacioni model baze podataka Edgar F. Kod je postaviopravila koja treba da podre njegovu teoriju, i obezbijede ispravno korienje relacione strukture.Kodova pravila su tako stroga da ih i dananji sistemi za upravljanje bazama podataka neispunjavaju u potpunosti. Pravila ima trinaest, numerisana su od nule do dvanaest.

0. Sistem se mora kvalifikovati kao relacioni, kao baza podataka, i kao sistem zaupravljanje.Da bi sistem za upravljanje bazom podataka nazvali relacionim, on iskljuivo morakoristiti svoje relacione mogunosti da upravlja bazom podataka.

1. Pravilo informacije :Sve informacije u bazi podataka moraju biti predstavljene na jedinstven nain, svojim

vrijednostima kolona sauvanih u redovima.2. Pravilo garantovanog pristupa :Svi podaci moraju biti dostupni bez dvosmislenosti. Ovo pravilo je reformulacijaosnovnog zahtjeva za postojanjem primarnih kljueva. Ono zahtjeva da je svakapojedinana vrijednost mora biti adresabilna navoenjem naziva tabele u kojoj se nalazi,naziva kolone u kojoj se nalazi i vrijednosti primarnog kljua reda u kom se vrijednostnalazi.


8/37

3. Sistemsko tretiranje NULL vrijednosti :Sistem mora dozvoljavati da svako polje po potrebi moe ostati prazno (imati vrijednostNULL). Mora podravati predstavljanje informacija koje nedostaju ili se ne mogudodjeliti, koje je sistematino, razliito od svih regularnih vrijednosti (npr. razliito odnule ili bilo kog drugog broja) i nezavisno od tipa podatka. Takoe se naglaava da takve

reprezentacije sistem mora tretirati dosledno.4. Aktivan, uvijek dostupan katalog zasnovan na relacionom modelu :Sistem sadri opis baze podataka na logikom nivou u vidu tabela, tj. relacioni katalogdostupan autorizovanim korisnicima kroz upotrebu standardnog upitnog jezika. To znaida korisnici moraju biti u mogunosti da pristupaju strukturi baze podataka (katalogu)koristei isti upitni jezik kojim se slue da bi pristupili i samim podacima.

5. Pravilo razumljivog podjezika :Sistem mora podravati bar jedan jezik kojia) ima linearnu sintaksu,b) moe da se koristi i interaktivno u okviru aplikativnih programa,c) podrava operacije definisanja podataka (ukljuujui definisanje pogleda), operacije

manipulacije podacima (auriranje kao i izdvajanje), pravila inegriteta kao iautorizaciju, kao i operacije manipulisanja transakcijama (begin, commit, rollback).6. Pravilo auriranja pogleda :

Sve poglede koje je teoretski mogue aurirati, aurira sistem.7. Unoenje, auriranje i uklanjanje podataka na nivou skupova :

Sistem mora podravati skupovne insert, update, delete operatore. To znai da se podaciiz relacione baze mogu izdvajati u skupovima koje ine podaci iz vie redova i vietabela. Ovo pravilo naglaava da operacije dodavanja auriranja i brisanja buduprimjenjive na bilo koji skup podataka koji se moe izdvojiti iz baze, a ne samo napojedinani red u jednoj tabeli.

8. Fizika nezavisnost podataka :Promjene na fizikom nivou (nain na koji se uvaju podaci) ne smiju zahtjevatipromjene aplikacija zasnovanih na datoj strukturi.

9. Logika nezavisnost podataka :Promjene na logikom nivou (tabela, kolona, redova itd.) ne smiju zahtjevati promjeneaplikacija zasnovanih na datoj strukturi. Mnogo je tee postii logiku nego fizikunezavisnost.

10.Nezavisnost od pravila integriteta :Pravila integriteta moraju biti definisana nezavisno od aplikativnih programa i sauvana ukatalogu. Mora biti predviena mogunost njihove izmjene u bilo kom trenutku beznepotrebnog uticanja na postojee aplikacije.

11.Nezavisnost od distribucije :Distribucija delova baze na razne lokacije mora biti nevidljiva za korisnike baze.Postojee aplikacije moraju nastaviti da rade :a) kada se prvi put uvodi distribucija baze ;b) pri bilo kojoj sledeoj distribuciji podataka u sistemu.

12.Pravilo zatite podataka :Ako sistem podrava upotrebu jezika koji rade na niskom nvou (manipulacija jednimredom u datom trenutku), onda oni ne mogu biti korieni za napad na sistem, u smisluzaobilaenja pravila integriteta ili sigurnosti relacija u sistemu.


9/37

Model nije stvaran svijet nego njegov pojednostavljen prikaz. Model koji je komplikovaniji odentiteta koji opisuje je bezvrijedan u modeliranju baze podataka. Entitet u sistemu moepredstavljati osobu, objekat, dogaaj ili pak moe opisivati relaciju izmeu objekata u stvarnom

svijetu. Entiteti mogu biti konkretni ili apstraktni u zavisnosti od potrebe, ali se moraju moijednoznano identifikovati. Jasno je da je ovjek kao bie jedinstven objekat u fizikom svijetu.

Ali ukoliko se entitet ovjek pojavljuje u bazi podataka koja se bavi biznisom, ovjek moeimati nekoliko uloga, moe biti zaposleni, saradnik, vlasnik ili kupac. Ako bi htjeli dapredstavimo jo detaljnije entitet ovjeka u pomenutom sistemu mogao bi da ima razliiteatribute i ovlaenja u zavisnosti od uloge u sistemu. ef u kompaniji moe otpustiti radnika aliradnik ne moe efa iako su u sistemu predstavljeni kao isti entitet ovjek. Isti entitet bi mogaoako je vlasnik da ima neke druge atribute i ovlaenja. Postavlja se pitanje da li model treba da sebazira na pojedincu ili na ulogama koje bi mu se dodjelile. Veina baza podataka se bazira naulogama koje se dodjeljuju pojedincu u sistemu baze podataka zbog lake manipulacijeovlaenjima i atributima. Tim sistemom lako se u tabeli koja se bavi entitetom ovjek izdvoje

samo vlasnici kompanije ili zaposleni, jednima bi sistem obraunavao platu a drugima dividendu.

2.2 Relacije u bazi podataka

Relacija ili veza je posebna vrsta entiteta. Relacija je nain da se entiteti veu jedan sa drugim,da bi se dobila nova informacija koja e postojati odvojeno od konkretnih objekata koje vee.Entiteti mogu biti povezani preko jednog ili vie atributa, u praksi se to svodi na vezu izmeuprimarnog kljua jedne tabele i spoljnjeg kljua druge. Mogu se razlikovati tri tipa relacija kojese uglavnom realizuju preko prve dvije navedene relacije :

- JEDAN NA JEDANTo znai da jednom redu jedne tabele odgovara tano jedan red druge tabele. Npr., ako seu jednoj tabeli uvaju podaci o firmama, a u drugoj o njihovim sjeditima i to je vezajedan-jedan (one-to-one).

- JEDAN NA VIEJednom redu prve tabele moe odgovarati vie redova druge tabele. Jedan kupac moeimati vie porudbina. (one-to-many)

- VIE NA VIEJednom redu prve tabele moe odgovarati vie redova druge, ali vai i obrnuto, jednomredu druge tabele moe odgovarati vie redova prve tabele. Dobar primjer je tabela ukojoj uvamo sve dostavljae robe u nekoj firmi, a u drugoj tabeli sve vozila kojedostavljai koriste.Veza je vie-vie, jer jedan dostavljamoe koristiti vie vozila,(recimo da ima deset dostavnih vozila) ali i isto vozilo moe koristiti koristi viedostavljaa. U praksi se ova veza razbija na dvije veze jedan-vie :

VIE NA VIE_________________________________________________________ (transformie se)

JEDAN NA VIEVIE NA JEDAN


10/37

2.3 Atributi

Atributi pripadaju entitetu i definiu ga. Njemaki matematiar Lajbnic2je otiao korak dalje irekao da je entitet proizvod svih svojih atributa. Relacioni model sledi njegovu tvrdnju,predstavlja atribute kao kolone koje u svojim redovima uvaju vrijednosti instance entiteta. U

relacionoj teoriji redovi su neureeni, to nije slu

aj u SQL

3

koji i pored toga to sledi relacionuteoriju ima ureene redove u tabelama. Ono to je vano naglasiti je to da se kod definisanjaatributa entiteta uzimaju u obzir atributi koji su zahvaeni poljem interesovanja kojim se bavibaza podataka. Ako modelujemo entitet Vozilo u firmi, vani atributi bi bili broj sjedita, godinaprve registracije, sledei servis i dr. Iako postoji u stvarnom svijetu atribut boja vozila se ne biuzimao u obzir prilikom definisanja atributa. S druge strane, ukoliko se kod atributa ponuuoavati njegovi atributi kao bitni, onda bi se dati atribut trebao u sistemu izdvojiti kao posebanentitet. To u praksi znai da ako imamo tabelu vozilo i atribut model vozila, model vozila zbogvanosti sopstvenih atributa trebao bi postati novi entitet, gdje bi postojala relacija izmeuglavnog entiteta vozilo i entiteta model vozila.

2.4 Kljuevi

Kandidat kljumoe biti sastavljen od jednog ili vie atributa koji nepogreivo treba daoznaavaju jedan red u tabeli. Definicija relacije kae da je svaki red u tabeli jedinstven, znai dase analizom kolona moe uoiti jedna ili vie kolona koje identifikuju svaki red. Ujednostavnijim tabelama e se nametnuti jedna kolona za primarni klju, kao to je sluaj u tabeliRadnik sa Slike 1, gde je primarni kljuatribut ID Radnik. U drugim sluajevima to e biti dvijeili vie kolona i takav primarni klju(PK) se naziva kompozitni ili sloeni primarni klju. Takavprimjer imamo u tabeli Ponuda, gdje primarni kljuine atributi ID Ponuda, ID Firma (firmakoja iznosi ponudu) i ID Roba (roba kao predmet ponude). U najgorem sluaju to mogu biti svekolone u tabeli, to moe biti znak da se nije na pravi nain modelovala tabela. Da bi izabraliprimarni kljuod kandidata kljueva u tabeli, on mora ispuniti sledee kriterijume :

-

mora biti jedinstven- mora biti popunjen- mora biti stabilan, sa malom vjerovatnoom projmene- mora biti minimalan, jer to manje kolona sadri, pretraivanje baze e biti bre i manje

e biti greaka pri unosu podataka.

Kao to je prethodno reeno o relacionom modelu, veza izmeu tabela moe biti jedan ili vieatributa. Spoljnim kljuem se naziva svaki atribut koji postoji u drugoj tabeli sa istimvrednostima. Takoe, atribut koji je dio veze izmeu tabela moe biti u primarnom kljuu tabeleA ili tabele B. Moe biti primarni kljuili dio njega u obe ili ni u jednoj. Po ovim osobinamaatributa za vezu moe da se primjeti velika fleksibilnost povezivanja izmeu tabela. Iako sespoljni kljune mora naznaiti, preporuljivo ga je obiljeiti zbog preglednosti modela bazepodataka. U gornjem primeru modela baze podataka (BP) u tabeli Firma postoji spoljni kljuIDRadnik koji se odnosi na radnika koji vodi firmu u informacionom sistemu.______________________2 - Gotfrid Vilhelm Frajher fon Lajbnic (1.jul 1646. 14. novembar 1716) ustanovio infinitezimalni raun i binarnisistem brojeva, koji je osnova dananjih raunara.3 Structured Query Language (struktuirani upitni jezik) je programski jezik specijalne namjene koji slui zaupravljanje realcionim bazama podataka


11/37

2.5 Ogranienja i pravila integriteta podataka

Opta ogranienja (pravila integriteta) su ogranienja sadraja baze podataka na neka dozvoljenastanja. Cilj tih pravila je da sprijei unos neispravnih, neistinitih ili nepotpunih podataka u bazu,to bi naruavalo konzistentnost baze podataka. Vano je istai da se integritet podataka ne

odnosi samo na kljueve. Skup optih pravila integriteta sastoji se od dva pravila :- Integritet objekta: atribut ili skup atributa koji ine primarni kljuili su njegov dio ne

mogu uzeti NULL vrijednost, dakle vrijednosti za te atribute mora biti unijeta (za tabeluRadnik to bi znailo da se ID Radnik obavezno mora unijeti !).

- Referencijalni integritet: ukoliko su dvije tabele u relaciji (npr.Firma i Radnik), tadasvaka vrijednost atributa koje je spoljni klju(ID Radnik u tabeli Firme) mora biti ilijednaka vrijednosti primarnog kljua (ID Radnik u tabeli Radnik) ili NULL vrijednosti.Drugim rijeima, kada se unosi ID radnika u tabeli Firma, kolona sa tom vrijednoumora postojati u tabeli Radnik, ili se to polje mora ostaviti prazno.

Ukoliko se paljivo proue ogranienja koja utiu na operacije nad tabelama u relacionom

modelu podataka, moe se zakljuiti da ova, naizgled teorijska ograni

enja i te kako imaju vezesa praksom i da se moe, ukoliko se potuju ova ogranienja, obezbijediti siguran unos, izmjena i

brisanje podataka u bazi podataka, a da pri tome ne doe do poremeaja konzistentnosti bazepodataka.C J. Date7u svojoj knjizi Introduction to Database Systems iznosi tvrdnju koju naziva GoldenRule (Zlatno pravilo) integriteta baze podataka :[No update operation must ever assign to any database a value that causes its database predicate

to evaluate to FALSE. ]to u prevodu znai : Nikada se na tabeli baze podataka ne smije izvriti takva izmjena podatakakoja bi ugrozila ispravnost relacije koju tabela posjeduje sa drugom tabelom.Dalje u tekstu kae da sistem BP ne moe garantovati istinitost podataka, samo konzistentnost.Ispravnost podrazumjeva konzistentnost, dok nekonzistentnost podrazumjeva neispravnostpodataka. Pod ispravnim podacima se podrazumjevaju podaci samo ako odraavaju stvarnostanje interesne sfere u realnom svijetu. Integritet podataka se ne odnosi samo na ogranienja natabelama zbog ispravnosti, nego i na ispravnost podataka dobijenih upitima.

U praksi se esto javlja sluaj nedostatka informacija koje su potrebne. Na primjer ako se vodievidencija o ponuenoj robi, pri emu se zavode podaci o robi, ta da se radi u situaciji kadagrupa robe nije prethodno definisana? Svaki dobar model realnog sistema mora pruitimogunost da se rijei ovaj problem i on se rjeava uvoenjem takozvane NULL vrijednosti.NULL vrijednosti je oznaka da nam je stvarna vrijednost atributa nepoznata.

Oganienja koja se pojavljuju prilikom dizajniranja baza podataka mogu se svrstati u dvijegrupe:

- Prvu grupu ine ogranienja na vrijednosti koje moe primiti neki atribut (npr. ID Robene moe biti slovo, niti manja od nule, a mora biti u opsegu od -2^31 (-2,147,483,648) do2^31-1 (2,147,483,647)) i koja ne zavise od vrijednosti ostalih atributa.

_______________________7 - Christopher J. Date (1941 -), izdavai autor knjiga o bazama podataka, autor Introduction to Database Systems


12/37

- U drugu grupu se ubrajaju ogranienja na vrijednosti koje moe primiti neki atribut, akoja zavise od vrijednosti ostalih atributa (iz primjera sa Slike 1, ako se unosi realizacijaponude i tranje, unijeti datum u realizaciji ne moe biti manji od datuma kada je ponudaili tranja objavljena).

III - NORMALIZACIJANormalizacija predstavlja sistemski metod za osiguravanje da je struktura baze podatakapogodna za upite opteg tipa, da se smanji mogunost redundancije podataka, da se smanjimogunost pojave anomalija unosa, auriranja i brisanja koje bi mogle da dovedu do gubitkaintegriteta podataka. Normalizacija je i iterativni proces tokom koga se vri reorganizacija bazepodataka u cilju izbjegavanja redundanse i poveanja stabilnosti baze podataka. Postupak jepodran i teoretski, ali posle stalnog rada u relacionom modelu se pokazuje da jezdravorazumsko razmiljanje najbolji osnov za izvravanje procesa normalizacije. Kasnije semoe izvriti provjera postupka normalizacije primjenom procedura za provjeru normalnih formiu kojima se nalaze tabele u bazi podataka. Normalizacijom baze podataka eliminiu se sledei

atributi :- atributi koji sadre vie od jedne vrijednosti,- atributi koji su dupli ili se ponavljaju,- atributi koji ne opisuju tabele,- atributi koji sadre redundantne podatke,- atributi koji su izvedeni iz ostalih atributa.

Potpuna normalizacija nije obavezna ali je preporuljiva. Uzdravanje od pune normalizacijeobino podrazumjeva predvianje problema koji bi se mogli pojaviti (takav pristup je ponekadneophodan s obzirom na slabu odvojenost logikog i fizikog modela). Proces normalizacije jezasnovan na hijerarhiji normalnih formi. Svaka normalna forma se zasniva na prethodnoj i

definie rjeenje problema koji prethodnik nije pokrio. Prve tri normalne forme je kao i pravilaza uspostavljanje relacionog modela ustanovio Ted Kod. Baza se smatra normalizovanomukoliko potuje pravila iz prve tri normalne forme (NF). Posle 3NF dolazi Bojs9/Kodovanormalna forma (BCNF) i proizala je iz zajednikog rada pomenute dvojice strunjaka. S drugestrane, to viu NF baza podrava vie je relacija u njoj, vie JOIN operatora zbog ega je teedoi do specifinog podatka, a baza koristi vie resursa da bi odgovorila na zahtjev. Jedan odproblema je i to to detekcija nepravilnosti koje definie peta i vie normalne forme ne moe dase obavi bez raunarske analize.

3.1 Anomalije unosa, auriranja i brisanja

Pretpostavimo da imamo tabelu sa tri kolone, student, predavai predmet. U korist primjerapretpostavimo da jedan student pohaa samo jedan predmet, i da jedan predmet ima samo jednog

predavaa.

______________________9 - Raymond F. Boyce (do 1974. godine), inenjer raunara, u toku rada u IBM zajedno saKodom definisaoetvrtupo redu Bojs/Kodovu normalnu formu


13/37

Tabela 1 : PredmetiSTUDENT PREDAVA PREDMET

MILO SIMI MREEGORAN SIMI MREEMARKO JOVANOVI MATEMATIKA

Anomalija unosa (insert-a) : Kada bi pokuali da dodamo novog studenta na Matematiku, moralibi da znamo da je predavana predmetu Matematika Jovanovi, inae ne bi mogli izvritikomandu dodavanja.Anomalija izmjene (update-a) : Goran se odluuje na promjenu predmeta na Programiranje zatoto su Mree preteke kod predavaa Simia. Naalost, ovo bi kreiralo red(Goran,Simi,Programiranje) to stvara netaan podatak da je Simipredavana predmetuProgramiranje.Anomalija brisanja (delete) : Ako predavaJovanoviodustane od predavanja Matematike,brisanje reda (Marko,Jovanovi,Matematika) bi grekom izbacilo Marka sa predmetaMatematika. Moemo pretpostaviti da fakultet nee ukinuti predmet Matematika iako je

Jovanovidao otkaz.Rjeenje za sprjeavanje anomalija iz primjera je da se studenti i predavai podjele u dvije

tabele. U tom sluaju bi se Predmetima dodjeljivali Predavai Studenti.

3.2 Funkcionalna zavisnost

Za shvatanje normalizacije veoma je vano razumjeti pojam funkcionalne zavisnosti (FZ) za daturelaciju. U toku procesa normalizacije analizira se posebno svaka relacija, identifikuju sezavisnosti u relaciji i ako je potrebno pristupa se normalizaciji. Na osnovu identifikovanihzavisnosti pristupa se postepenom ralanjivanju relacija u set novih relacija (tabela). Relacijekoje se pojavljuju u identifikovanju funkcionalne zavisnosti utvrdio je kandaski matematiar i

inenjer raunarstva Vilijam V. Amstrong u svom djelu iz 1974. Dependency structures ofdatabase relationships. Zakonitosti koje iznosi su poznate pod nazivom Amstrongove aksiome.

Tabela 2 : Koncept funkcionalne zavisnosti - identifikacija zavisnostiKoncept Definicija

Funkcionalna zavisnost

Atribut B je potpuno zavisan od atributa A akosvaka vrijednost atributa A odreuje jednu jedinuvrijednost B.Primjer : ID radnikime i prezime(ita se kao ID radnik funkcionalno odreuje imei prezime)ID radnik se smatra determinantnim atributom a

ime i prezime zavisnim atributom.Funkcionalna zavisnost (uoptena definicija) Atribut A odreuje atribut B ako se svi redovi utabeli za atribut A slau sa vrijednosti atributa B.

Potpuna funkcionalna zavisnost (kompozitni klju) Ako je Atribut B funkcionalno zavisan odkompozitnog kljua A, ali ne od svakog podskupakompozitnog kljua onda kaemo da je B potpunofunkcionalno zavisan od A.


14/37

Tabela 3 : Podaci tabele Radnik sa Slike 1.ID radnik Ime i prezime Adresa Radno mjesto Nivo pristupa

1 Milo Nikoli Danila Kia 29 Administrator 52 Marko Jovanovi Cara Uroa 11 Referent 3

Poto je primarni kljutabele ID Radnik, svaka vrijednost pomenutog atributa jednozna

noodreuje ostale atribute u tabeli Radnik. to e rei da su Ime i prezime, adresa, radno mjesto,

nivo pristupa funkcionalno zavisni od atributa ID Radnik.

Tabela 4 : Podaci tabele Ponuda sa Slike 1.ID Ponuda ID firma ID Roba Koliina Cijena Datum

1 1 1 10 20.00 01.02.20131 1 2 5 7.00 01.02.20132 105 23 4 50.00 05.02.2013

U primjeru iz tabele kompozitni kljuine (ID Ponuda, ID firma, ID Roba). Da bi bio

jednoznano odreen atribut koliina mora nam biti poznat kompletan kompozitni klju. Diokljua nam ne odgovara jer time ne dobijamo jednoznano odreen atribut koliina. Timemoemo rei da su atributi Koliina, Cijena i Datum potpuno funkcionalno zavisni od navedenogkompozitnog kljua.Za normalizaciju su posebno vane dvije vrste funkcionalne zavisnosti, a to su parcijalna FZ itranzitivna (prenosna) FZ. Parcijalna FZ postoji kada imamo funkcionalnu zavisnost u kojoj jedeterminantni atribut samo dio kompozitnog kljua. Ako pogledamo u primjer iz gornje tabeleonda je jasno da su atributi ID firma i Cijena upravo u relaciji parcijalne zavisnosti. ID firma(kao determinantni atribut) je dio primarnog kompozitnog kljua, i sa svojom vrijednou moesamo djelimino da odredi vrijednost atributa Cijena. Parcijalne zavisnosti su prilino direktne iobino se lako uoavaju.

Tabela 5 : Tabele KnjigeKnjiga anr Pisac Nacionalnost20.000 milja pod

moremNauna fantastika il Vern Francuz

Putovanje u sreditezemlje

Nauna fantastika il Vern Francuz

Ana Karenjina Fikcija Lav Tolstoj RusRat i mir Fikcija Lav Tolstoj Rus

Knjiga identifikuje pisca, a pisac svoju nacionalnost. To je sva sutina tranzitivne FZ. Akoimamo zavisnost KnjigaPisac (AB) i PisacNacionalnost (BC) i kada je atribut A

primarni klju, onda se relacija Knjiga

Nacionalnost (A

C) smatra tranzitivnomfunkcionalnom zavisnou. Za razliku od parcijalne FZ, tranzitivna FZ se mnogo tee uoava uanalizi podataka neke tabele. Meutim, postoji i laki nain za identifikaciju tranzitivne FZ.Tranzitivna FZ se pojavljuje samo tamo gdje postoji funkcionalna zavisnost izmeu atributa kojine pripadaju primarnom kljuu. U primjeru, tranzitivnu zavisnost identifikujemo u relaciji AC,meutim veza atributa BC signalizira postojanje tranzitivne zavisnosti.


15/37

3.3 Prva normalna forma

Prva normalna forma kae da svaki atribut koji ima tendenciju ponavljanja mora biti odvojen unovu tabelu. Da bi tabela ispunjavala prvu normalnu formu mora ispunjavati sledee :

- svaka tabela mora imati minimalni primarni klju

-

svaka kolona mora biti atomska, sadravati jednu jedinu vrijednost u jednom redu, nikakoset slinih vrijednosti- ne smije biti ponavljanja, dvije kolone ne smiju uvati sline vrijednosti u istoj tabeli.

Da bi tabelu normalizovali po prvoj normalnoj formi obavezno je proi kroz tri koraka :- eliminacija ponavljanja- idenitfikacija primarnog kljua- identifikacija zavisnosti

Tabela 6 : Tabela ProjektiID_Projekat Projekat_Naziv ID_Radnik Ime_Prezime Radno_Mjesto Cijena_Sata

101 Sistem upravljanjadokumentima

123

Milo NikoliMarko Pavlovi

Andrej imi

ProjektantProgramer

Administrator

201512

50 Transport ilogistika

415

Ljubomir KitiMilos NikolicRade Mitrovi

SistemanalitiarProjektant

Inenjer bazepodataka

122018

Dakle, kolone ID Radnik, Ime_prezime, Radno_Mjesto sadre u sebi vie vrijednosti slinihpodataka, koji se odnose na potpuno razliite radnike ili radna mjesta. Kao to je vereeno,sada bi se pristupilo eliminaciji ponavljanja. Tabela dole prikazuje rezultat eliminacije. Ono tosada imamo je da su sve kolone atomske, vie ne sadre viestruke vrijednosti u jednoj koloni.

Tabela 7 : Tabela Projekti, prvi korak normalizacijeID_Projekat Projekat_Naziv ID_Radnik Ime_Prezime Radno_Mjesto Cijena_Sata


1 Milo Nikoli Projektant 20


2 MarkoPavlovi

Programer 15


3 Andrej imi Administrator 12

50 Transport i logistika 4 LjubomirKiti

Sistem analitiar 12

50 Transport i logistika 1 Milo Nikoli Projektant 20

50 Transport i logistika 5 RadeMitrovi

Inenjer bazepodataka

18

Sledei korak je identifikacija primarnog kljua, lako je primjetiti da ID_Projekat ne moe bitiprimarni kljujer ne identifikuje jednoznano ostale atribute u tabeli. Ako uzmemo kolonuID_Projekat i njenu vrijednost 101 uoavamo da ne oznaava nepogreivo na kog radnika semisli iako su svi dio projekta 101. U ovom sluaju, samo kompozitni kljukoji se sastoji od


16/37

ID_Projekta i ID_Radnika e biti pogodan za dobijanje vrijednosti kompletnog reda. Ukoliko jeID_Projekat=101 a ID_Radnik=1, rezultat datog upita bazi bi bio Projekat_naziv= Sistemupravljanja dokumentima, Ime_Prezime= Milo Nikolii Radno_Mjesto = Projektant.

Samom identifikacijom kljua smo pronali jednu zavisnost :

ID_projekat,IDRadnik

Projekat_Naziv, Ime_Prezime, Radno_Mjesto, Cijena_sata.to znai da su atributi Projekat_naziv, Ime_Prezime, Radno_Mjesto, Cijena_sata zavisni, i da ihodreuje kombinacija atributa ID_projekat,ID_Radnik. Osim glavne zavisnosti od primarnogkljua, uvidjeemo i druge zavisnosti poput ID_projekatProjekat_Naziv. Takoe, ako nam jepoznata vrijednost atributa ID_Radnik, poznati su nam i ostali podaci o radniku, pa vai i :ID_RadnikIme_Prezime, Radno_Mjesto, Cijena_sata.Ako pogledamo jo paljivije moemo uoiti da od atributa Radno_Mjesto zavisi Cijena_Sata.Radno_MjestoCijena_Sata.Kao to je ranije reeno, poto je u pitanju veza izmeu atributa koji ne pripadaju primarnomkljuu to nam signalizira tranzitivnu zavisnost.Da sumiramo, pronaene su sledee zavisnosti :

-

parcijalna, ID_projekat

Projekat_Naziv-

parcijalna, ID_RadnikIme_Prezime, Radno_Mjesto, Cijena_sata- tranzitivna, Radno_MjestoCijena_Sata.

Iako je trenutno tabela normalizovana po prvoj normalnoj formi, problem je parcijalna zavisnostkoja nije preporuljiva mada se nekad namjerno koristi zbog performansi. Opreznost kodkorienja je opravdana jer tabela koja sadri parcijalnu zavisnost je i dalje pod opasnou odredundanse i raznih anomalija. Redundansa se moe pojaviti zbog toga to svaki novi unoszahtjeva unos duplikata vepostojeeg podatka. Na primjer kada se otvara novi projekat, morase unijeti koji radnik e raditi na projektu iako je vjerovatno da vepostoji u bazi podataka. Akose pogrijei u unosu njegovih podataka Ime_Prezime, Radno_Mjesto, Cijena_sata doi e dorazlika u podacima za datog radnika. Ovakav nain rada je veoma neefikasan, osim toganaruava integritet baze podataka i pravila konzistencije.

3.4 Druga normalna forma

Prilagoavanje tabele za drugu normalnu formu se radi samo kada kao rezultat prve imamokompozitni primarni klju. Ako je tabeli primarni kljujedan atribut onda je tabela automatski udrugoj normalnoj formi. Kae se da je tabela u drugoj normalnoj formi ako ispunjava bilo kojutvrdnju :

- tabela ima jedan atribut u primarnom kljuu- u tabeli ne postoji parcijalna zavisnost- svi atributi u tabeli su dio primarnog kljua

Koraci usaglaavanja tabele sa drugom normalnom formom su :-

eliminisanje postojanja parcijalnih zavisnosti- preraspodjela zavisnih atributa

Za svaki atribut koji je dio primarnog kljua, i koji je istovremeno determinantni za neke drugezavisne atribute u tabeli treba napraviti novu tabelu u koju se trebaju smjestiti svi zavisni atributii determinantni kao primarni kljunove tabele. U tom sluaju determinantni atribut treba daostane kao spoljni kljuu originalnoj tabeli nad kojom se radi normalizacija.


17/37

Eliminisanje postojanja parcijalnih zavisnosti se obavlja tako to se svi zavisni atributi uparcijalnoj relaciji briu iz postojee tabele. Njihovi determinatni atributi postaju primarnikljuevi u novim tabelama. Svi atributi koji nisu zavisni ni u jednoj parcijalnoj relaciji ostaju uoriginalnoj tabeli. Iz prethodno navedenog primjera dobijamo tri tabele sa sledeim sadrajem :

-

tabela Projekat (ID_projekat, Projekat_Naziv)- tabela Radnik (ID_Radnik, Ime_Prezime, Radno_Mjesto, Cijena_sata)- tabela Zadatak (ID_projekat, ID_Radnik).

Tabela 8 : Tabela ProjekatID_Projekat Projekat_Naziv

50 Transport i logistika101 Sistem upravljanja dokumentima

Tabela 9 : Tabela RadnikID_Radnik Ime_Prezime Radno_Mjesto Cijena_Sata

1 Milo Nikoli Projektant 202 Marko Pavlovi Programer 15

3 Andrej imi Administrator 124 Ljubomir Kiti Sistem analitiar 125 Rade Mitrovi Inenjer baze podataka 18

Tabela 10 : Tabela ZadatakID_Projekat ID_Radnik

50 150 450 5

101 1101 2101 3

Time to smo ostavili determinantne atribute u originalnoj tabeli (ine kompozitni klju) inainili ih primarnim kljuevima u novim tabelama, kreirali smo vezu primarni/spoljni klju.

Slika 2 : Logiki prikaz novonastalih tabela sa relacijama


18/37


19/37

Slika 4 : Relacija meu atributima gdje je determinantni atribut C odreujui za B (dio kljua)

Kao to je prikazano zavisnosti u tabeli su sledee :A+BC, D primarni kljuidentifikuje ostale atributeA+CB, D samim tim to CB, C je kandidat kljukoji zajedno sa A odreuje B, DCB C odreuje B.Jasno je da ovde nema parcijalnih niti tranzitivnih zavisnosti. Meutim u vezi CB, atribut Bkoji je dio kljua je zavisan od odreujueg atributa C koji nije dio primarnog kljua. U istovrijeme, ova veza nije ni parcijalna ni tranzitivna jer je atribut B dio PK, iz tog razloga ova tabelaispunjava uslov za 3NF, ali ne i BCNF zbog pomenute relacije. Da bi relacija sa slike ispunilaBCNF potrebno je promjeniti PK na A+C, poto je C odreujui za B. Posle promjene PK tabelaispunjava 1NF, i ima parcijalnu zavisnost.

Slika 5 : Relacija meu atributima nakon promjene primarnog kljua


20/37

Da bi se zavrila normalizacija na BCNF potrebno je eliminisati parcijalnu zavisnost, krajnjirezultat moemo pogledati na Slici 6.

Slika 6 : Prikaz rezultata usklaivanja sa BCNF

3.4 etvrta normalna forma

etvrta NF se odnosi na eliminaciju zavisnosti viestrukih vrijednosti. Tabela je u

etvrtoj NFako ispunjava BCNF i ako nema ponavljanja viestrukih vrijednosti. Ako se vratimo na primjer

sa Slike 1 i uzmemo samo primarni kljutabele Ponuda, vrijednosti u njoj bi izgledale ovako :

Tabela 11 : Vrijednosti PK tabele PonudaID_Ponuda ID_Firma ID_Roba

1 101 11 101 22 222 32 222 42 222 5

3 59 401

Vidljivo je da se neke vrijednosti ponavljaju iz reda u red. etvrta normalna forma kae da seova ponavljanja eliminiu kreiranjem novih tabela. Prva tabela bi se bavila vezom Ponuda /Firma a druga Ponuda / Roba. U tabelama dole se moe vidjeti izgled novih tabela.

Tabela 12 : Tabela Ponuda/FirmaID_Ponuda ID_Firma

1 1011 1012 222

2 2222 2223 59


21/37

Tabela 13 : Tabela Ponuda/RobaID_Ponuda ID_Roba

1 11 22 3

2 42 53 401

IV DENORMALIZACIJA

Denormalizacija je prevoenje tabele u slabiju normalnu formu. Za razliku od loih postavkibaze podataka i pravilima za ispravljanje o kojima je bilo rijei u Normalizaciji, ovdje je rijeonamjernom smanjenju normalizacije najee zarad performansi. Brojni teoretiari bazepodataka su snano protiv denormalizacije jer proces moe izazvati anomalije.Ako baza radi sa slabim performansama to ne mora uvijek da znai da je treba denormalizovati.

Moda je potrebno redizajniranje baze podataka jer je model pogreno osmiljen, i takav nemoe da ponudi performanse koje se od baze oekuju. Denormalizacija baze ne mora da znaipoboljanje karakteristika, problemi mogu ostati isti kao ranije, ili se pak mogu odraziti na drugidio sistema baze podataka. Denormalizacija znai promjenu strukture BP, stoga je moguepokvariti postojee funkcionalnosti sistema, ili napraviti probleme u izvjetavanju (vani upitimogu poeti raditi sporo usled promjene). To zahtjeva dosta analize posledica promjenestrukture BP. ak i ako performanse nisu oteene izmjenama, moe doi do anomalija unosa,izmjene i brisanja ime se ugroava referencijalni integritet baze. U tom sluaju moraju sekreirati ogranienja koja obezbjeuju referencijalni integritet, umjesto da veina problema buderijeena normalizacijom. Denormalizacija se smije raditi ako :

- jednostavna normalizovana baza ne moe pomoi ;

-

denormalizacija nee ugroziti ukupne performanse sistema ;- denormalizacija nee ugroziti referencijalni integritet.Ako je jedan ili dva od ovih uslova ispunjen ne treba se pristupati denormalizaciji BP.

Postoje dva pristupa denormalizaciji sistema, kod prvog se normalizovane tabele mijenjajudenormalizovanim, gdje se dobija nova struktura BP, a kod drugog se zadravaju normalizovanetabele ali se dodavaju i denormalizovane.

4.1 esto pridruivane tabele (Prejoined tables)

Ako se nad dvije iste tabele iznova i iznova izvrava JOIN operator, onda treba razmisliti o

kreranju nove tabele koja sadri u sebi cijelu vezu. Ako imamo tabelu Radnik i tabelu Projekatkoje su u relaciji sa Slike 7, primjeujemo da je ID_Radnik postoji u tabeli Projekat kao spoljnikljusvoje matine tabele Radnik, ali je u isto vrijeme i dio primarnog kljua u tabeli Projekat.


22/37

Slika 7 : Relacija tabela Projekat i Radnik

Dakle, da bi se eliminisalo esto pridruivanje dvije tabele, one se mogu spojiti u jednu tabelugdje e atributi biti svi koji se tiu i Projekta i Radnika.

Tabela 14 : Tabela Projekti nakon spajanja

ID_Projekat Projekat_Naziv ID_Radnik Ime_prezime Radno_Mjesto Cijena_Sata1 Transport 101 Milo Nikoli Programer 201 Transport 102 Jovan Rai Analitiar 152 Izvoz 103 Milan Anti Dizajner 12

Samim tim to je u novoj tabeli kljuID_Projekat, ID_Radnik jasno je da se radnik ne moe dvaputa dodjeliti istom projektu.

4.2 Izvjetaji (Reports)

Tabelu prilagoenu za izvjetaj je teko definisati. Svrha ovakve tabele je kreiranje izvora za

izvjetaj iz jedne tabele bez JOIN-a umjesto kreiranja komplikovanih upita i uzimanja podatakaiz vie tabela. Takva tabela je oigledno predviena da ima jedan atribut za svaku kolonu naizvjetaju. Meutim, moe uvati razliite formate podataka u jednoj koloni, to je naruavanjeintegriteta podataka. Da bi se podaci prebacili u tabelu izvrie se komanda UNION, kojom sespajaju nesrodni podaci iz dvije ili vie tabela. Kada se radi unija tabela bitna stavka je i redosledkolona koji moe da se uredi ORDER BY operatorom. Takoe, kod unije izmeu nesrodnihtabela e se neminovno pojavljivati NULL vrijednosti, njih ureuje SQL standard koji ih uvijekreda ili na poetku ili na samom kraju seta podataka, ukoliko komandom ORDER BY nismodrugaije naveli.

4.3 Preslikane tabele (Mirrored Tables)

Preslikana tabela je kopija postojee tabele. Moe biti djelimina ili potpuna kopija, cilj jeduplicirati podatke iz originalne u novu tabelu. To je sofisticirana tehnika koja priprema podatkeza sisteme za podrku u odluivanju (Decision support systems DSS). Uobiajena sitaucija u BPje da se nad originalnom tabelom vre transakcije tokom redovne upotrebe. Poto su upiti kojidaju informacije DSS obino agregatni nad velikim brojem podataka, ako bi dopustili takve upiteu toku redovne upotrebe BP, to bi znaajno oslabilo performanse sistema, moda ak i blokiralo


23/37

bazu podataka. Iz tog razloga se od tabele naini duplikat nad kojim se radi zahtjevnoizvjetavanje, dok se nad originalom odvijaju transakcije i puni se novim podacima.

4.4 Razdvajanje tabela (Table Splitting)

Razdvajanje tabela se podrazumjeva cijepanje normalizovane tabele u dve ili vie novih tabela.Tabela moe biti pocijepana horizontalno (podskup njenih redova) ili vertikalno (podskup njenihkolona). Ako se u BP zadri i originalna tabela, ovo se moe posmatrati i kao specijalni sluajpreslikane tabele. Cilj ovog tipa denormalizacije je da se tabela iscijepa u manje tabele kojima ese upravljati bre ili lake. Te manje tabele mogu biti na taj nain formirane i aurirane da moguponuditi agregatne podatke. Kriterijumi za razdvajanje mogu biti razni a najei su :

a) Fiziki - jedna tabela za jedno prodajno mjesto umjesto za sva prodajna mjesta jednatabela.

b) Prostorni jedna tabela za svaku regiju umjesto jedna tabela za cijelu dravu.c) Vremenski jedna tabela za mjesec dana umjesto jedna tabela za cijelu godinu.d) Proceduralni jedna tabela za svaki korak u zadatku umjesto jedna tabela za cijeli

zadatak.e)

Administrativni jedna tabela za svako odjeljenje umjesto jedna tabela za cijelukompaniju.

Horizontalna podjela tabele se kreira sa operatorom UNION, dok se vertikalna podjela formiraINNER JOIN operatorom. Kod obje, opasnost je da nova tabela ima vie redova od originalnetabele to naravno ugroava integritet podataka.

4.5 Spajanje tabela (Combined Tables)

Spajanje tabela je poseban sluaj esto pridruivanih tabela (Prejoined tables). Razlika je u tometo je ovde sluaj sa tabelama izmeu kojih je veza JEDAN NA JEDAN. Obino je jedna tabelamnogo manja od druge i njihovo spajanje moe biti korisno.

Slika 7 : Izgled tabela Parking i Radnik sa relacijom

Primjer sa slike je korisno spojiti u jednu tabelu da bi se imali potpuni podaci koji se tiu radnikana jednom mjestu. Problem kod spojene tabele moe biti to to e se esto pojavljivati NULLvrijednost jer nemaju svi radnici parking mjesto, neki od njih koriste druga prevozna sredstva.Tim radnicima bi se u kolonu ID_Parking_Mjesto upisivala NULL vrijednost. Jo jedan problemu primjeru je i to to ova veza ne mora ostati JEDAN NA JEDAN. Direktor kompanije moe za


24/37

sebe rezervisati tri parking mjesta, ili pak vozilo moe zauzimati vie od jednog parking mjesta.U tim sluajevima model sa spojenom tabelom ne daje rezultat i ne bi trebao da se koristi.

4.6 Redundantni podaci (Radundant Data)

Ako seesto kolone iz jedne tabele koja se pridruuje drugoj koriste skupa sa kolonama iz drugeonda se moe uzeti u razmatranje da se kolone iz prve ukljue u drugu i time bi se eliminisalo

pridruivanje te dvije tabele. Ako se ovaj tip denormalizacije upotrebi potrebno je obratiti panjuna sledee :

a) ne treba prebacivati kolone koje ne uestvuju u esto korienom setu podataka ;b) poto e se podaci ponavljati, trebaju se uzeti u obzir za prebacivanje samo kolone

koje uvaju podatke koji se rijetko mijenjaju ;c) obavezno je procedurama ili trigerima na bazi uvati integritet podataka da ne bi

dolo do razlika jer je rizik vei im se u dvije tabele smjetaju isti podaci.

Slika 8 : Izgled tabela Odjeljenje i Radnik sa relacijom

Ukoliko imamo relaciju kao na slici i ako nam je podatak Odjeljenje_Naziv esto potreban u setupodataka o Radniku, ima smisla taj podatak prebaciti u tabelu Radnik, gdje bi spoljni klju

ID_Odjeljenje ostao kao spoljni klju, samo bi dodali i naziv odjeljenja da ubrzamo dobijanjeizvjetaja.

4.7 Ponavljajue grupe (Repeating groups)

Ponavljajua grupa je set kolona koje su dio grupe ili strukture podataka umjesto da buduatomski podaci (1 kolona 1 vrijednost). Ovaj tip denormalizacije se koristi kada treba prikazatipodatke agregatno. Pretpostavimo da imamo tabelu rauna u kojoj uvamo pojedinane raunekao u tabeli ispod.

Tabela 15 : Tabela Rauni

ID_Kupac Kupac_Naziv Raun ID_Robe Koliina Cijena1 Milo 1 101 2,00 20,002 Marko 2 249 1,00 4,003 Nikola 3 43 5,00 50,001 Milo 4 503 1,00 90,001 Milo 5 444 3,00 24,00


25/37

Primarni kljuove tabele bi bio ID_Kupac i Raun. Meutim, izvjetavanje iz ove tabelepodrazumjeva korienje operatora GROUP BY i agregatnih funkcija. Umjesto toga moe senapraviti tabela u kojoj se uvaju podaci za takav izvjetaj.

Tabela 16 : Denormalizovana tabela Rauni putem metoda ponavljajue grupe

ID_Kupac Kupac_Naziv Vrijednost1 Vrijednost2 Vrijednost3 Vrijednost41 Milo 40,00 90,00 72,00 NULL2 Marko 4,00 NULL NULL NULL3 Nikola 250,00 NULL NULL NULL

Iako je posle ovakvog zahvata kreiranje nekih izvjetaja i auriranje bre, postoje i neeljeniefekti. Oni se ogledaju kroz :

a) Broj kolona u tabeli je statian. Nova kolona se ne moe tako lako dodati. Za dodavanjevrijednosti ponekad e biti potrebno dodati novu kolonu.

b) Korisno je dok je broj kolona mali. Kad bi tabela imala veliki broj kolona, ovakvadenormalizovana tabela bi postala ogromna. ta ako se tabela proiri na stotine kolona

koje se odnose na vrijednost rauna.c) Grupi se pristupa kolektivno umjesto pojedinano. Set podataka se pretvara u set kolona

umjesto u set odabranih redova (sa pristupom preko atributa koji ih opisuju).d) Mora se prihvatiti rad sa NULL vrijednostima. Kod svakog unosa, izmjene ili brisanja se

mora voditi rauna o kolonama koje e primiti NULL vrijednost.e) Ne ele se zbrajati podaci itajui kolone kroz red u kom se nalaze. Kod takvog zbrajanja

moraju se predvidjeti mjesta gdje se NULL vrijednost moe pojaviti, a to postaje veomanaporno u ovakvoj strukturi.

4.8 Izvedeni podaci (Derivable Data)

Mnoge vrijednosti koje su potrebne kao rezultat upita se mogu dobiti proraunom drugihvrijednosti u istoj ili u drugoj tabeli u BP. Uvijek je bolje postaviti formulu u upit i dobiti rezultat

nego uvati rezultat prorauna u tabeli. Meutim, postoje situacije kada je rezultat preestopotreban ili proraun kompleksan da to opravdava pohranjivanje u BP. Tu je problem to seproraunata vrijednost mora aurirati kada se bilo koji parametar za izraunavanje promjeni, akose to propusti gubi se tanost podatka. Dobra stvar je to se moe u istoj tabeli uvati iproraunata vrijednost i parametri tako da se uvijek moe provjeriti da li je podatak taan. Kaoprimjer moemo navesti saldo potraivanja od kupca koji zavisi od kupljene i plaene robe.Skeniranje baze podataka svaki put kada je podatak potreban je sporo, tako da se ta vrijednostmoe uvati u podacima o kupcu, ali se uvijek moe nanovo izraunati jer postoje svi parametriza proraun.

4.9 Hijerarhijske tabele (Hierarchy Tables)

Hijerarhijska struktura podrazumjeva relaciju JEDAN NA VIE, koja se naziva i strukturastabla. Jedan roditelj moe imati vie naslednika a naslednik ne moe imati vie roditelja. Potoje to strogo ureena struktura podsjea na ureenje u dravi ili vojsci, ureenoj organizaciji. Kaoto se moe pretpostaviti, hijerarhijska struktura je bila dobro rjeenje za predstavljanje podatakakoji su ureeni hijerarhijski. Evo primjera hijerarhijski ureene tabele.


26/37

Tabela 17 : Hijerarhijska tabela RadnikRadnik ef PlataMilo NULL 1000,00Marko Milo 800,00Nikola Milo 800,00

Mirko Nikola 600,00Goran Nikola 600,00Zoran Nikola 500,00

Dobra stvar u ovakvom modelu je to je unos novog radnika veoma lak, sve to treba da se zna jeko je ef novom radniku. Ako je novi radnik Miroslav a Nikola mu je ef jednostavno se dodared (Miroslav,Nikola,400.00). Meutim, problemi ovakvog pristupa su :

d) ako se desi promjena imena meu zaposlenim, morali bi svi redovi gdje se spominjetaj radnik da budu promjenjeni.

e) ako radnik koji je istovremeno i ef grupi radnika bude otputen, osim to njegaizbriemo iz tabele morali bi izbrisati ili aurirati i sve redove gdje je on ef jer bez te

izmjene ugroavamo validnost podataka.f) jako je teko agregirati podatke nad hijerarhijskom tabelom. Izraunavanje plataefova i njihovih radnika bi podrazumjevalo pisanje veoma komplikovanogproceduralnog upita.

g) postoji opasnost od upisivanja podatka kojim se rui hijerarhijska koncepcija. Radnikse moe putem nepravilnosti pojaviti kao ef sopstvenim efovima. To bi programe iupite navelo da uu u stanje beskonanog skeniranja tabele.

4.10 Preoptereeni tipovi podataka (Overloaded DataTypes)

Ova vrsta denormalizacije se esto pojavljuje u tabelama koje su kreirane da uvaju prevod rijei

izme

u jezika.

Slika 9 : Izgled uobi

ajene postavke tabele Prevodi

To su tabele u kojima jedna ili vie stranih rijei ima isto znaenje. U primjeru gore svi atrubutiine kompozitni primarni klju. Umjesto postojee strukture tabele bi mogli da dodamo kolonuTip_Prevoda koja bi se odnosila na to sa kog se jezika prevodi na koji (1 za srpski/engleski ili 2za engleski/srpski). Takoe, promjenili bi i ostale kolone, od postojeih bi ostale dvije RijeiZnaenje. U obe kolone bi se uvala viestruka vrijednost. Znai jedan red bi mogao ovako daizgleda (1, OVEK, MUKO, MUKARAC, LJUDI,CHAP, FELLOW, GUY, HUMAN,


27/37

MEN, MORTAL, PERSON). Naravno, to ne znai da prvom podatku u koloni Rijeodgovaraprevod iz kolone Znaenje sa prve pozicije, nego da u irem smislu pojmovi iz kolone RijeiZnaenje poklapaju dovoljno da se ponude kao predlozi za prevod. U novoj postavci PK bi bioTip_Prevoda i Rije. Pretraga pojmova po ovakvoj tabeli je veoma brza. Meutim, kao i ostalipristupi u denormalizaciji i ovaj ima nedostatke :

a)

veliina - tabela

e zauzimati mnogo ve

i prostor na hard disku nego prvi pristup;b) tipovi podataka - poto se svi prevodi dre u jednoj koloni, ta kolona mora biti tipa

STRING (VarChar n) maksimalne veliine. VarChar nije najzgodniji za koritenje, npr.pristup koloni tipa Char je mnogo bolje podran kroz SQL. Tipovi podataka nisu uvijekpogodni za sve to e se pojavljivati u njima;

c) validnost - izuzetno je teko uvati ispravnost podataka nad ovakvom gigantskomtabelom;

d) fleksibilnost jasno je da zbog ogromnog broja podataka i naina uvanja tabela nijepodlona lakim izmjenama;

e) sigurnost da bi se izbjegle greke u auriranju tabele potrebno je napraviti setovepodataka za pretraivanje. Takoe, korisniku je potrebno ograniiti pristup izmjenama da

ne bi mogao vriti izmjene van svojih ovlaenja;f)

normalizacija glavni razlog zbog kog je ovaj tip denormalizacije problematian je tajto naruava prvu NF. Iako ima PK i sve vrijednosti kolone su istog tipa ipak se u jednojkoloni uva vie vrijednosti.

V PRAKTIAN PRIMJER

U ovom dijelu e biti prezentovana praktina realizacija jednog realcionog sistema, teoretskepostavke na kojima poiva relacioni model podataka, sa povremenim osvrtima na razlike izmeuteorije i prakse. Takoe, predstavljena baza podataka nije namjenjena za voenje davanja uslugau nekoj uskoj oblasti nego se moe koristiti za evidenciju davanja usluga u bilo kojoj oblastiprivrede jer ima sve osnovne parametre sa velikim stepenom fleksibilnosti. Baza podatakaodgovara i knjigovodstvenim agencijama jer se mogu istovremeno voditi podaci o viepreduzea, gdje se podaci razdvajaju po preduzeima dijelom kompozitnog kljua.

5.1 Rijenik podataka

FK_DRZAVA,< SIS_DATUM>>FK_GRUPAKOMT,< SIS_DATUM>>FK_KOMT,,,,,,,,,,,,,< SIS_DATUM>>FK_MESTO,,< SIS_DATUM>>


28/37

FK_PRED,< SIS_DATUM>>FK_RACUN

>FK_REGIJA,,< SIS_DATUM>>FK_UPLATA,>FK_USLUGA,,< SIS_DATUM>>FK_VR_DOK

,< SIS_DATUM>>KORISNIK>FK_BANKA,< ADRESA>,< TELEFON>,< SIS_DATUM>>FK_NARUDZBA>

Tabela 18 : Definisanje polja u rijeniku podatakaNAZIV POLJA DOMEN OGRANIENJE

SIFRA SMALLINT(3) NOT NULLNAZIV CHAR(50)

SIS_DATUM TIMESTAMPSIFRA SMALLINT(3) NOT NULLNAZIV CHAR(50)

SIS_DATUM TIMESTAMPPRED SMALLINT(3) NOTNULLSIFRA INT(6) NOT NULLNAZIV CHAR(70)

ADRESA CHAR(70)ZIRORACUN CHAR(50)

OPIS BLOBTELEFON CHAR(25)PDV_BROJ CHAR(14)

MESTO SMALLINT(3)GRUPAKOMT SMALLINT(3)

EMAIL CHAR(30)WEB CHAR(30)

JIB_BROJ CHAR(13)


29/37

INOSTRANI_DA BIT IN(0,1)KOMT_PDV BIT IN(0,1)SIS_DATUM TIMESTAMP


REGIJA SMALLINT(3)SIS_DATUM TIMESTAMPSIFRA SMALLINT(3) NOT NULLNAZIV CHAR(70)MESTO SMALLINT(3)

ADRESA CHAR(30)TELEFON CHAR(20)

FAX FAX(20)EMAIL CHAR(30)WEB CHAR(30)

ZIRORACUN CHAR(50)

JIB CHAR(13)MATICNI CHAR(15)

POCETNI_KAPITAL DECIMAL(12,2)OPSTINA CHAR(30)VLASNIK CHAR(25)

PDV_OBVEZNIK BIT IN(0,1)SIS_DATUM TIMESTAMP

PRED SMALLINT(3) NOT NULLVR_DOK SMALLINT(3) NOT NULL

DOK MEDIUMINT(5) NOT NULLRBR SMALLINT(3) NOT NULL

DATUM DATEUSLUGA SMALLINT(3)

KOMT INT(3)NAPOMENA MEDIUMTEXTKOLICINA DECIMAL(12,2)

CIJENA DECIMAL(12,2)VALUTA_PLACANJA DATEPROCENAT_POREZA DECIMAL(5,2)

KORISNIK CHAR(10)SIS_DATUM TIMESTAMP

SIFRA SMALLINT(3) NOT NULLNAZIV CHAR(30)DRZAVA SMALLINT(3)

SIS_DATUM TIMESTAMPPRED SMALLINT(3) NOT NULLRBR SMALLINT(3) NOT NULL

DATUM_UPLATE DATEKOMT INT(6)


30/37

RACUN CHAR(15)IZNOS DECIMAL(12,2)

KORISNIK CHAR(10)SIS_DATUM TIMESTAMP

PRED SMALLINT(3) NOT NULL

SIFRA SMALLINT(3) NOT NULLNAZIV CHAR(50)POREZ_DA BIT IN(0,1)SIS_DATUM TIMESTAMP


SIS_DATUM TIMESTAMPKORISNIK CHAR(10) NOT NULL

SIFRA CHAR(10) NOT NULLNAZIV CHAR(50)SIFRA SMALLINT(3) NOT NULL

NAZIV CHAR(50)ADRESA CHAR(50)TELEFON CHAR(30)

SIS_DATUM TIMESTAMPPRED SMALLINT(3) NOT NULLDOK MEDIUMINT(5) NOT NULLRBR SMALLINT(3) NOT NULL

DATUM DATEKOMT INT(6)

USLUGA SMALLINT(3)KOLICINA DECIMAL(12,2)KORISNIK CHAR(10)

SIS_DATUM TIMESTAMP

5.2 Relacioni model

FK_DRZAVA(SIFRA#,NAZIV, SIS_DATUM)FK_GRUPAKOMT(SIFRA#, NAZIV,SIS_DATUM)FK_KOMT(PRED#,SIFRA#, NAZIV, ADRESA,ZIRORACUN,OPIS,TELEFON,PDV_BROJ,#MESTO,#GRUPAKOMT,EMAIL,WEB,JIB_BROJ,INOSTRANI_DA,KOMT_PDV, SIS_DATUM)FK_MESTO(#SIFRA,NAZIV,#REGIJA,SIS_DATUM)FK_PRED(#SIFRA,NAZIV,#MESTO,ADRESA,TELEFON,FAX,EMAIL,WEB,ZIRORACUN,JIB,MATICNI,POCETNI_KAPITAL,OPSTINA,VLASNIK,PDV_OBVEZNIK,SIS_DATUM)FK_RACUN(#PRED,#VR_DOK,#DOK,#RBR,DATUM, #USLUGA,#KOMT,NAPOMENA,KOLICINA,CIJENA, VALUTA_PLACANJA,PROCENAT_POREZA,#KORISNIK, SIS_DATUM)FK_REGIJA(#SIFRA,NAZIV, #DRZAVA,SIS_DATUM)


31/37

FK_UPLATA(#PRED,#RBR,DATUM_UPLATE, #KOMT,RACUN,IZNOS,#KORISNIK,SIS_DATUM)FK_USLUGA(#PRED,#SIFRA,NAZIV,POREZ_DA,SIS_DATUM)FK_VR_DOK(#SIFRA, NAZIV,SIS_DATUM)KORISNIK(#KORISNIK,#SIFRA,NAZIV)

FK_BANKA(#SIFRA,NAZIV, ADRESA, TELEFON,SIS_DATUM)FK_NARUDZBA(#PRED,#DOK,#RBR,DATUM, #KOMT,USLUGA,KOLICINA,#KORISNIK,SIS_DATUM)

Uzimajui u obzir predoeni rijenik podataka i relacioni model BP neto vie emo rei osamim tabelama i njihovim relacijama.

Tabele fk_drzava, fk_mesto, fk_regija, fk_grupakomt su tabele koje daju velike mogunosti zaizvjetavanja iz baze podataka. Samim postojanjem spoljnjeg kljua npr. Mesto u tabeliKomitent i istoimene tabele daje mogunost pregleda prometa usluga sa komitentima pomjestima odakle dolaze to pomae u planiranju razvoja preduzea. Ista stvar je i sa drugim

opisnim atributima u tabelama, npr. atribut entiteta Mesto je Regija to daje nove mogunosti upraenju poslovanja firmom. Sve ove opcije daju mogunost zahtjevnih upita koje daju opcije

pregleda prometa po dravama odakle kupci dolaze, regijama, gradovima, kao i mogunostkorisinka da napravi sopstvenu grupu kupaca koju bi posebno da prati kroz atribut Grupakomt utabeli Fk_Komt. Naravno, i ostali podaci mogu posluiti za ukrtanje i prikazivanje izvjetaja,meutim ove istiem jer im je funkcija iskljuivo opisna i pogodna za izvjetaje.

Tabela Fk_Komt koja sluzi za evidenciju kupaca ima u sebi njegove znaajne atribute ali ne sve.Na ovo obraamo panju jer je klijent-preduzee mnogo vie od njegovih osnovnih podataka.Primjetiete da nema podataka o vlasniku ili osnivakom kapitalu klijenta to nisu primarneinformacije za poslovanje sa preduzeem. Tu dolazimo do toga da BP daje podatke prenesene izrealnog svijeta ali samo one koji su prepoznati kao bitni, ostali se zanemaruju jer svaka tabela ubazi podataka treba da bude minimalistika, da zadovoljava potrebe za bitnim informacijama.

Tebela preduzee pak, skladiti informacije o preduzeu koje prodaje usluge. Ona treba dazadovolji i odreene zakonske procedure koje treba da se iskazuju na raunima prema kupcima.Tako da ona ima podatke poput onog u kojoj optini je registrovano preduzee. Preduzea suifrirana, i mogue je ispratiti da se preduzee kao spoljni kljupominje i u drugim tabelama i tokao dio PK druge tabele. To je zbog toga da bi se mogli skladititi podaci o vie preduzeaistovremeno u BP, svi ti podaci su odvojeni ifrom preduzea kojoj odreeni podatak pripada. Todalje implicira da ukoliko se korisnik uloguje u sistem pod odreenom ifrom preduzea bie muvidljivi podaci samo o preduzeu koje je prilikom prijave na sistem izabrao.

O glavnoj tabeli ovog modula baze podataka emo malo vie rei. Tabela Fk_Racun jeorganizovana putem kompozitnog kljua. Atribut pred oznaava vepomenuto preduzee injegova funkcija je objanjena. Sledi polje vr_dok koje je spoljni kljui odnosi se na vrstudokumenta koji se u tom momentu kreira (Raun, Predraun itd). Unutar oznake preduzea,uzimajui u obzir da je npr. u pitanju Raun postoji polje dok koje oznaava dokumente koji seredom prave kao Rauni. Poto je kljuu tabeli hijerarhijski organizovan, jedno preduzee moeimati vie vrsta dokumenta, istovremeno jedna vrsta dokumenta moe imati jako puno instanci.


32/37

Poslednje polje u kljuu je rbr, redni broj stavke koja omoguuje vie stavki u okviru jednogdokumenta. Kombinacijom ova etiri atributa dobijamo sve varijante koje su potrebne da bazapodataka bude fleksibilna. Ukoliko se stvori potreba za jo vrsta dokumenata, prostimregistrovanjem u tabeli Fk_Vr_Dok dobijamo podatak koji moemo izabrati prilikom rada satabelom Fk_Racun, gdje e baza moe odmah da pone sa odvajanjem dokumenata koji

pripadaju novoj vrsti dokumenta. Primjetimo, mnogi kreatori baza podataka imaju obiaj daskladite polje prodajni iznos u ovakvim tabelama, meutim to je krenje 3NF. Ona kae da se ne

bi trebali skladititi izvedene atribute, tj koje moemo dobiti kombinacijom druga dva. Premaformuli koliina*cijena=prodajni iznosjasno je da se prodajni iznos uvek moe dobitimnoenjem druga dva atributa. Meutim, poto je baza podataka uvijek kompromis izmeupravila i dostupnosti podacima ponekad se svjesno prekri NF. U velikim i komplikovanimbazama stalno mnoenje dva polja moe biti naporno, mnogi se odluuju da ipak uskladite ovajpodatak radi lakeg pristupa. Ista situacija je i sa procentom i iznosom poreza. Iznos poreza jebitan podatak, ali ukoliko imamo procenat uvijek mozemo izraunati iznos tako da ga ne bitrebalo kao uvati u bazi podataka. Ostali podaci se odnose na podatke o datom dokumentu istavci, kupac, koliina, cijena itd.

Tabela usluga nam daje osnovne podatke o usluzi koja se prodaje. Podatak Porez_da implicira naatribut tipa Yes/No, pri tom se misli na to da li je data usluga oporeziva ili ne.

U tabeli Fk_Uplate skladitimo podatke o uplatama kupaca gdje imamo atribut banka koji govorio iroraunu na koji je iznos uplaen, kao i na osnovu kog izdatog rauna je uplata izvrena. Ovonam daje bolji uvid u praenje samog poslovanja preduzea, jer razlika izmeu sume iznosaizdatih rauna i zbira uplata po komitentu znamo koliko je dobra naplata, kao i koji je preostalidug kupca. Naravno, u tabeli imamo i podatak o datumu kad se uplata desila i o korisniku koji jeaurirao BP zbog osnovne kontrole.

Fk_Naruzdba slui za pohranjivanje naruenih usluga od strane kupaca. Na osnovu nje imamouvid u to ta e se raditi u buduem vremenu, kao i projekcija potencijalnih prihoda.


33/37


34/37

5.3 Dijagram konteksta, prvi i drugi nivo dekompozicije

Slika 11 : Dijagram konteksta

Slika 12 : Prvi nivo dekompozicije


35/37


36/37

5.4 Model objekti-veze


37/37

Literatura

[1] Carlos Coronel, Steven Morris, Peter Rob, Databases system Design,Implementation, and management, Cengage Learning 2010.

[2] Christopher J. Date, An Introduction to Database Systems, C. J. Date, 2003.

[3] Jan L. Harrington, Relational Database Design, Morgan Kaufmann Publishers, 2002.[4] Joe Celkos, Data and databases: Concepts in Practice, Morgan Kaufmann Publishers,1999.

[5] VeinoviMladen, Goran imi, Uvod u baze podataka, Univerzitet Singidunum,Beograd, 2010.

[6] http://www.databasejournal.com/[7] http://en.wikipedia.org/wiki/Main_Page

Documents

Normalizacija i Relacione Baze