Baze Podataka - Projektovanje

Prof.
dr Rade Tanjga Baze podataka - Projektovanje
Akademska 2014-2015. godina
BAZE PODATAKA
PROJEKTOVANJE
Prof. dr Rade Tanjga

rade.tanjga@blc.edu.ba
Banja Luka, mart 2015.
1
Prof. dr Rade Tanjga Baze podataka - Projektovanje
Baze podataka
Sadraj:
I Dio: Teorija relacionih baza podataka
1. Osnovni pojmovi baza podataka
1.1. ta je to baza podataka?
1.2. Alatke za rad s bazama podataka
1.2.1. Maine baza podataka
1.2.2. Objektni modeli za pristupanje podacima
1.2.3. Okruenja za definisanje podataka
1.2.4. Razvoj eone komponente aplikacije
1.3. Relacioni model
1.4. Relaciona terminologija
1.5. Model podataka
1.5.1. Entiteti
1.5.2. Atributi
1.5.3. Domeni
1.5.4. Veze/odnosi izmeu entiteta
1.5.5. Dijagrami entiteta i veza
1.6. Saetak
2. Struktura baze podataka
2.1. Elimisanje redundantnosti
2.2. Obezbjeivanje fleksibilnosti
2.3. Osnovni principi
2.3.1. Dekomponovanje bez gubitaka
2.3.2. Kandidati za kljueve i primarni kljuevi
2.3.3. Funkcionalna zavisnost
2.4. Prva normalna forma
2.5. Druga normalna forma
2.6. Trea normalna forma
2.7. Dalje normalizovanje
2.7.1. Bojs-Kodova (Boyce-Codd) normalna forma
2.7.2. etvrta normalna forma
2.7.3. Peta normalna forma
2.8. Saetak
3. Veze izmeu entiteta
3.1. Terminologija
3.2. Modelovanje relacija
3.3. Veze tipa jedan prema jedan
3.3.1. Izrada potklasa entiteta
3.4. Veze tipa jedan prema vie
3.5. Veze tipa vie prema vie
3.6. Unarne veze
3.7. Ternarne veze
3.8. Veze s poznatim kardinalitetom
3.9. Saetak
4. Integritet podataka
4.1. Uslovi integriteta
4.1.1. Integritet domena
4.1.2. Integritet promjena stanja
4.1.3. Integritet entiteta
2
4.1.4. Referencijalni integritet

4.1.5. Integritet baze podataka
4.1.6. Integritet transakcija
4.2. Realizovanje integriteta podataka
4.2.1. Nepoznate i nepostojee vrijednosti
4.2.2. Neispunjavanje uslova integriteta
4.2.3. Deklarativni i proceduralni integritet
4.2.7. Druge vrste integriteta
4.3. Saetak
5. Relaciona algebra
5.1. Null vrijednosti i trovrijednosna logika
5.2. Relacione operacije
5.2.1. Ograniavanje
5.2.2. Projekcija
5.2.3. Spajanje
5.2.4. Dijeljenje
5.3. Operatori za rad sa skupovima
5.3.1. Unija
5.3.2. Presjek
5.3.3. Razlika
5.3.4. Dekartov proizvod
5.4. Specijalni relacioni operatori
5.4.1. Izraunavanje zbirnih podataka
5.4.2. Proirenje
5.4.3. Preimenovanje
5.4.4. Iskaz Trabsform
5.4.5. Operator Rollup
5.4.6. Operator Cube
5.5. Saetak
II Dio: Teorija dimenzionalnih baza podataka
6. Osnovni dimenzionalni koncepti
6.1. Model dimenzionalne baze podataka
6.2. Terminologija
6.3. Istorija poslovnih informacija
6.4. Saetak
7. Tabele injenica
7.1. Struktura tabele injenica
7.2. Osobine injeninih atributa
7.2.1. Granularnost
7.2.2. Vrste tabela injenica
7.2.3. Heterogene injenice
7.3. Saetak
8. Tabele dimenzija
8.1. Struktura tabela dimenzija
8.2. Grananje
8.3. Mijenjanje vrijednosti u tabelama dimenzija
8.4. Saetak
3
1. Osnovni pojmovi baza podataka
Dakle, ta je to taj famozni entitet, poznat pod nazivom relaciona baza podataka (engl.
relational database)? Osnovna (poetna) definicija mogla bi biti: baza podataka je alatka koja
omoguava skladitenje podataka i rad s njima, na efikasan i djelotvoran nain. Efikasno i
djelotvorno znai da su podaci zatieni od nenamjernog gubljenja ili oteenja, da se za tu
namjenu ne koristi vie resursa (ljudskih ili raunarskih) nego to je zaista neophodno i da se
podaci mogu uitavati u smislenim oblicima unutar prihvatljivih ogranienja preformansi. Da bi
se mogla kvalifikovati kao relaciona, baza podataka mora da realizuje relacioni model, to je
nain na koji se opisuje odreeni aspekt stvarnog svijeta, u skladu s pravilima koje je definisao
dr E.F.Codd krajem ezdesetih godina prolog vijeka.
Teorijski, softver za relacionu bazu podataka moe se napisati od nule, ali u praksi se
uvijek koriste usluge odreenog sistema za upravljanje bazama podataka (engl. Database
management system DBMS). DBMS se ponekad naziva i relacioni DBMS (RDBMS), ali
tehniki gledano, da bi se jedan DBMS kvalifikovao kao relacioni, morao bi da ispuni oko 300
uslova. Meutim, niti jedan od raspoloivih sistema koji postoje na tritu nije u potpunosti
kvalifikovan. Ovdje e se, kao ilustracija, razmatrati dva Microsoft-ova sistema za upravljanje
relacionim bazama podataka: Jet i SQL Server.
Kako je relaciona baza podataka fizika realizacija relacionog modela (modela podataka),
vano je razlikovati ta dva pojma.
1.1. ta je to baza podataka?
Terminologija baza podataka je prilino neodreena i u tom smislu podsjea na izraz

objektno orijentisano programiranje. Izraz baza podataka koristi se za opisivanje svaega, u
opsegu od obine grupe podataka, do sloenog skupa alatki, kao to je SQL Server, ali i svega
ro se nalazi izmeu. Taj manjak preciznosti ne mora obavezno da znai neto loe razlog je
sama priroda jezika ali poto nije ni naroito koristan za nae namjene, pokuaemo da ovdje
budemo precizniji. Na slici 1.1. prikazane su veze izmeu izraza koje spominjemo u ovom
poglavlju. Te izraze definiemo u ovom poglavlju, a detaljno emo ih razmotriti u poglavljima
koja slijede.
4
Sistem koji radi s bazom podataka
Aplikacija se sastoji od obrazaca (forms) i

izvjetaja (report) s kojima radi korisnik
aplikacije
Maina baze podataka nije sastavni dio baze

podataka
Baza podataka sadri fiziki oblik eme

i podataka
ema baze podataka

opisuje model
podataka koji se
uvaju u bazi
Model podataka je
konceptualni opis
prostora problema
Prostor problema je neki dobro definisan dio stvarnog

svijeta
Slika 1.1. Terminologija relacionih baza podataka
Iako se za relacione baze podataka ne mogu nai analogije u stvarnom svijetu, svrha veine
baza podataka je da modeluju (predstave) odreeni aspekt iz stvarnog ivota. Taj dio stvarnog
5
svijeta nazvaemo prostor problema (engl. problem space). Po samoj svojoj prirodi, prostor
problema je veoma sloen i zamren (esto nedovoljno jasan). Kada ne bi bio takav, ne bi ni
trebalo praviti njegov model. Meutim, za uspjeh projekta od kljune je vanosti da sistem za
koji se projektuje baza podataka bude ogranien na tano definisan skup objekata i njihovih
odnosa; jedino na taj nain se mogu donositi pravilne odluke o opsegu koji sistem treba da
obuhvati.
Izraz model podataka (engl. data model) koristiemo za pojmovni opis prostora problema.
Rad s relacionim modelom obuhvata definicije entiteta, njihovih atributa (na primjer, Kupac je
entitet, koji moe imati atribute Prezime i Adresa) i ogranienja koja vae za atribute (kao to je
na primjer, pravilo da polje ImeKupca ne moe biti prazno). Kada se radi sa dimenzionalnim
modelom, definicija modela podataka obuhvata injenice i dimenzije, ali o ovom modelu
govorie se kasnije.
Model podataka takoe obuhvata opis veza ili odnosa izmeu pojedinih entiteta, kao i
ogranienja koja vae za te veze. Na primjer, rukovodalic grupe ne moe imati vie od pet
podreenih koji mu podnose izvjetaje. Model podataka nita ne govori o fizikoj strukturi
sistema.
Definicija fizike strukture tabele i prikazi koji e biti napravljeni zove se ema baze
podataka (engl. database schema) ili samo ema. To je preslikavanje pojmovnog modela u
fiziki oblik, koji se moe realizovati pomou nekog DBMS. Treba imati u vidu da je ema
takoe konceptualni pojam a ne fiziki. ema nije nita drugo do model podataka izraen
pomou elemenata koje maina baze podataka (engl. database engine) prepoznaje, kao to su
tabele, okidai ili slina bia. Jedna od prednosti upotrebe maine baze podataka jeste to to se
ne moramo baviti fizikim oblikom baze podataka.
Poto se maini baze podataka objasni kako elimo da podaci izgledaju, pomou SQL
koda, ili u nekom interaktivnom okruenju, kao to je Microsoftov Access, ili SQL Server
Enterprise manager, maina baze podataka pravi nekoliko fizikih objekata (obino, ali ne
uvijek, negdje na vrstom disku) u koje emo kasnije smjestiti podatke. Ova kombinacija
strukture i podataka naziva se baza podataka. Takva baza podataka sadri: fizike tabele u
kojima se uvaju podaci; definisane prikaze, upite i uskladitene procedure koje omoguavaju
uitavanje podataka na razne naine; pravila ije potovanje obezbjeuje maina baze podataka i
time titi podatke.
6
Izraz baza podataka ne odnosi se na na aplikaciju koja se sastoji od obrazaca i izvjetaja s

kojima radi korisnik aplikacije, niti se odnosi na bilo koju drugu vrstu softvera kao to je
posredniki sloj ili Internet Information Server ija je namjena da povezuje eonu i pozadinsku
komponentu sistema. Prema tome, Accessova .mdb datoteka je baza podataka, dok je
Microsoftov Jet - maina baze podataka. U stvari, .mdb datoteka moe da sadri i objekte
aplikacije na primjer, obrasce i izvjetaje ali to je tema koja e se razmotriti kasnije.
Da bi se obuhvatile sve komponente aplikacija, baza podataka i maina baze podataka,

uobiajeno je da se koristi izraz sistem baze podataka ili sistem koji radi s bazom podataka
(engl. Database system). Sve softverske komponente i svi podaci koji su neophodni za rad
produkcionog sistema, ine sistem baze podataka.
1.2. Alatke za rad s bazama podataka
Iako je naa tema projektovanje a ne izrada baza podataka, sama teorija nije naroito
korisna ako se ne zna nain primjene; zato e se ovdje mnogo govoriti o izradi relacionih
baza podataka pomou Microsoftovih alatki. Na raspolaganju je veliki broj alatki te vrste, a
izgleda da je Microsoft najdostupniji; zato emo posvetiti malo vremena razmatranju o emu
se tu radi i gdje to tano spada. Na slici 1.2. prikazane su alatke koje emo razmatrati.
Najlake je da se o njima razmiljaimajui na umu ta nam je u ulozi projektanata potrebno
da bismo sistem preslikali iz apstraktnog modela u ivi produkcioni sistem; na isti nain su i
grupisane alatke na slici 1.2.
7
Okruenje za definisanje
Razvoj eonih komponenata
podataka
Microsoft Access
Microsoft Access
Visual Studio .NET
SQL Server Enterprise Manager
Analysis Manager
Objektni model za pristupanje podacima
ADO.NET
ADO (ActiveX Data Objects)
DAO (Data Access Objects)
Maina baze podataka
Microsoft Jet SQL Server

MSDE (Microsoft Desktop Engine)
Slika 1.2. Alatke za rad s bazama podataka koje se ovdje razmatraju
1.2.1. Maine baza podataka
Na najniem nivou nalaze se maine baza podataka (engl. data base engines). Ponekad se
nazivaju i pozadinske komponente (engl. Back ends), ali je to prilino loe, jer izraz
pozadinska komponenta zapravo opisuje fiziku arhitekturu, kao to emo vidjeti kasnije.
Zadatak tih alatki je fiziko manipulisanje podacima pohranjivanje na disk i uitavanje s
njega na zahtjev. Razmotriemo dvije meu njima: Jet i SQL Server. Moda je za nekog
iznenaenje to se ovdje ne spominje Access. Tehniki gledano, Access je okruenje za
razvoj eonog dijela aplikacije, koje za pohranjivanje podataka standardno koristi Jet ili SQL
Server, a moe da koristi i bilo koju drugu mainu baze podataka koja podrava standard
ODBC (Open DataBase Connectivity povezanost otvorenih baza podataka). Access radi s
8
podacima koji se uvaju u .mdb datotekama pomou maine Jet, a SQL Server (ili drugu
ODBC mainu baze podataka) koristi kada se radi s podacima u .adp datotekama. Access je
oduvjek koristio Jet mainu, koju Microsoft nije nudio kao zasebnu komponentu do
izdavanja Visual Basica 3.
I Jet i SQL Server, mada veoma razliiti, izuzetne su alatke za skladitenje podataka i rad
s njima. Razlikuju se po arhitekturi i problemima za ije su rjeavanje projektovane.
Microsoftov Jet je stona maina baze podataka, namjenjena sistemima koji se po veliini
mogu svrstati u opseg od malih do srednje velikih. S druge strane, SQL Server korisiti
arhitekturu klijent/server i namjenjen je sistemima u opsegu od srednje velikih do ogromnih,
koji se potencijalno mogu smanjiti ili poveati za hiljade korisnika aplikacija od kljune
vanosti za preduzee (ustanovu). MSDE (akronim za Microsoft Desktop Engine)
funkcionalno je ograniena verzija SQL Servera namjenjena upotrebi u jednokorisnikom
okruenju. Gledano iz ugla projektanta, razlika izmeu MSDE-a i pune verzije SQL Servera
je zanemariva i ovdje se nee spominjati. U ovom materijalu baviemo se razlikama izmeu
dvije navedene maine baze podataka, a posebno e se razmatrati kompromisi izmeu
njihovih arhitektura.
1.2.2. Objektni modeli za pristupanje podacima
Microsoftov Access, a u manjoj mjeri i Visual Studio .NET, nude jednostavne mehanizme
za povezivanje kontrola na obrascima direktno sa izvorom podataka, ime se izbjegava potreba
da programer radi neposredno s mainom baze podataka. Meutim, iz raznih razloga koji e se
ovdje razmotriti, to nije uvijek mogue ni prikladno. U takvim sluajevima mora se koristiti
objektni model za pristupanje podacima (engl. data access object model) da bi se s podacima
radilo pomou programskog koda.
Objektni model za pristupanje podacima vrsta je ljepka izmeu okruenja za

programiranje aplikacija i maine baze podataka; model stavlja na raspolaganje skup objekata, sa
njihovim svojstvima i metodama koje se mogu koristiti u programskom kodu. Budui da se
ovdje bavimo projektovanjem vie nego realizovanjem, neemo detaljno razmatrati razlike
izmeu tih modela, ali je korisno da ih se ukratko spomene.
9
Microsoft (zasad) stavlja na raspolaganje tri objektna modela za pristupanje podacima: Data
Access Objects (DAO), koji postoji u dvije varijante (DAO/Jet i DAO/ODBCDirect), Microsoft
ActiveX Data Objects (ADO) i ADO.NET.
DAO, najstariji od svih, standardni je interfejs za mainu baze podataka Jet. Bez obzira na
tvrdnje Microsoftove slube za marketing, to je najefikasniji model za rad s Jetovim bazama
podataka u Accessu. ADO koristi jednostavniju hijerarhiju objekata nego DAO jer se sastoji od
samo etiri primarna objekta i donosi nekoliko znaajnih proirenja osnovnog modela na
primjer, podrku za rad s nepovezanim i hijerarhijskim skupovima podataka. Koristi se u
Microsoftovom Accessu i u drugim softverskim proizvodima koji podravaju upotrebu jezika
VBA za rad sa svakom bazom podataka koja podrava ODBC interfejs, kao to su to i Jet i SQL
Server. ADO.NET je, naravno, verzija modela ADO za rad unutar .NET Frameworka.
1.2.3. Okruenja za definisanje podataka
Microsoftov Jet i SQL Server obavljaju poslove fizikog manipulisanja podacima umjesto
nas, a nama treba nain da im opiemo kako da strukturiraju podatke. Postoji bezbroj metoda za
tu namjenu, ali ovdje emo razmotriti samo tri Microsoftove: Access i SQL Server Enterprise
Mamager za relacione modele, i Analysis Manager za dimenzionalne modele. Kada se savladaju
principi, izabere se alatka koja je najpogodnija za posao koji treba da se obavi.
Struktura baze podataka moe se definisati i pomou SQL koda; opisaemo kako se to radi,
mada se u uobiajenim okolnostima to ne preporuuje. Osim kada je iz nekog razloga neophodno
da se izmijeni struktura podataka aplikacije dok se ona izvrava (ovo nije dobra praksa ako
ema podataka nije stabilna, vjerovatno da se nije dobro razumio domen problema), interaktivne
alatke su bre, lake i zabavnije za upotrebu.
1.2.4. Razvoj eone komponente aplikacije
Kada se zavri fizika definicija baze podataka, potrebne su alatke za izradu obrazaca i
izvjetaja s kojima e korisnici raditi. Ovdje e se razmotriti primjeri upotrebe dvije takve alatke:
Access i Visual Studio .NET (konkretno, Visual Basic .NET). U ovoj kategoriji takoe postoji
bezbroj alatki za izradu eonih komonenata, ali budui da su principi rada uvijek bili isti, trebali
bi biti u stanju da ono to se ovdje naui primjeni na alatku za koju smo se opredijelili. U jednom
poglavlju razmotrie se itai Weba, ali je sam HTML izvan dosega ovog materijala.
10
1.3. Relacioni model
Relacioni model se zasniva na grupi matematikih principa izvedenih iz teorije skupova i

predikatne logike. Te principe je kasnih ezdesetih godina prvi primjenio na oblast modelovanja
podataka dr E.F. Codd, tada istraiva u kompaniji IBM, a njegovi radovi prvi put su objavljeni
1970. godine1. Pravila relacionog modela definiu oblik u kojem se podaci predstavljaju
(struktura podataka), nain na koji se podaci tite (integritet podataka) i operacije koje se mogu
izvravati nad podacima (manipulisanje podacima).
Relacioni model nije jedini model koji postoji za skladitenje podataka i rad s njima. Ostali
modeli podataka su hijerarhijski, mreni i objektni. Svaki ima svoje pristalice i prua neosporne
prednosti za odreene vrste poslova. Meutim, zbog svoje efikasnosti i prilagodljivosti, relacioni
model je najpopularnija tehnika rada s bazama podataka i njega emo ovdje razmatrati. I Jet i
SQL Server realizuju relacioni model.
Razmotriemo i dimenzionalni model, to je specijalna vrsta relacione eme za skladitenje

arhivskih podataka. Dimenzionalni model i njegove veze s relacionim modelom obrauju se u
posebnom dijelu ovog materijala.
Uproteno govorei, sistemi relacionih baza podataka imaju sljedee odlike:

Svi podaci se konceptualno predstavljaju organizovani u redove i kolone; skup tako
organizovanjih podataka naziva se relacija (engl. Relation).
Sve vrijednosti su skalarne. To znai da se na svakom mjestu koje je odreeno datim
redom i kolonom, nalazi jedna i samo jedna vrijednost.
Sve operacije obavljaju se nad cijelom relacijom, a rezultat je takoe cijela relacija.
Taj koncept je poznat kao cjelovitost (engl. closure).
U Microsoft Access terminologiji, relacija se prepoznaje kao skup zapisa (engl.

recordset) ili, u SQL Server terminologiji kao !skup rezultata (engl. Result set). Rije
relacija izabrana je zbog toga jer nije imala praktino nikakvo drugo znaenje zavisno od
konteksta, za razliku od, na primjer, rijei tabela. Uvreeno je pogreno miljenje da se
1
Codd, E.F. A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, tom 13,
broj 6 (jun 1970).
11
relacioni model tako zove zbog veza (engl. relationship) koje uspostavljamo izmeu tabela. Ime
zapravo potie od relacija na kojima se model zasniva.
Model zahtijeva da podaci budu predstavljeni u obliku relacija samo na konceptualnom

nivou; model ne propisuje fiziki oblik u kojem se podaci uvaju. Razdvajanje konceptualnog
oblika od fizikog, koje je danas oigledno, bilo je velika inovacija prije trideset godina kada je
programiranje baza podataka uglavnom znailo pisanje mainskog koda za fiziko manipulisanje
ureajima za skladitenje podataka.
Ustvari, relacijama nije ni potreban fiziki oblik. Odreena relacija moe se preslikati u
stvarnu, fiziku tabelu koja se uva na vrstom disku, ali se moe sastojati i od kolona koje
potiu iz gomile razliitih tabela, uz jo nekoliko izraunatih kolona koje fiziki nigdje ne
postoje dodatih tek da stvar bude sloenija. Relacija se moe nazvati relacijom ako su podaci
organizovani u redove i kolone i ako su vrijednosti podataka iskljuivo skalarne. Postojanje
relacije potpuno je nezavisno od fizikog oblika podataka.
Uslov da svi podaci od kojih se relacija sastoji budu skalarni, ponekad moe navesti na
pogrene zakljuke. Pojam proste vrijednosti subjektivan je sam po sebi i zavisi od semantike
modela podataka. Na primjer, Ime osobe moe biti prosta vrijednost u jednom modelu, ali u
nekom drugom okruenju ta vrijednost e moda biti podijeljena na elemente kao to su
Funkcija, Ime i Prezime, dok e tree okruenje moda zahtijevati i Oevo ime ili
Titulu. Nijedno od navedenih nije ni bolje ni gore od drugog u apsolutnom smislu; sve zavisi
od svrhe za koju e se podaci koristiti.
Princip cjelovitosti tj. da se i tabele i rezultati operacija nad njima predstavljaju u obliku
relacija omoguava da se rezultati jedne operacije upotrebe kao ulazni podaci drugu operaciju.
Zahvaljujui tome, i Jet i SQL Server omoguavaju da rezultati jednog upita budu osnova za
drugi upit. Ta injenica prua projektantima baza podataka mogunost da operacije koje su
sloene ili se esto obavljaju, izdvoje u zasebne cjeline koje se mogu ponovo izvriti gdje god je
to potrebno.
Na primjer, napravili smo upit koji smo nazvali UpitPunoIme; on nadovezuje sve elemente
do kojih se sastoji ime osobe da bi dobio izraunato polje nazvano PunoIme. Moe se zatim
napraviti drugi upit iji je izvor podataka UpitPunoIme i u kojem se izraunato polje PunoIme
12
koristi na isti nain kao da je u pitanju polje koje postoji u izvornoj tabeli. Nema potrebe da se
ponovo sastavljaju elementi imena.
Razumije se, ovo je jednostavan primjer i vjerovatno nije sasvim oigledna neka znaajna
prednost koju bi pozivanje upita UpitPunoIme prualo nad ponovnim sastavljanjem elemenata
imena. Ali, kao to e se vidjeti, jezik SQL omoguava sastavljanje izuzetno sloenih upita, a
kako raste sloenost upita, tako postaju i sve vidljivije prednosti upotrebe postojeih upita kao
ulaznih podataka za nove upite.
1.4. Relaciona terminologija
Na slici 1.3. prikazana je relacija na kojoj su oznaena formalna imena osnovnih

komponenata. Vidi se da relacija nije u normalnoj formi, meutim i dalje se moe nazvati
relacijom zato to su podaci razmjeteni u redove i kolone, a sve vrijednosti su skalarne.
Kako je ve reeno, cijela struktura je relacija. Svaki red podataka zove se torka (engl.
tuple). Tehniki gledano, svaki red je zapravo n-torka (npr. petorka, estorka itd.), ali se n-
obino izostavlja. Ukupan broj torki u relaciji odreuje kardinalitet (engl. cardinality) relacije.
U primjeru na slici 1.3. kardinalitet je 12. Svaka kolona torke zove se atribut ili obiljeje (engl.
attribute). Ukupan broj atributa odreuje stepen (engl. degree) relacije. U primjeru na slici 1.3.
stepen relacije je 3.
Slika 1.3. Komponente relacije
13
Relacija je podijeljena na dva odjeljka: zaglavlje i tijelo. Torke ine tijelo ralacije, a u
zaglavlju se ispisuju nazivi atributa. Treba voditi rauna da se u relacionoj notaciji natpis u
zaglavlju svakog atributa sastoji od dva dijela, razdvojena dvotakom na primjer, Jedinina
cijena: Valuta (KM). Prvi dio natpisa je ime atributa, dok je drugi dio domen atributa. Domen
(engl. domain) atributa je vrsta podataka koje atribut predstavlja u ovom sluaju to su
novani iznosi. Domen nije isto to i tip podataka, o emu e se jo govoriti. Specifikacija
domena esto se izostavlja u zaglavlju.
Tijelo relacije sastoji se od neureenog skupa jedne ili vie torki. Tu imamo nekoliko vanih
koncepata. Prvo, relacija nije ureena. Moe se zamisliti relacija kao papirnata kesa u kojoj su
torke nagomilane bez ikakvog posebnog redoslijeda. Redni brojevi zapisa, uobiajen mehanizam
za pristupanje zapisima u nerelacionim bazama podataka, ne postoje u relacijama. Drugo,
relacija bez ijedne torke (tzv. prazna relacija) takoe je relacija. Tree, relacija je skup. Svaki
element skupa se, po definiciji, moe nedvosmisleno identifikovati. Prema tome, da bi se
odreena tabela kvalifikovala kao relacija, svaki zapis mora da bude nedvosmisleno
identifikovan i tabela ne smije da sadri duplirane zapise.
itaoci koji su itali Accessovu ili SQL Serverovu dokumentaciju, nee ovdje prepoznati
neke termine. To su formalni izrazi koji se koriste u tehnikoj literaturi, ali ih Microsoft ne
koristi. Naalost, Microsoftovi proizvodi ne samo to nisu usklaeni s formalnom
terminologijom, nego nisu usklaeni ni meusobno. Izrazi koji se koriste u dva Microsoftova
proizvoda (Access, SQL Server) prikazani su u tabeli 1.1. U ovom materijalu koristie se
formalna terminologija.
Tabela 1.1: Relaciona terminologija

Formalna terminologija
Konceptualna Fizika Access SQL Server
relacija tabela tabela ili skup zapisa tabela ili skup rezultata
atribut polje polje kolona
torka zapis zapis red
14
1.5. Model podataka
Najapstraktniji nivo projektovanja baze podataka jeste model podataka, to je konceptualni

opis prostora problema. Modeli podataka sastoje se od elemenata koji mogu biti entiteti, atributi,
domeni i veze. Ovdje emo pojedinano razmotriti te elemente.
1.5.1. Entiteti
Teko je osmisliti preciznu formalnu definiciju entititeta (engl. entity), ali je pojam relativno
lako razumljiv: entitet je sve o emu sistem treba da skladiti podatke.
Kada se pone projektovanje modela podataka, nee biti teko da se sastavi poetna lista
entiteta. Kada se govori o prostoru problema, veina imenica i glagola kandidati su za entitete.
Kupci kupuju robu. Prodavci prodaju robu. Dobavljai nam prodaju robu. Imenice Kupci,
Roba, Prodavci i Dobavljai predstavljaju oigledne entitete.
Dogaaji predstavljeni glagolima kupiti i prodati takoe su entiteti, ali tu postoji

nekoliko zamki. Prvo, glagol prodati predstavlja dva razliita dogaaja: prodaju robe kupcu
(ProdavacKupac) i nabavljanje robe za prodaju (DobavljaPreduzee).U ovom primjeru,
razlika je sasvim oigledna, ali je to zamka u koju se lako upada, naroito ako nije dobro izuen
prostor problema.
Druga zamka je suprotna prvoj: dva razliita glagola (kupuju u prvoj reenici i prodaju
u drugoj) opisuju zapravo isti dogaaj, tj. da je kupac kupio odreenu robu. Ovo nije uvijek
oigledno, osim kada se dobro poznaje prostor problema. Ovaj problem se esto tee uoava od
prvog. Ako klijent koristi razliite izraze da bi opisao neto to nama na prvi pogled izgleda kao
isti dogaaj, on moda govori o razliitim vrstama dogaaja. Na primjer, ako je na klijent
proizvoa konfekcije, rezultat dogaaja kupac kupuje odijelo i kupac naruuje odijelo u
oba sluaja je prodano odijelo, ali u prvom sluaju to moe biti kupovina ve gotovog
konfekcijskog odijela, dok se u drugom sluaju radi o ivenju odijela po mjeri. To su dvije vrlo
razliite radnje koje se moraju modelovati na razliite naine.
Osim razgovora s klijentima na osnovu kojih emo sastaviti listu entiteta, korisno je prouiti
dokumente koji postoje u prostoru problema. Obrasci za unoenje raznih podataka, izvjetaji i
15
pisana uputstva, dobri su izvori kandidata za entitete. Meutim, moramo biti oprezni sa pisanim
dokumentima. Pisani dokumenti mogu biti prilino zastarjeli tampani obrasci za unoenje
podataka mogu biti poprilino skupi i esto ne prate promjene poslovnih pravila i postupaka.
Ako se naie na entitet koji se ne spominje ni u jednom razgovoru, ne treba pretpostavljati da je
klijent zaboravio da ga spomene. Vjerovatnije je da taj entitet vie nije vaan organizaciji.
Moraemo sami da ispitamo ta je posredi.
Veina entiteta su modeli objekata ili dogaaja iz stvarnog ivota: kupci, roba, prodajne
ponude. To su konkretni entiteti. Entiteti mogu biti i modeli apstraktnih koncepata.
Najuobiajeniji primjer apstraktnog entiteta jeste entitet koji modeluje vezu ili odnos (engl.
relationship) izmeu drugih entiteta na primjer, injenicu da je odreeni predstavnik kompanije
odgovoran za odreenog klijenta, ili da odreeni student slua predavanja iz odreenog
predmeta.
Ponekad je dovoljno modelovati samo injenicu da veza ili odnos postoji. U drugim
sluajevima moe biti potrebno da o toj vezi evidentiramo i dodatne podatke, kao to je datum
uspostavljanja veze, ili neku drugu odliku te veze (ili odnosa). Na primjer, odnos izmeu pume i
kojota je konkurentski, dok je odnos izmeu pume i zeca takav da puma lovi zeca, to je korisno
znati ako se planira izgradnja zoolokog vrta bez kaveza.
Postoje razliita mjljenja o tome da li bi veze izmeu entiteta koje nemaju svoje sopstvene
atribute trebalo da se modeluju kao zasebni entiteti. Mislimo da se time nita ne dobija, a
komplikuje se postupak izvoenja eme iz modela podataka. Meutim, shvatanje da su
veze/odnosi izmeu entiteta podjednako vani kao i sami entiteti, kljuno je za projektovanje
kvalitetnog modela podataka.
1.5.2. Atributi
Sistem koji se projektuje mora da evidentira odreene injenice o svakom entitetu. Kako je
ve reeno, te injenice su atributi entiteta. Na primjer, ako u svom sistemu imamo entitet
Kupac, vjerovatno e biti vano znati imena i adrese kupaca, a moda i njihova zanimanja. Ako
se modeluje dogaaj kao to je ZahtjevZaServisiranje, vjerovatno treba znati koji je klijent u
pitanju, ko je zvao i da li je problem rijeen. Svi navedeni elementi su atributi.
16
Odreivanje atributa koji e se ugraditi u model jeste semantiki postupak, to znai da se

odluke donose na osnovu znaenja podataka i naina na koji e se oni koristiti. Pogledajmo est
primjer: adresu. Da li e se adresa modelovati kao jedan entitet (Adresa) ili kao grupa vie
entiteta (Ulica, Broj, Grad, Potaniski broj, Drava)? Veina projektanata obino automatski
razbija adresu na grupu atributa zbog opteg principa da se lake radi sa strukturiranim
podacima, ali to nije uvijek tano, a svakako nije oigledno.
Kao primjer uzmimo lokalni kulturni centar. Potrebno im je da evidentiraju adrese svojih
lanova kako bi mogli da tampaju naljepnice za koverte. Poto je to jedina svrha za koju e se
adrese koristiti, nema razloga da se adresa ikada tretira drugaije nego kao jedan blok od vie
redova teksta, koji se tampa na zahtjev.
Ali ta je sa kompanijom koja se bavi prodajom robe putem Interneta? Zbog obrauna carina
i poreza, kompaniji je potrebno da zna u kojoj dravi ivi svaki njen kupac. Iako se podatak o
dravi moe izdvojiti iz tekstualnog polja, to nije lako; prema tome, logino je da u ovom sluaju
treba modelovati barem dravu kao zaseban atribut. ta je sa ostalim dijelom adrese? Da li bi ga
trebalo razbiti na vie atributa i koji bi to atributi bili? Da li bi odgovarao skup atributa {Kuni
broj, Ulica, Drava, Potanski broj}? Meutim, moe zatrebati i broj stana, broj potanskog
pretinca. ta uraditi aki je u pitanju usluna adresa koja pripada nekom drugom? ta uraditi sa
adresama drava koje nemaju standardan domai format?
Nije u pitanju samo format adrese, nego je u pojedinim dravama razliit redosljed atributa.
Na primjer, za razliku od SAD, u veem dijelu Evrope kuni broj se pie iza imena ulice.
Meutim, koliko e operatera prepoznati da adresa 4/32 Griffen Avenue, Bindi Beach,
Australija, znai stan broj 4 u zgradi na broju 32?
Sutina u ovom sluaju nije to da je teko modelovati adresu (mada jeste), nego da se ne
moe unaprijed odreivati kako modelovati odreenu vrstu podataka. Sloeni sistem koji se
razvije za obradu meunarodnih porudbina, bie potpuno neprikladan za kulturni centar.
Slikaru Matisu pripisuje se tvrdnja da je slika gotova tek kad joj se vie nita ne moe ni
dodati ni oduzeti. Projektovanje entiteta pomalo je slino tome. Kako znati da smo stigli u tu
fazu? Naalost, odgovor glasi da u to nikad ne moemo biti potpuno sigurni (a ak i ako mislimo
da jesmo, s vremenom emo promijeniti miljenje). Pri tekuem stanju tehnologije, ne postoji
nain da se projektuje struktura baze podataka za koju se moe dokazati da je potpuno ispravna.
Moe se dokazati da u odreenoj strukturi ima propusta i greaka, ali se ne moe dokazati da ih u
17
drugoj strukturi nema. Kako se moe rijeiti taj problem? Nema strogih pravila, ali postoji
nekoliko strategija.
Prva strategija: Krenimo od rezulteta i nemojmo praviti sloeniju strukturu nego to je

zaista potrebno. Na koja pitanja baza podataka mora davati odgovore? Poto je u naem
primjeru, kulturnog centra, jedino pitanje bilo: Na koju adresu treba poslati pismo za tu i tu
osobu?, model s jednim atributom za adresu bio je dovoljan. U drugom primjeru, kompaniji
koja prodaje rodu putem Interneta, bio je potreban odgovor na pitanje: U kojoj dravi ivi ta i ta
osoba?, pa nam je zato bila potrebna drugaija struktura adrese.
Razumije se, mora se voditi rauna i pokuati da se obezbjedi fleksibilnostkoja e pruiti

odgovore, i to ne samo na pitanja koja korisnici postavljaju sada, ve i ona koja se mogu
predvidjeti da e se pojaviti u budunosti. Na primjer, veoma je vjerovatno da e godinu dana
nakon putanja u rad baze podataka u redovnu upotrebu, kulturni centar zatraiti da im se
sortiraju adrese po potanskom broju da bi dobili koliinski popust.
Trebalo bi takoe da se oekuju i pitanja koja bi korisnici postavili kada bi znali da mogu da
ih postave, naroito kada se automatizuje runi sistem. Zamislimo da rukovodilac biblioteke eli
znati koliko je iz fonda od milion knjiga bilo objavljeno u Banjoj Luci prije 1950. godine. U
runom sistemu ovaj zahtjev bi se mogao smatrati gotovo nemoguom misijom, jer je potrebno
ui u ormar s kartotekom i listati. Meutim, u dobro projektovanom sistemu koji radi s bazom
podataka, ta vrsta zahtjeva smatra se trivijalnom.
Jedan od zatitnih znakova dobrih projektanata jeste i temeljitost i kreativnost s kojima

podstiu potencijalna pitanja. Neiskusni analitiari esto tvrde da korisnici ne znaju ta tano
hoe. Naravno da ne znaju; na posao je da im pomognemo da otkriju ta zapravo ele.
Meutim, pri tome moramo biti oprezni. Cijena fleksibilnosti esto je vei stepen
sloenosti. Kao to smo vidjeli na primjeru adrese, to vie usitnjavamo podatke, vie emo imati
posebnih sluajeva za obradu, a to e nas dovesti do take kada predloeno rjeenje gubi smisao.
Druga strategija: Otkrijmo izuzetke. Ova strategija ima dva aspekta. Prvo, moramo
identifikovati sve izuzetke, i drugo, sistem moramo projektovati tako da obrauje to vei broj
izuzetaka, ali da pri tome ne zbunjuje korisnika. Kao ilustraciju ta tano znai ovaj princip,
razmotriemo jo jedan primjer: imena osoba.
18
Ako e namjena sistema koji projektujemo biti korespodencija, od kljune je vanosti da

imena osoba budu tano navedena. Veina imena osoba prilino su jasna sama po sebi. Ako je
primalac, na primjer, gospoa Mirjana L. Stankovi, elementi imena su: Oslovljavanje, Ime,
OevoIme, i Prezime, zar ne? Pogreno. Sigurnije je (i pravilnije po bontonu) koristiti
UobiajenoIme2 i Prezime. Dalje, ta uraditi kad je primalac Sir James Peddington Smythe, Lord
Dunstable? Peddington Smithe je u tom sluaju Prezime, ili je to OevoIme? ta je onda Lord
Dunstable? A pjeva Sting? Da li je to UobiajenoIme ili Prezime? A ta e se desiti Umjetniku
Ranije Poznatom Pod Imenom Prince? Da li nas to zaista zanima?
Posljednje pitanje nije tako besmisleno kao to se ini. Pismo iji je primalac naveden kao
Sir James Peddington Smythe, vjerovatno nee nikog uvrijediti. Ali ime pomenutog gospodina s
plemikom titulom nije Sir Smythe; u javnosti ga oslovljavaju sa Sir James ili moda Lord
Dunstable.Meutim, budimo realni, koliko naih klijenata ima titulu lorda? Kulturni centar nam
sigurno nee zahvaljivati ako im napravimo ekran nalik na onaj sa slike 1.4.
Slika 1.4. Previe sloen ekran za unoenje adresa
2
Potrebno je voditi rauna da je u nekim kulturama, za razliku od nae, uobiajeno da ljudi dobijaju dva, tri ili vie
imena pri roenju. U matinom listu navode se sva imena, ali se u praksi koristi samo jedno, koje se zove
uobiajeno ime (engl. given name).
19
Potrebno je imati u vidu da se mora napraviti kompromis izmeu fleksibilnosti i sloenosti.

Mada je vano obuhvatiti to vei broj izuzetaka, potpuno je razumno da neke od njih
zanemarimo jer su malo vjerovatni da bi opravdali cijenu svog ukljuivanja u sistem.
Razlikovanje entiteta od atributa ponekad moe biti teko. Dobar primjer za to je adresa a
odluka zavisi od prostora problema. Neki projektanti predlau upotrebu samo jednog entiteta za
adresu koji bi predstavljao sve vrste adresa koje se uvaju u sistemu. Sa take gledita
realizacije, to rjeenje prua nesporne prednosti u pogledu kapsuliranja i viekratne upotrebe
koda. Meutim, sa take gledita strukture baze podataka, imamo odreene rezerve.
Na primjer, malo je vjerovatno da e se adrese zaposlenih i kupaca koristiti na isti nain i za

iste namjene. Vjerovatnije je da e se cirkularne poruke zaposlenima slati putem interne e-pote
nego putem klasine pote. Ako je tako, za drugi sluaj pravila i zahtjevi su drugaiji. Nezgrapan
ekran za unoenje podataka prikazan na slici 1.4. ili neto slino tome, moe biti sasvim
prikladan za adrese kupaca. Meutim, ako imamo samo jedan entitet za adrese, moramo koristiti
isti ekran i za adrese zaposlenih; malo je vjerovatno da je to potrebno, a jo manje da e se to
svidjeti korisnicima.
1.5.3. Domeni
Rekli smo na poetku da se u zaglavlju relacija nalaze parovi ImeAtributa:ImeDomena za

svaki atribut. Reeno je da definicija domena odreuje vrstu podataka koje predstavlja atribut.
Tanije reeno, domen (engl. domain) je skup svih prihvatljivih vrijednosti koje atribut moe
imati.
Domeni se esto brkaju s tipovima podataka; to su dva razliita pojma. Tip podataka je
fiziki pojam, dok je domen logiki pojam. Broj je tip podataka; Starost je domen. I Ulica
i Prezime mogu biti predstavljeni poljima tekstualnog tipa, ali je oigledno da su u pitanju
razliite vrste tekstualnih polja, koja pripadaju razliitima domenima.
Domen je ui pojam od tipa podataka jer definicija domena zahtijeva precizniji opis validnih
podataka. Uzmimo kao primjer domen StrunaSprema, koji predstavlja strunu spremu osobe. U
emi baze podataka, taj atribut se moe definisati kao Text, ali to ne moe biti bilo koji tekst, ve
samo element iz skupa {nia, srednja, via, visoka, magistratura, doktorat}.
20
Razumije se da se ne mogu svi domeni definisati pojedinanim navoenjem prihvatljivih

vrijednosti. Starost, na primjer, sadri stotinjak vrijednosti ako je u pitanju starost osoba, ali to
mogu biti desetine hiljada razliitih vrijednosti kada su u pitanju muzejski eksponati. U takvim
sluajevima, umjesto liste vrijednosti, lake je definisati domen u obliku pravila koja utvruju da
li odreena vrijednost pripada skupu prihvatljivih vrijednosti. Na primjer, StarostOsobe moe se
definisati kao cjelobrojna vrijednost u opsegu od 0 do 129, dok bi StarostEksponata bila
cjelobrojna vrijednost vea od 0.
Moe se pomisliti da je domen kombinacija tipa podataka i pravila za ispravnost podataka.

To je pogrean zakljuak. Pravila ispravnosti podataka iskljuivo su dio integriteta podataka, a
ne opisa podataka. Na primjer, pravilo ispravnosti za potanske brojeve odreuje da su
prihvatljivi samo odreeni brojevi, dok je domen za potanske brojeve petocifreni broj.
U navedenim definicijama pominje se vrsta podataka koji se evidentiraju (znakovni ili

numeriki). To nas podsjea na tip podataka, ali ipak nije tako. Tipovi podataka su, kao to je
ve napomenuto, fiziki pojam; oni se definiu i zadaju u obliku koji prepoznaje maina baze
podataka. Bilo bi pogreno definisati domen kao varchat(30) ili Long Integer jer su to opisi
specifini za odreenu mainu baze podataka (SQL Server).
Za svaka dva domena, ako je mogue porediti atribute definisane u tim domenima (pa prema
tome, obavljati i relacione operacije kao to je spajanja), kae se da su oni kompatibilni po tipu
(engl. type compatible). Na primjer dvije relacije: Zaposleni (ifraZaposlenog, Oslovljavanje,
UobiajenoIme, Prezime, Zvanje) i Narudbe (BrojNarudbe, Kupac, ifraProdavca,
DatumNarudbe), mogu se povezati putem atributa ifraZaposlenog=ifraProdavca. To se moe
uraditi, na primjer, da bi se dobio spisak faktura koje je svaki zaposleni izdao. Domeni
ifraZaposlenog i ifraProdavca kompatibilni su po tipu. Meutim, ako pokuamo kombinovati
navedene dvije relacije putem atributa ifraZaposlenog=BrojNarudbe, vjerovatno se nee dobiti
smislen rezultat, uprkos tome to su oba domena definisana sa istim tipom podataka.
Naalost, ni maina baze podataka Jet niti SQL Server ne pruaju ugraenu podrku za
domene koja bi bila jaa od obine provjere tipova podataka. ak i za tipove podataka, nijedna
maina baze podataka ne obavlja striktnu provjeru tipa: obe e mirno konvertovati podatke u
pozadini. Na primjer, ako se koristi Microsoftov Access i u tabeli Zaposleni smo definisali da je
ifraZaposlenog tipa Long Integer, a u tabeli Fakture atribut FakturaTotal (ukupan zbir)
definisan kao Currency, moemo napraviti upit koji povezuje te dvije tabele kao
21
ifraZaposlenog=FakturaTotal. Microsoftov Jet e nam sastaviti spisak zaposlenih ije su ifre

(ifraZaposlenog) jednake ukupnim zbirovima odreenih faktura. Ta dva atributa nisu
kompatibilna po tipu, ali Jet to ne zna ili zanemaruje.
Ako je to tako, zato bi se uopte petljali s domenima? Zato to su oni, kao to emo
pokazati, izuzetno korisne alatke pri projektovanju baza podataka. Da li su ta dva atributa
meusobno zamjenjiva? Postoje li pravila koja vae u jednom, a ne vae u drugom domenu?
To su vana pitanja kada se projektuje model podataka, a analiza domena pomae nam da
naemo odgovore.
1.5.4. Veze/odnosi izmeu entiteta
Osim atributa svakog entiteta, model podataka mora da definie i veze ili odnose koji
postoje izmeu entiteta. Na pojmovnom nivou, veza ili odnos (engl. relationship) jeste
asocijacija izmeu entiteta. Reenica kupci kupuju robupokazuje da postoji veza izmeu
entiteta Kupci i Roba. Entiteti izmeu kojih postoji veza ili odnos zovu se uesnici veze (engl.
participants).
Broj uesnika odreuje stepen veze. (Stepen veze je slian, ali ne i jednak, stepenu relacije,
to je ukupan broj atributa.)
Velika veina veza izmeu entiteta je binarna, kao u primjeru kupci kupuju robu, ali to
nije pravilo. Uobiajene su ternarne veze, tj. one sa tri uesnika. Binarne veze zaposleni prodaju
robu i kupci kupuju robu implicitno podrazumijevaju postojanje ternarne veze zaposleni
prodaju robu kupcima. Meutim, navedene dvije binarne veze ne omoguavaju nam da
saznamo koji su zaposleni koju robu prodali kojim kupcima; to se moe saznati samo pomou
ternarne veze.
Specijalni sluaj binarne veze je entitet koji uestvuje u vezi sa samim sobom. To se esto
zove veza tipa sastavnice (engl. bill of materials relationship) i najee se koristi za
predstavljanje hijerarhijskih struktura. Uobiajen primjer je odnos izmeu zaposlenih i
nadreenih rukovodilaca. Svaki zaposleni moe istovremeno i biti rukovodilac i imati sebi
nadreenog rukovodioca.
22
Veza ili odnos izmeu dva entiteta moe biti tipa jedan prema jedan, jedan prema vie
ili vie prema vie. Veze tipa jedan prema jedan su rijetke, ali mogu biti korisne u nekim
okolnostima.
Veze tipajedan prema vievjerovatno je najuobiajenija vrsta. Jedna faktura se sastoji od

vie artikala. Jedan prodavac izdaje vie faktura. U oba primjera imamo vezu tipa jedan prema
vie.
Iako nisu toliko este kao veze tipa jedan prema vie, veze tipa vie prema vie nisu
neuobiajene i mogu se nai brojni primjeri. Jedan kupac kupuje vie artikala, a isti artikal moe
kupiti vie kupaca. Vie studenata slua predavanja kod jednog profesora, a isti student moe
sluati predavanja vie profesora. Veze tipa vie prema vie ne mogu se direktno predstaviti u
relacionom modelu, ali je njihov indirektan oblik vrlo jednostavan.
Uestvovanje jednog entiteta u vezi moe biti djelimino ili potpuno. Ako entitet ne moe
postojati ukoliko ne uestvuje u nekoj vezi, uestvovanje je potpuno; u suprotnom, uestvovanje
je djelimino. Na primjer, podaci o odreenom Prodavcu ne mogu logiki da postoje ako ne
postoji odgovarajui zaposleni. Obrnuto nije tano. Poto zaposleni moe biti i neto drugo osim
prodavca, moe postojati zapis o Zaposlenom bez odgovarajueg zapisa meu Prodavcima.
Prema tome, uestvovanje Zaposlenog u vezi je djelimino, dok je uestvovanje Prodavca
potpuno.
Trik je u tome da tvrdnja o djeliminom ili potpunom uestvovanju bude tana za sve
instance (primjerke) entiteta, u svim sluajevima. Na primjer, nije neuobiajeno da kompanija
promijeni dobavljaa za odreeni artikal. Ako je uestvovanje entiteta Artikal u vezi dobavljai
dobavljaju artikle definisano kao potpuno, tekueg dobavljaa ne moemo izbrisati ako ne
izbriemo sve podatke o artiklima koje nam on dobavlja.
1.5.5. Dijagrami entiteta i veza
Model entiteta i veza, koji podatke opisuje izraene kao entitete, atribute i veze, uveo je
Peter Pin Shan Chen 1976. godine3. Istovremeno je predloio metodu predstavljanja pomou
dijagrama nazvanih Entity Relationship (E/R) dijagrami, koja je postala iroko prihvaena. E/R
3
Peter Pin Shan Chen, The entity Relationship Model Toward a Unified View of Data?, ACM TODS 1, broj 1
(mart 1976)
23
dijagrami se sastoje od pravougaonika, koji predstavljaju entitete, elipsi, koje predstavljaju

atribute i rombova, koji predstavljaju veze izmeu entiteta. (Slika 1.5).
Priroda veza izmeu entiteta (jedan prema jedan, jedan prema vie ili vie prema vie)
predstavlja se na dva naina. Mnogi koriste simbole 1 i M ili 1 i ili simbol vranina kanda,
prikazan na slici 1.5.
Velika prednost E/R dijagrama jeste to to se lako crtaju i razumiju. Jedna grupa autora
obino crta atrubute na odvojenom dijagramu jer se mogu praviti dijagrami sa razliitim nivoima
detalja. Uglavnom, na dijagramu razmatramo ili entitete koji ine model i veze izmeu njih, ili
atribute datog entiteta, ali rijetko razmatramo oba aspekta istovremeno.
Slika 1.5. Primjer E/R dijagrama
24
1.6. Saetak
U ovom poglavlju razmotrili smo komponente sistema koji radi s bazom podataka i postavili
osnovu za projektovanje baza bodataka. Poeli smo od opisa prostora problema kao odreenog,
precizno definisanog dijela stvarnog svijeta. Konceptualni model podataka je opis prostora
problema izraen pomou entiteta, atributa i domena u kojima su definisani. Fizika struktura
modela podataka je ema baze podataka, koja se realizuje u bazi podataka. I najzad, maina baze
podataka fiziki manipulie podacima na zahtjev aplikacije sainjene od obrazaca i izvjetaja s
kojima korisnici rade.
25
2. Struktura baze podataka
U ovom poglavlju prouiemo prvi aspekt projektovanja modela relacionih podataka:

strukturu relacija. Glavni cilj ove faze projektovanja je jednostavan: treba obezbjediti da model
bude u stanju da prui odgovor na svako razumno pitanje koje moe biti postavljeno. Sekundarni
cilj je minimizacija redundantnosti i problema koji potiu od nje.
2.1. Elimisanje redundantnosti
Redundantnost (engl. redundancy) rasipa resurse i, to je jo vanije, oteava rad s bazom

podataka. Pogledajmo, na primjer,, skup zapisa prikazan na slici 2.1. fakture koje je izdala neka
kompanija. (Smatrajmo zasad da je taj skup zapisa sadraj stvarne tabele koja se uva u bazi
podataka, a ne rezultat nekog upita.)
Slika 2.1. Ovaj skup zapisa sadri redundantne (duplirane) podatke
Vidljivo je da se za nekoliko zaposlenih ponavljaju vrijednosti u kolonama

DatumZaposlenja i Telefon. To ima vie posljedica. Prvo, to znai da kad god unosimo novu
fakturu, moramo ponovo upisivati iste vrijednosti u ta polja. Razumije se, kad god unosimo
podatke koje ve imamo, postoji ansa da neto unesemo pogreno. Na primjer, u zapisima
prikazanim na slici 2.2 kako emo znati da li je Markovi Ana poela da radi 2002. Ili 2004.
Godine?
26
Drugo, ova struktura ne omoguava da unesemo datum zaposlenja ili telefonski broj novog
zaposlenog sve dok on neto ne proda. Tree, ako se fakture iz odreene godine arhiviraju i
uklone iz baze podataka, gube se i podaci o datumu zaposlenja i telefonskom broju prodavca.
Slika 2.2. Duplirani podaci mogu biti uzrok neusklaenosti
Ta vrsta problema, koji se obino nazivaju anomalije pri auriranju (engl. update anomalies),
postaje jo gora kada se redundantni podaci nalaze u vie od jedne relacije. Pogledajmo skupove
zapisa na slici 2.3. (Pretpostavimo da su to stvarne tabele, a ne rezultati upita). Ako se promijeni
broj telefona kompanije Alfirevi Fruteks, moraemo aurirati taj podatak na vie mjesta
jedanput u skupu zapisa Kupci i est puta u skupu zapisa Fakture.
Sutina nije u tome da se ta operacija ne moe obaviti, niti je to neto posebno teko.
Problem je u tome da ne zaboravimo da je obavimo. Pa ak i ako pojedinac nikada nita ne
zaboravlja (to je prilino malo vjerovatno), kako emo znati da e programer koji radi na
odravanju aplikacije kroz est mjeseci znati da postoje redundantnosti te vrste i da e se sjetiti (i
znati kako) da ih pravilno obradi? Znatno je bolje izbjegavati redundantnost podataka i probleme
koji iz njih izviru.
Moramo se uvjeriti da li su redundantni atributi koje razmatramo zaista redundantni.

Pogledajmo primjer na slici 2.4. Na prvi pogled, moda bismo pomislili da su atributi
JedininaCijena u te dvije relacije redundantni. Oni zapravo predstavljaju dvije razliite
vrijednosti. Atribut JedininaCijena u relaciji Artikli predstavlja tekuu prodajnu cijenu. Atribut
JedininaCijena u relaciji Porudbine predstavlja cijenu na dan kada je artikal bio prodat. Na
primjer, atribut JedininaCijena artikla Sirup umsko voe ima vrijednost 18,60 KM u relaciji
Porudbine, dok je u relaciji Artikli ta vrijednost 23,25 KM. injenica da je tekua cijena artikla
Sirup umsko voe 23,25 KM ne mijenja injenicu da je taj artikal nekad ranije prodat po
cijeni od 18,60 KM. Oba atribura su definisana u istom domenu, ali su logiki razliiti.
27
Slika 2.3. Isti duplirani podaci mogu da postoje u vie relacija
Slika 2.4. Naizgled isti podaci ne moraju obavezno biti i redundantni
28
2.2. Obezbjeivanje fleksibilnosti
Drugi cilj faze projektovanja je da se obezbjedi fleksibilnost baze podatakatj. Da ona moe
da prui odgovor na svako razumno pitanje koje se postavi. Fleksibilnost zavisi prvenstveno od
raznovrsnosti podataka (oigledno je da nijedna baza ne moe dati podatke koje ne sadri), a tek
potom od strukture tih podataka. Meutim, lakoa s kojom se dobijaju odgovori na pitanja
gotovo je iskljuivo rezultat strukture podataka. Princip je da se atributi i relacije lako kombinuju
kada su razdvojeni, ali se veoma teko razdvajaju kad su kombinovani.
Slika 2.5. Spajanje podataka je jednostavno, ali je teko izdvajanje podataka iz kombinovvanih
polja
Na primjer, ako su date dvije relacije prikazane na slici 2.5, iz prve se lako moe formirati
PunoIme osobe pomou iskaza:
Naslov & & UobiajenoIme & & Prezime & _ , & Funkcija
29
Meutim, da bismo izdvojili ime osobe (LastName) iz polja PunoIme u relaciji Zaposleni 1,
morali bismo da obradimo vrijednost atributa PunoIme na sljedei nain:
Function GetLastname (PunoIme) As String
Dim lastname As String
prvo ukalanjamo funkciju osobe

Lastname = Left (PunoIme, InStr (PunoIme, " ,") 1)
zatim uklanjamo nain oslovljavanja
Lastname = Right (lastname, Len(lastname) _ _
InStr(lastname , " "))
zatim uklanjamo ime osobe
Lastname = Right (lastname , Len(lastname ) - _
InStr(lastname , " "))
Get Lastname = lastname

End function
Tanost rezultata ove tehnike zavisi od varijanti sadraja polja PunoIme. Na primjer, ako se
osoba zove Milan Marka Markovi, rezultat e biti Marka Markovi, kada bismo vjerovatno
oekivali Markovi; ili ako se osoba zove Mirjana Zrni Markovi, rezultat e biti Zrni
Markovi, kada bismo vjerovatno oekivali Markovi. Ako nam treba lista u formatu Ime,
Prezime, moe se ispostaviti da to uopte nije lak posao.
Drugi princip koji vai pri izradi modela podataka i koji moe da prui tane odgovore na
postavljena pitanja, jeste da treba izbjegavati situacije u kojima je za odgovor na pitanje potrebno
uitavati iste podatke iz vie polja. Kao primjer, pogledajmo relacije na slici 2.6, koje obe
modeluju studente upisane na pojedine kolegijume.
Da bismo na pitanje: Koji studenti su upisali Biologiju ove godine?, odgovorili pomou
prve relacije, morali bismo da traimo vrijednost Biologija u tri polja. SQL iskaz SELECT za
tu namjenu izgledao bi ovako:
Select BrojIndeksa FROM Enrolments WHERE Semestar1 = "Biologija"
OR Semestar2 = "Biologija" OR Semestar3 = "Biologija"
30
U drugoj strukturi dovoljno je da pretraimo samo polje Kolegijum:

Select BrojIndeksa FROM Enrolments WHERE Kolegijum = "Biologija"
Slika 2.6. Oba skupa zapis sadre iste podatke
Obe strukture slue svrsi, ali se druga lake kodira, i manja je vjerovatnoa da emo
pogrijeiti, da ne govorimo o tome da emo je lake osmisliti.
Sve to treba znati o modelovanju podataka jeste kako da izbjegnemo redundantnost i kako
da pojednostavimo nain na koji se dolazi do traenih podataka; ostatak je samo pokuaj
formalizovanja ta dva principa. Meutim, uprkos jednostavnosti ova dva principa, njihova
praktina primjena ponekad moe biti veoma zapetljana. Oni podsjeaju na spajalicu za papir:
rjeenje izgleda potpuno oigledno, kad ga shvatite, ali malo se treba namuiti dok se prvi put ne
snaemo sa hrpom listova papira i komadom ice.
31
2.3. Osnovni principi
Postupak strukturiranja podataka u prostoru problema da bi se eliminisala redundantnost i

obezbjedila fleksibilnost, zove se normalizovanje (engl. normalization). Principi
normalizovanja, koje opisujemo u narednom dijelu ovog poglavlja jesu alatke za organizovanje
strukture podataka, na slian nain kao to spajalica organizuje listove papira. Normalne forme
(opisaemo njih est) odreuju pravila s rastuim stepenom strogosti za strukture relacija. Svaka
naredna normalna forma se nadovezuje na prethodnu tako to spreava odreene vrste anomalija
pri auriranju.
Treba imati u vidu da normalne forme nisu recept za izradu tanog modela podataka.
Model podataka moe biti savreno normalizovan, pa da uprkos tome ne uspijeva da prui
odgovore na postavljena pitanja; ili moe da prui odgovore, ali toliko sporo i nezgrapno, da
sistem napravljen na osnovu tog modela postaje neupotrebljiv. Ako je model podataka
normalizovan, tj. usklaen s pravilima relacione strukture, velika je vjerovatnoa da e rezultat
biti efikasan i djelotvoran model podataka.
Meutim, prije nego to preemo na normalizovanje, trebalo bi da se upoznamo s odreenim

principima iz te oblasti.
2.3.1. Dekomponovanje bez gubitaka
Relacioni model omoguava da povezivanjem atributa spajamo relacije na razliite naine.

Postupak izrade potpuno normalizovanog modela podataka obuhvata uklanjanje redundantnosti
razbijanjem relacija u oblik koji omoguava da se rezultujue relacije kombinuju bez gubljenja
ijednog izvornog podatka. To je princip dekomponovanja bez gubitaka (engl. loseless
decomposition). Na primjer, iz relacije prikazane na slici 2.7, moemo izvesti dvije relacije
prikazane na slici 2.8.
Slika 2.7. Primjer nenormalizovane relacije
32
Slika 2.8. Relacija sa slike 2.7. moe se razdvojiti na ove dvije relacije bez gubljenja ijednog
podatak
2.3.2. Kandidati za kljueve i primarni kljuevi
U prvom poglavlju definisali smo tijelo relacije kao neureen skup nula ili vie torki i
napomenuli smo da je, po definiciji, svaki pripadnik skupa jedinstven. U skladu s tim slijedi, u
svakj relaciji mora postojati odreena kombinacija atributa koja na nedvosmislen nain
identifikuje svaku torku. Ako taj uslov nije ispunjen, redovi takve relacije nisu torke u smislu
relacione teorije. Taj skup ili kombinacija jednog ili vie atributa zove se kandidat za klju (engl.
candidate key).
U jednoj relaciji moe biti vie od jednog kandidata za klju, ali svaki kandidat mora da
nedvosmisleno identifikuje svaku torku u relaciji, i to ne samo odreeni skup torki, nego sve
mogue torke, u svim sluajevima. Uzgred, mora biti ispunjen i suprotan uslov. Ako dvije torke
imaju jednake kandidate za klju, one moraju da predstavljaju isti entitet.
33
Kao i mnogo toga drugora u relacionom projektovanju, utvrivanje kandidata za kljueve je

semantiki postupak. To se ne moe uraditi samo ispitivanjem vrijednosti podataka. Ako je
odreeno polje ili kombinacija atributa jedinstvena za odreeni skup torki, ne moe se
garantovati da e tako biti za sve torke, to je uslov da bi ta kombinacija bila kandidat za klju. U
ovom sluaju takoe, moramo razumjeti semantiku modela podataka, tj. ta podaci stvarno
znae, a ne ta prividno znae.
Pogledajmo relaciju Porudbine 2 u donjem dijelu slike 2.8. Atribut ifra kupca ima
jedinstvene vrijednosti u ovom primjeru, ali je vrlo malo vjerovatno da e uvijek biti tako.
Po definiciji, svaka relacija mora da ima barem jednog kandidata za klju: to je skup svih
atributa koji ine torku. Kandidat za klju moe se sastojati od samo jednog atributa (prost
klju, engl. simple key) ili od vie njih (sloen klju, engl. composite key).
Neki smatraju da sloeni kljuevi nisu ispravno rjeenje i da zato moraju da dodaju svojim
tabelama vjetake identifikatore polja tipa identity ili autonumber da bi izbjegli sloene
kljueve. To je potpuno pogreno. Vjetaki su kljuevi, kao to emo vidjeti, esto praktiniji,
ali su sloeni kljuevi potpuno prihvatljivi.
Meutim, kandidat za klju mora da ispuni jo jedan dodatan uslov, a to je da se ne moe

razbiti na prostije dijelove; zbog toga skup svih atributa relacije ne mora obavezno biti kandidat
za klju. U relaciji prikazanoj na slici 2.9, atribut {Naziv kategorije} kandidat je za klju, kao to
je i atribut {Opis}, ali skup {Naziv kategorije, Opis}, iako jedinstven, nije kandidat za klju jer
je atribut Opis suvian.
Slika 2.9. Budui da kandidati za kljueve moraju biti atributi koji se ne mogu dalje razdvajati,
{naziv kategorije} odgovara, ali {Naziv kategorije, Opis} ne odgovara.
34
Ponekad mada ne esto dogaa se da relacija ima vie od jednog kandidata za kljueve.
U takvim sluajevima, jedan od kandidata odreuje se kao primarni klju (engl. primary key), a
drugi kandidati se smatraju alternativnim kljuevima (engl. alternate keys). To je proizvoljna
odluka koja nije mnogo bitna na logikom nivou. (Imajmo u vidu da je model podataka isto
apstraktni koncept). Da bi lake razlikovali model od njegove fizike realizacije, u kontekstu
modela podataka radije emo koristiti izraz kandidat za klju, a izraz primarni klju uvajmo
za fiziku realizaciju modela.
Kada je jedini mogui kandidat nezgrapan moemo dodati polje s vjetakim kljuevima
iji je tip podataka takav da sistem automatski generie vrijednost kljua.
Polja tog tipa, koji se u Microsoftovom Jetu zove AutoNumber, a u SQL Serveru Identity,
izuzetno su korisne alatke, pod uslovom da ne pokuavamo da im dodijelimo bilo kakvo
znaenje. To je zapravo samo nain oznaavanja torki. Nije garantovano da e vrijednost slijediti
jedna drugoj, imamo malo kontrole nad vrijednostima koje generiu, a ako pokuamo da im
dodijelimo neko znaenje, napraviemo vie problema nego to emo ih rijeiti.
Iako je odreivanje kandidata za kljueve, kao to smo vidjeli, semantiki postupak, ne treba
polaziti od pretpostavke da e atributi pomou kojih identifikujemo odreeni entitet u stvarnom
svijetu biti upotrebljivi i kao kandidati za klju. Na primjer, ljude identifikujemo uglavnom
pomou imena i prezimena, ali samo povran pogled u telefonski imenik uvjerie nas da imena i
prezimena nisu jedinstvena.
Razumije se, ime i prezime osobe moe biti kandidat za klju u kombinaciji drugih atributa,
ali to moe biti prilino nezgrapno. Na primjer, vrlo se lako moe dogoditi da u istoj firmi rade
tri osobe koje se zovu Milan, imaju isto prezime i rade isti posao. Ostali zaposleni ih mogu
razlikovati kao Mali Milan, Milan Panevac i Crni Milan, tj. po visini, po porjeklu i po
boji kose u kombinaciji sa imenom, to teko moe biti upotrebljivo za klju.
U takvim situacijama vjerovatno je najbolje rjeenje upotreba identifikacionog broja koji

sistem sam generie, kao to su polja tipa AutoNumber ili Identity, ali se ne smije zaboraviti da
ta vrijednost ne treba da ima nikakvo konkretno znaenje u sistemu. Razumije se, moramo voditi
rauna i o tome da e korisnici namjerno dodavati v rijednosti koje se prividno dupliraju, ali kao
to e se u narednim poglavljima vidjeti, to je najbolje kontrolisati u sklopu korisnikog
35
interfejsa, umjesto da nameemo vjetaka (i u sutini nepotrebna) ogranienja podataka koja

sistem treba da odrava.
2.3.3. Funkcionalna zavisnost
Koncept funkcionalne zavisnosti (engl. functional dependency) izuzetno je koristan za rad

sa strukturama podataka. Ako je data torka T i dva skupa njenih atributa. {X1... Xn} i {Y1...
Yn}(ti skupovi ne moraju biti meusobno iskljuivi), skup Y je funkcionalno zavisan od skupa X
ako, za svaku legalnu vrijednost u skupu X, postoji samo jedna legalna vrijednost u skupu Y.
Na primjer, u relaciji prikazanoj na slici 2.9, svaka torka koja sadri istu vrijednost atributa
{Naziv kategorije}, imae istu vrijednost i atributa {Opis}. Zbog toga moemo rei da atribut
Naziv kategorije funkcionalno odreuje atribut Opis. Imajmo u vidu da funkcionalna zavisnost
ne vai uvijek i u suprotnom smjeru: poznavenje vrijednosti atributa Opis ne omoguava nam da
utvrdimo i odgovarajuu vrijednost atributa Naziv kategorije.
Funkcionalnu zavisnost izmeu skupova atributa moemo predstaviti kao na slici 2.10. U
tekstu se funkcionalna zavisnost izraava kao X Y, to se ita kao X funkcionalno odreuje
Y.
Slika 2.10. Dijagrami funkcionalne zavisnosti obino su jasni sami po sebi
Funkcionalna zavisnost je zanimljiva za ljude sklone akademskom nainu razmiljanja jer

prua mehanizam za razvijanje neega to poinje da lii na matematiku modelovanja podataka.
Na primjer, moemo da razmotrimo refleksivnost i tranzitivnost funkcionalne zavisnosti, ukoliko
volimo da razmiljamo na taj nain.
U praktinim aplikacijama, funkcionalna zavisnost je zgodan oblik da se izrazi neto to je

prilino razumljivo samo po sebi: svaka relacija e uvijek imati odreeni skup atributa ije su
vrijednosti jedinstvene u svakoj torci; ako su te vrijednosti poznate, mogu se odrediti i
vrijednosti atributa koje nisu jedinstvene.
36
Prema tome, ako imamo torku {X, Y}, gdje je {X} kandidat za klju, onda atributi {Y}
moraju biti funkcionalno zavisni od {X}; to proizlazi iz definicije kandidata za klju. Ako {X}
nije kandidat za klju i funkcionalna zavisnost nije trivijalna (tj. {Y} nije podskup od {X}),
relacija e obavezno sadravati izvjesnu redundantnost i bie potrebno dalje normalizovanje.
Ako se vratimo na primjer sa slike 2.9, kada znamo vrijednost atributa Naziv kategorije, moemo
utvrditi i odgovarajuu vrijednost atributa Opis.
U odreenom smislu, normalizovanje podataka je postupak koji obezbjeuje da, kao to je
prikazano na slici 2.10, sve strelice polaze od kandidata za kljueve.
2.4. Prva normalna forma
Relacija je u prvoj normalnoj formi ako su skalarni svi domeni u kojima su definisani njeni
atributi. To je istovremeno i najjednostavniji i najtei koncept modelovanja podataka. Princip se
lako razumije: svaki atribut torke mora sadravati samo prostu vrijednost. Ali ta je tano prosta
vrijednost? U relaciji prikazanoj na slici 2.11, atribut Stavke oigledno sadri vie vrijednosti (tj.
nije prost), to znai da relacija nije u prvoj normalnoj formi. Meutim, to nije uvijek tako
oigledno kao u ovom primjeru.
Slika 2.11. U ovoj relaciji atribut Stavke nije skalaran
Kada smo u prethodnom poglavlju razmatrali modelovanje imena i adresa ljudi, naili smo
na neke probleme koji mogu nastati pri odreivanju da li je atribut skalaran ili nije. Datumi su
jo jedna nezgodna oblast. Oni se sastoje od tri komponente: dana, mjeseca i godine. Da li bi ih
trebalo uvati u bazi podataka kao tri odvojena atributa ili kao kombinaciju? Kao i uvijek, do
odgovora moemo doi na osnovu semantike prostora problema koji razmatramo.
Ako sistem najee koristi sve tri komponente datuma zajedno, datum treba biti skalarni
atribut. Ukoliko sistem ee obrauje komponente datuma pojedinano, bolje je da ih uvamo u
bazi podataka kao zasebne atribute. Na primjer, moda nam je dan nebitan a zanimaju nas samo
mjesec i godina. Ili, moda su nam vani samo dan i mjesec, ali ne i godina. Takvi sluajevi nisu
ba esti, ali postoje.
37
U specifinom sluaju datuma, budui da prograsmiranje datumske aritmetike nije

jednostavno, olakaemo sebi ivot ako datumske atribute definiemo kao tip podatka DateTime
(datum/vrijeme) koji kombinuje sve tri komponente datuma plus vrijeme. Tip podatka DateTime
omoguie nam da razvojnom okruenju prepustimo vei dio posla izraunavanja datuma koji,
na primjer, prethodi tekuem za 37 dana.
Meutim, atributi tipa DateTime mogu biti uzrok problema kada poredimo pojedinane
komponente. To naroito vai kada u polju zanemarujemo komponentu vremena. Na primjer,
ako polju DatumIzrade naa aplikacija dodjeljuje rezultat VBA funkcije Now, koja daje tekui
datum i vrijeme, a kasnije vrijednost iz tog polja poredimo s rezultatom funkcije Date(), koja
daje samo tekui datum, rezultati mogu biti neoekivani. ak i ako korisnicima aplikacije nikad
ne prikazujemo vrijednost vremenske komponente, podatak o tome se upisuje u bazu, a razumije
se, 1.1.1999 12:30:19 nije isto to i 1.1.1999.
Jo jedna oblast u kojoj ljudi imaju problema s neskalarnim (sloenim) vrijednostima jesu
ifre (engl. codes) i indikatori (engl. flags). Mnoge kompanije dodjeljuju ifre predmeta ili
referentne oznake koje su izraunate vrijednosti, na primjer, neto nalik na REF0010307, to bi
moglo znaiti da je u pitanju prvi predmet zapoet marta 2007. godine. Iako je malo vjerovatno
da e kompanija prihvatiti da mijenja svoja pravila na na zahtjev, bila bi loa ideja da u svom
modelu podataka pokuamo da pojedinano manipuliemo dijelovima referentne oznake.
Dugorono je znatno lake da dijelove referentne oznake uvamo kao zasebne atribute:
{VrstaReference, RedniBrojPredmeta, Mjesec, Godina}. S takvim rjeenjem, odreivanje
narednog broja predmeta otvorenog u datoj godini svodi se na jednostavan upit nad jednim
atributom i ne zahtijeva dodatan rad. To znaajno utie na performanse, naroito u kljient/server
okruenjima, gdje za izdvajanje vrijednosti iz sredine nekog atributa moe biti potrebno da se
svaki zapis pojedinano ispituje na lokalnom klijentskom raunaru (i prenosi putem mree), a ne
na serveru baze podataka.
Jo jedna vrsta neskalarnog atributa s kojim ljudi imaju problema jeste jednobitni indikator.
U konvencionalnim okruenjima za programiranje, uobiajena je praksa da se vie vrijednosti
logikog tipa grupie u jednu rije i da se zatim te vrijednosti uitavaju i ispituju pomou
operatora nad bitovima. Na primer, ta tehnika se veoma esto primjenjuje pri upotrebi funkcija iz
Windowsovog API-ja. U konvencionalnim okruenjima za programiranje, to je potpuno
38
prihvatljivo. U relacionim okruenjima, nije. Ne samo to se time naruava prva normalna forma,
ve je to izuzetno nezgrapno i uglavnom neefikasno.
Naalost, to je vrsta ogranienja koje je esto nametnuto iz istorijskih razloga. Ako imamo
bilo kakvu mogunost izbora po tom pitanju, na treba kodirati vie od jednog podatka u jedan
atribut. Kad moramo raditi sa nasljeenom strukturom podataka, uvijek moemo raspakovati
podatke i obe verzije unijeti u skup zapisa.
Postoji jo jedna vrsta neskalarnih vrijednosti o kojima treba voditi rauna kada se ispituje da
li je relacija u prvoj normalnoj formi, a to su grupe koje se ponavljaju. Na slici 2.12 prikazana je
relacija Faktura. Neko je u nekom trenutku odluio da kupcima nee biti dozvoljeno da kupe vie
od tri razliita artikla. To je gotovo sigurno vjetako ogranienje koje je nametnuo sistem, a ne
sam nain poslovanja. Vjetaka sistemska ogranienja veoma su loa, a u ovom sluaju
besmislena.
Slika 2.12. Ovaj model podataka ograniava broj artikala koje kupac moe da kupi
Jo jedan primjer grupe koja se ponavlja prikazan je na slici 2.13. Greka nije tako oigledna,
a mnogi uspjeni sistemi napravljeni su na osnovu slinog modela. Meutim, to je zapravo ista
struktura kao ona na slici 2.12 i uzrok je istih problema. Zamislimo kako bi izgledao upit koji
treba da utvrdi koji su artikli premaili plan za vie od 10 procenata u bilo kom trenutku prvog
tromjeseja.
Slika 2.13. Ovo je grupa koja se ponavlja
39
2.5. Druga normalna forma
Relacija je u drugoj normalnoj formi ako je u prvoj normalnoj formi i ako njeni atributi
zavise od cijelog kandidata za klju. Na primjer, klju na slici 2.14 je {Naziv artikla, Naziv
dobavljaa}, ali polje Telefonski broj dobavljaa zavisi samo od atributa Naziv dobavljaa, a ne
od cijelog kombinovanog kljua.
Slika 2.14. Svi atributi relacije treba sa budu zavisni od cijelog kljua
Ve smo napomenuli da je posljedica toga redundantnost, a posljedica redundantnosti mogu

biti neprijatni problemi odravanja usklaenosti podataka. Bolji model bio bi onaj prikazan na
slici 2.15.
Logiki gledano, ba bismo dobili drugu normalnu formu, treba pokuati izbjei da dva
razliita entiteta Artikle i Dobavljae predstavimo istom relacijom. Ako entitete predstavimo
odvojenim relacijama, time emo ne samo eliminisati redundantnost, ve emo dobiti i
mehanizam za skladitenje podataka koje na drugi nain ne bismo mogli unijeti. U primjeru na
slici 2.15, postaje mogue da podatke o odreenom dobavljau unesemo prije nego to upiemo
ijedan podatak o artiklima koje nam on dobavlja. To ne bi bilo mogue u prvoj relaciji (slika
2.14) zato to nijedna komponenta primarnog kljua ne moe da se izostavi.
40
Slika 1.15. Ove dvije relacije su u drugoj normalnoj formi.
Drugi nain na koji ljudi upadaju u probleme s drugom normalnom formom jeste da pobrkaju
ogranienja koja vae u odreenom trenutku sa onima koja vae uvijek. Na primjer, u relaciji sa
slike 2.16, pretpostavlja se da dobavlja moe imati samo jednu adresu, to moe biti tano sada,
ali ne znai da e tako ostati i ubudue.
Slika 2.16. U ovom primjeru, jedan dobavlja moe imati jednu adresu, to moe biti problem
41
2.6. Trea normalna forma
Relacija je u treoj normalnoj formi ako je u drugoj normalnoj formi i ako su svi atributi koji
nisu dio nijednog kljua meusobno nezavisni. (slika 2.17.)
Slika 2.17. Relacija Porudbine je u treoj normalnoj formi
U vezi s treom normalnom formom, moe se malo i cjepidlaiti. Na primjer, poto se

u veini mjesta u SAD vrijednost atributa PotanskiBroj sastoji od ifre grada i ifre Oblasti,
relacija prikazana na slici 2.18. nije u treoj normalnoj formi, ako tu definiciju primjenjujemo
doslovno.
Slika 2.18. Ova relacija nije striktno u treoj normalnoj formi
Dvije relacije prikazane na slici 2.19. tehniki su ispravnije, ali jedina stvarna prednost
koju prua to rjeenje jeste mogunost da se automatski potrai odgovarajui potanski broj pri
unoenju novih zapisa, to korisniku tedi nekoliko pritisaka na tastere. To nije tako zanemariva
prednost, ali vjerovatno postoje bolji naini da se obezbjedi takva funkcionalnost, u kojoj nije
potrebna dodatna operacija spajanja relacija kad god se referencira odreena adresa.
42
Slika 2.19. Ove dvije relacije su u treoj normalnoj formi
I ovdje je isti princip kao i pri donoenju svih drugih odluka tokom postupka modelovanja
podataka: kad i kako emo realizovati treu normalnu formu moemo odrediti samo na osnovu
semantike modela. Nemogue je navesti pravila koja bi uvijek vaila, ali postoje odreene
smjernice. Trebalo bi praviti zasebnu relaciju u sljedeim sluajevima:
Entitet je vaan dio modela, ili
Podaci se esto mijenjaju, ili
Sigurni smo da e nam to pruiti odreene tehnike prednosti pri realizovanju modela.
Potanski brojevi se mijenjaju, ali ne esto, a u veini sistema nisu sami po sebi vani. Osim
toga, odvojena tabela potanskih brojeva ne bi bila praktina u veini aplikacija iz stvarnog
ivota zbog razliitih pravila za odreivanje potanskih brojeva (u SAD).
43
2.7. Dalje normalizovanje
Prve tri normalne forme bile su opisane u Coddovoj prvobitnoj formulaciji relacione teorije;
u velikoj veini sluajeva one su sve o emu bi trebalo voditi rauna. S tim u vezi postoji i
izreka: Klju, klju i samo klju, tako mi Codd pomogao.
Ostale normalne forme Boyce-Coddova, etvrta i peta razvijene su za obradu specijalnih

sluajeva, koji su prilino rijetki.
2.7.1. Bojs-Kodova (Boyce-Codd) normalna forma
Boyce-Coddova normalna forma, koja se smatra varijantom tree normalne forme, obrauje
specijalan sluaj relacija koje imaju vie kandidata za kljueve. Da bi Boyce-Coddova normalna
forma bila primjenjiva, moraju biti ispunjeni sljedei uslovi:
Relacija mora imati dva ili vie kandidata za kljueve;
Najmanje dva meu kandidatima moraju biti kombinovani;
Kandidati za kljueve moraju imati neke zajednike atribute.
Najlaki nain da se razumije Boyce-Coddova normalna forma jeste jeste da se upotrebe

funkcionalne zavisnosti. Boyce-Coddova normalna forma propisuje, u sutini, sa ne smije biti
funkcionalnih zavisnosti izmeu kandidata za kljueve. Na primjer, relacija Dobavljai 2 na slici
2.20. Ta relacija je u treoj nornmalnoj formi (pod pretpostavkom da su imena dobavljaa
jedinstvena), ali i dalje sadri znaajnu redundantnost.
Slika 2.20. Ova relacija je u treoj normalnoj formi, ali ne i u Boyce-Coddovoj normalnoj formi
44
Dva kandidata za klju, koja su u ovom primjeru {ifraDobavljaa,

ifraArtikla}{NazivDobavljaa, ifraArtikla}, prikazana su zajedno s dijagramom funkcionalnih
zavisnosti na slici 2.21.
ifraDobavljaa
ifraArtikla
Koliina
JedininaCijena
NazivDobavljaa
ifraArtikla
Slika 2.21. Dijagram funkcionalnih zavisnosti relacije prikazane na slici 2.20.
Kao to se vidi, postoji funkcionalna zavisnost {ifraDobavljaa} {NazivDobavljaa} to

nije u skladu Boyce-Coddovom normalnom formom. Ispravan model prikazan je na slici 2.22.
45
Slika 2.22. Ovaj model je potpuno normalizovana verzije slike 2.21.
2.7.2. etvrta normalna forma
etvrta normalna forma obezbjeuje teorijsku osnovu za princip koji je intuitivno shvatljiv:
Nezavisne grupe koje se ponavljaju ne treba kombinovati u istoj relaciji. Primjera rada,
pretpostaviemo sljedee: roba koju prodaje naa firma isporuuje se u vie razliitih oblika
pakovanja; firma nabavlja robu od vie dobavljaa i svi dobavljaju sve vrste pakovanja. Potpuno
nenormalizovana verzija relacije Artikli 4 prikazana je na slici 2.23.
46
Slika 2.23. Ova realacija nije normalizovana
Prvi korak u normalizovanju ove relacije jeste eliminisanje neskalarnog atributa

VrstaPakovanja; tako dobijemo relaciju prikazanu na slici 2.24.
Iznenauje to da je relacija na slici 2.24. u Boyce-Coddovoj normalnoj formi, budui da

imamo same kljueve. Meutim imamo vrlo oigledan problem redundantnosti, usljed ega bi
odravanje integriteta tih podataka bio veoma teak zadatak. Rjeenje tih problema omoguava
nam koncept zavisnih parova grupa vrijednosti. (engl- multi-valued dependency pairs) i
etvrta normalna forma.
Zavisni par grupa vrijednosti sastoji se od dva meusobno nezavisna skupa atributa. Na slici
2.23, zavisni par grupe vrijednosti je {NazivArtikla} {VrstaPakovanja}| {NazivDobavljaa},
to treba itati kao: Atribut NazivArtikla vieznano odreuje atribute VrstaPakovanja i
NazivDobavljaa. etvrta normalna forma propisuje, neformalno izraeno, da se zavisne grupe
vrijednosti razdvoje u zasebne relacije, kao to je prikazano na slici 2.25. Formalno izraeno,
relacija je u etvrtoj normalnoj formi ako je u Boyce-Coddovoj normalnoj formi i ako su zavisne
grupe vrijednosti funkcionalno zavisne od kandidata za kljueve.
47
Slika 2.24. Ova verzija relacije prikazane na slici 2.23. nalazi se u Boyce-Coddovoj normalnoj
formi
48
Slika 2.25. Relacije koje sadre zavisne grupe vrijednosti treba razdvojiti
2.7.3. Peta normalna forma
Peta normalna forma obrauje rijedak sluaj krunih zavisnosti (engl. join dependencies).
Kruna zavisnost izraava cikliki uslov ako je Entitet 1 povezan sa Entitetom 2, a Entitet 2 je
povezan sa Entitetom 3, a Entitet 3 je povezan sa Entitetom 1, onda sva tri entiteta moraju
obavezno postojati unutar iste torke.
Kada se ovo prevede na obian govorni jezik, znaenje je sljedee: ako {Dobavlja} dobavlja
{Artikal}, a {Kupac} je naruio {Artikal} i {Dobavlja} je neto isporuio {Kupcu}, onda je
{Dobavlja} isporuio {Artikal} {Kupcu}. Razumije se, u stvarnom svijetuovako izveden
zakljuak bio bi pogrean. {Dobavlja} je mogao da isporui {Kupcu} neto, ali ne obavezno i
{Artikal}. Kruna zavisnost postoji samo ako je ispunjen dodatni uslov koji nalae da je
zakljuak izveden na opisani nain taan.
U ovom sluaju nije dovoljna jedna relacija sa atributima {Dobavlja, Artikal, Kupac} zbog
rezultujuih problema pri auriranju podataka. Na primjer, u relaciji prikazanoj na slici 2.26,
umetanje torke {Ana Todori Company, aj zeleni, Trade-M} zahtijeva i umetanje jo
49
jedne torke, {Alfirevi Fruteks, aj zeleni, Trade-M} zato to je modelu dadata nova veza
izmeu artikla aj zeleni i kupca Trade-M.
Slika 2.26. Ova relacija nije u petoj normalnoj formi
Razbijanje relacije na tri zasebne relacije (DobavljaArtikal, ArtikalKupac i

DobavljaKupac), rjeava prvobitni problem, ali uvodi novi: da bismo ponovo dobili prvobitnu
relaciju, morali bismo spojiti tri relacije. Rezultat djeliminog spajanja (samo dvije od tri), bili bi
netani podaci.
Gledano iz ugla projektanta sistema, to je vrlo loa situacija, budui da ne postoji ugraena
metoda automatskog spajanja tri tabele osim kroz bezbjednosna ogranienja. Dalje, ako korisnik
napravi djelimian spoj relacija, rezultat e izgledati vjerodostojno i malo je vjerovatno da e
korisnik uspjeti da otkrije greku prostim uvidom u podatke.
Sreom, kruna zavisnost je toliko rijetka da se njene posljedice mogu sasvim bezbjedno
zanemariti u veini situacija. U sluajevima kada to nije mogue, jedino rjeenje je da sistem koji
treba da radi s takvom bazom podataka napravimo tako da sam obezbjeuje integritet podataka
pri spajanju vie relacija.
2.8. Saetak
U ovom poglavlju razmatrali smo strukture baza podataka sa aspekta normalizovanja

podataka. Osnovni princip na kojem se zasniva normalizovanje jeste eliminisanje redundantnosti
putem dekomponovanja bez gubitaka to je razbijanje jedne relacije na vie drugih, pri emu
ne gubimo nijedan od prvobitnih podataka. Taj princip je formalizovan u konceptu normalnih
formi. Prve tri normalne forme, koje se i najee primjenjuju, saete su u reenici klju, klju i
samo klju, tako mi Codd pomogao. Preostale tri normalne forme koriste se samo u izuzetnim
sluajevima.
50
3. Veze izmeu entiteta
U prethodnom poglavlju razmatrali smo projektovanje strukture baze podataka, postupak

analiziranja entiteta u prostoru problema i razvijanja skupa entiteta koji efikasno i djelotvorno
obuhvataju sve podatke koji su nam neophodni. Relacije su samo jedan dio modela podataka.
Podjednako su vane i veze koje se mogu uspostaviti izmeu relacija i uslovi pod kojima se to
moe uiniti. U ovom poglavlju razmotriemo modelovanje veza izmeu entiteta (engl.
relationships), tj. predstavljanje asocijacija koje postoje u relacionom modelu. Kao i pri
definicanju relacija, osnovni principi postaju lako razumljivi poto savladamo semantiku modela
podataka. Meutim, postoje izvjesni specijalni sluajevi koji se ne uklapaju sasvim glatko u
model veza izmeu entiteta, to emo razmotriti posebno.
3.1. Terminologija
Postoji osnovna terminologija koja se odnosi na veze izmeu entiteta. Entiteti izmeu kojih
postoji odreena veza ili odnos zovu se uesnici (engl. participants), a broj uesnika u vezi zove
se stepen (engl. degree) veze. Veza izmeu entiteta najee je binarna, tj. sastoji se od dva
uesnika, ali postoje i unarne veze (kad je relacija povezana sama sa sobom), a nisu nepoznate
ni ternarne veze (s tri uesnika). Veina primjera veza u ovom poglavlju je binarna. Unarne i
ternarne veze razmotriemo u drugom dijelu ovog poglavlja kao posebne sluajeve.
Uestvovanje entiteta u vezi moe se opisati kao potpuno ili djelimino, u zavisnosti od toga
da li entitet moe ili ne moe postojati nezavisno od veze u kojoj uestvuje. Na primjer, Ako
imamo dva entitet, Kupac i Porudbine, uee entiteta Kupac u vezi je djelimino jer se podaci
o odreenom kupcu mogu unijeti i prije nego to taj kupac poalje prvu porudbinu. S druge
strane, uee entiteta Porudbina je potpuno jer samo postojei kupac moe da poalje
porudbinu.
Po istom principu, entiteti se ponekad klasifikuju kao zavisni tj. slabi (engl. weak), u sluaju
potpunog uea, ili nezavisni tj. jaki (engl. regular), u sluaju djeliminog uea. Slabi entiteti
mogu da postoje samo u vezama s drugim entitetima, dok jaki entiteti mogu da postoje i
samostalno. Ta klasifikacija je dio metode predstavljanja pomou E/R dijagrama, iji je autor
Chen (en). U E/R dijagramima moemo upotrebiti notaciju prikazanu na slici 3.1. kako bismo
pokazali da li je odreeni entitet slab ili jak.
51
Slika 3.1. Ova notacija omoguava razlikovanje slabih entiteta od jakih
Klasifikacija uestvovanja u vezi takoe je pokazatelj obaveznosti (engl. optionality) veze, tj.
da li odreeni entitet mora obavezno da uestvuje u datoj vezi. To je prilino neodreena oblast
zato to se praktina realizacija modela podataka pomou maine baze podataka ne poklapa u
potpunosti s prostorom problama, kao to emo vidjeti kada budemo razmatrali realizovanje
integriteta podataka.
Ponekad je korisno da veze izmeu entiteta dijelimo na kategorije je (jeste) i ima.

Koncept je jednostavan: entitet X je Y ili ima Y. Na primjer, Zaposleni je lan PopisneKomisije;
isti Zaposleni ima Adresu. Razumije se je i ima nisu rijei govornog jezika koje uvijek tano
opisuju prirodu veze. Zaposleni ne moe da ima Porudbinu, ve je on prima ili obrauje,
ali poto je sasvim jasno da Zaposleni nije Porudbina, intelektualni napor koji trebamo uiniti
da bismo razmiljali u kategorijama je i ima nije suvie veliki.
Maksimalan broj primjeraka jednog entiteta koji se moe povezati s jednim primjerkom
drugog entiteta, zove se kardinalitet (engl. cardinality) veze. (Treba imati na umu da stepen i
kardinalitet u kontekstu veza izmeu entiteta imaju neto drugaije zanaenje od onog u
kontekstu relacija.) Postoje tri vrste kardinaliteta veza izmeu entiteta: jedan prema jedan
(engl. one-to-one), jedan prema vie (engl. one-to-many) i vie prema vie (engl. many-to-
many).
Notacija pomou koje se predstavlja kardinalitet i obaveznost veza, prikazana je na slici 3.2.
Smatramo da je notacija gavranova kanda predstavljena u poglavlju 1 najizraenija i najlake
se moe objasniti klijentima. Razumije se, postoje i druge tehnike, pa treba koristiti onu koju
smatramo najpogodnijom za upotrebu.
52
Veze se predstavljaju pomou linija koje povezuju pravougaonike
Entitet jedan Entitet dva
Entiteti se prikazuju kao pravougaonici
Jedna vertikalna crtica predstavlja jedan:
Gavranova kanda predstavlja vie:
Krui predstavlja neobavezno:

(itati kao nula ili)
Simboli se mogu kombinovati. Ovaj simbol

znai nula, jedan ili vie:
Slika 3.2. Pomou ove notacije predstavljaemo obaveznost i kardinalitet
3.2. Modelovanje relacija
Poto utvrdimo da postoji odreena veza izmeu entiteta, moramo je modelovati tako to
emo atribute iz jedne relacije (primarna relacija, engl. primary relation) kopirati u drugu relaciju
(spoljna relacija, engl. foreign relation). Kao to je prikazano na slici 3.3.
Slika 3.3. Veza izmeu relacija modeluje se tako to se atributi iz primarne relacije (Porudbine)
kopiraju u spoljnu relaciju (StavkePorudbine)
53
Izbor primarne i spoljne relacije nije potpuno slobodan. Osnovni kriterijum je kardinalitet
veze, a u rijetkim situacijama kada postoje izvjesne sumnje, treba razmotriti i semantiku modela
podataka. Na primjer, ako su date dvije relacije izmeu kojih postoji veza tipa jedan prema
vie, relacija na strani jedan uvijek je primarna relacija, dok je relacija na strani vie uvijek
spoljna relacija. Drugim rijeima, kandidat za klju iz relacije na strani jedan dodaje se (kao
spoljni klju) relaciji na strani vie.
Ne moemo kopirati bilo koje atribute iz primarne relacije u spoljnu, ve moramo izabrati
one koji na jedinstven nain identifikuju primarni entitet. Drugim rijeima, atribute koji ine
primarni klju primarne relacije treba da dodamo spoljnoj relaciji. Sasvim oekivano, tako
duplirani atributi postaju spoljni kljuevi u spoljnim relacijama. U primjeru prikazanom na slici
3.3, BrojPorudbine kandidat za klju relacije Porudbine kopiran je u relaciju
StavkePorudbine. Porudbine je primarna relacija, a StavkePorudbine je spoljna relacija.
Treba imati u vidu injenicu da par kandidat za klju/spoljni klju koji modeluje vezu, ne
mora obavezno da bude primarni klju primarne tabele; u tu svrhu posluie svaki njen kandidat
za klju. Treba upotrebiti kandidat za klju koji je najloginiji u semantikom pogledu.
Ponekad e biti potrebo da modelujemo ne samo injenicu da postoji veza, ve i odreena

svojstva te veze na primjer, koliko dugo postoji ili datum njenog poetka. U tom sluaju
korisno je napraviti apstraktnu relaciju koja predstavlja vezu. Relacija RadnoMjesto, prikazana
na slici 3.4, primjer je takve relacije veze.
Slika 3.4. Apstraktne relacije mogu da modeluju svojstva veze
Poto zasebne relacije koje predstavljaju veze izmeu drugih relacija donekle komplikuju
model podataka, mogli bismo da doemo u iskuenje da atribute veze prosto kopiramo u jednu
od postojeih relacija. To rjeenje ne mora obavezno da bude loe, ali ako imamo mnogo
atributa, ili mnogo relacija sa atributima, moe postati nezgrapno. Vanije je to da odvojen
entitet veza omoguava da pratimo istoriju veze. Na primjer, model prikazan na slici 3.4,
54
omoguava da pratimo istoriju promjena radnog mjesta odreene osobe, to ne bi bilo mogue
kada bi RadnoMjesto bilo atribut relacije Zaposleni.
Apstraktni entiteti veze takoe su korisni kada treba da pratimo vrste promjena veze tokom
vremena. Na primjer, na slici 3.5. prikazan je dijagram promjena stanja koji opisuje mogue
legalne promjene branog stanja odreene osobe.
Slika 3.5. Dijagrami promjena stanja prikatuju dozvoljene promjene stanja entiteta; u ovom
primjeru to je brano stanje osobe
Dijagrami promjena stanja lako se prate. Svaka vertikalna linija predstavlja vaee stanje, a
horizontalna linija predstavlja promjenu iz jednog stanja u drugo. Na primjer, osoba moe
prelaziti iz stanja oenjen/udata u razveden(a) i obratno, ali nikad iz razveden(a) u
neoenjen/neudata.
Razumije se, ako u modelu treba pratiti samo tekue brano stanje osobe, nema potrebe da
uvodimo entitet apstraktne veze koji bi obezbjeivao da se prihvataju samo dozvoljene promjene
stanja. Ukoliko je potrebno da znamo da su se Luka i Jovana vjenali 1980. godine i razveli
1995. godine, a zatim se Jovana ponovo udala 2001. godine i postala udovica 2006. godine, onda
nam treba entitet apstraktne veze kako bismo mogli da evidentiramo sve te promjene.
3.3. Veze tipa jedan prema jedan
Moda najjednostavnija vrsta veze izmeu entiteta jeste veza jedan prema jedan. Ako je
tano da se svaki primjerak entiteta X moe povezati uvijek samo s jednim primjerkom entiteta
55
Y, tip te veze je jedan prema jedan. Veina veza tipa je (jeste) bie jedan prema jedan, ali
osim tog izuzetka na tu vrstu veza nailaziemo prilino rijetko u svim kategorijama problema.
Potrebno je voditi rauna o sljedeem: kada izmeu dva entiteta uspostavljamo vezu tipa
jedan prema jedan, moramo biti sigurni da ta veza uvijek vai, ili da nam stare vrijednosti nee
biti bitne ako veza prestane da vai. Recimo da modelujemo kancelarijski prostor za izdavanje u
nekoj zgradi. Ako pretpostavimo da svaku kancelariju zauzima po jedna osoba, izmeu relacija
Kancelarija i Zaposleni postoji veza tipa jedan prema jedan, kao to je prikazano na slici 3.6.
Meutim, veza izmeu odreenog zaposlenog i odreene kancelarije vai samo izvjesno
vrijeme. Dogaa se da se zaposleni premjetaju iz jedne kancelarije u drugu. (Moe se
promijeniti i raspored kancelarija u zgradi, ali to je drugaiji problem.) Ako upotrebimo vezu
tipa jedan prema jedan kao na slici 3.6, imaemo jednostavan i jasan model zgrade, ali neemo
moi da znamo istoriju rasporeda zaposlenih po kancelarijama.
Slika 3.6. Izmeu relacija Kancelarija i Zaposleni postoji veza tipa jedna prema jedan
Moda nam to nee biti ni vano.Ako pravimo sistem za dostavljanje prispjele pote, bitno je
da znamo gdje treba danas da dostavimo pisma za Marka Markovia, a ne gdje bismo morali da
mu ih dostavimo prije tri mjeseca. Meutim, ako pravimo sistem namjenjen vlasniku zgrade, ti
istorijski podaci ne smiju da se gube jer se od sistema moe zahtijevati, na primjer, podatak o
tome koliko su se esto mijenjali zakupci odreenih dijelova zgrade.
Iako su veze tipa jedna prema jedan rijetke u stvarnom ivotu, to su veoma uobiajene
apstraktne konstrukcije, koje su izuzetno korisne. Najee se upotrebljavaju u sljedee dvije
situacije: kada elimo (ili moramo) da smanjimo broj atributa relacije, ili kada modelujemo
potklase odreenog entiteta.
Ako koristimo mainu baze podataka Jet, ogranieni smo na najvie 255 polja po fizikoj
tabeli, odnosno 1024 polja, ukoliko koristimo SQL Server. Veoma su rijetki modeli podataka,
iako ih ima u domenu medicine i nauke, koji premauju ta ogranienja. U takvim sluajevima,
56
moemo samo da napravimo novu relaciju s proizvoljnim podskupom atributa i da uspostavimo

vezu tipa jedan prema jedan sa izvornom, vodeom relacijom.
Ketegorija problema koja nas esto naizgled primorava da premaimo fizika ogranienja
veliine tabela, jesu ispiti i upitnici. Ako ispit moe imati proizvoljan broj pitanja, moemo doi
u iskuenje da odgovore pojedinaca modelujemo kao na slici 3.7.
Ispit
PK Ime studenta
Datum ispita
Odgovor 1
Odgovor 2
...
Odgovor N
Slika 3.7. Iako se ponekad pomou ovakve strukture modeluju ispiti i upitnici, to nije dobro
rjeenje
Navedena struktura se lako realizuje, naroito ako e se baza podataka koristiti iskljuivo za
taj ispit. Meutim, to nije najbolje rjeenje i nee biti upotrebljivo za drugi ispit s razliitim
brojem pitanja. Poto atributi odgovora ine grupu koja se ponavlja, relacija nije u prvoj
normalnoj formi. Bolji model prikazan je na slici 3.8.
Ispiti Odgovori na ispitima
PK ifra ispita PK Ime studenta
Ime studenta ifra ispita

Datum ispita Broj pitanja
Odgovor
Slika 3.8. Mada se tee realizuje, ova struktura je bolja za modelovanje ispita i upitnika
3.3.1. Izrada potklasa entiteta
Upotreba veza tipa jedan prema jedanzanimljivija je za izradu potklasa, to je koncept

pozajmljen iz objektno orijentisanog programiranja. Da bismo shvatili prednosti upotrebe
potklase entiteta, prvo emo razmotriti uobiajenije rjeenje. U primjeru kao na slici 3.9, svaki
artikal (relacija Artikli) pripada odreenoj kategoriji (relacija Kategorije).
57
Kategorije Artikli
PK ifra kategorije PK ifra artikla
Naziv artikla
Naziv kategorije ifra dobavljaca
Opis kategorije ifra kategorije
Slika kategorije Kolicina po jedinici
...
Slika 3.9. Svaki artikal iz tabele Artikli spada u jednu od kategorija iz tabele Kategorije
Relacija Kategorije omoguava da se u izvjetajima artikli grupiu po kategorijama, to moe

biti dovoljno za na prostor problema. Meutim, takva struktura omoguava da dati artikal
obraujemo samo kao artikal, a ne kao pripadnika odreene kategorije. Sve atribute koje
definiemo za jedan artikal imae svi artikli, bez obzira na kategoriju kojoj pripadaju. Ne moe
se rei da to rjeenje dobro pokriva cijeli prostor problema jer artikli u kategoriji Pia po samoj
svojoj prirodi imaju atribute koji se razlikuju od atributa iz kategorije Slatkii.
Moda moemo pokuati da modelujemo artikle u bazi podataka kako je prikazano na slici
3.10. Taj model omoguava da evidentiramo sve podatke specifine za svaku kategoriju artikala
jer svaka relacija moe imati razliite atribute. Problem sa ovom strukturom jeste to to je teko
obraivati odreeni artikal kao opti pojam artikal.
Slika 3.10. Ovaj model omoguava da svaka kategorija artikla ima svoje, specifine atribute
58
Zamislimo, na primjer, kako bi izgledao postupak provjere da li je korisnik unio ispravnu

ifru artikla: Ako ifra postoji u relaciji x, ili u relaciji y, ili u .... To je loe koliko i upit s
grupama koje se ponavljaju. Osim toga, moe se desiti da u ovakvoj strukturi imamo probleme i
sa integritetom podataka ako imamo atribute koji su upotrebljivi samo za odreenu kategoriju
artikala (na primjer, KoliinaPoJedinici moe postojati u kategoriji Pia, ali ne i u kategoriji
Mlijeni proizvodi) i ta kategorija se promijeni. ta emo onda uraditi? Izbrisati stare podatke? A
ta ako je izmjena bila nenamjerna i korisnik vrati prvobitno stanje?
Uvoenje potklasa entiteta Artikli omoguava da dobijemo najbolje iz oba svijeta. Moemo
evidentirati podatke specifine za odreene kategorije artikala i istovremeno zadrati mogunosti
da artikle obraujemo kao artikle kada nam to zatreba, pri emu moemo odloiti brisanje
podataka koji nam ne trebaju do trenutka kada zaista postanu suvini. Slika 3.11. prikazuje
model u kome se koriste potklase entiteta.
Porudbine
Porudbine
Detalji
Artikli
Mlijeni Plodovi
Pia Zaini Slatkii
proizvodi mora
Pekarski Parad i Sueni

proizvodi i mesni voni
itarice proizvodi proizvodi
Slika 3.11. Ovaj model koristi potklase da bi obezbjedio mogunosti modela sa slika 3.9. i 3.10.
Vano je istai sljedee: mada je upotreba potklasa elegantno rjeenje za izvjesne kategorije
problema modelovanja podataka, praktino realizovanje moe biti prilian posao. Primjera radi,
u izvjetaj koji prikazuje podatke o artiklima morali bismo da ugradimo uslovnu logiku da bismo
59
prikazivali samo polja koja postoje u tekuoj potklasi. To nipoto nije neizvodljiv zadatak, ali
moramo ga uzeti u obzir. U veini sluajeva, ne preporuuje se da se model podataka uprosti
kako bismo programerima olakali posao. Meutim, svakako nije opravdano da uvoenjem
potklasa poveavamo sloenost modela ako nam samo treba mogunost da grupiemo ili
kategorizujemo entitete pri izradi izvjetaja; u tom sluaju, struktura prikazana na slici 3.9.
savreno je prikladana i znatno blia zdravoj pameti.
Utvrivanje koja je relacija primarna a koja spoljna u vezi tipa jedan prema jedan, moe
ponekad biti zapetljano. Kao i uvijek, svoju odluku moramo zasnivati na semantici modela
podataka. Ako smo izabrali ovu strukturu da bismo pravili potklase odreenog entiteta, generiki
entitet postaje primarna relacija, a svaka potklasa postaje spoljna relacija. (U ovakvim
situacijama, spoljni klju koji potklase preuzimaju esto je kandidat za klju u potklasama.
Rijetko postoji razlog da potklase imaju vlastite identifikatore.)
Ako vezu tipa jedan prema jedan koristimo da bismo zaobili ogranienje maksimalnog
broja polja, ili ako izmeu entiteta u prostoru problema zaista postoji prirodna veza tipa jedan
prema jedan, izbor e biti donekle proizvoljan. Primarnu relaciju treba da odredimo na osnovu
svog poznavanja prostora problema.
U takvoj situaciji, jedan od elemenata koji mogu biti od pomoi jeste obaveznost veze. Ako
je samo jedna strana veze neobavezna (a dosad nikad nisma vidio model u kome su obe strane
tipa jedan prema jedan bile neobavezne), relacija na neobaveznoj strani je spoljna relacija.
Drugim rijeima, ako je jedan entitet slab, a drugi jak, jaki entitet je primarna relacija a slabi
entitet je spoljna relacija.
3.4. Veze tipa jedan prema vie
Najuobiajenija vrsta veza izmeu entiteta jeste veza jedan prema vie, u kojoj je jedan
primjerak jednog entiteta povezan s nula, jednim ili vie primjeraka drugog entiteta. Rezultat
veine tehnika normalizovanja opisanih u prethodnom poglavlju jesu relacije izmeu kojih
postoje veze tipa jedan prema vie.
S vezama tipa jedan prema vie ima malo problema nakon uspostavljanja. Meutim, vano
je da paljivo razmotrimo obaveznost svake strane veze. Uvrijeeno je miljenje da samo strana
60
vie u vezi moe biti neobavezna, ali to nije uvijek tako. Pogledajmo, na primjer, vezu
prikazanu na slici 3.12.
Slika 3.12. Ova veza je neobavezna u oba smjera
Veza izmeu Klijenta i TrgovakogPutnika neobavezna je u oba smjera. Obinim jezikom

reeno, to bi znailo da TrgovakiPutnik moe imati nula ili vie klijenata. Klijent s kojim
posluje TrgovakiPutnik, ako mu je dodijeljen, mora postojati u relaciji TrgovakiPutnik.
Odreivanje obaveznosti na strani jedan veze jedan prema vie ima vane posljedice i po
fiziku realizaciju i po upotrebljivost sistema. Ta pitanja detaljno e se razmotriti kasnije, ali
zasada je potrebno zapamtiti samo to da relaciona teorija ne zahtijeva da strana jedan u vezi
jedan prema vie bude obavezna.
Odreivanje primarne i spoljne relacije u vezi jedan prema vie vrlo je jednostavno. Entitet
na strani jedan u vezi jedan prema vie uvijek je primarna relacija; njen kandidat za klju
kopira se u relaciju na strani vie, koja postaje spoljna relacija. Kandidat za klju primarne
relacije esto je dio kandidata za klju relacije na strani vie, ali sam za sebe ne moe nikad da
jednoznano identifikuje torke spoljne relacije, ve se mora kombinovati s jednim ili vie drugih
atributa da bi se sainio kandidat za klju.
3.5. Veze tipa vie prema vie
U stvarnom svijetu postoji mnogo primjera veza tipa vie prema vie. Jedan student slua
vie predmeta; svaki predmet slua vie studenata. Kupci kupuju u vie prodavnica; jedna
prodavnica ima vie kupaca. Meutim, veze tipa vie prema vie ne mogu se neposredno
predstaviti u relacionoj bazi podataka. Umjesto toga, one se modeluju pomou dopunske (vezne)
relacije koja je u vezi jedan prema vie sa svakim od uesnika izvorne veze, kao na slici 3.13.
Takva dopunska relacija obino se zove spojna tabela (engl. junction table) ak i kad se radi na
nivou modela podataka, gdje naravno, govorimo o relacijama a ne o tabelama.
61
Slika 3.13. Veze tipa vie prema vie prepravljaju se pomou dopunske tabele nazvane spojna
tabela
Budui da se veza vie prema vie modeluje kao dvije veze jedan prema vie,
odreivanje primarne i spoljne relacije je vrlo jednostavno. Kao to smo vidjeli, relacija na strani
jedan u vezi jedan prema vie uvijek je primarna. To znai da svi prvobitni entiteti postaju
primarne relacije, a spojna tabela postaje spoljna relacija, koja preuzima kandidate za kljueve
iz relacija sa obe svoje strane.
Spojne tabele se najee sastoje samo od kandidata za kljueve iz oba uesnika prvobitne
veze, ali su one zapravo samo specijalan sluaj apstraktnih entiteta koje smo razmatrali u
prethodnom dijelu ovog poglavlja. Kao takve, one mogu da sadre sve dodatne atribute koje
smatramo neophodnim. Na primjer, spojna tabela koja rjeava problem veze vie prema vie
izmeu relacija Predmeti i Studenti, moe da sadri atribut Semestar u kojem je student bio
upisan na odreeni predmet. (Atribut Semestar moe da uestvuje u u vezi jedan prema vie sa
entitetom Semestar. ema moe biti onoliko jednostavna ili sloena koliko to potrebe
zahtijevaju.)
3.6. Unarne veze
Sve veze izmeu entiteta koje smo do sada razmatrali bile su binarne veze, tj. imale su po
dva uesnika. Unarne veze imaju samo jednog uesnika realcija je povezana sama sa sobom.
Klasian primjer unarne veze je odnos izmeu entiteta Zaposleni i Nadreeni. Za svakog
zaposlenog koji je nekome Nadreeni,u veini sluajeva, postoji drugi Zaposleni koji je njemu
Nadreeni.
62
Unarne veze mogu imati proizvoljan kardinalitet. Unarne veze tipa jedan prema vie
omoguavaju realizovanje hijararhija, kao to je organizaciona hijerarhija izraena vezom
izmeu entiteta Zaposleni i Nadreeni. Unarne veze tipa vie prema vie, slino svojim
binarnim parnjacima, moraju se modelovati pomou spojne tabele. Unarne veze mogu biti i
neobavezne na jednoj strani, kao to je prikazano na slici 3.14. Generalni direktor u veini
organizacija nema nadreenog. (Vlasnici akcija preduzea se ne raunaju, osim ako su nezavisni
dio modela podataka.)
Unarne veze modeluju se na isti nain kao binarne veze kandidat za klju iz primarne
relacije dodaje se spoljnoj relaciji. Jedina razlika je to to su primarna i spoljna relacija zapravo
ista relacija. Prema tome, ako je atribut ifraZaposlenog kandidat za klju u relaciji Zaposleni, a
deklarisan je u domenu ifreZaposlenih, toj relaciji bismo dodali atribut ije bi ime moglo da
bude ifraNadereenog i koji bi takoe bio deklarisan u domenu ifreZaposlenih, kao to je
prikazano na slici 3.14.
Tako se javlja zanimljiv problem: iz razloga koji su vjerovatno oigledni, dva polja u tabeli
ne mogu imati isto ime. (U relaciji ne moemo ni imati dva atributa sa istim imenom, ali je
ime pomalo neodreen koncept na apstraktnom nivou.) To znai da moramo preimenovati
primarni ili spoljni klju u unarnoj vezi. Najee emo preimenovati spoljni klju. U naem
primjeru, spoljni klju bismo vjerovatno preimenovali u ifraNadreenog.
Slika 3.14. Unarna veza postoji kada je relacija povezana sama sa sobom
U stvari, atribut koji je spoljni klju moemo preimenovati u svakoj relaciji, to je esto i
opravdano u semantikom pogledu. Na primjer, atribut ifraZaposlenog u relaciji Zaposleni,
postao bi ifraTrgovakogPutnika u relaciji Kupac. injenica da razvojno okruenje moe da
63
automatski kombinuje tabele na osnovu istoimenih polja, ne treba da bude preporuka da bez
razmiljanja kopiramo imena atributa iz jedne relacije u drugu.
3.7. Ternarne veze
Ternarne veze obino su oblika entitet X ini Y entitetu Z, i slino vezama tipa vie prema
vie ne mogu se neposredno modelovati u relacionoj bazi podataka. Za razliku od veza vie
prema vie, ne postoji samo jedan nain da ih modelujemo.
Na slici 3.15, vidi se da je artikal Sir livanjski prodat kupcu Trade-M, a dobavljaju ga firme
Pavlovi mljekarstvo i Velprom. Meutim, nema naina da se utvrdi koja je od te dvije firme
dobavila konkretan sir koji je isporuen kupcu Trade-M. Ternarna veza se izgubila iz tog modela
podataka. Vie dobavljaa moe dobaviti isti artikal, ali je ponekad potrebno pratiti koji je
dobavlja isporuio konkretan artikal koji je prodat odreenom kupcu.
Slika 3.15. Ove relacije ne pokazuju ko je dobavlja sira isporuenog kupcu Trade-M
Da bismo razumjeli problem, korisno je da vezu prvo ispitamo u tipinijem prostoru

problema, kao to je prikazano na slici 3.16.
64
Dobavljai
Artikli
StavkePorudbine
Porudbine
Kupci
Slika 3.16. Ovo je tipian lanac veza izmeu entiteta koji uestvuju u jednoj porudbini
U modelu na slici 3.16, svaki artikal dobavlja samo jedan dobavlja i ternarna veza je
ouvana ako znamo da je artikal u pitanju, znamo i ko ga dobavlja. Meutim, u modelu na slici
3.17, jedan artikal moe dobavljati vie dobavljaa i ternarna veza je izgubljena.
Dobavljai
DobavljaArtikal
StavkePorudbine
Porudbine
Kupci
Slika 3.17. Ternarna veza je u ovom modelu izgubljena
Za rjeavanje ovog problema kljuno je da ispitamo smjerove u vezama jedan prema vie.
Za svaki entitet na strani vie, moemo odrediti njemu odgovarajui entitet na strani jedan.
65
Prema tome, za svaki primjerak entiteta StavkePorudbine na slici 3.16, moemo odrediti
primjerak entiteta Porudbine kome pripada, a na osnovu poznatog primjerka entiteta
Porudbine, moemo odrediti i odgovarajui primjerak entiteta Kupci. Postupak se moe
primjeniti i u suprotnom smjeru, naravno: za poznatu stavku iz entiteta StavkePorudbine,
moemo odrediti artikal, a zatim pronai njegovog dobavljaa.
Meutim, suprotan postupak se ne moe primjeniti. Poto identifikujemo odreeni primjerak

entiteta na strani jedan veze, ne moemo pronai jamo jedan njemu odgovarajui entitet na
strani vie. To je problem sa slikom 3.17. Za dati primjerak entiteta StavkePorudbine,
moemo odrediti odgovarajui artikal, ali poznajui artikal ne moemo odrediti s kojim
primjerkom entitata DobavljaArtikal je povezan.
Ovo se lake moe shvatiti na sljedei nain: ne moemo promjeniti smjer od jedan prema
vie u vie prema vie vie od jedanput u lancu veza izmeu entiteta. U lancu prikazanom na
slici 3.16, smjer se mijenja samo jedanput, kod entiteta StavkePorudbine. U lancu prikazanom
na slici 3.17, smjer se mijenja dvaput kod entiteta StavkePorudbine, a zatim jo jednom kod
entiteta DobavljaArtikal.
Rjeenje je da entitet Artikli izbacimo iz lanca, kao na slici 3.18.
Slika 3.18. Ovaj model odrava ternarne veze
66
Unutar lanca veza sad se smjer mijenja samo jedanput, kod entiteta StavkePorudbine, a veza
je odrana. Meutim, obratite panju na to da entitet Artikli zapravo nije izbaen. Poto je
vjerovatnije da e kupci naruivati artikle, bez obzira na to ko ih dobavlja, zadravanje entiteta
Artikli omoguava da se tome prilagodi korisniki interfejs.
Razumije se, u prostoru problema koji rjeavamo moda nam nee biti vane ternarne veze,
ili e moda postojati neki drugi nain da predstavimo postojee veze kad nam to zatreba, na
primjer, pomou oznake lota ili are na pakovanju. U ovom primjeru, potpuno je nepotrebno da
i to ukljuimo u model. Vano je razumjeti da model prikazan na slici 3.18 nije sam po sebi ni
bolji, ni ispravniji od onog na slici 3.17. Moramo odabrati model koji najbolje odraava
semantiku naeg prostora problema.
3.8. Veze s poznatim kardinalitetom
Ponekad e nam minimalni, apsolutni ili maksimalni broj torki na strani vie veze tipa
jedan prema vie biti unaprijed poznat. Radna nedjelja ima pet dana, skelet odrasle osobe
sastoji se od 200 kostiju, a na turniru golfa svaki igra moe da nosi samo 14 tapova.
U ovakvim situacijama uvijek izgleda pravo rjeenje da se kandidat za klju iz svake torke
doda kao atribut u relaciji na strani jedan, kao na slici 3.19, ali je to rjeenje uzrok dva ozbiljna
problema. Prvo, tako se dobije grupa koja se ponavlja, i drugo, to je nepouzdano rjeenje.
injenica da se atributi ponavljaju skrivena je na slici 3.19 razliitim imenima atributa, ali su
oni u stvari svi definisani u istom domenu, Semestar. Kad god imamo vie atributa definisanih u
istom domenu, velika je vjerovatnoa da zapravo imamo kategorije ili vrste vrijednosti
preruene u imena atributa.
Slika 3.19. Iako izgleda primamljivo, nije mudro modelovati poznati kardinalitet na ovaj nain
67
Osim navedenog teorijskog problema, jo jedan problem je to to strukture sline navedenoj

nisu pouzdane. Na primjer, pravilo firme moe biti da svaki rukovodilac ima najvie pet
podreenih koji mu direktno podnose izvjetaje, ali pravilo se ne sprovodi uvijek. Kada takvo
pravilo ugradimo u model podataka, realizujemo ga u obliku sistemskog ogranienja koje se ne
moe zaobii. Vrlo je vjerovatno da emo ve pri unoenju prvih podataka otkriti da postoji
barem jedan rukovodilac koji dobija est direktnih izvjetaja. ta e se u tom sluaju dogoditi?
Da li e neko naprasno dobiti novog efa? Da li e taj rukovodilac biti unijet (i moda plaen)
dvaput? Ili e moda programer koji je realizovao na projekat doi u sukob s nama?
Ogranienja kardinaliteta poput navedenih, moraju se realizovati u obliku sistemskih

ogranienja; nije preporuljivo da ih ugraujemo u same stukture relacija. Osim toga, kao to
emo vidjeti u poglavlju o odravanju integriteta baze podataka, trebalo bi dobro razmisliti o
njihovom uticaju na upotrebljivost sistemaprije nego to ugradimo u sistem bilo kakvo
ogranienje kardinaliteta.
3.9. Saetak
U ovom poglavlju detaljno smo razmotrili veze izmeu entiteta. Bavili smo se svim vrstama
binarnih veza: jedan prema jedan, jedan prema vie i vie prema vie. Vidjeli smo kako se
one predstavljaju u modelu podataka odreivanjem primarne relacije i dodavanjem njenog
kandidata za klju drugom uesniku veze, spoljnoj relaciji. Osim toga, razmotrili smo specijalne
sluajeve unarnih i ternanrih veza i vidjeli kako se one predstavljaju u modelu podataka.
Ovim smo savladali osnovne komponente modela podatak: entitete, njihove atribute i veze
izmeu njih. U narednom poglavlju prei emo na integritet podataka i mehanizme koje moemo
upotrebiti da bismo odrali konzistentnost baze podataka.
68
4. Integritet podataka
Izrada modela entiteta iz prostora problema i veza izmeu njih, samo je dio postupka
modelovanja podataka. Moramo obuhvatiti i pravila koja e sistem to radi s naom bazom
podataka primjenjivati da bi fiziki podaci koje skladiti u bazu podataka bili, ako ne potpuno
ispravni, barem prihvatljivi. Drugim rijeima, u model moramo ukljuiti integritet podataka
(engl. date integrity).Vano je shvatiti kako su prilino male anse da emo moi da garantujemo
bukvalnu tanost podataka. Uzmimo na primjer zapis o porudbini koji pokazuje da je Markovi
Milan kupio 12. juna 2004. godine 15 ubodnih pila. Sistem koji se oslanja na bazu podataka
moe da potvrdi da je Markovi Milan kupac poznat u sistemu, da preduzee zaista prodaje
ubodne pile i da je 12. juna 2004. godine primila porudbinu od kupca. Moe ak i da provjeri da
li Markovi Milan ima dovoljno novca na svojoj kreditnoj kartici da bi platio 15 ubodnih pila.
Ono to sistem ne moe da provjeri jeste da li je Markovi Milan zaista naruio 15 ubodnih pila,
a ne sedam ili jednu, ili je to zapravo bilo 15 odvijaa. Najbolje to bi sistem mogao da uradi
jeste da uoi da je 17 prevelik broj ubodnih pila koji bi samo jedna osoba kupila i da o tome
odavijesti operatera koji unosi porudbinu. Ali realizovanje sistema koji bi to radio bilo bi
vjerovatno preskupo, moda ak skuplje od koristi koju bi donio.
Ovim primjerom elimo pokazati kako sistem ne moe da provjerava da li je Markovi Milan
zaista poslao porudbinu koja je u potpunosti jednaka porudbini evidentiranoj u sistemu; moe
samo da provjeri da li je on to mogao da uini. Razumije se, to je sve to moe da uini i svaki
drugi sistem koji omoguava evidentiranje podataka, a dobro projektovan sistem koji radi s
bazom podataka svakako moe da obavi bolji posao od prosjenog runog sistema, makar samo
zato to dosljedno primjenjuje zadata pravila. Meutim, nijedan sistem koji se naslanja na bazu
podataka i nijedan projektant sistema ne moe da garantuje da su evidentirani podaci tani, ve
samo to da mogu biti tani. Sistem to radi tako to se stara da podaci budu usklaeni sa uslovima
integriteta (engl. integrity constraints) koji su definisani u sistemu.
4.1. Uslovi integriteta
Uslove integriteta neki autori jo zovu i poslovna pravila. Meutim, koncept poslovnog
pravila znatno je iri i obuhvata sva ogranienja i uslove definisane u sistemu, a ne samo uslove
koji odreuju integritet podataka. Na primjer, zatita sistema definicija ta koji korisnici smiju
da rade i u kojim okolnostima tie se administriranja sistema a ne integriteta podataka. Zatita
69
sistema svakako je jedan od sistemskih zahtjeva i sastojae se od jednog ili od vie poslovnih
pravila, ali e to pitanje biti posebno obraeno.
Integritet podataka realizuje se na vie nivoa detalja (engl. level of granularity). Uslovi koji
vae za domen, promjenu stanja i entitete definiu pravila za odravanje integriteta pojedinanih
relacija. Uslovi za referencijalni integritet obezbjeuju odravanje veza izmeu entiteta. Uslovi
za integritet baze podataka upravljaju bazom podataka kao cjelinom, dok uslovi za integritet
transakcija odreuju nain na koji se radi s podacima unutar jedne baze ili ak vie baza.
Kao to smo ve spomenuli, domen je skup svih moguih vrijednosti datog atributa. Uslov
za integritet domena koji se obino zove uslov za domen (engl. domain constraint) jeste
pravilo koje definie te prihvatljive vrijednosti. Moe biti potrebno da se definie vie od jednog
uslova za odreeni domen da bi bio potpuno opisan.
Domen nije isto to i tip podataka, a definisanje domena pomou tipova podataka izgleda
kao primamljivo rjeenje (koje se esto koristi), ali moe imati loe posljedice. Postoji opasnost
da time bez potrebe previe proirimo skup prihvatljivih vrijednosti na primjer, tako to
izaberemo tip podataka Integer jer smatramo da e za praktinu upotrebu biti dovoljno veliki, a
ne zato to je 255 najvea dozvoljena vrijednost u domenu.
Poto tip podataka moe biti zgodna preica u modelu podataka, biranje logikog tipa
podataka je prvi korak u odreivanju uslova za domen unutar sistema. Pod logikim tipom
podataka podrazumijeva se samo neto poput datum, tekst ili slika nita specifinije od
toga. Datumi su moda najbolji primjer prednosti takvog pristupa. Nije preporuljivo da domen
atributa DatumTransakcije definiemo kao DateTime, to je fiziki oblik. Ali ako ga
definiemo kao datum, to nam omoguava da ga posmatramo kao datum u opsegu od poetka
rada preduzea do tekueg datuma ukljuujui i njega i da zanemarimo sva ona prilino
zapetljana pravila o prestupnim godinama.
Poto izaberemo logiki tip podataka, moe biti korisno da suzimo definiciju domena, na
primjer, tako to emo zadati razmjeru i preciznosz podataka numerikog tipa ili maksimalnu
duinu znakovnih vrijednosti. To je vrlo blizu zadavanju fizikog tipa podataka, ali treba da
ostanemo na logikom nivou. Razumije se, to ne znai da ne moemo umjesto za znakovnu
70
vrijednost ne duu od 30 znakova koristiti skraen nain posanja char[30]. Ipak, to je opis
modela podataka apstraktniji, vie emo kasnije imati prostora za izmjene i manja e biti
vjerovatnoa da emo u sistem uvesti neeljena ogranienja.
Sljedei aspekt integriteta domena koji treba razmotriti jeste: da li je domenu dozvoljeno da
sadri nepoznate i nepostojee vrijednosti. Obrada tih vrijednosti nije uvijek jednostavna, a na
njih emo se vratiti kada budemo razmatrali pojedine aspekte projektovanja baze podataka.
Zasad treba shvatiti samo da postoji razlika izmeu nepoznete i nepostojee vrijednosti i da je
esto (iako ne uvijek) mogue zadati da li su prihvatljive u domenu, bilo jedna ili obe.
Prva ideja, tj. da nepoznata nije isto to i nepostojea, ne predstavlja vei problem na
logikom nivou. (Morammo uvijek imati na umu da je model podataka logika konstrukcija.)
Moj otac nema brata; ja ne poznajem susjedovog brata. To su dva razliita znaenja. Postoje
problemi njihovog praktinog realizovanja, kojima se jo neemo baviti, ali je logika razlika
sasvim razumljiva.
Druga ideja je sljedea: poto odluimo da li emo dozvoliti da domen obuhvata i nepoznete
ili nepostojee vrijednosti, moramo donijeti odluku o tome da li e ih sistem prihvatati. Ako se
vratimo na primjer DatumaTransakcije, svakako je mogue da datum transakcije bude nepoznat,
ali ako je transakcija obavljena, to se moralo dogoditi odreenog datuma, pa prema tome taj
datum ne moe da bude nepostojei. Drugim rijeima, mora postojati datum transakcije; jedini je
problem to to ga ne znamo.
Razumije se, moda nita ne znamo pa svaka vrijednost moe biti nepoznata. To nije korisna
razlika u pojmovima. Ovdje nam nije osnovni cilj da definiemo moe li vrijednost biti
nepoznata, ve da li bi entitet s nepoznatom vrijednou tog atributa trebalo prihvatiti u sistemu..
Moda je sistem takav da nema svrhe unositi podatak ako njegova vrijednost nije poznata ili se
odreeni entitet ne moe identifikovati ako je vrijednost nepoznata. U oba sluaja sprijeili
bismo da zapis koji sadri nepoznatu vrijednost u datom polju bude unijet u bazu podataka.
Ta odluka se ne moe uvijek donijeti na nivou domena, ali je uvijek korisno da je

razmotrimo jer time moemo sebi kasnije olakati rad. Naa odluka e u odreenoj mjeri zavisiti
od toga koliko su nai domeni opti. Pretpostavimo da smo definisali domen Ime i u njemu
deklarisali atribute Ime, Prezime, Nadimak i NazivFirme. Te atribute mogli smo definisati i u
odvojenim domenima, ali uoptenija definicija domena prua izvjesne prednosti jer tako
71
moemo da na jednom mjestu obezbjedimo potovanje vie pravila koja se djelimino poklapaju
(u ovom sluaju, vjerovatno ak i prilian broj njih). Meutim, u ovom sluaju neemo moi da
na nivou domena odredimo da li e prazne ili nepoznate vrijednosti biti prihvatljive; ta svojstva
moraemo da definiemo na nivu entiteta.
Posljednji aspekt integriteta domena jeste da skup vrijednosti koje domen predstavlja
moramo definisati to moemo preciznije. Na primjer, na domen DatumTransakcije nije samo
skup svih moguih datuma; to je skup datuma od dana kada je preduzee poelo da radi do
tekueg datuma. Taj domen se moe dalje suziti uklanjanjem nedjelja, dravnih praznika i drugih
dana u kojima preduzee ne radi, mada bi tu treba biti oprezan. Nije neuobiajeno da neki od
zaposlenih budu na poslu iako je preduzee zvanino zatvoreno i nema apsolutno nikakvog
razloga da im bude zabranjeno da se tada javljaju na telefon i primaju porudbine.
Ponekad se domen lake opisuje ako prosto nabrojimo sve vrijednosti u njemu. Domen
Vikendi je potpuno opisan skupom {Subota, Nedjelja}. U drugim sluajevima moe biti
jednostavnije navesti jedno ili vie pravila koja odreuju pripadnost domenu, kao to smo uradili
za domen DatumTransakcije. Oba oblika potpuno su prihvatljiva, iako se moe dogoditi da
metodologija projektovanja odreuje nain dokumentovanja pravila i ogranienja. Najvanije od
svega je da sva pravila i ogranienja budu to paljivije i to potpunije evidentirana i ugraena u
model.
4.1.2. Integritet promjena stanja
Uslovi integriteta promjena stanja (engl. transition integrity constraints) definiu

dozvoljena stanja kroz koja torka moe da proe. Recimo, dijagram promjena stanja na slici 4.1.
prikazuje stanja kroz koja moe da proe jedna porudbina.
72
Slika 4.1. Ovaj dijagram prikazuje stanja kroz koja moe da proe porudbina
Uslove integriteta promjena stanja zadali bismo, na primjer, da bismo obezbjedili da status
odreene porudbine ne pree iz Primljena u Zavrena ako prethodno nije prola kroz barem
jedno meustanje ili da bismo sprijeili svaku promjenu statusa ponitene porudbine.
Status entiteta obino je odreen samo jednim atributom. U tom sluaju integritet promjena
stanja moe se posmatrati kao poseban sluaj integriteta domena. Meutim, ponekad se
dozvoljenim promjenama stanja upravlja pomou vie atributa ili ak vie relacija. Budui da se
uslovi za prihvatljive promjene stanja mogu definisati na svakom nivou detalja, korisno je da ih
tokom pripreme modela podataka posmatramo kao razliite vrste ogranienja.
Na primjer, moe biti dozvoljeno da se status kupca promjeni iz Obian u Dobar samo
ako mu je odobren kredit preko odreene vrijednosti i ako je poslovao s preduzeem barem
godinu dana. Maksimalnu vrijednost kredita vjerovatno bi odreivao jedan od atributa relacije
Kupci, ali vrijeme tokom kojeg je kupac poslovao s preduzeem vjerovatno se nee nigdje
izriito unositi. Moda e biti potrebno da se ta vrijednost izraunava na osnovu najstarijeg
zapisa o datom kupcu u relaciji Porudbine.
73
Uslovi za integritet entiteta (engl. entity constraints) obezbjeuju integritet entiteta koje
modeluje sistem. Na najjednostavnijem nivou, postojanje primarnog kljua je uslov za integritet
entitata koji obezbjeuje potovanje pravila svaki entitet mora da se identifikuje jednoznano.
U izvjesnom smislu, to je jedini uslov za integritet samog entiteta; svi ostali su u tehnikom
pogledu samo uslovi definisani na nivou entiteta. Uslovi definisani na nivou entiteta mogu da
vae za odreeni njegov atribut, vie atributa ili za relaciju kao cjelinu.
Integritet pojedinanog atributa modeluje se prvenstveno definisanjem domena za taj atribut.

Svaki atribut unutar relacije nasljeuje uslove integriteta definisane za njegov domen. Na nivou
entiteta, nasljeeni uslovi mogu postati stroi, ali nikako blai. Drugi nain da se isto to izrazi
jeste da uslov na nivou entiteta moe da se sastoji od podskupa uslova za domene pojedinih
atributa, ali ne od nadskupa tih uslova. Na primjer, atribut DatumPorudbine definisan u domenu
DatumTransakcije moe da ograniava datum na tekuu godinu, dok domen DatumTransakcije
dozvoljava svaki datum izmeu datuma poetka rada preduzea i tekueg datuma. Meutim,
uslov definisan za cijeli entitet ne moe da dozvoli da atribut DatumPorudbine sadri neki
datum iz budunosti jer to zabranjuje domen tog atributa.
Slino tome, atribut NazivPreduzea definisan u domenu Ime moe da zabranjuje prazna
imena, iako ih domen Ime dozoljava. U ovom primjeru takoe imamo uu definiciju dozvoljenih
vrijednosti od one koja vai za domem.
(Napomena: Projektanti esto zadaju prihvatljivost praznih i nepoznatih vrijednosti na

nivou entiteta umjesto na nivou domena. Neki projektanti smatraju da ti uslovi vae samo na
nivou entiteta. Taj stav je donekle opravdan, ali preporuujemo da definicije domena obuhvataju
to vie detalja. Razumije se, razmatranje praznih i nepoznatih vrijednosti na nivou domena ne
moe da kodi, a moe da pojednostavi postupak zadavanja (i realizovanja).)
Osim suavanja opsega prihvatljivih vrijednosti za dati atribut, uslovi integriteta definisani
na nivou entiteta mogu da utiu i na vie atributa. Obaveza da DatumDostave bude jednak
DatumuPorudbine ili noviji od njega, primjer je takvog ogranienja. Meutim, uslovi integriteta
entiteta ne mogu da referenciraju druge relacije. Na primjer, ne bi bilo ispravno da za entitet
definiemo uslov integriteta koji podeava ProcenatPopusta kupcu (to je atribut relacije Kupci)
74
u zavisnosti od ukupne vrijednosti porudbina datog kupca (koja se izraunava na osnovu zapisa
u relaciji StavkePorudbine). Uslovi koji zavise od vie relacija mogu da se definiu samo na
nivou baze podataka, to emo razmotriti kasnije u okviru ovog poglavlja.
Treba biti oprezan kada imamo uslove koji obuhvataju vie atributa; to je esto znak sa na
model podataka nije potpuno normalizovan. Ako vrijednost jednog atributa uslovljavamo ili
izraunavamo u zavisnosti od drugog atributa, vjerovatno je sve u redu. Uslov za entitet koji
odreuje da se Status kupca ne moe promijeniti u Dobra kupac ukoliko zapis o kupcu nije
star barem godinu dana, potpuno je prihvatljiv. Meutim, ako vrijednost jednog atributa
odreuje vrijednost drugog na primjer, Ako je zapis o kupcu stariji od jedne godina, onda
Status = Dobar kupac onda imamo funkcionalnu zavisnost i krimo treu normalnu formu.
U prethodnom poglavlju razmotrili smo razbijanje relacija radi minimizovanja

redundantnosti i upotrebu spoljnih kljueva za povezivanje relacija. Ako se te veze prekinu,
sistem e u najboljem sluaju postati nepouzdan, a u najgorem neupotrebljiv. Uslovi za
ouvanje referencijalnog integriteta (engl. referential integrity constraints) odravaju i tite te
veze.
Postoji samo jedan uslov za ouvanje referencijalnog integriteta: spoljni kljuevi ne smiju da
postanu siroii. Drugim rijeima, nijedan zapis u spoljnoj tabeli ne smije da sadri spoljni
klju za koji ne postoji odgovarajui zapis u primarnoj tabeli. Torke koje sadre spoljen kljueve
bez odgovarajuih kandidata za klju u primarnoj relaciji zovu se entiteti siroii (engl.
orphaned entities). Entiteti siroii mogu da se pojave zbog jednog od sljedeih razloga:
1. Spoljnoj tabeli dodata je torka iji klju nema odgovarajueg parnjaka u kandidatu za
klju u primarnoj tabeli.
2. Spoljnom kljuu dodijeljena je vrijednost koja ne postoji u primarnoj tabeli.
3. Izmjenjena je vrijednost kandidata za klju u primarnoj tabeli.
4. Izbrisan je referencirani zapis iz primarne tabele.
Ako je potrebno da se integritet veze odri moramo obraditi sva etiri navedena sluaja. Prvi
sluaj, dodavanje spoljnog kljua bez parnjaka, najee se prosto zabranjuje. Treba imati u vidu
da se pri tome nepoznate i nepostojee vrijednosti ne uzimaju u obzir za njih vai drugo
75
pravilo. Ako je veza deklarisana kao neobavezna, moemo uzeti proizvoljan broj nepoznatih i
nepostojeih vrijednosti bez naruavanja referencijalnog integriteta.
Drugi i trei uzrok entiteta siroia mijenjanje kandidata za klju u referenciranoj tabeli
ne bi trebalo da se dogaa esto. Preporuka je da, gdje god je to mogue, izmjene kandidata za
klju i spoljnog kljua budu zabranjene. (Uzgred, to bi bio uslov za integritet entiteta: Nije
dozvoljena izmjena vrijednosti kandidata za kljueve.)
Ako na model dozvoljava mijenjanje kandidata za kljueve, moramo obezbjediti da se te

izmjene primjene i na spoljne kljueve. To je poznato kao lanano auriranje (engl. cascading
update). I Jet i SQL Server imaju mehanizam koji na jednostavan nain omoguava lanano
auriranje.
Ukoliko na model dozvoljava mijenjanje spoljnih kljueva, ime se entitet povezuje s

drugim primarnim entitetom, moramo obezbjediti da nova vrijednost bude ispravna. Taj uslov se
takoe i u Jetu i u SQL Serveru lako moe ispuniti, iako nema posebno ime.
Posljednji uzrok pojave spoljnih kljueva siroia jeste brisanje zapisa u kome se nalazi
primarni entitet. Na primjer, ako neko izbrie zapis o odreenom kupcu, ta e biti s njegovim
porudbinama? Slino izmjenama kandidata za kljueve, moemo zabraniti brisanje torki iz
primarne relacije ako se one referenciraju u nekoj spoljnoj relaciji. To je svakako najistije
rjeenje aki je to prihvatljivo ogranienje u naem sistemu. Ako nije, i u Jetu i u SQL Serveru
postoji nain povezivanja operacije brisanja zapisa iz obe tabele, to je poznato kao lanano
brisanje (engl. cascading delete).
U tom sluaju, imamo i treu mogunost koju je malo tee iskoristiti jer se ne moe obaviti
automatski. Moe nam zatrebati da zapise zavisne od jednog primarnog entiteta poveemo s
drugim. To esto nije preporuljivo, ali je ponekad neophodno. Recimo da je na kupac, Firma
A, kupila Firmu B, takoe naeg kupca. Moe biti korisno da izbriemo Firmu B i da sve njene
porudbine dodijelimo Firmi A.
Specijalna vrsta uslova za ouvanje referencijalnog integriteta jeste pitanje maksimalnog

kardinaliteta spomenuto u prethodnom poglavlju. U modelu podataka, pravila kao to je
Rukovodilac moe imati najvie petoro podreenih koji mu podnose izvjetaje, definiu se kao
uslovi za referencijalni integritet.
76
4.1.5. Integritet baze podataka
Najiri oblik za ouvanje integriteta jesu uslovi integriteta baze podataka (engl. database
integrity constraints). Uslovi integriteta baze podataka referenciraju vie od jedne relacije: Svi
Artikli prodati Kupcima koji imaju status Dravne ustanove moraju imati vie od jednog
Dobavljaa. Veina uslova integriteta baza podataka imaju takav oblik i slino navedenom,
mogu zahtijevati proraune koji obuhvataju vie relacija.
Treba voditi rauna o tome da se ne pobrka uslov integriteta baze podataka sa

specifikacijom operacije. Radni proces (engl. work process) obavlja se u bazi podataka, kao to
je unoenje porudbine, dok je uslov pravilo koje se odnosi na sadraj baze podataka. Pravila
koja definiu poslove koji se obavljaju pomou baze podataka dio su radnog procesa, a ne uslovi
integriteta baze podataka. Radni procesi mogu umnogome uticati na model podataka, ali ne bi
trebalo da budu sastavni dio modela.
Nije uvijek jasno da li je odreeno poslovno pravilo uslov integriteta ili radni proces (ili
neto tree). Razlika moda nee ni biti posebno vana. Ako to nita ne mijenja u preostalom
dijelu modela, pravilo se ugrauje tamo gdje smatramo najprikladnijim. Kada se odreeno
pravilo moe izraziti kao uslov u bazi podataka, uinimo tako. Ukoliko to postane zapetljano
(kao to se esto dogaa, ak i kad je sasvim jasno da je pravilo zapravo uslov integriteta),
premjestimo pravilo u srednji sloj ili u eonu komponentu, gdje se moe realizovati u
proceduralnom obliku.
4.1.6. Integritet transakcija
Posljednji oblik integriteta baze podataka jeste integritet transakcija (engl. transaction
integrity). Uslovi integriteta transakcija upravljaju nainom na koji se radi s podacima u bazi.
Za razliku od ostalih uslova integriteta, uslovi integriteta transakcija su proceduralni pa zato nisu
dio samog modela podataka.
Transakcije su tijesno povezane s radnim procesima. Ta dva koncepta su ortogonalna, jer se

jedan radni proces moe sastojati od vie transakcija i obrnuto. Mada nije sasvim ispravno,
korisno je da radni proces zamislimo kao apstraktnu konstrukciju (unoenje nove porudbine)
a transakciju kao fiziku konstrukciju (auriranje tabele StavkePorudbine).
77
Transakcija se obino definie kao logika jedinica posla, to je prilino neodreeno. U

sutini, transakcijaje grupa akcija, koje se moraju izvriti ili sve, ili nijedna. Transakcija mora da
ispunjava sve definisane uslove integriteta prije poetka transakcije i nakon njenog zavretka, ali
privremeno moe da prekri jedan ili vie tih uslova tokom transakcije.
Klasian primjer transakcije je prebacivanje novca s jednog bankovnog rauna na drugi. Ako
se novac skine s Rauna A a sistem ne uspije da za isti iznos povea stanje na Raunu B, ta svota
e biti izgubljena. Jasno je da se prva komanda mora ponititi ako se druga komanda zavri
neuspjehom. U argonu baza podataka, to se zove rolbek. Transakcije mogu da obuhvate vie
zapisa, vie relacija, pa ak i vie baza podataka.
Precizno govorei, sve su operacije u bazi podataka transakcije. ak i auriranje samo jednog
postojeeg zapisa predstavlja transakciju. Sreom, te transakcije najnieg nivoa obavlja u
pozadini maina baze podataka i taj nivo detalja obino se moe zanemariti.
Obe maine baze podataka, Jet i SQL Server, omoguavaju odravanje integriteta transakcija
pomou iskaza BEGIN TRANSACTION, COMMIT TRANSACTION i ROLLBACK
TRANSACTION. SQL Serverov mehanizam je robusniji i bolji kad treba oporaviti bazu
podataka od hardverskog kvara ili nekih softverskih problema. Ali to su pitanja praktine
realizacije koja su izvan opsega ovog materijala. Gledano iz ugla projekatnta, vano je da
uoimo i odredimo od ega treba da se sastoje transakcije, te zloglasne logike jedinice posla.
78
4.2. Realizovanje integriteta podataka
Dosad smo se bavili preslikavanjem prostora problema na apstraktnom nivou u konceptualni

model podataka. U ovom dijelu, razmotriemo neka pitanja izrade fizikog modela prostora
problema: baviemo se emom baze podataka. Kada prelazimo s jednog nivoa na drugi, najvie
se mijenja terminologija relacije postaju tabele, a atributi postaju polja izuzetak su pitanja
integriteta podataka. Ona se nikad ne preslikavaju u fiziki model onoliko neposredno koliko
bismo eljeli.
4.2.1. Nepoznate i nepostojee vrijednosti
Ve smo u ovom poglavlju govorili o nepoznatim i nepostojeim vrijednostima. Spomenuli

smo tada, pomalo bez pokria, kako bi trebalo ispitati domene i atribute da bismo utvrdili je li
potrebno dozvoliti prazne ili nepoznate vrijednosti atributa. Pri tome nismo naveli kako bismo
praktino obezbjedili ispunjavanje tih uslova. Problem praktine realizacije ne moemo vie
zanemariti kad preemo na emu baze podataka.
Takozvani problem nedostajuih podataka poznat je jo od poetka uvoenja relacionog

modela. Kako se moe izraziti da odreeni podatak nedostaje (kupac ima telefonski broj, ali mi
ga ne znamo) ili ne postoji (kupac uopte nema telefonski broj)? U veini relacionih baza
podataka, meu kojima su i Jetove i SQL Serverove baze podataka, postoji specijalna vrijednost
Null koja omoguava obradu nedostajuih i nepostojeih vrijednosti.
Nazvati upotrebu Null vrijednosti rjeenjem ovog problema vjerovatno je pretjerano jer je i
to uzrok brojnih problema. Neki strunjaci za baze podataka u potpunosti odbacuju Null
vrijednost. C. J. Date smatra da one obogaljuju model4, a kod vie autora moemo nai tvrdnju
da su Null vrijednosti veliko zlo. Na svaku napomenu o sloenosti njihove upotrebe ili bolna
priznanja o problemima koje su uzrokovale, dobija se odgovor u stilu: Odlino. Nije ni trebalo da
ih koristite. I ba je dobro ro su te namuile.
Kao alternativu, kola Null je zlo prepuruuje upotrebu posebnih vrijednosti iz

odgovarajueg domena koji upuuju na to da je u pitanju nepoznata ili nepostojea vrijednost, ili
i jedna i druga. To moemo nazvati rjeenjem s konvencionalnim vrijednostima. Rjeenje s
koncencionalnim vrijednostima uvodi vie problema. Prvo, u mnogim sluajevima izabrana
4
Date, C.J. An Introduction to Database Systems, 6. Edition, Addison-Wesley, 1995, pp 129.
79
vrijednost jeste samo konvencionalna. Datum 9/9/1900 ne znai zaista da je taj datum nepoznat,
ve samo to da smo se opredijelili da emo ga tako tumaiti. To je jedna od onih situacija tipa
znae samo ako ti neko kae, koje nepravedno optereuju i sistem i njegove korisnike.
Nejasno je zbog ega je to rjeenje bolje od upotrebe Null vrijednosti. Null je takoe
konvencionalna vrijednost, razumije se, ali ne moe se pobrkati ni s im drugim, a njena
prednost je to je podrava relacioni model i veina relacionih maina baza podataka.
Drugi problem, zbog koga treba odbaciti rjeenje s konvencionalnim vrijednostima, jeste
uticaj na referencijalni integritet. Primjera radi, pogledajmo neobaveznu vezu Kupca i
ReferentaZaKontakt, koja odreuje da ime tog referenta, ako je dodijeljen kupcu, mora postojati
u tabeli osoba zaduenih za komunikaciju s kupcima. Rjeenje s konvencionalnom vrijednou
zahtijeva da se u tabelu Referent doda zapis s nekom izabranom konvencionalnom vrijednou
koja pokazuje da kupcu nije dodijeljen nijedan referent (slika 4.2.).
Slika 4.2. Rjeenje s nekonvencionalnim vrijednostima zahtijeva dodavanje lanog zapisa da bi

se ouvao referencijalni integritet.
80
Koliko referenata radi u preduzeu? Jedan manje od ukupnog broja referenata upisanih u
tabelu Referent, jer jedan od njih zapravo je lanjak. Koji je prosjean broj kupaca po
referentu? Ukupan broj zapisa u tabeli Kupac minus broj zapisa u kojima je referent
Nedodijeljen, podijeljeno sa ukupnim brojem zapida u tabeli Referent manje jedan.
Konvencionalne veze jesu korisne pri izradi izvjetaja. Na primjer, vrijednost Null moemo
zamijeniti s Nepoznato, a prazne vrijednosti s Neprimjenjivo. Ali ovaj prijedlog je sasvim
drugaiji od unoenja konvencionalnih vrijednosti u bazu podataka, gdje, kao to smo vidjeli,
ometaju rad s podacima.
Null moda jeste zlo ruan svakako jeste ali to je najbolje rjeenje koje imamo za
predstavljanje nepoznatih i nepostojeih vrijednosti. O ovom problemu potrebno je razmiljati,
pronai alternative gdje god je to mogue, i prihvatiti probleme zbog upotrebe Null vrijednosti
gdje alternativa nema.
Jedan od problema pri upotrebi Null vrijednosti jeste to to, uz izuzetak domena s
vrijednostima znakovnog tipa, one mogu biti prisiljene na dvostruku namjenu. Polje
deklarisano kao polje tipa DateTime moe da prihvati samo datume ili vrijednost Null. Ako je
odgovarajui atribut definisan tako da prihvata i nepoznate i nepostojee vrijednosti, a obe
predstavljamo kao Null, nema naina da utvrdimo da li Null u odreenom zapisu predstavlja
nepoznato ili ne postoji. Ovaj problem se ne postavlja za znakovne tipove podataka jer za
prazne vrijednosti moemo upotrebljavati znakovni niz duine nula, a pomou Null vrijednosti
moemo predstavljati nepoznate vrijednosti.
U praksi se ovaj problem ne pojavljuje tako esto kao to bi se oekivalo. Budui da malo
domena koji nisu tekstualnog tipa prihvata nepostojee vrijednosti, u tim domenima se Null
uvijek moe tumaiti kao nepoznato. U domenima u kojima se prihvata nepostojea vrijednost,
esto se moe nai razumna alternativa za predstavljanje takve vrijednosti. Ovdje treba imati u
vidu da preporuujemo stvarne vrijednosti a ne konvnecionalne. Na primjer, relacija Artikal ima
atribut Teina, a za reklamaciju, koja oigledno ne moe imati teinu,moe se upotrebiti
vrijednost nula. (Nula je dobar izbor da se predstavi nita u mnogim, ali ne u svim, poljima
numerikog tipa.)
81
Drugi i znatno ozbiljniji problem pri upotrebi Null vrijednosti jeste to to komplikuju rad s
podacima. Logika poreenja postaju sloenija, a formulisanje nekih vrsta upita moe postati
malo zapetljano. To emo razmotriti posebno.
Ne podcjenjujemo problem Null vrijednosti, pa gdje god za nju postoji razumna ajternativa
treba je izabrati. Ali nemojmo naruavati model podataka samo zato da bismo programerima
olakali ivot. Treba dobro razmisliti, ali ako sistem zahtijeva upotrebu Null vrijednosti, treba ih
koristiti.
4.2.2. Neispunjavanje uslova integriteta
Kada definiemo emu baze podataka, moramo odrediti dvije stvari: kako emo
najefikasnije realizovati dati uslov integriteta i akciju koju e maina baze podataka izvriti ako
taj uslov ne bude ispunjen. U veini sluajeva, razumije se, baza podataka e samo odbaciti
neprihvatljivu komandu i vratiti odreeni kod greke na odgovarajui nain. Meutim, ponekad
baza podataka moe da preduzme odreenu akciju koja zahtjevanu izmjenu ini prihvatljivom.
Kao primjer takve akcije moemo navesti umetanje podrazumijevanih vrijednosti za atribute koji
ne prihvataju prazne vrijednosti, ili lanano auriranje ili lanano brisanje radi ouvanja
referncijalnog integriteta. Reagovanje na neispunjavanje uslova integriteta bie posebno
razmotreno.
4.2.3. Deklarativni i proceduralni integritet
Relacione maine baza podataka pruaju podrku za ouvanje integritata na dva naina:
deklarativni i proceduralni. Podrka za deklarativni integritet izriito je definisana
(deklarisana) kao sastavni dio eme baze podataka. I maine Jet i SQL Server pruaju
odreenu podrku za deklaratini integritet. Deklarativni integritet je preporuljiv nain
organizovanja integriteta podataka. Treba ga koristiti gdje god je to mogue.
SQL Server prua podrku za proceduralni integritet u obliku okidakih (engl. trigger)
procedura koje se izvravaju (okidaju) kada se u bazu podataka unese novi zapis, ili aurira ili
izbrie postojei zapis. Maina baze podataka Jet ne podrava proceduralni integritet. Kada se
odreeni uslov integriteta ne moe realizovati u obliku deklarativnog integriteta, a u sistemu se
koristi maina Jet, taj uslov se mora realizovati pomou koda u eonoj komponenti aplikacije.
82
SQL Server prua ogranienu podrku za domene u obliku tipova podataka koje definie
korisnik (engl. user-defined data types, UDDT). Polja definisana kao UDDT tip nasljeuju od
njega deklaraciju tipa podataka i uslove koji vae u domenu tog UDDT-a.
Podjednako vano je to da SQL Server zabranjuje poreenje polja deklarisanih s razliitim

UDDT tipovima, ak i kad se ti UDDT tipovi zasnivaju na istom sistemskom tipu podataka. Na
primjer, iako su oba domena atributa ImeMjesta i ImePreduzea, definisana kao char(39), SQL
Server e odbiti da usporedi ImeMjesta i ImePreduzea. To se moe izriito zaobiu pomou
funkcije za konverziju tipova podataka ImeMjesta = CONVERT(char(30), ImePreduzea), ali
moramo imati u vidu taj uslov prije nego to usporedimo polja deklarisana u razliitim
domenima. To je dobro, budui da takva poreenja logiki esto nemaju smisla.
UDDT tipovi podataka mogu se praviti pomou SQL Serverove alatke Enterprise Manager
ili pomou uskladitene procedure sp_addtype. U oba sluaja, UDDT tipovi deklariu se sa
imenom ili tipom podataka i zadaje se da li prihvata Null. Poto definiemo UDDT, moemo mu
zadati za njega podrazumijevanu vrijednost i pravila ispravnosti podataka. SQL Serverovo
pravilo (engl. rule) logiki je izraz koji definie prihvatljive vrijednosti za UDDT (ili u polju, ako
je pravilo pridrueno polju tabele umjesto UDDT-u). Podrazumijevana vrijednost je upravo to
podrazumijevana vrijednost koju sistem sam umee u polje koje bi bez toga bilo Null zato to
korisnik nije zadao nikakvu vrijednost.
Pridruivanje pravila ili podrazumijevane vrijednosti UDDT-u odvija se u dva koraka. Prvo
moramo definisati pravilo ili podrazumijevanu vrijednost, a zatim ga pridruiti UDDT-u (ili
polju tabele). Opravdanje za ovakav nije greka, nego tako treba postupak u dva koraka jeste
sljedei: poto ga definiemo, pravilo ili podrazumijevana vrijednost moe se upotrebiti i na vie
drugih mjesta. Smatramo da je postupak nezgrapan jer je iskustvo pokazalo da se ti objekti
rijetko koriste vie puta. Kada definiemo tabelu, SQL Server omoguava da direktno
deklariemo podrazumijevane vrijednosti za polja i zadajemo ogranienja tipa CHECK, kao
sastavne dijelove tabele. (Ogranienja tipa CHECK slina su pravilima, ali su znatno monija.)
Naalost, deklarisanje u jednom koraku nije mogue kada deklariemo UDDT tipove, za ta se
mora koristiti starija napravi-pa-pridrui metodologija. Bilo bi veoma poeljno da u jednoj od
buduih verzija SQL Servera, Microsoft i u UDDT tipove ugradi podrku za deklarisanje
podrazumijevanih vrijednosti i ogranienja tipa CHECK.
83
Drugi nain da realizujemo neku vrstu odloenog integriteta domena jeste upotreba
referentnih tabela (engl. lookup tables). Ta tehnika se moe koristiti i u Jetu i u SQL Serveru.
Primjera radi, uzmimo domen Optine. Teorijski gledano, moe se definisati pravilo po kome bi
se nabrajale sve postojee optine. U stvarnosti to bi bio muan postupak, naroito ako koristimo
Jet, gdje bismo morali da ponovo piemo pravilo za svako polje deklarisano u tom domenu.
Neuporedivo je lake napraviti referentnu tabelu Optine i primjenom referencijalnog integriteta
obezbjediti da vrijednosti u poljima tabela budu ograniene na one iz referentne tabele.
U emi baze podataka, uslovi integriteta mogu da vae za pojedinana polja, za vie polja
istovremeno ili za tabelu kao cjelinu. I Jet i SQL Server sadre mehanizme za odravanje
integriteta na nivou entiteta. SQL Server prua neto iru lepezu mogunosti.
Na nivou pojedinanih polja, tip podataka je najvaniji uslov integriteta. I Jet i SQL Server
nude bogat skup tipova podataka, kao to je prikazano u tabeli 4.1.
Kao to je ve reeno, SQL Server omoguava da polja deklariemo kao UDDT tipove.
UDDT polje nasljeuje pravila za Null i podrazumijevane vrijednosti, kao i pravila definisana za
tip podataka, ali se u definiciji polja moe zadati drugaije. Logiki gledano, trebalo bi da
definicija polja samo jo vie suzi ogranienja definisana za UDDT, ali SQL Server u stvari
samo zamjenjuje definiciju UDDT-a u opisu polja. To znai da je mogue dozvoliti da polje
prihvata Null vrijednosti iako UDDT s kojim je polje deklarisano to ne dozvoljava.
I SQL Server i Jet omoguavaju da zadamo hoe li polje prihvatiti Null vrijednosti. Kada u
SQL Serveru definiemo kolonu, treba samo da zadamo opciju NULL ili NOT NULL, ili da
potvrdimo odgovarajue polje u Enterprise Manageru.
Jetov ekvivalent indikatora za Null vrijednost jeste svojstvo Required. Osim toga, u Jetu
postoji indikator AllowZeroLenght, kojim se zadaje da li su u poljima tipa Text i Memo
dozvoljeni prazni znakovni nizovi (). To ogranienje se u SQL Serveru moe realizovati
pomou ogranienja tipa CHECK.
84
U maini baze podataka Jet, kada definiemo polje tabele, zadavanjem vrijednosti
odgovarajueg svojstva zadajemo istovremeno i podrazumjevanu vrijednost u polju. U SQL
Serveru, moemo zadati vrijednost svojstva Default kada definiemo polje, ili moemo s njim
povezati odgovarajuu sistemsku podrazumjevanu vrijednost, na isti nain kao za polja tipa
UDDT. Deklarisanje podrazumjevane vrijednosti kao sastavni dio definicije tabele, svakako je
istije rjeenje i opcija koju preporuujemo ako ne elimo (ili ne moemo) da definiemo
podrazumjevanu vrijednost na nivou domena polja.
I najzad, i Jet i SQL Server omoguavaju da zadamo posebne uslove integriteta. U Jetu
postoje dva svojsta polja: ValidationRule (pravilo ispravnosti) i ValidationText (tekst poruke
kada je prekreno pravilo ispravnosti). U SQL Serveru moemo deklarisati ogranienja tipa
CHECK unutar definicije polja ili s poljem moemo naknadno povezati postojea sistemska
pravila. Preporuljiva metoda je upotreba ogranienja tipa CHECK.
Na prvi pogled, Jetova pravila ispravnosti podataka i SQL Serverova ogranienja tipa
CHECK djeluju identino, ali ipak postoji nekoliko vanih razlika. Oba elementa imaju oblik
logikih izraza i ni u jednom ne moemo referencirati druge tabele ili kolone. Meutim, Jetovo
pravilo ispravnosti podataka mora se svesti na True da bi vrijednost bila prihvaena u polju
tabele. SQL Serverovo ogranienje tipa CHECK ne smije se svesti na False. Razlika je delikatna:
ogranienje tipa CHECK prihvata i True i Null, dok Jetovo pravilo ispravnosti prihvata samo
True.
Osim toga, za jedno SQL Serverovo polje moemo definisati vie ogranienja tipa CHECK.
Jednom SQL Serverovom polju moemo pridruiti jedno pravilo i proizvoljan broj ogranienja
tipa CHECK, dok Jetovo polje moe imati samo jedno svojstvo ValidationRule. Uzgred, sadraj
Jetovog svojstva ValidationText prosljeuje se eonoj komponenti kao poruka o greci.
Microsoftov Access prikazuje taj tekst u prozoru za poruku, a na raspolaganju je i Visual Basicu
i drugim razvojnim okruenjima kao tekst u kolekciji objekata Errors.
Uslovi za integritet entiteta koji referenciraju vie polja, realizuju se u Jetu u obliku pravila
ispravnosti koja vae za cijelu tabelu, a u SQL Serveru to se radi pomou ogranienja tipa
CHECK zadatih za tabelu. Osim drugaijeg mjesta na kojem se deklariu, ti uslovi i ogranienja
koji treba da vae za cijelu tabelu djeluju na potpuno isti nain kao i njihovi parnjaci koje
definiemo za pojedinana polja.
85
Najvaniji uslov za ouvanje integriteta entiteta jeste obaveza da svaki primjerak odreenog
entiteta mora da se identifikuje jedinstveno. Treba imati u vidu da je to glavni uslov integriteta
entiteta; svi ostali se tanije mogu smatrati ogranienjima za ouvanje entiteta koja su definisana
na nivou entiteta. Jet i SQL Server podravaju uslov jedinstvenosti otprilike na isti nain, ali se
prilino razlikuje oblik podrke. U obe maine baze podataka, taj uslov se realizuje pomou
indeksa, ali SQL Server to sakriva od korisnika. Da li indeks treba eksplicitno napraviti (Jet) ili
deklarisati ogranienje odgovarajueg tipa (SQL Server), uglavnom je pitanje praktinih detalja.
86
Tabela 4.1. Fiziki tipovi podataka podrani u Jetu i SQL Serveru
Tip podataka
Opseg vrijednosti Veliina u bajtovima
Logiki SQL Server Jet
Int Long integer Cjelobrojne vrijednosti u opsegu od -2.147.483.648 do 2.147.483.648 4

Cjelobrojni Smallint Cjelobrojne vrijednosti u opsegu od -32768 do 32768 2
Tinyint Cjelobrojne vrijednosti u opsegu od 0 do 255 1
Pakovani decimalni Cjelobrojne ili decimalne vrijednosti u opsegu od - 1038 10^38-1 do
Decimal Number (razliiti tipovi) 2-17
(taan numeriki) 10^38-1
Pribline numerike vrijednosti u opsegu od -1,79E^308 do 1,79E^308

Float (15-cifarska
Double Pozitivni opseg: od 2,23E^-308 do 1,79E^308 8
preciznost)
Negativni opseg: od -2,23E^-308 do -1,79E^308
S pokretnim zarezom
(priblini numeriki)
Pribline numerike vrijednosti u opsegu od -3,40E^38 do 3,40E^38
Real Single Pozitivni opseg: od 1,18E^-38 do 3,40E^38 4
Negativni opseg: od -1,18E^-38 do -3,40E^38
Znakovni (fiksna
Char N/A Najvie 255 znakova u Jetu; 8000 znakova u SQL Serveru 1 po deklarisanom znaku
duina)
Znakovni promjenjiva
Varchr Text Najvie 255 znakova u Jetu; 8000 znakova u SQL Serveru 1 po deklarisanom znaku
duina)
Numerike vrijednosti tane do etvrte decimale, u opsegu od -
Money Currency 8
922.337.208.685.477,5808 do 922.337.208.685.477,5807
Novani
Numerike vrijednosti tane do etvrte decimale, u opsegu od -
Smallmoney N/A 4
214.748,3648 do 214.748,3647
Od 01.01.1753. godine do 31.12.9999. godine u SQL Serveru;

Datetime Date/Time 8
Datum/Vrijeme Od 01.01.100.godine do 31.12.9999. godine u Jetu
Smalldatatime N/A Od 01.01.1900. godine do 06.06.2079. godine 4
Binarni (fiksna
Binary N/A Najvie 8000 bajtova Broj deklarisanih bajtova plus 4 bajta
duina)
Binarni promjenjiva (Podrano samo u Ukupan broj stvarno uskljaditenih

Varbinary Najvie 8000 bajtova
duina) povezanim tabelama) bajtova plus 4 bajta
Dugaak tekst/Veliki Znakovni podaci do 2GB u SQL Serverovoj bazi podataka; do 1GB u Koliina uskladitenih podataka plus 16
Text Memo
binarni objekat Jetovoj bajtova
Koliina uskladitenih podataka plus 16
(BLOB) Image OLE Object Binarni podaci do 2GB u SQL Serverovoj bazi podataka, ili 1GB u Jetovoj
bajtova
1 bajt, ali se u SQL Serveru kombinuju

Logiki Bit Yes/No 0 ili 1 kolone bitova; zbog toga 8 ili manje
kolona zauzimaju ukupno 1 bajt
87
I Jet i SQL Server podravaju definisanje grupa polja kao jedinstvenih vrijednosti. Oba
podravaju i definisanje skupa od jednog ili vie polja kao primarnog kljua, to podrazumijeva
jedinstvenost sadraja kolone. Tabela moe imati samo jedan primarni klju, koji se moe
sastojati od vie polja. Jedna tabela moe imati proizvoljan broj ogranienja tipa Unique.
Druga vana razlika izmeu ogranienja (indeksa) tipa Unique (jedinstvena vrijednost) i
primarnih kljueva jeste to da indeksi definisani sa uslovom Unique mogu da sadre i Null
vrijednosti, koje nisu dozvoljene u primarnim kljuevima. Postoje izvjesne razlike u nainu na
koji te dvije maine tretiraju Null vrijednosti u indeksima definisanim kao Unique. U Jetu postoji
svojstvo IgnoreNulls, koje spreava dodavalje u indeks zapisa koji sadre Null vrijednosti u
indeksiranim kolonama. Ta mogunost ne postoji u SQL Serveru.
Osim toga, SQL Server prihvata u indeksu samo jedan zapis koji sadri NULL. To je logiki
pogreno jer se zapisi koji sadre NULL tretiraju kao da su jednaki. Jedna Null vrijednost nije
jednaka niemu drugom, ak ni drugoj Null vrijednosti.
Zanimljivo je to da ni u Jetu, ni u SQL Serveru nije obavezno da tabela ima primarni klju, a
ne mora biti ispunjem ak ni uslov jedinstvenosti. Drugim rjeima, mogue je praviti tabele koje
nisu relacije, budui da torke u relacijama moraju da se identifikuju na jedinstven nain, dok to
nije obavezno za zapise u tabelama.
U SQL Serveru postoji i proceduralni mehanizam za obezbjeivanje integriteta na nivou

entiteta koji ne postoji u maini baze podataka Jet. Okidai (engl. triggers) su krai brokovi koda
koji se automatski izvravaju kada se desi odreeni dogaaj. U staroj verziji SQL Servera, moe
se izvravati samo Transaction SQL kod. Nova verzija, Yukon, dozvoljava da okidai budu
napisani u bilo kom .NET jeziku. Za svaki dogaaj INSERT, UPDATE ili DELETE moemo
definisati vie okidaa, kao i za novi dogaaj INSTEAD OF, a isti okida moe se definisati i za
vie dogaaja.
Dok je podrka za integritet entiteta otprilike izjednaena, razlikuju se oblici u kojima

maine baze podataka Jet i SQL Server podravaju referencijalni integritet. SQL Server
omoguava definisanje ogranienja tipa Foreign Key (spoljni klju) kao sastavnog dijela
88
definicije tabele. Ogranienje tipa Foreign Key uspostavlja vezu sa kandidatom za klju u
drugoj, primarnoj tabeli. Poto uspostavimo vezu, SQL Server spreava nastajanje zapisa
siroia tako to ne prihvata umetanje zapisa za koje ne postoji odgovarajui zapis u primarnoj
tabeli. Null vrijednosti nisu zabranjene u kolonama deklarisanim kao spoljni kljuevi, iako se
one mogu zabraniti u kolonama koje uestvuju u primarnom kljuu tabele, to je obino sluaj.
SQL Server zabranjuje i brisanje zapisa iz primarne tabele ako za njih postoje odgovarajue
vrijednosti u spoljnim kljuevima drugih tabela.
Maina baze podataka Jet podrava referencijalni integritet preko objekta baze podataka
Relation. Microsoft je nesretno izabrao terminologiju u ovom sluaju Jetov objekat Relation je
fiziko predstavljanje veze izmeu dva entiteta. Ne treba brkati objekat Relation s logikim
relacijama definisanim u modelu podataka.
Objekat tipa Relation najjednostavnije emo napraviti u Accessovom korisnikom interfejsu

(pomou komande Relationship menija Tools), ali moemo ga napraviti i u programskom kodu.
Svojstva Table i ForeignTable DAO (Data Access Object) objekta Relation, definiu tabele koje
uestvuju u vezi, a kolekcija Fields definie povezana polja iz svake tabele.
Nain na koji e maina baze podataka Jet odravati referencijalni integritet veze, odreuje
se svojstvom Attributes veze, koa to je prikazano u tabeli 4.2.
Tabela 4.2. Konstante koj moemo zadati kada definiemo vezu u Jetovoj bazi podataka
Konstanta Attribute Opis
dbRelationUnique Veza tipa "jedan prema jedan"
Veza nije uspostavljena. (Referencijalni integritet se ne

dbRelationDontEnforce
odrava.)
Veza postoji u drugoj bazi podataka koja nije tekua i u

dbRelationInherited
kojoj se nalaze obe povezane tabele.
dbRelationUpdateCascade Auriranje se lanano prenosi.
dbRelationDeleteCascade Brisanje se lanano prenosi.
Potrebno je obratiti panju na indikatore (engl. attribute flags) dbRelationUpdateCascade i

dbRelationDeleteCascade. Ako je ukljuen indikator Update (auriranje) i izmjeni se vrijednost
referenciranog polja, Jet e automatski aurirati i odgovarajua polja u spoljnoj tabeli. Slino
89
tome, indikator Delete (brisanje) automatski e brisati odgovarajue zapise iz spoljne tabele.
SQL Server 2000 je uveo sline automatske indikatore, a sloenije lanane akcije mogu se lako
realizovati pomou okidaa.
4.2.7. Druge vrste integriteta
U modelu podataka definiemo tri dodatne vrste integriteta: baze podataka, promjena stanja i
transakcija. Neki uslovi za promjenu stanja dovoljno su jednostavni da se mogu realizovati u
obliku pravila ispravnosti podataka. Meutim, veina njih, ukljuujui i sve uslove integriteta
baze podataka i transakcija, moraju se realizovati u proceduralnom obliku. U SQL Serverovim
bazama podataka to podrazumijeva upotrebu okidaa. Budui da maina baze podataka Jet ne
podrava okidae, ispunjavanje tih uslova mora se obezbjediti u kodu enone komponente
aplikacije.
4.3. Saetak
U ovom poglavlju razmotrili smo modelovanje i realizovanje integriteta podataka. Tri vrste
uslova integriteta domena, promjena stanja i entiteta upravljaju pojedinanim relacijama, dok
uslovi referencijalnog integritata obezbjeuju odravanje veze izmeu entiteta. Uslovi integriteta
baze podataka i promjena stanja upravljaju bazom podataka kao cjelinom.
Integritet podataka ugraujemo u emu podataka u obliku kombinacije deklarativnog i

proceduralnog integriteta. Deklarativni integritet izriito deklariemo kao sastavni dio eme, to
je i preporuljiv nain. Meutim, ne mogu se svi uslovi zadati u deklarativnom obliku; tamo gdje
to nije mogue, mora se primjeniti proceduralni integritet.
90
5. Relaciona algebra
U prethodnim poglavljima nastojali smo da definiemo odreenu vrstu relacija, nazvanu

osnovna relacija (engl. base relation), iji bismo fiziki oblik smjestili u bazu podataka.
Relacioni model podrava i izradu vie vrsta izvedenih relacija. Izvedena relacija (engl. derived
relation) predstavlja relaciju definisanu upotrebom drugih relacija, a ne zadavanjem atributa
relacije. Relacije navedene u definiciji mogu biti osnovne relacije ili druge izvedene relacije, u
bilo kojoj kombinaciji.
U emi baze podataka, osnovna relacija predstavljena je tabelom. Izvedene relacije

predstavljene su prikazima (engl. viwes) u SQL Serveru, odnosno upitima (engl. queries) u
maini Jet. Radi jezike jednostavnosti, ubudue emo koristiti izraz prikaz, budui da je to
standardni relacioni izraz, a osim toga, tako emo izbjei brkanje sa izvravanjm upita (engl.
querying), to je dovoljno slian izraz da moe doi do zabune. Koristie se i izraz skup zapisa
(engl. recordset) kao opti izraz koji obuhvata i tabelu (osnovnu relaciju) i prikaz (izvedenu
relaciju).
Prikazi se definiu pomou relacionih operacija koje su tema ovog poglavlja. MS Access i
SQL Serverov Enterprise Manager imaju grafiki interfejs za definisanje prikaza, koji se
najee definiu pomou iskaza SELECT jezika SQL.
SQL je akronim od Structured Query Language (strukturirani jezik za upite). To je

standardizovan jezik kojim se izraavaju relacione operacije. I Jet i SQL Server podravaju
vlastite dijalekte SQL-a. Naravno, ne isti dijalekt to bi bilo previe jednostavno. Sreom,
razlike meu njima ne utiu na relacionu algebru kojom emo se baviti u ovom poglavlju. Tamo
gdje se sintakse razlikuju, naveemo primjere iz oba dijalekta.
SQL-ov iskaz SELECT veoma je moan i prilino sloen, a njegov detaljan opis izlazi izvan
okvira ovog materijala. Za nae potrebe ograniiemo se na osnovnu strukturu, koja ima sljedeu
sintaksu:
91
SELECT <listaPolja>
FROM <listaSkupovaZapisa>
<vrstaSpoja> JOIN <uslovSpoja>
WHERE <uslovZaIzbor>
GROUP BY <listaPoljaZaGrupisanje>
HAVING <usloviZaIzbor>
ORDER BY <lista PoljaZaSortiranje>
Parametar <listaPolja> u odredbi SELECT jeste lista od jednog ili vie polja to treba da
budu prikazana u skupu zapisa koji se formira kao rezultat iskaza. To mogu biti fizika polja
koja potiu iz skupova obuhvaenih iskazom, ili se mogu izraunati na osnovu drugih polja. Kao
to je za oekivati, parametar <listaSkupovaZapisa> u odredbi FROM jeste lista tabela ili
prikaza na koje se odnosi iskaz SELECT. Ovo su dvije jedine odredbe iskaza SELECT koje
moramo obavezno zadati; sve ostale su neobavezne.
Odredba JOIN definie veze izmeu skupova zapisa navedenih u <listiSkupovaZapisa>.

Povezivanje tabela detaljno emo razmotriti u nastavku ovog poglavlja. Odredba WHERE
definie logiki izraz, <usloviZaIzbor>; on ograniava podatke koje e initi rezultujui skup
zapisa. To emo takoe detaljno razmotriti u nastavku ovog poglavlja.
Odredba GROUP BY kombinuje zapise koji sadre jednake vrijednosti u poljima na zadatoj
listi da bi se dobio jedan rezultujui zapis. Odredba HAVING omoguava dalje ograniavanje
broja redova rezultata poslije njihovog kombinovanja odredbom GROUP BY. I najzad, odredba
ORDER BY omoguava sortiranje rezultata prema sadraju polja navedenih u
<listiPoljaZaSortiranje>.
5.1. Null vrijednosti i trovrijednosna logika
Veina operacija relacione algebre podrazumijeva upotrebu logikih operatora, iji je

rezultat najee logikog tipa tj. moe imati samo vrijednost True (tano, istinito) ili False
(netano, neistinito). Kaemo najee zbog toga jer, ako se relacionom modelu dodaju
vrijednosti Null, stvari postaju neto sloenije.
Null dodaje treu vrijednost skupu logikih vrijednosti uslijed ega moramo raditi sa True,
False i Null. Stoga ne iznenauje da su ti operatori postali poznati kao trovrijednosna logika
92
(engl. three-valued logic). Trovrijednosne tabele istinitosti za standardne logike operatore

prikazane su na slici 5.1.
AND TRUE FALSE NULL

TRUE TRUE FALSE NULL
FALSE FALSE FALSE NULL
Null NULL NULL NULL
OR TRUE FALSE NULL

TRUE TRUE TRUE NULL
FALSE TRUE FALSE NULL
Null NULL NULL NULL
XOR TRUE FALSE Null

TRUE FALSE TRUE NULL
Null NULL NULL NULL
Slika 5.1. Tabele istinitosti za trovrijednosne operatore And, Or i Xor
Kao to se vidi, rezultat operacije Null op bilo ta gdje je op logiki operator uvijek je
Null. To je uglavnom tano i za operatore logikog poreenja (slika 5.2).
Postoje dva izuzetka od navedenih pravila. Microsoftov Jet vraa True umjesto Null kao
rezultat operacije True Xor Null (to se jo moe i razumjeti), dok SQL Server, iz razloga koji
sigurno izgledaju opravdani njihovim projektantima, normalnim logikim operacijama dodaje
svoja proirenja. Ako je iskljuena opcija ANSI_NULLS, Null = Null daje rezultat True, a
Null = <neka vrijednost, gdje se <neka vrijednost> bilo ta osim Null (ukljuujui i logike
vrijednsti True i False), daje rezultat False. Iskreno reeno, ne uspijevamo da shvatimo zato bi
neko poelio da na ovakav nain kri pravila relacione algebre rad s Null vrijednostima
dovoljno je komplikovan i bez dodatne neodreenosti u ponaanju operatora.
93
= TRUE FALSE NULL

TRUE TRUE FALSE NULL
FALSE FALSE TRUE NULL
Null NULL NULL NULL
TRUE FALSE NULL
TRUE FALSE TRUE NULL
Null NULL NULL NULL
Slika 5.2. Trovrijednosne tabele istinitosti za operatore jednako i razliito.
U SQL-u postoje i dva unarna operatora IS NULL i IS NOT NULL koji su namjenjeni za
rad sa Null vrijednostima. Oni djeluju tano onako kako bismo i oekivali. Tabele istinitosti za
operatore IS NULL i IS NOT NULL prikazane su na slici 5.3. I u ovom sluaju <neka
vrijednost> moe biti bilo ta osim Null.
Is Null Is Not Null

<value> FALSE TRUE
TRUE FALSE TRUE
FALSE FALSE TRUE
NULL TRUE FALSE
Slika 5.3. Tabele istinitosti za operatore IS NULL i IS NOT NULL
94
5.2. Relacione operacije
Na poetku prouavanja relacione algebre prikazaemo original. Na slici 5.4. grafiki je

prikazano osam originalnih relacionih operacija koje je uveo Codd u svojim najranijim
radovima.
Restrikcija Projekcija Dekartov proizvod
a a x
x
b a y
y
c b x
b Y
c x
c y
Presjek Unija Razlika
(prirodni) spoj
a1 b1 b1 c1 a1 b1 c1 a x x
a2 b1 b2 c2 a2 b1 c1 a y z
a3 b2 b3 c3 a3 b2 c2 a z
b x
c y
dijeljenje
Slika 5.4. Originalna relaciona algebra
95
Samo prouavanje realcione algebre zapoeemo od etiri tipa relacionih operacija:

ograniavanje, projekcija, spajanje i dijeljenje. Prva dva djeluju na jedan skup zapisa, mada taj
skup zapisa moe biti i prikaz koji obuhvata proizvoljan broj drugih skupova zapisa. Operator
spajanja (engl. join) moda je najvaniji u relacionom modelu i definie nain na koji dva skupa
zapisa treba da se kombinuju. Posljednji operator, dijeljenje (engl. divide), rijetko se
upotrebljava, ali je povremeno zgodna metoda za odreivanje koji zapisi iz jednog skupa zapisa
imaju odgovarajue parnjake u drugom skupu zapisa.
Svi navedeni operatori realizuju se pomou jednog od oblika SQL-ovog iskaza SELECT.
Moemo ih kombinovati na koji god nain elimo, jedino moramo potovati sistemska
ogranienja koja vae za maksimalnu duinu i sloenost iskaza.
5.2.1. Ograniavanje
Operator ograniavanja (engl. restriction) izdvaja samo zapise koji ispunjavaju zadate
uslove. Realizuje se u obliku odredbe WHERE iskaza SELECT, na sljedei nain:
SELECT *
FROM Zaposleni
WHERE Prezime = Markovi;
Ovaj iskaz vraa zapis o zaposlenom Markovi Milanu jer je to jedina osoba u naoj bazi u
tabeli Zaposleni s tim prezimenom. (Simbol * u odjeljku <listaPolja> iskaza, specijalna je
skraenica za sva polja.)
Uslovi za izdvajanje podataka zadati u odredbi WHERE mogu biti proizvoljno sloeni.
Logiki izrazi se mogu kombinovati pomou operatora AND i OR. Vrijednost izraza e se
izraunavati za svaki zapis u skupu zapisa; ako je vrijednost True, zapis e biti ukljuen u
rezultate iskaza. Ako je za odreeni zapis vrijednost izraza False ili Null, taj zapis nee biti
ukljuen meu rezultate.
96
5.2.2. Projekcija
Dok ograniavanje izdvaja horizontalni isjeak iz skupa zapisa, projekcija (engl. projection)
izdvaja vertikalni isjeak; taj operator vraa samo podskup polja iz izvornog skupa zapisa.
SQL obavlja tu jednostavnu operaciju pomou odjeljka <listaPolja> iskaza SELECT tako
to u skup rezultata ukljuuje samo polja koja navedemo u tom odjeljku. Na primjer, pomou
sljedeeg iskaza moemo sastaviti listu telefonskih brojeva zaposlenih:
SELECT Ime, Prezime, Telefon

FROM Zaposleni
ORDER BY Prezime, Ime;
Treba imati u vidu da odredba ORDER BY samo sortira podatke i zbog toga nije ni u kakvoj
vezi sa samom projekcijom. U navedenom primjeru, lista e biti sortirana abecednim
redosljedom prvo polja Prezime, a zatim polja Ime.
5.2.3. Spajanje
Operacije spajanja (engl. join) vjerovatno su najuobiajenije relacione operacije. One su

svakako sutinski vane za model podataka razdvajanje podataka na vie relacija ne bi imalo
svrhe ukoliko ne bi postojao nain da ih ponovo kombinujemo kada nam to zatreba.Tano to ini
operator spajanja: kombinuje skupove zapisa na osnovu poreenja jednog ili vie polja s
jednakim vrijednostima.
Relacije spajamo pomou odredbe JOIN iskaza SELECT. Spojevi izmeu relacija
razvrstavaju se prema nainima poreenja polja izmeu kojih se uspostavlja veza i nainu na koji
se tumae rezultati poreenja. Razmotriemo ih jedan po jedan.
Jednakovrijedni spojevi
Kada se operacijom poreenja utvruje da li postoji jednakost, u pitanju je jednakovrijedni

spoj (engl. equi-join). U operaciji te vrste izdvajaju se samo zapisi koji u zadatim poljima sadre
jednake vrijednosti.
97
Primjera radi, pogledajmo relacije na slici 5.5. To je tipian primjer povezanih tabela koje su
nastale kao rezultat postupka normalizovanja. Polje ifraPorudbine je primarni klju tabele
Porudbine i spoljni klju tabele DetaljiPorudbine.
Slika 5.5. Ove tabele mogu se ponovo kombinovati pomou operatora spajanja
Da bismo ponovo kombinovali (i usljed toga denormalizovali) te tabele, upotrebimo sljedei

iskaz SELECT:
SELECT Porudbine.ifraPorudbine, Porudbine.ifraKupca, [DetaljiPorudbine].ifraArtikla

FROM Porudbine
INNER JOIN [Detalji porudbine] ON Porudbine.ifraPorudbine = [Detalji porudbine].ifraPorudbine
WHERE Porudbine.ifraPorudbine=10248;
Rezultat ovog iskaza je skup zapisa prikazan na slici 5.6..
Slika 5.6. Ovaj skup zapisa je rezultat spajanja tabela Porudbine i DetaljiPorudbine
Prirodni spojevi
Specijalan sluaj jednakovrijednog spoja je prirodni spoj (engl. natural join). Da bi se spoj
mogao kvalifikovati kao prirodni, operacija spajanja mora da ispuni sljedee uslove:
Operator poreenja mora biti jednakost.
98
U spoju moraju uestvovati sva polja koja su zajednika za obe relacije.

U skupu rezultata pojavljuje se samo jedan skup zajednikih polja.
Prirodni spojevi nisu ni po emu izuzetni. Ne ponaaju se na poseban nain, niti u maini
baze podataka postoji nekakva posebna podrka za njih. Oni su najei oblik spojeva izmeu
relacija, koji je toliko est da je dobio posebno ime.
Maina baze podataka Jet ipak ini neto zaista posebno ako napravimo prirodan spoj koji
ispunjava izvjesne dodatne uslove. Ukoliko uzmeu tabele postoji veza tipa jedan prema vie,
a zajednika polja koja se pojavljuju u rezultatima potiu iz tabele na strani vie, Jet e izvriti
tzv. preslikavanje redova (engl. Row Fix-Up) ili automatsku zamjenu (engl. AutoLookup).
Kada korisnik Accessovog obrasca unese neku vrijednost u kontrolu vezanu za jedno od polja
koja se pojavljuju u spoju, Jet e automatski popuniti odgovarajuim podacima kontrole vezane
za polja na strani vie. Ovo znatno olakava rad programerima.
Teta spojevi
Spoj koji se zasniva na operatoru poreenja koji nije jednakost (<>, >, >=, <, <=) zove se
teta spoj (engl. theta-join). (Tehniki gledano, svi spojevi su teta spojevi, ali je uobiajeno da se,
ako je operator poreenja jednakost, spoj zove jednakovrijedni spoj ili samo spoj.)
Teta spojevi su u praksi izuzetno rijetki, ali mogu biti korisni za rjeavanje pojedinih
problema. To su, prije svega, problemi pri pronalaenju zapisa koji sadre vrijednost veu od
prosjeka ili od ukupnog zbira, ili zapisa koji se nalaze u odreenom opsegu.
Pretpostavimo da smo napravili dva prikaza, jedan koji daje prosjean broj jedinica prodatih
po kategorijama artikala, i drugi koji daje ukupan broj prodatih jedinica po artiklu (slika 5.7).
Naredni iskaz SELECT, u kome je upotrebljen operator poreenja >, daje listu
najprodavanijih artikala u svakoj kategoriji:
SELECT DISTINCTROW ArtikliKategorijeProsjek.NazivKategorije,

ArtikliUkupno.NazivArtikla
FROM ArtikliKategorijeProsjek
INNER JOIN ArtikliUkupno
ON ArtikliKategorijeProsjek.ifraKategorije = ArtikliUkupno.ifraKategorije
AND ArtikliUkupno.UkupnoProdato > [ArtikliKategorijeProsjek] . [ProsjenoProdato];
99
Slika 5.7. Ova dva prikaza mogu se povezati pomou teta spoja
Rezultati su prikazani na slici 5.8.
100
Slika 5.8. Ovaj skup zapisa rezultat je teta spoja
U ovom primjeru, isti prikaz se moe definisati i sa odgovarajuom odredbom WHERE. U

stvari, kad izaemo iz prikaza SQL, Access e prepraviti upit da izgleda ovako:
SELECT DISTINCTROW ArtikliKategorijeProsjek.NazivKategorije,

ArtikliUkupno.NazivArtikla
FROM ArtikliKategorijeProsjek
INNER JOIN ArtikliUkupno
ON ArtikliKategorijeProsjek.ifraKategorije = ArtikliUpupno.ifraKategorije
WHERE ArtikliUkupno.UkupnoProdato > ArtikliKategorijeProsjek.ProsjenoProdato;
Tehniki gledano, svi spojevi, ukljuujui i jedakovrijedne i prirodne spojeve, mogu sa

izraziti pomou odgovarajueg uslova u odredbi WHERE. U sluaju teta spojeva, oblik sa
uslovom u odredbi WHERE gotovo uvijek je preporuljiviji jer u tom sluaju maina baze
podataka lake optimizuje izvrenje iskaza.
101
Spoljni spojevi
Svi spojevi koje smo do sada razmotrili bili su unutranji spojevi (engl. inner joints), tj.
spojevi koji uitavaju samo zapise za koje je uslov spajanja ispunjen. Treba imati u vidu da to
nije sasvim isto to i uitavanje samo zapisa sa poklopljenim vrijednostima u zadatim poljima,
iako se obino tako opisuje unutranji spoj. Pojam poklapanje ukazuje na jednakost, a kao to
smo vidjeli, ne zasnivaju se svi spojevi na jednakosti.
Relaciona algebra podrava jo jednu vrstu spoja, a to je spoljni spoj (engl. outer join).
Spoljni spoj uitava sve zapise koje bi uitao unutranji spoj, plus sve ostale zapise iz jednog ili
oba skupa zapisa. Umjesto nedostajuih vrijednosti (bez parnjaka), prikazivae se Null.
Spoljni spojevi se dijele na lijeve, desne ili potpune, u zavisnosti od toga koji se dodatni
zapisi pojavljuju u rezultatima. Teorijski, lijevi spoljni spoj uitava sve zapise iz skupa na strani
jedan veze tipa jedan prema vie, dok desni spoljni spoj uitava zapise sa strane vie.
Meutim, i u Jetu i u SQL Serveru, razlika se zasniva na redoslijedu kojim su skupovi zapisa
nevedeni u iskazu SELECT. Zbog toga oba naredna iskaza uitavaju sve zapise iz X i samo one
zapise iz Y koji ispunjavaju <uslov>:
SELECT * FROM X LEFT OUTER JOIN Y ON <USLOV>

SELECT * FROM Y RIGHT OUTER JOIN X ON <USLOV>
Potpuni spoljni spoj (engl. full outer join) uitava sve zapise iz oba skupa, pri emu
kombinuje one koji ispunjavaju uslov. SQL Server podrava potpune spoljne spojeve pomou
uslova koji se zadaju u odredbi FULL OUTER JOIN:
SELECT * FROM X FULL OUTER JOIN Y ON <USLOV>
Maina baze podataka Jet ne podrava direktno potpune spoljne spojeve, ali ih moemo
simulirati pomou unije lijevog i desnog spoljnog spoja.
5.2.4. Dijeljenje
Posljednja relaciona operacija je dijeljenje. Operator relacionog dijeljenja (koje je tako

nazvano da bi se razlikovalo od matematikog dijeljenja) uitava zapise iz jednog skupa zapisa u
kome se nalaze vrijednosti koje imaju parnjake u svim zapisima iz drugog skupa zapisa. Na
102
primjer, ako je dat skup zapisa koji se sastoji od kategorija artikala koje isporuuje svaki
dobavlja, relacionim dijeljenjem dobili bismo listu dobavljaa koji isporuuju artikle iz svih
kategorija.
To nije neuobiajena situacija, ali rjeenje nije jednostavno poto SQL-ov iskaz SELECT ne
podrava direktno relaciono dijeljenje. Meutim, postoji vie naina da se postignu isti rezultati
kao pomou relacionog dijeljenja. Najlake je da se zahtjev drugaije formulie.
Umjesto prikazati dobavljae koji isporuuju artikle u svim kategorijama, to se teko

obrauje, pokuajmo sa prikazati dobavljae za koje je ukupan broj kategorija artikala koje
isporuuju jednak ukupnom broju kategorija artikala. To je primjer proirene operacije koju
emo razmotriti u nastavku ovog poglavlja. Drugaije formulisanje zahtjeva nee uvijek biti
mogue, a tamo gdje nije, dijeljenje moemo realizovati pomou koreliranih upita. Poto
korelirani upiti izlaze izvan opsega ovog materijala, vie informacija o njima moemo potraiti
meu odrednicama navedenim u bibliografiji.
5.3. Operatori za rad sa skupovima
Sljedee etiri operacije relacione algebre zasnivaju se na tradicionalnoj teoriji skupova.

Ovdje su donekle izmjenjene s obzirom na to da radimo s relacijama a ne sa skupovima
apstraktnih elemenata.
5.3.1. Unija
Na konceptualnom nivou, relaciona unije (engl. relational union) predstavlja nadovezivanje

dva skupa zapisa. To je manje-vie relaciona verzija sabiranja. Rezultat unije skupa zapisa A sa
skupom zapisa B isti je kao kada sve zapise iz skupa A dodamo u skup B.
Primjera radi, pretpostavimo da nam treba spisak svih imena i adresa koji postoje u bazi
podataka da bismo poslali cirkularno pismo. Poto oba skupa zapisa Kupci i Zaposleni, u bazi
podataka sadre adrese, lako se mogu kombinovati pomou operacije unija. U ovom sluaju
upotrebili bismo izkaz UNION, na sljedei nain:
103
SELECT NazivPreduzea AS PunoIme, Adresa, Grad, PotanskiBroj

FROM Kupci
UNION SELECT [Prezime] & & [Ime] AS PunoIme, Adresa, Grad, PotanskiKod
FROM Zaposleni
ORDER BY PunoIme;
Obratimo panju na to da je polje NazivPreduzea preimenovano u PunoIme a polja

Prezime i Ime iz tabele Zaposleni nadovezana su jedno na drugo. Rezultujue polje takoe je
nazvano PunoIme. Upit unija ne zahtijeva da polja na <listiPolja> svakog iskaza SELECT
imaju ista imena, ali mora biti jednak broju polja koja imaju jednake (ili kompatibilne) tipove
podataka. Rezultati ovog iskaza izvrenog u Accessu prikazani su naslici 5.9.
Slika 5.9. Iskaz UNION kombinuje zapise iz dvije tabele
5.3.2. Presjek
Operator relacionog presjeka (engl. relational intersection) vraa zapise koji su zajedniki
za oba skupa zapisa. U sutini, to je operacija tipa pronai duplikate, to je i nain na koji se
najee koristi.
Presjek se realizuje pomou spoljnih spojeva. Pretpostavimo da smo nasljedili liste klijenata
iz vie starijih sistema, kao na slici 5.10.
104
Naredni iskaz SELECT pronalazi duplirane zapise:
SELECT DuplicateKupci1.*
FROM DuplicateKupci1
LEFT JOIN DuplicateKupci2
ON DuplicateKupci1.ifraKupca = DuplicateKupci2.ifraKupca
WHERE DuplicateKupci2.ifraKupca IS NOT NULL
Rezultati ovog iskaza prikazani su na slici 5.11.
Slika 5.10. Stare tabele esto sadre duplirane podatke
105
Slika 5.11. Spoljni spoj u kombinaciji sa operatorom IS NOT NULL pravi presjek
5.3.3. Razlika
Dok presjek dva skupa zapisa omoguava pronalaenje duplikata, operator relacione
razlike pronalazi siroie. Relacionu razliku (engl. relational difference) izmeu dva skupa
zapisa ine zapisi koji pripadaju jednom skupu ali ne i drugom.
Primjera radi, za ista dva skupa zapisa prikazana na slici 5.10, naredni iskaz SELECT
pronalazi zapise bez parnjaka:
ON DupicateKupci1.ifraKupca = DuplicateKupci2.ifraKupca
WHERE DuplicateKupci2.ifraKupca IS NULL
Operacija spoljnog spoja u ovom iskazu uitava sve zapise sa obe liste. Spoljni spoj
postavlja vrijednosti Null pored polja koja nemaju odgovarajue parnjake u drugoj tabeli.
Operator IS NULL u odredbi WHERE, ograniava uitane zapise samo na takve zapise (bez
parnjaka).
Da bismo obavili istu operaciju u dva odvojena koraka: prvo napravimo spoljni spoj kao
prikaz, a pomou odredbe WHERE suzimo broj zapisa koje prikaz izdvaja. Postupak je
ilustorvan na slici 5.12.
Korak 1: pravljenje spoljnog spoja

106
Slika 5.12.a. Operacija formiranja razlike odvija se u dva koraka Korak 1
Korak 2: izdvajanje zapisa gdje je ifraKupca = Null

LEFT JOIN DupoicateKupci2
WHERE DuplicateKupci2. ifraKupca IS NULL
Slika 5.12.b. Operacija formiranja razlike odvija se u dva koraka Korak 2
5.3.4. Dekartov proizvod
Posljednji operator za rad sa skupovima je Dekartov proizvod. Slino svom parnjaku u

tradicionalnoj teoriji skupova, Dekartov proizvod (engl. Cartesian product) dva skupa zapisa
kombinuje svaki zapis iz jednog skupa sa svakim zapisom iz drugog skupa.
107
Dekartov proizvod (ili samo proizvod) dobija se pomou iskaza SELECT u kome su zadata
dva skupa zapisa (ili vie njih) ali ne i odredba za spajanje slupova (JOIN). Naredni iskaz
kombinuje svakog kupca sa svakim artiklom:
SELECT ImeKupca, ImeArtikla FROM Kupci, Artikli;
Dekartovi proizvodi pojekad su korisni za analitike namjene ili za dobijanje meurezultata

za dalju obradu. Meutim, ee se formiraju nenamjerno. Na primjer, ako u Accessovom
prozoru za izradu upita zaboravimo da povuemo liniju spajanja, imamo Dekartov proizvod.
5.4. Specijalni relacioni operatori
Od pojave relacionog modela do danas, predloeno je vie dopuna relacione algebre.

Razmotriemo tri meu njima koje su opteprihvaene: izraunavanje zbirnih podataka,
proirivanje i preimenovanje. Uz to, razmotriemo i tri dopune koje je uveo Microsoft:
transform, rollup i cube.
5.4.1. Izraunavanje zbirnih podataka
Operator za izraunavanje zbirnih podataka (engl. summarize operator)ini upravo ono to

bismo od njega oekivali: formira zapise koji sadre zbirne podatke grupisane na osnovu zadatih
polja. Izraunavanje zbirnih podataka izuzetno je korisno kad god treba prouavati podatke na
nivou apstrakcije viem od onog koji se uva u bazi podataka.
Operaciju izraunavanja zbirnih podataka realizuje odredba GROUP BY iskaza SELECT.

Za svaku nedupliranu vrijednost u zadatom polju ili poljima, formira se po jedan zapis. Ako je
navedeno vie od jednog polja, grupe se ugnjeduju. Primjera radi, pogledajmo naredni iskaz:
SELECT Kategorije.NazivKategorije, Artikli.NazivArtikla,

SUM ( [DetaljiPorudbine] .Koliina) AS UkupnoProdato
FROM Kategorije
INNER JOIN Artikli
ON Kategorije. ifraKategorije = Artikli.ifraKategorije)
INNER JOIN [Detalji porudbine]
ON Artikli. ifraArtikla = [Detalji porudbine] .ifraArtikla
GROUP BY Kategorije. NazivKategorije, Artikli.NazivArtikla;
108
Ovaj iskaz generie po jedan zapis za svaki artikal u bazi podataka, grupisano po kategoriji i
sa sljedea tri polja: NazivKategorije, NazivArtikla i UkupnoProdato (slika 5.13)
Slika 5.13. Odredba GROUP BY izraunava zbirne podatke
Polja navedena na <listiPolja> u iskazu SELECT moraju biti takoe navedena na

<listiPoljaZaGrupisanje> ili kao argument jedne od SQL-ovih zbirnih funkcija. SQL-ove zbirne
funkcije izraunavaju odreene zbirne vrijednosti u svakom zapisu. Najee upotrebljavane
zbirne funkcije su AVERAGE, COUNT, SUM, MAXIMUM i MINIMUM.
Upotreba zbirnih funkcija jo je jedna oblast u kojoj moe doi do problema sa Null
vrijednostima. U zbirnim operacijama, Null vrijednosti se uzimaju u obzir jer ine grupu.
Meutim, zbirne funkcije ih zanemaruju. Taj problem se javlja obino samo ako jedno od polja
na <listiPoljaZaGrupisanje> navedemo kao parametar neke zbirne funkcije.
5.4.2. Proirenje
Operator za proirenje (engl. extend operator) omoguava da definiemo virtuelna polja koja
se izraunavaju na osnovu konstanti i vrijednosti uskladitenih u bazi podataka. Virtuelna polja
se prave tako to ih definiemo na <listiPolja> iskaza SELECT, na sljedei nain:
109
SELECT [CijenaPoJedinici] * [Koliina] AS UkupnaVrijednost

FROM [Stavke Fakture];
Prorauni kojima definiemo virtuelna polja mogu biti proizvoljne sloenosti. Postupak je
toliko jednostavan i brz da se rijetko moe opravdati dodavalje izraunatog polja u tabelu.
5.4.3. Preimenovanje
Posljednji uobiajeni operator je operator za preimenovanje (engl. rename operator).

Operacija preimenovanja moe se izvesti nad skupom zapisa koji se nalaze na
<listiSkupovaZapisa> ili nad poljima <listePolja>. U maini baze podataka Jet, sintaksa za
preimenovanje skupa zapisa izgleda ovako:
SELECT <imePolja> AS <drugoImePolja>

FROM <imeTabele> AS <drugoImeTabele>
U SQL Serveru, rezervisana rije AS nije obavezna, kao u sljedeem primjeru:
SELECT <imePolja> AS <drugoImePolja> FROM <imeSkupaZapisa>

<drugoImeSkupaZapisa>
Preimenovanje je naroito korisno kada definiemo prikaz koji sadri samospoj (engl.
selfjion), kao u narednom bloku koda:
SELECT Nadreeni.Prezime, Radnik.Prezime

FROM Zaposleni AS Radnik
INNER JOIN Zaposleni AS Nadreeni
ON Radnik.ifraZaposlenog = Nedreeni.ifraNadreenog;
Ova sintaksa omoguava da svaku upotrebu iste tabele definiemo kao logiki zasebnu.
5.4.4. Iskaz Trasform
Iskaz TRANSFORM je prva Microsoftova dopuna relacione algebre koju emo razmotriti.
TRANSFORM preuzima rezultate zbirne operacije (GROUP BY) i prikazuje ih rotirane za 90
110
stepeni. Ovu veoma korisnu operaciju, poznatuju kao unakrsni upit (engl. crosstab query),
podrava maina baze podataka Jet. U SQL Serveru nije bila podrana sve do pojave Yukona.
Iskaz TRANSFORM ima sljedeu osnovnu sintaksu:
TRANSFORM <zbirnaFunkcija>
SELECT <listaPolja>
FROM <listaSkupovaZapisa>
GROUP BY <listaPoljaZaGrupisanje>
PIVOT <zaglavljaPolja> [IN (<listaVrijednosti>)]
Odredba TRANSFORM <zbirnaFunkcija> definie zbirne podatke od kojih e se sastojati

rezultujui skup zapisa. Iakaz SELECTmora da sadri odredbu GROUP BY a ne moe da sadri
odredbu HAVING. Kao i u svakoj odredbi GROUP BY, <listaPolja> moe se sastojati od vie
polja. (U iskazu TRANSFORM, <listaPolja> i <listaPoljaZaGrupisanje> gotovo uvijek su
identine.)
Odredbom PIVOT zadajemo polje ije e se vrijednosti pojavljivati u zaglavlju kolona

rezultata. Ako ne zadamo drugaije, maina baze podataka Jet poredae kolone skupa rezultata
abecednim redom slijeva nadesno. Meutim, neobavezna naredba IN omoguava da zadamo
imena kolona, koja e se prikazivati redom kojim ih navedemo na <listiVrijednosti>.
Naredni iskaz TRANSFORM uitava praktino iste podatke kao primjer naveden za
izraunavanje zbirnih podataka, dat na slici 5.13.
TRANSFORM Count (Artikli.ifraArtikla) AS CountifraArtikla

SELECT Dobavljai.NazivPreduzea
FROM Dobavljai
INNER JOIN (Kategorije INNER JOIN Artikli
ON Kategorije.ifraKategorije = Artikli. ifraArtikla
ON Dobavljai. ifraDobavljaa = Artikli.ifraArtikla
GROUP BY Dobavljai.NazivPreduzea
PIVOT Kategorije, NazivKategorije
Rezultati ove operacije prikazani su na slici 5.14.
111
Slika 5.14. Iskaz TRANSFORM rotira rezultate za 90 stepeni
5.4.5. Operator Rollup
Operator za izraunavanje zbirnih podataka u obliku odredbe GROUP BY, generie zapise
koji sadre izraunate zbirne podatke. Odredba ROLLUP, koja je podrana samo u SQL Serveru,
logino je proirenje te operacije koje omoguava izraunavanje ukupnih zbirova:
SELECT Ketegorije.NazivKategorije, Artikli.NazivArtikla,

SUM ( [Detalji porudbine] .Koliina) AS UkupnaKoliina
FROM (Kategorije INNER JOIN Artikli
ON Kategorije.ifraKategorije = Artikli.ifraKetegorije)
INNER JOIN [Detalji porudbine]
ON Artikli.ifraArtikla = [Detalji porudbine] .ifraArtikla
GROUP BY Kategorije.NazivKategorije, Artikli.NazivArtikla WITH ROLLUP;
5.4.6. Operator Cube
Operator CUBE takoe je na raspolaganju samo u SQL Serveru i realizovan je kao proirenje
odredbe GROUP BY. Odredba CUBE nalae izraunavanje zbirnih podataka pri svakoj
promjeni vrijednosti u svakoj koloni navedenoj na <listiPoljaZaGrupisanje>. Konceprualno je
slian operatoruROLLUP, ali dok ROLLUP izraunava ukupan zbir za svaku kolonu navedenu
na <listiPoljaZaGrupisanje>, CUBE izraunava zbirne podatke za dodatne grupe.
Na primjer, ako na <listiPoljaZaGrupisanje> imamo tri polja A, B, i C operator CUBE e

izraunati sljedeih sedam zbirnih vrijednosti:
1. Ukupan broj vrijednosti u koloni C.
112
2. Ukupan broj vrijednosti u koloni C, grupisano po vrijednostima u koloni A.

3. Ukupan broj vrijednosti u koloni C, grupisano po vrijednostima u koloni C unutar A.
4. Ukupan broj vrijednosti u koloni C, grupisano po vrijednostima u koloni B unutar A.
5. Ukupan broj vrijednosti u koloni C, grupisano po vrijednostima u koloni B.
6. Ukupan broj vrijednosti u koloni C, grupisano po vrijednostima u koloni A unutar B.
7. Ukupan broj vrijednosti u koloni C, grupisano po vrijednostima u koloni C unutar B.
5.5. Saetak
U ovom poglavlju razmotrili smo rad sa osnovnim relacijama pomou raznih relacionih
operatora i obradili smo nekoliko primjera napisanih na jeziku SQL. Ponovo smo razmotrili, ali
iz drugog ugla, problem upotrebe Null vrijednosti i trovrijednosnu logiku.
Od standardnih relacionih operatora, operatori za ograniavanje i projekciju izdvajaju

podskupove jednog skupa zapisa. Operatori za spajanje, presjek, razliku u Dekartov proizvod
odreuju nain na koji se dva skupa zapisa kombinuju. Svi ti operatori, izuzev operatora razlika,
mogu se realizovati pomou SQL-ovog iskaza SELECT. Razlika se moe ponekad realizovati
pomou izraza SELECT, a ponekad zahtijeva primjenu drugih tehnika koje su izvan opsega obog
materijala.
Prouili smo i nekoliko specijalnih operatora. Operator za izraunavanje zbirnih podataka i

operator za proirenje obavljaju proraune nad podacima. Operator za preimenovanje upravlja
imenima kolona koja se pojavljuju u prikazu. TRANSFORM, ROLLUP i CUBE su specijalna
proirenja jezika SQL koja je uveo Microsoftm a svako meu njima prua poseban nain
izraunavanja zbirnih podataka i njihovog prikazivanja.
113
6. Teorija dimenzionalnih baza podataka - Osnovni dimenzionalni koncepti
U prvom dijelu ovog materijala, razmotrili smo osnovne principe tradicionalne relacione
teorije i model entitet/veza. Veina aplikacija koje koriste baze podataka napravljene su
primjenom tih principa, iz vrlo opravdanih razloga. Kada se dosljedno primjenjuju, ti principi
obezbjeuju integritet podataka, otpornost na greke i skalabilnost u aplikacijama u kojima se
podaci esto mijenjaju.
Meutim, izmjene podataka nisu obavezno este u svim aplikacijama koje rade s bazama
podataka. Postoji i druga, itava kategorija takvih aplikacija sa razliitim namjenama i
zahtjevima. Te aplikacije moraju da skladite veoma (ponekad ak izuzetno) velike koliine
arhivskih podataka, ali se ti podaci, nakon unoenja, vrlo rijetko mijenjaju. Iako s tim
aplikacijama rijetko radi vie od nekoliko desetina korisnika istovremeno, njima je potreban
efikasan nain izrade izvjetaja na osnovu podataka. Efikasno u ovom sluaju znaidvije
stvari: ad hok upiti moraju brzo da vraaju rezultate, a struktura eme baze podataka mora biti
lako razumljiva krajnjem korisniku.
eme baze podataka do kojih se dolazi primjenom pravila za normalizovanje opisanih u

prvom dijelu, rijetko ispunjavaju te uslove. ak i ako su baze podataka dovoljno male da se brzo
odazivaju, a neke meu njima jesu takve, obrada arhivskih podataka moe biti nezgrapna ako se
koristi relacioni model. Osim toga, za potpuno normalizovane eme teko se moe rei da su
lako razumljive krajnjem korisniku.
S druge strane, pravila za dimenzionalne baze podataka koja emo ovdje razmotriti, razvijena
su upravo zato da bi se zadovoljile te potrebe.
6.1. Model dimenzionalne baze podataka
Relacione baze podataka, zasnovane na modelu entiteta i veza, esto podravaju radne
aktivnosti organizacije, kao to je obrada porudbina ili obraunavanje zarada zaposlenih. One
pruaju odgovore na pitanja tipa: Koliko je odvijaa naruio Markovi Milan 15. Juna?, ili
Koliko je isplaeno Mitrovi Petru marta 2007. godine?. Budui da je jedinica podataka u
takvim bazama pojedinana transakcija stavka porudbine, pojedinana zarada ti sistemi se
114
esto nazivaju OLTP (On-Line Transaction Processing) sistemi (za direktnu transakcionu
obradu).
Taj naziv je moda koristan, ali ne i dovoljno taan, budui da su eme zasnovane na modelu
entiteta i veza takoe najbolje strukture za skladitenje statikih podataka na primjer, tekueg
fonda knjiga u biblioteci (katalog) ili liste kupaca.
S druge strane, za analizu stanja u organizacijama gotovu uvijek se koriste eme baza
podataka zasnovane na dimenzionalnom modelu. One pruaju odgovore na pitanja tipa: Koje
grupe proizvoda donose najvei profit?, ili: Kako se kree prodaja ove sezone? To je razlog
to se one esto nazivaju OLAP (On-Line Analitical Processing) sistemi (za direktnu analitiku
obradu).
OLAP je tokoe koristan, ali ne ba sasvim taan izraz. Dok se OLAP sistemi rijetko koriste
za bilo ta drugo osim za analizu podataka, OLTP sistemi takoe mogu, a esto se i koriste, za
analizu podataka. Te dvije vrste sistema nisu meusobno iskljuive. Osim toga, kao to je vano
da logika i fizika struktura baze podataka budu razdvojene, miljenja smo da je prilino
pogreno koristiti funkcionalnu terminologiju da bi se izrazile strukturne razlike.
Iz tih razloga, i samo u ovom materijalu, koristiemo rijei normalizovana i

dimenzionalna da bismo istakli razliku izmeu ema razvijenih na osnovu pomenuta dva skupa
pravila. Treba imati na umu da je ovo terminologija uvedena samo ovdje. U drugoj strunoj
literaturi, poto se te dvije vrste ema baza podataka rijetko razmatraju zajedno, razlika se i ne
pravi. Ono to emo zvati normalizovana baza podataka, opisuje se samo kao baza podataka,
dok se dimenzionalna baza podataka naziva dimenzionalna baza podataka ili OLAP baza
podataka.
Meutim, u ovom materijalu moramo praviti razliku izmeu ta dva tipa baza podataka. Zbog
toga emo koristiti izraz normalizovana baza podataka da bismo opisali tradicionalne relacione
strukture koje smo razmatrali u prvom dijelu ovog materijala, i koje su definisane pomou
entiteta, atributa i veza (slika 6.1).
115
Veza
Porudzbine1 Detalji porudzbine1
PK ifra porudbine PK ifra porudbine
ifra kupca ifra artikla

Atribut ifra zaposlenog Jedinicna cijena Atribut
Datum porudzbine Kolicina
Rok isporuke Popust
Datum isporuke
pediter
Adresa peditera
Entitet
Entitet
Slika 6.1. Dvije tabele iz eme normalizovane baze podataka
Treba imati u vidu to da dva entiteta prikazana na slici 6.1. nisu cijela ema; nedostaju
entiteti Kupci, Zaposleni i Artikli.
Slika 6.2. prikazuje dimenzionalnu bazu podataka ekvivalentnu onoj na slici 6.1, ali
definisanu pomou tabela injenica, injenica i dimenzija. Kao to se vidi, ta dva modela se
djelimino preklapaju. Na kraju krajeva, i dalje radimo s relacionim bazama podataka. ema se i
dalje sastoji od logikih relacija (mada se one u dimenzionalnom dizajnu nazivaju optim
imenom tabele), ali su te relacije podijeljene u dvije jasno razdvojene kategorije: imamo jednu
tabelu injenica (engl. fact table) i vie tabela dimenzija (engl. dimension tables).
Obratimo panju na to da su, za razliku od normalizovane verzije, na slici 6.2 prikazane sve
relacije u emi. Da bi slika bila preglednija, u tabelama dimenzija nisu prikazani svi atributi, ali
su prikazane sve dimenzije. Krajnji korisnik e znatno lake razumjeti ovu strukturu od
ekvivalentne nomalizovane eme.
Jedinstvena tabela injenica modeluje podatke koji se koriste za izradu izvjetaja. Ta tabela
sadri dvije vrste atributa: kljune atribute, tj. spoljne kljueve pomou kojih je tabela injenica
povezana s tabelama dimenzija, i injenice, tj. atribute to sadre same podatke koji se obrauju.
Obratimo panju na to da je tabela injenica postavljena na sredinu dijagrama, a oko nje su

rasporeene tabele dimenzija. To je konvencionalni oblik tih ema. Poto je neko, negdje,
odluio da takav razmjetaj podsjea na zvijezdu, nazvan je zvjezdasta ema (engl. star schema).
116
Slika 6.2. Primjer dimenzionalne eme
Tehnika definicija zvjezdaste eme glasi: ema se sastoji od jedne tabele injenica i vie
tabela dimenzija, koje su sve neposredno povezane s tabelom injenica i obino nisu povezane s
drugim dimenzijama. Meutim, u nekim relativno rijetkim situacijama korisno je razdvojiti
odreenu dimenziju na vie relacija, kao na slici 6.3.
Ta struktura je poznata kao pahuljasta ema (engl. Snowflake schema). Pahuljasta ema u
stvari normalizuje dimenziju. Normalizovanje uglavnom nije primjenjivo u dimenzionalnim
bazama podataka, ali postoji nekoliko izuzetaka koje emo razmotriti kasnije.
Drugi oblik u kojem se mogu zamisliti podaci u dimenzionalnoj bazi podataka, jeste kocka
(engl. cube), kao na slici 6.4. Mnogi i nazivaju dimenzionalnu bazu podataka kocka. Taj izraz
koristi i Microsoft u svojoj dokumentaciji i proizvodima, a njega emo koristiti za opis fizikog
skladita podataka.
117
Dimenzija
Dimenzija Tabela cinjenica
Dimenzija
Dimenzija
Dimenzija
Dimenzija
Slika 6.3. Pahuljasta ema
Tehniki gledano, to je N-kocka jer moe imati vie od tri dimenzije, ali se N obino
izostavlja. Upotreba izraza kocka ne podrazumijeva drugaiju emu baze podataka ema se i
dalje definie primjenom pravila koja emo razmotriti u narednom tekstu ve samo odraava
drugaije vienje podataka.
118
Slika 6.4. Dimenzionalna kocka
6.2. Terminologija
Tehnika projektovanja dimenzionalnih baza podataka zasniva se na skupu koji ini vie
aplikacionih arhitektura i analitikih postupaka. Veina njih izlazi van okvira ovog materijala, ali
emo ih ipak ukratko razmotriti da bismo postavili dimenzionalnu analizu u odgovarajui
kontekst.
Naalost, budui da je u pitanju nova oblast, terminologija jo nije sasvim usklaena

dogaa se da veina izraza koje emo ovdje spominjati budu upotrebljeni za opisivanje cijele
oblasti. Kao i obino, skup izraza koje koristimo u kontekstu cijelog materijala odabran je na
osnovu onoga to nam se inilo loginim a bilo je u uobiajenoj upotrebi, to znai da je kod
itanja drugih informacija potreban oprez zbog terminoloke nekonzistentnosti.
Na primjer, Microsoft koristi izraz poslovne informacije (engl. business intelligence) kao
opti izraz koji obuhvata cijelu oblast, dok se skladite za podatke (engl. data warehousing)
odnosi na vie stvari. Drugi autori koriste skladite za podatke kao opti izraz, a poslovne
informacije uopte ne koriste. U konterkstu ovog materijala, koristiemo izraz poslovne
informacije kao opti izraz za cijelu oblast.
119
Izraz skladite za podatke koristiemo za fizike strukture podataka, a OLAP za aplikacije.

Za pojedinane kocke koristiemo izraz odjeljci za podatke (engl. data marts). Po ovoj definiciji,
moe se zamisliti da skladite za podatke ine pojedinane kocke za podatke koje organizacija
koristi.
U strunoj literaturi, izraz prekopavanje podataka (engl. data mining) uglavnom se odnosi
na primjenu statistikih tehnika na transakcione podatke da bi se iz njih izveli predvidivi
trendovi i pravila. Prekopavanje (rudarenje) podataka je precizna matematika oblast (SQL
Server 2000 i vie podrava odreene tehnike iz te oblasti), ali ni u kom sluaju ne obuhvata sve
analitike namjene za koje se koriste skladita podataka. Kao opti izraz, koristiemo poslovna
analiza.
Da bi se dobila cjelovita struktura organizacije, obino se moraju uitati podaci iz vie

OLTP sistema. Pretpostavimo da odreena organizacija koristi dva primarna OLTP sistema,
jedan za proizvodnju i drugi za obradu porudbina. Najpraktinije rjeenje je da se naprave dvije
odvojene kocke podataka, po jedna za svaki sistem.
6.3. Istorija poslovnih informacija
Nakon uvoenja raunarske podrke za veinu radnih postupaka, ljudi su shvatili da bi se

podaci uskladiteni u OLTP sistemima mogli koristiti za pomo rukovodiocima pri donoenju
odluka, ali podaci nisu bili dostupni u odgovarajuem obliku.
tampani izvjetaji su tradicionalni oblik predstavljanja informacija zasnovanih na OLTP

podacima. Naalost, teko je unaprijed predvidjeti parametre svih moguih analitikih izvjetaja.
Ad hok izrada izvjetaja nije jednostavna jer je osnovni problem u tome to veina alatki za
izradu izvjetaja zapravo nije namjenjena krajnjim korisnicima.
Prvo, i dalje postoji problem narmalizovanih ema. Ako poslovne analitiare i rukovodioce
ograniimo na unaprijed definisane upite, moe se dogoditi da time ograniimo i sam postupak
analize u tolikoj mjeri da to postane neprihvatljivo. Ali ako tim korisnicima dozvolimo
neogranien pristup sirovim podacima, rizikujemo da zaguimo cijeli sistem.
120
Treba imati na umu da se pomenuti OLTP sistemi koriste za obradu transakcija. To znai da
analitiar koji pokrene izradu Dekartovog proizvoda tri tabele, moe da zaustavi rad cijele
organizacije. ak i u najpovoljnijim okolnostima, mnoga pitanja na koja analitiari i rukovodioci
trae odgovor, zahtijevaju spajanje velikih (sporih) tabela to optereuje sistem.
Skladita za podatke su smiljena kao rjeenje tih problema. U skladitu za podatke, podaci
iz vie OLTP sistema izdvajaju se i stavljaju na raspolaganje analitiarima i rukovodiocima u
lako razumljivom obliku. Dimenzionalni dizajn predstavlja tekui nain razmiljanja u vezi s
najboljom metodom za predstavljanje tih podataka.
Do pojave SQL Servera 2000, skladita za podatke bila su slabo razumljiva, skupa i
ograniena uglavnom na velike firme. Dimenzionalna analiza nije se smatrala sastavnim dijelom
projekta uobiajenih relacionih baza podataka, uprkos injenici da je veina skladita za podatke
bila realizovana pomou relacionih baza podataka.
Ali, kao i u svim drugim oblastima, sada su poslovne informacije dostupne i personalnim
raunarima i sve vie se integriu u projekte uobiajenih aplikacija. Time se otvaraju nove bitno
drugaije mogunosti procesiranja, od procesiranja podataka i informacija do procesiranje
znanja, ali to je tema za drugi materijal.
6.4. Saetak
U ovom poglavlju uopteno smo razmotrili dimenzionalne baze podataka. Vidjeli smo
sljedee: dok su tradicionalne normalizovane baze podataka projektovane za obradu estih
dodavanja i auriranja podataka, dimenzionalne baze podataka namjenjene su prvenstveno za
obradu ad hok upita koje alju krajnji korisnii. Podaci,nakon prenoenja u dimenzionalnu bazu
podataka, rijetko se auriraju. Zvjezdaste i pahuljaste eme predstavljaju dimenzionalni
ekvivalent dijagrama entiteta i veza koji se koriste za definisanje normalizovanih baza podataka.
Zvjezdaste eme definiu relacije pomou tabela injenica i dimenzija. Tabele injenica sastoje
se od dvije vrste atributa, koji su spoljni kljuevi u tabelama dimenzija, i injenica, koje su sami
podaci uskladiteni u bazi.
Relacije definisane u zvjezdastoj emi moemo zamisliti i kao kocke (tehniki su to n-

kocke). Kocke podataka i zvjezdaste eme praktino su meusobno zamjenjive; to su samo
drugaiji oblici predstavljanja istih koncepata.
121
Dimenzionalni dizajn je analitika komponenta opte oblasti poznate pod nazivom poslovne
informacije (koju neki autori zovu skladite podataka). Aplikacije napravljene primjenom tih
tehnika ponekad se nazivaju OLAP aplikacije radi razlikovanja od OLTP aplikacija napravljenih
primjenom modela entiteta i veza.
OLAP aplikacije esto koriste tehnike prekopavanja (rudarenja) podataka da bi utvrdile

trendove u podacima. Meutim, prekopavanje podataka je samo jedna od komponenata poslovne
analize koja se obavlja pomou tih aplikacija.
122
7. Tabele injenica
U prethodnom poglavlju, razmotrili smo veliku sliku dimenzionalnog dizajna koji su njeni
sastavni dijelovi i kako se meusobno uklapaju. U ovom poglavlju prelazimo na detaljnije
razmatranje iste oblasti tako to emo podrobnije prouiti tebele injenica. Kako je ve reeno,
tabele injenica su jedna od dvije vrste relacija u dimenzionalnom modelu (drugoj vrsti pripadaju
tabele dimezija).
7.1.1. Struktura tabele injenica
Na slici 7.1 prikazan je vrlo jednostavan primjer tabele injenica koja modeluje porudbine
kupaca. Osnovna struktura je ista kao tabela razvijena pomou relacionog modela relacija se
sastoji od skupa atributa. Atributi u tabeli injenica mogu se razvrstati u dvije grupe: kljueve
dimenzija (engl. dimension keys), koji povezuju tabelu injenica s tabelama dimenzija i injenice
(engl. facts), koje predstavljaju stvarne vrijednosti koje mjerimo.
Slino skupovima dimenzija, skup atributa tabele injenica moe, teorijski, biti prazan.
Meutim, u praksi e gotovo uvijek sadravati barem dva atributa: kombinaciju jednog kljua
dimenzije i jedne injenice, ili u rijetkim sluajevima samo dva kljua dimenzija.
Kljuevi dimenzija su u sutini ekvivalentni spoljnim kljuevima u relacionom modelu po

tome to se koriste za povezivanje tabele injenica s tabelom dimenzija, ali je njihova primarna
svrha neto drugaija. Kao to smo vidjeli u prvom dijelu ovog materijala, jedan od primarnih
ciljeva relacionog dizajna jeste eliminisanje redundantnosti podataka i anomalija pri auriranju
iji bi ono bili uzrok.
Slika 7.1. Jednostavna tabela injenica
123
Meutim, to je u dimenzionalnim bazama podataka nepotrebno jer se njihov sadraj rijetko

aurira. Tabele dimenzija ipak smanjuju redundantnost u tabeli injenica, ali je to samo zgodan
sporedni efekat; njihova primarna svrha je da to vie opisanih atributa stave na raspolaganje
korisniku, koji e ih upotrebljavati kao uslove za izdvajanje podataka kada bude analizirao
podatke.
Princip redundantnost je nebitna vai i za atribute koji predstavljaju injenice. Obratitimo

panju na to da je atribut Broj porudbine injenica a ne klju dimenzije. U normalizovanoj bazi
podataka, atributi prikazani u ovoj tabeli injenica bili bi razdvojeni u dvije zasebne tabele: jednu
koja predstavlja porudbine i drugu koja predstavlja stavke (detalji) porudbina. U uobiajenoj
fizikoj realizaciji, tabela porudbina sadravala bi po jedan red za svaku porudbinu, a tabela
stavki porudbina imala bi po jedan red za svaki artikal naveden u porudbini. Atributi
ifraKupca, ifraZaposlenog i DatumPorudbine pripadali bi tabeli porudbina, a njihove
vrijednosti bi se zbog toga evidentirale samo jedanput za svaku porudbinu. U navedenom
primjeru tabele injenica, svi atributu ponovili bi se za svaki artikal koji pripada porudbini.
(Primjetimo takoe, da je DatumPorudbine iz normalizovane baze podataka postao klju
dimenzije u tabeli injenica, ali o tome emo govoriti u narednom poglavlju.)
Sasvim je uobiajeno da na opisani nain tabela injenica objedini vie normalizovanih

tabela i to nije propust u dizajnu. Poto se tabele u dimenzionalnoj bazi podataka rijetko
auriraju, problem auriranja istog podatka na vie mjesta obino se ne pojavljuje. Troi se malo
vie prostora na disku u navedenom primjeru, veliina datumskog polja puta prosjean broj
artikala po narudbini, ali to je zanemarivo u poreenju s cijenom dodatnog spajanja tabela
ako korisnik zada datum ili opseg datuma kao uslov za izradu izvjetaja.
7.1.2. Osobine injeninih atributa
Osim kljueva dimenzija, tabele injenica sadre i injenine atribute (engl. facts attributes).
(Postoji izuzetak od tog pravila, kojeg emo razmotriti u nastavku poglavlja.) Idealna injenica
ima dvije osobine: numerikog je tipa i potpuno je aditivna.
Kako se dimenzionalne baze podataka koriste za analize, posljedica toga je da e korisnici

rijetko razmatrati pojedinane redove u tabeli injenica. Ako injenica nije numerikog tipa na
primjer, ako je polje datumskog ili tekstualnog tipa tee je kombinovati zapise. Nenumeriki
124
atributi mogu se prebrojati ili se od njih moe sastaviti lista, ali se ne moe izraunati njihov
ukupan zbir, niti prosjek.
Na primjer, ukupna koliina plavih cipela broj 43 prodatih prvog oktobra, moe se
jednostavno izraunati ako se SQL-ova funkcija Sum primjeni na injenicu Koliina. Ali ako je
vrijednost injenice ImeKupca, moemo izraunati samo ukupan broj kupaca: prvog oktobra je
38 kupaca naruilo robu. Teorijski, moemo sastaviti listu svih 38 kupaca, ali poto aplikacija
nije trivijalna, taj broj moe isto tako biti 38.000 ili ak 38.000.000, pa je stoga malo vjerovatno
da e liste vrijednosti injenica ikad biti korisne.
Tekstualne injenice primjer su neaditivnih injenica njihove vrijednosti se ne mogu

sabirati. Nenumeriki atributi su, po definiciji, takoe neaditivni. To ne znai da ih nikad ne bi
trebalo ukljuivati u tabele injenica, ve da to treba initi oprezno. Prije nego to tabeli
injenica dodamo enaditivni atribut, treba dobro razmisliti da li bi efikasnije rjeenje bilo da ga
tretiramo kao dimenziju.
Postoje tzv. poluaditivne injenice. To su injenice koje su aditivne u nekim dimenzijama,

ali ne u svim.
Klasian primjer poluaditivne injenice jeste dnevno stanje na bankovnom raunu. Savreno
je legitimno da saberemo tekua stanja na svim svojim raunima odreenog dana ta injenica
je aditivna u dimenziji BankovniRaun ali stanje na kraju mjeseca na tednoj kljiici nije zbir
stanja tokom proteklog mjeseca injenica nije aditivna u dimenziji vrijeme.
Manje je vjerovatno da se ispostavi kako su poluaditivne injenice zapravo preruene

dimenzije (to je prije sluaj s neaditivnim injenicama), ali ni one nisu bez problema. One ne
uvode nikakva posebna ogranienja u projekat eme baze podataka, ali bi trebalo da eona
komponenta aplikacije upozori korisnika pri pokuaju da izvri operacije koje zahtijevaju
izraunavanje zbirnih podataka u poluaditivnoj dimenziji.
Jedna od karakteristika dimenzionalnih baza podataka koju jo nismo pomenuli jeste

sljedea: za razliku od normalizovanih baza podataka, njihove strukture su uvijek veoma sline.
Razlikuje se broj dimenzija kao i injenice i atributi ali se opta struktura uvijek sastoji od
jedne tabele injenica okruene dimenzijama.
125
To omoguava izradu optih eonih komponenata za pristupanje dimenzionalnim bazama

podataka. Razumije se, mogue je praviti opte eone komponente i za rad s normalizovanim
bazama podataka; Microsoftov Access je jedna od njih. To znai da je mogue napraviti eone
komponente koje su znatno manje komplikovane za krajnje korisnike. Dobar primjer toga je
Analysis Manager, sastavni dio SQL Serverovog modula Analysis Services.
Mogue je da eona komponenta unaprijed predvidi optu strukturu baza podataka i da

odredi tanu emu tek pri izvravanju. Problem u ovom sluaju je to to eona komponenta (a ni
bilo ko drugi) ne moe obinim uvidom da utvrdi da li je odreena numerika injenica
poluaditivna ili potpuno aditivna. Taj se podatak mora negdje uvati kao metapodatak. Uprkos
sve veoj popularnosti XML-a, formati za metapodatke i dalje su u velikoj mjeri
nestandardizovani.
To praktino znai sljedee: ako u dimenzionalnu bazu podataka ukljuimo poluaditivne

injenice, preporuljivo je da koristimo namjenski napravljenu eonu komponentu koja ita meta
podatke i upozorava korisnike ukoliko pokuaju da izraunaju zbirne podatke u poluaditivnoj
dimenziji. Osim toga, trebalo bi upozoriti korisnike na to da e morati sami da rjeavaju opisani
problem ukoliko koriste eonu komponentu nekog nezavisnog proizvoaa (a ne postoji
opravdan razlog zbog kojeg to ne bi uinili).
7.1.2.1. Granularnost
injenice o poslovanju organizacije mogu se mjeriti na vie nivoa detalja. Na primjer,

najnii nivo u organizaciji koja se bavi prodajom, ini stavka porudbine. Najvii nivo jeste ista
poslovna dobit organizacije kao cjeline. Sve injenice u tabeli injenica moraju biti na istom
nivou detalja, poznatom kao granularnost (engl. grain) tabele injenica.
Opte pravilo glasi da tabela injenica treba da bude projektovana za najnii nivo detalja za
koji postoje podaci. U veini organizacija to e biti nivo pojedinane transakcije: stavka
porudbine ili iznos uplaen na raun, ili podignut s njega tj. najkraa akcija za koju postoje
podaci. Razlog je vjerovatno oigledan: uvijek se mogu izraunati zbirni podaci, ali je gotovo
nemogue raditi u suprotnom smjeru i razdvojiti podatke na manje jedinice.
Maloprodaja je dobar primjer problema. Donedavno veina sistema za podrku maloprodaji

svakodnevno je, nakon zatvaranja prodavnice, slala zbirne podatke u centralu: danas smo
126
prodali 16 kartonskih pakovanja, 36 staklenih pakovanja, 42 aluminijumska pakovanja itd. To

jesu korisni podaci, ali nisu dovoljni.
Ako se jedini podaci o prodaji koje imamo odnose na dnevne koliine prodate robe, ne
moemo obavljati ono to se uopeteno zove analiza potroake korpe tj. traenje odgovora
na pitanja poput: Koliko je ljudi koji su kupili mlijeko kupilo i hljeb?, to je izuzetno vano za
istraivanje trita.
Dakle, princip glasi da to je vea granularnost podataka, na vie se naina mogu analizirati i
utoliko su korisniji.
Granularnost moe postati problem ako injenice s kojima radimo potiu iz vie sistema, to
je sasvim uobiajena situacija. Primjera radi, pretpostavimo da pravimo tabelu injenica ija je
granularnost stavka porudbine; iz sistema za unoenje porudbina mogu se dobiti prodajna
cijena i popust po porudbini. Meutim, zar ne bi bilo korisno da ukljuimo i nabavne trokove
za svaki prodati artikal, da bi analitiarima omoguiji da izraunaju istu dobit?
Ideja je odlina, meutim, nikad neemo moi dobiti potpunu sliku svih trokova po
pojedinanom artiklu. U krajnjem, potpuna bi sluka morala da sadri elemente kao to su plata
generalnog direktora, a ak i kad bi ti podaci bili dostupni, bilo bi nemogue da ih tano
raspodijelimo po artiklima.
Poto je potpunu sliko nemogue dobiti, moramo, u dogovoru s krajnjim korisnicima,

odrediti neku upotrebljivu sliku. Veina organizacija ija je djelatnost prodaja ima svoju metodu
odreivanja trokova prodate robe (TPR) koju koristi za knjigovodstvene svrhe. To je dobra
polazna taka za analize. Meutim, vjerovatno emo ustanoviti da se TPR obraunava na nivou
cijele porudbine i da stoga nije prihvatljivo da trokove raspodjeljujemo tako da ukupan iznos
TPR podijelimo s brojem stavki porudbine.
Poto se korisnici dogovore o formuli za raspodjelu izdataka, vano je da ta formula bude

potpuno dokumentovana, kao metapodatak ili (to je jo bolje) kao atribut odgovarajue
dimenzije.
To je naroito vano ako se radi s vie pregradaka za podatke. Pod predgratkom za podatke
podrazumijevamo jednodimenzionalnu bazu podataka, a sasvim je uobiajeno da se vie
127
dimenzionalnih baza podataka koristi zajedno. Da bi to bilo mogue u svima moraju vaiti iste
formule za odrivanje vrijednosti, a tako e biti samo ako su one dokumentovane u pojedinanim
predracima za podatke.
7.1.2.2. Vrste tabela injenica
Dosad smo se bavili najeom vrstom tabele injenica, a to je ona koja modeluje poslovnu
transakciju. Tu strukturu zvaemo optim imenom tabela transakcija (engl. transaction table).
Postoji jo nekoliko drugih vanih vrsta koje trebamo poznaviti.
injenice koje predstavljaju odreena stanja tokom vremena gotovo uvijek pripadaju drugoj
vrsti tabele injenica, a to je tabela snimaka stanja (engl. snapshot table). Tabele snimaka
predstavljaju snimke stanja organizacije u odreenim trenucima. Ta vrsta tabela se koristi kad
god je potrebno mjerenje odreene vrijednosti koja se mijenja tokom vremena. Tabela snimaka
stanja moe se upotrebiti za mjerenje, na primjer, stanja na bankovnim raunima, stanja zaliha,
promjena prodajnih cijena, evidentiranje studenata na predavanjima, ak i za mjerenje
temperature u prostoriji. Obratimo panju na to da neke, ali ne i sve navedene injenice utiu na
transakcije na primjer, to vai za stanje zaliha, ali ne i za temperature. Kada vrijednosti
injenica zavise od transakcija, uobiajeno je da se u skladite za podatke ugradi i tabela snimaka
i tabela transakcija.
Razumije se, stanje na raunu u datom trenutku moe se izraunati na osnovu poetnog
stanja i evidentiranih transakcija; tako rade kljigovodstveni sistemi. Odravanje snimaka svih
promjena stanja troi prostor na disku, potencijalno ak i veoma mnogo prostora, ali
izraunavanje moe biti sloen i dugotrajan postupak, za koji su potrebne stotine moda ak i
milioni pojedinanih operacija. Treba imati u vidu da je prostor na disku jeftin a vrijeme
skupo.
Pomou specijalnog para tabela transakcija/tabela snimaka modeluju se aktivnosti u kojima

se novac uplauje unaprijed, kao to su to pretplate za asopise, premije za osiguranje, pretplate
za kablovsku televiziju ili neke vrste finansijskih transakcija na primjer, pozajmice.
Uobiajeno je da organizacije koje se bave tim vrstama djelatnosti unaprijed primaju uplate za
svoje usluge, ali ne poveavaju svoj prihod dok ne proe mjesec za koji su naplatile uslugu (ili
proizvod).
128
Osim tabela snimaka i transakcija, postoji jo jedna vrsta tabela injenica na koju emo
vjerovatno naii: tabela dogaaja (engl. coverage table). Ponekad je samo postojanje reda sa
odreenim skupom identifikatora dimenzija dovoljno da saznamo sve to nam treba ili ak sve
to moemo saznati jer drugih injenica prosto nema.
Tabele dogaaja, ponekad nazvane tabele injenica bez injenica, najee se koriste kao
pokazatelji da se neto dogodilo. Razliiti identifikatori dimenzija potpuno definiu dogaaj, a
samo postojanje reda dovoljno je da pokae da se dogaaj odigrao. Na primjer, tabela injenica
prikazana na slici 7.2. moe se upotrebiti za modelovanje prisustva predavanjima.
Prisustvo nastavi
Datum
ifra kolegijuma
ifra profesora
ifra studenta
Slika 7.2. Tabela dogaaj koja modeluje prisustvo predavanjima
Neki analitiari dodaju u strukturu ovakvih tabela dopunsku injenicu logikog tipa, koja
uvijek ima vrijednost True (istinito), kao na slici 7.3. To rjeenje opravdavaju time to
zahvaljujui dopunskoj injenici lake razumiju tabelu i lake rade s njom.
To rjeenje je upitno. Prvo, vrijednosti logikog tipa nisu ni numerike ni aditivne. Drugo,
postojanje vrijednosti True navodi na to da je mogua i vrijednost False, to nije tano.
Prisustvo nastavi
Datum
ifra kolegijuma
ifra profesora
ifra studenta
Prisutan
Slika 7.3. Tabela dogaaja s vjetakom injenicom logikog tipa
129
7.1.2.3. Heterogene injenice
U treem poglavlju bilo je rijei o upotrebi potklasa entiteta u normalizovanoj bazi podataka
kao metode za modelovanje entiteta koji se moraju obraivati i uopteno i kao zasebne vrste. Taj
problem se javlja i u dimenzionalnim bazama podataka. Rjeenje je slino, ali ne potpuno isto.
Postoji konvencija da se u projektovanju dimenzionalnih baza podataka koristi izraz heterogene
injenice.
Slika 7.4, izvedena iz primjera u poglavlju 3, prikazuje opte rjeenje u normalizovanoj bazi
podataka. Entitet Artikli sadri sve atribute koji su zajedniki za sve artikle, dok entiteti
specifini za pojedine kategorije artikala Pia, Slatkii itd. sadre atribute specifine za datu
kategoriju.Atribut KategorijaArtikla, dodat entitetu Artikal, omoguava da se na vrlo
jednostavan nain svaki zapis ili grupa zapisa obrauje ili kao opti Artikal ili kao pripadnik
odreene klase artikala.
Aplikacije koje rade s normalizovanim bazama esto obrauju entitete istovremeno na oba
nivoa. Na primjer, ekran za unoenje artikala morao bi da za svaki zapis iz tabele Artikli prikae
i opta polja specifina za kategoriju kojoj artikal pripada. Takav zahtjev je rijedak u
dimenzionalnim bazama podataka. U praksi, korisnici e analizirati podatke na optem nivou ili
na nivou pojedinane kategorije, ali ne oboje. Nastavljajui s primjenom artikala, analitiar e
htjeti da ima mogunost analiziranja svih artikala po kategorijama, ali ta analiza ne bi obuhvatila
nijedan detalj specifian za pojedine artikle. Slino tome, analitiar koji prouava prodaju
proizvoda iz kategorije Slatkii usredsredio bi se na tu kategoriju i ne bi mu trebali podaci o
Piima, niti o MlijenimProizvodima.
130
Artikli
ifra Artikla
Kategorija artikla
Pica Slatkisi Mlijecni proizvodi
ifra Artikla ifra Artikla ifra Artikla

Gazirano Vrsta pakovanja Procenat masnoce
Slika 7.4. Entitet sa potklasama iz normalizovane baze podataka
Zbog tih razliitih naina upotrebe, najbolje je izbjei potrebu za spajanjem tabela tako to
se napravi nezavisna tabela injenica i za opti tip i za svaku kategoriju, kao na slici 7.5.
Na ovoj slici potrebno je obratiti panju na dvije stvari. Prvo, injenice za koje je
najvjerovatnije da e biti upotrebljavane u analizama ponavljaju se i u optoj tabeli injenica i u
tabelama injenica za pojedine kategorije. Dupliranje tih injenica troi dodatan prostor na disku,
ali time se izbjegava potreba za spajanjem tabela, a rezultat je primjetno poboljanje
performansi.
Sljedea stvar na koju treba obratiti panju jeste da imamo zasebne tabele, ne samo za
injenice, ve i za dimenzije. To nije apsolutno neophodno. Ponekad se dogaa da dimenzija
koja predstavlja odreenu kategoriju nema nijedan atribut koji bi bio specifian za kategoriju, pa
zato svi atributi te dimenzije mogu ostati na optem nivou. U tom sluaju, nema svrhe duplirati
dimenziju.
131
Slika 7.5. Grupa tabela injenica koje predstavljaju heterogenu injenicu
Meutim, ei je sluaj da svaka kategorija ima dimenzijske atribute koje ne dijeli s drugim
kategorijama. U takvim sluajevima, efikasnije je rjeenje s vie tabela jer se tako izbjegavaju
veliki, veim dijelom prazni, dimenzijski zapisi.
Bez obzira na rjeenje za koje se opredijelimo, treba izbjegavati definisanje atributa pri radu
aplikacije, na primjer, Ako je TipArtikla = Pie, onda Atribut 1 = Gazirano; ako je TipArtikla
= Slatkionda Atribut 1 = VrstaPakovanja, i tome slino. Ponekad je mogue vidjeti da se ova
vrsta indirektnog definisanja eme pokazuje kao prihvatljivo rjeenje u transakcionim sistemima
kada su te sisteme projektovali i odravaju ih zaista struni ljudi. Ali ee se deava da se
sistem pretvori u veliku buktinju onog trenutka kada se promjeni zahtjev ili kada izvorni
projektant prestane raditi na projektu.
Naalost, malo je vjerovatno da e u analitikom sistemu indirektna ema nalik na opisanu

potrajati i neko krae vrijeme. Traei razlog tome, napominjemo da je jedan od glavnih ciljeva
zvjezdaste eme to da ona bude razumljiva krajnjem korisniku. Indirektna ema ne moe nikad
postii taj cilj.
132
7.1.3. Saetak
U ovom poglavlju prouavali smo strukture tabela injenica u dimenzionalnoj bazi podataka.
Vidjeli smo da se tabela injenica sastoji od dvije vrste atributa: kljueva dimenzija i injenica.
Kljuevi dimenzija su po strukturi i po funkciji slini spoljnim kljuevima u relacionom modelu
jer povezuju redove iz tabele injenica s redovima u tabelama dimenzija.
injenice sadrane u tabeli injenica predstavljaju vrijednosti koje se mjere za odreenu

kombinaciju vrijednosti dimenzija. Idealna injenica ima dvije osobine: numerikog je tipa i
potpuno je aditivna. Nenumerike injenice nisu obavezno neprihvatljive, ali ako naiemo na
jednu od njih treba dobro razmisliti da nije u pitanju zapravo preruena dimenzija.
Nenumerike injenice su, po definiciji, neaditivne. Mogu se prebrojavati ili sastavljati

njihove liste, ali se ne mogu sumirati ni na koji drugi nain. Potpuno aditivne injenice moemo
prebrojavati i praviti njihove liste, te sumirati po bilo kojoj dimenziji. Poluaditivne injenice su
numerikog tipa, ali se mogu sabirati samo po odreenim dimenzijama, ne i svim.
Granularnost tabele injenica je nivo detalja na kojem se evidentiraju injenice.

Preporuljivo je da uvijek koristimo to veu granularnost. to je vii nivo detalja, na vie se
naina mogu analizirati podaci. Moramo imati u vidu da nee svi izvorni podaci biti na
raspolaganju s jednakim nivoom detalja, a odreivanje formule za preslikavanje injenica vieg
nivoa na nie nivoe moe biti postupak u kome ponekad dolazi do sporova.
Postoje tri primarne vrste tabela injenica. Najuobiajenija je tabela transakcija, koja
modeluje transakcije kao to su stavke porudbina. Tabele transakcija se esto kombinuju s
tabelama snimaka stanja, koje mjere vrijednosti u odreenim trenucima tokom vremena.
Posljednja vrsta tabela je tabela dogaaja, koja moda nee imati nijedan injenini atribut.
Tabele dogaaja najee evidentiraju da li se odreeni dogaaj odigrao.
Razmotrili smo i obradu heterogenih injenica. Primjenom postupka koji je slian izradi
potklasa entiteta u relacionom modelu, heterogene injenice se obrauju pomou vie parova
tabela injenica/tabela dimenzija, jedan par na optem nivou i po jedan par za svaku kategoriju.
Za razliku od potklasa, heterogene injenice dupliraju osnovne injenice u svakoj tabeli
kategorije. Time se izbjegava potreba za spajanjem velikih tabela.
133
8. Tabele dimenzija
U izvjesnom smislu, tabele dimenzija su sline referentnim tabelama uobiajenim u

normalizovanim bazama podataka, ali uprkos povrnoj slinosti,tabele dimenzija imaju sasvim
drugu namjenu. Svrha referentnih tabela je da smanje dupliranje podataka i obezbjede njihovu
usklaenost. Tabele dimenzija predstavljaju osobine koje se mjere a mjera se uzima za datu
kombinaciju vrijednosti dimenzija. Iako tabele dimenzija mogu, kao sporednu korist, da smanje
veliinu tabele injenica i koliinu dupliranih podataka koje ona sadri, njihova primarna
namjena je da olakaju analize podataka. One su sredstvo koje analitiarima omoguava da iz
velikuh gomila podataka izdvajaju one koji im trebaju.
8.1.1. Struktura tabela dimenzija
Tipina tabela dimenzija je znatno ira od tabele injenica pa ak i od tipine tabele u

normalizovanoj bazi podataka. Dok veina tabela injenica ne sadri vie od tri do etiri
injenice, a normalizovane baze podataka s vie od 20 ili 30 atributa smatraju se sumnjivim,
uobiajene su tabele dimenzija s pedesetak atributa, a nisu nepoznate ni one sa 100 ili vie
atributa. U stvari, to je jedina situacija u koloj je opravdano prekoraenje granice od 255 polja
koju namee veina relacionih maina baza podataka.
Moda je najbolji primjer ove tvrdnje vremenska dimenzija koja je sastavni dio gotovo svake
tabele injenica i predstavlja, na primjer, datum transakcije ili datum snimka stanja. U izvornoj
(normalizovanoj) bazi podataka, polje za datum je obino samo jedan SQL datum. U
dimenzionalnoj bazi podataka, to jedno polje bie zamjenjeno vezom koja upuuje u tabelu
dimenzije koja sadri vie od desetak atributa. Tabela 8.1 prikazuje tipian primjer iz aplikacije
za podrku maloprodaje.
U ovom primjeru obratimo panju na vie stvari. Prvo, ako paljivije prouimo atribute,
uoiemo da oni pokuavaju da obezbjede direktnu podrku za svaku vrstu pitanja koja bi
analitiar mogao da postavi. Da li prodajemo, vie komada nekog artikla ponedjeljkom ili
srijedom? Da li vane sportske manifestacije utiu na prodaju, na primjer, kafe? Koji se artikli
najbolje prodaju poetkom i krajem mjeseca (uobiajeni dani isplata zarada)?
134
Tabela 8.1. Tipina vremenska dimenzija

Atribut Primjer
IdentifikatorDatuma 8302984
PuniDatum 14. jun 2004.
DanUSedmici "Srijeda"
DanUMjesecu 14
DanUGodini 166
KalendarskaGodina 2004
Tromjeseje "Drugo"
FiskalnaGodina 0304
FiskalniPeriod "2Tromjeseje"
Praznik FALSE
ImePraznika ""
RadniDan TRUE
NeradniDan FALSE
PoetakMjeseca FALSE
Sredina mjesec TRUE
KrajMjeseca FALSE
GodinjeDoba "Proljee"
PosebanDogaaj FALSE
ImeDogaaja ""
Drugo, stvarni SQL datum zamjenjen je vjetakim kljuem IdentifikatorDatuma. To je

vjerovatno manje vano u vremenskim dimenzijama nego, na primjer, na listama artikala, ali je
dobra praksa da sve kljueve koje izdvojimo iz izvornih podataka zamijenimo vjetakim
kljuevima koji nemaju nikakvo konkretno znaenje.
Glavni razlog za dodjeljivanje vjetakih kljueva jeste izolovanje dimenzionalne baze

podataka od izmjena vrijednosti kljueva u izvornom sistemu. Potpuno je nevano koliko strogo
administrator izvornog sistema insistira na tome da se vrijednosti kljueva ne smiju mijenjati. To
e se obavezno desiti. Poslije dovoljno dugog vremena upotrebe, izvorni sistem e izmjeniti
metodu formiranja kljueva, moda zato to je transakcioni metod zamjenjen drugim ili zato to
se organizacija spojila s drugom, ili samo zato to je administrator to elio.
Ili, jo gore, izvorni sistem koristi stare vrijednosti kljueva. To je potpuno prihvatljivo u
transakcionom sistemu u kome se stariji podaci o poslovanju organizacije smatraju nevanim.
135
Ali ponovna upotreba starih vrijednosti kljueva izazvala bi katastrofu u dimenzionalnoj bazi
podataka koja biljei istorijske podatke. Da li se polisa broj PL-3957 odnosi na ugovor o
osiguranju privatne imovine sklopljen s Markovi Milanom, ili na ugovor o osiguranju
poslovnog prostora skljopljen s fimom Faziprom 1999. godine? To se pitanje ne bi nikad
postavilo u transakcionom sistemu ali se moe pojaviti u dimenzionalnoj bazi podataka.
Dodatna vrijednost upotrebe vjetakih kljueva koje definie sama dimenzionalna baza
podataka, jeste to da moemo koristiti kratke i jasne vrijednosti generisane u samoj
dimenzionalnoj bazi umjesto podataka koje dobijemo iz izvornog sistema. To obino nije
neophodno, ali time moemo sebi obezbjediti dodatnu municiju ako doe do spora s nekim ko
ne razumije kako rade dimenzionalne baze podataka. (To se esto dogaa.)
Uzgred, obratimo panju na to da se izvorni SQL datum uva u tabeli dimenzija u atributu
PuniDatum. Razumije se da uvijek moramo sauvati izvornu vrijednost. Ponekad je zgodno
sauvati ime transakcionog sistema koji je dodijelio izvornu vrijednostr kao primarni klju. To je
korisno ako se sistemi mijenjaju ili se ponovo upotrebljavaju stare vrijednosti kljueva. (To
pitanje detaljnije emo razmotriti u nastavku poglavlja, kada budemo govorili o izmjenama
vrijednosti dimenzija.)
U tabeli 8.1, treba obratiti panju na to da je vie njenih atributa izraunato (ili se barem
moe izraunati) na osnovu jednog ili vie drugih atributa. Mjesec, DanUSedmici i
DanUMjesecu, na primjer, lako se mogu izraunati iz punog datuma. To bi bilo, razumije se,
krenje normalne forme kada bi u pitanju bila normalizovana baza podataka. Ali poto nije,
pravilo ne vai.
Treba imati u vidu da je najmena atributa u tabeli dimenzija da pojednostave upite. U praksi,
to esto znai da e se postojee vrijednosti prikazivati u obliku padajue liste na korisnikovom
ekranu. Ako na primjer uzmemo atribut Mjesec, popunjavanje padajue liste bila bi razlika
izmeu:
SELECT DINSTINCT Mjesec FROM Vrijeme;
Iz denormalizovane dimenzionalne eme i

SELECT DINSTINCT ImeMjeseca
FROM KalendarskaImena
INNER JOIN NormalizovanaDimenzija
ON KalendarskaImena . RedniBrojMjeseca = Mjesec (SQLDatum) ;
136
iz eme normalizovane baze podataka. ak i bez formalnog ispitivanja performansi,

najverovatnije je da bi prva verzija ovog iskaza radila znatno bre od druge. Poboljanje
performansi bie jo primjetnije kada se radi s vie dimenzija, kao to je to sluaj pri tipinoj
analizi podataka. Ne zaboravimo: prostor na disku je jeftin, vrijeme je skupo.
Slian princip objanjava postojanje para meusobno iskljuivih atributa, RadniDan i

NeradniDan. Tano je da ako zadamo
RadniDan <> False
dobiemo isti skup redova kao sa
NeradniDan = True
ali je ovo drugo razumljivije korisniku i lake e raditi s tim.
Sljedee na ta bi trebalo obratiti panju u tabeli 8.1 jeste to da nema skraenica. Skraenice
su vjerovatno sasvim razumljive ljudima iji se radni dan sastoji od prijema porudbina,
pakovanja i dostavljanja odreenih artikala, ali kao opis artikla u dimenzionalnoj bazi podataka
potpuno je neupotrebljivo.
Osim problema nerazumljivosti skraenice za korisnika, obratimo panju na to da je, na

primjer, PJ11 D BLA ustvari kombinacija vie razliitih podataka. Ta oznaka vjerovatno
opisuje da je u pitanju atrikal skraenog naziva PJ, model 11, dvostruke veliine i bijele boje.
Nema nieg pogrenog u ugraivanju svih tih podataka u jedno opisno polje, pod uslovom da se
ti podaci evidentiraju i pojedinano, svaki u svom polju, koja se mogu koristiti pri pretraivanju.
Bez obzira na to kakva je ema glavne tabele artikala, trebalo bi da dimenzija koja predstavlja
artikal bude neto nalik na tabelu 8.2.
Naalost, izvoenje takve lijepe, jasne i lako razumljive dimenzije iz bilo koje izvorne tabele
artikala, to je postupak nazvan struganje (engl. scrubbing), ne moe biti jednostavna radnja.
Gotovo je izvjesno da e biti potrebna ljudska intervencija, koja moe biti uzrok sporova.
137
Najvei problem na koji se moe naii jeste da odredimo ko je vlasnik tabele artikala ili
bilo koje druge dimenzije koju prouavamo. U primjeru liste artikala, vjerovatno ima vie slubi
koje polau pravo na vlasnitvo: Proizvodnja, Prodaja, Marketing, pa ak i Dostava, a mi emo
morati da ih tokom postupka struganja ubjedimo da usaglase svoje zahtjeve ili da zatraimo da
hijerarhijski vii autoritet presjee problem.
Suprotna situacija je kad imamo posla s niijom dimenzijom koju svi koriste, ali je niko ne
smatra svojom. Nije nimalo neuobiajeno da na pitanja u vezi s glavnom tabelom atrikala
dobijemo kao neodreene odgovore i diskusiju o tome kako vie sistema koristi istu tabelu
artikala. Takva situacija je zapravo povoljna za projekat dimenzionalne baze podataka. To znai
da dimenzionalna baza podataka moe da preuzme vlasnitvo nad glavnom tabelom artikala (ili
nad drugom dimenzijom), sastrue njen sadraj i zatim zabrani drugim sistemima svako
petljanje s tom tabelom.
Tabela 8.2. Dimenzija Artikal izvedena iz primjera prodatkog artikla

Atribut Primjer
IdentifikatorDatuma 10293810
KatalokiBroj "PJ11-378095X"
Kategorija "Posteljina"
NazivArtikla "Perjani jorgan"
ifraModela 11
Veliina "Dvostruki"
Boja "Bijela"
Opis "Dvostruki perjani jorgan, model 11"
138
8.1.2. Grananje
Trebalo bi obratiti panju na jo neto u vezi sa strukturama dimenzija prikazanim u

tabelama 8.1 i 8.2: one nisu normalizovane. Veze tipa jedan prema vie nisu izdvojene u
zasebne tabele kao to bi bile u normalizovanoj bazi podataka.
Na primjer, u dimenziji predstavljenoj tabelom 8.2 i slikom 8.1, gotovo je sigurno da u

Kategoriji Posteljina ima vie Artikala; izmeu ta dva atributa postoji veza tipa jedan prema
vie. Druge takve veze postoje izmeu Artikla i Modela, kao i izmeu Modela i Boje.
Artikli
Identifikator artikla
Kataloki broj
Kategorija
Naziv artikla
ifra modela
Velicina
Boja
Opis
Slika 8.1. Dimenzija Artikal
U normalizovanoj bazi podataka, sve veze tipa jedan prema vie bile bi normalizovane
kao zasebne tabele, kao na slici 8.2. Ta ema omoguava efikasniju upotrebu prostora na disku i
smanjuje vjerovatnou greaka pri unoenju podataka.
Kao to je to ve vie puta reeno, nijedan od tih problema ne pojavljuje se u dimenzionalnoj

bazi podataka. Cilj je da analitiari lako razumiju i koriste emu dimenzionalne baze podataka.
Normalizovanjem dimenzije, to se u dimenzionalnom projektovanju naziva grananje (engl.
snowflaking), ne postie se nijedan od tih ciljeva.
Ipak, postoji situacija u kojoj je grananje opravdano: kada postoji veza vie prema vie
izmeu dimenzije i tabele injenica. Ta situacija je prilino rijetka u dimenzionalnoj bazi
podataka. Veina veza tipa vie prema vie pojavljuje se izmeu dimenzija, ali u tom sluaju
tabela injenica igra ulogu spojne tabele koja te veze prepravlja u jedan prema vie.
139
Slika 8.2. Normalizovana verzija dimenzije Artikal prikazane na slici 8.1
Ponekad se pojavljuju veze tipa vie prema vie izmeu dimenzija i injenica, pa se one
slino takvim vezama u relacionim bazama podataka moraju prepraviti pomou spojne tabele.
Klasian primjer takve situacije jeste veza izmeu tabele injenica koja modeluje ljekarske
preglede i dimenzije koja modeluje dijagnoze. Poto tokom jednog pregleda doktor moe da
postavi dijagnoze za vie problema, veza tipa vie prema vie izmeu dimenzije i tabele
injenica mora se modelovati kao to je prikazano na slici 8.3.
Slika 8.3. Veza tipa vie prema vie izmeu dimenzije Dijagnoza i tabele injenica Pregledi
Prikazano rjeenje je vrlo slino emi u normalizovanoj bazi podataka, ali obratimo panju
na to da spojna tabela sadri atribut Teina, kojeg obino nema u normalizovanim bazama
podataka. Atribut Teina je numerika vrijednost ija je svrha da raspodjeljuje numerike
injenice kada se dimenzija Dijagnoze koristi u upitima.
Zbir vrijednosti atributa Teina za svaki pregled mora biti jednak 100. Tako, na primjer, ako
je pacijent bio na pregledu kod doktora zbog prehlade, ali je tokom pregleda doktor izmjenio i
140
doziranje ljekova protiv visokog pritiska, u tabelu DinagnozaPoPregledu bila bi unijeta dva
zapisa sa, na primjer, 80 procenata teine dodijeljen prahladi i 20 procenata za visok pritisak.
Ako bi zatim analitiar zatraio ukupan iznos naplaen pri pregledima u kojima je
postavljena dijagnoza visok pritisak (tj. u upitu je upotrebljena dimenzija Dijagnoze kao uslov za
ograniavanje razultata), u rezultatu upita bilo bi prikazano 20 procenata od iznosa naplaenog
pri pregledu dotinog pacijenta. Ako bi, s druge strane, nekome bili potrebni podaci o ukupnim
iznosima naplaenim pri pregledima osoba iz odreene kategorije kojoj pripada i dotini
pacijent, onda bi bilo prikazano svih 100 procenata naplaenog iznosa.
Problem sa ovim rjeenjem sada je vjerovatno oigledan: mali su izgledi da e teinska

raspodjela postojati ve u izvornom sistemu. Ako ne postoji, moramo sami smisliti neku
vjetaku teinsku raspodjelu (najee tako to emo svakoj stavci dodijeliti jednaku teinu) ili
moramo izmjeniti izvorni sistem. U naem primjeru, to bi znailo da zahtjevamo od doktora da
oni odreuju teinsku raspodjelu pri pregledima, to, naravno, nema smisla.
Nije uvijek oigledno da se veze tipa vie prema vie izmeu dimenzija i tabela injenica
ponekad mogu eliminisati podeavanjem granularnosti tabele injenica. U naem primjeru, kada
bismo granularnost izmjenili od pregleda u dijagnozu, nestala bi veza tipa vie prema vie.
Naalost time se ne eliminie problem raspodjele vrijednosti, ve se samo premjeta.

Umjesto da teine diodijeljujemo grupama dimenzija, iznose bismo dodjeljivali u tabeli
injenica, uz sve probleme koje smo opisali u prethodnom poglavlju.
Iz toga ne treba zakljuiti da nije vrijedno razmiljati o izmjeni granularnosti tabele injenica
da bi se eliminisala veza tima vie prema vie. Ponekad samo razmiljanje o problemu na
drugaiji nain moe da ga eliminie, ili barem da nas usmjeri ka rjeenju najteeg problema
raspodjele vrijednosti.
Kada projektujemo emu tradicionalne normalizovane baze podataka, postupak se esto

svodi na relativno jednostavno utvrivanje ta tano podaci znae, a potom na primjenu logiki
jasnih pravila da bi se dobila odgovarajua struktura podataka. Meutim, projektovanje
dimenzionalne baze podataka, uprkos njenoj jednostavnosti i predvidivoj fizikoj strukturi, esto
je sloen proces usklaivanja granularnosti tabele injenica s raspoloivim podacima, kao i
razvoj upotrebljivih i politiki prihvatljivih formula za raspodjelu vrijednosti.
141
8.1.3. Mijenjanje vrijednosti u tabelama dimenzija
U dosadanjem razmatranju tretirali smo tabele dimenzija kao da su uglavnom statine.

Naveli smo upotrebu vjetakih kljueva radi izolovanja podataka od izmjena, ali jo nismo
razmatrali naine obrade izmjena kada do njih doe. A naravno, izmjena e uvijek biti.
Kada se promjeni vrijednost nekog atributa u redu tabele dimenzija, imamo sljedee tri
osnovne mogunosti:
Moemo zamijeniti stare vrijednosti novim (i izgubiti istoriju),
Moemo dodati novi red (ime zadravamo sve istorijske podatke, ali komplikujemo
strukturu), ili
Moemo zadrati i poetne i tekue vrijednosti (i iszubiti sve vrijednosti izmeu
njih).
Zamjena starih vrijednosti novim najjednostavnija je tehnika za obradu izmjene vrijednosti u

tabeli dimenzija. To je tehnika koja se najee koristi u transakcionim bazama podataka u
kojima se obino evidentira samo tekue stanje entiteta. Meutim, dimenzionalne baze podataka
zanimaju istorijski trendovi, a u tom kontekstu jednostavna zamjena starih vrijednosti novim
izaziva probleme.
Na primjer, u martu 2004. godine Markovi Petar dodat je u dimenziju Kupac kao muka
osoba koja ivi u banjoj luci, Republika Srpska BiH, a u tabelu injenica dodat je iznos
kupovine od 175,35 KM, dodijeljen njegovoj ifraKupca. Aprila 2007. godine, adresa mu se
mijenja u Doboj, Republika Srpska BiH, i dodjeljuje mu se dopunski iznos kupovine od 153,97
KM.
Sistemu za unoenje porudbina nebitno je to da je dotini kupac nekad ivio u Banjoj Luci.
On samo eli da zna gdje da mu poalje raun. Ali ako se starije vrijednosti u dimenzionalnoj
bazi podataka zamjenjuju posljednjim, a neki analitiar 2008. godine zatrai zbir svih vrijednosti
porudbina koje su u posljednjih pet godina poslali stanovnici Doboja, sistem bi pogreno sabrao
onih 175,35 KM koje je kupac potroio dok je ivio u Banjoj Luci.
Recimo da dimenzionalnoj bazi podataka nisu bitne istorijske vrijednosti a mi moemo

slobodno da ih odbacimo ili zamjenimo tekuim. Jedini sluaj u kom se ta tehnika moe
142
slobodno primjeniti jeste kada su izvorne vrijednosti pogrene, na primjer, kupac nikad nije ivio
u Banjoj Luci. Problem je, razumije se, kako znati da li je razlog izmjene preuzete iz izvornog
sistema ispravka greke ili stvarna izmjena, budui da veina transakcionih sistema ne daje taj
podatak.
Rjeenje tog problema pitanje je poslovne politike. Moda emo moi prilagoditi izvorni
sistem, iako je to malo vjerovatno. Ponekad rukovodstvo kompanije prihvata razumne
pretpostavke svaka izmjena unijeta tokom odreenog perioda, na primjer, u roku od sadam
dana, smatra se ispravkom greke. Nakon toga, sistem je obrauje kao stvarnu izmjenu. U
najveem broju sluajeva, status izmjene moraemo runo da utvrdimo, u okviru postupka
struganja.
Ako smo utvrdili da je izmjena zapravo stvarna izmjena, a ne ispravka greke, moramo se
opredijeliti za jedan od druga dva naina njene obrade. Na izbor e zavisiti od toga ta podaci
znae i za ta se koriste. Uzgred, izbori nisu meusobno iskljuivi. Moemo se opedijeliti da
dodamo novi zapis kada se promijene vrijednosti u odreenim poljima, ali da upotrebimo par
izvorna/tekua vrijednost pri izmjenama drugih polja u istoj dimenziji.
Dodavanje novog reda kada doe do izmjene najmonije je rjeenje, ali zahtijeva da se
identifikator dimenzije proiri tako da se sastoji od opteg identifikatora i rednog broja. Na
primjer da bi se sauvao podatak da je Markovi Petar koji sada ivi u Doboju isti onaj
Markovi Petar koji je ranije ivio u Banjoj Luci, dimenzija bi dodijelila optu vrijednost
ifreKupca od, na primjer, 35972 i redni broj 1 adresi u Banjoj Luci, a redni broj 2 adresi u
Doboju. U svakom trenutku, puni dimenzionalni identifikator dotinog kupca bio bi 35972-x,
gdje je x tekui redni broj.
Da bi postupak pronalaenja najnovije vrijednosti bio to laki, neki analitiari koriste

proizvoljan broj, obino 999, kojim oznaavaju posljedni zapis. U tom sluaju, sistem bi prvo
dodijelio 999 adresi u Banjoj Luci, a nakon preseljenja, b+dodijelio bi 1 Banjoj Luci, a 999
Doboju. Pod uslovom da obezbjedimo da se to pravilo nee mijenjati, takvo rjeenje zaista
pojednostavljuje analize tekue vrijednosti.
Osim praenja izmjena, ponekad je potrebno znati i kad se desila izmjena. To se moe uraditi
na dva naina. Datum se moe uvati u tabeli dimenzije, to je korisno kada treba sauvati
istoriju izmjena odreenog dimenzionalnog entiteta ili pri izvravanju upita nad samom tabelom
143
dimenzije. Druga mogunost je da se u tabeli injenica uva i opti identifikator i njegov redni
broj, to tano i jednostavno reda injenice hronolokim redoslijedom.
Veina autora preporuuje ovo drugo rjeenje, mada oba rjeanja nisu meusobno iskljuiva.
Smatramo da ih je dobro kombinovati tako to emo datum izmjene uvati u tabeli dimenzije a
redni broj u tabeli injenica. Posljedni navedeni nain obrade izmjena koristi se kada su istorijski
podaci manje vani, a najbitnije je da istovremeno uvamo poetnu (ili prethodnu) i tekuu
vrijednost. Takva struktura bi, na primjer, lako davala odgovore na pitanja tipa Koliko se
kupaca iz Doboja tamo doselilo iz Banja Luke? Naravno da to ba nema smisla za prodajnu
djelatnost, ali moda ima smisla za praenje demografskih trendova na primjer, sistemi za
praenje irenja nekih bolesti postavljaju pitanja te vrste.
U organizacijama ija je djelatnost prodaja, ta tehnika se koristi za tzv. meke izmjene, kada
je stvarni datum nepouzdan podatak, a u odreenom vremenskom periodu moe se opravdano
pretpostaviti da nije bilo izmjena. Klasian primjer toga je sastav proizvoda. Proizvodnja XYZ
lijeka po novoj formuli B poela je prvog marta, ali u skladitu, u tranzitu i u maloprodaji
vjerovatno jo ima zaliha proizvedenih po formuli A. U veini organizacija, postojae izvjestan
period nepredvidive duine tokom kojeg XYZ lijek moe biti proizveden po jednoj ili po drugoj
formuli.
Jo jedan primjer. Pogledamo etikete na proizvodima na ijoj listi sastojaka stoji upozorenje
da moe sadravati kikiriki ili proizvode od kikirikija. Sastav tih proizvoda neznatno se
mijenja u svakoj ari, budui da se koristi biljno ulje ili ulje od kikirikija, u zavisnosti od
tekuih cijena tih sastojaka. To je vrsta situacije u kojoj moemo koristiti parove atributa
Tekua/Poetna ili Tekua/Prethodna da bismo pratili izmjene.
Meutim, takve situacije su rijetke. U stvarnosti, ee emo morati da traimo odgovore na

pitanja tipa da li mi to i to treba ili ne treba nego da donosimo odluke tipa kako da
evidentiram, a kada nam ovo drugo bude potrebno, iskustvo pokazuje da je izbor izmeu
dodavanja novog reda i upotrebe tehnike para tekui/prethodni, u praksi, oigledan.
144
8.1.4. Saetak
U ovom poglavlju razmatrali smo tabele dimenzija. Prouiji smo njihovu osnovnu strukturu i
vidjeli da je u praksi najbolje da svim dimenzijama dodamo vjetaki klju da bismo
dimenzionalnu bazu podataka izolovali od izmjena eme izvornih podataka.
Razmotrili smo i grananje dimenzionalne eme i ustanovili da je to korisno u potpuno istim

situacijama u kojima se prave potklase relacije u normalizovanoj bazi podataka.
Na kraju, razmotrili smo problem izmjena vrijednosti dimenzije i opisali dvije tehnike za
njihovu obradu: dodavanje novog reda, ili upotrebu dvije injenice koje predstavljaju tekuu i
prethodnu vrijednost.
Literatura
1. Chen P. P. S., 1996., The entity Relationship Model Toward a Unified View of Data?,
ACM TODS 1, No: 1
2. Codd, E.F., 1970., A Relational Model of Data for Large Shared Data Banks,
Communications of the ACM, No: 6
3. Codd, C. J. 1999, An Introduction to Database Systems. 7th Edition. Reading: Addison-
Wesley Publishing Company
4. Date, C. J. I Hugh Drawen, 1998. Foundation for Object/Relational Databases: The Third
Manifesto, Reading: Addison-Wesley Publishing Company
5. Date, C. J. Database In Depth Relational Theory for Practitioners, OReilly Media, CA,
Sebastolol
6. Elmasri R., Navathe S., 1989., Fundamentals of Database Systems, The Benjamin/Cummings
Publishing Company, Inc, Redwood City, USA
7. Mogin P., Lukovi I., Govedarica, M., 1996, Principi baza podataka, Fakultet tehnikih
nauka Novi Sad, Stylos, Novi Sad
8. Mogin P., Lukovi I., 2000, Principi projektovanja baza podataka, Fakultet tehnikih nauka
Novi Sad, Stylos, Novi Sad
9. Pavlovi/Laeti G., 2005, Uvod u relacione baze podataka, Matematiki fakultet, Beograd
10. Riordan, R. M., 2005., Designing Efective Database Systems, Addison-Wesley
11. Rob P., Coronel C., 2006, Database Systems: Design, Implementation and Management,
Course Technology.
12. www.amazon.com
13. www.database.about.com
145

Baze Podataka - Projektovanje

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Baze Podataka - Projektovanje

Uploaded by

Copyright:

Available Formats

Prof.

dr Rade Tanjga Baze podataka - Projektovanje

Akademska 2014-2015. godina

Prof. dr Rade Tanjga

Banja Luka, mart 2015.

4.1.4. Referencijalni integritet

1. Osnovni pojmovi baza podataka

1.1. ta je to baza podataka?

Terminologija baza podataka je prilino neodreena i u tom smislu podsjea na izraz

Sistem koji radi s bazom podataka

Aplikacija se sastoji od obrazaca (forms) i

Maina baze podataka nije sastavni dio baze

Baza podataka sadri fiziki oblik eme

ema baze podataka

Prostor problema je neki dobro definisan dio stvarnog

Slika 1.1. Terminologija relacionih baza podataka

Izraz baza podataka ne odnosi se na na aplikaciju koja se sastoji od obrazaca i izvjetaja s

Da bi se obuhvatile sve komponente aplikacija, baza podataka i maina baze podataka,

1.2. Alatke za rad s bazama podataka

Objektni model za pristupanje podacima

Maina baze podataka

Microsoft Jet SQL Server

Slika 1.2. Alatke za rad s bazama podataka koje se ovdje razmatraju

1.2.1. Maine baza podataka

1.2.2. Objektni modeli za pristupanje podacima

Objektni model za pristupanje podacima vrsta je ljepka izmeu okruenja za

1.2.3. Okruenja za definisanje podataka

1.2.4. Razvoj eone komponente aplikacije

1.3. Relacioni model

Relacioni model se zasniva na grupi matematikih principa izvedenih iz teorije skupova i

Razmotriemo i dimenzionalni model, to je specijalna vrsta relacione eme za skladitenje

Uproteno govorei, sistemi relacionih baza podataka imaju sljedee odlike:

U Microsoft Access terminologiji, relacija se prepoznaje kao skup zapisa (engl.

Model zahtijeva da podaci budu predstavljeni u obliku relacija samo na konceptualnom

1.4. Relaciona terminologija

Na slici 1.3. prikazana je relacija na kojoj su oznaena formalna imena osnovnih

Slika 1.3. Komponente relacije

Tabela 1.1: Relaciona terminologija

1.5. Model podataka

Najapstraktniji nivo projektovanja baze podataka jeste model podataka, to je konceptualni

Dogaaji predstavljeni glagolima kupiti i prodati takoe su entiteti, ali tu postoji

Odreivanje atributa koji e se ugraditi u model jeste semantiki postupak, to znai da se

Prva strategija: Krenimo od rezulteta i nemojmo praviti sloeniju strukturu nego to je

Razumije se, mora se voditi rauna i pokuati da se obezbjedi fleksibilnostkoja e pruiti

Jedan od zatitnih znakova dobrih projektanata jeste i temeljitost i kreativnost s kojima

Ako e namjena sistema koji projektujemo biti korespodencija, od kljune je vanosti da

Slika 1.4. Previe sloen ekran za unoenje adresa

Potrebno je imati u vidu da se mora napraviti kompromis izmeu fleksibilnosti i sloenosti.

Na primjer, malo je vjerovatno da e se adrese zaposlenih i kupaca koristiti na isti nain i za

Rekli smo na poetku da se u zaglavlju relacija nalaze parovi ImeAtributa:ImeDomena za

Razumije se da se ne mogu svi domeni definisati pojedinanim navoenjem prihvatljivih

Moe se pomisliti da je domen kombinacija tipa podataka i pravila za ispravnost podataka.

U navedenim definicijama pominje se vrsta podataka koji se evidentiraju (znakovni ili

ifraZaposlenog=FakturaTotal. Microsoftov Jet e nam sastaviti spisak zaposlenih ije su ifre

1.5.4. Veze/odnosi izmeu entiteta

Veze tipajedan prema vievjerovatno je najuobiajenija vrsta. Jedna faktura se sastoji od

1.5.5. Dijagrami entiteta i veza

dijagrami se sastoje od pravougaonika, koji predstavljaju entitete, elipsi, koje predstavljaju

Slika 1.5. Primjer E/R dijagrama

2. Struktura baze podataka

U ovom poglavlju prouiemo prvi aspekt projektovanja modela relacionih podataka:

2.1. Elimisanje redundantnosti

Redundantnost (engl. redundancy) rasipa resurse i, to je jo vanije, oteava rad s bazom