Fakultet prirodoslovnih znanosti i odgojnih podruja

Sveuilita u Splitu

Toni Dadi

BAZE PODATAKA

Split, 2002.

Sadraj:

UVOD..........................................................................................................................
1.1
to je baza podataka?.....................................................................................4
1.2
Vrste baza podataka........................................................................................7
1.2.1
Datotena baze podataka........................................................................7
1.2.2
Hijerarhijska baza podataka...................................................................8
1.2.3
Mrena baza podataka............................................................................9
1.2.4
Relacijska baza podataka.......................................................................9
1.2.5
Objektna baza podataka.........................................................................9

Relacijski model podataka........................................................................................

2.1
IS male knjiare............................................................................................12
2.2
Pojmovi relacijskog modela podataka..........................................................15
2.3
Relacijska algebra........................................................................................16
2.4
Coddova pravila...........................................................................................19
2.5
Ogranienja relacijskog modela...................................................................20
2.5.1
Ogranienja strukture...........................................................................20
2.5.2
Ogranienja ponaanja.........................................................................21
2.6
Normalizacija...............................................................................................22
2.6.1
Prva normalna forma............................................................................23
2.6.2
Druga normalna forma.........................................................................25
2.6.3
Trea normalna forma..........................................................................26
2.6.4
Boyce-Coddova normalna forma.........................................................27
2.6.5
etvrta normalna forma.......................................................................28
2.6.6
Peta normalna forma............................................................................29

ivotni ciklus baze podataka....................................................................................

3.1
Faze ivotnog ciklusa baze...........................................................................31
3.2
Vrste baza podataka......................................................................................33
3.3
Postupak oblikovanja baze podataka............................................................34
3.3.1
Izrada modela.......................................................................................34
3.3.2
Razliiti aspekti sustava.......................................................................35
3.3.3
Model entiteti veze............................................................................35
3.3.4
Veze......................................................................................................36
3.3.5
Rjeenje veze vie prema vie..............................................................39
3.3.6
Rekurzivna veza...................................................................................39
3.3.7
Uestalost pojedinih vrsta veza u realnim modelima...........................40
3.3.8
Atributi.................................................................................................40
3.3.9
Opcionalnost atributa...........................................................................41
3.3.10
Jedinstveni identifikator.......................................................................42

3
3.4
Videoteka - model praktinog primjera........................................................43
3.5
Model entiteti veze ( MS SQL Server 2000).............................................47
3.6
Funkcije ( metode )......................................................................................47
3.7
Impementacija objekata baze podataka primjer dviju tablica ( Microsoft
SQL Server 2000 ):...................................................................................................48
4

Indeksi.......................................................................................................................

SQL Upitni jezik........................................................................................................

5.1
Uvod.............................................................................................................54
5.2
Upiti u relacijskoj bazi podataka..................................................................54
5.2.1
Projekcija i restrikcija..........................................................................54
5.2.2
Prirodno spajanje..................................................................................57
5.2.3
Vanjsko ( Outer Join ) spajanje............................................................58
5.2.4
Unutranje ( Inner Join ) spajanje........................................................60
5.2.5
Funkcije u SQL Upitu..........................................................................60
5.2.6
Grupiranje podataka i sumarna izraunavanja.....................................64
5.2.7
ZbrojOcjena..........................................................................................67
5.2.8
Logiki sloeni uvjeti...........................................................................67
5.2.9
Pobrojane vrijednosti...........................................................................69
5.2.10
Ugnijeeni upiti..................................................................................69
5.3
SQL comande za definiciju objekata relacijske baze podataka...................74
5.3.1
Stvaranje, promjena i unitavanje tablice.............................................74
5.3.2
Stvaranje i unitavanje pogleda view-a.............................................77
5.3.3
Stvaranje indeksa.................................................................................78
5.3.4
Unitavanje indeksa..............................................................................79
5.4
Naredbe za upisivanje, promjenu i brisanje podataka..................................80
5.4.1
Upisivanje ( insertiranje ) retka............................................................80
5.4.2
Upisivanje svih kolona.........................................................................81
5.4.3
Upisivanje iz jedne tablice u drugu......................................................81
5.4.4
Pomjena podataka ( update )................................................................81
5.4.5
Promjena podataka tablice vrijednostima druge tablice.......................82
5.4.6
Brisanje ( delete ) retka........................................................................83

Literatura:.................................................................................................................

1 UVOD

1.1 to je baza podataka?

Intuitivno nam je jasno da su baze podataka sastavnica informacijskog sustava. Stoga
krenimo od definicije informacijskog sustava.
Informacijski sustav prikuplja, pohranjuje, uva, obrauje i isporuuje informacije
vane za pojedinca, organizaciju i drutvo, tako da budu dostupne i uporabljive za
svakog tko ih eli koristiti. Informacijski sustav aktivni je drutveni sustav koji moe,
ali ne mora, koristiti suvremenu informacijsku tehnologiju ( M. Varga, Baze
podataka, DRIP, Zagreb 1994).
Informacija je sirovina i proizvod informacijskog sustava.
Elementarna informacija je opis jednog obiljeja odreenog objekta ( S. Tkalac,
1993).
Informacija je novo znanje, koje primatelju donosi nove injenice. Ona ima karakter
novosti, otklanja neizvjesnost i slui kao podloga za odluivanje ( Birolla i dr., 1988).
Po svojoj prirodi, informacija je nematerijalna. Da bi ostala sauvana, treba je
materijalizirati, odnosno zapisati. Taj se zapis zove podatkom:
Podatak je skup prepoznatljivih znakova na odreenom mediju.
Obrnuto gledano, informacija je protumaeni podatak, koji primatelju donosi novost,
iju vrijednost on sam mora procijeniti ( M. Varga, Baze podataka, DRIP, 1994).
Informacijski sustav moemo podijeliti na sastavnice:
-

Sklopovsku podrku ( Hardware )

Programsku podrku ( Software )
Ljudske resurse ( Humanware )
Organizacijske metode i postupke ( Orgware )

Programska podrka se, pak, dijeli na sistemsku i primjenjenu ili aplikacijsku

programsku podrku. Nije jednostavno povui strogu granicu izmeu ove dvije vrste
programske opreme, no kaimo da sistemsku podrku sainjavaju programi koji
osiguravaju rad raunalnog sustava kao cjeline. Naime, raunalni hardver je prvi
proizvod stvoren ljudskim umom i rukama, koji je toliko univerzalan, da sam, bez
programske podrke, praktino nije ni od kakve koristi. Potrebano ga je instruirati,
mogli bismo kazati nauiti da obavlja koristan posao. U tom postupku instruiranja
hardvera, uoene su i podijeljene po kategorijama razliite vrste poslova. Tako,
raunalni hardver mora prepoznati pritiske na tipke tipkovnice, prikazati na opremi za
ispis, kao to su monitori, znakovne i slikovne poruke itd. Isto tako, raunalni hardver
se esto koristi za istovremeno izvoenje razliitih zadataka, te za pamenje podataka

5
u radnoj memoriji i vanjskim jedinicama za masovnu pohranu podataka. Kako e
raunalni hardver obaviti ovu vrtstu osnovnih poslova, instruira ga programska
podrka koju nazivamo operacijski sustav. Nadalje, rauanlni sustav koji obavlja gore
navedene poslove jo uvijek nija iskoristiv u svakodnevnom poslu, jer ljudima treba
pomo u obavljanju konkretnih, strogo definiranih poslova. Lepeza tih poslova je vrlo
iroka, a svaki pojedini posao trai strogo definirane postupke, pa proizvoai
raunalnih sustava, dakle hardvera i sistemske podrke nisu u stanju definirati sve
detalje aplikativnih postupaka. Njih definiraju, te instruiraju raunalo kako da ih
obavi, kreatori primjenjene ili aplikativne programske podrke. S druge pak strane,
ako bi kreatori aplikacije morali voditi rauna o svim detaljima rada raunalnog
sustava, kao spremanjem podataka na medije za masovnu pohranu, njihovim
pretraivanjem , ispisom na ekranske forme i izvjetaje, od silnog posla i
mnogobrojnih detalja koji moraju biti razraeni do najsitnijih potankosti, nebi imali
vremena i mogunosti usredotoiti se na sam problem koji rjeavaju. Osim toga,
edukacija ljudi koji bi morali znati sve, poev od rada hardvera do detalja, do
tehnolokog posla kojeg informatiziraju, uzela bi toliko vremena, da bi vjerojatno
uili do mirovine.
Pojasnimo to primjerom: elimo izraditi informacijski sustav koji bi automatizirao
rad studentske referade, od upisa studenta na fakultet, preko prijave i polaganja ispita,
do izdavanja diplome. Vjerojatno na svakom fakultetu u Hrvatskoj postoje razlike u
postupku prijave ispita. tovie, ak i na jednom fakultetu neke je ispite potrebno
prijaviti etiri dana ranije, radi rezerviranja dvorane za ispit, do organizacije putovanja
nastavnika iz drugog grada, dok se drugi ispiti, recimo iz izbornih predmeta, koje
slua svega nekoliko studenata, ispitni termin dogovara s nastavnikom i nije potrebana
rezervacija dvorane. Nadalje, postupak prijave ispita u Kini i Hrvatskoj se sigurno
razlikuje uzme li se u obzir broj studenata na sveuilitima.
Oito je, da nije mogue izraditi jedinstvenu aplikaciju u prihvatljivom vremenu i po
isplatljivoj cijeni, koja bi informatizirala rad studentske referade u Kini i Hrvatskoj. S
druge pak strane, spremanje podataka na magnetski medij trebaju kreatori aplikacija u
obje zemlje. Stoga je trite odredilo specijalizaciju poslova, pa je mogue proizvesti
identianu programsku podrku koja e spremati i pretraivati podatke, kako za
aplikaciju u Kini, tako i u Hrvatskoj. tovie, ljudi specijalizirani za poslove
spremanja podataka, toliko su uli u detalje tog problema, da ga mogu rijeiti bre i
bolje nego li bi mogao univerzalni programer, koji bi morao voditi rauna o svim
aspektima raunalnog sustava i tehnologije koja se automatizira. Nadalje, dobar
proizvod kojeg su napravili specijalisti, prodaje se s takvom tiraom da su njegvi
autori visoko stimulirani, a kupcima je cijena prihvatljiva. Nadalje, specijalizirani
opi posao spremanja podataka na magnetski medij trebaju kreatori razliitih
aplikacijskih programa, pa su tijekom vremena pronaeni presjeci poslova, koji su
identini svakoj aplikaciji tog tipa.
Prema izloenoj logici su nastali specijalizirani programi za obavljanje opih poslova
vezanih uz rad informacijskog sustava, te primjenjeni programi, koji koriste njihove
programske usluge i obavljaju poslove koje ljudi trebaju u konkretnom, strogo
odreenom poslu.
Iskustveno znamo da je ljudima znaajna informacija, koja mora biti prikazana na
podesan nain. Na primjer, zanima nas broj permutacija est znamenkastog broja
123456, ali esto nas ne zanima kako je rezultat izraunat, samo gotovi rezultat. Ako

6
e netko napraviti program za izraunavanje broja permutacija operaciju
faktorjel, on e to napraviti openito, recimo za izraunavanje broja faktorjela
Fakt(x), pri emu je x ulaz u program, koji e izraunati izlaz y i prikazati ga na
monitoru raunalnog sustava:
y = Fakt(x)
Dakle, program, bio on jednostavan ili sloen, na temelju ulaza izraunava izlaze.
Korisnike zanimaji izlazi, a da bi ih dobili moraju program snabdjedi traenim
ulazima. Program moe imati vei broj ulaza, te izraunati vei broj izlaza. Oznaimo
li s X skup svih ulaza, te s Y skup svih izlaza, program f transformira ulaze u izlaze:
Y = f(X)
Neki ulazi mogu biti zadani ad hock, neposredno prije izraunavanja izlaza, kao u
primjeru izraunavanja faktorjela. No, mnogo je ei sluaj kada izlazni odziv nije
mogue dobiti odmah. Pretpostavimo da traimo posao preko interneta. Jedan mogui
pristup je: prijavimo se u neki chat-room i unesemo poruku:
Zovem se Toni, traim posao programera na dot.net platformi u programskom jeziku
C# itd.
Nakon nekoliko sekundi poruka bi nestala s ekrana i trebali bismo je ponoviti svako
nekog vremena. Vrlo nepraktino i s minimalnim izgledima na uspjeh, jer je malo
vjerojatno da e se u isto vrijeme u istom chat-roomu nai i osoba iz tvrtke koja
trai ovjeka sa znanjem dot.net i C#, a sigurno je danas to traena specijalnost.
Mnogo prikladniji nain traenja angamana je ako moemo pohraniti podatke o sebi
i svom znanju, te da oni budu na raspolaganju onima koji trebaju programere, tako
dugo dok naa potraga traje. U ovom sluaju, program e generirati izlaze na temelju
dvije vrste ulaza:
- ranije unijetih i pohranjenih ( podaci nae ponude )
- zadanih neposredno prije izvoenja programa ( podaci potrage )
Oznaimo li s X skup ulaznih podataka kod izvoenja programa, sa Z skup ranije
unijetihi pohranjenih ( perzistentnih ) ulaza, izlazni podaci Y e biti generirani
transformacijom ulaza X i Z:
Y = f( X, Z )
Bazu podataka moemo shvatiti kao elektronsko skladite za pohranu podataka, koji
e biti koriteni kao programski ulazi s odgodom. Kako je mogue predvidjeti i
generalizirati poslove spremanja te pretraivanja pohranjenih ulaznih podataka, to je
bilo mogue kreirati programski sustav za obavljanje ovih poslova. U poetku je
kreator aplikacije koristio unaprijed napravljene programe koji su zapisivali i itali
podatke na magnetski medij u obliku datoteka. Ove usluge su stavljali na raspolaganje
operacijski sustavi. Kreator aplikacije je morao voditi rauna o zapisivanju i itanju
svakog pojedinog znaka. Vremenom su stvoreni specijalizirani programi za
upravljanje elektronskim skladitem podataka.

7
Vjerojatno je svatko od nas koristio usluge garderobe na putovanjima. Osoblje
garderobe prima od nas prtljag na pultu, sprema ga na police, izdaje nam potvrdu i
kod podizanja prtljaga vrlo brzo ga pronae i izrui. Uoio sam da u velikim
garderobama pitaju putnike: Kada ete podii?. Odgovorio sam Za 2-3 sta. Onda
su moj prtljag stavili na policu sasvim blizu primopredajnog pulta. Ja im nita nisam
govorio o tome kako i gdje e spremiti moje putne torbe. Jedna dama je kazala, kako
e trebati svoj prtljag tek za 7 dana, pa su njen spremili na udaljenu policu, na samom
kraju skladita. Zakljuio sam kako oni vode rauna o spremanju prtljaga, a mi im
samo kaemo to trebamo.
Na slian nain rade i sustavi za upravljanje bazom - elektronskim skladitem
podataka. Kreator aplikacije im preda podatke na pultu, oni ih spreme i sami vode
rauna o organizaciji podataka, kako bi ih brzo pronali, te nam ih ponovno predaju
na pultu kada ih trebamo. tovie, iste spremljene podatke mogu transformirati i
predati nam u razliitim oblicima, poredane na jedan ili drugi nain, ba kako ih u
datom momentu zahtijevamo.
Baza podataka je elektronsko skladite podataka zapisanih na mediju za
masovnu pohranu, pri emu su podaci tako organizirani da se lako i brzo
pronau i to u onom opsegu koji zadovoljava postavljeni kriterij, te prezentiraju
u pogodnom obliku. Spremanjem, pronalaenjem i sortiranjem podataka
upravlja poseban programski sustav: DBMS ( database management system).
Karakteristika baze podataka je:
1. velika koliina podataka
2. znatan broj dnevnih promjena
3. razliite razine izvjetaja, kao:
- detaljni podaci
- sumarni podaci
- izraunati podaci

1.2 Vrste baza podataka

Prema stupnju usluge u smislu spremanja, odravanja, itanja i pretraivanja podataka
koju kreator aplikacije dobija od ugraene programske opreme, te nainu organizacije
podataka, baze moemo podijeliti na datotene, hijerarhijske, mrene, relacijske i
objektne.

1.2.1 Datotena baze podataka

Najstarije baze podataka koristile su datoteni sustav i to:
- sa sekvencijalnim pristupom
- sa sluajnim pristupom
Osnovna karakteristika datotenih baza je, da je sustav za upravljanje datotekama
kreatoru aplikacije pruao vrlo skromnu uslugu. U pravilu, kreiranje i unitavanje
datoteke, te pisanje i itanje. Kreator aplikacije je morao voditi rauna o poloaju

8
svakog znaka na disku. Najee se podacima pristupalo prema apsolutnom poloaju
na disku.
Naroite potekoe kod velikih datoteka, zadavalo je pretraivanje podataka, koje je u
pravilu radilo sporo, a programeri su morali utroiti znaajno vrijeme i napr da ope
implementiraju pretraivanje. Dakle, glavni napor programera bio je usredotoen na
organizaciju podataka na disku i izradu procedura za spremanje, itanje, te
pretraivanje zapisa slogova podataka. Problemi bi tek dolazili s odravanjem i
potrebom naknadnih modifikacija. Dodavanje jednog polja zahtijevalo je pomicanje
slogova, te izmjenu cijelih aplikacija koje sa slogom rade, jer je poloaj svakog polja
bio odreen apsolutnom pozijom kao npr.: Ime studenta poinje s 35. byte-om sloga i
zavrava na 64 poziciji.
Kako su programeri imali potpunu slobodu u organizaciji podataka, to je praktino
svaka aplikacija, ak i unutar jedne tvrtke, bila inkompatibilna s drugima. O
povezivanju aplikacija koje rade na razliitim sustavima, nije se moglo ni sanjati.

1.2.2 Hijerarhijska baza podataka

Hijerarhijski model podataka nastao je ezdesetih godina, nakon to je IBM razvio
sustav za upravljanje hijerarhijskom bazom IMS/VS, 1968. IMS je razvijen pod MVS
operacijskim sustavom za mainframe raunala. Element zapisa podatka je polje
(field), pri emu skup polja koji opisuju isti objekt ini slog ili rekord. Slogovi su u
odnosu roditelj dijete, pri emu niti jedan slog ne moe postojati kao dijete, ako za
njega ne postoji roditeljski vor. Podaci hijerarhiskog modela se organiziraju u stablo:

Poduzee
Zaposlenik: Ante Ivi
Zaposlenik:Ivan Peri 1946
Zaposlenik: Ana Peri 1949

1958

Child-twin pokaziva

Dijete : Ivo Ivi 1980

Dijete: Hrvoje Peri 1981
Dijete: Ana Ivi
1980
Hijerarhijske veze, te veze roditelj dijete realiziraju se hijerarhijskim i Child-twin
pokazivaima.

1.2.3 Mrena baza podataka

9
Mreni model podataka nastao je unapreenjem hijerarhiskog modela. Uoavamo da
zaposlenici Ivan i Ana Peri mogu biti suprunici, te u tom sluaju dijete Hrvoje
Peri moe biti dijete kako Ivana, tako i Ane Peri:

Zaposlenik:Ivan Peri 1946

Zaposlenik:Ana Peri 1946

Dijete: Hrvoje Peri 1981

Mreni model implementira mogunost pripadnosti jednog vora u hijerarhiji veem
broju nadreenih vorova. Jednako tako, svaki roditeljski vor moe imati vie djece.
Veze isprepletene na ovaj nain tvore mreu, po emu je mreni model dobio ime.

1.2.4 Relacijska baza podataka

Programski sustav za upravljanje relacijskom bazom podataka RDBMS ( Relational
database management system) nastao je kao implementacija pravila relacijskog
modela podataka, koje je definirao Codd 1971. godine. Naravno, tijekom vremena,
kako je raslo iskustvo i uoavane potebe, RDBMS je evoluirao, te danas postoje na
tritu programska rjeenja koja omoguuju pridravanje svih pravila relacijskog
modela, a da istovremeno odzivna vremena budu zadovoljavajua, sve
nestrpljivijim pretraiteljima baza. Isto tako, cijena programske opreme, iskazana u
$/transakciji ( provedenoj operaciji ) za cjelokupnu instalaciju je sasvim prihvatljiva.
Relacijski model je skup pravila koji mora biti zadovoljen kod projektiranja baze
podataka. Isto tako, Codd je definirao operacije nad relacijskim modelmom, koje
kasnije implementira upitni jezik SQL ( Structured Query Language). Uspjeh
relacijskog modela lei u injenici njegove utemeljenosti na dva dobro definirana
podruja matematike: teoriji skupova i matematike logike.

1.2.5 Objektna baza podataka

U posljednjem desetljeu je objektni pristup promatranja i analize aplikacijskih
zadataka, te oblikovanja programskih rjeenja, istisnuo raniji proceduralni pristup.
Glavna razlika ova dva pristupa proizlazi iz injenice, da su u realnom svijetu objekti
opisani svojim atributima, te znaju izvravati odreene metode. Proceduralni pristup
nas ui da usredotoimo svoju panju na niz koraka kojima se rjeava programski
problem. Nasuprot tome, objektni pristup upuuje koncentraciju kreatora objektnog
modela na atribute i metode objekata iz realnog okruenja. Dakle, objektni pristup je
blii miljenju u realnom svijetu, gdje objekti surauju jedan s drugim, pri emu je
vano suelje njihove interakcije, a manje su vani mehanizmi koji transformiraju
ulazne podraaje u izlazne reakcije.

10
Oslikajmo gornju ideju primjerom: na ulicama New York-a ve dvadesetih godina
prolog stoljea su bili postavljeni automati za automatsku prodaju osvjeavajuih
pia ( i duhanskih proizvode, koji su jako tetni po ljudsko zdravlje, no to tada njihova
prodaja na ovaj nain, nije bila zabranjena ). Automat komunicira s kupcem preko
tipki za izbor pia, te prozora za ubacivanje i povrat novca. Automati koriteni prije
80 godina su bili potpuno mehanike naprave, a dananji koriste mikroraunala. No
kupcu je svejedno, jer suelje preko kojeg komunicira s automatom je praktino
nepromijenjeno svih ovih godina: uvijek je to tipka sa slikom i natpisom pia koje
naruuje.
Ideja objektno oblikovanog programa lei u dobro definiranom suelju preko kojeg
poziva snabdjeva programski objekt ulazima i od njega dobija izlaze. Procedura
obrade ostaje skrivena unutar pozvanog objekta. Upravo izreeno, zapravo je ideja
strukturnog programiranja, jedino objektni model donosi dobro definiran odnos meu
objektima, poboljava komunikaciju meu objektima preko interfejsa, te to je
najvanije, programske prevoditelje koji implementiraju objektni programski model.
Objektni pristup unapreuje timsku izradu softvera, te poveava mogunost ponovne
upotrebe ve napisanog koda ( eng. reusebility ).
Karakteristike objektnog programskog model su:
Enkapsulacija program poziva ( klijent ) pristupa pozvanoj strukturi (posluitelju)
iskljuivo preko svojstava ( property ) programskog suelja, te pozivom izloenih
metoda. Drugim rijeima, neke varijable i procedure posluiteljskog objekta su
dostupne pozivau, dok su druge skrivene. Kreator posluiteljskog objekta u
potpunosti kontrolira prava pristupa.
Nasljeivanje ( Inheritance ) objekti se nalaze u jednom od dva mogua odnosa:
-

jedna vrsta od ( a kind of )

jedan dio od ( a part of )

Pojasnimo primjerom: Osoba je opisana imenom, prezimenom i datumom roenja.

Student je jedna vrsta osobe, pa prema tome ima sve znaajke osobe, ali povrh toga je
njegova znaajka godina studija koju pohaa. Zaposlenik je isto tako osoba, koji
dodatno ima atribute: datum zaposlenja i plaa. Umirovljenik je osoba, iji je
specifian atribut iznos mirovine ( drukija poreska optereenja u odnosu na plau
zaposlenika ).
U objektnom programskom modelu se definira prototip klasa Osoba, s atributima
ime, prezime i godina rodjenja. Zatim klasa Student nasljeuje sva svojstva osobe i
njima dodaje specifinost studenta godina studija. Shodno tome, Zaposlenik
nasljeuje svojstva Osobe i dodaje datum zaposlenja i plau, dok Umirovljenik
nasljeuje svojstva Osobe i dodaje mirovinu. Naravno, mogue je da netko studira
uz rad, pa bi objekt ZaposleniStudent nasljedio svojstva Zaposlenika i Studenta.
Dobitak ovakovog pristupa se iskazuje i tijekom razvoja klasa i tijekom odravanja.
Naprimjer, ako klasa Osoba podrava metodu Godine starosti na dan, uz ulazni
parametar Datum, onda se metoda implementira samo jednom, a koristi kod
izraunavanja godina starosti u svakoj od nasljeenih klasa. Dodatno, naslijeene

11
klase mogu neke metode polaznih klasa nadjaati, pa se istim pozivom, zapravo
odrauje druga metoda specifina toj klasi.
Polimorfizam ( Polymorphism) sposobnost koritenja istog izraza za izvoenje
razliitih operacija. Osnov ovog svojstva je poznat od najranijih programa. Zbrajamo
li cijele brojeve, to se obavlja drukijom metodom, nego kad zbrajamo brojeve u
tekuem zarezu. Objektno programiranje je dosljedno, pa kreator klase odreuje nain
izvravanja izraza. Uzmimo na primjer klasu Boje. Poznato je da mijeanjem npr. ute
i plave boje dobijemo zelenu. Klasa boje moe promijeniti znaenje operatora plus (+)
i dati kao rezultat zelenu boju, kad god se zbrajaju uta i plava.
Poruke ( Messages) Objekti komuniciraje putem poruka. Najee se implementira
kao pridjeljivanje vrijednosti svojstvima ( set get property) i funkcijskim pozivima.
Postojanost ( Persistence) - Gore izreena svojstva odnose se na paradigmu objektog
programiranja. Objektna baza mora implementirati gornja svojstva, ali isto tako
implementirati svojstvo postojanosti ( perzistencije) velike koliine podataka. Dakle,
zapisati, itati i pretraivati vrijednosti atributa svake instance objekta na mediju za
masovnu pohranu podataka.
Koliko je autoru ovih redaka poznato, za sada ne postoji stroga, formlno prohvaena
definicija objektne baze. Dodue, mnogi proivoai sustava za upravljanje bazom
podataka tvrde da su njihove baze objektne, ali je teko ii u ocjenu opravdanosti
takva naziva, dok se ne prihvati formalna definicija to je objektna baza.

12

2 Relacijski model podataka

Osnovne principe i strukturu relacijskog modela podataka iznio je 1971. matematiar
E.F. Codd, u to vrijeme lan IBM San Jose Research Laboratory. Najvea prednost
relacijskog modela podataka je njegova utemeljenost na matematikoj teoriji
relacijske algebre ( R. Vujnovi: SQL i relacijski model podataka, Znak 1995.).
Prije iznoenja definicija i pravila relacijske algebre, najprije krenimo s primjerom, na
kome emo ilustrirati maljkavosti mogueg rjeenja, koje se otklanjaju primjenom
relacijskih pravila.

2.1 IS male knjiare

Kako je reeno u definicijama informacijskog sustava i baze podataka, nije nuno da
informacijski sustav bude podran informacjskom tehnologijom. Pretpostavimo
potrebu informacijskog sustava, dakle odreenog ustroja, zapisivanja i koritenja
informacija male trgovine knjigama. Raspoloivih naslova je tako mali broj, da se sve
pregledno i bez napora moe voditi olovkom na papiru.
Knjiara FOKUS prodaje mali broj naslova razliitih izdavaa. Svaki naslov je
tiskan od strane samo jednog izdavaa, ali jedan izdava moe izdati vie naslova. IS
mora raspolagati adresnim podacima izdavaa, radi odravanja kontakata, potom i
telefonom.
Naslov je napisan od strane jednog ili vie autora. Potrebano je raspolagati podacima
o autoru kao to su Ime i Prezime.
Luka, vlasnik i prodava u knjiari, je na papiru napravio tablicu i pregledno unio
slijedee podatke:
Tablica:Knjige1
Red.
broj Naslov
1
2
3

Baze podataka
SQL i relacijski
model podataka

ORACLE 7
Dalmatinska
kuhinja

Dalmatinski kolai

Izdava Pota Mjesto

Ulica i kbr

Telefon

Autori
Mladen
DRIP
10000 ZAGREB Ilica 121
01/123-456 Varga
01/413Ratko
ZNAK
10000 ZAGREB Vukovarska 56 8567
Vujnovi
01/413ZNAK
10000 ZAGREB Vukovarska 56 8567
Darko Hreni
021/345- Ankica Bilu,
LOGOS 21000 SPLIT
Narodni trg 4 678
Marija Rode
021/345- Ankica Bilu,
LOGOS 21000 SPLIT
Narodni trg 4 678
Tanja Kesi

Luka prve probleme uoava nakon saznanja da je ZNAK preselio na novu adresu:
Maksimirska 161, te da je izmijenjeni telefonski broj: 01/656-7879. Morao bi u
svakom retku, gdje se pojavljuju ove informacije o izdavau ZNAK, mijenjati. im bi
knjiara prodavala vei broj Znakovih naslova, Luka bi uoio maljkavost svog modela
podataka, jer bi morao u mnogo redaka brisati stare i upisivati nove podatke.

13

Luka ocjenjuje svoj model podataka:

Nedostatak: isti podatak o izdavaima je zapisan vie puta, to ga izluuje kod
izmjena podataka. Ve mu je na vrh glave brisanja i upisivanja potpuno istog podatka
u mnogo redaka. Stoga zakljuuje:
podijelit u jedinstvenu tablicu Knjige1 u dvije: Knjige2 i Izdavai2, tako da svi
podaci o izdavau budu napisani samo jednom, pa e izmjenu adrsnih podataka
izdavaa, morati mijenjati na samo jednom mjestu.
Prednost: Sve informacije o jednoj knjizi su lako dostupne, im se pronae knjiga,
odmah moe proitati izdava i autore.
Tablica:Knjige2
Red.
broj
1
2
3
4
5

Naslov
Baze podataka
SQL i relacijski model podataka
ORACLE 7

Izdava
DRIP
ZNAK
ZNAK

Dalmatinska kuhinja
Dalmatinski kolai

LOGOS
LOGOS

Tablica: Izdavai2
Izdava Pota
DRIP
ZNAK
LOGOS

10000
10000
21000

Mjesto
ZAGREB
ZAGREB
SPLIT

Ulica i kbr
Ilica 121
Vukovarska 56
Narodni trg 4

Autori
Mladen Varga
Ratko Vujnovi
Darko Hreni
Ankica Bilu, Marija
Rode
Ankica Bilu, Tanja Kesi

Telefon
01/123-456
01/413-8567
021/345-678

Nadalje, Luka uoava da je mjesto odmah jednoznano odreeno, im je poznat

potanski broj, dakle 10000 je ZAGREB, a 21000 SPLIT, pa odluuje utedjeti papir i
napraviti novu tablicu Pote, te iz tablice Izdavai ukloniti kolonu Mjesto.
Tablica:Knjige3
Red.
broj
1
2
3
4
5

Naslov
Baze podataka
SQL i relacijski model podataka
ORACLE 7

Izdava
DRIP
ZNAK
ZNAK

Dalmatinska kuhinja
Dalmatinski kolai

LOGOS
LOGOS

Tablica: Izdavai3
Izdava Pota
DRIP
ZNAK
LOGOS

10000
10000
21000

Tablica Pote3:

Ulica i kbr
Ilica 121
Vukovarska 56
Narodni trg 4

Telefon
01/123-456
01/413-8567
021/345-678

Autori
Mladen Varga
Ratko Vujnovi
Darko Hreni
Ankica Bilu, Marija
Rode
Ankica Bilu, Tanja Kesi

14
Pota
10000
10000
21000

Mjesto
ZAGREB
ZAGREB
SPLIT

Luki se ovo rjeenje inilo dobro, sve dok nije odluio tiskati prospekt o knjigama
koje prodaje. Naime, u prospektu je trebao ispisati bibliografske podatke o svim
autorima koji su napisali knjige. Uoio je veliki problem kod knjiga to su ih napisala
dva ili vie autora, te ponavljanje bibliografskih podataka autora u svakom retku. Isto
tako, jedan autor je mogao napisati vie knjiga za razliite izdavae, s razliitim
koautorima. Nije bilo druge, nego iz tablice knjige izdvojiti kolonu autori, a da ne
izgubi vezu izmeu autora i knjiga, napraviti posebnu tablicu u koju e upisivati samo
identifikaciju autora i knjiga. Kako su knjigu istog naslova, npr. SQL, mogli izdati
razliiti izdavai, odlui knjigu identificirati naslovom i nazivom izdavaa:
Tablica:Knjige4
Red.
broj
Naslov
1
Baze podataka
2
SQL i relacijski model podataka
3
ORACLE 7
4
Dalmatinska kuhinja
5
Dalmatinski kolai
Tablica: Izdavai4
Izdava
Pota
DRIP
10000
ZNAK
10000
LOGOS 21000

Ulica i kbr
Ilica 121
Vukovarska 56
Narodni trg 4

Izdava
DRIP
ZNAK
ZNAK
LOGOS
LOGOS
Telefon
01/123-456
01/413-8567
021/345-678

Tablica Pote4:
Pota
Mjesto
10000
ZAGREB
10000
ZAGREB
21000
SPLIT
Tablica: Autori4
Ime
Mladen
Ratko
Darko
Ankica
Marija
Tanja

Prezime
Varga
Vojnovi
Hreni
Bilu
Rode
Kesi

Datum roenja

15
Tablica: Knjige_Autori4
Red. broj Naslov
Izdava
1
Baze podataka
DRIP
SQL i relacijski
2
model podataka
ZNAK
3
ORACLE 7
ZNAK
4
Dalmatinska kuhinja LOGOS
4
Dalmatinska kuhinja LOGOS
5
Dalmatinski kolai LOGOS
5
Dalmatinski kolai LOGOS

Autor_ime
Mladen
Ratko
Darko
Ankica
Marija
Ankica
Tanja

Autor_prezime
Varga
Vujnovi
Hreni
Bilu
Rode
Bilu
Kesi

Na kraju, Luka uoava da bi znaajno tedio papir i trud oko upisivanja u tablicu
Knjige_Autori4, ako bi tablicu povezao s Knjige4 sluei se rednim brojem knjige.
Naalost, prednost polazne tablice Knjige1, da svi podaci o knjizi budu pregledni i
lako dostupni vie nije ouvana. Sreom, raunalo moe obavito ovo povezivanje
brzo i lako, te je Luka odluio nauiti pravila relacijskog modela i upotrijebiti
programski sustav za upravljanje relacijskom bazom.

2.2 Pojmovi relacijskog modela podataka

Entitet je sve ono o emu elimo i moemo skupljati informacije i ije se pojave
mogu meusobno razlikovati ( identificirati).
Tako na primjer, studenti jesu entitet jer razlikujemo svakog studenta imenom,
prezimenom, datumom roenja. Kamenii na pjeanoj plai nisu entitet, jer ne
moemo razlikovati svakog od njih.
( Rije entitet posuena je iz latinskog jezike i znai: ens = bie, summ = jesam,
esse=biti, i znai bitnost, ono to jest)
Neki autori razlikuju pojmove entitet i tip entiteteta, smatrajui svaku pojavu objekta
entitetom, a prototipsku definiciju klasu - tipom. Tako je Ivo Ivi, roen 22.06.1981.
entitet, a prototip ime, prezime, datum roenja tip entiteta.
Atribut opisuje svojstva entiteta. Svaki entitet opisan je skupom atributa. Tako je
osoba opisana imenom, prezimenom, datumom roenja. Svaki atribut moe primiti
jednu vrijednost: ime=Ivo, prezime=Ivi, datum roenja=22.06.1981.
Domena je imenovani skup svih moguih ( doputenih ) vrijednosti jednog atributa.
Oito su onda mogue pojave entiteta Kartezijev produkt svih domena.
Tako Hrvatska pota katalogizira potanske brojeva u Hrvatskoj, dakle definira
domenu potanskih brojeva, a Dravni sabor je donio Zakon o registraciji trgovakih
drutava, definirajui mogue djelatnosti koje ova mogu obavljati, dakle domenu
djelatnosti.
Odgovor na pitanje: koje djelatnosti mogu biti obavljane u mjestima Hrvatske (svako
mjesto za razliku od naselja ima potanski broj) emo potraiti u Kartezijevom
produktu pota i djelatnosti, jer koliko je meni poznato, svaka djelatnost zakonski

16
moe biti obavljana u svakom mjestu. Naravno da skup postojeih pota i djelatnosti
predstavlja podskup Kartezijevog produkta.
Relacija je imenovani podskup Kartezijevog produkta domena:
Neka su Di domene atributa Ai, te neka su di elementi domene Di. Tada je relacija R
podskup Di x Dj, pri emu je i, j=1,2,3 n & i <> j, gdje je n broj atributa entiteta.
Relacijska shem R sastoji se od naziva relacije i konanog skupa (naziva) atributa
odnosno stupaca ( A1, A2, An ), koji opisuju istoimenu relaciju.
Uobiajeni nain pisanja relacijske sheme je R(A1,A2, An), odnosno, R(A1:D1,
A2:D2, An:Dn).
Ime relacije mora biti jedinstveno, jednako kao i imena atributa iste relacije.
Redoslijed atributa relacije nije bitan.
N-torka je jedan element iz skupa Kartezijevog produkta svih atributa. U relaciji ne
mogu postojati dvije identine n-torke.
Klju relecije je minimalni skup atributa ije vrijednosti jednoznano identificiraju
svaku n-torku relacije.
Klju relacije R skup je atributa K iz R, tako da svake dvije n-torke r1 i r2 relacije R
imaju razliite vrijednosti atributa K, tj. da je ri(K)=tj(K), samo za i=j.
Relacijska shema baze podataka je skup relacijskih shema.
Relacijska baza podataka je skup relacija definiranih relacijskom shemom baze
podataka.
U praksi je uobiajeno koritenje pojmova:
tablica je fizika implementacija relacijske sheme
kolona implementacija atributa
redak implementacija n-torke

2.3 Relacijska algebra

Relacijska algebra definira skup formaliziranih operacija nad relacijama. Rezultat bilo
koje operacije je relacija. Neke od operacija dobro su poznate u teoriji skupova.
Osnovne operacije su:
- unija
- razlika
- Kartezijev produkt
- projekcija
- restrikcija
- prirodno i theta spajanje
- presjek
- dijeljenje
Unija

17

Unija dviju unijski kompatibilnih relacija R(A1, A2, An) i S(A1, A2, An) je
nova relacija T(A1,A2, An) koja se sastoji od svih n-torki sadranih u R i S.
Studenti1:
Ime
Ivo
Ana
Josip

Prezime
Ivi
Mari
Petri

Studenti2:
Ime
Luka
Ana

Prezime
Dadi
Mari

Studenti1_UNIJA_Studenti2:
Ime
Ivo
Ana
Josip
Luka

Prezime
Ivi
Mari
Petri
Dadi

Razlika
Razlika diferencija dviju unijski kompatibilnih relacija R(A1,A2, An) i S(A1,A2,
An) je nova relacija T(A1,A2, An) koja obuhvaa sve n-torke iz R, koje nisu
sadrane u S.
Studenti1:
Ime
Ivo
Ana
Josip

Prezime
Ivi
Mari
Petri

Studenti2:
Ime
Luka
Ana

Prezime
Dadi
Mari

Studenti1_MINUS_Studenti2:
Ime
Ivo
Josip

Prezime
Ivi
Petri

Studenti2_MINUS_Studenti1:
Ime
Luka

Prezime
Dadi

18

Kartezijev produkt
Kartezijev produkt dviju relacija R(A1,A2, An) i S(B1,B2, Bm) je nova relacija
T(A1,A2, An,B1,B2, Bm) koja se sastoji od n-torki nastalih spajanjem svake ntorke relacije R sa svakom n-torkom relacije S.
Jasno je, broj n-torki u novoj relaciji T produkt je broja n-torki u R i S.
Projekcija
Projekcija relacije R nova je relacija T koja se sastoji od atributa relacije R po kojima
je obavljena operacija projekcije i u kojoj su uklonjene jednake n-torke.
R(A1,A2,A3,A4) ( A1, A3 ) T(A1,A3)
Restrikcija
Restrikcija relacije R(A1,A2, An) je nova relacija T(A1,A2, An) koja se sastoji
od n-torki relacije R koje ispunjavaju zadani uvjet.
Spajanje
Theta-spoj je restrikcija Kartezijevog produkta relacija R i S opisana formulom
A<operator>B, gdje je A atribut relacije R, a B atribut relacije S.
Vanjsko spajanje
Operacija vanjskog spoja relacija R i S je nova relacija T, koja je jednaka operaciji
spoja R i S, uz dodatak n-torki iz relacija R i S koje nisu sadrane u spoju. Te n-torke
su popunjene null-vrijednostima na mjestima nedostajuih atributa.

19

2.4 Coddova pravila

Radi izbjegavanja nesuglasja oko toga koji sustav za upravljanje bazom podataka je, a
koji nije relacijski, Codd je 1985. definirao 12 pravila od kojih barem 6 sustav mora
ispunjavati, kako bi se smatrao relacijskim. Za nas su znaajna ova pravila, kako
bismo razumjeli to podrava relacijska baza i kako bismo mogli iskoristiti njene
mogunosti, kod projektiranja relacijske baze podataka. Drugim rjeima,
naruavanjem ovih pravila postupkom projektiranja aplikacijske baze, naa baza ne
moe nositi atribut relacijska, iako koristimo relacijski sustav za upravljanje bazom.
Pravilo 0: Bilo koji sustav za upravljanje bazama podataka koji se smatra relacijskim,
mora upravljati bazom podataka na potpuno relacijski nain i relacijskom metodom.
1. Predstavljanje informacija: Sve informacije u relacijskoj bazi podataka logiki
su predtavljene iskljuivona jedan nain: vrijednostima u tablicama, tj. relacijama
2. Obvezna logika dostupnost: Svaka najmanja vrijednost ( atom informacije, tj,
jedna vrijednost atributa u jednoj n-torci) u relacijskoj bazi mora biti logiki
dostupna preko kombinacije imena relacije, vrijednosti promarnog kljua i imena
atributa.
3. Prezentacija nepostojee informacije: Relacijska baza podataka mora
podravati koncept Null vrijednosti, neovisno o tipu podatka. Pod pojmom Null
vrijednosti se podrazumijeva vrijednost atributa koja nije poznata u datom
vremenskom trenutku.
4. Dinamiki on-line katalog: Na lokalnoj razini baza podataka opisana je na isti
nain kao i obini podaci, tako da ovlateni korisnici mogu koristiti isti upitni
jezik za pretraivanje strukture baze, opisa objekata baze, kao i za pretraivanje
podataka.
5. Sveobuhvatni jezik za manipulaciju podacima: Relacijski sustav mora
podravati najmanje jedan jezik iji se izrazi pomou dobro definirane sintakse,
mogu prezentirati kao nizovi znakova i koji mora podravati:
- definiranje podataka
- definiranje pogleda
- manipulaciju podacima ( interaktivno i iz aplikacije)
- ogranienja vezana uz integritet podataka
- autorizaciju orisnika
- upravljanje transakcijama
6. Auriranje pogleda: Svi pogledi koji se po relacijskoj teoriji mogu aurirati,
moraju se moi aurirati i u implementiranom modelu ( tablicama na kojima se
pogled temelji).
7. Visok nivo unosa, auriranja i brisanja: Svojstvo manipulacije relacijom ili
pogledom kao obinim operandom mora biti mogue ne samo kod pretraivanje,
ve i pri unosu, auriranju i brisanju podataka.
8. Fizika neovisnost podataka: Aplikacije i aktivnosti koje korisnik poduzima
prema bazi potpuno su neovisne o metodi pristupa ili o strukturi spremanja
podataka.
9. Logika neovisnost podataka: Aplikacije i aktivnosti koje korisnik poduzima
prema bazi, ostaju nepromjenjene kad god je uinjena promjena na relacijama
koja je po teoriji doputena i koje ne naruava neovisnost podataka.

20
10. Neovisnost integriteta: Ogranienja na integritet podataka ne smiju biti dio
aplikacije ve moraju biti sadrana u katalozima baze.
11. Neovisost distribucije: : Bez obzira na to, podrava li sustav distribuciju ili ne,
jezik sustava mora biti takav da podrava distribuciju bez uticaja na aplikativne
programe.
12. Pravilo o nesubverzivnosti: Ako sustav podrava jezik niskog nivoa, taj jezik ne
smije biti koriten da bi se zaobila ili ignorirala pravila o integritetu.

2.5 Ogranienja relacijskog modela

Ogranienja su definirana kako bi se podrala ispravnost i istinitost podataka. Pravila
se nazivaju i pravilima integriteta podataka.
Vano je imati na umu, da dobar informacijski sustav poiva na dobro definiranoj bazi
podataka. Baza se pak temelji na dobro definiranom modelu podataka. Kljuni initelj
dobrog modela podataka su ispravno uoena i provedena ogranienja.
Ogranienja dijelimo na:
-

ogranienja strukture
ogranienja ponaanja

2.5.1 Ogranienja strukture

Ogranienja strukture nasljeuju se iz definicije relacijskog model i izraavaju
specifina svojstva elemenata relacijskog modela.
Ogranienje domene definira skup vrijednosti koje moe primiti neki atribut.
Provodi se definiranjem:
- Minimalne i maksimalne vrijednosti atributa
- Uvjetom koji vrijednost mora zadovoljiti
- Nabrajanjem vrijednosti
Ogranienje Null vrijednosti definira da li vrijednost atributa moe biti
nedefinirana. Ako je doputena null vrijednost, ne moramo unijeti podatak, a ako nije
doputena, esto se kae da je podatak mandatoran obvezan, nije mogue upisati
redak, ako se ne navede doputena vrijednost atributa.
Ogranienje jedinstvenosti kljua ili entitetski integritet vrijednost primarnog
kljua ne smije biti Null vrijednost. Isto tako nije mogue unijeti dvije n-torke s
istom vrijednosti primarnog kljua. Ista vrijednost primarnog kljua znai ili da je
unijeta pogrena vrijednost jednog od atributa koji identificiraju objekt, ili da se radi o
istom objektu ili pak, da skup atributa koji moraju jedinstveno identificirati objekt nije
dostatan.

21
Referencijsko ogranienje ili integritet stranog kljua strani klju u relaciji mora
biti jednak jednoj od vrijednosti u relaciji gdje je on promarni klju ili pak moe ostati
nedefiniran, tj. primiti Null-vrijednost.
Navedena ogranienja odnose se na strukturu podataka.

2.5.2 Ogranienja ponaanja

Ogranienje ponaanja vodi eliminaciji redudantnosti zapisa, a time olakanim
promjenama podatka i uedi prostora za pohranu. Ogranienje ponaanja promatramo
kroz razliite tipove ovisnosti. Najvanije su funkcijska, vieznana i spojna ovisnost.
2.5.2.1 Funkcijska ovisnost
Neka su A i B podskupovi atributa u relacijskoj shemi R. Funkcijska ovisnost f:AB
vrijedi onda i samo onda, ako za bilo koje dvije n-torke t1(A) i t2(A) za koje vrijedi
t1(A)=t2(A), istovremeno vrijedi i t1(B)=t2(B). Tada kaemo da A funkcijski odreuje
B.
Na primjer, u tablici Knjige1, kad god je potanski broj 10000, mjesto je Zagreb i kad
god je potanski broj 21000, odreeno je mjesto Split. Kaemo da potanski broj
funkcijski odreuje mjesto.
Definirani su aksiomi za izvoenje funkcijskih ovisnosti:
F1)
Refleksivnost: ako je A podskup od B, tada B A. ( znak itat funkcijski
odreuje)
F2)

Proirenje: ako j A B, tada AC B.

F3)

Aditivnost: ako A B i A C, tada A BC

F4)

Projektivnost: ako A BC, tada A B.

F5)

Tranzitivnost: ako A B i B C tada A C.

F6)

Pseudotranzitivnost: ako A B i BC D, tada AC D.

Aksiomi F1, F2 i F6 nazivaju se Armstrongovi aksiomi i oni ine potpuni skup

aksioma, jer se aksiomi F3, F4 i F5 daju izvesti iz njih. Navedene aksiome dobro je
znati jer su temelj za pronalaenje funkcijskih ovisnosti i modifikacije nad strukturom
podataka.
2.5.2.2 Vieznana ovisnost
Neka su A i B disjunktni podskupovi atributa u relacijskoj shemi R i neka je relacijska
shema Z jednaka Z = R AB. Kaemo da relacija r udovoljava uvjetima vieznane

22
ovisnosti (VZO), odnosno A ->>, ako vrijedi: uvijek kada relacija r sadri n-torke
t1(ABC)=a(b1)(c1) i t2(ABC)=a(b2)(c2), onda mora sadravati i n-torke
t3(ABC)=a(b1)(c2) i t4(ABC)=a(b2)(c1). Pojasnimo vieznanu ovisnost primjerom.
Student
Ivi
Ivi
Ivi
Ivi

Sport
PLIVANJE
TRANJE
PLIVANJE
TRANJE

Jezik
NJEMAKI
ENGLESKI
ENGLESKI
NJEMAKI

Dakle, student Ivi se bavi sportovima PLIVANJE i TRANJE; te govori strane

jezike NJEMAKI i ENGLESKI. Dakle, ukoliko postoji n-torka da se jedan student
(a=Ivi), bavi (b1=PLIVANJEM) i zna (c1=NJEMAKI), te (b2=TRANJEM) i
(c2=ENGLESKI), onda moraju postaojati i n-torke (a=Ivi)(b1=PLIVANJE)
(c2=ENGLESKI), kao i (a=Ivi)(b2=TRANJE)(c1=NJEMAKI).
To dokazuje da atributi Sport i Jezik nemaju nikakvih meusobnih ovisnosti, dok
Student funkcijski odreuje i Jezik i Sport, pa vrijede vieznane ovisnosti:
STUDENT ->> SPORT i STUDENT ->> JEZIK
To dokazuje da se mogu pojavljivati redundantni podaci, koji mogu dovesti do
anomalija u auriranju baze podataka, zato to moraju postojati sve kombinacije
parova sport jezik. Anomalija ove vrsti, odnosno ovisnost, rijeit e se
razbijanjem poetne relacije na dvije:
Student
Ivi
Ivi

Sport
PLIVANJE
TRANJE

Student
Ivi
Ivi

Jezik
NJEMAKI
ENGLESKI

Dekompozicija tablica je reverzibilna, to jest, da se prirodnim spajanjem tablica po

kljuu student, dobija izvorna tablica kombinacija sportova i jezika.

2.6 Normalizacija
Normalizacija je postupak uklanjanja nepoeljnih funkcijskih ovisnosti, a provodi se
radi postizanja dobrih statikih i dinamikih svojstava baze podataka:
-

uinkovitost pristupa podacima i jednostavnost njihova pretraivanja

kontrola nad redundancijom ( viestrukim pojavljivanjem podataka u bazi)
kontrola nad anomalijama koje se mogu pojaviti kod auriranja podataka

23
Definirano je est normalnih formi, a u praksi je potrebno i najee dovoljno, dovesti
sve relacije u treu normalnu formu.

2.6.1 Prva normalna forma

Relacija se nalazi u prvoj normalnoj formi (1NF) ako je svaki njen atribut atomian,
to znai da sadri samo jednu vrijednost, nikako vie vrijednosti odvojenih npr.
zarezom. Dvodimenzionalna tablica ima u svakoj eliji samo jednu elementarnu
vrijednost, koja se ne moe dalje rastaviti bez gubitka smisla informacije. Klju uvijek
ima jedinstvenu vrijednost, a za svaku njegovu vrijednost moe se pojaviti samo jedna
vrijednost nekljunog atributa:
Definicija: Relacija se nalazi u prvoj normalnoj formi (1NF) ako su svi nekljuni
atributi funkcijski zavisni o kljuu relacije.
Primjer 1:
est je sluaj da se cijene artikala vode u Eurima, a prikazuju u Kunama, mnoei
iznos u Eurima teajem Kune:
Tablica:Knjige_0
#Naslov
Cijena u
EURIMA
SQL
50,00
Baze podataka
60,00
DOS
30,00

Teaj Kune
7,42
7,42
7,42

Klju tablice Knjige_0 je Naslov ( # ispred imena oznaava primarni klju). Jasno je
da cijena svake knjige ovisi o kojoj se knjizi radi, a to nam jednoznano odreuje
naslov knjige. Prema tome, nekljuni atribut cijena ovisi o kljuu. Teaj Kuna Euro,
nipoto ne ovise o naslovu knjige, dakle, tablica Knjige_0 nije u prvoj normalnoj
formi. Tablica koja nije u prvoj normalnoj formi ne moe se zvati relacijom, jer je po
definiciji relacija barem u prvoj normalnoj formi.
Rjeenje: dekomponirati tablicu Knjiga_0 u dvije:
Tablica:Knjige_1
#Naslov
Cijena u
EURIMA
SQL
50,00
Baze podataka
60,00
DOS
30,00
Tablica:Teajna_Lista_1
#Datum
Teaj Kune
09.12.2002
7,42
Knjige_1 je u prvoj normalnoj formi, jednako kao i Teajna_Lista_1.

24
Primjer 2:
Tablica:Knjige_0
Kataloka oznaka Naslov
1
2
3
4
5

Baze podataka
SQL i relacijski
model podataka
ORACLE 7
Dalmatinska
kuhinja
Dalmatinski
kolai

Broj
strnica
162
419
780
420
360

Izdava Pota Mjesto Autori

DRIP
10000 ZAGREB Varga
ZNAK
ZNAK

10000 ZAGREB Vujnovi

10000 ZAGREB Hreni
Bilu
LOGOS 21000 SPLIT
Rode
Bilu
LOGOS 21000 SPLIT
Kesi

U tablici Knjige_0, upisana je adresa izdavaa, ali isto tako prezimena svih autora
naslova. Tablica nije u prvoj normalnoj formi, jer podaci u koloni autori nisu atomini
( dakle, niti se ne moe utvrivati funkcijska ovisnost, jer jedan atom moe funkcijski
ovisiti, a drugi ne).
Rjeenje: Rascijepiti neatomine podatke u koloni Autori, dodavanjem redaka za
svakog autora, kako bi u jednoj eliji Autor, bude samo jedno prezime.
Tablica:Knjige_0A ( nema primarni klju)
Broj
Kataloka
stranica Izdava Pota Mjesto
oznaka
Naslov
1
2
3
4
4
5
5

Baze podataka
162
SQL i relacijski model 419
podataka
ORACLE 7
780
Dalmatinska kuhinja 420
Dalmatinska kuhinja 420
Dalmatinski kolai
360
Dalmatinski kolai
360

DRIP

Autor
10000 ZAGREB Varga

ZNAK
ZNAK
LOGOS
LOGOS
LOGOS
LOGOS

10000 ZAGREB
10000 ZAGREB
21000 SPLIT
21000 SPLIT
21000 SPLIT
21000 SPLIT

Vujnovi
Hreni
Bilu
Rode
Bilu
Kesi

Sada imamo atomine podatke, te moramo definirati primarni klju relacije. Postavlja
se pitanje to odreuje atribut Broj stranica? Jasno je da broj stranica knjige ovisi o
Katalokoj oznaci. Klju mora imati jedinstvenu vrijednost, a u sluaju kada su jedan
naslov napisala dvojica ili vie autora, vrijednost atributa Kataloka oznaka se
ponavlja. Stoga, definirajmo primarni klju slaganjem atributa Kataloka oznaka +
Autor (Relacija Knjige_1B). Primjetimo, hipotetski sluaj kada bi jedan naslov mogao
napisati samo jedan autor, tada bi klju mogao biti jednostavan, inio bi ga samo
atribut Kataloka oznaka. ( Relacija Knjige_1A).
Relacija:Knjige_1A ( jednostavan klju)
#Kataloka
oznaka
1
2
3
4

Broj
stranica
Naslov
Baze podataka
SQL i relacijski
model podataka
ORACLE 7
Dalmatinska

162
419
780
420

Izdava Pota Mjesto Autor

DRIP
10000 ZAGREB Varga
ZNAK
10000 ZAGREB Vujnovi
ZNAK
10000 ZAGREB Hreni
LOGOS 21000 SPLIT
Bilu

25

kuhinja
Dalmatinski kolai 360

Tablica:Knjige_1B(sloeni klju)
#Kataloka
oznaka
Naslov
1
2
3
4
4
5
5

LOGOS 21000 SPLIT

Broj
stranica Izdava
Baze podataka
162
DRIP
SQL i relacijski
419
model podataka
ZNAK
ORACLE 7
780
ZNAK
Dalmatinska
420
kuhinja
LOGOS
Dalmatinska
420
kuhinja
LOGOS
Dalmatinski kolai 360
LOGOS
Dalmatinski kolai 360
LOGOS

Bilu

Pota Mjesto #Autor

10000 ZAGREB Varga
10000 ZAGREB Vujnovi
10000 ZAGREB Hreni
21000 SPLIT

Bilu

21000 SPLIT
21000 SPLIT
21000 SPLIT

Rode
Bilu
Kesi

Svi nekljuni atributi ovise o kljuu, pa moemo kazati da smo doveli relaciju u prvu
normalnu formu ( u oba sluaja).
Usprkos tome to smo relaciju doveli u prvu normalnu formu, uoavamo znaajne
anomalije, prije svega u redundantnosti podataka, to vodi nepotrebnom troenju
medija za spremanje podataka i vrlo je oteano mijenjanje. Dakle, nije dovoljno
dovesti relaciju u prvu normalnu formu.

2.6.2 Druga normalna forma

Zavisnost nekljunih atributa o dijelovima kljua je uzrok anomalija. Poeljna je
potpuna funkcijska zavisnost o cijelom kljuu, odnosno o svim dijelovima sloenog
kljua.
Relacija se nalazi u drugoj normalnoj formi (2NF) ako su svi nekljuni atributi
potpuno funkcijski zavisni o bilo kojem (moguem) kljuu relacije i to o svim
dijelovima kljua.
Relacija Knjige_1A ima jednostavan klju, dakle ini ga samo jedan atribut i ona
samim tim zadovoljava pravilo druge normalne forme. Dakle, moemo rei da je
relacija odmah u drugoj normalnoj formi, ako joj je klju jednostavan.
Relacija Knjige_1B nije u drugoj normalnoj formi, jer nekljuni atributi Pota i
Mjesto, dodue ovise o dijelu kljua Kataloki broj, tranzitivno preko Izdavaa, ali ne
ovise o dijelu kljua Autor. Isto tako, odreeni autor funkcijski odreuje Naslov, ali ne
i izdavaa, jer isti autor moe napisati Naslov i za drugog izdavaa.
Rjeenje: Napraviti pouzdanu dekompoziciju relacije ( reverzibilnu), tako da se
nekljuni atributi koji ovise samo o dijelu kljua premjeste u novu relaciju, skupa s
dijelovima kljua koji ih funkcijski odreuje. U naem primjeru, o dijelu kljua Autor,
ne ovisi izdava, pa prema tome niti atributi koji ovise o izdavau. Kataloka oznaka

26
odreuje autora, pa emo izdvojiti atribute Kataloka oznaka i Autor u posebnu
relaciju.
Relacija:Knjige_2
#Kataloka
oznaka
Naslov
1
2
3
4
5

Broj
starnica Izdava
Baze podataka
162
DRIP
SQL i relacijski
419
model podataka
ZNAK
ORACLE 7
780
ZNAK
Dalmatinska
420
kuhinja
LOGOS
Dalmatinski kolai 360
LOGOS

Pota Mjesto
10000 ZAGREB
10000 ZAGREB
10000 ZAGREB
21000 SPLIT
21000 SPLIT

Relacija: Knjige_Autori_2
#Kataloka
oznaka
1
2
3
4
4
5
5

#Autor
Varga
Vujnovi
Hreni
Bilu
Rode
Bilu
Kesi

Nakon dekompozicije, obje su relacije u drugoj normalnoj formi.

2.6.3 Trea normalna forma

Jo uvijek nalazimo na redundantnost podataka. Naime, Izdava jednoznano
odreuje Potu i Mjesto izdavaa. tovie, Mjesto je funkcijski odreeno potanskim
brojem. Anomalija ovakvih podataka se ogleda u nepotrebnom troenju medija za
spremanje, kao i potrebom za promjenama u vie redaka potanskog broja i mjesta
kad se izdava preseli u drugo mjesto.
Relacija se nalazi u treoj normalnoj formi(3NF) ako ni jedan nekljuni atribut
nije tranzitivno ovisan o bilo kojem kljuu relacije.
Iz prethodne definicije slijedi jednostavna i popularna definicija 3NF, koja se lako
pamti:
Svaki nekljuni atribut mora ovisiti o kljuu, cijelom kljuu i ni o emu drugom
osim o kljuu.
U naem primjeru nalazimo tranzitivne zavisnosti: Izdava je odreen Katalokim
brojem, te Izdava funkcijski odreuje Potu. Dakle, Pota ovisi o kljuu, ali
tranzitivno preko Izdavaa. Nadalje, Mjesto ovisi o Izdavau tranzitivno preko Pote.
Dvije tranzitivne ovisnosti uklanjamo pouzdanim dekomponiranjem relacije Knjige_2
u relacije, Knjige_3, Izdavai_3 i Pote_3:

27

Relacija:Knjige_3
#Kataloka
oznaka
Naslov
1
2
3
4
5

Broj
stranica Izdava
Baze podataka
162
DRIP
SQL i relacijski
419
model podataka
ZNAK
ORACLE 7
780
ZNAK
Dalmatinska
420
kuhinja
LOGOS
Dalmatinski kolai 360
LOGOS

Relacija:Izdavai_3
Izdava
DRIP
ZNAK
LOGOS

Pota
10000
10000
21000

Relacija:Pote_3
Pota Mjesto
10000 ZAGREB
21000 SPLIT

2.6.4 Boyce-Coddova normalna forma

Dovoenje relacije u treu normalnu formu je zadovoljava veinu praktinih
primjena. Iako ona rjeava ponaanje nekljunih atributa, ne rjeava problem koji se
javlja kod sloenih primarnih kljueva. Prepostavimo trgovaku kuu koja ima vie
referenata prodaje. Svaki od njih odrava kontakt s jednim kupcem i prodaje mu jedan
ili vie artikala.
Relacija: Referent_Artikal_3
#Referent
#Artikal
Ivi
Papir
Juri
Olovke
Mari
Omotnice
Mari
Biljenice
Tomi
Flomasteri

Kupac
Naprijed
Polet
Srima
Srima
Swing

U gornjoj relaciji vrijede funkcijske zavisnosti:

(Referent,Artikal) Kupac, te Kupac Referent, jer referent vee odreeni artikal
uz jednog kupca, a kupac je vezan samo uz jednog referenta. Iako je relacija u treoj
normalnoj formi, uoava se redundancija podataka, koja uzrokuje anomalije u obradi:
informacija da je kupac Srima vezan uz referenta Mari, jednom po artiklu omotnice,
a drugi put po artiklu biljenice, prisutna je u dvije n-torke. Ova se redundancija
otklanja dekompozicijom na dvije relacije.

28
Relacija je u Boyce-Coddovoj normalnoj formi (BCNF) ako sve funkcijske
zavisnosti relacije proizlaze iz njezinog kljua.
Relacija je u BCNF ako ne postoji ni jedan tranzitivno zavisan atribut, ukljuujui i
atribute kljua. BCNF je gotovo identina 3NF, s time da uvjete o tranzitivnoj
neovisnosti protee i na sam klju.
Iz definicije je jasno zato relacija Referent_Artikal_3 nije u BCNF. Funkcijska
zavisnost Kupac Referent ne proizlazi iz kljua.
Relacija: Kupac_Artikal_BCNF
#Kupac
#Artikal
Naprijed
Papir
Polet
Olovke
Srima
Omotnice
Srima
Biljenice
Swing
Flomasteri
Funkcijska zavisnost: (Kupac, Artikal) 0.
Relacija: Kupac_Referent_BCNF
#Kupac
Referent
Naprijed
Ivi
Polet
Juri
Srima
Mari
Swing
Tomi
Funkcijska zavisnost: Kupac Referent.
Gore provedena dekompozicija nije reverzibilna, jer je izgubljena funkcijska
zavisnost Referent Artikal, dakle sauvana je informacija o tome koji se artikli
prodaju svakom kupcu, te koji referent opsluuje svakog kupca, ali je izgubljena
informacija po kojim artiklima referent posluuje kupca.
U nekim prilikama moemo zakljuiti, da je bolje sauvati relaciju u 3NF, nego li
izgubiti dio informacija.

2.6.5 etvrta normalna forma

Kod vieznane ovisnosti smo ve vidjeli moguu anomaliju:
Relacija: Student_Sport_Jezik_BCNF
#Student
#Sport
Ivi
PLIVANJE
Ivi
TRANJE
Ivi
PLIVANJE
Ivi
TRANJE

#Jezik
NJEMAKI
ENGLESKI
ENGLESKI
NJEMAKI

29
Kako je oito da u relaciji ne vrijedi niti jedna funkcijska zavisnost, relacija je u
BCNF. Ipak, velika redundancija rezultira u manjkavosti koritenja medija za
spremanje podataka i oteava izmjene podataka.
Relacija u kojoj je zadan skup funkcijskih i vieznanih ovisnosti, u etvrtoj je
normalnoj formi (4NF), ako je svaka vieznana ovisnost X ->> Y trivijalna ili je X
klju relacije.
Pouzdanim dekomponiranjem se relacija prevodi u dvije nove relacije, koje spajanjem
rezultiraju polaznom relacijom, pa kaemo da je dekompozicija reverzibilna, dakle
pouzdana.
Relacija: Student_Jezik_5
#Student
#Jezik
Ivi
ENGLESKI
Ivi
NJEMAKI
Relacija: Student_Sport_5
#Student
#Sport
Ivi
PLIVANJE
Ivi
TRANJE

2.6.6 Peta normalna forma

Relacija R, u kojoj je zadan skup funkcijskih i spojnih ovisnosti, u petoj je
normalnoj formi (5NF), ako je svaka spojna zavisnost *(R1,R2, ... Rn) trivijalna ili
je svaki Ri klju u R.
Relacija je u 5NF, ako su iz nje izbaene sve spojne zavisnosti, odnosno, ako se vie
ne moe pozdano (reverzibilno) dekomponirati.
Relacija: Student_Instrument_Nastavnik
Br.Indeksa
Instrument
Nastavnik
1
Violina
Ani
1
Flauta
Peri
2
Violina
Peri
Problem se rjeava dekompozicijom na 3 relacije:
Relacija: Student_Nastavnik_5
Br.Indeksa
Nastavnik
1
Ani
1
Peri
2
Peri
Relacija: Student_Instrument_5

30
Br.Indeksa
1
1
2

Instrument
Violina
Flauta
Violina

Relacija: Instrument_Nastavnik_5
Instrument
Nastavnik
Violina
Ani
Flauta
Peri
Violina
Peri
No, veina se relacija koje predstavljaju implementaciju n arne ( n>2) veze ne moe
dekomponirati, jer ponovnim spajanjem nastaju nepostojee n-torke:
Relacija: Student_Instrument_Nastavnik_S
Br.Indeksa
Instrument
Nastavnik
1
Violina
Ani
1
Violina
Peri
1
Flauta
Peri
2
Violina
Peri

nova pogrena n-torka

31

3 ivotni ciklus baze podataka

ivotni ciklus baze podataka slijedi identine korake koji se primjenjuju u analizi i
oblikovanju programske podrke, koji su dobro utvreni sedamdesetih godina. Valja
kazati, kako postavke programskog inenjerstva vuku svoje korijene iz inenjerstva
openito, odnosno graditeljstva. Naime, ivotni ciklus jedne zgrade, zapoinje
stvaranjem idejnog rjeenja, praenog skicama i modelima, koje izrauju arhitekti,
suraujui s investitorom i buduim korisnicima. Metodom usmjerenog razgovora
(interview) arhitekt saznaje elje investitora i uklapa ih u estetski prihvatljiva i
tehniki izvediva rjeenja. Nakon toga graevinski inenjeri izvode statike i
dinamike proraune, s ciljem izraunavanja nosivosti temelja, zidova, kako bi zgrada
izdrala teret vlastite konstrukcije, te dinamika naprezanja uzrokovana vjetrom ili
moebitnim zemljotresom. Dizajneri interijera oblikuju unutranje ureenje do
najsitnijeg detalja.
Nakon to je zgrada izgraena, slijedi njeno koritenje, odravanje, otklanjanje
uoenih nedostataka, a ponekad i naknadne modifikacije u cilju zadovoljavanja
zahtjeva koji su definirani tijekom eksploatacije objekta.
Identini ivotni ciklus prolazi informacijski sustav, pa tako i baza podataka, kao
njegova sastavnica. Moemo povui usporedbu baze podataka s temeljem graevine.
Dakle, ivotni ciklus baze podataka moemo podijeliti na korake:
-

Analiza
Oblikovanje
Implementacija
Eksploatacija
Odravanje i naknadne modifikacije

3.1 Faze ivotnog ciklusa baze

Analiza vrlo je vjerojatno da je neki posao odavna obavljan primjenom postojeih
tehnolokih postupaka, prije informatizacije. Postupkom analize, primjenom metode
usmjerenog razgovora (interview), s osobljem koje pozna tehnologiju posla, se
identificiraju izlazi koje informacijski sustav mora producirati. Da bi se izlazi mogli
producirati, potrebno je programsku podrku snabdjeti odreenim ulazima. Neki ulazi
e se definirati u tijeku izvoenja programa, no neki drugi moraju biti pohranjeni na
mediju za mosaovnu pohranu podataka, najee magnetskim diskovima. Projektant
baze podataka mora identificirati upravo te, tzv. perzistentne ulaze. Naprimjer, kod
prodaje automobil, sve relevantne informacije o vozilu valja pohraniti u bazi
podataka. Kupac definira kriterije koje mora zadovoljiti automobil od njegova
interesa kriterije pretraivanja. Ovi kriteriji ne moraju biti perzistentni, ve se
definiraju prije poetka pretraivanja, te se zaboravljaju nakon obavljene potrage.
Dakako, podrava li informacijski sustav naknadno pretraivanje, onda e i kriterije
valjati sauvati. Naime, u momentu pretrage kupac moe ne pronai eljeni auto, a IS
moe osigurati spremanje njegovih kriterija, te po njima pretraivati, npr. jednom

32
dnevno, da li se u meuvremenu pojavio auto koji zadovoljava kriterije i o tome
kupca obavijestiti e-mailom.
Logiko ( konceptualno) oblikovanje faza analize zavrava definicijom pojmova i
opisom entiteta, njihovih atributa, te moguih domena, najee prirodnim jezikom
(hrvatskim ili engleskim). Nakon toga, valja identificirati entitete, atribute i domene,
te metode - funkcije. Najee imenice iz opisa prirodnim jezikom vode entitetima i
njihivim atributima, a pridjevi i brojani podaci definiraju domene. Rezultat ovog
koraka su relacije prikazane prikladnim simbolima. Vrlo je vjerojatno da e u ovoj
fazi relacije posjedovati nepoeljnu redundantnost, kao posljedicu nedoputenih
funkcijski zavisnosti, pa se primjenjuje postupak normalizacije, iterativno, sve dok ne
dovedemo sve relacije barem i obavezno u treu normalnu formu (3NF). Nakon toga
slijedi utvrivanje meusobnih veza meu relacijama i njihov prikaz modelom
Entiteti veze. Dakako, u prikazu se koristimo simbolima, zavisno izabranoj metodi.
Implementacija je postupak definicije relacija u bazi podataka, pri emu entiteti (ili
tipovi entiteta) postaju tablice, atributi kolone, a domena slui kao podloga za izbor
tipa podatka i eventualna integritetska ogranienja ( ogranienje null vrijednosti,
ogranienje podruja vrijednosti uvjetom koji podaci moraju zadovoljiti ili
referencijalnim, tj. integritetom stranog kljua). Slijedi izrada objekata baze podataka,
najee pomou grafikog korisnikog suelja na razvojnom raunalu proizvoaa
IS, te generiranje komandi upitnog jezika (SQL), koje se koriste za prenoenje
objekata na odredina raunala kupca.
Statika i dinamika analiza uvrivanjem tipova podataka svake kolone, te
poznavanjem naina kako koriteni RDBMS sprema podatke na mediju, a na temelju
procjene broja n-torki, odnosno redaka svake tablice, procjenjuje se fizika veliina
tablica. Isto tako, u najranijoij fazi definicije projeta, potrebno je definirati odzivna
vremena kritinih, esto izvoenih upita. Najbolje je da definicija odzivnih vremena
bude kvantificirana ( npr. 3 sekunde nakon klika na dugme Trai ). Da bi odzivna
vremena bila zadovoljena, vano je pravilno procijeniti vanost i uestalost pojedinih
upita, te broj klijenata koji e istovremeno napadati bazu podataka. Analiza upita i
odzivnih vremena rezultira definiranjem odgovarajuih indeksa, koji znaajno
ubrzavaju pretraivanje, ali naalost usporavaju izmjene ( upisivanje insert,
promjene update i brisanje delete ), jer kod svake izmjene indeksi moraju biti
reorganizirani. Stoga teimo identifikaciji minimalnog broja indeksa, koji
zadovoljavaju kritine upite nad vruim tablicama. Kako indeksi troe prostor na
mediju za pohranu podataka, izraunava se statika indeksa na temelju broja redaka
tablice i poznavanja organizacije indeksa koritenog RDBMS. Ova veliina, zajedno
s veliinom prostora za pohranu tablinih podataka, slue za procjenu veliine
potrebnog prostora medija za masovnu pohranu ( diska).
Eksploatacija i odravanje baze podataka - ve prije poetka eksploatacije
potrebno je planirati sigurnost podataka i to u smislu neovlatenog pristupa podacima,
te uvanja priuvnih podataka backupa. Naime, mogue elementarne nepogode ili
teroristiki napadi mogu unititi cijeli raunalni sustav, skupa s podacima. Isto tako
kvar raunalnog hardvera ili ak upad hackera mogu uzrokovati gubitak podataka. I
pored takvih katastrofa, organizacija mora nastaviti s radom i imati na raspolaganju
podatke unijete u bazu do momenta katastrofe. Vremenski period ponovne
raspoloivosti podataka moe biti nekoliko sekundi ili nekoliko dana nakon gubitka,

33
pa zavisno definiciji ovog intervala, izraujemo strategiju backupa, poev od standby-backup-baze za brzi nastavka rada, do klasninog pristupa zamjene neispravnih
dijelova raunala i restauracije podataka, to moe potrajati nekoliko sati ili ak dana.
Tijekom eksploatacije potrebno je pratiti odzivna vremena i korist predvienih
indeksa, te po potrebi brisati nekorisne i kreirati nove korisne indekse.
U ranim fazama projekta, nije mogue predvidjeti sve funkcionalnosti informacijskog
sustava, ili jo ee svjesno se ide s minimalnim funkcijama, kako bi se izilo na
trite prije konkurencije i ostvariovao prihod. Potom se sustav obogauje, a to
zahtijeva i promjene strukture baze podataka. Vrlo je vano promjenama ne ugroziti
postojee stanje, kako u smislu funkcionalnosti, tako i u smislu odzivnih vremena.

3.2 Vrste baza podataka

Prije razrade svih koraka ivotnog ciklusa baze, osvrnimo se na vrste baze podataka.
Na jednom polu su sustavi koji podupiru donoenje odluka, DSS (Decision
support system), koji se samo i iskljuivo pretrauju. Dakle nema izmjena podataka,
samo se itaju. Kod ovakvih sustava moemo definirati neogranieni broj indeksa
( jasno, on je ogranien veliinom medija i maksimalnim brojem indeksa koje
RDBMS podrava).
Na drugom polu su baze koje nitko nebi pretraivao, ve bi samo upisivale podatke
(insertirale) podatke, pa niti ne trebamo definirati indekse. Naravno, ovo su samo
ekstremni sluajevi, dok je najee istovremeno pretraivanje i promjena podataka, a
takve baze nazivamo OLTP ( on-line transaction processing), dakle, promjene se
obavljaju u ivo, usporedno s pretraivanjem. Baze ove vrsti, mogu imati ogranieni
broj indeksa, jer indeksi ubrzavaju pretraivanje, ali usporavaju promjene, jer se
zajedno s promjenom podataka, mora aurirati i stablo svih indeksa, koji sadre
promijenjeni podataka. Ovdje je to istaknuto iz razloga denormalizacije baze. Naime,
normalizacija uklanja redundantnost i anomalije odravanja podataka, ali vodi veem
broju tablica, koje su zapisane na razliitim cilindrima diska, najeeg medija za
pohranu baza. Upitima se tablice spajaju, a to je skupa operacija, pa su upiti mnogo
sporiji, nego li kad nema spajanja, tj. kad su podaci pregledno u istoj tablici.
Potrebno je pomiriti ove dvije suprotnosti, postupkom denormalizacije. Moramo
razlikovati pojmove ne-normalizirane i denormalizirane strukture. Naime, doputeno
je postojanje redundantnih zapisa podataka, ali uz jasno razlikovanje master
podatka, koji implementira atribut iz normalizirane relacije, od slave podatka, koji
ubrzava pretraivanje i mora vjerno slijediti promjene vrijednosti master podatka.
Funkcija slijeenja se moe ostvariti definiranjem okidaa ( trigera ), koje okida
promjena master podatka, te oni izvoenjem adekvatne SQL naredbe auriraju
slave podatak. Drugi nain denormalizacije se moe provesti upotrebom
materijaliziranih pogleda. Naime, pogled (view) se definira pomou SQL naredbe
koja spaja vie relacija ( tablica i drugih pogleda), radi olakanog pisanja kasnijih
upita, te radi ogranienja pristupa objektima baze ( primjenom operacija projekcije i

34
restrikcije). Klasini pogled nema fizikog zapisa podataka na mediju, ve obavlja
projekciju, restrikciju i spajanje dinamiki, kada se upit definiran pogledom izvodi.
Moemo sebi predoiti pogled, kao zamjenu sloenog upita jednim imenom, a
pozivom pogleda, se zapravo izvodi upit koji lei iza tog imena.
Nasuprot tome, materijalizirani pogled ima fiziki zapis podataka na magnetskom
mediju, kao slave podatke, pa se pozivom imena materijaliziranog pogleda, zapravo
ita fiziki zapis kopije podataka. RDBMS osigurava da kopija podataka iz razliitih
izvornih tablica vjerno slijedi promjene izvornoh, master podataka. Promjene
kopije se obavljaju kod izmjene master podataka, pa se tijekom upita nad
materijaliziranim pogledom ne obavlja dinamiki spajanje veeg broja tablica.
Ovom tehnikom moemo postii bazu koja apsolutno udovoljava i najstroim
teoretskim zahtjevima, a da isto tako kritini upiti budu pokriveni materijaliziranim
pogledima, ime se ostvaruju iznimno dobra odzivna vremena. Naravno, broj
materijaliziranih pogleda mora biti ogranien, jer bi u protivnom usporio promjene
podataka kod OLTP baza, pa treba vrlo briljivo odabrati upite pokrivene
materijaliziranim pogledom.

3.3 Postupak oblikovanja baze podataka

3.3.1 Izrada modela

Aktivnost oblikovanja na svakom polju djelatnosti, karakterizira izrada modela. Od
male djece koja izrauju modele realnih objekata pomou Lego kockica, do
nuklearnih fiziara koji izrauju modele ponaanja jezgre atoma, fiziki i mentalni
modeli objekata iz realnog svijeta pomau shvaanju ponaanja realnih objekata i
zbivanja, istraivanju ideja i razumijevanju dogaaja.
Modeli se mogu koristi za:
- opis
- specifikaciju
- istraivanje
- komunikaciju
- analizu
- kategorizaciju
- imitaciju
ponaanja realnih objekata i zbivanja.
Vano je uoiti konflikt: model koji osigurava mnogo detalja da bi sustav opisao
potpuno, moe sakriti ili oteati shvaanje cjelovitosti. To je stvorilo ideju stvaranja,
tzv. ugnijeenih ili postupnih modela. Uzmimo na primjer izuavanje povijesti
Hrvata, koju ne moemo uiti izolirano od povijesnih zbivanja europske i svjetske
povijesti u svakom razdoblju. Uimo li istovremeno i svjetsku i hrvatsku povijest,
dolazimo do toliko detalja, da od njih ne vidimo osnovne znaajke razdoblja. Zato se
uenje provodi najprije uenjem svjetske povijesti u osnovnim crtama, pa onda

35
hrvatske povijesti detaljnije ( u osnovnoj koli), onda se postupak ponavlja s vie
detalja o svjestkoj povijesti itd. ( u srednjoj koli).
Dakle, uoavamo postupnost u razumijevanju i svladavanju problema, pa isti pristup
valja primijeniti i kod modeliranja objekata i zbivanja odnosno tehnolokih
postupaka predmeta informatizacije.

3.3.2 Razliiti aspekti sustava

Model mora prikazivati realne objekte i zbivanja selektivno, uzimajui u obzir bitna
obiljeja. U pravilu model isputa mnogo vie detalja,nego li ih ukljuuje. Ako bi
model ukljuio sve mogue detalje realnih objekata, pretpostavimo li da je to ope
mogue, bio bi identian realnom ivotu, pa vjerojatno teko razumljiv i prihvatljiv.
Oslikajmo ideju primjerom. Bacimo kameni s visine 10 m i zanima nas brzina
kojom udari pri padu na tlo. Kao to je poznato iz fizike, brzinu raunamo po modelu
opisanom formulom:
v= SQRT( 2gh)
gdje je g ubrzanje zemljine sile tee ( 9.81 m/s2) a h visina ( 10 m ) i dobijemo:
v = 14.8 m/s
Pri tom smo zanemarili brojne injenice koje utiu na slobodan pad, kao trenje zraka,
tlak zraka, utjecaj mogueg vjetra itd. Ako bi vrlo kompleksnim modelom uvaili sve
te utjecaje, odstupanje rezultata bi bilo neznatno, a raun sloen.
Ako pak raunamo brzinu kojom satelit moe pasti na zemlju, ranije zanemareni
utjecaji se moraju uzeti u raun, jer je njihov doprinos znaajan. Dakle, osnovno u
izradi modela je izbor parametara od utjecaja na konaan rezultat, a u inenjerskom
pristupu, nastojimo to jednostavnijim modelom dobiti najmanje loe rezultate.
Slijedi zakljuak, da u cilju postizanja to boljeg modela valja koristiti razliite
tehnike zajedno. Na primjer, kod medicinskog ispitivanja pacijenta, lijenik stvara
model njegova zdravstvenog stanja koristei nalaze krvi, krvni tlak, rentgentske i
ultrazvune snimke, te analizom svih nalaza zakljuuje o zdravstvenom stanju.
Isto tako moramo i mi, upotrijebiti razliite tehnike koje se fokusiraju na razliite
aspekte sustava, ali koje se nadovezuju i isprepliu, dajui kompletnu sliku sustava.
Koristit emo:
- Model entiteti veze
- Funkcijski model
- Model toka podataka

3.3.3 Model entiteti veze

Cilj modeliranja je definirati i razumjeti injenice znaajne za poslovnu aktivnost,
koje informacije mora pamtiti, te vezu meu njima.

36

Koristi se pristup od vrha nadolje (Top-Down), polazei najprije od utvrivanja

entiteta, a potom njihovih atributa.
Pojmovi od znaaja u analizi entiteta
- Entitet
- Veza
- Atribut
- Jedinstveni identifikator (primarni klju)
- Podtip
- Nadtip
to moe biti entitet ?
Bilo to o emu moemo prikupljati informacije. Bilo koja imenovana stvar. Sve ono
to ima posebna svojstva, koja se mogu razlikovati, bilo u domenu realnih objekata i
zbivanja ili u sferi apstraktnog miljenja. Entitet je obino imenica u reenici
napisanoj tijekom usmjerenog razgovora (interview) s korisnicima postojee
tehnologije.
Primjer entiteta:
OSOBA, POSAO, PROJEKT, TVRTKA, ODJEL, ZAPOSLENIK, KUPAC,
DOBAVLJA
Dobro je potraiti i sinonime: drukija imena koja znae isto. Na primjer, to je
KUPAC, TVRTKA, DOBAVLJA ? Vjerojatno ORGANIZACIJA.
Zavisno od izabrane metode za prikazivanje modela, entiteti se mogu prikazati jednim
od grafikih simola:

OSOBA

OSOBA

OSOBA

3.3.4 Veze
Veza predstavlja bilo koji nain na koji dva objekta istog ili razliitog tipa mogu biti
upueni jedan na drugoga. Svaku je vezu dobro imenovati, naprimjer:
ZAPOSLENIK obavlja POSAO
POSAO je dodijeljen ZAPOSLENIK-u
Veze su opisane stupnjem veze i opcionalnou:
U naem primjeru, stupanj veze odgovara na pitanje: Koliko poslova moe obavljati
jedan zaposlenik?

37

Odgovor: Jedan zaposlenik moe obavljati vie poslova.

Pitanje: Koliko zaposlenika moe obavljati isti posao?
Odgovor: Vie zaposlenika moe obavljati istu vrst posla.
Dakle, veza ZAPOSLENIK POSAO je M:N, tj. vie prema vie.
Opcionalnost veze
Postavlja se pitanje, da li ZAPOSLENIK-u uvijek mora biti dodijeljen POSAO, ili
moe i ne mora biti ?
Odgovor: ZAPOSLENIKU mora biti dodijeljen POSAO.
Sada vezu moemo itati: Svaki ZAPOSLENIK obavlja jedan ili vie POSLOVA, ili
obratno, svaki POSAO je dodijeljen jednom ili vie ZAPOSLENIKA.
Prikaz veze:
Martinova notacija:
obavlja
ZAPOSLENIK

POSAO
dodijeljen

Chenova notacija:

ZAPOSLENIK

obavlja
N

POSAO

ORACLE notacija:

ZAPOSLENIK

Stupanj ili kardinalni broj veze:

POSAO

38

Naziv veze
Jedan prema vie

Martinova notacija
1:N

Chenova notacija
1:N

Vie prema vie

M:N

M:N

Jedan i samo jedan

1:1

1:1

Martinova
notacija
0,1

Chenova notacija

0,N

0,N

1,N

1,N

ORACLE notacija

Opcionalnost veze:
Naziv veze
Opcionalna veza
(moe biti) jedan
Opcionalna veza
(moe biti) vie
Obvezna veza
(mora biti ) jedan
Obvezna veza
(mora biti ) barem
jedan ili vie

Pravilo itanja veza:

Svaki ( entitet )
mora biti /1/
ili

( veza )

moe biti /0/

jedan ili vie /N/
ili

(entitet)

jedan i samo jedan /1/.

0,1

ORACLE notacija

39
Primjer: Svaki zaposlenik obavlja barem jedan ili vie poslova, te svaki posao je
dodijeljen jednom ili vie zaposlenika.
Evo nekih korisnih parova imena veza:
temelji se na osnov za
kupuje se od isporuuje
imenovan za povjeren
dio od sastavljen od
odgovoran za u nadlenosti

3.3.5 Rjeenje veze vie prema vie

Jedan projekt moe obavljati vie zaposlenika, a isto tako jedan zaposlenik moe
istovremeno ili u razliitim vremenima, raditi na vie projekata.
0,M
ZAPOSLENIK

PROJEKT

ukljuen
0,N

Vezu vie prema vie ( M:N) teko je implementirati i odravati, stoga se ona
dekomponira u dvije veze 1 naprema vie ( 0,1:N + 0,1:M ).

ZAPOSLE
NIK

0,1

ZAP_PROJ
M

N
PROJEKT
0,1

Dakle, veza M:N se dekomponira u dvije veze 1:N, umetanjem presjenog (eng.
intersection) entiteta, pri emu je kardinalni broj (stupanj veze), na strani polaznih
entiteta 1 uz zadranu opcionalnost, dakle 1 ili 0,1, a na strani presjenog entiteta
1,M. Dakle, polazna veza Svaki Zaposlenik moe biti ukljuen u vie projekata i
Svaki projekt moe ukljuivati vie zaposlenika je sauvana. Presjeni entitet e
imati dva strana kljua, koji su primarni kljuevi u polaznim entitetima, a oni zajedno
ine primarni klju u presjenom entitetu.

3.3.6 Rekurzivna veza

Rekurzivna veza predstavlja vezu entiteta sa samim sobom. Koristi se za prikazivanje
hijerarhije nelimitiranog broja kompatibilnih elemenata.
Na primjer, u organizaciji koja je u pravilu hijerarhiski ureena, svaki zaposlenik ima
pretpostavljenog (efa), pri emu ovaj ima svog pretpostavljenog i tako dalje, sve do
vrha piramide.
ef od
0,1

40

OSOBA

ima efa
0,N

Dakle, Svaka osoba moe ( glavni ef nema nad-efa) imati jednog i samo jednog
neposrednog efa, a neke osobe su efovi veem broju osoba.
Rekurzivna veza je zgodna za prikazivanje sastavnica, dio od sastavljen od,
teritorijalne pripadnosti itd.

3.3.7 Uestalost pojedinih vrsta veza u realnim modelima

Oznaka veze
1,M : 0,1
0,M : 0,1
0,M : 1
1,M : 1
0,M : 0,N
1,M : 0,N
1,M : 1,N
1 : 0,1
0,1 : 0,1
1:1

Naziv veze
barem jedan ili vie prema moe biti
jedan
moe biti vie prema moe biti jedan
moe biti vie prema jedan i samo
jedan
barem jedan ili vie prema jedan i
samo jedan
moe biti vie prema moe biti vie
barem jedan ili vie prema moe biti
jedan
barem jedan ili vie prema barem
jedan ili vie
jedan i samo jedan prema moe biti
jedan
moe biti jedan prem amoe biti
jedan
jedan i samo jedan prema jedan i
samo jedan

Uestalost
(5) VRLO ESTO
(4) ESTO
(3) NIJE RIJETKO
(2) RIJETKO
(4) ESTO U POETNOJ
FAZI
(4) ESTO U POETNOJ
FAZI
(1) VRLO RIJETKO
(2) RIJETKO
(2) RIJETKO
(1) VRLO RIJETKO

Brojevi u zagradama odreuju uestalost pojave, 1 = vrlo rijetko, 5=vrlo esto.

3.3.8 Atributi
Openito kazano atributi opisuju entitet.
Namjena atributa je da:
- Kvalificiraju
- Identificiraju
- Klasificiraju
- Kvantificiraju
- Izraze stanje

41

Postupkom oblikovanja utvrujemo atribute od znaaja u opisu entiteta, a

izostavljamo iz modela one koji nisu.
Tako na primjer, entitet Student moe biti opisan atributima:
Atribut
Ime
Prezime
Zavrena srednja kola

Kategorija
Identificira
Identificira
Kategorizira

Studijska grupa
Poloeni ispiti
Teina
Status

Klasificira
Kvalificira
Kvantificira
Izraava stanje

Brano stanje

Izraava stanje

Opis
Npr. u statistikoj analizi
prolaznosti s obziro iz koje
kole dolazi
Prema studijskim grupama
Za upis na viu godinu
Nije od znaaja u IS
Redovito upisan, ponavlja,
parcijalno upisan
Noenjen, neudata,
oenjen, udata

Jasno je da neki atributi u IS Studentska sluba nisu znaajni, kao npr. teina pa ih
isputamo iz odreenog modela. Kod modela nekog drugog IS, npr. Zdravstvena
ustanova atribut teina je od znaaja, jer je poznato da moe biti povezana s nekim
bolestima, pa atribut mora biti uvrten u model.

3.3.9 Opcionalnost atributa

Vrijednosti nekih atributa mogu biti nepoznate i ostati nedefinirane, dok drugi atributi
moraju obavezno biti definirani. Oznaimo u modelu opcionalnost simbolima:
* mora biti definiran
o moe ostati nedefiniran
Na primjer, entitet osoba je opisan atributima:
Osoba
* Ime
* Prezime
* Spol
o Datum roenja
o Adresa

3.3.10

Jedinstveni identifikator

Kako je ve reeno, svaki entitet ( npr. svaki student ) mora biti identificiran na
jedinstven nain, jednim atributom ili skupom atributa. Jedinstveni identifikator u fazi
implementacije postaje primarni klju.

42

Atribute koji jedinstveno identificiraju pojavu entiteta simboliki oznaimo znakom #.

Evo nekih primjera jedinstvenog identifikatora:
Proizvod
# Bar kod
Ispit
#Predmet
#Datum
Osoba
#JMBG
Osoba
#Ime
#Prezime
#Datum roenja
#Adresa
Naravno, atributi koji identificiraju svaku pojavu entiteta, moraju biti definirani. to
emo izabrati za identifikator, ovisi o konkretnom informacijskom sustavu.
Motorno vozilo
#Broj asije
Tako na primjer, broj asije motornog vozila je odlian identifikator, jer svako
motorno vozilo na svijetu ima jedinstvenu oznaku, ali u IS Trgovina rabljenim
motornim vozilima cilj je oglasiti prodaju to veeg broja vozila, pa tako imati veu
zaradu, a vlasnici motornih vozila esto ne znaju napamet ovaj broj, pa bi izbor
takvog identifikatora, koji mora biti definiran, odvratio mnoge klijente da isti posao
odrade kod konkurentskog internet site, koji ne trai unos kompliciranih oznaka.
Dakle, izbor atributa koji identificiraju entitet, mora biti paljiv i razlikovat e se
prema namjeni informacijskog sustava.
U fazi implementacije baze podataka, jedinstveni identifikator e postati primarni
klju tablice. est je sluaj da jedan objekt iz realnog svijeta moe jedinstveno
identificirati skup veeg broja atributa. Tako osobu u mnogim IS ne moe
identificirati samo Prezime, nego npr. skup atributa Ime, Prezime, Datum roenja i
Adresa stanovanja. Veze meu tablicama ostvarujemo odnosom primarni strani
klju. To znai, da bi u tablici djetetu, svaka pripadnost roditelju, bila definirana
skupom od vie kolona, s tekstualnim vrijednostima, koji ponekad mogu imati
nekoliko stotina znakova. Pri spajanju tablica raunalni hardver mora usporediti da li
su vrijednosti u svim relevantnim kolonama identine traenim vrijednostima,
vjerojatno znak po znak, pri emu sva mala slova moraju biti pretvorena u velika
(pretpostavljamo da baza radi case insensitive, dakle ne razlikuje malo i veliko
slovo (a i A su isti znak). Da bi izbjegli naruavanje odzivnih vremena iz ovog
razloga, vrlo esto, u fazi implementacije biramo primarni klju kao apstraktan, tj.

43
definiramo kolonu cjelobrojnog tipa od 4 byta, ije vrijednosti baza automatski
generira, ime je osigurana jedinstvenost. Spajanje tablica onda ostvarujemo ovim
apstraktnim identifikatorom, jer raunalo vrlo brzo usporeuje 4-bytne brojeve.
Primarni klju nazivamo apstraktnim, jer on ne identificira objekt u realno svijetu,
samo interno u naem IS. Kako bi sprijeili pojavu dva retka s istom vrijednou
atributa, koji su zapravo trebali biti primarni klju, jer oni identificiraju objekt u
realnom svijetu, definiramo jedinstveni indeks nad skupom tih atributa. Na taj nain
imamo osiguranu jedinstvenost i dobili smo na brzini spajanja tablica, te utedjeli
prostor za pohranu.

3.4 Videoteka - model praktinog primjera

Nakon obavljenog usmjerenog razgovora s naruiteljem informacijskog sustava
Videoteka, napravljene su slijedee biljeke:
Videoteka upisuje lanove koji posuuju na odreeni period kasete razliitih
naslova. lanovi su opisani imenom, prezimenom, kunom adresom i brojem
telefona. lan se ne moe upisati ako nisu poznati ovi atributi, radi vraanja
zaboravljenih kaseta. Na svaku kasetu je snimljen samo jedan naslov ( film ). Naslov
je opisan nazivom djela ( filma), anrom, trajanjem u minutama, kratkim sadrajem
te akterima, kao to su producent, reiser, glavni i ostali glumci. O svakoj kaseti se
vodi evidencija njenog stanja (istroenosti), radi planiranja zamjena. Kasete se izdaju
za trajanje od jednog do vie dana, a najam se naplauje na dan vraanja, po
jedinstvenoj cijeni Kuna/dan.
lanovi esto ele izabrati jedan od naslova njihovih omiljenih glumaca.
Meu imenicama (tiskanim masnim podvuenim kurzivom), traimo imena entiteta ili
(imenice tiskane masnim kurzivom) su kandidadti za atribute, a glagoli sugeriraju
metode ( SQL upit ).
Entitetski kandidati:
lanovi
# Identifikator lana
* Ime
* Prezime
* Potanski broj
* Mjesto
* Ulica i Kuni broj
* Telefon
o Datum Rodjenja
o Spol
Naslovi
# Identifikator naslova
* Naslov
o Trajanje minuta
o anr

44
o Opis
Kasete
# Identifikator kasete
* Naslov
* Stanje
Akteri
# Identifikator aktera
o Ime
* Prezime
PosudbaKaseta
# Identifikator lana
# Identifikator kasete
# Datum izdavanja
o Planirani datum vraanja
o Stvarni datum vraanja
Analizom entiteta, zakljuujemo na relacije:
Clanovi
#
*
*
$

ClanID
Ime
Prezime
PostaID

*
*
o
o
o
$

Ulica
Kbr
KbrDodatak
Kat
DatumRodjenja
Spol

Int4 Autoident
varchar(30)
varchar(30)
Int4 - Strani klju ref:
Poste
varchar(50)
Int2
varchar(10)
Int2
smalldatetime
Int1 Strani klju ref:
Spolovi

Total:

Max
duina
4
30
30
4

Prosjena
duina
4
7
8
4

50
2
10
2
4
1

12
2
1
2
4
1

137

45

Max
duina
4
30
35

Prosjena
duina
4
9
13

Poste
#
*
Total:

PostaID
Posta

Int4
varchar(30)

45
Spolovi
#
*
Total:

SpolID
Spol

Int1
varchar(30)

Max
duina
1
30
31

Prosjena
duina
1
6
7

Max
duina
4
80
2
1
1024
1111

Prosjena
duina
4
16
2
1
250
273

Max
duina
1
30
31

Prosjena
duina
1
6
7

Max
duina
4
4
1
9

Prosjena
duina
4
4
1
9

Max
duina
1
30
31

Prosjena
duina
1
10
11

Max
duina
4

Prosjena
duina
4

Naslovi
#
*
o
$
o
Total:

NaslovID
Naslov
TrajanjeMin
ZanrID
Opis

Int4 Autoident
varchar(80)
Int2
Int1
varchar(1024)

Zanrovi
#
*
Total:

ZanrID
Zanr

Int1
varchar(30)

Kasete
#
$
$
Total:

KasetaID
NaslovID
StanjeKaseteID

Int4 - Autoident
Int4 ref: Naslovi
Int1

StanjeKaseta
#
*
Total:

StanjeKaseteID
StanjeKasete

Int1
varchar(30)

Akteri
#

AkterID

Int4 Autoident

46
o
*
o
Total:

Ime
Prezime
Opis

varchar(30)
varchar(30)
varchar(255)

30
30
255
219

10
10
60
84

Max
duina
4
4
1
9

Prosjena
duina
4
4
1
9

Max
duina
1
30
31

Prosjena
duina
1
12
13

AkteriUloge
#$
#$
#$
Total:

AkterID
NaslovID
UlogaID

Int4 ref: Akteri

Int4 ref: Naslovi
Int1 ref: Uloge

Uloge
#
*
Total:

UlogaID
Uloga

Int1
varchar(30)

PosudbeKaseta
#$
#$
#
o
o
Total:

KasetaID
ClanID
DatumIzdavanja
PlaniraniDatumVracanja
DatumVracanja

Int4 ref: Kasete

Int4 ref:Clanovi
smalldatetime
smalldatetime
smalldatetime

Max
duina
4
4
4
4
4
20

Prosjena
duina
4
4
4
4
4
20

Pojanjenje:
-

varchar(n) je varijabilni tekst maksimalne duine n znakova, s tim da stvarno

zauzeti prostor odgovara broju stvarno unijetih znakova (+ m byte-ove za
zapis duine teksta).
Int1 1 byte-ni cio broj, 0 ... 255 ili 128 ...0 ... 127, ovisno bazi
Int2 2 byte-ni cio broj, -32786 ...0 ... 32767
Int4 4 byte-ni cio broj ( -2**31 ...0 ... 2**31 1 )
Autoident baza generira broj kod insertiranja zapisa
smalldatetime zapis datuma, nain zapisa ovisi o bazi, rezolucija reda
minuta, ( kod MS SQL Server 2000, 4 byte)
* - Obvezan unos, Null vrijednost nije doputena
$ - Strani klju
ref Referentna tablica
o unos nije obvezan, doputena je Null vrjednost

47
-

# - dio primarnog kljua, unos obvezan

Maksimalna i oekivana duina slue kao podloga za izraunavanje potrebnog

prostora za pohranu tablica.

3.5 Model entiteti veze ( MS SQL Server 2000)

3.6 Funkcije ( metode )

lanovi
- Upis novog lana
- Promjena podataka lana
- Brisanje lana
- Traenje
Naslovi
- Upis novog naslova
- Promjena podatakao o naslovu
- Brisanje naslova
- Traenje
Kasete
- Upis nove kopije
- Promjena stanja kopije ( ukljuuje otpis datoteke )
- Traenje
Akteri

48
-

Upis
Promjena
Brisanje
Traenje

Izdavanje vraanje kaseta

- Izdavanje
- Vraanje

3.7 Impementacija objekata baze podataka primjer dviju

tablica ( Microsoft SQL Server 2000 ):
CREATE TABLE [dbo].[Akteri] (
[AkterID] [int] IDENTITY (1, 1) NOT NULL ,
[Ime] [varchar] (30) NULL ,
[Prezime] [varchar] (30) NOT NULL ,
[DatumRodjenja] [smalldatetime] NULL
) ON [PRIMARY]
CREATE TABLE [dbo].[Clanovi] (
[ClanID] [int] IDENTITY (1, 1) NOT NULL ,
[Ime] [varchar] (30) NOT NULL ,
[Prezime] [varchar] (30) NOT NULL ,
[DatumRodjenja] [smalldatetime] NULL ,
[JMBG] [bigint] NULL ,
[PostaID] [int] NOT NULL ,
[Ulica] [varchar] (50) NOT NULL ,
[Kbr] [smallint] NOT NULL ,
[KbrDodatak] [varchar] (10)NULL ,
[Kat] [smallint] NULL ,
[TelefonOperater] [smallint] NULL ,
[TelefonBroj] [int] NOT NULL ,
[email] [varchar] (100) NULL
) ON [PRIMARY]
ALTER TABLE [dbo].[Akteri] WITH NOCHECK ADD
CONSTRAINT [PK_Akteri] PRIMARY KEY CLUSTERED
(
[AkterID]
) ON [PRIMARY]
ALTER TABLE [dbo].[Clanovi] WITH NOCHECK ADD
CONSTRAINT [PK_Clanovi] PRIMARY KEY CLUSTERED
(
[ClanID]
) ON [PRIMARY]

49

4 Indeksi
Pojasnimo najprije pojam indeksa, primjerom. elimo pronai znaenje engleske
rijei event. U englesko hrvatskom rjeniku, u zaglavlju svake stranice su
napisane poetna i zavrna rije koje se nalaze na toj stranici. Brzo listamo stranice,
gledajui samo zaglavne rijei i pronalazimo onu na kojoj u zaglavlju stoji: even ...
excess. Kako se rije event u abecednom poretku nalazi izmeu ove dvije rijei,
zadravamo se na toj stranici i pronalazimo traenu rije (sa znaenjem dogaaj).
Dakle, rije smo pronali brzo, zato to su sve rijei u rijeniku poredane po
abecednom redu engleskih rijei. Kaemo da je rjenik indeksiran po engleskim
rijeima. Kada bi ovaj isti englesko-hrvatski rjenik upotrijebili za nalaenje
engleskog prijevoda hrvatske rijei nebo, morali bismo prelistati cijeli rjenik, jer
nije poredan po hrvatskim rijeima. Naravno, hrvatsko-engleski rjenik, koji sadri
iste rijei kao i prethodni, bi pomogao, jer je indeksiran po hrvatskim rijeima.
Ovakvu vrstu indeksa, kod kojeg su podaci fiziki poredani po indeksiranoj koloni (ili
kolonama), sustav MS SQL Server naziva klasterirani indeks. Jasno je da se podaci
fiziki mogu poredati samo na jedan nain, pa je isto tako mogu samo jedan
klasterirani indeks u tablici. Ova vrsta indeks pomae kod pretraivanja podruja
(ranga) vrijednosti.
Potraimo sada u knjizi R. Vujnovi SQL i relacijski model podataka, pojanjenje
pojma indeksiranje. Na kraju knjige pronalazimo indeksno kazalo, te pod slovom
I, indeksiranje, 151. Dakle, na stranici 151 zapoinje pojanjenje pojma, te brzo
pronalazimo stranicu s traenim podatkom. Ovakav indeks podravaju i sustavi
relacijskih baza, a MS SQL Server ga naziva neklasterirani indeks. Moe se definirati
vei broj indeksa ovog tipa i svaki od njih moe ukljuiti jednu ili vie kolona.
Pogledajmo primjer organizacije podataka ( MS SQL Server 2000, no slino podatke
organiziraju i ostali sustavi) na mediju za pohranu. Poznato je da se podaci itaju i
zapisuju, dakle prenose u radnu memorije, u kvantima, stranicama.
Stoga i baze podataka organiziraju podatke po stranicama, kako bi koristile uslugu
operacijskog sustava na sukladan nain. Stoga su i podaci zapisani u jednoj tablici,
zapravo razbacani po stranicama, koje mogu biti na bilo kojem cilindru diska.
Primjer organizacije tablice Studenti(Ime, Prezime, Spol) slijedi. Poredani su po
stranicama stohastiki, kako su dodavani u tablicu, jer nije definiran indeks.
elimo pronai sve studente s prezimenom izmeu Horvat i Koti, ukljuivo i njih
same, zato jer svi one obavljaju vjebe kao lanovi grupe B. SQL upit e biti:
SELECT * FROM Studenti
WHERE Prezime BETWEEN 'Horvat' AND 'Koti'
Kako tablica nije indeksirana, RDBMS e krenuti od prvog zapisa na prvoj stranici,
usporeivati da li prezime nalazi u zadanom intervalu, te ga prikazati, nastavljajui
zapis po zapis sve do zadnjeg zapisa na zadnjoj stranici. Ovakvo pretraivanje

50
zovemo potpuno pretraivanje tablice (full table scaning). Kod tablica s velikim
brojem zapisa, uzima znaajno vrijeme i odziv je spor.
Stranica
1

Zapis
1
2
3
4

Ime
Ivo
Ante
Jure
Anica

Prezime
Ivi
Peri
Padovan
Zubi

Spol
M
M
M
Z

1
2
3

Damir
Kristian
Marina

Kelava
Brunner
Bajramovi

M
M
Z

1
2
3
4

Ivica
Slavko
Slavica
Miranda

Tomi
Dekovi
Perovi
Poljak

M
M
Z
Z

1
2
3
4
5

Ivan Goran
Ivana
Nikolina
Mate
Pako

Peni
Mari
Metovi
Anti
Ivankovi

M
Z
Z
M
M

1
2
3

Domagoj
Hrvoje
Danijela

Horvat
Orlandini
Klisovi

M
M
Z

1
2
3
4

Ana
Ivana
Domina
Kata

Beli
Zubovi
Aljinovi
Rei

Z
Z
Z
Z

1
2
3

Doris
Mario
Franka

Koti
Lojpur
Dodi

Z
M
Z

Kreiramo li klasterirani indeks po koloni Prezime, podaci e biti reorganizirani po

stranicama i poredni po abecedi prezimena, kako prikazuje donja slika. Pri tome, se
kreira korijen indeksa, u naem primjeru sa dva zapisa, koji senalaze na stranici 14. i
koji dijele itavu sortiranu tablicu u dva podjednaka dijela. Ovi zapisi pokazuju na
srednju razinu indeksa, odnosno da se Prezime Aljinovi nalazi na stranici 15. srednje
razine indeksa, a Lojpur na stranici 16. Srednja razina indeksa dijeli tablicu na jo
manje segmente, pokazujui stranicu slijedee razine koja sadri isti podatak.
Konano, zadnja razina klasteriranog indeksa sadri same podatke.
Napomenimo da ovako klasterirani indeks kreira sustav za upravljanje relacijskom
bazom Microsoft SQL Server 2000. Neki drugi sustavi ne poznaju ovaj tip indeksa, te
tovie pod istim nazivom klasterirani indeks mogu podrazumijevati potpuno
drukiju strukturu, no smatram da je korisnije pokazati organizaciju indeksa na
konkretnom primjeru izabrane baze.

51

Klasterirani indeks: Prezime

Posljednja razina ( leaf)
Str Zap Ime
Prezime
Spol
1 Domina
Aljinovi
Z
2 Mate
Anti
M
1
3 Marina
Bajramovi Z
Srednja razina ( intermediate)
Str
Na str
Aljinovi
1
15
Beli
2
Dodi
3
Kelava
4

Korijen (root)
Na str
15
14 Aljinovi
Lojpur
16

Str

Str
Lojpur
16
Padovan
Poljak
Zubi

Na str
5
6
7
8

1
2
3

Ana
Kristian
Slavko

Beli
Brunner
Dekovi

Z
M
M

1
2
3
4

Franka
Domagoj
Pako
Ivo

Dodi
Horvat
Ivankovi
Ivi

Z
M
M
M

1
2
3

Damir
Danijela
Doris

Kelava
Klisovi
Koti

M
Z
Z

1
2
3
4

Mario
Ivana
Nikolina
Hrvoje

Lojpur
Mari
Metovi
Orlandini

M
Z
Z
M

1
2
3
4

Jure
Padovan
Ivan Goran Peni
Ante
Peri
Slavica
Perovi

M
M
M
Z

1
2
3

Miranda
Kata
Ivica

Poljak
Rei
Tomi

Z
Z
M

1
2

Anica
Ivana

Zubi
Zubovi

Z
Z

Kako se trai prezime Horvat ?

Polazi se od korjena indeksa i pronalazi da je Horvat vee od Aljinovi i manje
od Lojpur, pa se slijedi zadnji pokaziva od kojeg nije manji ( tj. vee ili jednako),
dakle Aljinovi i odlazi na stranicu 15. Tu se pronalazi da je Horvat vee od
Dodi i manje od Kelava, pa se slijedi pokaziva od Dodi i odlazi na stranicu
3. Zatim se pronalazi Horvat, prikazuje i nastavlja po zapisima u slijedu i prezime
usporeuje s Koti, prikazujui ih, sve dok je prezime manje ili jednako Koti.
Oito je ubrzanje traenja, jer broj srednjih razina nije velik, ak ni kod velikih
tablica.
Pronaimo sada studenta s imenom Ivo.

52
Indeks: Ime

Srednja razina(interm)
Str Ime
Na str
Ana
23
21
Doris
24

Zadnja razina ( leaf)

Str
Ime
Ana
Anica
23
Ante
Damir

Na str
2
8
6
4
4
3
1

Zap
1
1
3
1
2
2
1

Ivana

Na str
4
3
5
6
5
8

Zap
3
1
4
2
2
2

Ivica
Ivo
Jure
Kata
Kristian
Marina
Mario

Na str
7
3
6
7
2
1
5

Zap
3
4
1
2
2
3
1

Mate
Miranda
Nikolina
Pako
Slavica
Slavko

1
7
5
3
6
2

2
1
3
3
4
3

Danijela
Domagoj
Domina
Str

24
Korijen(root)
Str Ime
Na str
21
20 Ana
Ivica
22

Doris
Franka
Hrvoje
Ivan Goran
Ivana

Str
25

Str
Ivica
22
Mate

Na str
25
26
Str

26

Indeks po koloni Prezime nam ne pomae u pronalaenju imena. Zato kreirajmo

indeks po koloni Ime. Indeks ponovo ima korijen, srednje razine, te posljednju razinu,
koja pokazuje na stranicu i zapis na kojoj se nalaze svi podaci studenta kojem je ime
Ivo.
Dakle, Ivo je vei od Ivica, no kako je to posljedni zapis na stranici korjena,
slijedi se pokaziva od Ivica i odlazi na stranicu 22. srednje razine indeksa. Tu je
Ivo vei od Ivica, ali manji od Mate, pa se odlazi na stranicu 25, gdje se
pronalazi Ivo, jer zadnja razina uvijek sadri sve zapise indeksiranih kolona cijele
tablice i odlazi na stranicu 3, zapis 4, to je kompletan zapis studenta s imenom Ivo.
Ovakva struktura indeksa se naziva B-tree,tj. uravnoteeno stablo (eng. balanced
tree). Karakterizira je da uvijek dijeli ciljelu tablicu na priblino jednake segmente, a
to znai da se nakon svake promjene podataka u tablici, koji obuhvaaju i indeksne
kolone, stablo mora reorganizirati. Naravno, to uzima vrijeme, pa je jasno da indeks
ubrzava traenje, ali usporava izmjene: dodavanje, auriranje ili brisanje zapisa. Stoga
je vano kreirati razuman broj indeksa, prema iskustvima iz prakse 5-7 i njima
zadovoljiti esto izvoene upite.

53
Potraimo sada sve zapise koji imaju vrijednost kolone Spol = Z. Sada nam ne
pomae ni jdan ni drugi indeks, pa e se pretraivati cijela tablica.
Da li bi nam pomogao neklasterirani indeks po koloni Spol ? Nebi, jer je 50% zapisa s
vrijednou Z, pa bi pretraivanje stabla indeksa vie trajalo, nego potpuno
pretraivanje tablice. Ova vrsta indeksa je korisna, ako su podaci dobro distribuirani,
dakle ako se ista vrijednost pojavljuje u 5 10 % sluajeva ( dakako, toan postotak
ovisi o baznom sustavu i konkretnoj tablici).

54

5 SQL Upitni jezik

5.1 Uvod
SQL jezik inovirala je tvrtka IBM, polazei od osnovnih operacija relacijskih baza
podataka, kako ih je definirao Codd . SQL je neproceduralni jezik IV generacije. Pod
time se podrazumijeva, da nije potrebno definirati korake ( proceduru) izvoenja,
nego se definira to elimo kao rezultat i nain kako e rezulatat biti prikazan.
Naredbe jezika dijele se u dvije skupine:
DML
DDL

Data
Manipulation
Language
Data
Definition
Language

Komande za traenje, umetanje, izmjene i brisanje

podataka.
Komande za definiciju objekata ( tablica, indeksa, pgleda )
relacijske baze podataka.

5.2 Upiti u relacijskoj bazi podataka

5.2.1 Projekcija i restrikcija
Definirana je relacija ( tablica ) u relacijskoj bazi Studenti, s atributima ( kolonama ):
Ime
Prezime
DatumRodjenja
StudijID
PostaID
Izlistajmo sadraj tablice i prikaimo ga na konzoli komandom:
SELECT * FROM Studenti;
Rezulta ovog upita je:
Ime
Prezime DatumRodjenja StudijID
Ivo
Ivic
22.06.1981
Ana
Matic
01.01.1980
Tomislav Butorovic
21.01.1982
Ana Marija Tomic
21.12.1981
Marko
Markovic
24.07.1981

PostaID
1
21000
1
22000
1
21000
1
20000
2

55
Helena
Hrvoje
Ante

Topic
Antic
Zelic

05.08.1979
21.03.1981
08.09.1981

1
1

20000
23000
53000

Dakle, prikazane su sve kolone i svi retci tablice, pri emu je poredak redaka sluajan,
najee onim redom kako su retci upisivani u tablicu.
esto nam nisu potrebne sve kolone, pogotovu kod tablica s veim brojem kolona.
Kolone koje elimo prikazati pobrojimo poslije kljune rijei SELECT, pa komanda
kojom emo prikazati samo Ime i Prezime studenta izgleda:
SELECT Ime, Prezime FROM Studenti;
Rezultat izvoenja komande je:
Ime
Ivo
Ana
Tomislav
Ana Marija
Marko
Helena
Hrvoje
Ante

Prezime
Ivic
Matic
Butorovic
Tomic
Markovic
Topic
Antic
Zelic

esto elimo prikaz samo nekih redaka tablice i to onih koji zadovoljavaju odreeni
uvjet. Prikaimo Ime i Prezime studenata koji su upisani na studij Matematike
Informatike. Pregledom tablice Studiji:
SELECT * FROM Studiji;
StudijID

Studij
1 Matematika - Informatika
2 Tehnicka kultura - Informatika
3 Matematika
4 Matematika - Fizika
5 Biologija - Kemija

nalazimo, da studij Matematike Informatike ima oznaku StudijID=1. Tako e upit za

prikaz imena i prezimena studenata Matematieke Informatike biti:
SELECT Ime, Prezime
FROM Studenti
WHERE StudijID=1
Ime
Ivo
Ana
Tomislav

Prezime
Ivic
Matic
Butorovic

Konano, elimo studente Matematike Informatike ali po abecednom redu

prezimena:

56

SELECT Ime, Prezime

FROM Studenti
WHERE StudijID=1
ORDER BY Prezime
Ime
Tomislav
Ivo
Ana

Prezime
Butorovic
Ivic
Matic

Dakle, SQL upitna komanda nad jednom tablicom ima opi oblik:
SELECT Kolona1, Kolona2, Kolona... | *
FROM Tablica
[ WHERE uvjet ]
[ ORDER BY Kolona2 [DESC], Kolona [DESC]... ]
pri emu je redoslijed kolona proizvoljan i u SELECT klauzuli i u ORDER BY
klauzuli. elimo li prikazati sve kolone tablice u poretku kako je tablica definirana,
moemo upotrijebiti simbol zvjezdice ( * ) koji ukljuuje sve kolone. Uvjet u
WHERE klauzuli mora za svaki redak rezultirati s jednom od dvije mogue
vrijednosti: ISTINA ili LA. Prikazani e biti oni retci ija je vrijednost ISTINA.
SELECT klauzula provodi relacijsku operaciju projekcije, a WHERE provodi
operaciju restrikcije. Kada restrikcija nije potrebna, tj. ele li se prikazati svi reci,
onda se WHERE klauzula isputa ( uglate zagrade u gornjoj definiciji), jednako kao i
ORDER BY klauzula, kada poredak nije eksplicitno definiran.
Kako Sustav za upravljanje relacijskom bazom podataka ( RDBMS ) izvodi ovaj upit
(tablica nema definiranih indeksa ):
Prevede upit u niz poziva primitivnih procedura
Utvrdi optimalan slijed izvoenja
Kako nema definiranih indeksa ( ili kada je tablica s malim brojem redaka) izvodi
potpuno skeniranje tablice, dakle kree od prvog do posljednjeg retka
Stvori privremenu radnu tablicu, s kolonama
- Ime varchar(50)
- Prezime varchar(50)
uzimajui definiciju kolona iz temeljne tablice Studenti
Proita prvi redak tablice Studenti i ako je vrijednost kolone StudijID=1, upie
vrijednosti Ime i Prezime u radnu tablicu. U sluaju da StudijID nije 1, ide na
slijedei redak.
Poreda retke u radnoj tablici po abecednom redu prezimena
Ispie rezultat u prozoru konzole

57

5.2.2 Prirodno spajanje

Nedostatak gornjih upita je taj, to brojane oznake StudijID nisu dovoljno opisne, tj.
iako vidimo oznaku studija, ne znamo o kojem se studiju radi, naravno, ne elimo li
stalno traiti naziv studija u tablici Studiji. Na sreu, SQL upitni jezik provodi i
operaciju prirodnog spajanja dviju ili vie tablica:
SELECT Ime, Prezime, Studenti.StudijID, Studiji.*
FROM Studenti, Studiji
ORDER BY Prezime
1
2
3
4
5
6
7
8

Ime
Hrvoje
Hrvoje
Hrvoje
Hrvoje
Hrvoje
Tomislav
Tomislav
Tomislav

Prezime StudijID StudijID

Antic
2
Antic
2
Antic
2
Antic
2
Antic
2
Butorovic
1
Butorovic
1
Butorovic
1

Studij
1 Matematika - Informatika
2 Tehnicka kultura - Informatika
3 Matematika
4 Matematika - Fizika
5 Biologija - Kemija
1 Matematika - Informatika
2 Tehnicka kultura - Informatika
3 Matematika

Zelic
Zelic
Zelic

3 Matematika
4 Matematika - Fizika
5 Biologija - Kemija

--38
39
40

Ante
Ante
Ante

3
3
3

Rezultat ovog upita je relacija, prikazana kao Kartezijev produkt tablica Studenti i
Studiji. Dakle, svaki redak tablice Studenti je udruen sa svakim retkom tablice
Studiji. Kako Studenti sadri 8 redaka, a Studiji 5, to rezultantana tablica sadri 40
redaka. Uoavamo da neki retci ne sadre istinite podatke: student Hrvoje Anti je
upisan na studij 2 Tehnicka kultura Informatika ( lijeva kolona StudijID u tablici ), pa
povezivanje sa studijima 1, 3, 4 i 5 ne odgovara istini. Zato u pravilu, operaciju prirodnog
spajanja ograniavamo na retke koji sadre istinite podatke, dakle:

SELECT Ime, Prezime, Studenti.StudijID, Studiji.*

FROM Studenti, Studiji
WHERE Studenti.StudijID=Studiji.StudijID
ORDER BY Prezime
Ime
Prezime
Hrvoje
Antic
Tomislav Butorovic
Ivo
Ivic
Marko
Markovic
Ana
Matic
Ana Marija Tomic
Helena
Topic
Ante
Zelic

StudijID
2
1
1
2
1
3
2
3

StudijID
2
1
1
2
1
3
2
3

Studij
Tehnicka kultura - Informatika
Matematika - Informatika
Matematika - Informatika
Tehnicka kultura - Informatika
Matematika - Informatika
Matematika
Tehnicka kultura - Informatika
Matematika

Rezultat upita je virtualna tablica, pod ime se misli da ne postoji njen fiziki zapis
na mediju, npr. disku, nego se dinamiki izgrauje pri izvoenju upita.
Uobiajeni naziv za ovakav oblik spajanja tablica je spajanje jednakosti ( eng.
equi join).

58

5.2.3 Vanjsko ( Outer Join ) spajanje

Izvedimo slian upit, kojim emo prikazati ime, prezime, potanski broj i naziv pote
studenta:
Ime
Hrvoje
Tomislav
Ivo
Ana
Helena
Ante

Prezime PostaID PostaID Posta

Antic
23000
23000 Zadar
Butorovic
21000
21000 Split
Ivic
21000
21000 Split
Matic
22000
22000 Sibenik
Topic
20000
20000 Dubrovnik
Zelic
53000
53000 Gospic

Naalost, umjesto oekivanih 8 redaka, tablica ne sadri retke:

Ana Marija
Marko

Tomic
Markovic

Razlog lei u nedefiniranim potanskim brojevima ( prigodom prijave, studenti nisu

prijavili adresu, jer su bili u fazi preseljenja ). No, mi elimo prikazati sve studente,
ak i ako nije definiran potanski broj. Naravno, ako pota nije poznata, nee biti
ispisana.
SELECT Ime, Prezime, Studenti.PostaID, Poste.*
FROM Studenti
LEFT OUTER JOIN Poste ON Studenti.PostaID=Poste.PostaID
ORDER BY Prezime
Ime
Prezime PostaID PostaID Posta
Hrvoje
Antic
23000
23000 Zadar
Tomislav Butorovic
21000
21000 Split
Ivo
Ivic
21000
21000 Split
Marko
Markovic NULL
NULL
NULL
Ana
Matic
22000
22000 Sibenik
Ana Marija Tomic
NULL
NULL
NULL
Helena
Topic
20000
20000 Dubrovnik
Ante
Zelic
53000
53000 Gospic

Engleski termin ovog oblik spajanja je LEFT OUTER JOIN, to moemo prevesti kao
spajanje slijeva, a prikazuje sve retke u tablici s lijeve strane kljune rijei
( Studenti ) . Svaki redak tablice Studenti e pokuati spojiti s tablicom Poste preko
identinih vrijednosti kolona PostaID i prikazati naziv pote, kad god je spajanje
uspjeno, odnosno NULL vrijednost kad spajanje nije mogue.
Vrijednost NULL tumaimo kao nedefinirana ili nepoznata vrijednost.

59
Kako Sustav za upravljanje relacijskom bazom podataka ( RDBMS ) izvodi ovaj upit
(tablice nemaju definirane indekse ):
Prevede upit u niz poziva primitivnih procedura
Utvrdi optimalan slijed izvoenja
Kako nema definiranih indeksa ( ili kada je tablica s malim brojem redaka) izvodi
potpuno skeniranje tablice, dakle kree od prvog do posljednjeg retka tablice
Studenti
Stvori privremenu radnu tablicu, s kolonama
- Ime varchar(50)
- Prezime varchar(50)
- PostaID int ( iz tablice Studenti)
- PostaID int ( iz tablice Poste)
- Posta varchar(50)
uzimajui definiciju kolona iz temeljnih tablica Studenti i Poste
Proita prvi redak tablice Studenti i upie vrijednosti u radnu tablicu:
Ivo

Ivic

21000

Pretrai tablicu Poste, poev od prvog retka za vrijednost

Poste.PostaID=Studenti.PostaID, odnosno dok ne pronae PostaID=21000
Upie u redak radne tablice PostaID ( 21000 ) i Posta ( Split )
Ponovlja postupak itanja svih redaka
Poreda retke u radnoj tablici po abecednom redu prezimena
Ispie rezultat u prozoru konzole
Isto tako, mogue je spojiti tablicu s desna:
SELECT Studiji.*, Ime, Prezime
FROM Studenti
RIGHT OUTER JOIN Studiji ON Studenti.StudijID=Studiji.StudijID
ORDER BY Studiji.StudijID
StudijID
1
1
1
2
2
2
3
3
4
5

Studij
Matematika - Informatika
Matematika - Informatika
Matematika - Informatika
Tehnicka kultura - Informatika
Tehnicka kultura - Informatika
Tehnicka kultura - Informatika
Matematika
Matematika
Matematika - Fizika
Biologija - Kemija

Ime
Prezime
Ivo
Ivic
Ana
Matic
Tomislav Butorovic
Marko
Markovic
Helena
Topic
Hrvoje
Antic
Ana Marija Tomic
Ante
Zelic
NULL
NULL
NULL
NULL

Ovim upitom prikazuju se sve mogue studijske grupe, te studenti onih studijskih
grupa koje imaju upisane studente. Studiske grupe bez studenata, isto tako su
navedene, ali naravno bez pridruenih studenata.

60

5.2.4 Unutranje ( Inner Join ) spajanje

U nekim prilikama, ipak elimo prikaz samo onih redaka koji se mogu spojiti s
odgovarajuim recima druge tablice. Recimo, kada trebamo uputiti pisma na adrese
studenata, studenti bez adrese trebaju biti isputeni iz prikaza:
SELECT Ime, Prezime, Studenti.PostaID, Posta
FROM Studenti
INNER JOIN Poste ON Studenti.PostaID=Poste.PostaID
ORDER BY Prezime
Ime
Hrvoje
Tomislav
Ivo
Ana
Helena
Ante

Prezime
Antic
Butorovic
Ivic
Matic
Topic
Zelic

PostaID Posta
23000 Zadar
21000 Split
21000 Split
22000 Sibenik
20000 Dubrovnik
53000 Gospic

Isti rezulata se dobije i primjenom Equi-join spajanjem, no ipak INNER JOIN

zapis potpunog spajanja ima prednost, jer u komandi jasno razlikuje klauzulu
restrikcije WHERE od spajanja INNER JOIN.
Dakle, sintaksa potpune upitne komande koja izvrava projekciju, potpuno i
nepotpuno spajanje, restrikciju i odreivanje poretka je:
SELECT Kolona1, Kolona2, ...
FROM Tablica1
[ INNER JOIN Tablica2 ON Kolona3=Kolona4 AND Kolona5=Kolona6 ]
[ LEFT OUTER JOIN Tablica3 ON Kolona7=Kolona8 AND ... ]
[ WHERE uvjet ]
[ ORDER BY Kolona1 [ ASC | DESC ], Kolona2 [ ASC | DESC ], ... ]

5.2.5 Funkcije u SQL Upitu

esto trebamo neke izraunate podatke, ija se vrijednost temelji na baznim
podacima, upisanim u tablici.
Prikaimo ime i prezime studenata u jednoj koloni, spajanjem kolona ime i prezime,
te ukupni broj slova imena i prezimena ( razmak nije ukljuen). Retke je potrebno
poredati po duini teksta, tako da student s najduim imenom i prezimenom bude na
vrhu poretka:
SELECT Prezime + ' ' + Ime, LEN(Prezime + Ime)
FROM Studenti
ORDER BY LEN(Prezime + Ime) DESC

61

Ime Prezime
Duina Ime i Prezime
Butorovic Tomislav
Tomic Ana Marija
Markovic Marko
Topic Helena
Antic Hrvoje
Zelic Ante
Matic Ana
Ivic Ivo

17
15
13
11
11
9
8
7

Kljuna rije DESC ( DESCEDING ) oznaava inverzni poredak prikazane tablice.

Predefiniran je poredak od manje vrijednosti prema veoj ASC ( ASCEDING ) i nije
ga potrebno navoditi.
Neke esto koritene funkcije:
Sintaksa
LEFT( Tekstualni izraz, n )
RIGHT( Tekstualni izraz,
n)
SUBSTRING( Tekstualni
izraz, S, D)
LEN( Tekstualni izraz )

Opis
Izdvaja n pozicija s lijeva iz tekstualnog izraza
( obino tekstualna kolona tablice)
Izdvaja n pozicija s desna iz tekstualnog izraza
( obino tekstualna kolona tablice)
Izdvaja D znakova iz tekstualnog izraza, poev od
pozicije S izraza
Daje duinu ( broj slova ) tekstualnog izraza

Primjeri:
a) Prikazati poetno slovo imena ( inicijal ) i prezime u jednoj koloni.
SELECT LEFT(Ime, 1) + '. ' + Prezime
FROM Studenti
Inicijal Prezime
I. Ivic
A. Matic
T. Butorovic
A. Tomic
M. Markovic
H. Topic
H. Antic
A. Zelic

b) Prikazati dva posljednja slova prezimena studenta

SELECT RIGHT(Prezime, 2), Prezime
FROM Studenti
2 zadnja slova

Prezime

62
prezimena
ic
ic
ic
ic
ic
ic
ic
ic

Ivic
Matic
Butorovic
Tomic
Markovic
Topic
Antic
Zelic

c) Prikazati 3 slova imena studenta, poev od 3. slova

SELECT SUBSTRING(Ime, 3, 3 ), Ime
FROM Studenti
3 slova poev od
3. Pozicije
o
a
mis
aM
rko
len
voj
te

Ime
Ivo
Ana
Tomislav
Ana Marija
Marko
Helena
Hrvoje
Ante

d) Prikazati sve studente ije je ime=Ivo'

SELECT *
FROM Studenti
WHERE Ime='Ivo'
Ime
Ivo

Prezime
Ivic

DatumRodjenja StudijID PostaID

22.06.1981
1
21000

e) Prikazati sve studente ije ime sadri slovo i na bilo kojoj poziciji.
SELECT *
FROM Studenti
WHERE Ime LIKE '%i%'
Ime
Ivo
Tomislav
Ana Marija

Prezime
Ivic
Butorovic
Tomic

DatumRodjenja StudijID PostaID

22.06.1981
1
21000
21.01.1982
1
21000
21.12.1981
3 NULL

f) Prikazati sve studente kojima naziv pote sadri slovi i na bilo kojoj poziciji.
SELECT Ime, Prezime, Studenti.PostaID, Posta
FROM Studenti

63
LEFT OUTER JOIN Poste ON Studenti.PostaID=Poste.PostaID
WHERE Posta LIKE '%i%'
Ime
Ivo
Ana
Tomislav
Helena
Ante

Prezime
Ivic
Matic
Butorovic
Topic
Zelic

PostaID
Posta
21000 Split
22000 Sibenik
21000 Split
20000 Dubrovnik
53000 Gospic

g) Prikazati sve studente kojima naziv pote sadri slovi i na bilo kojoj poziciji.
SELECT Ime, Prezime, Studenti.PostaID, Posta
FROM Studenti
LEFT OUTER JOIN Poste ON Studenti.PostaID=Poste.PostaID
WHERE Posta NOT LIKE '%i%'
Ime
Hrvoje

Prezime
Antic

PostaID

Posta
23000 Zadar

h) Prikazati ime, prezime i duinu imena svim studentima, ije je ime due od 5 slova.
Poredati po duini imena.
SELECT Ime, Prezime, LEN(Ime)
FROM Studenti
WHERE LEN(Ime) > 5
ORDER BY LEN(Ime)
Ime
Helena
Hrvoje
Tomislav
Ana Marija

Prezime
Topic
Antic
Butorovic
Tomic

Duzina
Imena
6
6
8
10

g) Prikazati ime i prezime studenta u jednoj koloni, te svaku pojavu malog slova a,
zamijeniti velikim slovom A.
SELECT REPLACE(Ime + ' ' + Prezime, 'a', 'A')
FROM Studenti
Ime Prezime
Ivo Ivic
AnA MAtic
TomislAv Butorovic
AnA MArijA Tomic
MArko MArkovic
HelenA Topic
Hrvoje Antic
Ante Zelic

64

5.2.6 Grupiranje podataka i sumarna izraunavanja

a) Zanima li nas koliko imamo ukupno studenata u tablici Studenti, izvest emo upit:
SELECT count(*)
FROM Studenti
(No column name)
8

Dakle, count(*), pri emu * da nas zanima broj redaka, bez obzira na definiranu
vrijednost kolona, e izbrojati ukupni broj redaka tablice.
Umetnemo li redak koji sadri iskljuivo nedefinirane vrijednosti ( to je u suprotnosti
s pravilima relacijskih baza ), broj redaka bit e 9.
b) Ispiimo sada ukupni broj studenta, te broj studenata koji imaju definiranu adresu
(PostaID):
SELECT count(*) As BrojStudenata, count(PostaID) As ImaDefiniranuAdresu
FROM Studenti
BrojStudenata ImaDefiniranuPostu
8
6

c) Ispiimo broj studenata na svakoj studijskoj grupi. Grupe na kojima nema upisanih
studenata nije potrebno prikazati, te poredati prema broju studenata na grupi, poev
od najbrojnije grupe:
SELECT StudijID, count(*)
FROM Studenti
GROUP BY StudijID
ORDER BY count(*) DESC
StudijID

count(*)
1
2
3

3
3
2

Kako programski sustav za upravljanje relacijskom bazom podataka( RDBMS) izvodi

ovaj upit ( Pretpostavka je da tablica nije indeksirana):
RDBMS prevede definiranu komandu SQL upita u niz poziva primitivnih
procedure
Izrauna optimalan redoslijed izvoenja primitiva

65
U bazi za privremene radne tablice stvori tablicu ije su kolone:
StudijID smallint ( Uzima definiciju kolone iz polazne tablice )
Count1 int
Krene od prvog retka tablice Studenti i upie vrijednost StudijID ( 1 ) u radnu
tablicu, te brojakoj koloni Count dodijeli vrijednost 1.
Prelazi na slijedei redak i ponovno pronalazi StudijID=1. Kako oznaka studija
postoji u radnoj tablici, uvea broja pojava Count za 1, te on sada iznosi 2.
Prelazi na slijedei redak i pronalazi StudijID=2, te stvori novi redak s brojaem
na inicijalnoj vrijednosti 1.
Ove korake ponavlja sve do posljednjeg redka tablice, te svaki put kada naie na
veijednost StudijID, koja ne postoji u tablici, stvori redak. Ako oznaka studija
postoji u radnoj tablici, uveava joj broja za 1.
Sortira retke radne tablice od najvee do najmanje vrijednosti brojake kolone.
d) Gore dobiveni rezultat je ispravan, ali nije razumljiv, jer oznake studija nisu
deskriptivne. Zato bismo radije itali rezultat uz puni naziv studijske grupe, pa zato
moramo spojiti tablicu Studiji, gdje se opisi nalaze:
SELECT Studij, count(*) As BrojStudenata
FROM Studenti S
INNER JOIN Studiji ST ON S.StudijID=ST.StudijID
GROUP BY Studij
ORDER BY count(*) DESC
Studij
BrojStudenata
Matematika - Informatika
Tehnicka kultura - Informatika
Matematika

3
3
2

e) Zahtijeva li se prikaz samo onih studijskih grupa, na kojima je opisano vie od 2

studenta, upit e biti:
SELECT Studij, count(*) As BrojStudenata
FROM Studenti S
INNER JOIN Studiji ST ON S.StudijID=ST.StudijID
GROUP BY Studij
HAVING count(*) > 2
ORDER BY count(*) DESC
Studij
BrojStudenata
Matematika - Informatika
Tehnicka kultura - Informatika

3
3

Dakle, uvjet koji se odnosi na sumarne podatke definira se u klauzuli HAVING.

f) elimo li pak, ispisati sve studijske grupe, te ukupan broj studenata upisan na svaku
studijsku grupu, ukljuujui i grupe na kojima nema upisanih studenata, upit e biti:

66
SELECT Studij, count(Ime)
FROM Studiji ST
LEFT OUTER JOIN Studenti S ON S.StudijID=ST.StudijID
GROUP BY Studij
ORDER BY Studij DESC
Studij

BrojStudenata

Biologija - Kemija
0
Matematika
2
Matematika - Fizika
0
Matematika - Informatika
3
Tehnicka kultura - Informatika 3
Uoimo, da count(Ime) osigurava da BrojStudenata bude 0, kada na Studiju nema
upisanih studenata, dok bi count(*) dao ispravan broj u sluaju da je barem jedan
student upisan na Studijsku grupu, ali bi isto tako dao vrijednost jedan i kad na grupu
nije upisan niti jedan student. U pravilu emo uvijek kada se tablice spajaju s OUTER
JOIN, upotrijebiti count( Kolona ).
g) Ispis studenata i njihovih prosjenih ocjena, dobit emo upitom:
SELECT Ime, Prezime, AVG(Ocjena*1.0)
FROM Studenti S
LEFT OUTER JOIN StudentiOcjene SO ON S.StudentID=SO.StudentID
GROUP BY Ime, Prezime
ORDER BY Prezime
Ime
Hrvoje
Tomislav
Ivo
Marko
Ana
Ana Marija
Helena
Ante

Prezime (no column name)

Antic
2.7500
Butorovic
4.0000
Ivic
4.0000
Markovic
2.7500
Matic
3.0000
Tomic
3.0000
Topic
4.0000
Zelic
3.7500

h) Isto tako, moemo ispisati sve studente, ija je prosjena ocjena vea ili jednaka
3.5:
SELECT Ime, Prezime, AVG(Ocjena*1.0) As ProsjenaOcjena
FROM Studenti S
LEFT OUTER JOIN StudentiOcjene SO ON S.StudentID=SO.StudentID
GROUP BY Ime, Prezime
HAVING AVG(Ocjena*1.0) >= 3.5
ORDER BY Prezime
Ime
Tomislav
Ivo
Helena

Prezime
Butorovic
Ivic
Topic

ProsjenaOcjena
4.0000
4.0000
4.0000

67
Ante

Zelic

3.7500

i) Konano, ispiimo sve studente s adresom 21000 ( Split ) koji imaju prosjenu
ocjenu 3.5 ili veu, te ukupan zbroj ocjena i prosjenu ocjenu svakog studenta, a
rezltate poredajmo po abecednom redu prezimena:
SELECT Ime, Prezime, PostaID, SUM(Ocjena) As ZbrojOcjena,
AVG(Ocjena*1.0) As ProsjenaOcjena
FROM Studenti S
LEFT OUTER JOIN StudentiOcjene SO ON S.StudentID=SO.StudentID
WHERE PostaID=21000
GROUP BY Ime, Prezime, PostaID
HAVING AVG(Ocjena*1.0) >= 3.5
ORDER BY Prezime

Ime
Tomislav
Ivo

Prezime
Butorovic
Ivic

5.2.7 ZbrojOcjena ProsjenaOcjena

PostaID
21000
21000

16
16

4.0000
4.0000

Uoimo da kod upita grupiranja, projekcija( klauzula SELECT ) sadri kolone iz

temeljnih tablica, kao Ime, Prezime i PostaID, te funkcije grupiranja,count(), SUM,
AVG. Operacija grupiranja ( klauzula GROUP BY ) mora sadravati sve kolone po
kojima se grupiranje obavlja, dakle, Ime, Prezime i PostaID. Isto tako, rezultat
grupiranja moe se sortirati samo po kolonama koje su navedene SELECT klauzuli,
jer one jedino i postoje u radnoj tablici, koja se naknadno sortira.

5.2.8 Logiki sloeni uvjeti

a) Ispiimo sve studente Studijske ije ime ili prezime zapoinje slovom a :
SELECT Ime, Prezime
FROM Studenti
WHERE Ime LIKE 'a%' OR Prezime LIKE 'a%'
Ime
Ana
Ana Marija
Hrvoje
Ante

Prezime
Matic
Tomic
Antic
Zelic

Uvjet e biti zadovoljen ako Ime ili prezime zapoinje slovom A, pa su ova dva uvjeta
povezana logikim operatorom OR.
b) Ispiimo sve studente kojima Ime zapoinje slovom A a prezime slovom Z:
SELECT Ime, Prezime

68
FROM Studenti
WHERE Ime LIKE 'a%' AND Prezime LIKE 'z%'
Ime
Ante

Prezime
Zelic

Uvjet je zadovoljen samo u sluaju kada ime zapoinje slovom A, a prezime slovom Z,
pa su ova dva uvjeta vezana logikim operatorom AND.
c) Prikaimo studente, ije ime NE zapoinje slovomA i prezime zapoinje
slovom A:
SELECT Ime, Prezime
FROM Studenti
WHERE Ime NOT LIKE 'A%' AND Prezime LIKE 'A%'
Ime
Hrvoje

Prezime
Antic

Bilo koji od logikih izraza moe biti negiran, odnosno, rezultirat e istinom kada nenegirani uvjet daje la.
d) Potrebno je izlistati sve studente, kojima ima ili prezime zapoinje slovom A,
a da im je PostaID=22000:
SELECT Ime, Prezime, PostaID
FROM Studenti
WHERE Ime LIKE 'A%' OR Prezime LIKE 'A%' AND PostaID=22000
Ime
Ana
Ana Marija
Ante

Prezime
Matic
Tomic
Zelic

PostaID
22000
NULL
53000

Gornji upit nije dao oekivani rezultat, jer vidimo da samo jedan od tri studenta
prebiva na PostaID=22000. Problem je uzrokovan logikim povezivanjem
elementarnih uvjeta. Naime, kao to kod raunskih operacija mnoenje ima vei
prioritet od zbrajanja, tako logiki operator AND ima vei prioritet od OR operatora.
Zato gornji uvjet zadovoljava svaki redak, im ime zapoinje slovo A.
Redoslijed razvijanja pojedinih elementarnih uvjeta moemo odrediti upotrebo
zagrada, pa je ispraljeni upit :
SELECT Ime, Prezime, PostaID
FROM Studenti
WHERE ( Ime LIKE 'A%' OR Prezime LIKE 'A%' ) AND PostaID=22000
Ime
Ana

Prezime
Matic

PostaID
22000

Uoavamo da se najprije izraunava vrijednost logikog izraza u zagradama.

69

5.2.9 Pobrojane vrijednosti

Ispiimo sve studente upisane na StudijID 1, 3 ili 5 :
SELECT Ime, Prezime, StudijID, PostaID
FROM Studenti
WHERE StudijID IN ( 1, 3, 5 )
Ime
Ivo
Ana
Tomislav
Ana Marija
Ante

Prezime
Ivic
Matic
Butorovic
Tomic
Zelic

StudijID

PostaID
1
21000
1
22000
1
21000
3 NULL
3
53000

Isti upit mogue je napisati ina ovaj nain:

SELECT Ime, Prezime, StudijID, PostaID
FROM Studenti
WHERE StudijID=1 OR StudijID=3 OR StudijID=5
Da se izbjegne ponavljanje imena kolone StudijID, prvi oblik upita, kod kojeg se
nabroji lista traenih vrijednosti, je mnogo prikladniji i razumljiviji, te se redovito
koristi. RDBMS izvodi oba upita na isti nain.

5.2.10

Ugnijeeni upiti

a) Prikaimo sve studente koji studiraju na istoj studijskog grupi kao student ije je
prezime Ivi.
Ovaj zadatak bismo mogli odraditi pomou dva uipta:
Upit 1:
SELECT StudijID
FROM Studenti
WHERE Prezime='Ivic'
Zatim oitamo vrijednost StudijID i izvedemo
Upit 2:
SELECT Ime, Prezime, StudijID
FROM Studenti
WHERE StudijID=1
Oba upita mogue je definirati kao jedinstveni, ugnijeeni upit:

70

SELECT Ime, Prezime, StudijID

FROM Studenti
WHERE StudijID IN (SELECT StudijID
FROM Studenti
WHERE Prezime='Ivic')
Ime
Ivo
Ana
Tomislav

Prezime StudijID
Ivic
1
Matic
1
Butorovic
1

Dakle, umjesto da pobrojimo konstantne vrijednosti, moemo definirati upit koji

vraa listu pobrojanih vrijednosti. Najprije se izvodi upit u zagradama, dakle
ugnijeeni, a zatim vanjski. Moe se ugnijezditi vei broj upita.
b ) Komplementarno gornjem upitu, moemo ispisati sve studente koji nisu upisani na
isti studij kao student Ivi:
SELECT Ime, Prezime, StudijID
FROM Studenti
WHERE StudijID NOT IN (SELECT StudijID
FROM Studenti
WHERE Prezime='Ivic')
Ime
Prezime StudijID
Ana Marija Tomic
3
Marko
Markovic
2
Helena
Topic
2
Hrvoje
Antic
2
Ante
Zelic
3

Uoimo, upotrebu kljune rijei NOT, kojom se oznaava da uvjet zadovoljavaju svi
studenti, ija je vrijednost StudijID razliita od 1, tj. nemaju StudijID isti kao student
Ivi.
esto se ugnjeuju upiti grupiranja, kao u primjeru:
c) Ispiimo sve studente, koji studiraju na studijskim grupama, na kojima je upisano
vie od 2 studenta.
SELECT Ime, Prezime, StudijID
FROM Studenti
WHERE StudijID IN (SELECT StudijID
FROM Studenti
GROUP BY StudijID
HAVING count(*) > 2)
Ime
Ivo

Prezime StudijID
Ivic
1

71
Ana
Tomislav
Marko
Helena
Hrvoje

Matic
Butorovic
Markovic
Topic
Antic

1
1
2
2
2

2.9 Jedinstvene vrijednosti redaka

a) elimo znati poetna slova ( inicijale ) imena studenata:
SELECT LEFT(Ime, 1)
FROM Studenti
ORDER BY 1
Inicijal
A
A
A
H
H
I
M
T

U sluaju velikog broja redaka u tablici, ovakav prikaz bi bio potpuno nepregledan, pa
elimo vidjeti samo jedinstvene pojave svakog slova, jer nas saznanje da imamo
jednog ili vie studenata ije ime zapoinje s A zadovoljava:
SELECT DISTINCT LEFT(Ime, 1)
FROM Studenti
ORDER BY 1
Inicijal
A
H
I
M
T

Kljuna rije DISTINCT oznaava da se retci s istom vrijednou svih kolona,

prokau samo jednom.
Kako RDBMS izvodi ovaj upit:
Stvori privremenu radnu tablicu s kolonama kako je navedeno u SELECT
klauzuli, dakle u naem primjeru, s jednom kolonom.
Izvodi upit pretraujui tablicu, provjeravajui zadovoljenje uvjeta ako postoji,
poziva funkciju LEFT, koja vraa prvo slovo imena.
Upisuje vrijednosti projeciranih kolona onih redaka koji zadovoljavaju uvjet u
radnu tablicu

72
Sortira retke u radnoj tablici po svim kolonama
Pretrai radnu tablicu ispisujui svaki put samo prvu pojavu retka, preskaui
retke koji imaju iste vrijednosti u svim kolonama, kao ve ispisani redak.
2.10

Null vrijednost

Pri upisu retka u tablicu, vrijednosti nekih kolona mogu biti nepoznate, te ih moramo
ostaviti nedefiniranim. Naravno, neke kolone moraju imati obavezno unijete
vrijednosti, pa se pri kreiranju tablice zahtijeva obavezan unos vrijednosti. U naem
primjeru tablice Studenti, ime, prezime i studijska grupa moraju biti unijete, a
PostaID, te datum roenja mogu ostati nedefinirane. Nedefinirana vrijednost naziva se
Null vrijednost.
a) Ispiimo sve studente koji imaju PostaID = Null :
SELECT Ime, Prezime, StudijID, PostaID
FROM Studenti
WHERE PostaID IS Null
Ime
Prezime StudijID PostaID
Ana Marija Tomic
3 NULL
Marko
Markovic
2 NULL

Uoimo da se Null vrijednost testira kljunom rjeju IS Null i da test = Null, gdje je
znak jednakosti zamijenio kljunu rije IS, ne mora dati oekivani rezultat. Naime, o
postavkama baze podataka ovisi rezultat test = Null, no to prelazi okvire ovih skripta.
b) Prikaimo sve studente koji imaju definiranu vrijednost PostaID, dakle
PostaID IS NOT Null :
SELECT Ime, Prezime, StudijID, PostaID
FROM Studenti
WHERE PostaID IS NOT Null
Ime
Ivo
Ana
Tomislav
Helena
Hrvoje
Ante

Prezime StudijID PostaID

Ivic
1
21000
Matic
1
22000
Butorovic
1
21000
Topic
2
20000
Antic
2
23000
Zelic
3
53000

73

5.3 SQL comande za definiciju objekata relacijske baze

podataka
U prethodnom poglavlju smo izvodili upite nad ve definiranim tablicama u koje su
prethodno unijeti podaci. U ovom poglavlju emo definirati i izvoditi komande
kojima se stvaraju, mijenjaju i unitavaju objekti relacijske baze. Razliiti sustavi za
upravljanje relacijskim bazama ( RDBMS ) pruaju mogunost definiranja nekih
specifinih objekata, no svi sigurno podravaju mogunost kreiranja, mijenjanja i
unitavanja tablica, pogleda ( views) i indeksa.
Isto tako, valja napomenuti da je mnogo prokladniji nain stvaranja objekata
koritenjem grafikog korisnikog suelja. Lake je klikom mia odabrati eljenu
akciju ili tip podatka, nego pamtiti sintaksu komandi, te emo najvjerojatnije objekte
baze kreirati koristei grafiki interfejs i pokazivaku jedinicu ( mi ) na razvojnom
raunalu. U fazi implementacije baze na ciljnom raunalu ili veem broju ciljnih
raunala, bilo bi veoma neprikladno ponavljati niz ve odraenih klikova. Sreom,
danas koriteni sustavi relacijskih baza mogu generirati komande za stvaranje bazbih
objekata. Mi moramo komande razumjeti i biti u stanju zadati ih runo.
U ovo poglavlju emo se upoznati samo s komandama u tekstualnom obliku.

5.3.1 Stvaranje, promjena i unitavanje tablice

Tablica sadri kolone i retke. Kolone se moraju definirati prigodom stvaranja tablice,
a retci se stvaraju unosom vrijednosti u tablicu. Tablica predstavlja fiziku
implementaciju entiteta, a kolone atributa. Tablica je odreena korisnikim imenom
kreatora i imenom tablice. Isti korisnik mora svakoj tablici odabrati jedinstveno ime.
Razliiti korisnici mogu koristiti ista imena za svoje tablice. Kako jedan sustav za
upravljanje relacijskim bazama moe u isto vrijeme upravljati s vie baza na istom
stroju, kaimo da je tablica odreena preko tri komponente:
Baza.Korisnik.Tablica
Jasno je, da u sluajevima kada se radna baza i korisnik podrazumijevaju, nije
potrebnonavoditi bazu i korisnika.
5.3.1.1 Stvaranje tablice Studenti
Entitet Studenti opisan je atributima:
Atributi
Ime
Prezime
DatumRodjenja
StudijID

Opis
Slobodno unijeti tekst, maksimalne duine 30 znakova,
obavezan unos
Slobodno unijeti tekst, maksimalne duine 30 znakova,
obavezan unos
Datum, unos nije obavezan
Cio broj, s vrijednostima od 1 do 255, obavezan unos. Opis

74
brojane oznake pogledati u tablici Studiji
Cio broj, s vrijednostima od 10000 ( Zagreb) do 99999, unos
nije obavezan. Opis brojanih vrijednosti pogledati u tablici
Poste

PostaID

Kod kreiranja tablice je veoma vano odabrati odgovarajui tip podatka svake kolone.
Na taj nain onemoguavamo unos nesuvislih ili nemoguih podataka, barem u onoj
mjeri koliko je to mogue. Pojasnimo primjerom: ako bi kolona DatumRodjenja bila
tekstualnog tipa, onda bi bo mogu unos datuma 30.02.2002, no znamo da veljaa ne
moe imati 30 dana. Zato je vano da kolona DatumRodjenja bude datumskog tipa,
pri emu baza nee dopustiti unos nemogueg datuma. Dakle, pravilnim izborom tipa
podatka kolone spreavamo nemogue unose, no neispravni unosi jo su uvijek
moguu: npr. osobi roenoj 2. sijenja 1980, jo je uvijk mogue nepanjom unijeti
datum roenja 1. veljae 1980.
Dakle, tablica Studenti imat e kolone:
Kolona
Ime

Tip podatka
varchar(30)

Null vrijednost
NOT Null

Prezime

varchar(30)

NOT Null

DatumRodjenja

datetime

Null

StudijID

tinyint

NOT Null

PostaID

int

Null

Opisanu tablicu kreirajmo komandom:

CREATE TABLE Studenti (
Ime varchar(30) NOT Null,
Prezime varchar(30) NOT Null,
DatumRodjenja datetimeNull,
StudijID tinyint NOT Null
)

Opis tipa podatka

tekstualni,
maksimalna duina
30 znakova. Unosi
troe onoliko
byte-ova koliko je
znakova unijeto, uz
dodatk 2 byte za
duinu unijetog
podatka
tekstualni,
maksimalna duina
30 znakova
Datumski podatak,
8 byte-ova ( ovisno
RDBMS)
brojani podataka
izmeu 0 i 255, 1
byte
brojani podatak, 4
byte

75
Tablicu Studenti, stvorenu gornjom komandom mogli smo kreirati i preko grafikog
korisnikog suelja.

Kreiranje tablice preko GUI

5.3.1.2 Unitavanje tablice
Tablicu koju vie ne trebamo moemo unititi, komandom:
DROP TABLE Studenti
elimo li ponovno stvoriti tablicu s istim imenom, postojeu moramo najprije unititi,
jer nisu mogue dvije tablice s istim imenom.
5.3.1.3 Izmjena strukture tablice
Pri kreiranju tablice Studenti, propustili smo kreirati kolonu PostaID. Vrlo je est
sluaj da se tijekom eksploatacije baze podataka moraju dodati neke kolone, kao
posljedica naknadog proirenja zahtjeva. Unitavanje, radi ponovnog kreiranja tablice
nije mogue jer su podaci ve upisani, a to bi znailo njihov gubitak. Dapae, tablicu
e koristiti postojea aplikacija, pa ona ne smije biti nedostupna. Zato su nam na
raspolaganju komande za dodavanje novih kolona, te za promjenu postojeih. Iz
praktinih razloga, nastojimo nikada ne unititi postojee kolone, jer neki segment
aplikacije koji se poziva na stara imena kolona, nee raditi. Kolone moemo dodavati
bez bojazni po greke postojeih aplikacija, naravno ako se pridravamo i nekih
drugih praktinih pravila o kojima e biti rijei u slijedeem poglavlju.
Dodajmo kolonu PostaID int Null :
ALTER TABLE Studenti ADD PostaID int Null
Kolonu nije mogue dodadi uz zabranu Null vrijednosti ( NOT NULL ), ako nije
definirana predefinirana ( default) vrijednost.
Navedimo i komandu za unitavanje kolone, iako je dobro izbjegavati takvu praksu, iz
ranije opisanih razloga:
ALTER TABLE Studenti DROP COLUMN PostaID
Promijenimo tip podatka kolone StudijID iz tinyint u smallint ( 2 byte ).
ALTER TABLE Studenti2 ALTER COLUMN StudijID smallint

76
Pri izmjenama tipa podataka iz tipa veeg opseg vrijednosti u manji opseg, moramo
osigurati da ve upisane vrijednosti ne prelaze novi, manji opseg.
Mijenjamo li maksimalno doputeni broj znakova u kolonama varijabilne irine, moe
doi do gubitka dijela unosa koji ne stane u novu, manju dimenziju. Neke RDBMS e
prijaviti greku:
Server: Msg 8152, Level 16, State 9, Line 1
String or binary data would be truncated.
The statement has been terminated.

5.3.2 Stvaranje i unitavanje pogleda view-a

U praksi emo vrlo esto trebati ispise iz tablice Studenti povezane s tablicama Studiji
i Poste, jer nas u pravilu zanima naziv studija i pote. Da bi olakali pretraivanje i
izbjegli sloenost esto koritenih upita, stvorit emo pogled ( view) Vstudenti, koji
e povezivati potrebne tablice. Isto tako, javlja se potreba da neke kolone ne budu
dostupne stanovitoj grupi korisnika, dok ih neka druga skupina moe itati. U naem
primjeru, zadrat emo kolonu DatumRodjenja skrivenom u pogledu Vstudenti.
CREATE VIEW VStudenti
AS
(
SELECT Ime, Prezime, Studij, S.PostaID, Posta
FROM Studenti S
INNER JOIN Studiji ST ON S.StudijID=ST.StudijID
LEFT OUTER JOIN Poste P ON S.PostaID=P.PostaID
)
Sada je ispis imena, prezimena, naziva studija, potanskog broja i naziva pote,
krajnje jednostavan:
SELECT *
FROM Vstudenti
Ime
Prezime
Ivo
Ivic
Ana
Matic
Tomislav Butorovic
Ana Marija Tomic
Marko
Markovic
Helena
Topic
Hrvoje
Antic
Ante
Zelic

Studij
PostaID Posta
Matematika - Informatika
21000 Split
Matematika - Informatika
22000 Sibenik
Matematika - Informatika
21000 Split
Matematika
NULL
NULL
Tehnicka kultura - Informatika NULL
NULL
Tehnicka kultura - Informatika
20000 Dubrovnik
Tehnicka kultura - Informatika
23000 Zadar
Matematika
53000 Gospic

RDBMS pogled tretira kao virtualnu tablicu, dakle ne ita je s medija ( diska ) nego
dinamiki izgrauje za vrijeme izvoenja upita, ba kao da smo zadali upit:
SELECT Ime, Prezime, Studij, S.PostaID, Posta

77
FROM Studenti S
INNER JOIN Studiji ST ON S.StudijID=ST.StudijID
LEFT OUTER JOIN Poste P ON S.PostaID=P.PostaID
To znai da moemo primijeniti restrikciju i sortiranje:
SELECT *
FROM VStudenti
WHERE Studij LIKE '%Informatika%'
ORDER BY Studij, Prezime
Ime
Tomislav
Ivo
Ana
Hrvoje
Marko
Helena

Prezime
Butorovic
Ivic
Matic
Antic
Markovic
Topic

Studij
PostaID Posta
Matematika - Informatika
21000 Split
Matematika - Informatika
21000 Split
Matematika - Informatika
22000 Sibenik
Tehnicka kultura - Informatika
23000 Zadar
Tehnicka kultura - Informatika NULL
NULL
Tehnicka kultura - Informatika
20000 Dubrovnik

Zgodno je ovdje napomenuti, da suvremni sustavi za upravljanje relacijskim bazama

omoguavaju stvaranje materijaliziranih pogleda. Naime, relacijska baza mora biti
najmanje u 3. normalnoj formi, a to znai da svaka relacija ( tablica ) mora biti
najmanje u toj ili vioj normalnoj formi. Kod ispisa podataka esto moramo spajati
vei broj tablica, to znaajno ugroava odzivna vremena, jer je operacija spajanja u
pravilu vremenski zahtjevna, naroito pri spajanju relacija s velikim brojem unosa
(redaka). Stoga se u praksi, nakon normaliziranja baze, esto pristupa denormalizaciji.
U tom postupku materijalizirani pogledi igraju znaajnu ulogu, jer oni predstavljaju
fiziku kopiju spojenih tablica, pri emu RDBMS sam odrava redudantne podatke.
Korisnici baze vide relacije ( tablice) normalizirane, bez odstupanja od teoretskih
postavki, a materijalizirani pogledi osiguravaju iznimno brze upite.
5.3.2.1 Unitavanje pogleda
Pogled koji vie ne trebamo, ili ga elimo ponovno kreirati, moemo unititi
komandom:
DROP VIEW Vstudenti
Jasno je da unitavanje pogleda nema nikakvog utjecaja na bazne tablice i podatke.

5.3.3 Stvaranje indeksa

Cilj ovog poglavlja su naredbe SQL jezika za stvaranje objekata relacijske baze, pa
tako i indeksa. Analizom upita, planiranjem indeksa, te ostalih potankosti vezanih uz
indekse se bavimo u posebnom poglavlju, a ovdje samo kratko pojasnimo pojam i
znaaj indeksa.

78
Pretpostavimo da elimo pronai u telefonskom imeniku splitskog podruja sve osobe
ije je prezime Ivi. Zadatak emo brzo obaviti, jer je imenik poredan po abecednom
redu prezimena pretplatnika. No, ako bi zadatak bio pronai sve osobe koje ive u
Teslinoj ulici, potroili bi mnogo vie vremena. Jednostavno, morali bi krenuti od
prvog pretplatnika, na prvoj stranici imenika, te svakom pretplatniku pregledati ulicu.
Postupak provjere ulice bi provodili jednom po jednom, svim pretplatnicima, sve do
posljednjeg na zadnjoj stranici imenika. Razlog za potpuno itanje imenika lei u
injenici da je imenik sortiran po abecedi prezimena, ali ne i po ulicama. Dakle,
imenik je indeksiran po prezimenu. Kada bi eljeli isti imenik sortiran i po ulicama, to
bi radi utede papira mogli napraviti na ovaj nain: dodati stranice s abecednim
popisom ulica, te kod svake ulice nabrojati sve stranice i retke u kojima emo pronai
pretplatnike s adresom u Teslinoj ulici. To bi vjerojatno znailo, da bi brzo pronali
Teslinu ulicu i onda bismo za svakog pretplatnika morali pronai stranicu, te ponovno
za slijedeeg pretplatnika skoknuti na stranicu indeksa ulica, proitati na kojoj se
stranici nalazi slijedei pretplatnik i tako redom.
Dakle, indeksiranjem se znaajno ubrzava pretraivanje.
Shvatimo naredbu za kreiranje indeksa kao sortiranje podataka u odreenom poretku (
sluaj abecednog poretka po prezimenima ), odnosno, kao dodavanje stranica s
abecednim poretkom ulica i pokazivaima stranica i redaka na kojima su pretplatnici
date ulice.
Naravno, mi elimo indeksirati tablicu studenti, po prezimenu, kako bismo u tablici s
mnogo redaka brzo pronali traeno prezime ( naredbom je stvoren indeks koji
odgovara indeksiranju ulica u gornjem tekstu).
CREATE INDEX Prezime_X ON Studenti(Prezime)
Postupak stvaranja indeksa u velikim tablicama, s nekoliko stotina tisua i miliona
redaka, moe potrajati nekoliko minuta.

5.3.4 Unitavanje indeksa

Shvatimo komandu kao trganje iz telefonskog imenika dodanih stranica sa
sortiranim ulicama. Sreom, stranice medija za pohranu podataka se proglaavaju
slobodnima i bit e ponovno upotrebljene, dok recikliranje starog papira ipak ne ide
tako glatko.
DROP INDEX Studenti.Prezime_X
Uoimo, da se indeks odreuje imenom tablice i imenom indeksa, no to se moe
razlikovati od jednog do drugog sustava relacijskih baza.
Podrobnije o indeksima govori se u drugim poglavljima ovih skripta.
Ope pravilo stvaranja i unitavanja objekata baze podataka

79
- stvaranje
CREATE TipObjekta NazivObjekta (
Definicija objekta
)
unitavanje
DROP TipObjekta NazivObjekta

5.4 Naredbe za upisivanje, promjenu i brisanje podataka

Cjeloviti informacijski sustav izgrauje niz ekranskih formi prozora preko kojih
upisujemno, mijenjamo ili briemo podatke u tablicama relacijske baze, sluei se
programskim objektima za spajanje na bazu i rad sa skupovima podataka. No, pored
toga, u svim fazama ivota baze podataka, postavlaju se nepredvieni upiti, a isto tako
se obavljaju ad hock izmjene podataka, pa stoga treba obratiti potrebnu panju i stei
potrebnu sigurnost i samopouzdanje u koritenju naredbi za manipulaciju podacima.

5.4.1 Upisivanje ( insertiranje ) retka

Upiimo novog studenta u tablicu Studenti, ije je ime Marko, prezime Mari, roen
je 07.08.1980. i upisan je na studijsku grupu 1. Potanski broj njegove adrese za sada
nije poznat.
INSERT INTO Studenti( Prezime, Ime, StudijID, DatumRodjenja)
VALUES( 'Marti', 'Marko', 1, '1980/08/07' )
Primjetimo da nakon kljune rijei INSERT INTO slijedi ime tablice, te lista kolona u
koje e biti upisani podaci, dok kljunu rije VALUES slijedi lista vrijednosti. Lista
kolona i lista vrijednosti moraju se podudarati po broju i tipu podataka. Sustav e
javiti greku ako:
broj kolona nije jednak broju datih vrijednosti
(There are more columns in the INSERT statement than values specified in
the VALUES clause. )
upisujemo vrijednost iji tip ne odgovara ili se ne moe pretvoriti u tip kolone,
npr. ako bismo u cjelobrojnu kolonu StudijID pokuali upisati tekst 'Marko'.
(Syntax error converting the varchar value 'Marko' to a column of data type
smallint.)
tekstualne konstante nisu zatvorene u jednostrukim navodnicima
(The name 'Marko' is not permitted in this context. Only constants,
expressions, or variables allowed here. Column names are not permitted.)
datum nije ispravan.
(The conversion of a char data type to a datetime data type resulted in an
out-of-range datetime value.)
nije navedena vrijednost za kolonu s obaveznim unosom ( NOT Null ), a da
istovremeno nije zadana ( kod kreiranja tablice ) pretpostavljena (default)

80
vrijednost.
(Cannot insert the value NULL into column 'Prezime', table
'DT.dbo.Studenti'; column does not allow nulls. INSERT fails.The statement
has been terminated.)

5.4.2 Upisivanje svih kolona

Kada naredba za upisivanje retka obuhvaa listu svih kolona definiranih u tablici, nije
neophodno navoditi listu kolona, ve samo listu vrijednosti, pri emu poredak
vrijednosti mora odgovarati fizikom poretku kolona u tablici:
INSERT INTO Studenti
VALUES( 'Slavko', 'Peri', '1980/08/07', 1, 21000 )
Ovakvu naredbu moemo koristiti ad hock, dakle upotrijebimo i izbriemo, ali nipoto
u programima ili skriptama koje se koriste trajno. Naime, tijekom vremena prpizii e
potreba za dodavanjem jedne ili vie kolona u tablicu, to je uobiajena praksa kako
primjena baze napreduje, a onda broj kolona tablice i navedenih vrijednosti se nee
podudariti. Stoga je praktiana neophodnost da se uvijek navodi lista kolona u koje se
upisuju vrijednosti. Naknadno dodane kolone moraju doputati Null vrijednost ili
imati definiranu pretpostavljenu ( default ) vrijednost.

5.4.3 Upisivanje iz jedne tablice u drugu

Stvorimo li tablicu Studenti2, s kolonama Ime, Prezime i StudijID, tada u nju moemo
upisati dio ili sve retke iz tablice Studenti, naredbom:
INSERT INTO Studenti2( Ime, Prezime, StudijID)
SELECT Ime, Prezime, StudijID
FROM Studenti
WHERE StudijID=1
Dobijena poruka je (5 row(s) affected), te moemo provjeriti sadraj tablice
Studenti2.

5.4.4 Pomjena podataka ( update )

Potrebno je promijeniti DatumRodjenja studentu Ivo Ivi. Ispravan datum je
21.06.1980.
UPDATE Studenti
SET DatumRodjenja='1980/06/21'
WHERE Ime='Ivo' AND Prezime='Ivi'
Prije izvoenja ovakve naredbe, moramo biti sigurni da e se promjena provesti samo
eljenom studentu, pa je kod ovakvih promjena najbolje koristiti primarni klju u

81
WHERE klauzuli. este su greke koje se dese zbog brzopletosti, npr. izvoenjem
komande:
UPDATE Studenti
SET DatumRodjenja='1980/06/21'
Uinak je katastrofalan: svim studentima postavljen je isti datum roenja. Naravno i
za ovakve pogreke moramo predvidjeti lijek, no u svakom sluaju dobro je izbjei
ovako neugodne situacije, paljivim zadavanjem naredbe UPDATE.

5.4.5 Promjena podataka tablice vrijednostima druge tablice

Svim studentima koji nemaju definiran potanski broj, ( PostaID IS NULL), potrebno
je upisati broj ija druga znamenka slijeva odgovara broju StudijID, a prva znamenka
je 2.
Kako se radi o zahtjevnoj naredbi, najprije emo provjeriti nae razmiljanje
izvoenjem SELECT upita, jer jasno je, pogreno promijenjene podatke nije lako
popraviti:
SELECT StudijID, S.PostaID, P.PostaID
FROM Studenti S, Poste P
WHERE CONVERT(varchar,
StudijID)=SUBSTRING(CONVERT(varchar, P.PostaID), 2,1) AND
P.PostaID BETWEEN 20000 AND 29999 AND S.PostaID IS NULL
StudijID

S.PostaID P.PostaID
3 NULL
23000
2 NULL
22000
1 NULL
21000

Kako smo zaista dobropostavili uvjet, to vidimo da su obuhvaeni samo studenti

kojima nije definirana PostaID ( NULL ), te da je prva znamenka slijeva potanskog
broja 2 i konano StudijID i driga znamenka potanskog broja se uvijek podudaraju.
Stoga, provedimo promjene podataka:
UPDATE Studenti
SET PostaiD=P.PostaID
FROM Studenti S, Poste P
WHERE CONVERT(varchar, StudijID)=SUBSTRING(CONVERT(varchar,
P.PostaID), 2,1) AND
P.PostaID BETWEEN 20000 AND 29999 AND S.PostaID IS NULL
Jasno je, da e nakon izvedene naredbe PostaID dobiti ranijom komandom izlistane
vrijednosti.

82

5.4.6 Brisanje ( delete ) retka

Moemo brisati pojedinane retke, grupu redaka koji zadovoljavaju odreeni kriterij,
ili pak sve retke u tablici.
5.4.6.1 brisanje jednog retka
Openito, sigurno emo izbrisati samo jedan redak, ako se u WHERE klauzuli testira
vrijednost primarnog kljua, jer on na jedinstven nain identificira svaki redak.
Primarni klju tablice Studenti je StudentID, ije vrijednosti automatski generira
sustav relacijske baze ( Autonumber ).
Briemo, dakle trajno uklanjamo iz tablice, studenta Hrvoja Antia, ijije StudentID
( u mojoj tablici ) 7 naredbom:
DELETE FROM Studenti
WHERE StudentID=7
Kako smo upotrijebili primarni klju kao uvjet, to smo sigurni da je izbrisan najvie
jedan redak.
5.4.6.2 brisanje vie redaka koji zadovoljavaju uvjet
Pretpostavimo da su se svi studenti iz Zadarske i ibenske upanije ispisali sa studija,
te ih moramo ukloniti iz tablice. Iskoritit emo pogodnost da sve pote u Zadarskoj
upaniji zapoinju s 23, a u ibenskoj s 22, pa su u opsegu brojeva 22000 do 23999
zaparavo sva mjest ove dvije upanije:

DELETE FROM Studenti

WHERE PostaID BETWEEN 22000 AND 23999
Rezulta je: (3 row(s) affected).
brisanje svih redaka tablice
Vrlo jednostavno, kako se i da pretpostaviti, isputanjem uvjeta bit e izbrisani svi
retci tablice.
DELETE FROM Studenti
Skrenimo panju, da je nakon izvedene komande, tablica potpuno prazna. Prije
izvoenja ovakvih komandi, moramo biti sigurni to elimo.

83

6 Literatura:
1. Mladen Varga: Baze podataka Konceptualno, logiko i fiziko modeliranje
podataka, Drutvo za razvoj informacijske pismenosti (DRIP), Zagreb, 1994.
2. Darko Hreni: ORACLE, Znak, Zagreb, 1995.
3. Ratko Vujnovi: SQL i relacijski model podataka, Znak, Zagreb, 1995.
4. Malcolm Dodwell: System Modelling Techniques ( Course Notes ), Oracle
Corporation UK Ltd, 1993.
5. David Solomon: MS SQL Server 6.5, SAMS Publishing, 1996.
6. Kalen Delany: Inside SQL Server 2000, 2000.
7. Ken Henderson: The Gurus's Guide to Transact-SQL, Addison-Wesley,
2000.