UNIVERZITET SINERGIJA BIJELJINA

FAKULTET ZA POSLOVNU INFORMATIKU

DIPLOMSKI RAD









Kandidat
Milo Nikoli

BIJELJINA, 2013



UNIVERZITET SINERGIJA BIJELJINA

FAKULTET ZA POSLOVNU INFORMATIKU






Kandidat : Milo Nikoli broj indeksa 26/2008

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

Cilj rada :
Teze :
1. Uvod
2. Struktura relacione baze podataka
3. Normalizacija
4. Denormalizacija
5. Praktian primjer
6. Zakljuak













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


Bijeljina, 2013
1

SADRAJ

1. Uvod.2
2. Struktura relacione baze podataka...3
2.1 Model relacione baze podataka..5
2.2 Relacije u bazi podataka7
2.3 Atributi...8
2.4 Kandidat klju, primarni klju, spoljni klju.8
2.5 Ogranienja i pravila integriteta podataka.....9
3. Normalizacija.10
3.1 Anomalije unosa, auriranja i brisanja.10
3.2 Funkcionalna zavisnost11
3.3 Prva normalna forma13
3.4 Druga normalna forma.14
3.5 Trea normalna forma..16
3.6 Bojs/Kodova normalna forma..16
3.7 etvrta normalna forma...18
4. Denormalizacija.19
4.1 esto pridruivane tabele.19
4.2 Izvjetaji...20
4.3 Preslikane tabele..20
4.4 Razdvajanje tabela...20
4.5 Spajanje tabela.21
4.6 Redundantni podaci.21
4.7 Ponavljajue grupe...22
4.8 Izvedeni podaci23
4.9 Hijerarhijske tabele..23
4.10 Preoptereeni tipovi podataka24
5. Praktian primjer baze podataka25
5.1 Rijenik podataka.25
5.2 Relacioni model...28
5.3 Dijagram konteksta, prvi i drugi nivo dekompozicije.32
5.4 Model objekti-veze..34
6. Zakljuak
7. Literatura35




2

I - UVOD

Kroz istoriju je termin baza podataka dobijao razna znaenja. Najprije je bio koriten da oznai
jednu tabelu, ili kako se to ranije nazivalo datoteku. Zatim je oznaavao samo skup odreenih
tabela, 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 (datoteke
povezane vezom roditelj/naslednik , gdje svaki naslednik moe imati najvie jednog roditelja, a
roditelj 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 jednog
vlasnika). 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 su
previe novca.

Danas se pod terminom baza podataka podrazumijeva kolekcija meusobno povezanih podataka
uskladitenih 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 ureenja 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 radu
iz 1970 A Relational Model of Data for Large Shared Data Banks
2
, ime postavlja paradigmu
relacione baze podataka. Relacioni model podataka bio je veliki iskorak naprijed, jer omoguava
vezu izmeu datoteka na nivou kolone u datotekama(tabelama). Da bi ostvarili vezu meu
tabelama u relacionom modelu potrebno je samo da imaju minimum jedan zajedniki atribut, to
ini 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 magazinu
Communications of ACM, 1970 godine.
3


II - STRUKTURA RELACIONE BAZE PODATAKA

Dolazak do relacione baze podataka podrazumijeva kreiranje modela podataka, najprije
konceptualnog, 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 vrste
apstrakcija i daje semantiki zadovoljavajui opis sloenog sistema. Relacioni model podataka je
danas najrasprostranjeniji model podataka jer za njega postoji dosta komercijalno raspoloivih
sistema za upravljanje bazama podataka.

Svaka baza podataka nastaje iz modela podataka. Model podataka je intelektualno sredstvo za
prikazivanje objekata sistema, njihovih atributa i meusobnih veza (statikih karakteristika
sistema) preko logike strukture baze podataka. Svaki model podataka posjeduje tri osnovne
komponente:

a) Struktura modela skup koncepata za opisivanje objekata sistema, njihovih atributa i
meusobnih veza
b) Ogranienja semantika ogranienja na vrijednost podataka koja se ne mogu predstaviti
samom strukturom modela, a koja u svakom trenutku moraju biti zadovoljena (pravila
integriteta)
c) Operacije operacije nad konceptima strukture podataka, pod definisanim
ogranienjima, 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 koja
se moe ugraditi u model podataka, modeli podataka se mogu podeliti u generacije. Postoje
sledee tri generacije modela podataka:
1. Modeli podataka I generacije
2. Modeli podataka II generacije
3. Modeli podataka III generacije

1. Za modele podataka I generacije je karakteristino da je svaki konvencionalni programski
jezik zaseban model podataka. Podaci se modeluju koritenjem koncepata kojima dati
jezik raspolae. Modeli podataka I generacije i na njima zasnovani programski jezici nisu
dovoljno pogodni za modelovanje realnog sistema, pa im je praktina upotreba
ograniena.
2. Modeli podataka II generacije za prezentaciju podataka koriste naprednije koncepte nego
modeli podataka I generacije, ali koriste iste apstrakcije kao i modeli podataka I
generacije. Moe se definisati baza podataka kao skup meusobno povezanih podataka. I
pored toga to su semantiki bogatiji od modela podataka I generacije, ne mogu dati
4

semantiki zadovoljavajui opis sloenog sistema. Ovoj generaciji pripadaju sledei
modeli podataka:
- funkcionalni model podataka
- hijerarhijski model podataka
- mreni model podataka
- klasini relacioni model podataka
Vrlo 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 poseduju
mehanizme za najbolji opis realnog sistema, a korisniku su razumljivi. Ovoj generaciji
pripadaju 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 bazom
podataka.

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 koji
se 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 sa
drugim relacijama. Teorija relacionog modela kae da redovi u tabeli ne posjeduju implicitni
poredak. To znai da je poredak fleksibilan i da se moe naznaiti prilikom konstruisanja upita
za bazu podataka. Kao u sluaju redova ni kolone ne moraju imati predodreen poredak, zbog
toga se kae da relaciona baza prua logiku nezavisnost podataka.
5


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 postavio
pravila 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 ne
ispunjavaju u potpunosti. Pravila ima trinaest, numerisana su od nule do dvanaest.
0. Sistem se mora kvalifikovati kao relacioni, kao baza podataka, i kao sistem za
upravljanje.
Da bi sistem za upravljanje bazom podataka nazvali relacionim, on iskljuivo mora
koristiti 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 reformulacija
osnovnog zahtjeva za postojanjem primarnih kljueva. Ono zahtjeva da je svaka
pojedinana 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 vrijednost
nalazi.

6

3. Sistemsko tretiranje NULL vrijednosti :
Sistem mora dozvoljavati da svako polje po potrebi moe ostati prazno (imati vrijednost
NULL). Mora podravati predstavljanje informacija koje nedostaju ili se ne mogu
dodjeliti, koje je sistematino, razliito od svih regularnih vrijednosti (npr. razliito od
nule 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 katalog
dostupan autorizovanim korisnicima kroz upotrebu standardnog upitnog jezika. To znai
da 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 koji
a) 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 i
autorizaciju, 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 podaci
iz relacione baze mogu izdvajati u skupovima koje ine podaci iz vie redova i vie
tabela. Ovo pravilo naglaava da operacije dodavanja auriranja i brisanja budu
primjenjive na bilo koji skup podataka koji se moe izdvojiti iz baze, a ne samo na
pojedinani red u jednoj tabeli.
8. Fizika nezavisnost podataka :
Promjene na fizikom nivou (nain na koji se uvaju podaci) ne smiju zahtjevati
promjene aplikacija zasnovanih na datoj strukturi.
9. Logika nezavisnost podataka :
Promjene na logikom nivou (tabela, kolona, redova itd.) ne smiju zahtjevati promjene
aplikacija zasnovanih na datoj strukturi. Mnogo je tee postii logiku nego fiziku
nezavisnost.
10. Nezavisnost od pravila integriteta :
Pravila integriteta moraju biti definisana nezavisno od aplikativnih programa i sauvana u
katalogu. Mora biti predviena mogunost njihove izmjene u bilo kom trenutku bez
nepotrebnog 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 jednim
redom u datom trenutku), onda oni ne mogu biti korieni za napad na sistem, u smislu
zaobilaenja pravila integriteta ili sigurnosti relacija u sistemu.
7



Model nije stvaran svijet nego njegov pojednostavljen prikaz. Model koji je komplikovaniji od
entiteta koji opisuje je bezvrijedan u modeliranju baze podataka. Entitet u sistemu moe
predstavljati 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 moi
jednoznano 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 moe
imati nekoliko uloga, moe biti zaposleni, saradnik, vlasnik ili kupac. Ako bi htjeli da
predstavimo jo detaljnije entitet ovjeka u pomenutom sistemu mogao bi da ima razliite
atribute i ovlaenja u zavisnosti od uloge u sistemu. ef u kompaniji moe otpustiti radnika ali
radnik ne moe efa iako su u sistemu predstavljeni kao isti entitet ovjek. Isti entitet bi mogao
ako je vlasnik da ima neke druge atribute i ovlaenja. Postavlja se pitanje da li model treba da se
bazira na pojedincu ili na ulogama koje bi mu se dodjelile. Veina baza podataka se bazira na
ulogama koje se dodjeljuju pojedincu u sistemu baze podataka zbog lake manipulacije
ovlaenjima 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 izmeu
primarnog kljua jedne tabele i spoljnjeg kljua druge. Mogu se razlikovati tri tipa relacija koje
se uglavnom realizuju preko prve dvije navedene relacije :
- JEDAN NA JEDAN
To znai da jednom redu jedne tabele odgovara tano jedan red druge tabele. Npr., ako se
u jednoj tabeli uvaju podaci o firmama, a u drugoj o njihovim sjeditima i to je veza
jedan-jedan (one-to-one).
- JEDAN NA VIE
Jednom redu prve tabele moe odgovarati vie redova druge tabele. Jedan kupac moe
imati vie porudbina. (one-to-many)
- VIE NA VIE
Jednom redu prve tabele moe odgovarati vie redova druge, ali vai i obrnuto, jednom
redu druge tabele moe odgovarati vie redova prve tabele. Dobar primjer je tabela u
kojoj uvamo sve dostavljae robe u nekoj firmi, a u drugoj tabeli sve vozila koje
dostavljai koriste.Veza je vie-vie, jer jedan dostavlja moe koristiti vie vozila,
(recimo da ima deset dostavnih vozila) ali i isto vozilo moe koristiti koristi vie
dostavljaa. U praksi se ova veza razbija na dvije veze jedan-vie :



VIE NA VIE
_________________________________________________________ (transformie se)
JEDAN NA VIE
VIE NA JEDAN
8

2.3 Atributi

Atributi pripadaju entitetu i definiu ga. Njemaki matematiar Lajbnic
2
je otiao korak dalje i
rekao 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 sluaj u SQL
3
koji i pored toga to sledi relacionu
teoriju ima ureene redove u tabelama. Ono to je vano naglasiti je to da se kod definisanja
atributa entiteta uzimaju u obzir atributi koji su zahvaeni poljem interesovanja kojim se bavi
baza podataka. Ako modelujemo entitet Vozilo u firmi, vani atributi bi bili broj sjedita, godina
prve registracije, sledei servis i dr. Iako postoji u stvarnom svijetu atribut boja vozila se ne bi
uzimao u obzir prilikom definisanja atributa. S druge strane, ukoliko se kod atributa ponu
uoavati njegovi atributi kao bitni, onda bi se dati atribut trebao u sistemu izdvojiti kao poseban
entitet. To u praksi znai da ako imamo tabelu vozilo i atribut model vozila, model vozila zbog
vanosti sopstvenih atributa trebao bi postati novi entitet, gdje bi postojala relacija izmeu
glavnog entiteta vozilo i entiteta model vozila.

2.4 Kljuevi

Kandidat klju moe biti sastavljen od jednog ili vie atributa koji nepogreivo treba da
oznaavaju jedan red u tabeli. Definicija relacije kae da je svaki red u tabeli jedinstven, znai da
se analizom kolona moe uoiti jedna ili vie kolona koje identifikuju svaki red. U
jednostavnijim tabelama e se nametnuti jedna kolona za primarni klju, kao to je sluaj u tabeli
Radnik sa Slike 1, gde je primarni klju atribut ID Radnik. U drugim sluajevima to e biti dvije
ili vie kolona i takav primarni klju (PK) se naziva kompozitni ili sloeni primarni klju. Takav
primjer imamo u tabeli Ponuda, gdje primarni klju ine atributi ID Ponuda, ID Firma (firma
koja iznosi ponudu) i ID Roba (roba kao predmet ponude). U najgorem sluaju to mogu biti sve
kolone u tabeli, to moe biti znak da se nije na pravi nain modelovala tabela. Da bi izabrali
primarni klju od 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 vie
atributa. Spoljnim kljuem se naziva svaki atribut koji postoji u drugoj tabeli sa istim
vrednostima. Takoe, atribut koji je dio veze izmeu tabela moe biti u primarnom kljuu tabele
A ili tabele B. Moe biti primarni klju ili dio njega u obe ili ni u jednoj. Po ovim osobinama
atributa za vezu moe da se primjeti velika fleksibilnost povezivanja izmeu tabela. Iako se
spoljni klju ne mora naznaiti, preporuljivo ga je obiljeiti zbog preglednosti modela baze
podataka. U gornjem primeru modela baze podataka (BP) u tabeli Firma postoji spoljni klju ID
Radnik 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 binarni
sistem brojeva, koji je osnova dananjih raunara.
3 Structured Query Language (struktuirani upitni jezik) je programski jezik specijalne namjene koji slui za
upravljanje realcionim bazama podataka
9

2.5 Ogranienja i pravila integriteta podataka

Opta ogranienja (pravila integriteta) su ogranienja sadraja baze podataka na neka dozvoljena
stanja. 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 klju ili su njegov dio ne
mogu uzeti NULL vrijednost, dakle vrijednosti za te atribute mora biti unijeta (za tabelu
Radnik to bi znailo da se ID Radnik obavezno mora unijeti !).
- Referencijalni integritet: ukoliko su dvije tabele u relaciji (npr.Firma i Radnik), tada
svaka vrijednost atributa koje je spoljni klju (ID Radnik u tabeli Firme) mora biti ili
jednaka vrijednosti primarnog kljua (ID Radnik u tabeli Radnik) ili NULL vrijednosti.
Drugim rijeima, kada se unosi ID radnika u tabeli Firma, kolona sa tom vrijednou
mora 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 ogranienja i te kako imaju veze
sa 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 baze
podataka.
C J. Date
7
u svojoj knjizi Introduction to Database Systems iznosi tvrdnju koju naziva Golden
Rule (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 podataka
koja 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 neispravnost
podataka. Pod ispravnim podacima se podrazumjevaju podaci samo ako odraavaju stvarno
stanje interesne sfere u realnom svijetu. Integritet podataka se ne odnosi samo na ogranienja na
tabelama zbog ispravnosti, nego i na ispravnost podataka dobijenih upitima.

U praksi se esto javlja sluaj nedostatka informacija koje su potrebne. Na primjer ako se vodi
evidencija o ponuenoj robi, pri emu se zavode podaci o robi, ta da se radi u situaciji kada
grupa robe nije prethodno definisana? Svaki dobar model realnog sistema mora pruiti
mogunost 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 dvije
grupe:
- Prvu grupu ine ogranienja na vrijednosti koje moe primiti neki atribut (npr. ID Robe
ne moe biti slovo, niti manja od nule, a mora biti u opsegu od -2^31 (-2,147,483,648) do
2^31-1 (2,147,483,647)) i koja ne zavise od vrijednosti ostalih atributa.


_______________________
7 - Christopher J. Date (1941 -), izdava i autor knjiga o bazama podataka, autor Introduction to Database Systems
10

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

III - NORMALIZACIJA

Normalizacija predstavlja sistemski metod za osiguravanje da je struktura baze podataka
pogodna za upite opteg tipa, da se smanji mogunost redundancije podataka, da se smanji
mogunost pojave anomalija unosa, auriranja i brisanja koje bi mogle da dovedu do gubitka
integriteta podataka. Normalizacija je i iterativni proces tokom koga se vri reorganizacija baze
podataka u cilju izbjegavanja redundanse i poveanja stabilnosti baze podataka. Postupak je
podran i teoretski, ali posle stalnog rada u relacionom modelu se pokazuje da je
zdravorazumsko razmiljanje najbolji osnov za izvravanje procesa normalizacije. Kasnije se
moe izvriti provjera postupka normalizacije primjenom procedura za provjeru normalnih formi
u 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 normalizacije
obino podrazumjeva predvianje problema koji bi se mogli pojaviti (takav pristup je ponekad
neophodan s obzirom na slabu odvojenost logikog i fizikog modela). Proces normalizacije je
zasnovan 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 pravila
za uspostavljanje relacionog modela ustanovio Ted Kod. Baza se smatra normalizovanom
ukoliko potuje pravila iz prve tri normalne forme (NF). Posle 3NF dolazi Bojs
9
/Kodova
normalna forma (BCNF) i proizala je iz zajednikog rada pomenute dvojice strunjaka. S druge
strane, to viu NF baza podrava vie je relacija u njoj, vie JOIN operatora zbog ega je tee
doi do specifinog podatka, a baza koristi vie resursa da bi odgovorila na zahtjev. Jedan od
problema je i to to detekcija nepravilnosti koje definie peta i vie normalne forme ne moe da
se obavi bez raunarske analize.

3.1 Anomalije unosa, auriranja i brisanja

Pretpostavimo da imamo tabelu sa tri kolone, student, predava i predmet. U korist primjera
pretpostavimo 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 definisao etvrtu
po redu Bojs/Kodovu normalnu formu
11

Tabela 1 : Predmeti
STUDENT PREDAVA PREDMET
MILO SIMI MREE
GORAN SIMI MREE
MARKO JOVANOVI MATEMATIKA

Anomalija unosa (insert-a) : Kada bi pokuali da dodamo novog studenta na Matematiku, morali
bi da znamo da je predava na predmetu Matematika Jovanovi, inae ne bi mogli izvriti
komandu dodavanja.
Anomalija izmjene (update-a) : Goran se odluuje na promjenu predmeta na Programiranje zato
to su Mree preteke kod predavaa Simia. Naalost, ovo bi kreiralo red
(Goran,Simi,Programiranje) to stvara netaan podatak da je Simi predava na predmetu
Programiranje.
Anomalija brisanja (delete) : Ako predava Jovanovi odustane od predavanja Matematike,
brisanje reda (Marko,Jovanovi,Matematika) bi grekom izbacilo Marka sa predmeta
Matematika. Moemo pretpostaviti da fakultet nee ukinuti predmet Matematika iako je
Jovanovi dao otkaz.
Rjeenje za sprjeavanje anomalija iz primjera je da se studenti i predavai podjele u dvije
tabele. U tom sluaju bi se Predmetima dodjeljivali Predava i Studenti.

3.2 Funkcionalna zavisnost

Za shvatanje normalizacije veoma je vano razumjeti pojam funkcionalne zavisnosti (FZ) za datu
relaciju. U toku procesa normalizacije analizira se posebno svaka relacija, identifikuju se
zavisnosti u relaciji i ako je potrebno pristupa se normalizaciji. Na osnovu identifikovanih
zavisnosti pristupa se postepenom ralanjivanju relacija u set novih relacija (tabela). Relacije
koje se pojavljuju u identifikovanju funkcionalne zavisnosti utvrdio je kandaski matematiar i
inenjer raunarstva Vilijam V. Amstrong u svom djelu iz 1974. Dependency structures of
database relationships. Zakonitosti koje iznosi su poznate pod nazivom Amstrongove aksiome.

Tabela 2 : Koncept funkcionalne zavisnosti - identifikacija zavisnosti
Koncept Definicija


Funkcionalna zavisnost
Atribut B je potpuno zavisan od atributa A ako
svaka vrijednost atributa A odreuje jednu jedinu
vrijednost B.
Primjer : ID radnik ime i prezime
(ita se kao ID radnik funkcionalno odreuje ime
i 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 u
tabeli za atribut A slau sa vrijednosti atributa B.
Potpuna funkcionalna zavisnost (kompozitni klju) Ako je Atribut B funkcionalno zavisan od
kompozitnog kljua A, ali ne od svakog podskupa
kompozitnog kljua onda kaemo da je B potpuno
funkcionalno zavisan od A.


12

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 5
2 Marko Jovanovi Cara Uroa 11 Referent 3

Poto je primarni klju tabele ID Radnik, svaka vrijednost pomenutog atributa jednoznano
odreuje 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.2013
1 1 2 5 7.00 01.02.2013
2 105 23 4 50.00 05.02.2013

U primjeru iz tabele kompozitni klju ine (ID Ponuda, ID firma, ID Roba). Da bi bio
jednoznano odreen atribut koliina mora nam biti poznat kompletan kompozitni klju. Dio
kljua nam ne odgovara jer time ne dobijamo jednoznano odreen atribut koliina. Time
moemo rei da su atributi Koliina, Cijena i Datum potpuno funkcionalno zavisni od navedenog
kompozitnog kljua.
Za normalizaciju su posebno vane dvije vrste funkcionalne zavisnosti, a to su parcijalna FZ i
tranzitivna (prenosna) FZ. Parcijalna FZ postoji kada imamo funkcionalnu zavisnost u kojoj je
determinantni atribut samo dio kompozitnog kljua. Ako pogledamo u primjer iz gornje tabele
onda 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 moe
samo djelimino da odredi vrijednost atributa Cijena. Parcijalne zavisnosti su prilino direktne i
obino se lako uoavaju.
Tabela 5 : Tabele Knjige
Knjiga anr Pisac Nacionalnost
20.000 milja pod
morem
Nauna fantastika il Vern Francuz
Putovanje u sredite
zemlje
Nauna fantastika il Vern Francuz
Ana Karenjina Fikcija Lav Tolstoj Rus
Rat i mir Fikcija Lav Tolstoj Rus

Knjiga identifikuje pisca, a pisac svoju nacionalnost. To je sva sutina tranzitivne FZ. Ako
imamo zavisnost Knjiga Pisac (AB) i Pisac Nacionalnost (BC) i kada je atribut A
primarni klju, onda se relacija Knjiga Nacionalnost (AC) smatra tranzitivnom
funkcionalnom zavisnou. Za razliku od parcijalne FZ, tranzitivna FZ se mnogo tee uoava u
analizi podataka neke tabele. Meutim, postoji i laki nain za identifikaciju tranzitivne FZ.
Tranzitivna FZ se pojavljuje samo tamo gdje postoji funkcionalna zavisnost izmeu atributa koji
ne pripadaju primarnom kljuu. U primjeru, tranzitivnu zavisnost identifikujemo u relaciji AC,
meutim veza atributa BC signalizira postojanje tranzitivne zavisnosti.


13

3.3 Prva normalna forma

Prva normalna forma kae da svaki atribut koji ima tendenciju ponavljanja mora biti odvojen u
novu 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, nikako
set 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 Projekti
ID_Projekat Projekat_Naziv ID_Radnik Ime_Prezime Radno_Mjesto Cijena_Sata
101 Sistem upravljanja
dokumentima
1
2
3
Milo Nikoli
Marko Pavlovi
Andrej imi
Projektant
Programer
Administrator
20
15
12
50 Transport i
logistika
4
1
5
Ljubomir Kiti
Milos Nikolic
Rade Mitrovi
Sistem
analitiar
Projektant
Inenjer baze
podataka
12
20
18

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

Tabela 7 : Tabela Projekti, prvi korak normalizacije
ID_Projekat Projekat_Naziv ID_Radnik Ime_Prezime Radno_Mjesto Cijena_Sata
101 Sistem upravljanja
dokumentima
1 Milo Nikoli

Projektant

20
101 Sistem upravljanja
dokumentima
2 Marko
Pavlovi
Programer

15
101 Sistem upravljanja
dokumentima
3 Andrej imi Administrator 12
50 Transport i logistika 4 Ljubomir
Kiti
Sistem analitiar

12
50 Transport i logistika 1 Milo Nikoli Projektant

20
50 Transport i logistika 5 Rade
Mitrovi
Inenjer baze
podataka
18

Sledei korak je identifikacija primarnog kljua, lako je primjetiti da ID_Projekat ne moe biti
primarni klju jer ne identifikuje jednoznano ostale atribute u tabeli. Ako uzmemo kolonu
ID_Projekat i njenu vrijednost 101 uoavamo da ne oznaava nepogreivo na kog radnika se
misli iako su svi dio projekta 101. U ovom sluaju, samo kompozitni klju koji se sastoji od
14

ID_Projekta i ID_Radnika e biti pogodan za dobijanje vrijednosti kompletnog reda. Ukoliko je
ID_Projekat=101 a ID_Radnik=1, rezultat datog upita bazi bi bio Projekat_naziv= Sistem
upravljanja dokumentima, Ime_Prezime= Milo Nikoli i 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 ih
odreuje kombinacija atributa ID_projekat,ID_Radnik. Osim glavne zavisnosti od primarnog
kljua, uvidjeemo i druge zavisnosti poput ID_projekat Projekat_Naziv. Takoe, ako nam je
poznata vrijednost atributa ID_Radnik, poznati su nam i ostali podaci o radniku, pa vai i :
ID_Radnik Ime_Prezime, Radno_Mjesto, Cijena_sata.
Ako pogledamo jo paljivije moemo uoiti da od atributa Radno_Mjesto zavisi Cijena_Sata.
Radno_Mjesto Cijena_Sata.
Kao to je ranije reeno, poto je u pitanju veza izmeu atributa koji ne pripadaju primarnom
kljuu to nam signalizira tranzitivnu zavisnost.
Da sumiramo, pronaene su sledee zavisnosti :
- parcijalna, ID_projekat Projekat_Naziv
- parcijalna, ID_Radnik Ime_Prezime, Radno_Mjesto, Cijena_sata
- tranzitivna, Radno_Mjesto Cijena_Sata.
Iako je trenutno tabela normalizovana po prvoj normalnoj formi, problem je parcijalna zavisnost
koja nije preporuljiva mada se nekad namjerno koristi zbog performansi. Opreznost kod
korienja je opravdana jer tabela koja sadri parcijalnu zavisnost je i dalje pod opasnou od
redundanse i raznih anomalija. Redundansa se moe pojaviti zbog toga to svaki novi unos
zahtjeva unos duplikata ve postojeeg podatka. Na primjer kada se otvara novi projekat, mora
se unijeti koji radnik e raditi na projektu iako je vjerovatno da ve postoji u bazi podataka. Ako
se pogrijei u unosu njegovih podataka Ime_Prezime, Radno_Mjesto, Cijena_sata doi e do
razlika u podacima za datog radnika. Ovakav nain rada je veoma neefikasan, osim toga
naruava integritet baze podataka i pravila konzistencije.

3.4 Druga normalna forma

Prilagoavanje tabele za drugu normalnu formu se radi samo kada kao rezultat prve imamo
kompozitni primarni klju. Ako je tabeli primarni klju jedan atribut onda je tabela automatski u
drugoj normalnoj formi. Kae se da je tabela u drugoj normalnoj formi ako ispunjava bilo koju
tvrdnju :
- 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 druge
zavisne atribute u tabeli treba napraviti novu tabelu u koju se trebaju smjestiti svi zavisni atributi
i determinantni kao primarni klju nove tabele. U tom sluaju determinantni atribut treba da
ostane kao spoljni klju u originalnoj tabeli nad kojom se radi normalizacija.
15


Eliminisanje postojanja parcijalnih zavisnosti se obavlja tako to se svi zavisni atributi u
parcijalnoj relaciji briu iz postojee tabele. Njihovi determinatni atributi postaju primarni
kljuevi u novim tabelama. Svi atributi koji nisu zavisni ni u jednoj parcijalnoj relaciji ostaju u
originalnoj 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 Projekat
ID_Projekat Projekat_Naziv
50 Transport i logistika
101 Sistem upravljanja dokumentima

Tabela 9 : Tabela Radnik
ID_Radnik Ime_Prezime Radno_Mjesto Cijena_Sata
1 Milo Nikoli Projektant 20
2 Marko Pavlovi Programer 15
3 Andrej imi Administrator 12
4 Ljubomir Kiti Sistem analitiar 12
5 Rade Mitrovi Inenjer baze podataka 18

Tabela 10 : Tabela Zadatak
ID_Projekat ID_Radnik
50 1
50 4
50 5
101 1
101 2
101 3

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


Slika 2 : Logiki prikaz novonastalih tabela sa relacijama
16

3.5 Trea normalna forma

Da bi tabela ispunila zahtjeve tree normalne forme potrebno je eliminisati tranzitivne zavisnosti
a potom i izvriti preraspodjelu zavisnih atributa. Za svaku pronaenu tranzitivnu zavisnost
kreira se nova tabela u kojoj je primarni klju determinantni atribut iz relacije zavisnosti. Ako
uoimo tri tranzitivne zavisnosti, to znai da imamo tri determinante i samim tim emo imati tri
nove tabele. Kao i kod usaglaavanja sa drugom NF, determinanta ostaje u originalnoj tabeli kao
spoljni klju. Pregledom tri tabele koje imamo nakon usaglaavanja sa drugom NF, moemo da
uoimo jednu tranzitivnu zavisnost, u kojoj je determinanta Radno_Mjesto a zavisni atribut
Cijena_Sata. Kao to sam naveo, Radno_Mjesto ostaje kao spoljni klju u tabeli Radnik, postaje
primarni klju nove tabele, a zavisni atribut Cijena_Sata prelazi u novu tebelu a brie se iz stare.
Primjer sada izgleda ovako :


Slika 3 : Logiki prikaz rezultata posle usklaivanja sa 3NF

3.6 Bojs/Kodova normalna forma (BCNF)

Ova normalna forma definie jo stroije ono ime se bavi trea NF. Prilagoavanje BCNF se
radi samo kada tabela ima vie kandidat kljueva, inae nema razlike izmeu 3NF i BCNF.
Definicija kae da je tabela u BCNF ako i samo ako su svi determinantni atributi kandidat
kljuevi. Moe se takoe rei i da je BCNF poseban sluaj 3NF. Ukoliko se pristupi
normalizaciji kao to je prikazano u primjeru veina relacija prilagoenih 3NF e ve ispunjavati
kriterijum i za BCNF. Postavlja se pitanje kako uopte tabela moe biti u 3NF a ne biti i u
BCNF. Vraamo se na ono da tranzitivna zavisnost postoji samo kada nisu dio kljua ni
determinantni ni zavisni atribut u relaciji. Ali ta je sa sluajem sa Slike 4 u kom atribut koji nije
klju je determinantni u relaciji gdje je zavisni atribut dio kljua.

17


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+B C, D primarni klju identifikuje ostale atribute
A+C B, D samim tim to CB, C je kandidat klju koji zajedno sa A odreuje B, D
C B C odreuje B.
Jasno je da ovde nema parcijalnih niti tranzitivnih zavisnosti. Meutim u vezi C B, atribut B
koji je dio kljua je zavisan od odreujueg atributa C koji nije dio primarnog kljua. U isto
vrijeme, ova veza nije ni parcijalna ni tranzitivna jer je atribut B dio PK, iz tog razloga ova tabela
ispunjava uslov za 3NF, ali ne i BCNF zbog pomenute relacije. Da bi relacija sa slike ispunila
BCNF potrebno je promjeniti PK na A+C, poto je C odreujui za B. Posle promjene PK tabela
ispunjava 1NF, i ima parcijalnu zavisnost.


Slika 5 : Relacija meu atributima nakon promjene primarnog kljua




18

Da bi se zavrila normalizacija na BCNF potrebno je eliminisati parcijalnu zavisnost, krajnji
rezultat 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 NF
ako ispunjava BCNF i ako nema ponavljanja viestrukih vrijednosti. Ako se vratimo na primjer
sa Slike 1 i uzmemo samo primarni klju tabele Ponuda, vrijednosti u njoj bi izgledale ovako :

Tabela 11 : Vrijednosti PK tabele Ponuda
ID_Ponuda ID_Firma ID_Roba
1 101 1
1 101 2
2 222 3
2 222 4
2 222 5
3 59 401

Vidljivo je da se neke vrijednosti ponavljaju iz reda u red. etvrta normalna forma kae da se
ova 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/Firma
ID_Ponuda ID_Firma
1 101
1 101
2 222
2 222
2 222
3 59





19

Tabela 13 : Tabela Ponuda/Roba
ID_Ponuda ID_Roba
1 1
1 2
2 3
2 4
2 5
3 401

IV DENORMALIZACIJA

Denormalizacija je prevoenje tabele u slabiju normalnu formu. Za razliku od loih postavki
baze podataka i pravilima za ispravljanje o kojima je bilo rijei u Normalizaciji, ovdje je rije o
namjernom smanjenju normalizacije najee zarad performansi. Brojni teoretiari baze
podataka 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 ne
moe da ponudi performanse koje se od baze oekuju. Denormalizacija baze ne mora da znai
poboljanje karakteristika, problemi mogu ostati isti kao ranije, ili se pak mogu odraziti na drugi
dio sistema baze podataka. Denormalizacija znai promjenu strukture BP, stoga je mogue
pokvariti postojee funkcionalnosti sistema, ili napraviti probleme u izvjetavanju (vani upiti
mogu poeti raditi sporo usled promjene). To zahtjeva dosta analize posledica promjene
strukture 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 se
kreirati ogranienja koja obezbjeuju referencijalni integritet, umjesto da veina problema bude
rijeena 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 mijenjaju
denormalizovanim, gdje se dobija nova struktura BP, a kod drugog se zadravaju normalizovane
tabele 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 Projekat
koje su u relaciji sa Slike 7, primjeujemo da je ID_Radnik postoji u tabeli Projekat kao spoljni
klju svoje matine tabele Radnik, ali je u isto vrijeme i dio primarnog kljua u tabeli Projekat.

20


Slika 7 : Relacija tabela Projekat i Radnik

Dakle, da bi se eliminisalo esto pridruivanje dvije tabele, one se mogu spojiti u jednu tabelu
gdje 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_Sata
1 Transport 101 Milo Nikoli Programer 20
1 Transport 102 Jovan Rai Analitiar 15
2 Izvoz 103 Milan Anti Dizajner 12

Samim tim to je u novoj tabeli klju ID_Projekat, ID_Radnik jasno je da se radnik ne moe dva
puta 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 podataka
iz vie tabela. Takva tabela je oigledno predviena da ima jedan atribut za svaku kolonu na
izvjetaju. Meutim, moe uvati razliite formate podataka u jednoj koloni, to je naruavanje
integriteta podataka. Da bi se podaci prebacili u tabelu izvrie se komanda UNION, kojom se
spajaju nesrodni podaci iz dvije ili vie tabela. Kada se radi unija tabela bitna stavka je i redosled
kolona koji moe da se uredi ORDER BY operatorom. Takoe, kod unije izmeu nesrodnih
tabela e se neminovno pojavljivati NULL vrijednosti, njih ureuje SQL standard koji ih uvijek
reda ili na poetku ili na samom kraju seta podataka, ukoliko komandom ORDER BY nismo
drugaije naveli.

4.3 Preslikane tabele (Mirrored Tables)

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

bazu podataka. Iz tog razloga se od tabele naini duplikat nad kojim se radi zahtjevno
izvjetavanje, 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 njenih
kolona). Ako se u BP zadri i originalna tabela, ovo se moe posmatrati i kao specijalni sluaj
preslikane tabele. Cilj ovog tipa denormalizacije je da se tabela iscijepa u manje tabele kojima e
se upravljati bre ili lake. Te manje tabele mogu biti na taj nain formirane i aurirane da mogu
ponuditi agregatne podatke. Kriterijumi za razdvajanje mogu biti razni a najei su :
a) Fiziki - jedna tabela za jedno prodajno mjesto umjesto za sva prodajna mjesta jedna
tabela.
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 cijelu
kompaniju.

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

4.5 Spajanje tabela (Combined Tables)

Spajanje tabela je poseban sluaj esto pridruivanih tabela (Prejoined tables). Razlika je u tome
to je ovde sluaj sa tabelama izmeu kojih je veza JEDAN NA JEDAN. Obino je jedna tabela
mnogo 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 radnika
na jednom mjestu. Problem kod spojene tabele moe biti to to e se esto pojavljivati NULL
vrijednost 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 problem
u primjeru je i to to ova veza ne mora ostati JEDAN NA JEDAN. Direktor kompanije moe za
22

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 se esto kolone iz jedne tabele koja se pridruuje drugoj koriste skupa sa kolonama iz druge
onda 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 panju
na 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 setu
podataka 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 dobijanje
izvjetaja.

4.7 Ponavljajue grupe (Repeating groups)

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

Tabela 15 : Tabela Rauni
ID_Kupac Kupac_Naziv Raun ID_Robe Koliina Cijena
1 Milo 1 101 2,00 20,00
2 Marko 2 249 1,00 4,00
3 Nikola 3 43 5,00 50,00
1 Milo 4 503 1,00 90,00
1 Milo 5 444 3,00 24,00

23

Primarni klju ove tabele bi bio ID_Kupac i Raun. Meutim, izvjetavanje iz ove tabele
podrazumjeva korienje operatora GROUP BY i agregatnih funkcija. Umjesto toga moe se
napraviti 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 Vrijednost4
1 Milo 40,00 90,00 72,00 NULL
2 Marko 4,00 NULL NULL NULL
3 Nikola 250,00 NULL NULL NULL

Iako je posle ovakvog zahvata kreiranje nekih izvjetaja i auriranje bre, postoje i neeljeni
efekti. Oni se ogledaju kroz :
a) Broj kolona u tabeli je statian. Nova kolona se ne moe tako lako dodati. Za dodavanje
vrijednosti ponekad e biti potrebno dodati novu kolonu.
b) Korisno je dok je broj kolona mali. Kad bi tabela imala veliki broj kolona, ovakva
denormalizovana 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 veoma
naporno u ovakvoj strukturi.

4.8 Izvedeni podaci (Derivable Data)

Mnoge vrijednosti koje su potrebne kao rezultat upita se mogu dobiti proraunom drugih
vrijednosti 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 preesto
potreban ili proraun kompleksan da to opravdava pohranjivanje u BP. Tu je problem to se
proraunata vrijednost mora aurirati kada se bilo koji parametar za izraunavanje promjeni, ako
se to propusti gubi se tanost podatka. Dobra stvar je to se moe u istoj tabeli uvati i
proraunata vrijednost i parametri tako da se uvijek moe provjeriti da li je podatak taan. Kao
primjer 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 vrijednost
moe uvati u podacima o kupcu, ali se uvijek moe nanovo izraunati jer postoje svi parametri
za proraun.

4.9 Hijerarhijske tabele (Hierarchy Tables)

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

Tabela 17 : Hijerarhijska tabela Radnik
Radnik ef Plata
Milo NULL 1000,00
Marko Milo 800,00
Nikola Milo 800,00
Mirko Nikola 600,00
Goran Nikola 600,00
Zoran Nikola 500,00

Dobra stvar u ovakvom modelu je to je unos novog radnika veoma lak, sve to treba da se zna je
ko je ef novom radniku. Ako je novi radnik Miroslav a Nikola mu je ef jednostavno se doda
red (Miroslav,Nikola,400.00). Meutim, problemi ovakvog pristupa su :
d) ako se desi promjena imena meu zaposlenim, morali bi svi redovi gdje se spominje
taj radnik da budu promjenjeni.
e) ako radnik koji je istovremeno i ef grupi radnika bude otputen, osim to njega
izbriemo 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 plata
efova i njihovih radnika bi podrazumjevalo pisanje veoma komplikovanog
proceduralnog upita.
g) postoji opasnost od upisivanja podatka kojim se rui hijerarhijska koncepcija. Radnik
se moe putem nepravilnosti pojaviti kao ef sopstvenim efovima. To bi programe i
upite 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
izmeu jezika.


Slika 9 : Izgled uobiajene postavke tabele Prevodi

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

MEN, MORTAL, PERSON). Naravno, to ne znai da prvom podatku u koloni Rije odgovara
prevod iz kolone Znaenje sa prve pozicije, nego da u irem smislu pojmovi iz kolone Rije i
Znaenje poklapaju dovoljno da se ponude kao predlozi za prevod. U novoj postavci PK bi bio
Tip_Prevoda i Rije. Pretraga pojmova po ovakvoj tabeli je veoma brza. Meutim, kao i ostali
pristupi u denormalizaciji i ovaj ima nedostatke :
a) veliina - tabela e zauzimati mnogo vei 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 uvijek
pogodni za sve to e se pojavljivati u njima;
c) validnost - izuzetno je teko uvati ispravnost podataka nad ovakvom gigantskom
tabelom;
d) fleksibilnost jasno je da zbog ogromnog broja podataka i naina uvanja tabela nije
podlona lakim izmjenama;
e) sigurnost da bi se izbjegle greke u auriranju tabele potrebno je napraviti setove
podataka 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 taj
to naruava prvu NF. Iako ima PK i sve vrijednosti kolone su istog tipa ipak se u jednoj
koloni uva vie vrijednosti.

V PRAKTIAN PRIMJER

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

5.1 Rijenik podataka

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>>


26

FK_PRED
<<SIFRA>,<NAZIV>,<MESTO>,<ADRESA>,<TELEFON>,<FAX>,<EMAIL>,<WEB>,<ZIR
ORACUN>,<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>>
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>>

Tabela 18 : Definisanje polja u rijeniku podataka
NAZIV POLJA DOMEN OGRANIENJE
SIFRA SMALLINT(3) NOT NULL
NAZIV CHAR(50)
SIS_DATUM TIMESTAMP
SIFRA SMALLINT(3) NOT NULL
NAZIV CHAR(50)
SIS_DATUM TIMESTAMP
PRED SMALLINT(3) NOTNULL
SIFRA INT(6) NOT NULL
NAZIV CHAR(70)
ADRESA CHAR(70)
ZIRORACUN CHAR(50)
OPIS BLOB
TELEFON CHAR(25)
PDV_BROJ CHAR(14)
MESTO SMALLINT(3)
GRUPAKOMT SMALLINT(3)
EMAIL CHAR(30)
WEB CHAR(30)
JIB_BROJ CHAR(13)
27

INOSTRANI_DA BIT IN(0,1)
KOMT_PDV BIT IN(0,1)
SIS_DATUM TIMESTAMP
SIFRA SMALLINT(3) NOT NULL
NAZIV CHAR(50)
REGIJA SMALLINT(3)
SIS_DATUM TIMESTAMP
SIFRA SMALLINT(3) NOT NULL
NAZIV 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 NULL
VR_DOK SMALLINT(3) NOT NULL
DOK MEDIUMINT(5) NOT NULL
RBR SMALLINT(3) NOT NULL
DATUM DATE
USLUGA SMALLINT(3)
KOMT INT(3)
NAPOMENA MEDIUMTEXT
KOLICINA DECIMAL(12,2)
CIJENA DECIMAL(12,2)
VALUTA_PLACANJA DATE
PROCENAT_POREZA DECIMAL(5,2)
KORISNIK CHAR(10)
SIS_DATUM TIMESTAMP
SIFRA SMALLINT(3) NOT NULL
NAZIV CHAR(30)
DRZAVA SMALLINT(3)
SIS_DATUM TIMESTAMP
PRED SMALLINT(3) NOT NULL
RBR SMALLINT(3) NOT NULL
DATUM_UPLATE DATE
KOMT INT(6)
28

RACUN CHAR(15)
IZNOS DECIMAL(12,2)
KORISNIK CHAR(10)
SIS_DATUM TIMESTAMP
PRED SMALLINT(3) NOT NULL
SIFRA SMALLINT(3) NOT NULL
NAZIV CHAR(50)
POREZ_DA BIT IN(0,1)
SIS_DATUM TIMESTAMP
SIFRA SMALLINT(3) NOT NULL
NAZIV CHAR(50)
SIS_DATUM TIMESTAMP
KORISNIK CHAR(10) NOT NULL
SIFRA CHAR(10) NOT NULL
NAZIV CHAR(50)
SIFRA SMALLINT(3) NOT NULL
NAZIV CHAR(50)
ADRESA CHAR(50)
TELEFON CHAR(30)
SIS_DATUM TIMESTAMP
PRED SMALLINT(3) NOT NULL
DOK MEDIUMINT(5) NOT NULL
RBR SMALLINT(3) NOT NULL
DATUM DATE
KOMT 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)
29

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 o
samim tabelama i njihovim relacijama.

Tabele fk_drzava, fk_mesto, fk_regija, fk_grupakomt su tabele koje daju velike mogunosti za
izvjetavanja iz baze podataka. Samim postojanjem spoljnjeg kljua npr. Mesto u tabeli
Komitent i istoimene tabele daje mogunost pregleda prometa usluga sa komitentima po
mjestima 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 u
praenju poslovanja firmom. Sve ove opcije daju mogunost zahtjevnih upita koje daju opcije
pregleda prometa po dravama odakle kupci dolaze, regijama, gradovima, kao i mogunost
korisinka da napravi sopstvenu grupu kupaca koju bi posebno da prati kroz atribut Grupakomt u
tabeli 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 primarne
informacije za poslovanje sa preduzeem. Tu dolazimo do toga da BP daje podatke prenesene iz
realnog svijeta ali samo one koji su prepoznati kao bitni, ostali se zanemaruju jer svaka tabela u
bazi podataka treba da bude minimalistika, da zadovoljava potrebe za bitnim informacijama.

Tebela preduzee pak, skladiti informacije o preduzeu koje prodaje usluge. Ona treba da
zadovolji 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 su
ifrirana, i mogue je ispratiti da se preduzee kao spoljni klju pominje i u drugim tabelama i to
kao dio PK druge tabele. To je zbog toga da bi se mogli skladititi podaci o vie preduzea
istovremeno u BP, svi ti podaci su odvojeni ifrom preduzea kojoj odreeni podatak pripada. To
dalje implicira da ukoliko se korisnik uloguje u sistem pod odreenom ifrom preduzea bie mu
vidljivi 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 je
organizovana putem kompozitnog kljua. Atribut pred oznaava ve pomenuto preduzee i
njegova funkcija je objanjena. Sledi polje vr_dok koje je spoljni klju i odnosi se na vrstu
dokumenta 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 se
redom prave kao Rauni. Poto je klju u tabeli hijerarhijski organizovan, jedno preduzee moe
imati vie vrsta dokumenta, istovremeno jedna vrsta dokumenta moe imati jako puno instanci.
30

Poslednje polje u kljuu je rbr, redni broj stavke koja omoguuje vie stavki u okviru jednog
dokumenta. Kombinacijom ova etiri atributa dobijamo sve varijante koje su potrebne da baza
podataka bude fleksibilna. Ukoliko se stvori potreba za jo vrsta dokumenata, prostim
registrovanjem u tabeli Fk_Vr_Dok dobijamo podatak koji moemo izabrati prilikom rada sa
tabelom Fk_Racun, gdje e baza moe odmah da pone sa odvajanjem dokumenata koji
pripadaju novoj vrsti dokumenta. Primjetimo, mnogi kreatori baza podataka imaju obiaj da
skladite 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. Prema
formuli koliina*cijena=prodajni iznos jasno je da se prodajni iznos uvek moe dobiti
mnoenjem druga dva atributa. Meutim, poto je baza podataka uvijek kompromis izmeu
pravila i dostupnosti podacima ponekad se svjesno prekri NF. U velikim i komplikovanim
bazama stalno mnoenje dva polja moe biti naporno, mnogi se odluuju da ipak uskladite ovaj
podatak radi lakeg pristupa. Ista situacija je i sa procentom i iznosom poreza. Iznos poreza je
bitan podatak, ali ukoliko imamo procenat uvijek mozemo izraunati iznos tako da ga ne bi
trebalo kao uvati u bazi podataka. Ostali podaci se odnose na podatke o datom dokumentu i
stavci, kupac, koliina, cijena itd.

Tabela usluga nam daje osnovne podatke o usluzi koja se prodaje. Podatak Porez_da implicira na
atribut 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 govori
o iroraunu na koji je iznos uplaen, kao i na osnovu kog izdatog rauna je uplata izvrena. Ovo
nam daje bolji uvid u praenje samog poslovanja preduzea, jer razlika izmeu sume iznosa
izdatih rauna i zbira uplata po komitentu znamo koliko je dobra naplata, kao i koji je preostali
dug kupca. Naravno, u tabeli imamo i podatak o datumu kad se uplata desila i o korisniku koji je
aurirao BP zbog osnovne kontrole.

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

















31


Slika 10 : Fiziki model BP prodaja usluga











32


5.3 Dijagram konteksta, prvi i drugi nivo dekompozicije


Slika 11 : Dijagram konteksta



Slika 12 : Prvi nivo dekompozicije

33



Slika 13 : Drugi nivo dekompozicije prodaja usluga




Slika 14 : Drugi nivo dekompozicije evidencija uplata


34

5.4 Model objekti-veze

35

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] Veinovi Mladen, Goran imi, Uvod u baze podataka, Univerzitet Singidunum,
Beograd, 2010.
[6] http://www.databasejournal.com/
[7] http://en.wikipedia.org/wiki/Main_Page