Professional Documents
Culture Documents
Normalizacija I Relacione Bazegfhfgh
Normalizacija I Relacione Bazegfhfgh
DIPLOMSKI RAD
Kandidat
Milo Nikoli
BIJELJINA, 2013
Uvod
Struktura relacione baze podataka
Normalizacija
Denormalizacija
Praktian primjer
Zakljuak
Dekan :
Profesor dr Duan Regodi, dipl. in.
Mentor :
Profesor dr Mladen Veinovi, dipl. in.
Datum uruivanja :
Bijeljina, 2013
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
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 IBM1 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 Banks2, 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.
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
3
Slika1 : Logiki model relacione baze podataka sa relacijama, kreiran u IBM Rational Software Architect
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
7
2.3 Atributi
Atributi pripadaju entitetu i definiu ga. Njemaki matematiar Lajbnic2 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 SQL3 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
_______________________
7 - Christopher J. Date (1941 -), izdava i autor knjiga o bazama podataka, autor Introduction to Database Systems
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 Bojs9/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
10
Tabela 1 : Predmeti
STUDENT
MILO
GORAN
MARKO
PREDAVA
SIMI
SIMI
JOVANOVI
PREDMET
MREE
MREE
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
Definicija
Atribut B je potpuno zavisan od atributa A ako
svaka vrijednost atributa A odreuje jednu jedinu
Funkcionalna zavisnost
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.
Koncept
11
ID radnik
1
2
Ime i prezime
Milo Nikoli
Marko Jovanovi
Adresa
Danila Kia 29
Cara Uroa 11
Radno mjesto
Administrator
Referent
Nivo pristupa
5
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
1
1
2
ID firma
1
1
105
ID Roba
1
2
23
Koliina
10
5
4
Cijena
20.00
7.00
50.00
Datum
01.02.2013
01.02.2013
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
20.000 milja pod
morem
Putovanje u sredite
zemlje
Ana Karenjina
Rat i mir
anr
Nauna fantastika
Pisac
il Vern
Nacionalnost
Francuz
Nauna fantastika
il Vern
Francuz
Fikcija
Fikcija
Lav Tolstoj
Lav Tolstoj
Rus
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.
12
Projekat_Naziv
Sistem upravljanja
dokumentima
50
Transport i
logistika
Radno_Mjesto
Projektant
Programer
Administrator
Sistem
analitiar
Projektant
Inenjer baze
podataka
Cijena_Sata
20
15
12
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.
50
50
Transport i logistika
ID_Projekat
101
101
101
50
Rade
Mitrovi
Inenjer baze
podataka
Cijena_Sata
20
15
12
12
20
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
13
ID_Projekat
50
101
Projekat_Naziv
Transport i logistika
Sistem upravljanja dokumentima
Tabela 9 : Tabela Radnik
ID_Radnik
1
2
3
4
5
Ime_Prezime
Milo Nikoli
Marko Pavlovi
Andrej imi
Ljubomir Kiti
Rade Mitrovi
Radno_Mjesto
Projektant
Programer
Administrator
Sistem analitiar
Inenjer baze podataka
Cijena_Sata
20
15
12
12
18
ID_Projekat
50
50
50
101
101
101
ID_Radnik
1
4
5
1
2
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.
16
Slika 4 : Relacija meu atributima gdje je determinantni atribut C odreujui za B (dio kljua)
17
ID_Ponuda
1
1
2
2
2
3
ID_Firma
101
101
222
222
222
59
ID_Roba
1
2
3
4
5
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
1
1
2
2
2
3
ID_Firma
101
101
222
222
222
59
18
ID_Ponuda
1
1
2
2
2
3
ID_Roba
1
2
3
4
5
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.
19
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
1
1
2
Projekat_Naziv
Transport
Transport
Izvoz
ID_Radnik
101
102
103
Ime_prezime Radno_Mjesto
Milo Nikoli
Programer
Jovan Rai
Analitiar
Milan Anti
Dizajner
Cijena_Sata
20
15
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
20
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.
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
21
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.
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
1
2
3
1
1
Kupac_Naziv
Milo
Marko
Nikola
Milo
Milo
Raun
1
2
3
4
5
ID_Robe
101
249
43
503
444
22
Koliina
2,00
1,00
5,00
1,00
3,00
Cijena
20,00
4,00
50,00
90,00
24,00
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
1
2
3
Kupac_Naziv
Milo
Marko
Nikola
Vrijednost1
40,00
4,00
250,00
Vrijednost2
90,00
NULL
NULL
Vrijednost3
72,00
NULL
NULL
Vrijednost4
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.
23
Radnik
Milo
Marko
Nikola
Mirko
Goran
Zoran
ef
NULL
Milo
Milo
Nikola
Nikola
Nikola
Plata
1000,00
800,00
800,00
600,00
600,00
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.
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,
24
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>>
25
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
SIFRA
NAZIV
SIS_DATUM
SIFRA
NAZIV
SIS_DATUM
PRED
SIFRA
NAZIV
ADRESA
ZIRORACUN
OPIS
TELEFON
PDV_BROJ
MESTO
GRUPAKOMT
EMAIL
WEB
JIB_BROJ
DOMEN
SMALLINT(3)
CHAR(50)
TIMESTAMP
SMALLINT(3)
CHAR(50)
TIMESTAMP
SMALLINT(3)
INT(6)
CHAR(70)
CHAR(70)
CHAR(50)
BLOB
CHAR(25)
CHAR(14)
SMALLINT(3)
SMALLINT(3)
CHAR(30)
CHAR(30)
CHAR(13)
26
OGRANIENJE
NOT NULL
NOT NULL
NOTNULL
NOT NULL
INOSTRANI_DA
KOMT_PDV
SIS_DATUM
SIFRA
NAZIV
REGIJA
SIS_DATUM
SIFRA
NAZIV
MESTO
ADRESA
TELEFON
FAX
EMAIL
WEB
ZIRORACUN
JIB
MATICNI
POCETNI_KAPITAL
OPSTINA
VLASNIK
PDV_OBVEZNIK
SIS_DATUM
PRED
VR_DOK
DOK
RBR
DATUM
USLUGA
KOMT
NAPOMENA
KOLICINA
CIJENA
VALUTA_PLACANJA
PROCENAT_POREZA
KORISNIK
SIS_DATUM
SIFRA
NAZIV
DRZAVA
SIS_DATUM
PRED
RBR
DATUM_UPLATE
KOMT
BIT
BIT
TIMESTAMP
SMALLINT(3)
CHAR(50)
SMALLINT(3)
TIMESTAMP
SMALLINT(3)
CHAR(70)
SMALLINT(3)
CHAR(30)
CHAR(20)
FAX(20)
CHAR(30)
CHAR(30)
CHAR(50)
CHAR(13)
CHAR(15)
DECIMAL(12,2)
CHAR(30)
CHAR(25)
BIT
TIMESTAMP
SMALLINT(3)
SMALLINT(3)
MEDIUMINT(5)
SMALLINT(3)
DATE
SMALLINT(3)
INT(3)
MEDIUMTEXT
DECIMAL(12,2)
DECIMAL(12,2)
DATE
DECIMAL(5,2)
CHAR(10)
TIMESTAMP
SMALLINT(3)
CHAR(30)
SMALLINT(3)
TIMESTAMP
SMALLINT(3)
SMALLINT(3)
DATE
INT(6)
27
IN(0,1)
IN(0,1)
NOT NULL
NOT NULL
IN(0,1)
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
RACUN
IZNOS
KORISNIK
SIS_DATUM
PRED
SIFRA
NAZIV
POREZ_DA
SIS_DATUM
SIFRA
NAZIV
SIS_DATUM
KORISNIK
SIFRA
NAZIV
SIFRA
NAZIV
ADRESA
TELEFON
SIS_DATUM
PRED
DOK
RBR
DATUM
KOMT
USLUGA
KOLICINA
KORISNIK
SIS_DATUM
CHAR(15)
DECIMAL(12,2)
CHAR(10)
TIMESTAMP
SMALLINT(3)
SMALLINT(3)
CHAR(50)
BIT
TIMESTAMP
SMALLINT(3)
CHAR(50)
TIMESTAMP
CHAR(10)
CHAR(10)
CHAR(50)
SMALLINT(3)
CHAR(50)
CHAR(50)
CHAR(30)
TIMESTAMP
SMALLINT(3)
MEDIUMINT(5)
SMALLINT(3)
DATE
INT(6)
SMALLINT(3)
DECIMAL(12,2)
CHAR(10)
TIMESTAMP
NOT NULL
NOT NULL
IN(0,1)
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
NOT NULL
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.
29
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.
30
31
32
33
34
Literatura
[1]
[2]
[3]
[4]
[5]
[6]
[7]
35