Leonid Stoimenov - Uvod U Baze Podataka PDF

Univerzitet u Niu
Elektronski fakultet
Leonid Stoimenov
Ime
MBR
N
STUDENT
Prezime
1
MENTOR
Indeks
PROFESOR
Ime
Ime
Prezime
MBR
Milan
Petrovi
123456
Milan
Ili
654321
Aleksandar
Jovanovi
345612
Ime
Prezime
Indeks
MentorMBR
Petar
Petrovi
1111
123456
Milan
Milanovi
2222
654321
Jovan
Jovanovi
3333
654321
Prezime
SELECT STUDENT.Ime, STUDENT.Prezime

FROM STUDENT, PROFESOR
WHERE MentorMBR=MBR AND
PROFESOR.Ime=Petar;
Edicija: Udbenici
Univerzitet u Niu
Leonid Stoimenov
Uvod u Baze podataka

Edicija: Udbenici
Ni, 2013
Prof. dr Leonid Stoimenov

UVOD U BAZE PODATAKA
Izdava: Elektronski fakultet u Niu
P. fah 73, 18000 Ni
http://www.elfak.ni.ac.yu
Recenzenti: Prof. dr Ivan Lukovi
Prof. dr Milena Stankovi
Glavni i odgovorni urednik: Prof. dr Dragan Tasi

Odlukom Nastavno-naunog vea Elektronskog fakulteta u Niu, br. 07/05004/13-003 od 31.10.2013., rukopis je odobren za tampu kao univerzitetski
udbenik.
ISBN 978-86-6125-099-6
CIP -
,
Pretampavanje ili umnoavanje ove knjige nije dozvoljeno bez pismene

dozvole izdavaa.
Tira: 300 primeraka
tampa: Elektronski fakultet, Ni
Predgovor
Baze podataka su, po miljenju autora, jedna od znaajnijih oblasti raunarstva i
informatike. Posledica toga je postojanje odgovarajuih kurseva na tehnikim ali i netehnikim fakultetima koji se bave razliitim aspektima baza podataka od osnovnih
kurseva za poetnike, do naprednih kurseva koji se bave specijalizovanim temama iz ove
iroke oblasti.
Namena udbenika
Navedeni materijal je u skladu sa planom i programom predmeta Baze podataka na II
godini osnovnih akademskih studija na Elektronskom fakultetu u Niu i u potpunosti
pokriva sve teme sa predavanja i vebi na modulu Raunarstvo i informatika. Udbenik je
namenjen studentima koji se prvi put susreu sa bazama podataka i ne zahteva nikakvo
posebno predznanje osim opteg znanja o raunarstvu i informatici sa I godine studija.
Udbenik se moe koristiti i na drugim modulima ovih studija. Udbenik sadri koncizan
prikaz teorijske osnove baza podataka, brojne primere i zadatke za samostalni rad
studenata. Kao takav, on predstavlja materijal za spremanje kompletnog ispita iz predmeta
Baze podataka.
Struktura udbenika
Udbenik sadri osam poglavlja i literaturu. Struktura i redosled poglavlja je takav da
prati teme koje se obrauju na predavanjima i vebama iz uvodnog kursa Baze podataka.
Svako poglavlje sadri veliki broj primera koji treba da pomognu studentima u
savladavanju gradiva.
U Poglavlju 1, pod naslovom Baze podataka osnovni pojmovi, dat je kratak pregled
osnovnih pojmova iz oblasti baza podataka, pregled i poreenje dva pristupa:
konvencionalne obrade zasnovane na datotekama i korienje baza podataka.
U Poglavlju 2, pod naslovom Modeli podataka i proces projektovanja baze podataka,
opisani su nivoi apstrakcije kod DBMSa, opisani modeli podataka na razliitim nivoima
apstrakcije i njihovi osnovni koncepti, i opisan generalni postupak projektovanja baza
podataka.
U Poglavlju 3, pod naslovom Konceptualno projektovanje baze podataka, prikazani su
osnovni koncepti ER i EER, opisan je proces projektovanja odnosno korienja ovih
koncepata. Dat je pregled grafike notacije za ER i EER dijagrame, i date su preporuke za
izvoenje ER i EER modeliranja. U ovom poglavlju su dati primeri projektovanja baza
podataka.
U Poglavlju 4, pod naslovom Relacioni model podataka, dat je prikaz koncepata
relacionog modela i opis odgovarajue terminologije. Dat je osvrt i na integritetnu
komponentu ovog modela, kao i algoritam za preslikavanje ER i EER modela podataka u
relacioni.
U Poglavlju 5, pod naslovom Relaciona algebra, dat je pregled osnovnih operacija
relacione algebre i veliki broj primera korienja kao i upita relacione algebre.
U Poglavlju 6, pod naslovom Normalizacija i normalne forme, prikazane su
funkcionalne zavisnosti i njihovo izvoenje, pojam kljua relacije, analiza eme relacije i
Uvod u baze podataka: Sadraj

normalne forme. Osim definicije normalnih formi dati su primeri testiranja, opisan je i
ilustrovan primerima postupak normalizacije.
U Poglavlju 7, pod naslovom Upitni jezik SQL, uz veliki broj primera i zadataka za
vebu prikazane su mogunosti SQL jezika od naredbi za kreiranje podataka i modifikaciju
eme do naredbi za pretraivanje i manipulaciju podacima.
U Poglavlju 8, pod naslovom Kreiranje korisnikih aplikacija: ADO.NET, prikazane su
osnove ADO.NETa, odgovarajuih provajdera podataka i opisan je nain za direktan
pristup podacima. Prikazani su i primeri za kreiranje konekcije ka bazi podataka, kreiranje
SQL komande i korienje datareaderi objekta.
Online materijal
Dodatni materijal kao podrka udbeniku je dostupan studentima i moe se nai na
Moodle stranicama predmeta: http://cs.elfak.ni.ac.rs/nastava.
Plan i program predmeta Baze podataka, koji se slua na II godini studija u u letnjem
semestru, moe se nai na Web-u, na adresi: http://www.elfak.ni.ac.rs, na stranici koja se
odnosi na Akreditaciju 2013.godine.
Zahvalnica
Autor se zahvaljuje recenzentima ovog praktikuma, prof.dr Ivanu Lukoviu i prof.dr
Mileni Stankovi, na trudu koji su uloili itajui ovaj praktikum, zapaanjima,
primedbama i koristnim sugestijama, koje su svakako doprinele kvalitetu ovog praktikuma.
Takoe, autor se zahvaljuje svojim saradnicima dr Aleksandru Stanimiroviu i Milou
Bogdanoviu koji su svojim dugogodinjim radom uradili mnogo toga da ovaj kurs bude
popularan meu studentima, a posebno na trudu koji su uloili u pisanju poslednja dva
poglavlja ovog materijala.
Na kraju, ali sa najvie emocija, autor se zahvaljuje prof.dr Slobodanki oreviKajan, profesorki Elektronskog fakulteta u penziji, koja je najzaslunija za uvoenje ovog i
drugih srodnih kurseva, i koja je bitno uticala na oblikovanje tema koje su prezentirane i u
ovom udebniku.
U Niu, avgust 2013. godine
vi
Autor
Sadraj
1 BAZE PODATAKA OSNOVNI POJMOVI .............................................................1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
PODACI I INFORMACIJE ......................................................................................1

KONVENCIONALNI SISTEMI U ODNOSU NA BAZE PODATAKA .............................2
SISTEM BAZA PODATAKA ..................................................................................4
TA JE BAZA PODATAKA? ..................................................................................5
TA JE SISTEM ZA UPRAVLJANJE BAZAMA PODATAKA? .....................................8
TIPOVI SISTEMA BAZA PODATAKA ...................................................................11
ZANIMLJIVOSTI: ISTORIJAT DBMSA ............................................................... 13
2 MODELI PODATAKA I PROCES PROJEKTOVANJA BAZE PODATAKA .... 15

2.1
2.2
2.3
NIVOI APSTRAKCIJE U DBMS-U ...................................................................... 15

MODELI PODATAKA ........................................................................................ 17
PROJEKTOVANJE BAZE PODATAKA ..................................................................18
3 KONCEPTUALNO PROJEKTOVANJE BAZE PODATAKA .............................. 23

3.1
ENTITETI, TIP ENTITETA I SKUP ENTITETA........................................................ 24
3.1.1
Atributi...................................................................................................26
3.1.2
Klju tipa entiteta .................................................................................. 32
3.2
POVEZNICI, SKUP POVEZNIKA I TIP POVEZNIKA ............................................... 34
3.3
OGRANIENJA NAD TIPOM POVEZNIKA ............................................................ 40
3.4
SLABI TIP ENTITETA ........................................................................................ 46
3.5
PREGLED GRAFIKE NOTACIJE ER DIJAGRAMA ............................................... 47
3.6
PRIMERI KONCEPTUALNOG MODELIRANJA ...................................................... 49
3.6.1
Preporuke kod modeliranja ...................................................................56
3.7
EER MODEL ...................................................................................................57
3.7.1
Koncepti EER modela podataka ............................................................ 57
3.7.2
Notacija i primeri korienja koncepata EER modela........................... 59
4 RELACIONI MODEL PODATAKA ......................................................................... 65
4.1
OSNOVE RELACIONOG MODELA PODATAKA .................................................... 65
4.2
KONCEPTI RELACIONOG MODELA PODATAKA ................................................. 66
4.3
DOMENI, ATRIBUTI, TORKE I RELACIJE ............................................................ 66
4.3.1
Svojstva eme relacije i relacije ............................................................ 70
4.4
KLJU EME RELACIJE ..................................................................................... 70
4.4.1
Pregled terminologije za kljueve.......................................................... 72
4.5
EMA I POJAVA RELACIONE BAZE PODATKA .................................................... 73
4.5.1
Predstavljanje ema relacione baze podataka ....................................... 75
4.6
OGRANIENJA U RELACIONOM MODELU.......................................................... 76
4.6.1
Specifikacija ogranienja u DBMSu ...................................................... 78
4.7
OPERACIJSKA KOMPONENTA ........................................................................... 83
4.8
PREGLED TERMINOLOGIJE OSNOVNIH KONCEPATA.......................................... 83
4.9
PRESLIKAVANJE ER/EER MODELA U RELACIONI MODEL ................................ 84
5 RELACIONA ALGEBRA ........................................................................................... 91

5.1
5.2
5.3
5.4
5.5
5.6
5.7
SELEKCIJA ....................................................................................................... 92
PROJEKCIJA ..................................................................................................... 94
PREIMENOVANJE ............................................................................................. 96
OPERACIJE RELACIONE ALGEBRE IZ TEORIJE SKUPOVA ...................................96
-SPOJ .......................................................................................................... 100
FUNKCIJE AGREGACIJE .................................................................................. 103
PRIMERI UPITA U RELACIONOJ ALGEBRI ........................................................ 103
6 NORMALIZACIJA I NORMALNE FORME......................................................... 109

6.1
FUNKCIONALNE ZAVISNOSTI ......................................................................... 109
6.2
IZVOENJE FUNKCIONALNIH ZAVISNOSTI...................................................... 112
6.2.1
Zatvara skupa funkcionalnih zavisnosti ............................................. 112
6.2.2
Zatvara skupa atributa....................................................................... 114
6.3
KLJU EME RELACIJE ................................................................................... 115
6.4
ANALIZA EME RELACIONE BAZE PODATAKA ................................................ 120
6.5
NORMALNE FORME I NORMALIZACIJA ........................................................... 124
6.5.1
Prva normalna forma .......................................................................... 125
6.5.2
Druga normalna forma (2NF) ............................................................. 127
6.5.3
Trea normalna forma (3NF) .............................................................. 131
6.5.4
Boyce-Codd-ova normalna forma (BCNF) .......................................... 134
6.5.5
Denormalizacija .................................................................................. 138
7 UPITNI JEZIK SQL .................................................................................................. 141
7.1
BAZA PODATAKA PREDUZEE................................................................... 142
7.2
SQL NAREDBE ZA KREIRANJE PODATAKA ..................................................... 144
7.2.1
Tipovi podataka ................................................................................... 144
7.2.2
Ogranienja kolone ............................................................................. 148
7.2.3
Ogranienja tabele .............................................................................. 150
7.3
MODIFIKACIJA EME RELACIONE BAZE PODATAKA ....................................... 154
7.3.1
Brisanje tabele ..................................................................................... 154
7.4
PRETRAIVANJE PODATAKA .......................................................................... 156
7.4.1
Naredba SELECT ................................................................................ 156
7.4.2
Kaluzule SELECT i FROM .................................................................. 157
7.4.3
Klauzula WHERE ................................................................................ 159
7.4.4
Klauzula ORDER BY ........................................................................... 165
7.4.5
Aritmetike funkcije ............................................................................. 166
7.4.6
Funkcije za rad sa stringovima ............................................................ 168
7.4.7
Funkcije agregacije ............................................................................. 169
7.5
NAPREDNE KLAUZULE SELECT NAREDBE I SPAJANJE TABELA..................... 170
7.5.1
Spajanje tabela .................................................................................... 170
7.5.2
Dekartov proizvod (cross-join) ............................................................ 172
7.5.3
Unutranji spoj (inner-join) .................................................................172
7.5.4
Levi spoljanji spoj (left-outer join)..................................................... 173
7.5.5
Desni spoljanji spoj (right-outer join) ............................................... 174
7.5.6
Potpuni spoljanji spoj (full-outer join)............................................... 175
7.5.7
Klauzule GROUP BY i HAVING ......................................................... 178
7.5.8
Kombinovanje rezultata vie SQL upita .............................................. 181
7.5.9
Ugnjedeni upiti................................................................................... 185
viii

7.5.10
Pseudo kolona ROWNUM ................................................................... 189
7.5.11
Klauzula CONNECT BY...START WITH ............................................. 191
7.6
SQL NAREDBE ZA MANIPULACIJU PODACIMA ............................................... 192
7.6.1
Dodavanje novih podataka .................................................................. 193
7.6.2
Auriranje podataka ............................................................................ 196
7.6.3
Brisanje podataka ................................................................................ 198
7.7
NAREDBE ZA RAD SA POGLEDIMA .................................................................200
7.8
NAREDBE ZA RAD SA INDEKSIMA .................................................................. 203
8 KREIRANJE KORISNIKIH APLIKACIJA: ADO.NET .................................... 205
8.1
8.2
8.3
8.4
8.5
8.6
8.7
OSNOVE ADO.NET-A................................................................................... 205

ADO.NET DATA PROVIDER-I ....................................................................... 206
DIREKTAN PRISTUP PODACIMA KORIENJEM ADO.NET-A ......................... 209
KREIRANJE KONEKCIJE KA BAZI PODATAKA .................................................. 209
KREIRANJE SQL KOMANDE........................................................................... 210
KORIENJE DATAREADER OBJEKTA ............................................................ 211
KORIENJE BEZKONEKCIONOG SLOJA ADO.NET-A ZA PRISTUP PODACIMA
216
9 LITERATURA ........................................................................................................... 223
ix
Spisak slika
Slika 1-1. Konvencionalni sistem zasnovan na datotekama ............................... 2
Slika 1-2. Obrada zasnovana na bazama podataka ............................................. 4
Slika 1-3. Komponente sistema baza podataka................................................... 5
Slika 1-4. Tabela u bazi podataka sa oznaenom vrstom i kolonom .................. 7
Slika 1-5. Meusobna povezanost podataka u bazi podataka ............................. 7
Slika 1-6. Personalni sistem baza podataka ....................................................... 11
Slika 1-7. Enterprise sistem baza podataka ....................................................... 12
Slika 2-1. Arhitektura tri eme DBMSa ............................................................. 16
Slika 2-2. Faze projektovanja baza podataka ..................................................... 20
Slika 3-1. Konceptualno projektovanje baze podataka ...................................... 23
Slika 3-2. Grafika notacija za tip entiteta ......................................................... 26
Slika 3-3. Predstavljanje atributa u ER dijagramu ............................................. 28
Slika 3-4. Sloeni (kompozitni) atributi u ER dijagramu .................................. 30
Slika 3-5. Grafika notacija za izvedeni atribut ................................................. 30
Slika 3-6. Grafika notacija za vievrednosni atribut ........................................ 31
Slika 3-7. Grafika notacija za prikaz tipa entiteta i njegovih atributa .............. 33
Slika 3-8. Grafika notacija za tip poveznika .................................................... 34
Slika 3-9. Ternarni tip poveznika SNABDEVA ................................................ 36
Slika 3-10. Neke pojave tipa poveznika RADI-NA.......................................... 36
Slika 3-11. Neke pojave tipa poveznika RUKOVODI ..................................... 37
Slika 3-12. Neke pojave tipa poveznika JE_RUKOVODILAC ....................... 37
Slika 3-13. Neke pojave rekurzivnog tipa poveznika U-BRAKU .................... 38
Slika 3-14. Neke pojave ternarnog tipa poveznika SNABDEVA .................... 38
Slika 3-15. Prikaz uloge u ER modelu .............................................................. 39
Slika 3-16. Oznaavanje kardinaliteta .............................................................. 41
Slika 3-17. Veza 1:N izmeu tipova entiteta RADNO-MESTO i RADNIK .... 42
Slika 3-18. ER dijagram sa oznaenim kardinalitetima tipa poveznika............ 42
Slika 3-19. Oznaavanje participacije za tip veze RASPOREEN ................. 43
Slika 3-20. Oznaavanje participacije za tip veze RADI-U.............................. 43
Slika 3-21. Oznaavanje strukturalnih ogranienja .......................................... 45
x

Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
Slika
3-22. Primer oznaavanja strukturalnih ogranienja ............................... 46

3-23. Slabi tip entiteta u ER dijagramu ................................................... 46
3-24. Primer ER dijagrama: vlasnici i njihova vozila .............................. 51
3-25. ER dijagram baze podataka PREDUZEE .................................... 52
3-26. EER model baze podataka VIDEO_KLUB ................................... 54
3-27. ER dijagram baze podataka o autorima i njihovim delima ............ 55
3-28. ER dijagram baze podataka o publikacijama ................................. 56
3-29. Primer specijalizacije ..................................................................... 60
3-30. Primer generalizacije ...................................................................... 61
3-31. Hijerarhija klasa ............................................................................. 61
3-32. Primer deljive klase ........................................................................ 62
3-33. Primer kategorije ............................................................................ 62
3-34. EER dijagram za zadatak za vebu ................................................ 64
4-1. Tabela sa podacima koja odgovara relaciji radnik ........................... 70
4-2. Ostvarivanje veza preko stranih kljueva ......................................... 72
4-3. Jedna pojava baze podataka PREDUZEE ..................................... 74
4-4. Relaciona ema baze podataka PREDUZEE ................................. 76
4-5. Ekvivalentni skup pojmova kod baza podataka .............................. 83
4-6. Pregled osnovnih koncepata relacionog modela .............................. 84
4-7. ER dijagram baze podataka PREDUZEE ...................................... 87
4-8. Relacioni model baze podataka PREDUZEE ................................ 89
4-9. Deo eme koji sadri ternarnu vezu SNABDEVA ........................... 89
4-10. Relacioni model baze podataka VIDEO_KLUB ............................ 90
5-1. Rezultat selekcije su izdvojene vrste relacije ................................... 92
5-2. Primer rezultata primene selekcije ................................................... 94
5-3. Primer primene operacije projekcije ................................................ 95
5-4. Rezultat projekcije nad relacijom radnik ......................................... 96
5-5. Primer primene skupovnih operacija ................................................ 98
5-6. Primer primene Dekartovog proizvoda ............................................ 99
5-7. Primer primene operacije deljenja .................................................... 99
5-8. Primer primene operacije spoja ...................................................... 101
5-9. Primer primene prirodnog spoja ..................................................... 102
6-1. Primer loe projektovane relacije ................................................... 121
6-2. Nenormalizovana relacija ............................................................... 126
6-3. Relacije nakon normalizacije do 2NF ............................................ 131
xi

Slika
Slika
Slika
Slika
Slika
Slika
Slika
xii
6-4. Ilustracija parcijalnih i tranzitivnih zavisnosti ............................... 132

6-5. Relacije nakon normalizacije do 3NF ............................................ 134
6-6. Relacija KlijentIntervju .................................................................. 138
6-7. Relacija KlijentIntervju nakon normalizacije ................................. 138
7-1. Relacija KlijentIntervju nakon normalizacije ................................. 143
8-1. Struktura Data Provider-a .NET platforme .................................... 207
8-2. Bezkonekcioni pristup podacima ................................................... 217
1 BAZE
P O D ATA K A
POJMOVI
OSNOVNI
Moderne kompanije i institucije poseduju razliite elektronske (raunarske,

informacione) sisteme koje koriste kao podrku u procesu obrade informacija, koje
nastaju kako unutar samog sistema tako i onih koji dolaze spolja. Takvi
informacioni sistemi obezbeuju kako osoblju tako i spoljnim korisnicima (kupci,
dobavljai, agencije i sl) da pristupe informacijama kompanije sa razliitim
nivoima prioriteta i prava pristupa. To mogu da budu sistemi za upravljanje
dokumenata, sistemi za upravljanje projektima, e-mailing sistemi, intranet, internet
stranice i sl. Svi ovi sistemi imaju jedan neizostavan deo bazu podataka, koja
uva sve informacije koje se obrauju i obezbeuje pristup tim informacijama.
Baze podataka su kljuna komponenta kod standardnih informacionih sistema, ali i
sistema e-poslovanja i drugih Web zasnovanih aplikacija. Koriste ih oragnizacije i
preduzea od onih najmanjih do globalnih korporacija i milioni korisnika.
1.1 Podaci i informacije

Pojam interakcije oveka sa svojom okolinom zasniva se na tri osnovna
koncepta:
1) podatak,
2) informacija i
3) znanje (uz koje se danas sve vie vezuje pojam mudrost).
Dve osnovne operacije nad elementima koji su definisani ovim konceptima su
predstavljanje i obrada.
Podatak (lat. datum deo informacije, eng. Data) je jednostavna neobraena
izolovana injenica koja ima neko znaenje i koja se obrauje i uva na raunaru.
Podaci su osnova baza podataka i predstavljaju injenice, pojmove ili dogaaje,
vezani za objekat posmatranja, predstavljeni na unapred dogovoreni, formalizovan
nain. Podaci su znakovni prikaz injenica i pojmova koji opisuju svojstva
objekata.
Informacija (lat. Informare, eng. Information) predstavlja rezultat analize i
organizacije podataka na nain da daje/generie novo znanje. Obrada podataka
Uvod u baze podataka

podrazumeva proces prevoenja podataka u informacije, tako da Informacija (u
obradi podataka) predstavlja smisao dodeljen podacima na osnovu dogovora za
njihovo predstavljanje.
Pojam Znanje se u oblasti raunarstva odnosi na sisteme vetake inteligencije.
Objanjenje ovog pojma i nain korienja znanja nije predmet ovog uvodnog
kursa (dodatne informacije: kurs Vetaka inteligencija, VII semestar).
1.2 Konvencionalni sistemi u odnosu na baze podataka

Tradicionalni pristup obrade podataka podrazumeva korienje sistema
zasnovanog na datotekama (engl. File-based system). To je tzv. ad hoc pristup kod
koga:
postoji datoteka ili skup datoteka podataka potrebnih za definisanu

aplikaciju,
razvijaju se programi koji obrauju podatke iz datoteka i
svaki program definie sopstvene podatke i upravlja tim podacima.
esto se koristi pojam Automatska obrada podataka (AOP) kod koje postoje
meusobno nezavisne aplikacije jednog informacionog sistema (IS), i za svaku
aplikaciju se kreiraju i odravaju posebne datoteke sa svim potrebnim podacima.
Aplikacioni program prodaje
Unos
podataka i
tampanje
izvetaja
Prodaja
Rutine za
rukovanje
datotekama
Definicije
datoteka
Datoteke
prodaje
Aplikacioni program nabavke

Unos
podataka i
tampanje
izvetaja
Nabavka
Rutine za
rukovanje
datotekama
Definicije
datoteka
Datoteke
nabavke
Slika 1-1. Konvencionalni sistem zasnovan na datotekama
Na slici 1-1 prikazan je konvencionalni sistem sa dve aplikacije jednog

preduzea, za sektor Prodaja i sektor Nabavka. Podaci se uvaju u nezavisnim
datotekama. Obe aplikacije sadre rutine za unos podataka i tampanje izvetaja,
kao i rutine za rukovanje datotekama. Definicija datoteka je ugraena u programe.
Datoteke su nezavisne i mogu da sadre i iste podatke, pa je odravanje tih
2
Baze podataka osnovni pojmovi

podataka sloenije i preputeno programu odnosno programeru u toku razvoja
aplikacije.
Osnovne karakteristike ovakvog sistema zasnovanog na datotekama su:
Ugraeni su opisi fizikih karakteristika podataka (ili fizikih struktura

podataka) u aplikacioni program.
Ne postoji kontrola pristupa podacima, osim one koju vre aplikacioni
programi.
Prednosti konvencionalne obrade zasnovane na datotekama su jednostavnost

projektovanja i realizacije. Meutim, obe osnovne karakteristike su i potencijalni
problemi kod korienja. Poeljno je da definicija podataka bude odvojena i
nezavisna od aplikacija, a takoe, poeljna je potpuna kontrola pristupa podacima i
to nezavisno od konkretnog aplikacionog programa. Kao posledica, nedostaci ovih
sistema su:
nepovezanost aplikacija,
ponavljanje podataka,
neusaglaenost (nekonzistentnost) podataka,
vrsta povezanost programa i podataka:
o programi za obradu podataka zavise od naina fizikog
struktuiranja podataka,
o promena strukture podataka zahteva promenu programa.
ograniena mogunost zajednikog korienja podataka,
ograniena raspoloivost podataka i
neadekvatna realizacija oporavka od pada sistema.
Posledice navednih nedostataka su da je obrada podataka skupa i da se zahteva

neko bolje reenje. Reenje problema su baze podataka koje treba da obezbede:
Nezavisnost struktura podataka od programa koji ih obrauju.

Nezavisnost programa od struktura podataka.
Minimalnost ponavljanja podataka.
Da obrada podataka nije vezana za programski jezik opte namene, ve
za vii upitni jezik.
Korienje baze podataka od strane veeg broja korisnika.
Obrada zasnovana na bazama podataka prikazana je na slici 1-2. Baze podataka

podravaju rad veeg broja aplikacija, koje preko Sistema za upravljanje bazama
podataka omoguava pristup podacima u bazi podataka. Sistem za upravljanje
bazama podataka je zaduen za aurnost podataka. Aplikacije, Sistem za
3

upravljanje bazama podataka i baza podataka ine Sistem baza podataka (objaenje
ovih pojmova je dato u odeljcima 1.3, 1.4 i 1.5).
Vane odrednice pristupa zasnovanog na korienju baza podataka su:
Podaci su deljivi.
Baza podataka sadri i podatke i njihove definicije (opisi, eme).
Definicije podataka se nalaze u katalogu sistema (renik sistema) i
nazivaju se meta podaci.
Definicije podataka su odvojene od aplikacionih programa.
Podaci su logiki povezani (entiteti, atributi, veze).
Unos podataka i
tampanje izvetaja
Prodaja
Aplikacioni programi
prodaje
Sistem baze podataka
DBMS
Baza
podataka
Unos podataka i
tampanje izvetaja
Nabavka
Aplikacioni programi
nabavke
Slika 1-2. Obrada zasnovana na bazama podataka
1.3 Sistem baza podataka

Sistem baza podataka sadri tri osnovne komponente (slika 1-3):
(1) aplikacija nad bazom podataka,
(2) sistem za upravljanje bazama podataka (Database Management System
DBMS), i
(3) baza podataka.
Baza podataka predstavlja kolekciju povezanih podataka organizovanih u
logike celine predstavljene tabelama. U sistemu baza podataka ona je zaduena za
uvanje podataka. Naredne sekcije ove lekcije su posveene objanjenju pojma
baza podataka.
Sistem za upravljanje bazama podataka ili DBMS je raunarski program (u
praksi obino skup raunarskih programa odnosno aplikacija) koji obezbeuje
kreiranje, obradu i administraciju nad bazom podataka. DBMS dobija zahteve u
obliku upita i prevodi te zahteve u odgovarajue akcije nad bazom podataka.
4

DBMS je obino jako velika, sloena aplikacija koja obezbeuje veliki broj
funkcionalnosti za korisnika. U poglavlju o SQL upitnom jeziku (poglavlje 7), koji
je glavna karika u procesu obrade podataka iz baza podataka, dato je vie detalja o
zadavanju upita.
Aplikacija
Sistem za
upravljanje
bazama
podataka
Baza
podataka
Korisnici
Slika 1-3. Komponente sistema baza podataka
Aplikacija nad bazom podataka predstavlja jednu ili vie aplikacija

(raunarskih programa) koje predstavljaju posrednike izmeu korisnika i DBMSa.
Aplikacije mogu itaju ili modifikuju podatke iz baze podataka tako to alju SQL
zahteve DBMSu koji vraa podatke (obino u obliku tabela). S druge strane,
aplikacija na pogodan nain prikazuje korisniku dobijene podatke. Osnovne
informacije o razvoju aplikacija nad bazama podataka su date u poglavlju 8.
Korisnici su etvrta komponenta sistema baza podataka. Oni preko formi
aplikacije pregledaju, unose i modifikuju podatke iz baze podataka, a preko
izvetaja mogu da prikau ili tampaju rezultate pretraga i analiza podataka.
1.4 ta je baza podataka?

Baza podataka, koja predstavlja kolekcija povezanih podataka, se projektuje za
neku organizaciju kao to su: kompanija, banka, fakultet, grad, biblioteka,
supermarket i sl. Baza podataka, kako se vidi iz definicije date u prethodnom
odeljku, predstavlja kolekciju podataka koji su organizovani u tabele. Podaci su
meusobno povezani, a mogu da se koriste za jednu ili vie aplikacija.
Sluajni skup podataka nije baza podataka. Baza podataka se projektuje i gradi
za specifinu namenu i predstavlja neki aspekt realnog sveta organizacije za koju
se ona projektuje. To je tzv. minisvet deo realnog sveta za koji je neophodno
uvati i obraivati podatke. Na primer, za bazu podataka Fakultet mini svet moe
da se odnosi na podatke o studentima, ispitima, nastavnicima, slubama i sl.
Promene u minisvetu utiu na bazu podataka tako da mogu da utiu na promene u
podacima (napr. za bazu podataka Fakultet upis novih studenata) ili na promene u
opisu baze podataka (napr. promena organizacije fakulteta).

Primer: Baza podataka Fakultet
Baza podataka Fakultet se odnosni na mini-svet fakultet i moe da obuhvata
podatke nekim apsektima rada fakulteta odnosno ne mora da pokrije kompletno
poslovanje i rad fakulteta. Ova baza podataka moe da sadri podatke o:
Entitetima objektima realnog sveta, kao to su:

o studijski programi,
o studenti,
o predmeti,
o uionice
Vezama meu ovim entitetima:
o student slua predmet,
o predmet se izodi u uionici,
o predmet pripada studijskom programu
Osnovna namena baze podataka je da bude repozitorijum (skladite) za

podatke. Podaci mogu biti razliitog tipa, tekstualni, numeriki, slike, audio i video
zapisi i sl. Skup podataka pripremljen tako da se mogu jednostavno koristiti, tj.
pregledati, pretraivati, sortirati, uporeivati, itd., ali i menjati. Podaci u bazi
podataka se uvaju tako da je unos novih podataka, kao i itanje i pretraivanje
postojeih, je jednostavno, efikasno i ako je mogue, bez greaka.
Iz definicije baze podataka vidi se da je ona kolekcija meusobno
povezanih podataka, koji su organizovani u tabele. U ovoj definiciji dve su
injenice od znaaja organizacija podataka u tabele i njihova meusobna
povezanost.
Podaci u bazama podataka su organizovani u dvodimenzionalne tabele. Tabela
moe da ima vie kolona, gde svaka kolona predstavlja neku osobinu ili atribut
objekta realnog sveta. Vrste tabele ine konkretni podaci, odnosno konkrente
vrednosti osobina/atributa nekog objekta. Pri tome redosled podataka u tabeli nije
relevantan i tabela nema duplikata ili je njihov broj minimalan.
Na primer, jedna tabela moe da sadri informacije o studentima (slika 1-4).
Kolone tabele definiu atribute odnosno uvaju vrednosti izabranih osobina
studenata: ime, prezime, indeks, matini broj, i sl. Na slici 1-4. prikazana je kolona
Prezime koja uva prezimena studenata. Vrste u takvoj tabeli su studenti, tako da
se svaka vrsta odnosi na jednog studenta. Na slici 1-4 oznaena je vrsta koja se
odnosi na studenta Milana Milanovia sa indeksom 2222 i matinim brojem
654321. Presek jedne vrste i jedne kolone predstavlja eliju koja sadri vrednost
odgovarajue osobine odnosno atributa. U ovom sluaju, to je vrednost prezimena
studenta Milanovia.

Ime
Prezime
Indeks
MBR
Petar
Petrovi
1111
123456
Milan
Milanovi
2222
654321
Jovan
Jovanovi
3333
345612
Slika 1-4. Tabela u bazi podataka sa oznaenom vrstom i kolonom
Koje e tabele da sadri baza podataka zavisi od problema za koji treba

realizovati bazu podataka. Na primer, baza podataka se moe odnosti na kolu, pa
e u tom sluaju tabele biti o uenicima, nastavnicima, odeljenjima, i sl. Postupak
izbora i definisanja tabela za bazu podataka je deo procesa modeliranja odnosno
izgradnje modela podataka. Model podataka je detaljno objanjen u sekciji nakon
sekcije o DBMSu.
Ime
Prezime
MBR
Milan
Petrovi
123456
Milan
Ili
654321
Aleksandar
Jovanovi
345612
Ime
Prezime
Indeks
MentorMBR
Petar
Petrovi
1111
123456
Milan
Milanovi
2222
654321
Jovan
Jovanovi
3333
654321
Slika 1-5. Meusobna povezanost podataka u bazi podataka
Meusobna povezanost podataka je ono po emu se baza podataka razlikuje u

odnosu na tradicionalni pristup zasnovan na datotekama i programe za unakrsna
izraunavanja ko to je Excel. Povezanost podataka obezbeuje znaajne prednosti
kod pretraivanja kada korisnik moe da na osnovu veza izvue mnogo vie
podataka. Na primer, ako u bazi podataka postoje dve tabele: tabela koja uva
podatke o studentima i tabela sa podacima o njihovim mentorima (slika 1-5), veza
izmeu studenta i mentora je ostvarena preko matinog broja mentora.
Uparivanjem vrednosti MBR i MentorMBR moe da se ostvari veza i da se za
studenta dobiju i svi podaci o mentoru ili obrnuto da dobijete podatke o svim
studentima iji je mentor zadati profesor. Ovi podaci mogu da se obezbede
odgovarajuim zahtevom (SQL upitom) DBMSu (objaenje u poglavlju o upitnom
jeziku SQL).

Opisi podataka i ogranienja nad podacima (tzv. metapodaci) su sastavni deo
sistema baze podataka. Baza podataka pored podataka sadri i metapodatke,
odnosno podatke o samoj strukturi baze podataka. Metapodaci mogu da se odnose
na imena tabela, imena kolona u svakoj tabeli, na podatke o korisnicima podataka,
kao i raznim pomonim strukturama koje obezbeuju brz prstup podacima
(indeksi).
Ovi opisi se nalaze u sistemskom katalogu koji je dostupan i DBMS-u i
korisnicima kojima je potrebno poznavanje strukture baze podataka. Nezavisnost
programa i podataka je obezbeena tako to su opisi podataka u DBMS katalogu
i nezavisni su od programa za pristup podacima.
1.5 ta je Sistem za upravljanje bazama podataka?

Softverski sistem koji omoguava korisnicima definisanje, kreiranje i
manipulisanje bazom podataka naziva se sistem za upravljanje bazama
podataka (eng. Database Management System - DBMS).
Definisanje se odnosi na specificiranje tipova podataka, struktura i

ogranienja za podatke koje treba memorisati u bazi podataka.
Kreiranje podrazumeva proces memorisanja podataka na nekom
medijumu koji kontrolie DBMS.
Manipulisanje podrazumeva postavnjanje upita bazi podataka da bi se
nali specifini podaci, auriranje baze podataka da bi se unele promene
nastale u mini svetu i generisanje izvetaja na osnovu podataka
memorisanih u bazi podataka.
Za kontrolisani pristup podacima u bazi podataka DBMS treba da obezbedi:
Sigurnosni sistem, koji onemoguava pristup bazi podataka

neautorizovanim korisnicima (sigurnosni servisi), odnosno samo
autorizovani korisnici mogu da koriste podatke u skladu sa definisanim
privilegijama (autorizacioni servisi).
Integritetni sistem, koji odrava konzistentnost podataka u bazi
podataka, odnosno da se sve promene deavaju u skladu sa definisanim
pravilima.
Sistem za kontrolu i upravljanje konkurentskim pristupom, koji
doputa deljivi pristup podacima iz baze podataka, tj da se obezbedi
korektno auriranje podataka kada vie korisnika pokuava istovremeno
da vri auriranja.
Sistem za kontrolu i upravljanje oporavkom baze podataka, koji

omoguava rekonstrukciju prethodnog konzistentnog stanja u sluaju
neke hardverske ili softverske neispravnosti.
Katalog kome korisnici mogu pristupati, koji sadri opis podataka koji
su memorisani u bazi podataka.
Podrku za transakcije, koja obezbeuje korektno izvravanje niza
transakcija koje mogu biti meusobno zavisne; transakcija je skup
operacija upisa i itanja iz baze podataka koji se tretira kao celina tj ima
svoj poetak i kraj.
Razne korisnike funkcije, kao to su import, eksport podataka,
statistike analize i funkcije za nadgledanje.
DBMS obino nudi jezike koji omoguavaju kontrolisani pristup i rad sa

podacima:
Jezik za opis podataka (eng. Data Definition Language - DDL), koji

omoguava korisnicima definisanje tipa i strukture podataka, kao i
ogranienja nad podacima memorisanim u bazi podataka (naredne
lekcije CREATE TABLE naredba).
Jezik za manipulaciju podacima (eng. Data Manipulation Language DML), koji omoguava korisnicima umetanje, auriranje, brisanje i
pretraivanje podataka iz baze podataka (naredne lekcije SELECT,
INSERT INTO, UPDATE naredbe).
Jezik za definisanje naina memorisanja podataka (eng. Storage
Definition Language - SDL), koji se koristi za specificiranje interne
eme baze podataka.
Kontrolisani pristup bazi podataka, to ukljuuje razliite funkcije i
mehanizme za pristup podacima u bazi podataka.
Prednosti koje obezbeuje DBMS u odnosu na tradicionalni pristup zasnovan

na datotekama su brojne:
Nezavisnost podataka - Aplikacioni programi su nezavisni od

reprezentacije i naina memorisanja podataka. DBMS nudi aplikaciji
apstraktni pogled na podatke.
Efikasan pristup podacima - DBMS koristi posebne tehnike za efikasno
memorisanje i pretraivanje podataka.
Integritet i bezbednost podataka - DBMS kontrolie integritet podataka
koristei ogranienja koja je definisao projektant baze podataka. DBMS
9
nadgleda pristupne privilegije korisnika, tako da svaki korisnik moe

videti samo podatke za koje poseduje pristupne privilegije
Administracija podataka - Kada su podaci deljivi centralizovana
administracija podataka donosi znaajno poboljanje (zaduenje
administratora baze podataka)
Konkurentni pristup i oporavak - DBMS upravlja konkurentnim
pristupom podacima od strane vie korisnika, i ima ugraene mehanizme
oporavka baze podataka od razliitih neispravnosti.
Krae vreme razvoja aplikacija - DBMS ima ugraene razliite funkcije
za rad sa podacima to aplikacionim programerima znaajno olakava
zadatak razvoja aplikacije i nudi interfejs iz jezika visokog nivoa ka
bazi podataka.
Postoje i nedostaci, koji ne ograniavaju znaajno prednosti koje DBMS prua.

Ipak, za reavanje problema i aplikacije koje rade sa malom koliinom podataka, i
tradicionalna obrada zasnovana na datotekama moe da bude bolji izbor od
korienja baza podataka. Neki nedostaci korienja baza podataka i DBMSa su:
Sloenost DBMS zahteva poznavanje rada svih njegovih komponenti,

pa je posao administratora jako zahtevan.
Veliina za instalaciju DBMSa i uvanje podataka obino treba daleko
vie memorijskog prostora u odnosu na tradicionalni pristup.
Trokovi za DBMS obuhvataju dodatne trokove za instalaciju i
odravanje DBMSa, kao i dodatne trokove za nabavku hardvera
odnosno servera na kojima se DBMS i baza podataka instaliraju.
Trokovi konverzije ako postoji potreba da se postojei podaci
konvertuju u format definisan bazom podataka; kod novih sistema ovi
trokovi mogu da se odnose na unos postojeih podataka iz drugih
izvora informacija.
Performanse zavise od samog DBMSa, podeavanja, iskustva
administratora i sl.
Vei uticaj neispravnosti neispravnosti mogu direktno da utiu na rad
DBMSa, to podrazumeva da DBMS mora da bude u stanju da reava
takve probleme.
Izbor DBMSa moe takoe da bude jedan od problema u procesu razvoja

sistema baze podataka. Danas na tritu postoji veliki broj proizvoaa DBMSa
koji nude sistema razliitih performansi i koji su namenjeni razliitim segmentima
trita. Koji DBMS ete izabrati zavisi od tipa i veliine problema koji treba da
10

reite realizacijom aplikacije. U narednoj sekciji dat je kratak prikaz tipova sistema
baza podataka.
1.6 Tipovi sistema baza podataka

Tehnologija baza podataka se moe koristiti za veliki broj aplikacija. Praktino
danas skoro i da ne moe da se realizuje aplikacija koja ne koristi neki sistem baza
podataka za uvanje podataka bez obzira da li se radi o standardnim desktop
aplikacijama, kao to su knjigovodstvene aplikacije, sistemi za upravljanje
dokumentima, sistemi za banke, i sl, ili se radi o modernim Web aplikacijama koje
obezbeuju sloenu funkcionalnost u distribuiranom okruenju, od on-line
kupovine do raznih socijalnih mrea i sl. U zavisnosti od aplikacije, zahtevi prema
bazi podataka mogu znaajno da se razlikuju.
Jedan granini sluaj se odnosi na potrebu za aplikacijom za evidenciju kunih
trokova. U tom sluaju ona obino sadri samo nekoliko tabela, gde svaka tabela
moe da ima samo nekoliko stotina vrsti. Aplikaciju, a samim tim i bazu podataka,
koristi samo jedan korisnik. Za takve sisteme se obino koristi naziv personalni
sistemi baza podataka (slika 1-6). Naravno, ovakvi sistemi mogu da se primene i
na mnogo sloenije aplikacije od evidencije kunog budeta. Na primer, mogu da
pokriju i poslovane manjeg preduzea, ili da podre rad nekog Web sajta.
S druge strane, ako se baza podataka koristi u velikoj kompaniji koja ima vie
organizacionih jedinica, gde svaka od njih ima sopstvene poslovne procese,
neophodna vam je podrka sistema baza podataka koji moe da obezbedi uvanje i
pretragu velike koliine informacija na vie distribuiranih lokacija. Takvi sistemi,
poznati kao enterprise sistemi baza podataka (slika 1-7), sadre veliki broj tabela,
a neke od njih mogu da imaju i nekoliko stotina hiljada vrsta i vie, podacima moe
konkurentno da pristupa veliki broj korisnika i moraju da rade 24 asa dnevno, 7
dana u nedelji.
Aplikacija
Korisnik
Sistem za
upravljanje
bazama
podataka
Baza
podataka
Microsoft Access
Ili neki drugi Personalni DBMS
Slika 1-6. Personalni sistem baza podataka
Veliina problema, odnosno tip sistema baza podataka koji treba da se primeni,
odreuje izbor sistema za upravljanje bazama podataka. Naravno, izmeu
personalnih i enterpise sistema postoji irok opseg drugih sistema razliitog nivoa
11

sloenosti u odnosu na koliinu podataka koju treba obraivati. Za takve sisteme
moe da se izabere DBMS u zavisnosti od zahteva koji se postavljaju pred
sistemom baze podataka, ali i u zavosnosti od cene i raspoloivih sredstava za
razvoj.
Aplikacija A
Java kod
Aplikacija B
C# kod
Aplikacija C
Sistem za
upravljanje
bazama
podataka
Baza
podataka
Oracle, DB2,
SQL Server,
MySQL i sl
DBMS
HTML, ASP
kod
Korisnici
Slika 1-7. Enterprise sistem baza podataka
Komponente personalnog sistema baza podataka su prikazane na slici 6.

Microsoft Access ili neki drugi personalni DBMS, ima ulogu aplikacije i DBMSa.
Personalni sistem baza podataka je razvijen tako da se korisniku obezbedi
jednostavan razvoj aplikacija. Na primer, korienjem Access-a, korisnik moe da
razvija aplikaciju ili da koristi funkcije DBMSa, esto ne primeujui razliku
izmeu ova dva dela. Praktino, Access u sebi sadri razvojno okruenje za
aplikacije i DBMS. Na taj nain skriveni su mnogi aspekti koji se odnose na
deavanja iza scene u procesu obrade podataka. Iako u pozadini i ovaj tip
DBMSa radi sa SQLom, korisniku je obezbeen veliki broj arobnjaka (wizard-a),
ijom upotrebom moe da se pojednostavi posao realizacije aplikacije. Na prvi
pogled to predstavlja olakanje, ali ako neto od onoga to treba uraditi nije
pokriveno arobnjakom, kao i za bilo koji ozbiljni zahvat, potrebno je da zna ta je
iza scene. Za razvoj bilo kog velikog sistema, korisnik mora da naui i te
skrivene tehnologije.
12

Na slici 1-7. prikazan je enterpise sistem baza podataka. Na slici su prikazane
aplikacije razvijane u razliitim jezicima: Java, C#, HTML i ASP.NET. Takve
aplikacije koriste velike DBMS sisteme za upravljanje bazom podataka.
arobnjaka kao kod personalnih sistema uglavnom nema, ali postoje slini alati
koji mogu da pomognu u razvoju takvih sistema. Programeri moraju da napiu kod
koji e da obezbedi pristup i pretraivanje podataka korienjem funkcija DBMSa.
Iako su poetne prednosti koje prua skrivanje tehnologija i sloenosti DBMSa
kod personalnih sistema jako zgodne, oigledno je da za razvoj velikih sistema
neophodno mnogo ire znanje. Tehnologije prezentovane u narednim lekcijama
daju mogunost razvoja velikih sistema, ali i mogunost da se personalni sistemi
obogatite elementima koji nisu deo arobnjaka.
1.7 Zanimljivosti: istorijat DBMSa

U ovom odeljku dat je kratak pregled istorije razvoja DBMSa. Ovaj pregled je
samo pogled autora na istorijski razvoj i ne mora da predstavlja pravo stanje.
Mogue je da su u toku vie od 50 godina razvoja ove oblasti, neke faze nisu
navedene a imale su istorijski znaaj. Ono to je znaajno je da se oblast baza
podataka intenzivno razvija i da je njen znaaj za razvoj informacionih sistema
ogroman. Istorijski, razvoj DBMSa poinje 60-tih godina prolog veka sa
povremenim drastinim promenama i traje sve do dananjih dana:
60-tih godina 20-tog veka
o
projekat Apollo, na inicijativu predsednika Kenedija. Rezultat

ovog projekta je GUAM (Generalized Update Access Method)
Sredinom 60-tih
o
IBM je prihvatio GUAM ideju i razvio IMS (Information

Management System) to je hijerarhijski DBMS
Sredinom 60-tih godina

o
General Electric je razvio IDS (Integrated Data Store) to je

mreni DBMS
Prvi DBMS opte namene koga je projektovao Charles Bachman,

prvi dobitnik Turing-ove nagrade koju dodeljuje ACM (ekvivalent
Nobelove nagrade za Raunarske nauke)
Bachman je nagradu dobio za rad u oblasti baza podataka
1967. je formirana, u okviru CODASYL-a, Database Task Group (DBTG)

koja je uradila standard za DBMS;
o
1969 draft report
1971 final report

13

1970. E.F.Codd iz IBM Research Lab je predloio relacioni model
Prvi komercijalni relacioni DBMS su proizvedeni krajem 70-tih i poetkom
80-tih godina 20-tog veka:
o
Projekat System R (IBM) krajem 70-tih (SQL)
DB2 i SQL/DS (IBM) 80-tih
Oracle (Oracle Corporation) 80-tih
Danas postoji na hiljade relacionih DBMS-ova za mainframe i PC

okruenja:
o
INGRES (Computer Associates)
INFORMIX, DB2 (IBM)
Office Access, Visual FoxPro (Microsoft)
InterBase, JDataStore (Borland)
R:Base (R:Base Technologies)
1976. Chen je predloio ER model

1979. Codd je predloio proirenu verziju relacionog modela RM/T i 1990.
RM/V2 koji se ubraja u semantike modele podataka
Druga polovina 90-tih godina 20-tog veka: Objektno-orijentisani DBMS
(OODBMS) i Objektno-relacioni DBMS (ORDBMS)
Poetak ovog veka
o
Postrelacione BP
XML native BP i podrka za XML u RDBMS
Poslednjih desetak godina

o
Relacione baze podataka + nove tehnologije + skalabilnost
NoSQL baze podataka
U ovom trenutku: Trendovi vraanja na stare, dobre vrednosti RDBMS
14
2 MODELI
P O D ATA K A I P R O C E S
P R O J E K T O VA N J A B A Z E P O D ATA K A
Baza podataka kao kolekcija neredundantnih povezanih podataka koji se koriste

za jednu ili vie aplikacija uva podatke koji se odnose na deo realnog sveta, tzv
mini svet, za koji se ona projektuje i razvija. U procesu razvoja baze podataka
najpre se formira model realnog sistema, a zatim se na osnovu tog modela gradi
formalni sistem. Razlog za formiranje modela je da se istaknu znaajne
karakteristike sistema i da se privremeno stave u drugi plan sve one karakteristike
koje nisu bitne za sistem koji se razvija.
Postoji mnogo razliitih mogunosti da se modelira sistem. U fazi modeliranja,
zadatak sistem analitiara, odnosno inenjera zahteva, je da otkrije funkcije koje
sistem mora izvravati, podatke koje mora pamtiti i obraivati, informacije koje
mora obezbeivati za potrebe korisnika, sekvence u kojima se funkcije moraju
izvravati i u kojima se moe pristupati podacima. Model sistema koji se odnosi na
podatke predstavlja emu (ili opis) baze podataka. Model podataka predstavlja
vrstu meta-modela, koji omoguava projektojovanje eme baze podataka.
U ovom poglavlju dat je najpre opis nivoa apstrakcije u DBMSu, a nakon toga i
opis odgovarajuih modela podataka. Znaajan deo procesa projektovanja baza
podataka se odnosi na korienje konceptualnih modela, pa je naredno poglavlje
posveeno modelu entiteta i veza.
2.1 Nivoi apstrakcije u DBMS-u

U DBMS-u podaci su opisani u tri nivoa apstrakcije (slika 2-1.):
Eksterna ema (esto se naziva i podema): ima ih vie, po jedna za

svaku grupu korisnika
Konceptualna ema: postoji jedna za celu bazu podataka
Interna ema: postoji jedna za celu bazu podataka
ema baze podataka je opis baze podataka. DBMS je odgovoran za

preslikavanja izmeu ovih ema, odnosno za preslikavanje konceptualne u internu
emu i obrnuto, kao i za preslikavanje eksterne u konceptualnu emu i obrnuto.

eme, odnosno opisi se memoriu u sistemskom katalogu DBMS-a. Ovakva
arhitektura je poznata kao Arhitektura tri eme DBMS-a (ANSI-SPARC
arhitektura, slika 8). Svi DBMS-i ne razlikuju sva tri nivoa. Cilj arhitekture 3-eme
je odvojiti pogled korisnika baze podataka od naina njene fizike reprezentacije.
Instancu baze podataka ine podaci koji se trenutno nalaze u bazi podataka.
Jednoj emi baze podataka moe odgovarati vie instanci. ema baze podataka se
naziva i intenzija baze podataka, a instanca ekstenzija ili stanje baze podataka.
Eksterni nivo (nivo pogleda) je korisniki pogled na bazu podataka. Svaki
pogled na bazu podataka opisuje samo onaj deo baze podataka koji je od interesa
za konkretnu grupu korisniku i prikriva ostali deo baze podataka od ove grupe
korisnika. Sadri veliki broj eksternih ema ili pogleda korisnika. Razliiti
pogledi mogu imati razliite reprezentacije istih podataka.
Konceptualni (logiki) nivo sadri konceptualnu emu koja predstavlja globalni
opis baze podataka. Konceptualni nivo predstavlja pogled na bazu podataka svih
korisnika baze podataka. Opisuje koji se podaci uvaju u bazi podataka, kako su ti
podaci struktuirani i kako su meusobno povezani.
Korisnik 1
Eksterni
nivo
Pogled 1
Pogled 2
Eksterna ema 1
Eksterna ema 2
Konceptualni
nivo
Interni
nivo
Fiziki
nivo
Korisnik 2
Korisnik n
Pogled n
Eksterna ema
Konceptualna
ema
Interna
ema
Baza
podataka
Sistemski
katalog
Slika 2-1. Arhitektura tri eme DBMSa
Konceptualna ema opisuje entitete, atribute i njihove veze, ogranienja nad

podacima, semantike informacije o podacima, sigurnost i integritet informacija i
ne sadri nikakve detalje o nainu memorisanja podataka!
Interni nivo predstavlja fiziku reprezentaciju baze podataka na raunaru. Sadri
internu (fiziku) emu koja opisuje kako su podaci memorisani u bazi podataka.
Interna ema opisuje sve detalje o memorisanju podataka, definie strukturu i
organizaciju fajlova koji se koriste za smetanje baze podataka. Ovaj nivo koristi
16
Modeli podataka i proces projektovanja baza podataka

usluge fajl sistema operativnog sistema (OS) za smetanje podataka na memorijski
medijum, za formiranje indeksa, za pretraivanje podataka itd. Na internom nivou
se definie dodela prostora na disku za podatke i indekse, opis slogova, smetanje
slogova, kompresija podataka i tehnike enkripcije podataka.
Ispod internog nivoa je fiziki nivo kojim moe da upravlja operativni sistem
po direktivama DBMS-a. Funkcije OS-a i DBMS-a na fizikom nivou nisu strogo
razgraniene, pa variraju od jednog do drugog DBMS-a. Neki DBMS-i koriste
metode pristupa OS-a, dok drugi imaju sopstvene fajl sisteme.
Opisana arhitektura tri eme omoguava opis i memorisanje podataka preko
DBMS-a. Korisnici baze podataka su u nekom realnom svetu, podaci memorisani u
bazi podataka predstavljaju neke aspekte tog realnog sveta (mini svet). DBMS
omoguava korisnicima da opiu (definiu) podatke koje ele memorisati u bazi
podataka. Za kreiranje modela baze podataka (tj. eme baze podataka) koristi se
model podataka. ema baze podataka predstavlja opis logike strukture podataka,
odnosno same baze podataka.
2.2 Modeli podataka

Proces razvoja baze podataka podrazumeva formiranje modela realnog sistema,
na osnovu izabranih znaajnih karakteristika sistema. Modeliranje strukture
podataka je zadatak projektanta baze podataka i obuhvata aktivnosti koje se odnose
na otkrivanje i izbor podataka koji baza podataka mora pamtiti i obraivati. Ovako
dobijene informacije su osnova za kreiranje modela baze podataka izabranim
modelom podataka.
Model podataka je integrisana kolekcija koncepata za opis i manipulaciju
podacima, vezama izmeu podataka i ogranienjima nad podacima i vezama. To je
matematika apstrakcija koja se koristi za projektovanje modela realnog sistema.
Model podataka sadri skup koncepata i konstrukcija koji se koristi za opis
sadraja baze podataka i veza izmeu podataka u bazi podataka. Taj opis, koji se
zove i ema baze podataka, se odnosi na tip injenica ukljuenih u bazu podataka
i pravila ili ogranienja koja postoje.
Model podataka ima tri komponente:
Strukturnu koja se sastoji od skupa pravila prema kojima se baza

podataka moe konstruisati,
Integritetnu koja definie tipove ogranienja nad vrednostima atributa,

veze izmeu podataka i meusobnu uslovljenost podataka,
Operacijsku koja definie tipove operacije nad strukturama podataka i

koja modelira dinamike osobine realnog sistema.
U odnosu na ANSI-SPARC arhitekturu DBMS-a modeli podataka mogu biti:

17
Eksterni modeli podataka slue za predstavljanje pogleda korisnika na

realni svet,
Konceptualni modeli podataka slue za predstavljanje logikog

pogleda ili pogleda zajednice na realni sistem nezavisno od DBMS-a,
Interni modeli podataka slue za predstavljanje konceptualne eme na

takav nain da je razumljiva za DBMS.
Da bi model podataka bio upotrebljiv mora obezbeivati prostu korespodenciju

izmeu koncepata koje nudi i koncepata realnog sveta. Prema tipu koncepata koji
nude za opis baze podataka, modeli podataka se razvrstavaju u tri kategorije:
Konceptualni modeli podataka nude koncepte visokog nivoa, kao to

su entiteti, atributi i veze, koji su razumljivi i za krajnjeg korisnika i za
projektanta baze podataka, i koji se mogu lako preslikati u
implementacioni model podataka. Najpoznatiji konceptualni model
podataka je model entitet-veza (prikazan u poglavlju 3).
Implementacioni modeli podataka nude koncepte koji su prihvatljivi

za projektanta baze podataka i koji su pogodni za direktnu
implementaciju na raunaru. Najpoznatiji implementacioni modeli
podataka su relacioni (poglavlje 4), objektno-relacioni i objektnoorijentisani. Za predstavljanje informacije u relacionom modelu
podataka koristi se kolekcija tabela, kod objektno-relacionog modela
podataka koristi se kolekcija objekata klasa i tabela, a kod objektnoorijentisanog modela podataka koristi se kolekcija klasa i njihovih
meusobnih veza.
Fiziki modeli podataka nude koncepte za opis naina memorisanja

baze podataka u raunaru. To su koncepti niskog nivoa, kao to su tipovi
podataka, formati slogova, kriterijumi ureenja slogova, memorijske
strukture podataka i pristupni putevi.
Konceptualni modeli podataka ne zavise od izabora DBMSa i ne utiu izbor. S

druge strane izbor implementacionog modela odreuje izbor tipa DBMSa.
Najpoznatiji implementacioni model je relacioni model. Ogormna veina
komercijalni sistema koristi relacioni model, pa se za takve baze podataka koristi
naziv relacione baze podataka, a odgovarajui DBMS je relacioni DBMS
(RDBMS). U ovom materijalu se pod pojmom baza podataka podrazumeva
relaciona baza podataka.
2.3 Projektovanje baze podataka

Problem koji treba reiti u fazi projektovanja baze podataka se odnosi na
projektovanje logike i fizike strukture jedne ili vie baza podataka da bi se
zadovoljile informacione potrebe korisnika u organizaciji za definisani skup
18

operacija. Ciljevi su da se zadovolje informacioni zahtevi specificiranih korisnika i
aplikacija i da se obezbedi struktuiranje informacija koje je prirodno i lako za
razumevanje. Pri tome je potrebno podrati zahteve obrade i zahteve performansi
(vreme odgovora, vreme obrade i memorijski prostor).
Realni svet (koji treba predstaviti modelom podataka), odnosno njegov deo koji
je od znaaja za proces projektovanja baze podataka (mini-svet) se sastoji od
objekata koji mogu biti stvarni ili apstraktni i koje nazivamo entitetima.
Svaki objekat, odnosno entitet, poseduje neka svojstva. Na primer, entitet
"vozilo" ima vlasnika, registarski broj, datum registracije, godinu proizvodnje,
proizvoaa, marku, boju, tip motora, i dodatnu opremu. Svojstva ili atributi
objekta e biti predstavljena kolonama u odgovarajuoj tabeli baze podataka.
Objekti meusobno mogu biti povezani razliitim odnosima odnosno
relacijama. Svaka takva relacija moe da poseduje posebna svojstva. Relacije se
mogu iskoristiti kod pretraivanja meusobno povezanih podataka, na primer, kod
pretraivanja podataka o registrovanim vozilima i njihovim vlasnicima. Vie
detalja o nainu povezivanja podataka iz tabela se nalazi u sekciji 4.5 koja se
odnosi na kljueve relacija.
Vano: Izborom objekata, definisanjem njihovih svojstava i prepoznavanjem
veza izmeu objekata, izvreno je modeliranje mini-sveta odnosno dela realnog
sveta.
Faze procesa projektovanja baze podataka, prikazane na slici 2-2., su:
Prikupljanje i analiza zahteva je prva faza projektovanja u kojoj se
prikupljaju informacije o podacima i transakcijama imajui u vidu sadanje i
budue potrebe korisnika. Prikupljaju se imena i opisi entiteta, imena i opisi
atributa, izvori, naini upotrebe, tajnost, znaaj i vrednost svih podataka.
Prikupljeni podaci se analiziraju i formiraju se jasni i konzistentni zahtevi za
podacima i transakcijama.
U fazi konceptualno projektovanje baze podataka projektuje se konceptualni
model baze podataka, nezavistan od bilo kakvih implementacionih detalja, kao to
su izabrani DBMS, aplikacioni programi, programski jezici, hardverska platforma,
traene performanse i slino.
Konceptualni model baze podataka sadri detaljan opis entiteta, veza i
ogranienja. Koriste se dva prilaza. Po prvom se nezavisno projektuju lokalni
konceptualni modeli podataka za svaki pogled korisnika na bazu podataka, a zatim
se ovi lokalni konceptualni modeli integriu u jedinstven globalni konceptualni
model baze podataka. Po drugom se prvo projektuje globalni konceptualni model
baze podataka, a zatim se na osnovu ovog globalnog modela projektuju lokalni
modeli za pojedine poglede korisnika na bazu podataka. U ovom materijalu
koristie se drugi prilaz. Izlaz iz ove faze projektovanja su konceptalna i eksterne
19

eme baze podataka. Za konceptualno projektovanje eme baze podataka
koristien je ER i/ili EER model podataka.
Slika 2-2. Faze projektovanja baza podataka
U fazi logiko projektovanje projektuje se logiki model baze podataka. On se

dobija preslikavanjem konceptualnog modela u model podataka DBMSa koji je
odabran za implementaciju baze podataka, pri emu se ne uzimaju u razmatranje
konkretne osobine odabranog DBMSa, niti bilo kakve fizike karakteristike
sistema.
Kao implementacioni model podataka moe se koristiti relacioni, objektnorelacioni ili objektno-orijentisani model podataka. Rezultati ove faze projektovanja
su logika ema baze podataka i skup logikih podema. Nakon izbora DBMSa za
realizaciju baze podataka, logika ema se prevodi u implementacionu emu, a
logike podeme u implementacione podeme. Ova faza logikog projektovanja
esto se naziva implementaciono projektovanje.
Na osnovu implementacione eme vri se opis baze podataka u jeziku za opis
podataka (DDLu) i njena realizacija, dok se na osnovu implementacionih podema
grade transakcioni programi (aplikacije nad bazom podataka). U ovom materijalu
20

kao implementacioni model podataka koristie se relacioni model, a za opis
implementacionih ema koristie se DDL podskup SQLa. U mnogim sluajevima
SQL naredbe ukljuuju i neke implementacione detalje, tako da se kompletna SQL
specifikacija baze podataka moe dobiti tek nakon faze fizikog projektovanja.
U fazi fiziko projektovanje baze podataka biraju se interne memorijske
strukture podataka i pristupni putevi za datoteke baza podataka da bi se dobile
traene performanse za planirane aplikacije. Izlaz iz ove faze projektovanja je
interna ema baze podataka. U ovom kursu za opis interne eme takoe e se
koristiti SQL naredbe.
21
3 KONCEPTUALNO
P R O J E K T O VA N J E
B A Z E P O D ATA K A
Cilj konceptualnog projektovanja je kreiranje takvog projekta konceptualnog

modela baze podataka da to vernije opisuje realni sistem za koji se projektuje baza
podataka (slika 3-1.). Na osnovu prikupljenih zahteva, korienjem nekog modela
podataka visokog nivoa, gradi se konceptualni model baze podataka. U okviru
ovog materijala za fazu konceptualnog projektovanja izabran je model entiteta i
veza i njegova proirena verzija za podrku objektno orijentisanih koncepata, tzv
unapreeni model entiteta i veza.
Sistemski
zahtevi
Konceptualno
projektovanje
Konceptualni
model podataka
ER ili EER dijagram
Renik podataka
Slika 3-1. Konceptualno projektovanje baze podataka
Model entitet-veza (engl. Entity Relationship Model), i njegovo proirenje,

unapreeni model entiteta i veza (engl. Enhanced Entity Relationship Model) je
jedan od najpopularnijih semantikih modela podataka koji se koristi na
konceptualnom nivou. Nadalje u tekstu koristie se skraenice ER model za model
entiteta i veza, odnosno EER model za unapreeni ER model.
Model entiteta i veza koristi ER dijagram za grafiko predstavljanje. Autor ovog
modela je Chen 1976 godine, a danas postoji vie verzija (E)ER modela i vie
grafikih notacija. esto se u literaturi moe nai i sa alternativnim nazivima:
model entiteta i poveznika ili model objekti-veze.
Osnovna ideja kod ER modela je da se za realni sistem, odnosno za deo realnog
sveta (tzv mini svet) za koji se projektuje baza podataka, moe identifikovati
postojanje entiteta (objekata realnog sveta) i veza izmeu njih. Svaki entitet
predstavlja neto to postoji kao posebna celina, odnosno razlikuje se u odnosu
na druge entitete koji egzistiraju u mini svetu i moe se odnositi na realni subjekat,
objekat, dogaaj, pojavu ili apstraktni pojam iz mini sveta. ER model se zasniva na

ovakvoj percepciji realnog sveta koja podrazumeva identifikaciju klase slinih
entiteta i specifikaciji veza izmeu njih putem odgovarajuih grafikih koncepata.
Strukturna komponenta ER modela podataka sadri osnovne koncepte kao to
su: entitet, tip entiteta i skup entiteta, atributi, poveznik (veza), tip poveznika i skup
poveznika. EER model sadri sve koncepte osnovnog ER modela i dodaje nove
koncepte iz objektno-orijentisane paradigme, kao to su: generalizacija i
specijalizacija (potklase, natklase i nasleivanje atributa), kategorije, deljive klase.
ER model ima dobro definisana ogranienja u okviru integritetne komponente koja
se uglavnom eksplicitno definiu i odnose se na integritet domena, kardinalnost
tipa poveznika, participaciju tipa poveznika, slabi tip entiteta i klju tipa entiteta.
3.1 Entiteti, tip entiteta i skup entiteta

Entitet je subjekat, objekat, dogaaj, pojava ili apstraktni pojam o kome se
prikupljaju, memoriu, obrauju i prezentiraju podaci u automatizovanim
informacionim sistemima i koji se moe jednoznano identifikovati i na taj nain
izdvojiti u skupu slinih entiteta.
Entitet moe biti objekat koji fiziki egzistira (stvarni objekat, npr. osoba, kola,
kua ili radnik) ili objekat koji konceptualno egzistira (apstraktni objekat, npr.
kompanija, posao ili predmet na univerzitetu).
Stvarni objekti mogu biti prirodni (na primer, reke, planine, mora, ume) ili
vetaki (na primer, telefonske ili vodovodne instalacije, putevi, vozila, zgrade).
Apstraktni objekti mogu biti dogaaji (na primer, osiguranje vozila, popis
stanovnitva, prodaja robe, uplate na iro raun, polaganje ispita, overa semestra,
upis na fakultet), pojmovi (na primer, nauka, znanje, uenje, obuka, profit,
republika, optina, kompanija, vremenska prognoza), stanja (na primer, radi na
projektu, slua predavanje, boravi u bolnici) i uloge (na primer, slubenik, stranka,
doktor, pacijent, radnik, profesor, student, stanovnik).
Kandidati za entitete u realnom sistemu mogu da budu:
Organizacione jedinice: fakultet, katedra, biblioteka,
Lokacije: uionica, raskrsnica, radarska pozicija, laboratorija,
Uloge: radnik, slubenik, student, profesor, stanovnik, referent,
Dogaaji koji se pamte: ispit, utakmica, predavanje, ispit,
Ureaji: proizvodna traka, raunar, skener, radar, antena,
Drugi sistemi sa kojima sistem interaguje
Primer: Potencijalni entiteti za mini svet Fakultet i mini svet Preduzee
Mini svet FAKULTET moe da se odnosi na sledee entitete:

o
24
student
Konceptualno projektovanje baza podataka
o profesor
o predmet
o laboratorija
o udbenik
Za mini svet PREDUZEE, potencijalni entiteti mogu biti:
o
o
o
o
o
radnik
sektor (organizaciona jedinica)
radno mesto
projekat
plan
Skup entiteta (engl. Entity Set) je kolekcija svih entiteta odreenog tipa entiteta
u bazi podataka u nekom trenutku. Praktino, entiteti koji egzistiraju u ljudskom
intelektu kao predstave realnih subjekata, objekata ili dogaaja mogu se
klasifikovati u skupove slinih entiteta za koji se koristi termin skup entiteta.
Primer: Skupovi entiteta
studenti jednog fakulteta

radnici jednog preduzea
proizvodi jednog preduzea
zgrade jednog preduzea
uplate na iro raun
Tip entiteta (egl. Entity Type) je model skupa entiteta i koristi se za opis skupa
entiteta. Tip entiteta opisuje emu ili intenziju skupa entiteta koji dele istu
strukturu. Kolekcija entiteta odreenog tipa entiteta grupisana u skup entiteta se
takoe naziva ekstenzija tipa entiteta.
Svaki tip entiteta u ER modelu podataka ima ime (imenica u jednini), koje je
jedinstveno. Obeleavanje tipa entiteta se vri na sledei nain:
E(A1, A2, ... , An)
gde je E ime tipa entiteta, a Ai | i = 1, n atributi odabrani za modeliranje entiteta E.
Za skup entiteta se koristi ime tipa entiteta.
Za obeleavanje tipa entiteta koriste se dva stila:
Stil A: Obeleavaju se velikim slovima latinine azbuke.
Stil B (UML notacija) Obeleavaju se malim slovima latinine azbuke

osim prvog slova.
25

Primer: Tip entiteta
Ime RADNIK se koristi i za tip entiteta i za trenutni skup svih entiteta

radnik u bazi podataka kojoj taj tip entiteta pripada
Tipovi entiteta RADNIK1, RADNIK2, RADNIK3 modeliraju na razne
naine entitet radnik iz realnog sistema:
o RADNIK1 (IME, DATUM-ROENJA, ADRESA, TELEFON,
SEKTOR, LD, LANOVI-PORODICE)
o RADNIK2 (IME, SEKTOR, LD)
o RADNIK3 (ID-RADNIKA, MATINI-BROJ-STANOVNIKA,
IME-RADNIKA)
Pojava (instanca) tipa entiteta se odnosi na skup podataka kojima je opisan

jedan konkretni entitet zadatog tipa.
Primer: Pojava tipa entiteta
Dve pojave tipa entiteta RADNIK2(IME, SEKTOR, LD) mogu da budu:
SAVA KRSTI, INSTITUT, 85000
JOVAN RISTI, TEST, 57000
Predstavljanje tipa entiteta u ER dijagramu se
pravougaonikom koji sadri ime tipa entiteta (slika 3-2.).
vri
jednostavnim
UML notacija
Radnik
RADNIK
Slika 3-2. Grafika notacija za tip entiteta
3.1.1 Atributi
Atribut je osobina, obeleje odnosno svojstvo koje opisuje neke aspekte objekta
koji treba da se uvaju. Svaki entitet ima obeleja odnosno svojstva koja ga
opisuju. Svi entiteti jednog skupa entiteta imaju bar jedno zajedniko svojstvo na
osnovu koga su svrstani u isti skup.
U prethodnom odeljku je navedeno da tip entiteta, kao model skupa entiteta
opisuje emu skupa entiteta koji dele istu strukturu. Tip entiteta sadri atribute koji
su odabrani za modeliranje skupa entiteta.
Primer: Atributi entiteta
26
Entitet radnik moe imati svojstva, odnosno atribute: matini broj

radnika, ime, prezime, datum rodjenja,
Entitet student moe imati atribute: Broj indeksa, ime, prezime, datum
roenja, godina studija,

Za obeleavanje atributa koriste se dva stila:
Stil A: Obeleavaju se velikim slovom sa crticom ili znakom za

podvlaenje kao poveznikom izmeu rei.
Stil B (UML notacija): Obeleavaju se nizom rei koje se piu malim
slovima, osim prvog slova svake rei. Nema delimitera izmeu rei.
Primer: Obeleavanje atributa

Stil A:
IME
DATUM_UPISA ili DATUM-UPISA
BOJA_KOLA ili BOJA-KOLA
Stil B:
Ime
DatumUpisa
BojaKola
Svaki konkretan entitet ima vrednosti za svaki od atributa koji ga opisuje. Na
primer, jedan od studenta ima broj ideksa 1231, njegovo ime je Petar (odnosno
vrednost atributa ime je Petar), prezime Petrovi, godina studija je III.
Domen atributa specificira skup moguih vrednosti atributa. Svaki konkretan
entitet za svaki od atributa ima odreenu vrednost iz odgovarajueg domena.
Obeleavanje domena: dom(ime_atributa)
Primer: Domen atributa
BOJA_KOLA, OCENA_STUDENTA i PRELAZNA_OCENA:
dom(BOJA_KOLA) = (bela, crvena, zelena)
dom(OCENA_STUDENTA) = (5, 6, 7, 8, 9, 10)
dom(PRELAZNA_OCENA) = (6, 7, 8, 9, 10)
Ogranienje domena imaju gotovo svi modeli podataka. Opti oblik ogranienja
domena je: (tip podatka, duina podatka, uslov)
Tip podatka i duina podatka su standardna ogranienja domena. Tip podatka
definie vrstu znakova putem kojih se izraava vrednost stributa. Duina podatka
definie maksimalni broj znakova koji mogu biti upotrebljeni za izraavanje
vrednosti atributa. esto ova ogranienja nisu dovoljno precizna, pa se dodaje trea
komponenta uslov, koja preciznije definie ogranienje domena.
Standardna ogranienja domena su tipovi podataka sa duinama tih podataka:
INTEGER(broj cifara), REAL(broj cifara ispred zapete, broj cifara iza zapete),
CHARACTER(broj znakova), DATE, LOGICAL, itd.
27

Primer: Ogranienje domena
Ako je dom(OCENA) pridrueno standardno ogranienje INTEGER(2),

tada vai dom(OCENA)={0,1,2,...,99}
Ako je dom(NAZIV_PREDMETA) pridrueno standardno ogranienje
CHARACTER(15), tada vai da naziv predmeta moe biti bilo koji niz
duine 15 znakova
Pojava (instanca) atributa je konkretna vrednost koju atribut uzima iz svog

domena da predstavi podatak o odreenom entitetu. Samo instanca atributa moe
predstavljati podatak.
Primer: Pojava atributa
Student PERA ILI ima broj indeksa RE 5034/88. Tada je podatak PERA
ILI instanca atributa IME_STUDENTA, a RE5034/88 instanca atributa
BROJ_INDEKSA
Primer: Pojava svih atributa
Dve vrednosti svih atributa tipa entiteta RADNIK(IME, ADRESA,
DATUM_ROENJA, KUCNI_TELEFON, ZANIMANJE, SEKTOR, LD):
Pera Ili, Nika 16 18000 Ni, 05-FEB-68, 018-315-072, inenjer
elektronike, Razvoj, 35000
Mina Stojanovi, Majakovskog 29 18000 NI, 25-JUL-85, 018-515799, diplomirani pravnik, Zajednike slube, 25000
Predstavljanje atributa u ER dijagramu je preko elipsi koje sadre ime atributa i
povezani su linijama sa odgovarajuim tipom enetiteta. Na slici 3-3. prikazan je tip
entiteta RADNIK sa atributima Matini broj (MBR), Ime i Prezime.
IME
MBR
PREZIME
RADNIK
Slika 3-3. Predstavljanje atributa u ER dijagramu
Atributi mogu da budu prosti i sloeni. Atribut je prost (elementaran) ako se

dalje ne moe dekomponovati ili ako se u konretnoj situaciji ne dekomponuje na
28

komponente koje ine atribut. Vrednost elementarnog atributa je elementarni
(prost) podatak. Atribut je sloen (kompozitan) ako je sastavljen od vie
elementarnih atributa. Vrednost sloenog atributa je sloeni (strukturni) podatak.
Primer: Prosti i sloeni atributi
Prosti atributi:
OCENA-STUDENATA, BOJA-AUTOMOBILA, NAZIV-PROIZVODA
Sloeni atributi:
ADRESA-STUDENTA, IME-STUDENTA, DATUM-UPISA
Sloeni atribut se moe podeliti (dekomponovati) na manje delove koji
predstavljaju vie osnovnih atributa sa nezavisnim znaenjem:
Primer: Dekomponovanje sloenih atributa
ADRESA_STUDENTA se moe dekomponovati na

o
IME_STUDENTA se moe dekomponovati na

o
ULICA, BROJ_ZGRADE, BROJ_STANA, GRAD
LIME, SREDNJE_SLOVO, PREZIME
DATUM_UPISA se moe dekomponovati na

o
DAN, MESEC, GODINA
U ovom materijalu dekomponovan sloeni atribut e se oznaavati na sledei

nain:
ADRESA_STUDENTA( ULICA, BROJ_ZGRADE, BROJ_STANA,

GRAD)
IME_STUDENTA (LIME, SREDNJE_SLOVO, PREZIME)
DATUM_UPISA (DAN, MESEC, GODINA)
Postavlja se pitanje kada i zato koristiti sloene atribute? Sloeni atributi su

korisni za modeliranje situacije gde se korisnici ponekad obraaju atributu kao
celini, a ponekad pojedinim komponentama tog atributa. Ako se sloeni atribut
uvek referencira kao celina treba ga modelirati kao prost atribut. Na primer, ako
kod adrese studenta nema potrebe za nezavisnim referenciranjem pojedinih
komponenti adrese, adresu studenta treba modelirati kao prost atribut.
Predstavljanje sloenih (kompozitnih) atributa u ER dijagramu je na slian
nain kao predstavljanje prostih atributa elipsom sa upisanim imenom
29

kompozitnog atributa koja je povezana sa odgovarajuim tipom entiteta (slika 34.). Komponente se predstavljaju na isti nain, ali su povezane sa odgovarajuim
kompozitnim atributom iji su delovi.
Komponente
kompozitnog
atributa
LIME
SSLOVO
PREZIME
Kompozitni atribut
IME
IME
MBR
RADNIK
Slika 3-4. Sloeni (kompozitni) atributi u ER dijagramu
Izvedeni atribut je atribut ije se vrednosti dobijaju primenom nekog algoritma

na vrednosti drugih atributa (elementarnih, sloenih, izvedenih). Vrednost
izvedenog atributa je izvedeni podatak.
Primer: Izvedeni atribut
Atribut SREDNJA_OCENA studenta se moe dobiti primenom

algoritma za izraunavanje srednje vrednosti na atribut OCENA u
entitetu STUDENT
Atribut BROJ_ZAPOSLENIH u preduzeu se izvodi primenom
algoritma prebrojavanja pojava entiteta RADNIK
Predstavljanje izvedenih atributa u ER dijagramu se vri na isti nain kao i kod

prostih atributa, s tim da je linija isprekidana (slika 3-5.).
IME
DAT_RODJ
STAROST
izvedeni atribut
STAROST
RADNIK
Slika 3-5. Grafika notacija za izvedeni atribut
30

Jednovrednosni i vievrednosni atributi
Za odreeni entitet jedan atribut moe imati jednu ili vie vrednosti. U prvom
sluaju atribut je jednovrednosni, a u drugom vievrednosni.
Primer: Jednovrednosni i vievrednosni atributi
Atribut DATUM_ROENJA entiteta RADNIK je jednovrednosni

atribut jer radnik moe imati samo jedan datum roenja, npr.05-FEB-68
Atribut KUNI_TELEFON entiteta RADNIK je vievrenosni atribut jer

radnik moe imati vie telefona, npr.520-505 i 224-061
IME
MBR
EMAIL
Vievrednosni atribut
EMAIL adresa
RADNIK
Slika 3-6. Grafika notacija za vievrednosni atribut
Predstavljanje vievrednosnih atributa u ER dijagramu se vri na isti nain kao i

kod prostih atributa, s tim da je linija elipse dvostruka (slika 3-6).
Null vrednosti atributa
U nekim sluajevima, moe da se desi da za konkretan entitet neki od atributa
nema definisanu vrednost. U takvim situacijama se koristi specijalna vrednost Null vrednost atributa. Praktino, atribut nema definisanu vrednost u dva sluaja:
ako se radi o neprimerenom svojstvu za konkretan entitet, ili ako vrednost atributa
postoji, ali je nepoznata.
Null vrednost moe da ima dva znaenja:
Postojea ali nepoznata vrednost Vrednost atributa za posmatrani

entitet ne postoji ili jo uvek nije poznata. Na primer, za radnika koji je
tek treba ili je tek poeo da radi vrednost atributa prethodni radni sta
nije poznata.
Neprimerena vrednost atributa Vrednost atributa za posmatrani nije

primenjiva. Na primer, ako za relaciju RADNIK imamo atribut
FAKULTET u kome se uva naziv fakulteta koji je radnik zavrio, svi
radnici sa srednjom kolskom spremom e imati NULL vrednost za taj
atribut.
31

Primer: Semantika Null vrednosti
Semantika Null vrednosti, neprimerena vrednost atributa:
Ako radnik IVANA GOCI nema telefon u stanu, atribut TELEFON za
ovog radnika e imati NULL vrednost.
Ako radnik IVANA GOCI nije trenutno rasporeena ni u jednom sektoru,
atribut SEKTOR e imati NULL vrednost
Semantika NULL vrednosti, postojea ali nepoznata vrednost:
Ako je adresa radnika IVANE GOCI nepoznata, atribut ADRESA e
imati NULL vrednost
3.1.2 Klju tipa entiteta

Da bismo jedan entitet jednoznano identifikovali u posmatranom skupu
entiteta on mora posedovati neko svojstvo, ili kombinaciju od nekoliko svojstava,
takvu da vrednost tog ili tih svojstava jednoznano odreuju svaku pojavu tog tipa
entiteta. Takva svojstva nazivamo karakteristinim, a njihove vrednosti koristimo
kao identifikator entiteta unutar skupa.
Na primer, skup entiteta RADNIK predstavljamo relacijom/tabelom gde svaka
vrsta odgovara jednom entitetu, odnosno predstavlja jednog konkretnog radnika. U
tom sluaju neophodno je prepoznati svojstva (atribute) koje moemo da koristimo
za identifikaciju radnika unutar skupa radnika.
Minimalni skup atributa koji ima jedinstvenu vrednost za sve pojave odreenog
tipa entiteta je klju tog tipa entiteta. Svaki tip entiteta poseduje bar jedan klju.
Tip entiteta moe imati vie kljueva - to su kljuevi kandidati. Jedan od kljueva
kandidata se bira za primarni klju tipa entiteta.
Primer: Klju tipa entiteta
Zadat je tip entiteta RADNIK3 (ID_RADNIKA, MBR, IME_RADNIKA)
gde su ID_RADNIKA jedinstevni identifikator radnika unutar preduzea, a
MBR jedinsteni matini broj radnika.
Klju moe biti ID_RADNIKA ali i MBR. ID_RADNIKA ima jedinstvene
vrednosti za radnike tog preduzea, a MBR je jedinstven za sve stanovnike pa i
za radnike tog preduzea. Oba atributa su kandidati za kljueve.
Primer: Klju tipa entiteta
Identifikovati primarne kljueve tipova entiteta RADNIK(IME, SSLOVO,
PREZIME, DATUM_RODJENJA, MBR) i SEKTOR(SBROJ, NAZIV).
U relaciji RADNIK primarni klju je oigledno matini broj radnika (MBR).
Kod radnika se moe identifikovati i potencijalni kompozitni klju kandidat, na
primer od kombinacije atributa ime (ime, srednje slovo i prezime zajedno) i
32

datuma roenja. Naravno, ovakav klju se moe izabrati ako ne postoji neki
oigledniji i jednostavniji kao to je u ovom sluaju matini broj.
Primarni klju u relaciji SEKTOR je broj sektora, odnosno atribut SBROJ, zato
to na jedinstven nain identifikuje svaki sektor u preduzeu (ne mogu da
postoje dva sektora sa istim brojem). Klju kandidat (i potencijalni primarni
klju) u ovoj relaciji moe biti i naziv sektora, uz pretpostavku da sektori ne
mogu da imaju ista imena.
Za obeleavanje primarnog kljua se koriste dva naina:
Stil A: primarni klju u tipu entiteta se podvlai kontinualnom linijom
Stil B: iza imena primarnog kljua se stavlja povisilica (#)
Primer: Oznaavanje kljua

U tipu entiteta RADNIK3 oznaen je klju MATINI_BROJ_RADNIKA
korienjem stila A:
RADNIK3(ID_RADNIKA, MBR, IME)
korienjem stila B:
RADNIK3(ID_RADNIKA#, MBR, IME)
Kompletna grafika notacija za predstavljanje atributa u ER dijagramu je data
na slici 3-7. Prikazan je tip entiteta RADNIK iji je primarni klju MBR, i koji ima
sloeni atribut IME, vievrednosni TELEFON i izvedeni atribut BROJRADNIKA.
Komponente
kompozitnog
atributa
LIME
SSLOVO
PREZIME
IME
MBR
Kompozitni atribut
TELEFON
Vievrednosni atribut
Primarni klju
BROJRADNIKA
RADNIK
izvedeni atribut
Slika 3-7. Grafika notacija za prikaz tipa entiteta i njegovih atributa
33
3.2 Poveznici, skup poveznika i tip poveznika

U realnom sistemu izmeu entiteta postoje odreeni odnosi (relacije). Meu
entitetima jednog skupa, kao i meu entitetima vie skupova, mogu postojati
razliite relacije, to se u ER modelu podataka modelira kao tip poveznika
odnosno tip veze. Tip veze R meu tipovima entiteta E1, E2,... En, definie skup
asocijacija ili skup veza meu entitetima ovih tipova. Obino tip veze oznaavamo
kao R(E1, E2,... En).
Skup poveznika R={e1,e2,,en|eiEi, i=1,,n} predstavlja relaciju (u
matematikom smislu) izmeu n (n2) skupova entiteta. Skupovi Ei ne moraju biti
razliiti, a svaka n-torka (e1,e2,,en) u R predstavlja jedan poveznik odnosno
jednu vezu. Svaki entitet u n-torci ima svoju ulogu koja se u ER dijagramu moe
navesti. Ako se uloge entiteta u n-torki eksplicitno navedu tada redosled navoenja
entiteta nije bitan. Izmeu dva ista skupa entiteta moe postojati vie razliitih
skupova poveznika. Ako poveznik povezuje entitete istog skupa, naziva se
rekurzivnim.
Tip poveznika je model skupa poveznika. Obino se za naziv tipa poveznika
koristi naziv skupa poveznika, tj. R(E1,E2,,En;B1,B2,,Bm). Za svaki tip entiteta
Ei | i=1,n se kae da participira u tipu poveznika R.
Pojava odnosno instance tipa poveznika se odnosi na konkretne veze izmeu
pojednih entiteta odgovarajuih skupova entiteta koji uestvuju u vezi.
Primer: Tip poveznika
Mogui tipovi poveznika izmeu tipova entiteta RADNIK i PROJEKAT:
RADI-NA(RADNIK,PROJEKAT) definie vezu radnika sa projektima
RUKOVODI(RADNIK,PROJEKAT) definie radnika rukovodioca
projekta
Rekurzivni tip poveznika za tip entiteta RADNIK:
JE-RUKOVODILAC(RADNIK,RADNIK) definie odnos radnika i
nadreenog/efa (u ovom sluaju vana je uloga!)
RADNIK
RADI-NA
PROJEKAT
Radnik radi na projektu

Slika 3-8. Grafika notacija za tip poveznika
RadiNa
u ER dijagramu jeProjekat
dato na slici 3-8. Ime UML
tipa notacija
poveznika je navedno velikim slovima, a prikazane su veze ka tipovima entiteta
Radnik radi na projektu
34
Angauje
UML notacija
Projekat
Radnik
Radnik
Predstavljanje
tipa poveznika
Projekat angauje radnike

koji uestvuju u tom tipu poveznika. Na slici je prikazan tip poveznika RADI-NA
koji definie vezu radnika sa projektom.
Primer: Skup poveznika
Posmatraemo entitete RADNIK i PROJEKAT. Neka u realnom sistemu
izmeu ova dva entiteta postoje odnosi
radnik radi na projektu
radnik rukovodi projektom
radnik je rukovodilac radniku
Neka su Mina i Pera elementi skupa RADNIK, a Web server element skupa
PROJEKAT
Poveznik (Mina,Web server) moe imati znaenje Radnik Mina radi na
projektu Web server.
Poveznik (Pera,Web server) moe imati znaenje Radnik Pera rukovodi
projektom Web sever.
Poveznik (Pera,Mina) moe imati znaenje Radnik Pera je rukovodilac
radnika Mina.
U ovim primerima nisu eksplicitno navedene uloge entiteta u poveznicima.
Stepen tipa poveznika je broj tipova entiteta koji participiraju u tipu
poveznika. Tip poveznika stepena 1 naziva se rekurzivni, tip poveznika stepena 2
se naziva binarni, tip poveznika stepena 3 se naziva ternarni, itd. U praksi se
najee koriste binarni tipovi poveznika.
Primer: Stepen tipa poveznika
Dva tipina primera rekurzivnog tipa poveznika:
Pomenuta veza radnika i njegovog nadreenog (rukovodioca), koji je

takoe radnik (podaci o radnicima, bez obzira da li je rukovodilac ili ne
se uvaju u istoj tabeli):
JE-RUKOVODILAC(RADNIK,RADNIK)
veza dve osobe koje su u braku:
U-BRAKU(OSOBA,OSOBA)
Binarni tipovi poveznika (radnici rade na projektima, projekti imaju
rukovodioce, radnici imaju rukovodioce):
RADI-NA(RADNIK,PROJEKAT)
35

RUKOVODI(RADNIK,PROJEKAT)
JE-RUKOVODILAC(RADNIK,RADNIK)
Ternarni tip poveznika (za potrebe projekta preko dobavljaa se nabavlja deo):
SNABDEVA(DOBAVLJA,DEO,PROJEKAT)
Na slici 3-9. prikazan je ternarni tip poveznika koji povezuje dobavljae,
projekat i deo. Tip poveznika SNABDEVA modelira vezu koja postoji u minisvetu kada se za potrebe projekta nabavljaju delovi od nekog konkretnog
dobavljaa. Ternarna veza se u optem sluaju ne moe uvek predstaviti sa tri
binarne veze.
Primer: Ternarni tip poveznika
DOBAVLJA
SNABDEVA
PROJEKAT
DEO
Slika 3-9. Ternarni tip poveznika SNABDEVA
Primer: Pojava tipa poveznika

Neke pojave tipa poveznika RADI-NA izmeu radnika i projekata su date na
slici 3-10.
RADNIK
RADNIK
RADI-NA
RADI-NA
PROJEKAT
PROJEKAT
r1
Ana
Mina
Pera
Laza
Nadja
r2
r3
r4
r5
Web
server
Web
sajt
Map
server
Slika 3-10. Neke pojave tipa poveznika RADI-NA
36

U prethodnom primeru se moe uoiti da svaka pojava ri se odnosi na jednu
konkretnu vezu izmeu jednog radnika, napr. Ane i jednog projekta, napr. Web
server. Svaki od radnika i svaki od projekata moe da uestvuje u vie veza, ali i ne
mora da uestvuje ni u jednoj vezi to je definisano ogranienjima opisanim u
narednoj sekciji.
Neke pojave tipa poveznika RUKOVODI (slika 3-11).
RADNIK
RADNIK
RUKOVODI
RUKOVODI
PROJEKAT
PROJEKAT
r1
Ana
Mina
r2
Pera
Laza
r3
Nadja
Web
server
Web
sajt
Map
server
Slika 3-11. Neke pojave tipa poveznika RUKOVODI
U navedenom primeru moe se uoiti da ne uestvuju svi radnici u ovoj vezi

(odnosno postoje radnici koji nisu rukovodioci projekata), ali svi projekti imaju
rukovodioce. Navedene tvrdnje su deo ogranienja koja treba definisati za ovaj tip
veze.
Neke pojave tipa poveznika JE_RUKOVODILAC (slika 3-12).
RADNIK
JE_RUKOVODILAC
RADNIK
JE_RUKOVODILAC
RADNIK
RADNIK
r1
Ana
Mina
Ana
r2
Pera
Laza
Mina
Pera
r3
Laza
Nadja
r4
Nadja
Slika 3-12. Neke pojave tipa poveznika JE_RUKOVODILAC
37

U ovom sluaju je oigledno da se sa obe strane veze nalaze radnici, ali i da ne
moraju svi radnici da budu rukovodioci, a praktino i nemaju svi radnici
rukovodioca (najmanje jedan koji je na vrhu hijerarhije).
Primer: Pojava rekurzivnog tipa poveznika
Neke pojave rekurzivnog tipa poveznika U-BRAKU (slika 3-13).
OSOBA
U-BRAKU
r1
suprug
Ana
OSOBA
U-BRAKU
supruga
r2
Mina
Pera
Laza
r1
Nadja
Slika 3-13. Neke pojave rekurzivnog tipa poveznika U-BRAKU
Na slici 3-13 prikazan je i deo ER dijagrama koji definie rekurzivni tip

poveznika sa navednim ulogama. Pri tome su koriene razliite linije (iako to nije
u skladu sa notacijom ER modela) kako bi se uoile pojave ovog rekurzivnog tipa
poveznika.
DOBAVLJA
SNABDEVA
d1
PROJEKAT
r1
d2
r2
r3
r4
DEO
r5
Web
server
Web
sajt
Map
server
r6
deo1
deo2
deo3
deo4
Slika 3-14. Neke pojave ternarnog tipa poveznika SNABDEVA
38

Primer: Pojava ternarnog tipa veze
Neke pojave ternarnog tipa poveznika SNABDEVA, iji je ER model dat u
nekom od prethodnih primera (slika 3-9), su prikazane na slici 3-14.
Svaki tip entiteta koji participira u tipu poveznika ima posebnu ulogu u tom
odnosu. Ime uloge oznaava ulogu koju igra entitet koji participira u povezniku u
svakoj instanci poveznika. Ime uloge pomae u razumevanju odnosa koji poveznik
modelira. Ime uloge je posebno vano kod rekurzivnih poveznika!
Primer: Uloga kod tipova poveznika
U tipu poveznika RADI-NA(RADNIK,PROJEKAT) tip entiteta

RADNIK je u ulozi zaposlen, a PROJEKAT u ulozi poslodavac
U tipu poveznika JE-RUKOVODILAC(RADNIK,RADNIK) tip entiteta
RADNIK igra dvojaku ulogu, kao nadreeni i podreeni radnik u
hijerarhiji rukovoenja
Uloga se u ER dijagramu navodi pored linije koja povezuje simbol tipa

poveznika i tip entiteta i odnosi se na ulogu tog tipa entiteta u tom tipu poveznika.
Slika 3-15. prikazuje uloge za rekurzivni tip veze JE_RUKOVODILAC.
RADI-NA
nadreen
PROJEKAT
RADNIK
RUKOVODI
podreen
JE-RUKOVODILAC
Slika 3-15. Prikaz uloge u ER modelu
Atributi tipa poveznika

Tip poveznika moe da ima svoje atribute, na nain kako ih imaju tipovi
entiteta. Na primer, za tip veze sa slike 3-10, moe da se definie broj radnih sati
angaovanja radnika na konkretnom projektu. Na slian nain moe da se difinie i
datum postavljanja rukovodioca za tip veze sa slike 3-12. U oba sluaja navedeni
39

atribut moe da bude atribut bilo kog od dva tipa entiteta koji uestvuju u tipu veze.
Izbor da li neki tip veze ima atribut, ili se taj atribut pridruuje nekom od tipova
entiteta koji uestvuju u vezi moe se izvriti na osnovu injenice da li se njegova
vrednost razlikuje za svaku vezu u skupu veza.
3.3 Ogranienja nad tipom poveznika

Tipovi poveznika imaju izvesna ogranienja koja limitiraju mogue
kombinacije entiteta koji mogu participirati u skupu poveznika. Ova ogranienja
omoguavaju modeliranje prirode odnosa koji postoje meu entitetima u realnom
svetu. U prethodnim primerima koji su se odnosili na pojave tipa poveznika mogli
ste da uoite neka od ovih ogranienja koja su se odnosila na brojnost uea
pojednih entiteta ili na mogunost da ne uestvuju u nekom skupu veza.
Primer: Ogranienja nad tipom poveznika
Neka od ogranienja koja vae za mini-svet koji se odnosi na preduzee:
Radnik moe raditi na vie projekata

Radnik moe rukovoditi samo jednim projektom
Svaki radnik mora raditi bar na jednom projektu
Svaki radnik, osim glavnog menadera preduzea, mora imati
rukovodioca
Dva glavna tipa ogranienja nad tipom poveznika su:
Odnos kardinaliteta, ili kardinalnost (brojnost)
Participacija (odnosno uee)
Ogranienje kardinalnosti
Za modeliranje realnog sveta vana je klasifikacija svih veza s obzirom na broj
entiteta odreene vrste koji su u odreenoj vezi sa entitetima druge vrste, odnosno s
obzirom na kardinalnost odgovarajue relacije meu povezanim tipovima entiteta.
Kardinalnost binarnog tipa poveznika R(E1,E2) specificira maksimalni broj
instanci poveznika u kojima entiteti E1 i E2 mogu participirati.
Mogui odnosi kardinaliteta tipa poveznika R(E1,E2) su:
jedan-prema-jedan (1 : 1)
vie-prema-jedan (N : 1)
jedan-prema-vie (1 : N)
vie-prema-vie (N : M)
(gde je N 0 i M0)
40

Veza 1 : 1. Kod ove vrste veza svaki element prvog skupa moe biti povezan sa
najvie jednim elementom drugog skupa. Istovremeno svaki element drugog skupa
moe biti povezan sa najvie jednim elementom prvog skupa.
Veza N : 1. Kod ove vrste veza svaki element prvog skupa moe biti povezan sa
najvie jednim elementom drugog skupa. Istovremeno svaki element drugog skupa
moe biti povezan sa vie elemenata prvog skupa.
Veza 1 : N. Kod ove vrste veza svaki element prvog skupa moe biti povezan sa
vie elemenata drugog skupa. Istovremeno svaki element drugog skupa moe biti
povezan samo sa jednim elementom prvog skupa.
Veza N : M. Svaki element prvog skupa entiteta moe biti povezan sa vie
elemenata drugog skupa, i obrnuto, svaki element drugog skupa entiteta moe biti
povezan sa vie elemenata prvog skupa.
Primer: Ogranienje kardinalnosti
Tip poveznika RADI-U(RADNIK,SEKTOR) ima odnos kardinaliteta N:1 to
znai da jedan radnik moe biti u vezi (u ulozi zaposlenog) samo sa jednim
sektorom, ali svaki sektor (u ulozi poslodavca) moe biti u vezi sa proizvoljnim
brojem radnika (u ulozi zaposlenih).
Za oznaavanje kardinaliteta A:B tipa poveznika R(E1,E2), kod ER dijagrama
postoje dva naina (slika 3-16):
A se navodi uz tip poveznika E1, a B uz tip poveznika E2, ili
A se navodi uz tip poveznika E2, a B uz tip poveznika E1 (u ovom

materijalu koristie se ovaj nain)
A
E1
R(E1,E2)
E1
E2
A
R(E1,E2)
E2
Slika 3-16. Oznaavanje kardinaliteta
Primer: Oznaavanje kardinaliteta

Na slici 3-17. prikazan je nain oznaavanja kardinaliteta za tip poveznika
RASPOREEN(RADNIK,RADNO_MESTO) za realni sistem u kojem:
Radnik moe biti rasporeen samo na jedno radno mesto, a
Na jedno radno mesto moe biti rasporeeno vie radnika
41
RASPOREEN
RADNIK
Uvod u baze
podataka
RASPOREEN
RADNIK
RADNO-MESTO
RADNO-MESTO
Slika 3-17. Veza 1:N izmeu tipova entiteta RADNO-MESTO i RADNIK

N
RADI-U
nadreen
SEKTOR
RADI-NA
PROJEKAT
RADNIK
1
RUKOVODI
podreen
N
JE-RUKOVODILAC
Slika 3-18. ER dijagram sa oznaenim kardinalitetima tipa poveznika
Na slici 3-18. prikazan je jedan primer ER dijagrama sa oznaenim

kardinalitetima tipa poveznika. Sektori imaju vie radnika, radnici mogu da rade na
vie projekata, a jedan projekat realizuje vie radnika, a jedan od njih je
rukovodilac projekta. Prikazana je i rekurzivna veza koja definie rukovodioce.
Ogranienje participacije
Ogranienje participacije specificira minimalni broj instanci poveznika u
kojima entitet moe participirati. Ponekad se naziva minimalno ogranienje
kardinaliteta. Ogranienje participacije specificira da li postojanje (egzistencija)
entiteta zavisi od toga da li je u vezi sa drugim entitetom preko tipa poveznika.
Postoje dva tipa ogranienja participacije entiteta u vezi. To su:
totalna (egzistencijalna) participacija i
parcijalna participacija
Totalna participacija tipa entiteta E1 u tipu veze R(E1, E2) znai da svaki
entitet iz skupa entiteta E1 mora biti povezan sa nekim entitetom iz skupa entiteta
E2 preko veze iz skupa veza modeliranih tipom veze R. To dalje znai da
egzistencija nekog entiteta u skupu E1 zavisi od toga da li je povezan sa nekim
entitetom iz skupa E2 preko tipa veze R. Otuda se ovaj tip participacije takoe
naziva egzistencijalna participacija.
42

Parcijalna participacija entiteta E1 u tipu veze R(E1, E2) znai da svaki
entitet iz skupa E1 ne mora biti povezan sa nekim entitetom iz skupa entiteta E2
preko tipa veze R. To takoe znai da u skupu entiteta E1 mogu postojati entiteti
koji nisu povezani ni sa jednim entitetom iz skupa entiteta E2 preko tipa veze R.
U ER dijagramu, za oznaavanje participacije tipa poveznika R(E1,E2)
koristiemo dva razliita tipa linija koje spajaju tip entiteta sa tipom poveznika:
Jednostruku liniju za parcijalnu participaciju i
Dvostruku liniju za totalnu participaciju
Primer: Oznaavanje participacije u ER dijagramu

Na slici 3-19. prikazana su dva prethodno navedena naina prikaza
participacije za realni sistem u kojem:
Radnik mora biti rasporeen na tano jedno radno mesto, a
Na jedno radno mesto moe biti rasporeeno vie radnika, ali mogu
postojati radna mesta na koja niko nije rasporeen
totalna
RADNIK
parcijalna
RASPOREEN
RADNO-MESTO
Slika 3-19. Oznaavanje participacije za tip veze RASPOREEN
Primer: Oznaavanje participacije u ER dijagramu

Ogranienje participacije u tipu poveznika RADI-U(RADNIK,SEKTOR)
prikazano je na slici 3-20:
tip entiteta RADNIK ima totalnu participaciju ako u preduzeu vlada

pravilo da svaki radnik mora biti zaposlen u nekom sektoru
Tip entiteta SEKTOR ima parcijalnu participaciju ako u preduzeu

vlada pravilo da mogu postojati sektori bez zaposlenih
RADNIK
Totalna participacija
RADI-U
SEKTOR
Parcijalna participacija
Slika 3-20. Oznaavanje participacije za tip veze RADI-U
43

Definisanje ogranienja je jako vano u procesu projektovanja baze podataka
zato to utie kasnije na opis baze podataka i tabele koje treba kreirati. Postavlja se
pitanje kako se mogu u procesu projektovanja na pravi nain definisati navedena
ogranienja kardinalnosti i praticipacije a da ne doe do greke? Pristup koji autori
ovog materijala koriste je jednostavan: ako posmatrate vezu izmeu dva tipa
entiteta, gledate najpre odnos izmeu jednog entiteta iz prvog tipa entiteta i svih
ostalih entiteta iz druge. Na taj nain odredite ogranienje sa strane drugog tipa
entiteta gde posmatrate sve entitete. Nakon toga isti postupak ponovite za drugi
smer, odnosno odnos jednog entiteta iz drugog tipa entiteta sa svim entitetima iz
prve.
Za pomenutu vezu RADI-U, izmeu relacija RADNIK i SEKTOR (odnosi se na
radnike koji rade u nekom sektoru), ogranienje kardinaliteta se moe odrediti na
sledei nain:
Oznaimo odnos kardinaliteta sa X i Y dok ne odredimo odgovarajue
vrednosti:
RADNIK : SEKTOR
X:Y
Najpre posmatramo jednog radnika i odreujemo sa koliko sektora je on u vezi.
Poto jedan radnik moe da radi samo u jednom sektoru, kardinalnost sa strane
sektora je 1:
RADNIK : SEKTOR
X:1
Nakon toga posmatramo jedan sektor i odreujemo sa koliko radnika je u
pomenutoj vezi. Jedan sektor moe da ima vie radnika, pa je kardinalnost sa strane
radnika u ovoj vezi N:
RADNIK : SEKTOR
N:1
Strukturalna ogranienja tipa poveznika
Drugi nain zadavanja ogranienja tipa poveznika kod ER modela su tzv.
strukturalna ogranienja. Ako se posmatra binarna relacija R izmeu skupova
pojava dva tipa entiteta E1 i E2, ona se moe predstaviti putem dva preslikavanja:
R1: E1P(E2)
R2: E2P(E1)
gde je P(E) partitivni skup skupa E.
Za svako od ovih preslikavanja se definie minimalni i maksimalni kardinalitet
preslikavanja. Preslikavanjima R1 i R2 se moe dati sledea semantika
interpretacija: R1 je uloga entiteta iz skupa E1, a R2 uloga entiteta iz skupa E2 u
njhovoj vezi opisanoj relacijom R(E1,E2).
44

Praktino, radi se o jednostavnom nainu da se predstave oba navedena
ogranienja, kardinalitet i participacija - pored svakog od tipova entiteta koji
uestvuju u vezi navede se par vrednosti (min,max), to ima sledee znaenje:
min = 0,
parcijalna participacija
min > 0,
totalna participacija
max = maksimalni broj entiteta odreenog tipa koji uestvuju u vezi
U ovom sluaju, tip poveznika R(E1, E2) se predstavlja na sledei nain:

E1 : E2 = R(E1(min1, max1) : E2(min2, max2))
Svaki element skupa E1 je u vezi sa min2 do max2 elemenata skupa E2 i
obrnuto, svaki element skupa E2 je u vezi sa min1 do max1 elemenata skupa E1.
Minimalna vrednost definie participaciju entiteta u tipu poveznika R(E1,E2):
ako je min=1 preslikavanje je totalno, a ako je min=0 preslikavanje je parcijalno.
Maksimalne vrednosti definiu odnos kardinaliteta tipa poveznika R(E1,E2),
tako da vrednosti max1:max2 definiu veze: 1:1, 1:N ili N:M.
Za oznaavanje (min,max) ogranienja
dijagramu postoje dva naina (slika 3-21):
tipa poveznika R(E1,E2) u ER
Brojnost preslikavanja se upisuje uz tip entiteta u koji se on preslikava.

Par (min1,max1) se navodi na potegu uz tip poveznika E2, a par
(min2,max2) na potegu uz tip poveznika E1, ili
Brojnost preslikavanja se upisuje uz sam tip entiteta. Par (min1,max1) se

navodi na potegu uz tip poveznika E1, a par (min2,max2) na potegu uz
tip poveznika E2.
E1
E1
(min2,max2)
(min1,max1)
R(E1,E2)
(min1,max1)
E2
(min2,max2)
R(E1,E2)
E2
Slika 3-21. Oznaavanje strukturalnih ogranienja
Primer: Predstavljanje strukturalnih ogranienja

Predstavljanje (min,max) ogranienja tipa poveznika u ER dijagramima. Na
primeru sa slike 3-22. su prikazana ova dva naina za isti realni sistem u
kojem:
Radnik moe biti rasporeen samo na jedno radno mesto,
45
Na jedno radno mesto moe biti rasporeeno vie radnika, a moe radno
mesto biti slobodno.
(0,N)
RASPOREEN
RADNIK
(1,1)
RADNIK
RASPOREEN
(1,1)
RADNO-MESTO
(0,N)
RADNO-MESTO
Slika 3-22. Primer oznaavanja strukturalnih ogranienja
3.4 Slabi tip entiteta

Tip entiteta moe biti regularni (tip entiteta koji smo do sada definisali i
koristili) ili slabi tip entiteta. Slabi tip entiteta nema sopstvene kljune atribute na
nain kako su definisani u odeljku 3.1.2. Entiteti slabog tipa entiteta se identifikuju
preko veze sa nekim drugim tipom entiteta (regularnim ili slabim) u kombinaciji sa
nekim svojim atributom. Taj drugi tip entiteta je identifikujui tip entiteta
(vlasniki, roditeljski ili dominantni).
Poveznik koji povezuje slabi tip entiteta sa vlasnikom se naziva identifikujui
poveznik. Slabi tip entiteta uvek totalno participira u identifikujuem tipu veze.
Slabi tip entiteta ima parcijalni klju (diskriminator) koji predstavlja podskup
skupa atributa slabog tipa entiteta koji na jedinstven nain identifikuje slabe
entitete koji su u vezi sa istim vlasnikim tipom entiteta. U najgorem sluaju, kada
ne moe da se izdvoji takav podskup atributa, parcijalni klju ini skup svih
atributa slabog tipa entiteta.
NAZIV
Klju
VEZA
ParcKlju
NAZIV
Slika 3-23. Slabi tip entiteta u ER dijagramu
Slabi tip entiteta se u ER dijagramu prikazuje kao regularni, s tim da se koristi

dvostruka linija (slika 3-23). Postoji identifikujui tip veze prema vlasnikom tipu
46

entiteta prikazana takoe dvostrukom linijom. Parcijalni klju slabog tipa entiteta
se podvlai isprekidanom linijom.
3.5 Pregled grafike notacije ER dijagrama

Pretodno je navedeno da se ema konceptualnog ER i EER modela podataka
predstavlja se dijagramom. U prethodnim odeljcima je dat pregled osnovnih
koncepata, kao i prikaz i objanjenje grafike notacije, a ovaj odeljak daje pregled
usvojene grafike notacije ER dijagrama prema notaciji iz knjige [Elmasri &
Navathe, 2010].
Pravila koja su koriena za obeleavanje entiteta, atributa, veza i kljueva su:
Entitete obeleavamo velikim slovima. Na primer: u sistemu za

registraciju vozila imena entiteta su: VOZILO, VLASNIK,
SLUBENIK, REGISTRACIJA i ORGANIZACIJA.
Atributi i veze se mogu obeleavati na dva naina: (1) nizom rei koje se
piu velikim slovima sa znakom za podvlaenje ili crticom izmeu rei;
Na primer: IME, BOJA_KOLA, REG_BROJ ili BOJA-KOLA, REGBROJ; (2) nizom rei koje se piu malim slovima, osim prvog slova
svake rei, bez delimitera izmeu rei; Na primer: Ime, BojaKola,
RegBroj.
Domen atributa A obeleavaemo sa dom(A).
Tip entiteta E sa atributima A1,A2,...,An oznaavaemo kao

E(A1,A2,...,An)
Atributi koji ine klju tipa entiteta bie podvueni.
Koncepti osnovnog ER modela se po usvojenoj notaciji grafiki

predstavljaju na sledei nain:
Tip entiteta odnosno se crta kao pravougaonik sa upisanim imenom. Ime se

upisuje velikim slovima:
NAZIV
Slabi tip entiteta se crta kao dvostruki pravougaonik sa upisanim imenom

kao kod regularnog tipa entiteta:
NAZIV
Tip veze se crta kao romb sa upisanim imenom:

VEZA
47
Identifikacioni tip veze se crta kao dvostruki romb sa upisanim imenom:

VEZA
Tip veze R izmeu tipova entiteta E1 i E2 crta se kao neusmeren poteg od

romba R do grafikog simbola entiteta E1 i E2:
U optem sluaju, za n-arni tip veze, crta se neusmereni poteg od romba do
svakog tipa entiteta koji uestvuje u tom tipu veze.
E1
E2
Prosti atributi se prikazuju kao elipse sa upisanim nazivom i povezuju se

linijom sa geometrijskom slikom tipa entiteta ili tipa poveznika na koji se
odnose:
Atribut
ENTITET
Vievrednosni atributi se predstavljaju dvostrukom elipsom:
Atribut
ENTITET
Sloeni atributi se predstavljaju preko svojih komponenti:
A2
A1
A3
Atribut
ENTITET
48
Izvedeni atributi se prikazuju isprekidanom linijom:
Atribut
ENTITET
Kljuni atributi se prikazuju podvlaenjem imena:

Atribut
ENTITET
Parcijalni kljuevi se podvlae isprekidanom linijom:

Atribut
ENTITET
Ogranienja tipa veze, kardinalnost i participacija, prikazuju se pored

potega od oznake tipa entiteta (pravougaonik) do oznake tipa veze (romb):
Kardinalnost je oznaena brojevima, a participacija linijama. Na slici je
prikazana veza tipa 1:N izmeu tipova entiteta E1 i E2. Jednostruka linija
odgovara parcijalnom ueu tipa entiteta E1, a dvostruka totalnom ueu
tipa entiteta E2.
E1
E2
Strukturno ogranienje se navodi pored tipa entiteta koji uestvuje u

nekoj vezi:
E1
(min, max)
3.6 Primeri konceptualnog modeliranja

U ovom odeljku dato je nekoliko primera konceptualnog modeliranja i prikazani
su ER dijagrami koji su dobijeni na osnovu zadatih zahteva, kao i primeri za vebu.
Zadaci za vebu: Osnovni elementi konceptualnog projektovanja
Nacrtati ER dijagrame za sledee situacije:
49

Entititeti
(a) Brod: brod ima ime, registracioni kod, bruto nosivost, i godina igradnje;
brodovi se dele na teretne i putnike.
(b) Restoran: restorani imaju naziv, adresu, broj mesta, telefon, i vrstu hrane
(rotilj, riba, pice).
(c) Krava: krava muzara ima ime, datum roenja, rasu i numerisnu plastinu
oznaku na uvetu.
Veze
(d) Seljak ima vie krava, ali krava pripada samo jednom seljaku.
(e) Seljak moe da ima svoje krave ili da ih deli (zajednike krave) sa drugim
seljacima.
(f) Fakultet ima vie studenata, ali jedan student moe da studira samo na jednom
fakultetu.
(g) Avion moe da ima vie putnika, ali jedan putnik moe da bude na samo
jednom letu u odreeno vreme.
(h) Drava ima vie regiona, svaki region ima vie gradova.
(i) evapdinica prodaje vie vrsta pljeskavica. Isti dodaci (salate) se mogu
koristiti uz razliite tipove pljeskavica.
(j) Pacijent moe da ima vie doktora, a jedan doktor ima vie pacijenata.
Primer: Vlasnici i njihova vozila
Potrebno je projektovati bazu podataka koja sadri podatke o vozilima i
njihovim vlasnicima. Za vozila se uva registarski broj, tip, broj asije i broj
motora. Za vlasnike broj dozvole, ime (lino ime i prezime)i adresa. Vlasnici mogu
da imaju vie vozila.
Na slici 3-24. prikazan je ER dijagram, dobijen na osnovu navedenih zahteva,
koji sadri dva tipa entiteta:
50
VOZILO, sa atributima
BrojMotora, Brojasije, i
VLASNIK sa atributima Ime (sloeni atribut, sastoji se iz dve

komponente: LinoIme, Prezime), Adresa, BrojDozvole (kljuni atribut).
Tip,
RegistarskiBroj
(kljuni
atribut),
RegistarskiBroj
BrojDozvole
Tip
VOZILO
1
POSEDUJE
VLASNIK
BrojMotora
Adresa
Ime
Brojasije
LinoIme
Prezime
Slika 3-24. Primer ER dijagrama: vlasnici i njihova vozila
Registarski broj je izabran kao klju za vozila poto na jedinstven nain

identifikuje svako vozilo. Za vlasnike klju je oigledno broj dozvole. Izmeu ova
dva tipa entiteta postoji veza POSEDUJE, koja definie odnos vlasnika i vozila.
Veza je tipa 1:N, zato to vlasnik moe da poseduje vie vozila, a jedno vozilo ima
samo jednog vlasnika. Participacija je na strani vlasnika i vozila totalna, uz
pretpostavku da se u bazi podataka uvaju podaci samo o vlasnicima koji poseduju
bar neko vozilo, kao i podaci o vozilima koji imaju vlasnika.
Zadaci za vebu: Projektovanje konceptualne eme baze podataka
(a) Projektovati konceptualnu emu baze podataka koja treba da uva podatke o
slikarima i muzejima u kojima se nalaze njihove slike. Za svaku sliku, treba
pamtiti informacije o veliini (dimenzijama), godini kada je ona nastala, naslov
i stil. Za slikare pamtiti nacionalnost, datum roenja i datum smrti (ako je
poznat). Za svaki muzej, pamtiti lokaciju, kao i specijalnost, ako postoji.
(b) Projektovati konceptualnu emu baze podataka o takmienju u odbojci. U bazi
podataka treba uvati informacije o ekipama koje uestvuju (naziv, zemlja,
trener, najbolji plasman na svetskim i evropskim prvenstvima) i igraima za
svaku ekipu. Za igrae pamti se ime i prezime, mesto u timu i broj. Brojevi
igraa su jedinstveni u okviru ekipe. Treba pamtiti i podatke o utakmicama
(jedinstveni identifikator, datum, vreme, sudije, dve ekipe koje igraju i konacni
rezultat u setovima). Utakmice se igraju na tri dobijena seta, a za svaki set na
utakmici treba pamtiti njegov redni broj i rezultat. Za utakmice pamti se i
statistika za igrace i ekipu. Za svakog igraa, za svaku utakmicu, pamti se broj
osvojenih poena i broj promena. Za svaku ekipu na utakmici vodi se statistika
o broju as servisa, broju direktnih poena i broju poena na greke protivnika.
51

Primer: Baza podataka PREDUZEE
Na osnovu navedenih zahteva projektovati ER dijagram baze podataka
PREDUZEE.
Zahtevi:
Preduzee ima vie sektora. Svaki sektor ima ime, broj i rukovodioca.
Sektor ima bar etiri radnika. Vodi se evidencija o datumu kada je
rukovodilac postavljen na tu funkciju. Sektor moe imati vie lokacija.
U sektoru se radi na vie projekata. Svaki projekat ima ime, broj i

jedinstvenu lokaciju.
Za svakog radnika se pamti ime, matini broj, adresa, plata, pol i datum
roenja. Svaki radnik radi u jednom sektoru, a moe biti angaovan na
vie projekata, koje ne vodi isti sektor. Pri tome se vodi evidencija o
broju radnih asova koje radnik provede na nekom od projekata. Takoe
se vodi evidencija o hijerarhiji odgovornosti, odnosno evidentira se za
svakog radnika ko mu je neoposredni rukovodilac.
Vodi se i evidencija o lanovima porodice. Za svakog lana evindetira se

ime, pol, datum roenja i srodstvo.
ER dijagram za bazu podataka PREDUZEE dat 3-25. Zahtevi su navedni tako

da se lako prepoznaju tipovi enetiteta i odgovarajue veze.
Sbroj
SSlovo
Prezime
LIme
RADI-U
N
Adresa
Ime
Sektor
Radnik
Pol
BrojRadnika
Plata
MatBr
1
RUKOVODI
DatRodj
nadredjen
podredjen
Izvrsilac
M
RukovodiSektorom
Sati
JE-NOSILAC
RADI-NA
1
Sektor-nosilac
NosiProjekat N
N
NADZOR
SEKTOR
DatumPost
Rukovodilac
RADNIK
Lokacija
Naziv
Projekat
PROJEKAT
Radnik
ZAVISI_OD
Lokacija
Naziv
Broj
Ime
Zavisi
Srodstvo
CLAN-PORODICE
Pol
DatRodj
Slika 3-25. ER dijagram baze podataka PREDUZEE
52

U procesu projektovanja baze podataka najpre treba prepoznati tipove entiteta, a
to su redom: sektori, projekti, radnici i lanovi porodice, sa atributima koji su
navedeni u svakom od pasusa. Ime radnika moe da bude sloeni atribut, dok je
lokacija sektora oigledno vievrednosni atribut. Broj radnika po sektoru se moe
izraunati pa predstavlja izvedeni atribut.
lan porodice je slabi tip entiteta poto se ne moe identifikovati preko
navedenih atributa (ime, koji je parcijalni klju), ali moe preko vrednosti atributa
roditelja odnosno radnika.
Nakon toga treba definisati tipove veza koji se mogu prepoznati itanjem
zahteva ali i na osnovu atributa koje ste definisali u prvom prolazu za prepoznate
tipove entiteta. Ako postoji vrednost koju treba da uvati u nekom tipu entiteta, a
predstavlja vrednost atributa drugog tipa entitata, sigurno se radi o vezi ova dva
tipa entiteta. Na primer, u zahtevima stoji da se za sektore uva i rukovodilac
poto su rukovodioci radnici, to predstavlja vezu radnika i sektora. Kod radnika se
takoe pamte podaci o rukovodiocu (rekurzivni tip veze radnik-radnik), a takoe i
sektor u kome radi (veza sa sektorom). Na slian nain u zahtevima je definisana
veza sektora i projekata, kao i radnika i projekata.
Kod veza radnika i sektora, gde se definie rukovodilac sektora, treba uvati
informaciju o datumu postavljanja rukovodioca. Generalno, njegova vrednost se
razlikuje za svaku pojedinanu vezu u tom skupu veza i moe se posmatrati kao
atribut tipa veze. Ako to nije sluaj, verovatno takav atribut moete da pridruite
nekom od tipova entiteta koji uestvuju u vezi. U ovim zahtevima atribut veze je i
broj radnih sati koje radnik provede na nekom od projekata zato to se ta vrednost
razlikuje za svakog radnika i odnosi se na konkretan projekat na kome on radi.
Na kraju, treba odrediti i ogranienja za svaki tip veze. Veza sektora i
rukovodioca je oigledno 1:N (sektor ima jednog rukovodioca, a jedan radnik je
rukovodilac jednom sektoru), gde ne moraju svi radnici da budu rukovodioci
sektora (parcijalno uee radnika), a svaki sektor mora da ima rukovodioca
(totalno uee sektora). Odnos sektora i radnika je 1:N, gde i radnici i sektori
participiraju totalno. Odnos radnika i projekata na osnovu zahteva definie
kardinalitet M:N, zato to projekte realizuje vie radnika, a radnici mogu da rade na
veem broju projekata. Participacija je totalna zato to se podrazumeva da projekti
moraju da imaju radnike a da radnici moraju da imaju neko angaovanje na nekom
od projekata. Odnos sektora i projekata definie kardinalitet 1:N, ali sa parcijalnom
participacijom.
Primer: Baza podataka VIDEO_KLUB
Projektovati ER dijagram baze podataka VIDEO_KLUB na osnovu navedenih
zahteva.
53

Zahtevi:
Potrebno je pratiti sledee informacije o filmovima: jedinstveni broj,

naslov filma, reiser, tip (akcioni, komedija, drama,...), rejting filma
(kritika u novinama oznaena brojem zvezdica), godina, nominacije za
nagrade Akademije (tzv. Oskar, Academy Award), dobijene nagrade
Akademije.
Za svaki film treba pamtiti imena glumaca i tip uloge (glavna,

sporedna,...). O glumcima se pamte imena (ime i prezime), podaci o
datumu roenja i mestu roenja, datumu smrti (ako postoji).
Za svakog glumca postoji jedinstveni identifikator. Pamtiti podatke o

reiserima filmova: za svakog reisera postoji jedinstveni broj, pamte se
imena, datum roenja i datum smrti (ako postoji).
Prezime
Ime
Kod
Adresa
Datum
Broj_iznajmljivanja
Ime_i_prezime
Datum_Nabavljanja
Broj
KASETA
IZNAJMIO
LAN
Najamnina
Naslov
Datum
SADRI
Bonus
Tip
Uloga
Broj
Datum_roenja
Datum_smrti
1
N
FILM
AA_nominacije
Broj
IGRA
GLUMAC
N
Mesto_roenja
Ime_i_prezime
AA_nagrade
REIJA
Kritika
Prezime
Ime
Datum_Smrti
1
Godina
REISER
Broj
Datum_Roenja
Ime
Ime_i_prezime
Prezime
Slika 3-26. EER model baze podataka VIDEO_KLUB
54
Treba pamtiti i informacije o lanovima kluba: broj lanske karte, ime i

prezime, adresa, jedinstveni broj, datum ulanjenja, ukupan iznos
najamnine (od svih iznajmljenih kaseta) i vrednost ostvarenog bonusa
(odreuje se na osnovu pet iznajmljivanja).
Pamtiti podatke o kasetama: jedinstveni kod kasete, datum dobijanja,

film koji se na njoj nalazi i broj iznajmljivanja kasete. Vie kaseta moe
biti sa istim filmom. Za svakog lana kluba treba pamtiti kasete koje je
uzeo i datum izdavanja.
ER dijagram baze podataka VIDEO_KLUB je dat na slici 3-26.

Zadaci za vebu: Konceptualno projektovanje dodatni primeri
(a) Zadat je ER dijagram na slici 3-27.
1. Prouite ER dijagram i na osnovu datog modela podataka rekonstruiite
zahteve baze podataka.
2. Identifikujte i oznaite sve nedostatke datog modela.
Prezime
Ime
ID_Autora
Ime_i_prezime
AUTOR
Broj_narudbine_1
1
NAPISAO_1
Broj_narudbine_2
M
Jezik
Kljuna_re
NAPISAO_2
Naslov
Naslov
N
BRN
Jezik
LANAK
text
KNJIGA
N
Strane
ISBN
N
Broj
Izdava
PRIPADA_2
IZDAT_U
Volumen
1
Ime
M
SUBJEKT
1
PRIPADA_1
ASOPIS
Izdava
ID_Sertifikata
BRN
Slika 3-27. ER dijagram baze podataka o autorima i njihovim delima
55

(b) Kompletirati ER dijagram sa slike 3-28. dodavanjem ogranienja za veze
(kardinalnost).
Prezime
Broj_narudbenice
Ime
ID_Autora
Ime_i_prezime
NAPISAO
AUTOR
Naslov
Ime
ID_Specifikacije
Jezik
PUBLIKACIJA
PRIPADA
SUBJEKT
BRN
Kljuna_re
JE_KNJIGA
JE_LANAK
Vol
LANAK
text
Klju
pp
Br
KNJIGA
IZDAT_U
ISBN
Godina
ISSN
Brojevi
ASOPIS
Izdava
IZDAVA
Volumen
Slika 3-28. ER dijagram baze podataka o publikacijama
3.6.1 Preporuke kod modeliranja

Projektovanje ER i EER modela baze podataka je sloen zadatak koji zahteva
poznavanje koncepata ovih modela i dosta iskustva u radu. Osnovne preporuke
kojih se treba pridravati i koje vam mogu pomoi kod modeliranja baze podataka
su:
56
Identifikujte tipove entiteta detaljnim itanjem i analizom zahteva.

Tipove entiteta moete obino prepoznati traenjem imenica u
reenicama. Kao pomo moete da koristite spisak objekata realnog
sveta koji vam je dat u ovom poglavlju.
U prvom prolazu pretpostavite da su svi entiteti koje prepoznate

regularni (jaki) tipovi entiteta; proveru da li je neki tip entiteta slabi tip
vrite kasnije, u narednim prolazima.
Analizirajte atribute kod svih prepoznatnih entiteta. Ako neki od

potencijalnih tipova entiteta nemaju atribute ili ih ima malo, razmotrite
njihovu egzistenciju u obliku tipa entiteta. Moda se ti atributi mogu
pridruiti nekom drugom tipu entiteta!
Pronaite identifikatore za svaki jaki tip entiteta (kandidati za kljueve).
Odredite domene atributa. Proverite da li se neki atributi mogu

dekomponovati na prostije, naravno ako za to ima potrebe. Proverite da
li neki atributi imaju vie razliitih vrednosti za konkretan entitet iz
skupa. Ako ima vie takvih atributa koji se odnose na isti objekat
realnog sveta odnosno tip entiteta, umesto vievrednosnih atributa
razmotrite uvoenje novog tipa entiteta.
Atributi mogu pomoi i kod prepoznavanja veza. U sluaju da imate

atribut koji se referencira na drugi tip entiteta koji postoji u vaem
modelu, sigurno postoji veza izmeu njih.
U prvom prolazu definisanja veza pretpostavite da su sve veze

parcijalne, a proveru da li su totalne vrite kasnije.
Ne zaboravite da na kraju proverite ogranienja za sve prepoznate tipove

veza.
Proverite da li model sadri redundantne komponente.
Vodite rauna o nivou detaljnosti i konzistentnosti; na primer, u

poetnim fazama moete izostaviti atribute iz modela i sl.
Moete da razvijate dijagram iz vie delova (celina koje prepoznate) i da

ih kasnije spajate prepoznavanjem veza izmeu delova.
3.7 EER Model

Enhanced Entity Relationship (EER) je proireni ER model konceptima
objektno-orijentisane (OO) paradigme. EER omoguava modeliranje kompleksnih
veza izmeu objekata u bazi podataka (multimedija, geo- i sl). Koristi dodatne
koncepte koji mogu da modeliraju takve veze, kao to su koncepti potklase i
natklase, specijalizacija i generalizacija i sl. EER modelu pripadaju i koncepti: ISA hijerarhija, kategorizacija, agregacija pa ak i koncept slabog tipa entiteta, koji
se jo esto zove i identifikaciono zavisni tip entiteta.
3.7.1 Koncepti EER modela podataka

Proireni ER model koristi koncept klase koji odgovara pojmu klase iz OO
paradigme i posmatra se kao skup ili kolekcija entiteta. Praktino se tipovi entiteta
mogu tretirati kao klase i obrnuto. Za klase se mogu definisati natklase i/ili
potklase. Kod potklasa se podrazumeva nasleivanje atributa i nasleivanje veza iz
57

natklase. Veza izmeu natklase i njenih potklasa se naziva veza natklasa/potklasa
ili jednostavno veza klasa/potklasa.
Kod definisanja potklasa moe se krenuti od postojeih klasa, kod kojih se trae
mogue specijalizacije koje, pored zajednikih osobina sadranih u klasi, imaju
svoje specifine osobine. Postupak definisanja skupa takvih potklasa je poznat kao
specijalizacija. Obrnuti postupak, kada se od vie postojeih klasa uoavanjem
zajednikih osobina definie generalnija klasa (natklasa) je generalizacija.
Potklase mogu biti predikatom definisane ili korisniki definisane. Predikatom,
odnosno uslovom, definisane potklase imaju to svojstvo da sve instance potklasa
zadovoljavaju uslov zadat predikatom, odnosno uslovom. Korisniki definisane
potklase su one kod kojih se takav uslov ne moe definisati.
Za isti tip entiteta se moe definisati vie specijalizacija. Generalizacija i
specijalizacija obezbeuju formiranje hijerarhije klasa.
Za specijalizaciju i generalizaciju definiu se dve vrste ogranienja:
Participacija potklasa u vezi:

o disjunktna (eng. disjoint) svaki entitet iz natklase pripada
samo jednoj potklasi; i
o preklapajua (eng. overlap) entitet iz natklase moe da
pripada veem broju potklasa.
Kompletnost:
o potpuna (eng. total) svaki entitet iz natklase mora da pripada
nekoj potklasi;
o parcijalna (eng. partial) svi entiteti iz natklase ne moraju da
pripadaju nekoj od potklasa.
Sva navedena ogranienja su nezavisna i mogu se kombinovati, tako da se
mogu prepoznati etiri tipa veze generalizacija/specijalizacija:
disjunktna, potpuna
disjunktna, parcijalna
preklapajua, potpuna
preklapajua, parcijalna
Navedena ogranienja definiu pravila kod dodavanja i brisanja entiteta. Kod
brisanja entiteta iz superklase, briu se i odgovarajui entiteti iz potklasa (oni koji
zadovoljavaju zadati predikat, ako postoji). Kod dodavanja entiteta superklasi,
moe se dodati i entitet u potklasama, u zavisnosti od toga da li je kompletnost
parcijalna ili totalna. Dodavanje entiteta superklase potklasi (za disjoint), odnosno
potklasama (za overlap), za totalnu specijalizaciju je obavezno.
Deljive potklase su klase koje imaju vie od jedne natklase. Deljive potklase
obezbeuju viestruko nasleivanje kod EER modela.
58

Potreba za potklasama sa vie od jedne superklase je dovela do uvoenja
koncepta kategorija. Ako su natklase takve da se razlikuju, odnosno da su razliitog
tipa (obino nemaju iste kljueve), onda je takva potklasa kategorija.
Kod kategorija postoji selektivno nasleivanje. Za razliku od deljivih klasa,
koje nasleuju dve ili vie klasa istog tipa (obino sa istim kljuevima), i kod kojih
je nasleivanje unija natklasa, kod kategorija se moe rei da se radi o preseku
natklasa.
Za kategorije vae ista ogranienja kao kod generalizacije/specijalizacije, tako
da postoji totalna i parcijalna kategorizacija.
3.7.2 Notacija i primeri korienja koncepata EER modela

Za ove koncepte postoji odgovarajua grafika notacija koja se koristi kao
proirenje ER notacije.
EER dijagram koristi grafiku notaciju za ER dijagram i dodatke koje se odnose
na proirene koncepte, koji se predstavljaju na sledei nain:
Klasa se predstavlja na isti nain kao i tip entiteta, pravouganikom sa

upisanim imenom klase.
Ogranienja:
Oznake za participaciju potklasa:
Oznake za kompletnost:
-
totalna:
parcijalna:
Oznaka za kategorije:
Kao to je navedeno, klasa se odnosi se na pojam Tip entiteta iz ER modela

podataka. Specijalizacija podrazumeva top-down pristup, odnosno podelu klase na
potklase.
Primer: Specijalizacija
59

Specijalizacije klase RADNIK
POSLOVODJA, INENJER, itd.
mogu
da
budu:
SEKRETARICA,
Posledica specijalizacije je nasleivanje potklasa nasleuje atribute i veze iz

natklase (napr. kod radnika: Ime, Datum rodjenja,...). Potklase s druge strane mogu
da imaju jedinstvene atribute.
Primer: Atributi specijalizacije
SEKRETARICA ima atribut BrzinaKucanja,
POSLOVODJA ima atribut StepenStruneSpreme, itd.
Kada postoji jedna ili vie potklasa, definisanih na osnovu istog atributa
(TipPosla), koristite sledeu grafiku notaciju za prikaz veze klasa/potklase:
Iako se po terminologiji ne vidi, kod veze klasa/potklasa se radi o vezi izmeu

tipova entiteta! Za prikaz veze (crtanje tipa poveznika) izmeu dva razliita tipa
entiteta koristite uobiajenu notaciju ER dijagrama.
Na slici 3-29. prkazan je EER dijagram koji prikazuje dve specijalizacije klase
RADNIK, po tipu posla i po nainu isplate. Prikazana je i klasina veza izmeu
tipova entiteta RADNIK i SEKTOR.
JMBG
Ime
RADNIK
TipPosla
Isplata
RADI_U
SEKTOR
SEKRETAR
INENJER
SW_INENJER
STALNO_ZAP
Slika 3-29. Primer specijalizacije
60
ZAP_NA_ODR

Generalizacija podrazumeva obrnuti postupak (bottom-up approach),
definisanje natklase na osnovu zajednilkih osobina nekih klasa. Prvi korak kod
generalizacije je pronalaenje zajednikih atributa kod entiteta (odnosno klasa).
Primer:
AUTOMOBIL (sa atributima boja, cena, maks.brzina) i KAMION (sa
atributima boja, cena, nosivost) se mogu generalizovati u VOZILO (sa
atributima boja i cena) (slika 3-30).
Slika 3-30. Primer generalizacije
Nasleivanje, odnosno generalizacija/specijalizacija moe da ide po dubini, tako

da se definie hijerarhija klasa. Hijerarhija podrazumeva da definisana potklasa
uestvuje u nekoj klasa/potklasa relaciji.
Na slici 3-31. je prikazana hijerarhija u kojoj je RADNIK natklasa za klase
SEKRETAR i INENJER, a ova druga je natklasa za klasu SW_INENJER.
Atributi nisu prikazani na dijagramu. Zbog nasleivanja, SW_INENJER bi imao
sve atribute svojih natklasa, INENJERa i RADNIKa.
SW_INENJER ima sve
atribute INENJERa i
RADNIKa
RADNIK
SEKRETAR
INENJER
SW_INENJER
Slika 3-31. Hijerarhija klasa
61

Kod EER modela mogu da se grade i reetke (Lattices), koje podrazumevaju da
potklasa moe da uestvuje u vie relacija klasa/potklasa. To su tzv. deljive
potklase.
Na slici 3-32. prikazana je reetka, u kojoj deljiva klasa
INENJER_MENADER nasleuje klase INENJER i MENADER. Ona ima
atribute obe svoje natklase.
INENJER_MENADER
(deljiva podklasa) je
MANADER i
INENJER
RADNIK
SEKRETAR
INENJER
MENADER
INENJER_MENADER
Slika 3-32. Primer deljive klase
Kategorije modeliraju odnos klasa/potklasa sa vie od jedne natklase ali

razliitih tipova entiteta. Nasleivanje atributa je selektivno. Na slici 3-33.
prikazana je kategorija VLASNIK, koja je potklasa unije tri klase OSOBA,
BANKA i KOMPANIJA. Praktino, VLASNIK moe da bude ili OSOBA, ili
BANKA ili KOMPANIJA, pa u skladu sa tim ima i odgovarajue atribute.
OSOBA
BANKA
U
VLASNIK
KOMPANIJA
Kategorija, VLASNIK, je
podklasa unije OSOBA,
BANKA, KOMPANIJA.
VLASNIK je ili OSOBA, ili
BANKA ili KOMPANIJA
Slika 3-33. Primer kategorije
62

Zadatak za vebu: EER modeliranje
Dat je EER dijagram na slici 3-34. Dodati neophodne detalje na osnovu
sledeih zahteva:
Izdavai mogu da izdaju razliite vrste knjiga i asopisa. Neki izdavai izdaju
samo knjige, neki samo asopise, a neki i knjige i asopise. Ne postoje knjige i
asopisi koje su izdanja vie od jednog izdavaa. Jedan autor moe da pie i
knjige i radove u asopisima. asopis obino sadri vie radova, svaki od njih
je napisao jedan ili vie autora. Knjige takoe mogu da imaju vie autora.
Jedan rad se ne moe pojaviti u vie asopisa. Svaka knjiga i svaki rad se
recenziraju od strane vie profesionalaca iz naune oblasti iz koje su autori.
Naravno, autori ne mogu da recenziraju svoje radove i svoje knjige. Svaki
strunjak koji vri recenziju knjige i autor knjige rade za nekog izdavaa i
plaeni su od strane tog izdavaa. Autori radova i recenzenti nisu plaeni.
Recenzenti radova ne mogu biti recenzienti knjiga. Autori i recenzenti koji nisu
plaeni od strane izdavaa, su poznati kao nezavisni profesionalci.
63

IZDAVA
ASOPIS
KNJIGA
LANAK
AUTOR_KNJIGE
NEZAVISNI_PROFESIONALAC
U
U
AUTOR_LANAKA
U
AUTOR
RECEZENT_LANKA
U
RECEZENT_KNJIGE
U
U
U
ZAPOSLENI_KOD_IZDAVAA
RECEZENT
Slika 3-34. EER dijagram za zadatak za vebu
64
4 RELACIONI
M O D E L P O D AT A K A
Relacioni model je najpopularniji i najrasprostranjeniji model podataka danas i

predstavlja osnovu za relacione baze podataka koje dominiraju na tritu. Najvei
broj aktuelnih sistema i tehnologija za rad sa bazama podataka baziran je na
relacionom modelu koji ima teoretsku osnovu u teoriji skupova i predikatskoj
logici prvog reda. Relacioni model je formulisao i predloio E.F. Codd 1970.
godine. Ovaj model je jednostavan za razumevanje i zasniva se na korienju
koncepta matematike relacije kao osnovnog gradivnog elementa modela.
4.1 Osnove relacionog modela podataka

Relacioni model podataka obezbeuje koncepte za specifikaciju strukture
podataka i za manipulaciju podacima, kao i ogranienja kojima se obezbeuje
integritet podataka. Navedeni koncepti su meusobno povezani i oslanjaju se jedan
na drugi. Inicijalna specifikacija relacionog modela koju je dao Codd, koja se
odnosila na model podataka sa relacijama kao tipom strukture podataka i
formalnim jezikom (relacionom algebrom) je tokom godina proirena, tako da
danas ne postoji specifikacija jedinstvenog standardizovanog relacionog modela,
ve postoje klase modela koje se baziraju na relacijama koje sadre odreene
specifinosti u pogledu korienih skupova operatora za specifikaciju upita,
auriranje podataka i specifikaciju ogranienja.
Snana teorijska osnova relacionog modela obezbeuje da se projektovanje i
evaluacija relacionih baza podataka izvodi sistematskim metodama zasnovanim na
apstrakcijama koje su jednostavne za razumevanje, redukuju kompleksnost
projektovanja, odnosno omoguavaju projektantu da se koncentrie na sam
problem. Relacioni model oslobaa korisnika frustracija oko rukovanja podacima
na niskom nivou, zalaenja u detalje smetanja podataka i metodama pristupa iz
korisnikog interfejsa. Relacioni model obezbeuje sredstva za opis podataka sa
njihovom prirodnom strukturom, bez dodatnih struktura za potrebe mainske
reprezentacije. Ovaj model daje osnovu za jezik visokog nivoa za pristup
podacima koji obezbeuje maksimalnu nezavisnost izmeu programa, s jedne
strane, i mainske reprezentacije, s druge strane.
Neformalno se moe navesti da baza podataka predstavlja kolekciju vie
relacija, a svaka relacija je tabela sa vrstama i kolonama. Relacija, kao osnovni
koncept relacionog modela je zapravo matematika relacija (to je objanjeno u

narednom odeljku), i ima jednostavnu i za korisnika vrlo prihvatljivu
reprezentaciju u obliku dvodimenzionalne tabele sa podacima, koja se na
odgovarajui nain moe vizuelizovati.
Tabelarna reprezentacija relacije omoguava da se lako razume sadraj baze
podataka, i da se za manipulaciju podacima koristi jednostavan jezik visokog
nivoa. Svaka vrsta tabele predstavlja kolekciju vrednosti podataka koje su u nekom
odnosu. Intuitivno, vrsta u tabeli predstavlja odreeni entitet (objekat, pojavu ili
dogaaj) realnog sveta, dok vrednosti u pojedinim kolonama predstavljaju
odreena svojstva odgovarajueg entiteta. Podaci u razliitim tabelama mogu da
budu u meusobnoj vezi, tako da kreiranje zbirne predstave o objektima realnog
sveta koji su u odreenom odnosu zahteva povezivanje podataka iz razliitih
tabela. Vana karakteristika relacionih baza podataka je da se podaci predstavljaju
na uniforman nain, preko vrednosti na odgovarajuim pozicijama u
vrstama/kolonama tabela.
4.2 Koncepti relacionog modela podataka

Formalno, u terminologiji relacionog modela podataka, vrste relacije se
nazivaju torke, kolone atributi, a tabela se naziva relacija. Vrednost koje mogu
da se pojave u nekoj od kolona, odnosno vrednosti atributa, su odreene
domenom. Ova sekcija se bavi formalnim definicijama ovih koncepata.
Koncepti na nivou ekstenzije kod relacionog modela su:
Domen atributa
Torka
Pojava relacije
Pojava baze podataka
Koncepti na nivou intenzije relacionog modela su:
Atribut
ema relacije
ema baze podataka
Svi ostali koncepti se izvode iz osnovnih primenom odreenih formalnih,

matematikih pravila, koja nisu deo ovog materijala i osnovnog kursa iz baza
podataka.
4.3 Domeni, atributi, torke i relacije

U relacionom modelu podataka polazna osnova za definisanje koncepata
strukturalne komponente je univerzalni skup atributa. Obeleava se sa U, pri
emu je U={Ai|i=1,n}. To je skup stributa realnog sistema ili nekog njegovog dela
66
Relacioni model podataka

koji se posmatra (mini sveta). Svaki atribut Ai opisuje neku odabranu osobinu klase
entiteta ili klase poveznika. Svakom atributu je pridruen domen, u oznaci
dom(Ai), koji predstavlja specifikaciju skupa moguih vrednosti iz kojeg atribut
uzima vrednosti.
U relacionom modelu podataka domen D je skup atominih vrednosti. U ovom
sluaju atominost znai da su svi elementi domena nedeljivi. Uobiajeni nain
specifikacije domena je preko tipa podataka. Korisno je da svaki domen ima naziv.
Domen se moe definisati i kao podopseg vrednosti nekog drugog domena ili
nabrajanjem doputenih domenskih vrednosti. U relacionom modelu podataka
svaki atribut ima pridruen domen, pri emu vie atributa moe imati isti domen.
Na primer, atributi koji se odnose na ime studenta i ime nastavnika mogu da imaju
isti domen koji definie da se radi o podacima znakovnog tipa duine 20.
Koncept domena u relacionom modelu je vrlo vaan, zato to omoguava
korisniku da definie na jednom centralnom mestu znaenje i izbor vrednosti koje
atribut moe uzimati. Domen atributa se definie tipom podataka, duinom
podataka i opsegom vrednosti. Atributi uzimaju vrednosti iz odgovarajueg
domena koji im je dodeljen, to u praksi znai da e vrednosti u tabeli za neku
kolonu da budu onog tipa podataka koji smo izabrali za tu kolonu. Meutim, moe
da se desi da atribut nema dodeljenu vrednost to podrazumeva korienje tzv Null
vrednosti sa znaenjem kako je to objanjeno u odeljku 3.1.1. Specijalna vrednost
Null moe biti lan svakog domena.
Primer: Definicija domena
Logika definicija domena:

o
Lokalni_telefonski_broj: skup 6-cifrenih telefonskih brojeva koji

su validni na podruju lokalne mrene grupe
o Ocena_studenta: celi broj izmeu 6 i 10
o Kod_obrazovnog_profila: skup oznaka profila Elektronskog
fakulteta: E,EEN,EMK,MIM,RI,T,US
Tip podataka ili format domena:
o
o
o
Lokalni_telefonski_broj: CHARACTER string oblika ccc-ccc

Prelazna_ocena_studenta: INTEGER broj iz opsega 6-10
Kod_obrazovnog_profila: CHARACTER string iz skupa
{E,EEN,EMK,MIM,RI,T,US}
Definicija relacije u relacionom modelu se oslanja na definiciju matematike

relacije, kao podskupa Dekartovog proizvoda skupa domena.
Definicija relacije:
Neka je A={A1, A2,..., An} skup atributa realnog sistema, i neka je svakom
atributu Ai pridruen domen Di. Domeni ne moraju biti razliiti.
67

Relacija r na skupovima D1, D2,..., Dn je konaan skup n-torki (torki) od kojih
svaka sadri prvi element iz D1, drugi iz D2, ... , n-ti iz Dn.
Relacija r je na osnovu ove definicije podskup Dekartovog proizvoda skupa
domena: r D1 x D2 x ... Dn, gde je D1 x D2 x ... Dn = {(v1, v2, , vn) | vi Di, i =
1,2,,n}. Relacija r u relacionom modelu se sastoji iz zaglavlja i tela relacije.
Zaglavlje relacije je {A1, A2,..., An}, iji elementi Ai predstavljaju atribute. Svaki
atribut je odreen imenom i odgovarajuim domenom Di. Telo relacije ine n-torke
(v1, v2, , vn), pri emu svaka n-torka ima istu kardinalnost kao i zaglavlje, a svaki
element vi neke n-torke je lan domena odgovarajueg atributa (vi dom(Ai),
odnosno vi Di ). Stepen relacije r jednak je broju atributa zaglavlja.
ema relacije predstavlja opis relacije i definisana je na osnovu skupa atributa.
Zaglavlje relacije opisano u prethodnom pasusu praktino predstavlja emu
relacije.
Definicija eme relacije:
ema relacije je imenovana dvojka, u oznaci N(R,C), gde je:
N naziv eme relacije,
RU skup atributa relacije, a

C skup ogranienja integriteta relacije
U ovoj definiciji N je neformalna komponenta koja opisuje semantiku relacije u

prirodnom jeziku. Skup ogranienja integriteta C opisuje odnose izmeu elemenata
domena atributa iz R. Praktino, ova komponenta ograniava koje e se torke
pojaviti u instanci ove relacije.
Uobiajeno je da se ema relacije obeleava tako to se navede njen naziv, a
nakon toga skup atributa (s tim da se uz svaki atribut moe navesti domen i
eventualno ogranienje kljua), i evenatualno skup ogranienja. Na primer,
injenicu da je R ema relacije definisana nad atributima A1, A2,..., An,
oznaavamo sa:
R=(A1, A2,..., An),
ili alternativno
R(A1, A2,..., An).
Primer: Oznaavanje relacije
Relacija sa imenom R i listom atributa A1, A2,..., An, primarnim kljuem A1:
R(A1, A2,..., An)
Relacija sa imenom R i listom atributa A1, A2,..., An, listom domena atributa
D1, D2,..., Dn i kljuem A1
68

R(A1:D1, A2:D2,..., An:Dn)
U oba primera A1 se odnosi na ogranienje tipa primarni klju relacije.
Primer: Oznaavanje relacije uz definisana ogranienja
Posmatraemo tip entiteta STUDENT sa atributima {IND,IME,PREZIME,BPI}
Pri emu je u toku projektovanja uoeno da vae ogranienja:
(1) svaki student ima broj indeksa i ne postoje dva studenta sa istim
brojem indeksa
(2) broj poloenih ispita (BPI) je vei od nule i manji od 50
ema relacije koja predstavlja model ove klase entiteta bi imala oblik:
STUDENT({IND,IME,PREZIME,BPI}, {1, 2})
Primer: ema relacije koja se odnosi na radnike preduzea
Primer dve eme relacije koje se odnose na radnike, u drugom sluaju su
navedeni domeni atributa:
RADNIK1 (MBR, LIME, LD, SBR)
RADNIK2 (MBR:integer, LIME:char(15),LD:real, SBR:integer)
Pojava (instanca) relacije se odnosi na skup n-torki relacije u nekom trenutku.
Ako se napravi analogija relacione eme sa konceptom tip podataka, tada pojam
reklacije odgovara konceptu promenljive u programskom jeziku. Kao to
promenljiva moe da ima razlilite vrednosti u razliitim trenucima, tako i relacija
moe da sadri razliite n-torke u razliitim trenucima.
Definicija pojave relacije:
Pojava relacije r nad emom relacije (R,C), u oznaci r(R), je skup n-torki
t = {t1,t2,...,tk} koje zadovoljavaju ogranienja C.
U ovoj definiciji svaka n-torka predstavlja ureenu listu od n-vrednosti,
t=<v1,v2,...vn>, gde je svaka vrednost iz odgovarajueg domena, viDi ili vi=null. ita vrednost torke t, koja odgovara atributu Ai, se obeleava sa t[Ai]
Primer:
Za emu relacije RADNIK(MBR,LIME,LD,SBR) jedna pojava relacije radnik
je:
<2203,MIRA,50000,10>
<2817,PERA,40000,20>
<2932,MIRA,35000,10>
<2995,GOCA,18000,30>
69

Relacija r nad emom relacije R(A1, A2, ..., An) se predstavlja tabelom ije
kolone odgovaraju atributima, a vrste pojedinim n-torkama vrednosti ovih atributa.
Sve vrste moraju biti razliite.
Primer: Predstavljanje relacije tabelom
Relacija radnik definisana nad emom relacije RADNIK(MBR, LIME,
LD,SBR) se predstavlja tabelom kao na slici 4-1.
radnik
MBR
LIME
LD
SBR
2203
MIRA
50000
10
2817
PERA
40000
20
2932
MIRA
35000
10
2995
GOCA
18000
30
Slika 4-1. Tabela sa podacima koja odgovara relaciji radnik
4.3.1 Svojstva eme relacije i relacije

Vano svojstvo eme relacije je da ne sadri dva jednaka naziva atributa kao i to
da redosled naziva atributa u relaciji nije bitan. Ova dva svojstva proizilaze iz
definicije eme relacije: navedeno je da je ema relacije skup naziva atributa, a po
definiciji skup ne moe sadrati dva meusobno jednaka elementa. Posledica
promene redosleda atributa i torki u relaciji nee biti gubitak informacije sadrane
u relaciji.
Posledica definicije relacije je svojstvo da relacija ne sadri dve jednake torke,
kao i da redosled torki u relaciji nije bitan. Ova dva svojstva proizilaze iz definicije
relacije koja je definisana kao skup torki. Poto su relacije skupovi n-torki, a
izmeu elemenata skupa ne postoji ureenost, redosled n-torki u relaciji nije
definisan niti je bitan. Ipak, na nivou implementacije ili vizuelizacije sadraja
relacije postoji ureenost n-torki zato to su one smetene u odreenom fizikom
redosledu. Iako taj redosled nije od znaaja, korisniku se na logikom nivou moe
prikazati razliit redosled n-torki, na primer po rastuim vrednostima nekog
atributa.
4.4 Klju eme relacije

U prethodnom poglavlju je navedeno da kod ER modela za svaki tip entiteteta
postoji atribut ili skup atributa koji na jedinstven nain identifikuje svaki
pojedinani entitet u skupu entiteta. U relacionom modelu podataka sve torke su
razliite, odnosno ne postoje dve torke koje imaju iste vrednosti za sve atribute
relacije. Najee se torke razlikuju samo na odreenom podskupu atributa. Za
specifikaciju ovih ogranienja koristi se, kao kod ER modela, koncept kljua eme
relacije.
70

Klju eme relacije je atribut ili skup atributa (tzv kompozitni klju odnosno
klju od vie atributa), ije vrednosti predstavljaju identifikator torke u relaciji, to
odgovara identifikatoru pojave tipa entiteta. Svaka ema relacije ima bar jedan
klju koji na jedinstven nain identifikuje svaku torku u relaciji. Atributi koji su
deo kljua relacije se nazivaju kljuni odnosno primarni atributi.
U relacionom modelu podataka postoji vie termina koji se koriste za relacione
kljueve, to e nadalje biti uvedeno.
Definicija kljua
Skup atributa X R predstavlja klju eme relacije (R,C), ako za svako r vae
sledea dva uslova:
1) U1: (u,v r) (u[X]=v[X] u=v)
2) U2: (Y X) ( U1)
Uslov U1 definie jedinstvenost vrednosti kjua, dok uslov U2 definie
minimalnost skupa atributa kljua.
Na osnovu ove definicije vano je naglasiti da je klju minimalni skup atributa
koji na jedinstven nain identifikuje svaku svaku torku u relaciji, to znai da
uklanjanjem bilo koje komponente kljua, klju gubi svojstvo identifikacije.
Jedna ema relacije moe imati vie kljueva, i to su ekvivalentni kljuevi ili
kljuevi kandidati.
Jedan od ekvivalentnih kljueva se bira za primarni klju relacije. Za primarni
klju moraju da vae uslovi jedinstvenosti i minimalnosti, odnosno uslovi U1 i U2.
Atribut ili skup atributa koji na jedinstven nain identifikuje torku u relaciji se
zove superklju. Svaka relacija ima najmanje jedan superklju, a to je skup svih
atributa te relacije. Kod superkljua vai samo uslov jedinstvenosti (uslov U1),
odnosno ne vai uslov minimalnosti U2.
Superklju iji nijedan pravi podskup nema svojstvo super kljua u toj relaciji je
kandidat za klju. Kod kandidata za kljueve vae oba uslova, U1 i U2.
Primarni klju praktino je jedan od kandidata za klju koji je izabran od strane
projektanta baze podataka da na jedinstven nain identifikuje torke relacije. Preko
ovog kljua se najee vri traenje u relaciji. On se koristi kao strani klju u
drugim emama relacija, odnosno preko njega se ostvaruju meusobne veze
izmeu relacija/tabela.
Pojam strani klju se odnosi na atribut ili skup atributa jedne relacije koji se
uparuje sa kljuem kandidatom druge ili iste relacije. Skup atributa SK relacije r je
strani klju relacije ako zadovoljava sledea dva uslova:
71
Ako se relacija r referencira na relaciju q, tada atributi iz SK relacije r

moraju imati isti domen kao atributi primarnog kljua PK relacije q.
Ako se torka t1 relacije r referencira na torku t2 relacije q, tada vrednost

stranog kljua SK u torki t1 relacije r mora biti jednaka vrednosti
primarnog kljua PK u torki t2 relacije q ili moe imati nedefinisanu
(Null) vrednost.
Slika 4-2. prikazuje meusobnu povezanost relacija radnik, sektor i projekat

preko stranih kljueva. Relacija radnik ima strani klju SBR, koji je primarni klju
relacije sektor zbog veze koja postoji izmeu radnika i sektora u kome radi.
Relacija projekat takoe ima kao strani klju SBR zbog veze koja postoji izmeu
projekta i sektora koji ga izvodi. Projekat sadri i strani klju PRUK koji je
praktino MBR radnika zbog veze radnika kao rukovodioca projekta.
Slika 4-2. Ostvarivanje veza preko stranih kljueva
4.4.1 Pregled terminologije za kljueve

U ovom odeljku dat je kratak pregled terminologije koja se koristi kod kljueva.
Nakon samog termina sledi kratak neformalni opis.
Klju
Poto su sve torke relacije razliite, u relaciji mora postojati atribut ili skup
atributa (tzv kompozitni klju klju od vie atributa), nazvani relacioni kljuevi
ili kljuevi relacije, koji na jedinstven nain identifikuje svaku torku relacije.
Superklju
Atribut ili skup atributa koji na jedinstven nain identifikuju torku unutar
relacije (nema uslova minimalnosti).
Klju kandidat
Superklju iji nijedan pravi podskup nije superklju relacije. Relacija moe
imati vie kljueva kandidata, kod implementacije se bira jedan od njih kao
primarni klju.
72

Primarni klju
Klju kandidat koji je odabran da na jedinstven nain identifikuje torke unutar
relacije.
Strani klju
Atribut ili skup atributa jedne relacije koji se uparuje sa kljuem kandidatom
neke druge ili iste relacije. Vaan za ostvarivanje meusobnih veza izmeu tabela.
4.5 ema i pojava relacione baze podatka

ema relacione baze podataka predstavlja konaan skup ema relacija baze
podataka Ri (i=1, 2,..., m) i skup meurelacionih ogranienja IC. Oznaava se sa
S(R1,R2,...,Rm;IC).
Pojava (instanca) baze podataka nad emom S(R1,R2,...,Rm;IC), je skup pojava
ri ema relacija Ri (i=1, 2,..., m), pri emu skup relacija ri (i=1, 2,..., m) zadovoljava
ogranienja integriteta IC. Oznaava se sa s.
Primer: ema relacione baze podataka FAKULTET
U ovoj emi je definisano: ime eme baze podataka (FAKULTET), imena ema
relacija (STUDENT, PROFESOR, PREDMET, ZAPISNIK, IZBOR i
NASTAVA) i imena atributa (Ind, Ime, Adresa,). Ogranienja integriteta IC
nisu definisana.
FAKULTET({STUDENT,PROFESOR,PREDMET,ZAPISNIK,
NASTAVA}; IC)
STUDENT(Ind,Ime,Adresa,Status)
PROFESOR(Id,Ime,KatId)
PREDMET(KatId,PrKod,PrNaziv,Opis)
ZAPISNIK(StudId,PrKod,Rok,Ocena)
IZBOR(StudId,PrKod,Semestar)
NASTAVA(ProfId,PrKod,Semestar)
Primer: ema relacione baze podataka PREDUZEE
U ovom primeru Svaka ema relacije sadri specifikaciju primarnog kljua
(podvueni atribut u emi relacije) i specifikaciju stranih kljueva (italic u emi
relacije)
PREDUZEE ({RADNIK, SEKTOR,PROJEKAT};IC)
RADNIK(MBR, LIME, LD, SBR)
73

SEKTOR(SBR, SNAZIV, SLOK)
PROJEKAT(PBR, PNAZIV, SBR, PRUK)
Primer: Jedna pojava baze podataka PREDUZEE
Na slici 4-3. prikazana je jedna pojava baze podataka preduzee ija je ema
data u prethodnom primeru.Oznaeni su primarni kljuevi (podvueni nazivi
atributa) i strani kljuevi (imena oznaena italikom)
radnik
MBR
LIME
LD
SBR
2203
2817
2932
2995
3305
3515
3819
MIRA
PERA
MIRA
GOCA
LAZA
JOVAN
VLADA
50 000
40 000
35 000
18 000
60 000
20 000
65 000
10
20
10
30
40
20
30
sektor
projekat
SBR
SNAZIV
SLOK
PBR
PNAZIV
SBR
PRUK
10
20
30
40
PROIZVODNJA
PROIZVODNJA
ININJERING
RAZVOJ
NI
BEOGRAD
NI
NI
100
200
300
400
PC
HOST
LAN
VIPX
10
20
30
40
2203
3305
3819
2817
Slika 4-3. Jedna pojava baze podataka PREDUZEE
Primer: ema baze podataka FAKULTET sa definisanim ogranienjima

U ovoj emi je definisano ogranienje domena i ogranienje kljua (primarni
klju). Data su i ogranienja stranog kljua.
FAKULTET(STUDENT, PROFESOR, PREDMET, ZAPISNIK, NASTAVA,
IC)
STUDENT(Ind:INTEGER, Ime:STRING, Adresa:STRING,Status:STRING)
PROFESOR(Id:INTEGER, Ime:STRING, KatId:STRING)
PREDMET(KatId:STRING,PrKod:STRING,PrNaziv:STRING,
Opis:STRING)
ZAPISNIK(StudId:INTEGER, PrKod:STRING, Rok:STRING,
Ocena:INTEGER)
IZBOR(StudId:INTEGER, PrKod:STRING, Semestar:STRING)
NASTAVA(ProfId:INTEGER, PrKod:STRING, Semestar:STRING)
74

ZAPISNIK(StudId) referencira STUDENT(Ind)
ZAPISNIK(PrKod) referencira PREDMET(PrKod)
IZBOR(StudId) referencira STUDENT(Ind)
IZBOR(PrKod) referencira PREDMET(PrKod)
NASTAVA(ProfId) referencira PROFESOR(Id)
NASTAVA(PrKod) referencira PREDMET(PrKod)
4.5.1 Predstavljanje ema relacione baze podataka

Uobiajena konvencija za predstavljanje relacione eme obuhvata ime relacije
iza koga slede imena atributa u malim zagradama. Imena atributa se odvajaju
zapetama. Primarni klju se podvlai, a spoljni kljuevi se piu italikom. Nie je
prikazana relaciona ema baze podataka PREDUZEE:
RADNIK (LIME, SSLOVO, PREZIME, MATBR, DATRODJ, POL, PLATA,
ADRESA, MATBROJS, BRSEK)
PROJEKAT (NAZIV, LOKPR, BROJPR, BRS)
SEKTOR (NAZIV, SBROJ, MATBRR, DATPOST)
CLAN-PORODICE (MATBRRAD, IME, POL, SRODSTVO, DATRODJ)
LOK-SEK (BRS, LOKACIJA)
RADI-NA (MBR, BRPR, SATI)
Radi poboljanja itljivosti relacione eme, obino se za imena atributa ili
entiteta koriste mala slova, tako da ema dobija jedan od sledeih formata:
RADNIK (Lime, Sslovo, Prezime, MatBr, DatRodj, Pol, Plata, Adresa,
MatBrojS, BrSek)
PROJEKAT (Naziv, LokPr, BrojPr, BrS)
SEKTOR (Naziv, SBroj, MatBrR, DatPost)
CLAN-PORODICE (MatBrRad, Ime, Pol, Srodstvo, DatRodj)
LOK-SEK (BrS, Lokacija)
RADI-NA (Mbr, BrPr, Sati)
radnik (LIME, SSLOVO, PREZIME, MATBR, DATRODJ, POL, PLATA,
ADRESA, MATBROJS, BRSEK)
projekat (NAZIV, LOKPR, BROJPR, BRS)
sektor (NAZIV, SBROJ, MATBRR, DATPOST)
75

clan_porodice (MATBRRAD, IME, POL, SRODSTVO, DATRODJ)
lok_sek (BRS, LOKACIJA)
radi_na (MBR, BRPR, SATI)
Uobiajena konvencija za predstavljanje relacione eme je dijagram eme
relacije. Svaka ema relacije se predstavlja jednim izduenim pravougaonikom koji
ima onoliko elija koliko je atributa u emi relacije. Ime eme relacije se ispisuje
iznad pravougaonika, a imena atributa u elijama, pri emu ostaje pravilo da se
primarni klju podvlai, a da se spoljni kljuevi piu italikom. Na slici 4-4. je
prikazan dijagram relacione eme baze podataka PREDUZEE:
RADNIK
LIME SSLOVO PREZIME MATBR DATRODJ POL
...
... PLATA ADRESA MATBROJS BRSEK

PROJEKAT
NAZIV LOKPR BROJPR BRS
SEKTOR
NAZIV SBROJ MATBRR DATPOST
CLAN_PORODICE
MATBRRAD IME POL SRODSTVO DATRODJ
LOK_SEKTOR
RADI_NA
BRS LOKACIJA
MBR BRPR SATI
Slika 4-4. Relaciona ema baze podataka PREDUZEE
4.6 Ogranienja u relacionom modelu

Ogranienja predstavljaju neophodni sastavni deo definicije eme baze
podataka. Koriste se pri formiranju i auriranju baze podataka u cilju odravanja
sadraja baze podataka u saglasnosti sa uoenim odnosima izmeu atributa realnog
sistema. Neka od ogranienja iz integritetne komponente smo ve usvojili u
prethodnim odeljcima na primer, naveli smo da se za svaki atribut u relaciji
vezuje odreeni domen. Ustvari, radi se o domenskim ogranienjima, kojima se
ograniava skup dozvoljenih vrednosti atributa relacije. Definisan je i pojam
kljua eme relacije, koji obezbeuje da su sve torke u relaciji razliite.
Ogranienja se mogu klasifikovati kao:
76
Ogranienja torki proveravaju se za svaku torku relacije
Relaciona ogranienja proveravaju se meusobni odnosi vie torki

jedne relacije. Ovim se regulie lokalna konzistentnost usaglaenost
pojave relacije sa definicijom eme relacije.
Meurelaciona ogranienja Regulie se globalna konzistentnost baze

podataka, odnosno usaglaenost pojave baze podataka sa definicijom
eme baze podataka.
Primer: Ogranienje na nivou torki

Ogranienje 2 koje je zadato u nekom od prethodnih primera: broj poloenih
ispita (BPI) je vei od nule i manji od 50:
2(r)=T (ur)(0u[BPI]50)
Primer: Ogranienje na nivou relacije
Ogranienje 1 koje je zadato u nekom od prethodnih primera predstavlja
ogranienje na nivou relacije:
1(r)=T (u,vr)(u[IND]=v[IND] u=v)
U relacionom modelu podataka postoje i druga pravila integriteta, koja
ograniavaju ili zabranjuju pojave odreenih torki u relaciji. Definiu se
ogranienja u odnosu na kljueve, tipove entiteta, meusobno referenciranje i
semantiku relacija. Ova ogranienja se nazivaju, redom:
integritet kljueva
integritet entiteta
referencijalni integritet
semantiki integritet
Integritet kljueva podrazumeva da vrednosti kljueva kandidata moraju biti

jedinstvene u pojavi eme relacije. Ovim ogranienjem se definie ogranienje
jedinstvenosti. Razlog uvoenja se odnosi na injenicu da je jedinstvenost
vrednosti kljueva kandidata posledica injenice da relacija predstavlja skup torki,
te stoga u relaciji ne mogu postojati dve iste torke.
Integritet entiteta podrazumeva da niti vrednost primarnog kljua, niti bilo
koje njegove komponente, ne sme imati nepoznatu (NULL) vrednost u pojavi
relacije. Poto primarni klju slui za identifikaciju pojedinih torki relacije, to
nepoznata vrednost primarnog kljua bi onemoguila da se neke torke relacije
identifikuju.
Referencijalni integritet se odnosi na zahtev da referencirana torka mora
postojati. Vaan tip referencijalnog integriteta je ogranienje stranog kljua. Ovo
ogranienje definie da, ako u relaciji postoji strani klju, tada vrednost stranog
77

kljua mora biti jednaka vrednosti kljua kandidata neke torke referencirane
relacije ili imati NULL vrednost. To je ogranienje koje se definie izmeu dve
relacije u cilju odravanja konzistentnosti meu torkama ovih relacija.
Referencijalni integritet obezbeuje da se svaka torka iz jedne relacije referencira
samo na postojeu torku u drugoj ili istoj relaciji
Ogranienja semantikog integriteta se odnosi na opta, aplikativno bazirana
ogranienja. To su pravila koja specificira korisnik, a koja definiu ili ograniavaju
neke aspekte realnog sistema. Obino se odnose na neka pravila koja ne mogu da
se pokriju ogranienjima na nivou eme baze podataka, koja su specifina za svaki
aplikativni system i koja moraju biti nametnuta i osigurana odgovarajuim
mehanizmima. Na primer, ogranienje tipa Broj zaposlenih u svakom sektoru
preduzea ne moe biti vei od 20 ili Plata rukovodioca mora biti vea od plata
njegovih radnika, se ne moe specificirati korienjem prethodno opisanih
deklarativnih ogranienja na nivou eme baze podataka. Umesto toga mogu se
specificirati procedure sa ciljem da se obezbedi implementacija eljenih
ogranienja zahtevanih poslovnim pravilima realnog sistema.
4.6.1 Specifikacija ogranienja u DBMSu

U relacijama baze podataka i izmeu relacija baze podataka postoji veliki broj
ogranienja integriteta koja treba eksplicitno uneti u emu baze podataka. U emi
relacije se eksplicitno specificiraju sledea ogranienja:
Domeni atributa.
Primarni klju.
Strani kljuevi i referenca na primarni klju.
Da li atribut moe imati NULL vrednost.
Da li atribut mora imati jedinstvenu vrednost.
Da li atribut ima podrazumevanu vrednost.
Ostala semantika ogranienja.
Ogranienja integriteta se specificiraju u emi baze podataka i eksplicitno
specificiraju korienjem jezika DDL (Data Definition Language, deo SQLa koji je
opisan u jednom od narednih poglavlja), tako da ih DBMS moe automatski
nadzirati. Semantika ogranienja se mogu specificirati i kontrolisati unutar
aplikacionih programa za auriranje baze podataka ili se mogu specificirati u emi
baze podataka korienjem jezika za specificiranje ogranienja.
Veina komercijalnih DBMS-a podrava integritet kljua i entiteta, dok manji
broj podrava referencijalni i semantiki integritet.
Detalje o jeziku SQL moete proitati u narednim poglavljima, a u ovoj sekciji
je dat pregled dela SQL naredbi koje se koriste za definisanje podataka (iz DDL
podskupa naredbi) i njihovo korienje za definisanje ogranienja.
78

Za ilustraciju definisanja navedenih ogranienja, koristie se date eme relacija
STUDENT i PREDMET:
STUDENT (Ind:INTEGER, Ime:STRING, Adresa:STRING,Status:STRING),
Klju: {Ind}
PREDMET(KatId:STRING,PrKod:STRING,PrNaziv:STRING, Opis:STRING),
Kljuevi: {PrKod}, {KatId,PrNaziv}
U nastavku je najpre prikazana naredba za specificiranje tipa relacije, odnosno
kreiranje tabele u bazi podataka, a nakon toga su date odgovarajue SQL naredbe
za definisanje ogranienja.
Specificiranje tipa relacije
SQL naredba za kreiranje odgovarajue tabele za emu relacije STUDENT je:
CREATE TABLE STUDENT (
Ind
INTEGER,
Ime
CHAR(20),
Adresa CHAR(50),
Status
CHAR(10) )
Nakon izvrenja ove naredbe, kreirana je tabela STUDENT sa kolonama Ind,
Ime, Adresa i Status, svaka od njih definisana navedenim tipom podatka.
Specificiranje ogranienja kljua
Klju relacije STUDENT je atribut Ind, to se u naredbi za kreiranje tabele
moe specificirati na dva naina.
Prvi nain je navoenjem ogranienja PRIMARY KEY:
Ind
INTEGER,
Ime
CHAR(20),
Adresa
CHAR(50),
Status
CHAR(10),
PRIMARY KEY (Ind ) )

Ovaj nain je primenjen i u narednoj naredbi, s tim da je kod tabele PREDMET
definisano ogranienje UNIQUE za klju kandidat koji se sastoji od dva atributa
KatID i PrNaziv:
CREATE TABLE PREDMET (
KatId
CHAR(6),
PrKod CHAR(4),
79

PrNaziv CHAR(20),
Opis
CHAR(100),
PRIMARY KEY (PrKod),
UNIQUE (KatId,PrNaziv) )
Generalno, UNIQUE je mehanizam DBMS-a koji slui za (a) deklarisanje
ogranienja kljua kandidata (kada su nula vrednosti zabranjene) i (b) deklarisanje
ogranienja jedinstvenosti (kada se ne zahteva zabrana nula vrednosti za sva
obeleja u UNIQUE).
Specificiranje NULL i podrazumevanih vrednosti
Za tabelu STUDENT, za atribut Status definisana je podrazumevana vrednost
Bruco a ime ne sme da ima NULL vrednosti:
Ind
INTEGER,
Ime
CHAR(20) NOT NULL,
Adresa CHAR(50),
Status
CHAR(10) DEFAULT Bruco',
PRIMARY KEY (Ind ) )
Drugi nain zadavanja ogranienja primarnog kljua je navoenjem kljune rei
PRIMARY KEY odmah nakon specifikacije odgovarajueg atributa:
Ind
INTEGER PRIMARY KEY,
Ime
CHAR(20) NOT NULL,
Adresa CHAR(50),
Status
CHAR(10) DEFAULT Bruco' )
Specificiranje ogranienja domena
Za specificiranje ogranienja domena, primer se odnosi na emu relacije
ZAPISNIK:
ZAPISNIK(StudId: INTEGER, PrKod: STRING, Rok: STRING, Ocena:
INTEGER), Klju: {StudId, PrKod, Rok}
Pored primarnog kljua koji se sastoji od tri atributa, definisano je ogranienje
domena (navoenjem CHECK kod kreiranja tabele), da Ocena moe da ima
vrednosti u opsegu od 5 do 10 i vrednost ne moe da bude NULL, kao i
ogranienje da vrednost StidId moe da bude izmeu 0 i 7000:
CREATE TABLE ZAPISNIK (
StudId INTEGER,
80

PrKod CHAR(6),
Rok
CHAR(6),
Ocena INTEGER NOT NULL,
PRIMARY KEY (StudId,PrKod,Rok),
CHECK (Ocena IN ( 5,6,7,8,9,10) AND VALUE IS NOT NULL),
CHECK (StudId >0 AND StudId <7000) )
Kreiranje korisniki definisanog domena
Za kreiranje korisniki definisanog domena koristi se CREATE DOMAIN. U
primeru je navedeno kreiranje domena OCENA. Nakon toga je kod kreiranja tabele
ZAPISNIK iskorien ovaj domen za specificiranje tipa jedne od kolona:
CREATE DOMAIN OCENA INTEGER
CHECK (VALUE IN (5,6,7,8,9,10) AND VALUE IS NOT NULL )
StudId INTEGER,
PrKod CHAR(6),
Rok
CHAR(6),
Ocena OCENA,
CHECK (StudId >0 AND StudId <7000) )
Specificiranje ogranienja stranog kljua
Specificiranje ogranienja stranog kljua je prikazano za zadatu emu baze
podataka, gde su oznaeni primarni (podvuena imena) i strani kljuevi (italic):
STUDENT(Ind, Ime, Adresa,Status)
PROFESOR(Id, Ime, KatId)
PREDMET(KatId, PrKod, PrNaziv, Opis)
ZAPISNIK(StudId, PrKod, Rok, Ocena)
IZBOR(StudId, PrKod, Semestar)
NASTAVA(ProfId, PrKod, Semestar)
Moe da se uoi da su neki atributi delovi primarnog kljua, a ujedno i strani
kljuevi praktino, oni mogu da budu posledica preslikavanja veza M:N ili slabih
tipova entiteta.
SQL naredba za kreiranje tabele ZAPISNIK sa specifikacijom ogranienja
stranih kljueva:
81

StudId INTEGER,
PrKod CHAR(6),
Rok
CHAR(6),
Ocena OCENA,
FOREIGN KEY (StudId) REFERENCES STUDENT(Ind),
FOREIGN KEY (PrKod) REFERENCES PREDMET )
Ova tabela ima dva strana kljua, StudId i PrKod, koji se referenciraju na
odgovarajue atribute STUDENTa i PREDMETa.
Unos, brisanje i auriranje torki
Za promenu vrednosti torki, kao i za inos novih koriste se sledee SQL naredbe:
Unos torki:
INSERT INTO STUDENT(Ind, Ime, Adresa,Status)
VALUES (11708, Ana, Niavska 11 Pirot,apsolvent)
Ova SQL naredba omoguava unos jedne torke u relaciju odnosno vrste. Mogu
se izostaviti imena atributa (kolona) u klauzuli INTO, ali se vrednosti atributa
moraju navesti u redosledu koji je defiisan emom relacije. Dobar stil je da se
imena atributa eksplicitno navedu.
Brisanje torki:
DELETE FROM STUDENT S
WHERE S.ime= Ana
Naredba DELETE, u ovom sluaju, iz tabele STUDENT brie torku koja u
koloni Ime ima vrednost Ana. Ukoliko se uslov u WHERE izostavi, naredba e
obrisati sve torke/vrste u tabeli STUDENT. Ova naredba brie podatke a ne i
definiciju tabele u bazi podataka.
Auriranje vrednosti torki:
UPDATE STUDENT S
SET S.Status= poslediplomac
WHERE S.ind= 11708
Ova SQL naredba omoguava auriranje vrednosti navedenih atributa u SET
pod uslovima zadatim u WHERE. Navedena naredba u tabeli STUDENT aurira
torku koja u koloni Ind ima vrednost 11708 tako to postavlja novu vrednost
82

poslediplomac u koloni Status. Ako se ne navede uslov, aurirae se vrednosti
navedenog atributa u svim torkama.
4.7 Operacijska komponenta

U relacionom modelu nad relacijama je definisan skup operacija koje
omoguavaju specificiranje upita nad bazom podataka. Jedna od osnovnih
karakteristika relacionog modela je da su operandi operacija koji se koriste kod
zadavanja upita, cele relacije. Rezultat upita odnosno primene operacija je nova
relacija koja moe biti formirana od jedne ili vie poetnih relacija koje se
pretrauju.
Postoje dva tipa operacija nad relacionim modelom podataka:
Operacije relacione algebre
Operacije relacionog rauna
Operacije relacione algebra su opisane u narednom poglavlju. Relacioni raun

nije predmet ovog materijala odnosno uvodnog kursa iz baza podataka.
4.8 Pregled terminologije osnovnih koncepata

Ovaj odeljak pokuava da ukratko da pregled prethodno opisanih koncepata
relacionog modela i time dodatno omogui razjanjenje terminologije.
Ono to je oigledno je da je relacija u relacionom modelu, odgovara pojmu
tabela u bazi podataka. U svetu baza podataka, obino se koriste jedni termini kada
se govori o relacionom modelu, a drugi kada se govori o bazi podataka, odnosno
implementaciji relacionog modela. Uporedni prikaz termina i njihovog znaenja
dat je na slici 4-5.
Relacioni model
Baza podataka
Relacija
Tabela
Torka
Vrsta
Atribut
Kolona
Domen atributa
Tip podatka kolone
ema relacije
Opis tabele
Slika 4-5. Ekvivalentni skup pojmova kod baza podataka
Na slici 4-6. su prikazane neformalne definicije, odnosno objanjenja osnovnih

koncepata relacionog modela podataka. Vie o ovim konceptima i o relacionom
modelu podataka moete nai u literaturi koja je navedena na kraju ovog
materijala.
83

Koncept relacionog modela
Objanjenje (neformalni opis)
Relacija
Tabela sa vrstama i kolonama.
Relaciona baza podataka
Kolekcija
normalizovanih
razliitim imenima.
ema relacije
Opis relacije. Sadri ime relacije, imena

atributa i domene atributa.
ema relacione baze podataka
Opis baze podataka. Skup ema relacija i skup

ogranienja, pri emu svaka relacija ima
razliito ime.
Atribut
Odabrana osobina klase entiteta ili klase

poveznika, deo eme relacije; U kontekstu
relacije, neformalno se odnosi na imenovanu
kolonu relacije.
Domen atributa
Specifikacija skupa dozvoljenih vrednosti za

jedan ili vie atributa.
Torka relacije
Jedna vrsta relacije odnosno tabele.
Stepen relacije
Broj atributa iz eme relacije ije vrednosti

relacija sadri.
Kardinalnost relacije
Broj torki koje relacija sadri.
relacija
sa
Slika 4-6. Pregled osnovnih koncepata relacionog modela
4.9 Preslikavanje ER/EER modela u relacioni model

Preslikavanje ER modela u relacioni odvija se u sedam sukcesivnih koraka, a za
preslikavanje dodatnih koncepata EER modela su neophodna jo tri koraka. Nakon
preslikavanja, na osnovu zadatog ER/EER dijagrama baze podataka koji je razvijen
u fazi konceptualnog projektovanja, dobija se ema baze podataka koja sadri
odgovarajue eme relacija. Ove relacije e kasnije biti tabele u bazi podataka koje
e uvati podatke.
Nadalje je opisan postupak preslikavanja korak po korak. Nakon toga dati su
primeri koji ilustruju postupak preslikavanja.
Preslikavanje ER modela u relacioni model

Korak 1. Preslikavanje regularnog tipa entiteta
Za svaki regularni tip entiteta E u ER emi kreira se ema relacije R koja sadri
sve proste atribute i sve proste komponente svih sloenih atributa iz E.
84

Jedan od kljunih atributa iz E se uzima za primarni klju eme relacije R. Ako
je kljuni atribut u E sloen, tada se njegov skup prostih atributa uzima zajedno kao
primarni klju u R.
Korak 2. Preslikavanje slabog tipa entiteta
Za svaki slabi tip entiteta S u ER emi iji je vlasnik tip entiteta E kreira se
ema relacije R koja sadri sve proste atribute iz S i sve proste komponente svih
sloenih atributa iz S.
ema relacije R kao spoljni klju sadri sve atribute primarnog kljua eme
relacije tipa entiteta E.
Za primarni klju eme relacije R uzima se kombinacija primarnog kljua
vlasnika E i parcijalnog kljua slabog tipa entiteta S.
Korak 3. Preslikavanje veza 1:1
Za svaki binarni tip veza R(1:1) u ER emi identifikuju se eme relacija S i T
koje odgovaraju tipovima entiteta koji participiraju u R. Bira se jedna od ove dve
eme relacija, recimo S, i u nju se kao spoljni klju ukljuuje primarni klju eme
relacije T.
Za emu relacije S treba birati tip entiteta koji totalno participira u R. Kao
atribute eme relacije S treba ukljuiti sve proste atribute i sve proste komponente
sloenih atributa tipa veze R.
Moe se izabrati i alternativno reenje po kome se formira zajednika ema
relacije za tipove entiteta S i T u koju se ukljuuju svi atributi iz obe eme relacije.
Ovo je reenje dobro kada oba tipa entiteta totalno participiraju u R i kada ne
participiraju ni u jednom drugom tipu veze.
Korak 4. Preslikavanje veza 1:N
Za svaki binarni tip veze R(1:N) u ER emi identifikuje se ema relacije S koja
participira na N strani. U S se kao spoljni klju ukljuuje primarni klju eme
relacije T koja predstavlja tip entiteta koji participira na 1 strani.
Kao atribute eme relacije S treba ukljuiti sve proste atribute i sve proste
komponente sloenih atributa tipa veze R.
Korak 5. Preslikavanje veza M:N
Za svaki binarni tip veze R(M:N) u ER emi kreira se nova ema relacije S. U S
se kao spoljni kljuevi ukljuuju primarni kljuevi ema relacija koje predstavljaju
tipove entiteta koji participiraju u R.
Kombinacija ovih spoljnih kljueva formira primarni klju eme relacije S. U
emi relacije S se takoe ukljuuju svi prosti atributi i sve proste komponente
sloenih atributa tipa veze R.
85

Korak 6. Preslikavanje vievrednosnog atributa
Za vievrednosni atribut A tipa entiteta E ili tipa poveznika P kreira se nova
ema relacije R koja sadri atribut A i primarni klju K eme relacije kojom je
predstavljen tip entiteta E ili tip veze P.
Za primarni klju eme relacije R bira se kombinacija A i K. Ako je
vievrednosni atribut sloen, ukljuuju se sve njegove proste komponente.
Korak 7. Preslikavanje n-arnog tipa veze
Za svaki n-arni tip veze R, n > 2, kreira se nova ema relacije S. U S se kao
spoljni kljuevi ukljuuju primarni kljuevi ema relacija koje predstavljaju tipove
entiteta koji participiraju u R.
Kombinacija ovih spoljnih kljueva formira primarni klju eme relacije S.
U emi relacije S se takoe ukljuuju svi prosti atributi i sve proste komponente
svih sloenih atributa n-arnog tipa veze.
Ako neki tip entiteta E participira u R sa ogranienjem (min,max) i ako je
max=1, tada se kao primarni klju eme relacije S moe uzeti onaj spoljni kljuni
atribut kojim se ema relacije S referencira na emu relacije kojom je predstavljen
tip entiteta E.
Preslikavanje dodatnih koncepata EER modela u relacioni model

Korak 8. Preslikavanje veze potklasa/natklasa (generalizacija/specijalizacija)
Postoje etiri alternative za preslikavanje veze potklasa/natklasa:
a) Kreirati eme relacija za svaku natklasu sa svim atributima natklase.
Kreirati eme relacija za svaku potklasu sa svim atributima potklase i
kljuem natklase, koji je istovremeno i klju potklasa.
b) Kreirati eme relacija za sve potklase tako da sadre sve atribute
natklase i sve atribute potklase. Primarni klju eme relacije potklase je
primarni klju njegove natklase. Treba uoiti da kod ove opcije ne
kreira ema relacije za natklasu.
c) Kreirati jednu emu relacije koja sadri sve atribute natklase i sve
atribute potklasa i atribut tip koji svojom vrednou odreuje potklasu.
d) Kao pod (c) s tim to se dodaju atributi t1, t2, ..., tn (n je broj potklasa,
dom(ti, i=1,n)=Boolean ) koji odreuju pripadnost potklasi. Ova opcija
je pogodna za preklapajue potklase, mada se moe primeniti i za
disjunktne potklase.
Korak 9. Preslikavanje deljivih potklasa
Obino ide primena koraka 8(a).
86

Korak 10. Preslikavanje kategorija
Kreirati emu relacije za kategoriju i eme relacija za njene natklase. Ako su
kljuevi razliiti, za kategoriju se generie novi atribut koji predstavlja surogat
klju; ema relacije sadri sve atribute kategorije i surogat klju. Dodati surogat
klju svakoj emi relacije koja predstavlja natklasu kategorije koja se preslikava.
Primeri
Primer: Preslikavanje ER modela baze podataka PREDUZEE
ER dijagram za bazu podataka PREDUZEE dat je na slici 4-7. Ovaj dijagram
je dobijen projektovanjem baze podataka na osnovu zahteva iz odgovarajueg
primera u prethodnom poglavlju.
Sbroj
SSlovo
Prezime
LIme
(1,1)
Adresa
Ime
Sektor
Radnik
Pol
BrojRadnika
LD
MatBr
RADNIK
podredjen
(0,1)
NADZOR
SEKTOR
DatumPost
Rukovodilac
(0,1)
Izvrsilac
(1,n)
Sati
(1,1)
RUKOVODI
(0,n)
Sektor-nosilac
RukovodiSektorom
DatRodj
nadredjen
(0,n)
Lokacija
Naziv
(4,n)
RADI-U
JE-NOSILAC
NosiProjekat
(1,1)
(1,n)
RADI-NA
(0,n)
Radnik
PROJEKAT
Projekat
ZAVISI_OD
Lokacija
Naziv
Broj
(1,1)
Zavisi
Ime
Srodstvo
CLAN-PORODICE
DatRodj
Pol
Slika 4-7. ER dijagram baze podataka PREDUZEE
Postupak preslikavanja ER modela baze podataka PREDUZEE u relacioni

model podataka:
Korak 1: Preslikavanje regularnih tipova entiteta.
Regularni tipovi entiteta u bazi podataka PREDUZEE su RADNIK,
SEKTOR i PROJEKAT, tako da se u ovom koraku dobijaju relacije sa
istim imenima. Za svaku relaciju oznaeni su i primarni kljuevi.
RADNIK
LIME
SSLOVO
SEKTOR
NAZIV
PREZIME
MATBR
DATRODJ
POL
PLATA
ADRESA
SBROJ
PROJEKAT
NAZIV LOKPR
BROJPR
87

Korak 2: Preslikavanje slabih tipova entiteta
Jedini slabi tip eniteta je LAN-PORODICE, pa se za njega kreira nova
relacija, koja pored atributa slabog tipa entiteta sadri i klju relacije
vlasnika, MATBRRAD. Primarni klju je zajedno klu relacije vlasnika
i parcijalni klju, odnosno MATBRRAD i IME.
CLAN-PORODICE
MATBRRAD IME
POL
DATRO
SRODSTVO
Korak 3: Binarne veze (poveznici) tipa 1:1.

Jedina veza 1:1 je RUKOVODI, u kojoj potpuno uestvuje tip entiteta
SEKTOR, kome se dodaje atribut DAT_POST (datum postavljanja
rukovodioca) i spoljni klju MATBRR (matini broj rukovodioca) koji
predstavlja primarni klju relacije RADNIK.
SEKTOR
NAZIV
SBROJ
MATBRR
DATPOST
Korak 4: Binarne veze tipa 1:N.

Binarne veze tipa 1:N su RADI_U i NADZOR, u kojima se na N strani
javlja RADNIK, kao i veza JE_NOSILAC u kojoj je na N strani
PROJEKAT. Relacijama na N strani se dodaju kao spoljni kljuevi
primarni kljuevi relacije na 1 strani.
RADNIK
LIME
SSLOVO
PROJEKAT
NAZIV
LOKPR
PREZIME
MATBR
DATRODJ
POL
PLATA
ADRESA
MATBROJS
BRSEK
BROJPR
BRS
Korak 5: Binarna veza M:N

Binarna veza RADI-NA izmeu tipova entiteta RADNIK i PROJEKAT
je tipa M:N, tako da se za nju formira posebna relacija RADI-NA u
koju se kao spoljni kljuevi ukljuuju primarni kljuevi relacija
RADNIK i PROJEKAT. Ova dva spoljna kljua formiraju primarni
klju relacije RADI-NA.
RADI-NA
MBR
BRPR
SATI
Korak 6: Vievrednosni atributi

Atribut LOKACIJA tipa entiteta SEKTOR je vievrednosni. Za njega se
formira relacija LOK-SEKTOR koja kao spoljni klju ima primarni
klju relacije SEKTOR.
LOK-SEKTOR
BRS
LOKACIJA
Korak 7: U ER modelu baze podataka PREDUZEE ne postoje n-arne veze.

88

Koraci 8-10: U ER modelu baze podataka PREDUZEE nisu korieni dodatni
koncepti proirenog modela.
Kompletni relacioni model baze podataka PREDUZEE dobijen nakon

preslikavanja ER modela prikazan je na slici 4-8.
RADNIK
LIME
SSLOVO
PREZIME
MATBR
DATRODJ
PLATA
PROJEKAT
NAZIV
LOKPR
BROJPR
BRS
SEKTOR
NAZIV
MATBRR
DATPOST
SBROJ
CLAN_PORODICE
MATBRRAD
IME
POL
LOK_SEKTOR
BRS
LOKACIJA
SRODSTVO
POL
ADRESA
MATBROJS
BRSEK
DATRO
RADI_NA
MBR
BRPR
SATI
Slika 4-8. Relacioni model baze podataka PREDUZEE
Primer: Preslikavanje ternarnog tipa veze

Na slici 4-9. je dat deo ER dijagrama koji sadri ternarnu vezu i dobijeni
relacioni model. U relaciju koja se kreira za ternarnu vezu je pored kljueva
svih relacija koje uestvuju u vezi dodat i atribut veze Koliina.
DOBAVLJA
PROJEKAT
SNABDEVA
DIme
PrIme
Koliina
DEO
BDela
Slika 4-9. Deo eme koji sadri ternarnu vezu SNABDEVA
89

Preslikavanje:
Za ternarni tip poveznika SNADBEVA relaciona ema sadri kljueve atribute
iz sva tri tipa entiteta odnosno odgovarajuih relacija, kao i atribut veze
KOLIINA:
DOBAVLJA
DIME
...
SNABDEVA
DIME
DEO
DEO
BDELA
PROJEKAT
PRIME
...
...
KOLIINA
PRIME
Primer: Preslikavanje ER modela baze podataka VIDEO_KLUB

ER dijagram za bazu podataka VIDEO_KLUB dat je slici 53. Ovaj dijagram je
dobijen projektovanjem baze podataka na osnovu zahteva iz odgovarajueg
primera u prethodnom poglavlju.
Preslikavanjem ER modela baze podataka VIDEO_KLUB dobija se relaciona
ema ove baze podataka prikazana na slici 4-10.
FILM
BROJ
NASLOV
TIP
AA_NOM
AA_NAG
KRITIKA
GODINA
REISER
REISER
BROJ
IME
PREZIME
DATUM_RO
IME
PREZIME
ADRESA
DATUM_SM
LAN
BROJ
NAJAM
BONUS
DATUM
GLUMAC
BROJ
IME
PREZIME
DATUM_RO
MESTO_RO
DATUM_SM
KASETA
KOD
DATUM_NABAV
FILM
BROJ_IZNAJM
LAN
DATUM_IZNAJM
IGRA
BR_FILM
BR_GLUMAC
ULOGA
Slika 4-10. Relacioni model baze podataka VIDEO_KLUB
90
5 RELACIONA ALGEBRA
Relaciona algebra je formalni jezik za relacioni model. Zasniva se na

matematikoj teoriji skupova. Jako je vana poto obezbeuje formalnu osnovu za
operacije relacionog modela, a takoe se koristi kao osnova za implementaciju i
optimizaciju upita u RDBMS-u. Neki od njenih koncepata su ugraeni u SQL
standardni upitni jezik za relacioni model podataka.
Relaciona algebra je definisana sa ciljem da se obezbedi skup operacija
pogodan za iskazivanje upita, odnosno selekciju i dobijanje podataka iz relacione
baze podataka. Sekvenca operacija relacione algebre formira izraze relacione
algebre iji je rezultat takoe relacija, koja predstavlja rezultat upita nad bazom
podataka. Kao to je napomenuto u prethodnom poglavlju, bitna karakteristika
operacija u relacionom modelu (samim tim i operacija relacione algebre) jeste da se
relacije i operandi i rezultat operacija. Samim tim, kod izraza relacione algebre,
koji se sastoje od operatora i operanada, operandi su relacije (skupovi torki ili
reprezentanti skupova torki), a rezultat primene izraza je takoe relacija.
Za iskazivanje upita putem relacione algebre koriste se dve vrste operatora:
Specijalni operatori relacione algebre:

o
selekcija,
projekcija,
spoj,
deljenje.
Standardni operatori matematike teorije skupova:

o
unija,
presek,
razlika,
Dekartov proizvod.

Osnovni skup operacija relacione algebra ine sledee operacije:
Selekcija
Projekcija
Unija
Razlika
Dekartov proizvod
Preostale operacije su iz takozvanog proirenog skupa poto se mogu izvesti

primenom formalnih pravila iz operacija osnovnog skupa. Proireni skup operacija
relacione algebra ine:
Presek
Deljenje
Spoj i varijante spoja: Unutranji, Spoljanji (Levi, Desni ili Potpuni) i

Polu spoj
5.1 Selekcija
Selekcija je operacija kojom se iz relacije izdvajaju one torke koje imaju
zadatu vrednost specificiranih atributa. Atributi i njihove vrednosti po kojima se
vri selekcija se zadaju uslovom selekcije. Na slici 5-1. prikazane su dve torke
dobijene selekcijom sa zadatim uslovom da radnici rade u sektoru 10.
radnik
MBR
LIME
LD
SBR
2203
2817
2932
2995
3305
3515
3819
MIRA
PERA
MIRA
GOCA
LAZA
JOVAN
VLADA
50 000
40 000
35 000
18 000
60 000
20 000
65 000
10
20
10
30
40
20
30
Slika 5-1. Rezultat selekcije su izdvojene vrste relacije
Operacija selekcije se oznaava na sledei nain:
<uslov selekcije> (<ime relacije>)

Selekcija se vri iz zadate relacije <ime relacije>. Atributi i njihove vrednosti po
kojima se vri selekcija se zadaju uslovom selekcije. Rezultat ove operacije je
92
Relaciona algebra
relacija koja sadri one torke poetne relacije koje zadovoljavaju zadati <uslov
selekcije>.
Redosled atributa rezultantne relacije ekvivalentan je redosledu atributa relacije
nad kojom je primenjena selekcija.
Vodite rauna da je selekcija unarna operacija! Kao i kod svih ostalih operacija
relacione algebre, rezultat primene selekcije nad nekom relacijom je takoe
relacija.
Uslov selekcije moe da bude prost i sloeni.
Prost uslov selekcije je logiki izraz oblika:
Ai Aj
Ai C
C Ai
gde je:
{<, =, >, <=, >=, !=}, Ai i Aj imena atributa relacije nad kojom se
selekcija izvodi, C konstanta koja uzima vrednosti iz domena atributa Ai.
Sloeni uslov selekcije se sastoji od prostih uslova selekcije koji su povezani
operatorima , i , odnosno AND, OR i NOT.
Primer: Selekcija
Iz relacije radnik nad emom relacije RADNIK (MBR,LIME,LD,SBR)
izabrati sve radnike koji ispunjavaju uslov:
(a) LD > 20000
(b) LD > 20000 i SBR = 10
Odgovarajue operacije relacione algebre su:
(a) LD>20000 (radnik)
(b) LD>20000 AND SBR=10 (radnik)
Rezultat primene ovih operacija je dat na slici 5-2. Data je poetna relacija
radnik i rezultat primene operacije selekcije pod (a) i (b).
93
radnik
MBR
LIME
LD
SBR
2203
2817
2932
2995
3305
3515
3819
MIRA
PERA
MIRA
GOCA
LAZA
JOVAN
VLADA
50 000
40 000
35 000
18 000
60 000
20 000
65 000
10
20
10
30
40
20
30
LD>20000 (radnik)
(a)
LD>20000 AND SBR=10 (radnik)
MBR
LIME
LD
SBR
2203
2817
2932
3305
3819
MIRA
PERA
MIRA
LAZA
VLADA
50 000
40 000
35 000
60 000
65 000
10
20
10
40
30
(b)
MBR
LIME
LD
SBR
2203
2932
MIRA
MIRA
50 000
35 000
10
10
Slika 5-2. Primer rezultata primene selekcije
Selekcija je komutativna operacija, odnosno vai:
<uslov1> ( <uslov2> (r)) = <uslov2> ( <uslov1> (r))

Posledica komutativnosti je da sekvenca operacija selekcije u nekom upitu
relacione algebra moe biti primenjena u bilo kom redosledu ili zamenjena jednom
operacijom selekcije sa sloenim uslovom:
<uslov1> ( <uslov2> ( <uslovn> (r)) =

<uslov1> AND <uslov2> AND AND <uslovn> (r)
5.2 Projekcija
Projekcija je operacija kojom se iz relacije izdvajaju kolone koje odgovaraju
atributima po kojima se vri projekcija i kojom se iz tako dobijene relacije
eliminiu jednake torke. Na slici 5-3. prikazana je projekcija dve kolone relacije
radnik MBR i LD.
94
Relaciona algebra
radnik
MBR
LIME
LD
SBR
2203
2817
2932
2995
3305
3515
3819
MIRA
PERA
MIRA
GOCA
LAZA
JOVAN
VLADA
50 000
40 000
35 000
18 000
60 000
20 000
65 000
10
20
10
30
40
20
30
Slika 5-3. Primer primene operacije projekcije
Operator projekcije se oznaava sa:
<lista atributa>(<ime relacije>)

gde <lista atributa> definie za koje atribute se vri projekcija nad zadatom
relacijom <ime relacije>. Rezultat projekcije je relacija. Redosled atributa
rezultantne relacije definisan je listom atributa projekcije.
Navedeno je da se kod projekcije eliminiu jednake torke. Ova osobina je
posledica toga da operacije relacione algebra tretiraju relacije kao skupove, pa se i
u ovom sluaju podrazumeva da se kod projekcije vrednosti jedne ili vie kolona
prikazuju samo razliite vrednosti. Kod upitnog jezika SQL to nije sluaj!
Projekcija nije komutativna operacija.
Primer: Projekcija
Projektovati po atributima LIME, SBR relaciju radnik definisanu nad emom
relacije RADNIK(MBR, LIME, LD, SBR):
LIME, SBR(radnik)
Projekcija istih atributa, ali u obrnutom redosledu:
SBR, LIME (radnik)

Rezultat projekcije u oba sluaja je prikazan na slici 5-4. Iz primera se vidi da
kod operacije projekcije navoenja atributa odreuje redosled atributa u
rezultujuoj relaciji.
95
LIME,SBR(radnik) SBR,LIME (radnik)
radnik
MBR
LIME
LD
SBR
LIME
SBR
SBR
LIME
2203
2817
2932
2995
3305
3515
3819
MIRA
PERA
MIRA
GOCA
LAZA
JOVAN
VLADA
50 000
40 000
35 000
18 000
60 000
20 000
65 000
10
20
10
30
40
20
30
MIRA
PERA
GOCA
LAZA
JOVAN
VLADA
10
20
30
40
20
30
10
20
30
40
20
30
MIRA
PERA
GOCA
LAZA
JOVAN
VLAD A
Slika 5-4. Rezultat projekcije nad relacijom radnik
5.3 Preimenovanje
Preimenovanje je operacija koja omoguava promenu imena relacije i imena
atributa u rezultantnoj relaciji. Ova operacija se moe koristiti u upitima relacione
algebre kako bi rezultati upita bili razumljiviji.
Operator preimenovanja se oznaava sa:
<novo ime relacije i/ili atributa>(<ime relacije>)

Primer: Operacija Preimenovanje
Varijante operacije preimenovanja, pri emu je s novo ime relacije
r(A1,A2,,An), B1,B2,,Bn su nova imena atributa A1,A2,,An.
Preimenovanje imena relacije i imena atributa
s(B1,B2,,Bn)(r)
Preimenovanje imena relacije
s(r)
Preimenovanje atributa relacije
(B1,B2,,Bn)(r)
5.4 Operacije relacione algebre iz teorije skupova

Operacije relacione algebra iz teorije skupova praktino su standardne
matematike operacije nad skupovima: unija, presek, razlika i Dekartov proizvod.
Poto se radi o operacijama nad skupovima, relacija rezultat ovih operacija sadri
samo razliite torke.
Unija relacija r i s je skup torki koje pripadaju relacijama r ili s ili obema. Uslov
za obavljanje ove operacje je da su r i s unijski kompatibilne relacije. To znai da
obe relacije imaju isti stepen i da su domeni korespodentnih atributa u obe relacije
isti. Rezultujua relacija ima imena atributa prve relacije.
96
Relaciona algebra
Unija je komutativna i asocijativna operacija:
rs=sr
(r s) t = r (s t)
Razlika relacija r i s je skup torki koje pripadaju relaciji r ali ne pripadaju
relaciji s. Relacije r i s treba da su unijski kompatibilne. Rezultujua relacija ima
imena atributa prve relacije.
Razlika nije komutativna operacija:
rss-r
Presek relacija r i s je skup torki koje pripadaju obema relacijama. Uslov za
obavljanje ove operacije je da su r i s unijski kompatibilne relacije. Rezultujua
relacija ima imena atributa prve relacije.
Presek se moe izraziti preko razlike na sledei nain:
r s = r - (r - s)
Presek je komutativna i asocijativna operacija:
rs=sr
(r s) t = r (s t)
Primer: Skupovne operacije
Prikazati rezultat primene operacija razlike, unije i preseka relacija student i
kandidat.
Unija (rezultat primene je prikaza na slici 5-5a):
student kandidat
(zbog komutativnosti je isto to i kandidat student)
Presek (rezultat primene je prikaza na slici 5-5b i 5-5c):
student kandidat
kandidat student
Razlika (rezultat primene je prikaza na slici 5-5d):
student kandidat (ili kandidat student)
97
student
IND
kandidat
IME
DATR
GRAD
ID
IME
DATR
GRAD
1211
PERA
010971
NI
1213
VERA
130872
NI
1213
VERA
130872
NI
1217
VERA
220371
SV
1215
MILA
150171
LE
1223
MIKA
101072
LE
1217
VERA
220371
SV
(a) student kandidat
(b) student - kandidat
IND
IME
DATR
GRAD
IND
IME
DATR
GRAD
1211
PERA
010971
NI
1211
PERA
010971
NI
1213
VERA
130872
NI
1215
MILA
150171
LE
1215
MILA
150171
LE
(c) kandidat - student
1217
VERA
220371
SV
ID
IME
DATR
GRAD
1223
MIKA
101072
LE
1223
MIKA
101072
LE
(d) student kandidat

IND
IME
DATR
GRAD
1213
VERA
130872
NI
1217
VERA
220371
SV
Slika 5-5. Primer primene skupovnih operacija
Dekartov proizvod relacija r i s nad emama relacije R(A1, A2, ..., An) i S(B1,
B2, ..., Bm) je relacija q nad emom relacije Q(A1, A2 ,..., An, B1, B2, ..., Bm)
koju ine torke duine n+m, gde prvih n komponenti ini torku u r, a drugih m
torku u s.
Relacija q ima po jednu torku za sve kombinacije torki, jedna iz r, jedna iz s.
Ako r ima Kr torki i ako s ima Ks torki, tada q ima Kr x Ks torki.
Dekartov proizvod se oznaava na sledei nain:
q=rxs
Primer: Dekartov proizvod
Dekartov proizvod relacija r i s, r x s, je prikazan na slici 5-6. Rezultat
predstavlja skup torki koje su dobijene tako to je napravljena kombinacija prve
torke iz r sa svim torkama iz s (prve etiri torke u rezultatu), pa nakon toga
kombinacija druge torke iz r sa svim torkama iz s (poslednje etiri torke u
rezultatu).
98
Relaciona algebra
rxs
A
a1
a2
B
b1
b2
D
d1
d2
d3
E
e1
e2
e3
C
c1
c2
A
a1
a1
a1
a2
a2
a2
B
b1
b1
b1
b2
b2
b3
C
c1
c1
c1
c2
c2
c2
D
d1
d2
d3
d1
d2
d3
E
e1
e2
e3
e1
e2
e3
Slika 5-6. Primer primene Dekartovog proizvoda
Deljenje ili kolinik relacija r i s, u oznaci r/s, je skup torki t koje se javljaju u r
u kombinaciji sa svim torkama iz s. Deljenje nije iz osnovnog skupa operacija i
moe se izraziti pomou operacija projekcija, Dekartov proizvod i razlika (, x, -)
na sledei nain:
y (r) -> q1
y ((s x q1) - r) -> q2
q1 - q2 -> q
Deljenje nije ni komutativna, ni asocijativna operacija.
Primer: Deljenje
Rezultat deljenja relacija r i s je prikazan na slici 5-7. U rezultatu su vrednosti
za atribut A: a1 i a5 poto se jedino one pojavljuju u r u kombinaciji sa b1 i b2.
r/s
a1
a1
a3
a4
a4
a5
a5
b1
b2
b1
b2
b3
b1
b2
b1
b2
a1
a5
Slika 5-7. Primer primene operacije deljenja
99
5.5 -spoj
-spoj je spoj relacija r i s nad emama relacija R(A1, A2, ..., An) i S(B1,
B2,...,Bm) je relacija q nad emom Q(A1, A2, ..., An, B1, B2, ..., Bm) koja ima po
jednu torku za svaku kombinaciju torki, jedna iz r i jedna iz s, kad god ova
kombinacija zadovoljava uslov spoja (to je glavna razlika u odnosu na Dekartov
proizvod).
Za spoj se koristi oznaka:
r
<uslov spoja>
gde je <uslov spoja> izraz formata:

<uslov> ... <uslov>
<uslov> je oblika Ai Bj {=, <, <=, >, >=, !=}
Torke iji atributi spoja imaju NULL vrednost ne pojavljuju se u rezultatu.
Varijacije -spoja:
Equijoin (ekvi spoj) je spoj gde je uslov spoja oblika Ai = Bj.
Natural join (prirodni spoj) je ekvi spoj gde je iz rezultata iskljuen

jedan od dva jednaka atributa (Ai ili Bj)
Prva varijanta spoja je na osnovu jednakosti atributa i koristiete je uglavnom u

upitima relacione algebre. Ona je osnova za implementaciju spoja kod SQL
upitnog jezika.
Prirodni spoj se oznaava sa * ili se navodi simbol za spoj ali bez navoenja
uslova. Da bi prirodni spoj mogao da se primeni, oba atributa u uslovu spoja
moraju da imaju isto ime. Ukoliko to nije sluaj koristimo operaciju
preimenovanja.
Primer: Operacija spoja.
Rezultat spoja relacija radnik i projekat na osnovu uslova spoja koji definie
da su vrednosti broja sektora SBR iste u obe relacije je dat na slici 5-8:
radnik
radnik.SBR=projekat.SBR
projekat
Redosled atributa u rezultujuoj relaciji je takav da se navode atributi iz relacije

radnik (koja je s leve strane operacije), a nakon toga iz relacije sektor. Atribut
SBR se pojavljuje na dva mesta.
100
Relaciona algebra
projekat
radnik
MBR
LIME
LD
SBR
PBR
PNAZIV
SBR
PRUK
2203
2817
2932
2995
3305
3515
3819
MIRA
PERA
MIRA
GOCA
LAZA
JOVAN
VLADA
50 000
40 000
35 000
18 000
60 000
20 000
65 000
10
20
10
30
40
20
30
100
200
300
400
PC
HOST
LAN
VIPX
10
20
30
40
2203
3305
3819
2817
radnik
projekat
radnik.SBR=projekat.SBR
MBR
IME
LD
SBR
PBR
PNAZIV
SBR
PRUK
2203
2932
2817
3515
2995
3819
3305
MIRA
MIRA
PERA
JOVAN
GOCA
VLADA
LAZA
50 000
35 000
40 000
20 000
18 000
65 000
60 000
10
10
20
20
30
30
40
100
100
200
200
300
300
400
PC
PC
HOST
HOST
LAN
LAN
VIPX
10
10
20
20
30
30
40
2203
2203
3305
3305
3819
3819
2817
Slika 5-8. Primer primene operacije spoja
Primer: Prirodni spoj

Rezultat prirodnog spoja relacija radnik i projekat:
radnik
projekat
radnik * projekat
Atribut na osnovu kog se vri prirodni spoj je SBR njegov naziv je isti u obe
relacije, a uslov je jednakost vrednosti ovih atributa u obe relacije. Rezultat
primene prirodnog spoja ove dve relacije je prikazan na slici 5-9. Redosled
atributa u rezultujuoj relaciji je kao kod spoja - navode se najpre atributi iz
relacije radnik (koja je s leve strane operacije), a nakon toga iz relacije sektor.
U ovom sluaju se atribut SBR pojavljuje samo na jednom mestu koje mu je
odreeno pozicijom u relaciji koja se navodi s leve strane operacije prirodnog
spoja.
101
radnik * projekat
radnik
projekat
MBR
IME
LD
SBR
PBR
PNAZIV
PRUK
2203
2932
2817
3515
2995
3819
3305
MIRA
MIRA
PERA
JOVAN
GOCA
VLADA
LAZA
50 000
35 000
40 000
20 000
18 000
65 000
60 000
10
10
20
20
30
30
40
100
100
200
200
300
300
400
PC
PC
HOST
HOST
LAN
LAN
VIPX
2203
2203
3305
3305
3819
3819
2817
Slika 5-9. Primer primene prirodnog spoja
Spoljanji spoj je operacija kod koje se navodi uslov spoja koji se odnosi na
jednakost atributa kao kod klasinog spoja. Ipak, rezultat primene zavisi od tipa
spoljanjeg spoja, i moe da sadri torke iz neke od relacija iako one ne ispunjavaju
uslov jednakosti. Ovaj spoj moe da ima sledee varijante:
Levi (Left) spoj rezultat zadrava sve torke iz leve relacije bez obzira
na to da li ispunjavaju uslov spoja, i one relacije s desne strane koje
ispunjavaju zadati uslov. Za one torke s leve strane koje ne ispunjavaju
uslov, u desni deo se upisuje NULL vrednost.
Desni (Right) spoj - rezultat zadrava sve torke iz desne relacije bez
obzira na to da li ispunjavaju uslov spoja, ali se u levi deo upisuje NULL
vrednost za sve one koje ne ispunjavaju uslov.
Puni (Full) spoj - rezultat zadrava sve torke bez obzira na to da li

ispunjavaju uslov spoja. Neuparene torke dobijaju NULL vrednost na
suprotnoj strani.
Spoljanji spojevi se obeleavaju na slian nain kao spoj, s tim da se u simbolu

dodaju oznake u obliku dve crtice s leve, desne strane ili obostrano, da bi se
oznailo da li se radi o levom, desnom ili punom spoju:
Oznaka za levi spoljanji spoj:
Oznaka za desni spoljanji spoj:
Oznaka za puni, odnosno obostrani spoljanji spoj:
Spoljanji spoj se moe koristiti da bi se dobila unija torki u sluaju kada

relacije nisu unijski kompatibilne. Ova operacija obezbeuje uniju svih torki
relacija koje su parcijalno kompatibilne odnosno kada su samo neki atributi unijski
kompatibilni.
102
Relaciona algebra
5.6 Funkcije agregacije

Funkcije agregacije su funkcije koje omoguavaju da se na osnovu vrednosti
zadatih atributa korienjem tih funkcija dobiju odnosno izraunaju nove vrednosti
(tzv. agregirane vrednosti).
Oznaavanje funkcije agregacije u relacionoj algebri:
<atributi grupisanja>F<lista funkcija>(r)
gde su:
<atributi grupisanja> lista atributa relacije r
<lista funkcija> je lista parova (<funkcija><atribut>)
<funkcija> je funkcija koja se primenjuje i moe biti:
SUM - za izraunavanje sume vrednosti navednog atributa,
AVERAGE - za izraunavanje prosene vrednosti,
MAXIMUM - za odreivanje maksimalne vrednosti,
MINIMUM - za odreivanje minimalne vrednosti,
COUNT - za brojanje ne-nultih vrednosti zadatog atributa.
Primer: Funkcije agregacije
Za svaki sektor nai broj radnika u tom sektoru i prosean lini dohodak.
SBR
F COUNT MBR, AVERAGE LD(radnik)
U datom reenju grupisanje je izvreno po broju sektora SBR i za svaku grupu

torki koja ima istu vrednost SBR (odnosno za svaki sektor) se vri izraunavanje
prosene vrednosti plate (AVERAGE LD) i broje se radnici (COUNT MBR).
Funkcija COUNT broji ne-nulte vrednosti navedenog atributa.
5.7 Primeri upita u relacionoj algebri

Upiti u relacionoj algebri se grade korienjem osnovnih operacija. Poto je
rezultat primene svake operacije relacija, ona moe biti ulaz za narednu operaciju u
upitu. Rezultat sekvence primenjenih operatora (odnosno upita relacione algebre)
je takoe relacija koja sadri eljene podatke iz poetnih relacija. Upiti relacione
algebre se mogu napisati na vie alternativnih naina, a u navedenim primerima
prikazano je samo po jedno reenje.
Primeri upita se odnose na dve eme relacionih baza podataka: prva koja sadri
eme relacija koje se odnosi se na studente, predmete i vezu izmeu njih koja
103

definie koje je predmete neki student izabrao, a druga se odnosi na bazu podataka
PREDUZEE.
ema baze podataka o studentima:
STUDENT(Indeks, Ime, Adresa, Mentor)
PREDMET(ID, Naziv)
IZABRAO(Indeks,IDP)
Primer 1. Prikazati Indekse i Imena studenata
Indeksi i imena studenata su podaci koji se uvaju u relaciji STUDENT pa se
upit svodi na primenu operacije projekcije koja vraa razliite vrednosti parova
Indeks, Ime:
Indeks, Ime(STUDENT)
Primer 2. Prikazati ID-ove onih predmeta koje je izabrao neki student (izabrani
predmeti)
Poto se u ovom primeru ne trae dodatni podaci o predmetima, ve samo ID, a
informacije o predmetima koji su izabrani od studenata su u relaciji IZABRAO,
upit se svodi na jednostavnu primenu projekcije:
IDP(IZABRAO)
Primer 3. Podaci o studentima iji je mentor Petar Petrovi
Svi podaci o studentima su u relaciji STUDENT, ukljuujui i podatke o
mentoru. Potrebno je izdvojiti one torke iz ove relacije koje zadovoljavaju uslov
na je vrednost atributa Mentor Petar Petrovi. Primer se odnosi na oiglednu
primenu selekcije:
Mentor = Petar Petrovi (STUDENT)

Primer 4. Prikazati nazive izabranih predmeta.
Informacije o izabranim predmetima su u relaciji IZABRAO, a nazivi predmeta
su u relaciji PREDMET. Da bi ste prikazali nazive izabranih predmeta potrebno
je uraditi spoj ove dve relacije i nakon toga projekcijom izdvojiti samo traene
attribute:
Naziv(PREDMET
104
ID = IDP
IZABRAO)
Relaciona algebra
Primer 5. Prikazati ID-ove predmeta koje nije izabrao nijedan student

U ovom sluaju projekcijom ID iz relacije PREDMET dobiemo razliite
vrednosti ID-ova svih predmeta. Projekcijom IDP iz relacije IZABRAO
dobiemo razliite identifikatore samo izabranih predmeta. Razlika ova dva
skupa (svi predmeti i izabrani predmeti) su predmeti koje nije izabrao nijedan
student:
ID(PREDMET) - IDP(IZABRAO)
Za vebu: Studenti koji nisu izabrali nijedan predmet.
Primer 6. Nazivi predmeta koje nije izabrao nijedan student.
Deo reenja ovog upita je reenje prethodnog upita. Rezultat smetamo u
privremenu relaciju r:
r ID(PREDMET) - IDP(IZABRAO) - prethodni primer
Da bi prikazali nazive predmeta potrebno je uraditi spoj sa relacijom
PREDMET koja uva nazive, i nakon toga projekcijom izdvojiti samo razliite
nazive predmeta:
Naziv( r
r.ID=Predmet.ID PREDMET)
Primer 7. Imena studenata i nazivi predmeta koje su izabrali.

Privremena relacija r1 sadri predmete koje su studenti izabrali; r2 sadri podatke
o studentima i predmetima koje su izabrali (praktino ova dva spoja su veza
studenata i predmeta preko relacije IZABRAO). Na kraju, projekcijom su
prikazana imena studenata i nazivi predmeta:
r1 PREDMET
r2 r1
ID=IDP
IZABRAO
r1.Indeks=Student.Indeks
STUDENT
r Ime,Naziv(r2)
Primer 8. Indeksi studenata koji su izabrali predmet Baze podataka.
Pomona relacija r1 sadri podatke o predmetu Baze podataka, koji se spojem sa
IZABRAO povezuju sa studentima koji su ga izabrali:
r1 Naziv = Baze podataka (PREDMET)
105

r2 r1
ID=IDP
IZABRAO
r Indeks(r2)
Za vebu: Indeksi studenata koji su izabrali predmet Baze podataka ILI
predmet Strukture podataka.
Ideja 1: promena uslova kod selekcije
Ideja 2: reenje iz prethodnog primera (2 puta) + unija
Za vebu: Indeksi studenata koji su izabrali oba predmeta:Baze podataka i
Strukture podataka.
ema baze podataka PREDUZEE:
RADNIK(MBR,LIME,PREZIME,DRODJ,ADRESA,LD,SBR,SEF)
SEKTOR(SBR,SNAZIV,SLOK,MBR)
PROJEKAT(PBR,PNAZIV,SBR,PRUK)
RADINA(MBR,PBR,SATI)
LAN_PORODICE(MBR,IME,DRODJ,SRODSTVO)
Primer 1: Nai ime, prezime i adresu svih radnika koji rade u sektoru 5
Reenje:
r LIME, PREZIME,ADRESA SBR=5 (radnik)
Primer 2: Nai imena, prezimena i adrese svih radnika koji rade u sektoru
PROIZVODNJA u Niu
r1 SNAZIV=PROIZVODNJA AND SLOK=NI(sektor)
r2 r1
r1.SBR=radnik.SBR radnik
r MBR,LIME,LD(r2)
Primer 3: Nai ime, prezime i adresu svih radnika koji rade u sektoru
RAZVOJ
106
Relaciona algebra
Reenje
r1 SNAZIV=RAZVOJ (sektor)
r2 radnik
radnik.SBR=r1.SBR r1
r LIME, PREZIME,ADRESA (r2)

Drugi oblik upita
r LIME, PREZIME,ADRESA(radnik
radnik.SBR=sektor.SBR ( SNAZIV=RAZVOJ
(sektor)))
Primer 4: Nai imena radnika koji rade na svim projektima koje nadgleda
sektor broj 5
PROJEKAT(PBR,PNAZIV,SBR,PRUK)
RADINA(MBR,PBR,SATI)
Reenje:
r1 SBR=5(projekat) projekti koje nadgleda sektor 5
r2 r1
r1.PBR = radina.PBR
r3 r2
r2.MBR = radnik.MBR
radina
radnik - radnici koji rade na projektima sek 5
r4 LIME,PREZIME (r3)
Primer 5: Nai imena radnika koji imaju 2 i vie izdravanih lica
LAN_PORODICE(MBR,IME,DRODJ,SRODSTVO)
Reenje:
r1(MBR,BROJ_IZL) MBR F COUNT IME(LAN_PORODICE)
r2 BROJ_IZL2(r1)
r LIME,PREZIME(r2
r2.MBR = radnik.MBR
radnik)
107
6 NORMALIZACIJA
I NORMALNE
FORME
Jedan od ciljeva relacionog modela je da se obezbedi zatita podataka od estih

i potencijalno opasnih reorganizacija baze podataka, to se moe postii tako to se
spreavaju anomalije odravanja podataka u bazi podataka i omoguava bolje
korienje informacija iz baze podataka. U ostvarivanju tih ciljeva znaajnu ulogu
ima normalizacija i normalne forme.
Da bi se obezbedilo da relacija nema neeljena svojstva koja mogu da postoje
meu atributima, u procesu normalizacije se ograniavaju odnosi meu atributima
na odreene tipove zavisnosti. Za relaciju u kojoj takvi odnosi vae kaemo da je
normalizovana, odnosno da se nalazi u normalnoj formi.
Normalizacija se oslanja na pojmove i definicije iz relacionog modela, kao to
su funkcionalne zavisnosti, zatvara skupa funkcionalnih zavisnosti i sl. Zbog toga
je u ovom poglavlju, u prvom odeljku dat pregled definicija koje se odnose na
funkcionalne zavisnosti. Nakon toga, nakon kratkog odeljka koji navodi
potencijalne probleme koji mogu da se jave zbog postojanja anomalija u auriranju
i razloga zato je potrebna normalizacija, sledi odeljak u kome su date definicije
normalnih formi i postupka normalizacije.
6.1 Funkcionalne zavisnosti

Funkcionalna zavisnost (FZ) je prvi tip ogranienja definisan u okviru
relacionog modela podataka. FZ specificira ogranienja izmeu dva skupa atributa
u relacionoj bazi podataka i koriste se za specifikaciju odreenih, u praksi vrlo
znaajnih, normalnih formi organizacije baze podataka, kao i za specifikaciju
algoritama transformacije postojeih ema relacija u eljene normalne forme.
Podsetnik:
ema relacije R(A;F) je definisana na osnovu:
skupa atributa A, i
skupa funkcionalnih zavisnosti F kojima se specificiraju ogranienja

Funkcionalna zavisnost je izraz oblika f: XY, gde f predstavlja naziv
funkcionalne zavisnosti, a X i Y su skupovi atributa iz posmatrane eme relacije.
esto se koristi skraena notacija: XY. Znaenje navedenog izraza XY se
moe interpretirati na dva naina:
da Y funkcionalno zavisi od X ili
da X funkcionalno odreuje Y
To dalje znai da se svakom elemenu iz domena atributa X, dom(X) moe

pridruiti najvie jedan element iz domena atributa Y, dom(Y).
Primer: Funkcionalna zavisnost atributa
Data je funkcionalna zavisnost:
Grad, Adresa PotanskiKod
Ako u relaciji postoje atributi Grad, Adresa i Potanski kod, oigledna
funkcionalna zavisnost je da naziv grada i adresa zajedno funkcionalno
odreuju potanski kod, odnosno da potanski kod funkcionalno zavisi od
naziva grada i adrese.
Definicija funkcionalne zavisnosti
Funkcionalna zavisnost se moe definisati na sledei nain:
Preduslov: Neka je r relacija nad emom relacije R(A;C) i neka su X i Y
podskupovi skupa atributa A={A1, A2, ..., An}
U emi relacije R postoji funkcionalna zavisnost f: X Y ako i samo ako je
svakom elementu iz dom(X) pridruen najvie jedan element iz dom(Y),
odnosno, na osnovu vrednosti atributa X moe se odrediti odgovarajua
vrednost atributa Y.
Posmatrano na nivou torki, funkcionalna zavisnost XY znai da za bilo koje
dve torke t1 i t2 iz r vai implikacija:
t1[X] = t2[X] => t1[Y] = t2[Y]
Kao posledica toga, ako je t1[X] = t2[X] (odnosno vrednost atrubuta X u torci
t1 jednaka je vrednosti istih atributa u torci t2) , tada mora biti t1[Y] = t2[Y],
odnosno vrednosti atrubuta Y u odgovarajuim torkama moraju da budu iste.
Praktino, vrednost komponente Y torke u relaciji r zavisi od vrednosti
komponente X, odnosno vrednost komponente X funkcionalno odreuje vrednost
komponente Y.
Primer: Funkcionalne zaviosnosti u relaciji
Zadata je ema relacije POSETILAC({IME,ADRESA};{IMEADRESA})
110
Normalizacija i normalne forme

Funkcionalna zavisnost IMEADRESA moe se tumaiti na sledei nain:
Vrednost atributa IME na jedinstven nain odreuje vrednost atributa

ADRESA
Ako u instanci relacije posetilac(POSETILAC) postoji torka

<GAGA, Niavska 14>,
tada kad god se u nekoj instanci relacije posetilac(POSETILAC) pojavi

vrednost GAGA u koloni IME, u koloni ADRESA ove torke mora biti
vrednost Niavska 14
Primer: Znaenje funkcionalne zavisnosti
U emi relacije:
RADPROJ(MBR,RIME,SATI,PBR,PNAZIV,PLOK,SBR,PRUK)
na osnovu semantike atributa mogu da se prepoznaju sledee funkcionalne
zavisnosti:
1. MBR RIME
2. MBR SBR
3. PBR {PNAZIV, PLOK}
4. {MBR,PBR} SATI
5. PBR PRUK
Znaenje navedenih FZ, redom, se moe protumaiti na sledei nain:
1. Matini broj radnika jednoznano odreuje ime radnika
2. Matini broj radnika jednoznano odreuje broj sektora u kome
radnik radi
3. Broj projekta jednoznano odreuje naziv i lokaciju projekta
4. Matini broj radnika i broj projekta jednoznano odreuju vreme
(SATI) angaovanja radnika na projektu
5. Broj projekta jednoznano odreuje rukovodioca projekta
Semantika ovih ogranienja je:
1. Svaki radnik ima jedinstven matini broj (MBR)
2. Radnik moe raditi samo u jednom sektoru (SBR)
3. Svaki projekat ima jedinstven broj projekta (PBR)
4. Radnik moe biti angaovan na vie projekata odreeni broj sati
5. Svaki projekat ima samo jednog rukovodioca
111
6.2 Izvoenje funkcionalnih zavisnosti

Projektanti baze podataka specificiraju funkcionalne zavisnosti koje su
semantiki oigledne u toku projektovanja baze podataka. U svim relacijama nad
emom relacije R u kojoj vai skup funkcionalnih zavisnosti F postoje i mnoge
druge FZ. U realnom sistemu nije mogue specificirati sve mogue FZ za datu
situaciju, zato to je neke teko prepoznati, a druge mogu biti na neki nain
prikrivene.
Ove FZ se mogu izvesti iz FZ koje postoje u F i koje su definisane u fazi
projektovanja baze podataka. Za dobijanje tih novih funkcionalnih zavisnosti na
osnovu postojeih je potreban alat za izvoenje. Da bismo uveli takav alat
potrebno je upoznati sledee koncepte:
zatvara skupa FZ
pravila izvoenja FZ
zatvara skupa atributa
6.2.1 Zatvara skupa funkcionalnih zavisnosti

Definicija:
Zatvara ili zatvaranje skupa funkcionalnih zavisnosti F, u oznaci F+, je skup
funkcionalnih zavisnosti sadran u F i skup svih funkcionalnih zavisnosti koje
se mogu izvesti iz F.
Za potrebe izvoenja novih FZ iz postojeih definiu se pravila ili aksiome
izvoenja funkcionalnih zavisnosti. Kardinalni broj zatvaraa je vrlo veliki ak i za
mali broj FZ u F i za mali broj atributa.
Pravila (aksiome) izvoenja funkcionalnih zavisnosti su:
P1 (Refleksivnost) : Ako je YX, tada vai XY
P2 (Proirenje) : Ako je XY i ZW, tada vai XWYZ
P3 (Tranzitivnost) : Ako je XY i YZ, tada vai XZ
P4 (Dekompozicija) : Ako je XYZ, tada vai XY i XZ
P5 (Unija) : Ako XY i XZ, tada vai XYZ
P6 (Pseudotranzitivnost): Ako XY i YWZ, tada vai XWZ
gde su X,Y,W i Z podskupovi skupa atributa A eme relacije R(A;F) i gde XY
oznaava uniju skupova X i Y.
112

Pravila P1-P3 se nazivaju Armstrongove aksiome. Pravilo 1 dovodi do
definisanja tzv. trivijalnih FZ. To su zavisnosti za koje vai da je desna strana FZ
podskup leve strane.
U pravilu P2, ako je Z=W, tada ovo pravilo postaje:
Ako je XY, tada vai XZYZ
Ako je W prazan skup u Pravilu 6, tada ono prelazi u tranzitivnost.
Na osnovu pravila unije (P5) sledi da se svaki skup funkcionalnih zavisnosti F
moe zameniti ekvivalentnim skupom G u kojem se na desnoj strani svake FZ
nalazi samo 1 atribut.
Iscrpnom primenom pravila izvoenja P1-P6 na skup funkcionalnih zavisnosti F
dobija se skup funkcionalnih zavisnosti F+.
U nastavku je dat pseudokod algoritma za nalaenje zatvaraa F+. Algoritam
kao ulaz ima skup atributa eme relacije i skup inicijalnih funkcionalnih zavisnosti,
a rezultat je skup F+. Inicijalno, zatvara ima vrednost poetnog skupa FZ, i u
narednim koracima se proiruje. Algoritam za svaku FZ iz aktulene vrednosti F +
(do tog koraka generisane FZ kao i poetni skup) primenjuje pravilo refleksivnosti
i dodaje rezultat u F+ (koraci 4 i 5). Za svaki par FZ pokuava da primenom
tranzitvnosti generie nove FZ i da ih doda u F+. Postupak se ponavlja sve dok se
generiu nove FZ.
Algoritam za nalaenje F+
Ulaz: Skup atributa A={A1, A2,..., An}, i
Skup funkcionalnih zavisnosti F={f1, f2,..., fm} eme relacije R(A;F)
+
Izlaz: F (funkcionalno zatvaranje skupa F)

1. F+ := F;
2. repeat
3. za svaku funkcionalnu zavisnost f u F+
4.
primeniti pravilo refleksivnosti i pravilo proirenja na f ;
5.
dodati rezultujue funkcionalne zavisnosti u F+ ;
6. za svaki par funkcionalnih zavisnost fi i fj u F+

7.
8.
ako se fi i fj mogu kombinovati korienjem tranzitivnosti

dodati rezultujuu funkcionalnu zavisnost u F+ ;
9. until (ne menja se F+)

113
6.2.2 Zatvara skupa atributa

Definicija:
Zatvara skupa atributa X (gde je XA) u odnosu na skup funkcionalnih
zavisnosti F je skup atributa Y koje funkcionalno odreuje X:
X+F = {Y | XYF+}
Zatvara skupa atributa ima vie primena:
Za proveru da li je X super klju eme relacije: Proveravamo da li X+

sadri sve atribute eme relacije.
Za proveru da li funkcionalna zavisnost XY vai u F: Proveravamo da

li je YX+.
Kao alternativni nain za izraunavanje F+: Za svako XA eme relacije

R(A;F) nalazimo X+ i za svako YX+ dodajemo u F+ funkcionalnu
zavisnost XY.
Algoritam za nalaenje zatvaraa X+ skupa atributa X zadate eme relacije R

podrazumeva da postupak krene od skupa X, i vri se provera svih funkcionalnih
zavisnosti iz F. Ako leva strana posmatrane FZ predstavlja podskup do tada
generisanog zavaraa skupa atributa, onda se zatvara proiruje skupom atributa sa
desne strane te FZ. Postupak se ponavlja sve dok postoje promene, odnosno sve
dok se dodaju novi atributi u X+.
Algoritam za nalaenje X+
Ulaz: Konaan skup atributa A eme relacija R(A;F),skup funkcionalnih
zavisnosti F nad A i podskup X skupa A
Izlaz : X+ (zatvaranje X u odnosu na F).
1. X+:=X;
2. repeat
3.
staroX+:= X+;
4. za svaku FZ YZ u F
5.
ako YX+ tada X+ := X+ Z;
6. until (X+ = staroX+)
114

Primer: Nalaenje X+
U emi relacije (klju je prikazan na uobiajeni nain, podvlaenjem imena
kljunih atributa):
RADPROJ = (MBR, RIME, SATI, PBR, PNAZIV, PLOK)
postoje sledee funkcionalne zavisnosti :
f1:{MBR, PBR} -> SATI
f2: MBR -> RIME
f3: PBR -> {PNAZIV, PLOK}
Prema gornjem algoritmu dobija se redom, za zatvarae skupa atributa X1, X2 i
X3, gde je: X1 = {MBR}, X2 = {PBR}, X3 = {MBR, PBR}:
Za X1= {MBR}, polazimo od skupa {MBR} i posmatramo sve FZ. Jedino f2
s leve strane ima atribut MBR koji je podskup poetnog skupa, pa
zatvarau dodajemo atribute s desne strane ove FZ, a to je RIME. Nakon
ovog koraka nema vie promena u zatvarau, pa je to kraj postupka:
X1 = {MBR}, X1+ = {MBR, RIME}
Za X2= {PBR}, polazimo od skupa {PBR} i posmatramo sve FZ. Jedino f3 s
leve strane ima atribut PBR koji je podskup poetnog skupa, pa zatvarau
dodajemo atribute s desne strane ove FZ, a to su PNAZIV i PLOK. Nakon
ovog koraka nema vie promena u zatvarau, pa je to kraj postupka:
X2 = {PBR}, X2+ = {PBR, PNAZIV, PLOK}
Za X3= {MBR, PBR}, polazimo od skupa {MBR, PBR} i posmatramo sve
FZ. Sve date FZ sa leve strane imaju atribute koji su podskup poetnog
skupa, pa zatvarau dodajemo atribute s desne strane sve tri FZ (tri prolaza
kroz repeat petlju algoritma):
X3 = {MBR, PBR}, X3+ = {MBR, PBR, SATI, RIME, PNAZIV, PLOK}
6.3 Klju eme relacije

Definicija:
Neka
je
R({A1,A2,...,An};F)
X{A1, A2, ..., An}
ema
relacije
neka
je
X je klju eme relacije R ako i samo ako ima sledea svojstva:

S1. Svojstvo identifikacije: X funkcionalno odreuje sve atribute eme
relacije, tj. {X Ai l i=1, 2 ,..., n}
115

S2. Svojstvo minimalnosti: Nijedan pravi podskup od X nema tu osobinu,
tj. za X" X vai {X"-/-> Ai l i=1,2,...,n}
Iz definicije kljua relacije sledi da svaka relacija ima barem jedan klju, a to je
skup svih atributa A = {A1, A2, ..., An}.
Ako za neko X {A1, A2, ..., An} vai samo svojstvo S1 iz definicije kljua,
tada X predstavlja super kju relacije R. Treba uoiti da super klju sadri klju
relacije. Moe se rei da je klju relacije njen minimalni i stoga neredundantni
super klju.
Ako skup kljueva K eme relacije R(R;F) ima vie od jednog elementa, tada su
svi oni kljuevi kandidati. Jedan od kljueva kandidata se bira za primarni klju
eme relacije.
Primer: Klju eme relacije
U emi relacije RADNIK(MBR, LIME, LD, SBR), {MBR} je jedini klju
kandidat, tako da je on istovremeno i primarni klju.
U emi relacije RADNIK(MBR,JMB, LIME, LD, SBR) , kljuevi kandidati su
{MBR,JMB} ali je MBR izabran za primarni klju
Primarni klju je klju koji je izabran da jedinstveno identifikuje entitete
predstavljene relacijom. Stoga nijedan od njegovih atributa nesme nikada imati
nedefinisanu (null) vrednost. Svaka ema relacije mora imati primarni klju.
Atribut Ai eme relacije R je primarni (kljuni) atribut ako je lan primarnog
(bilo kog) kljua relacije zadate emom R. Ostali atributi Aj Ai eme relacije R su
neprimarni (sporedni, nekljuni).
Primer: Primarni i neprimarni atributi
U emi relacije RADPROJ atributi MBR i PBR su primarni (kljuni), dok su svi
ostali neprimarni (sporedni, nekljuni)
Zavisnost kljua
Ako je K jedan klju eme relacije (A;F), tada vai funkcionalna zavisnost
KA. Ova se funkcionalna zavisnost naziva zavisnou kljua.
Primer: Zavisnost kljua
Ako je zadata ema relacije R({A,B,C,D,E};{ABC,CDE,BD,E A}) i
ako je A klju ove eme relacije, tada u ovoj relaciji postoji sledea zavisnost
kljua: AA,B,C,D,E
116

Algoritam za nalaenje jednog kljua je jednostavan i svodi se na primenu
odnosno odreivanje zatvaraa skupa atributa. Algoritam inicijalno poinje sa
skupom svih atributa eme relacije R i nakon toga za svaki atribut vri proveru da li
je deo kljua ili se moe izbaciti. Ova provera se vri tako to se odredi zatvara
aktuelnog skupa atributa bez posmatranog atributa (K-X). Ako se za zatvara (KX)+ dobije skup svih atributa relacije R, tada se posmatrani atribut X moe izbaciti
iz kljua. Naredni koraci podrazumevaju ponavljanje postupka tako to se u
svakom od njih posmatra po jedan od preostalih atributa. Na kraju postupka
odreen je jedan klju zadate eme relacije.
Algoritam za nalaenje jednog kljua
Ulaz: ema relacije (R;F); skup atributa R i skup funkcionalnih zavisnosti F
nad skupom atributa R
Izlaz: Klju K eme relacije (R;F)
Metoda: Algoritam nalazi samo jedan klju K za zadati skup atributa R i zadati
skup FZ F nad skupom R
1. K := R;
2. Za svaki atribut X u K
{ izraunati (K-X)+ u odnosu na F;
ako (K-X)+ sadri sve atribute u R
tada K := K-{X} };
Primer: Odreivanje jednog kljua
Za zadatu emu relacije (R;F) nai jedan klju, gde je:
R=(A,B,C,D,E), i
F=( ABC,
CDE,
BD,
E A)
Primena algoritma, opisana po koracima:
1. K={A,B,C,D,E} inicijalno, potencijalni klju se sastoji od svih atributa
2. Iz K izbacujemo atribute redom
Iz K izbacujemo atribut A, provera da li je A deo kljua:
117

Izraunavamo {K-A}+F, tj. {K-A}+ F ={B,C,D,E,A};
(CD odreuje E, ali E je ve u kljuu; B odreuje D koji je
takoe u kljuu, jedino se zbog poslednje FZ doda A)
{K-A}+ sadri sve atribute iz R,
tako da je K:= K-A :={B,C,D,E};
Iz K={B,C,D,E} izbacujemo B
(sada u K nema atributa A koji je izbaen u prethodnom koraku!)
Izraunavamo {K-B}+F, tj. {K-B}+ F ={C,D,E,A,B};
{K-B}+ sadri sve atribute iz R,
K :=K-B, tj. K={C,D,E};
Iz K izbacujemo atribut C
Izraunavamo {K-C}+F, tj. {K-C}+ F ={D,E,A,B,C};
{K-C}+ sadri sve atribute iz R,
K :=K-C, tj. K={D,E};
Iz K izbacujemo atribut D
Izraunavamo {K-D}+F, tj. {K-D}+ F ={E,A,B,C,D};
{K-C}+ sadri sve atribute iz R, pa
K:=K-D, tj. K ={E};
Iz K izbacujemo atribut E
Izraunavamo {K-E}+F, tj. {K-E}+ F =;
{K-E}+ ne sadri sve atribute iz R, pa K ostaje nepromenjeno, tj. K ={E};
3. KRAJ algoritma: Klju zadate eme relacione je {E}
Algoritam za nalaenje svih kljueva eme relacije se takoe oslanja na zatvara
skupa atributa i odgovara prethodnom algoritmu, ali je zahtevniji postupak je
potrebno ponoviti za svaki podskup akupa atributa eme relacije R.
Algoritam za nalaenje svih kljueva eme relacije
Ulaz: ema relacije (R;F)
Izlaz: Skup kljueva SK eme relacije (R;F)
118

1. SK := ;
2. do trai_klju Ki (XR) // za svaki podskup skupa atributa R
if R=X+F then // svojstvo identifikacije
do redukcija (AX)
if A{X-A}+ then X={X-A} endif
// svojstvo
minimalnosti
enddo redukcija
Ki=X
Dodati Ki u SK
endIf
3. enddo trai_klju Ki
Primer: Odreivanje svih kljueva
Zadata je ema relacije (R;F), gde je
R=(A,B,C,D,E) i F=(ABC,CDE,BD,E A)
Nai sve kljueve ove relacije.
Ulaz: R=(A,B,C,D,E) i F=(ABC,CDE,BD,E A)
1. SK=
2. Ispitujemo da li svojstvo kljua ima svaki podskup skupa atributa R, tj.:
{A}, {B}, {C},{D},{E}, {A,B},{A,C}, {A,D}, {A,E}, {B,C}, {B,D},
{B,E}, {C,D}, {C,E}, {D,E},{A,B,C},{A,B,D}, {A,B,E},{A,C,D}
{A,C,E},{A,D,E} {B,C,D},{B,C,E},{B,D,E}, {C,D,E}, {A,B,C,D},
{A,B,C,E},{A,B,D,E},{A,C,D,E},{B,C,D,E}
3. KRAJ algoritma.
Izlaz: SK={A, E,BC,CD}
Vani pojmovi koje emo u narednom poglavlju kod normalizacije pomenuti i
koristiti, a odnose se na FZ su potpuna i parcijalna funkcionalna zavisnost, kao i
tranzitivna zavisnost.
Potpuna i parcijalna funkcionalna zavisnost
Neka su X i Y skupovi atributa. Funkcionalna zavisnost X Y je potpuna ako
izbacivanjem bilo kog atributa A iz X ova zavisnost vie ne postoji.
119

Ako postoji atribut A koji se moe izbaciti iz X, a da se funkcionalna zavisnost
X Y zadri, onda je ova funkcionalna zavisnost parcijalna.
Primer: Potpuna i parcijalna FZ
U emi relacije STUDENT(BRIND, JMB, IME GODINA) funkcionalna
zavisnost:
{BRIND,JMB} IME
nije potpuna budui da vai i funkcionalna zavisnost BRIND IME, odnosno
da broj indeksa funkcionalno odreuje ime studenta.
Tranzitivna funkcionalna zavisnost

Neka su X i Y skupovi atributa eme relacije R. Funkcionalna zavisnost XY u
emi relacije R je tranzitivna zavisnost ako u R postoji skup atributa Z, koji nije
podskup nijednog kljua relacije R, za koji:
vai FZ gde XZ,
ne vai FZ da ZX
vai FZ gde ZY.
Tranzitivna zavisnost postoji kod relacija sa najmanje tri atributa. Kod ovakve
zavisnosti, u odnosu na primarni klju, X treba da bude primarni klju, a Z moe
biti ili kandidat za klju ili njegov deo.
Primer: Tranzitivna FZ
U emi relacije:
RADSEK(RIME, RMBR, DATRODJ, ADRESA, SBR, SNAZIV, SRUK)
postoji tranzitivna funkcionalna zavisnost:
RMBRSBR i SBRSRUK,
a atribut SBR nije podskup nijednog kljua relacije.
6.4 Analiza eme relacione baze podataka

Analiza eme relacione baze podataka je proces odreivanja kvaliteta
projektovanih ema relacija. U teoriji baza podataka definisani su formalizmi za
analizu kvaliteta eme relacije i prevoenje eme relacije u ekvivalentnu, bolju
emu. Postoje dva takva formalizma:
120
Logike zavisnosti i
Normalne forme

Kvalitet projektovane eme relacije se moe posmatrati sa logikog (sa strane
korisnika) i fizikog nivoa (sa strane sistema). Na logikom nivou od eme se
zahteva da bude jasna i laka za razumevanje, a na fizikom nivou od eme se
zahteva da obezbedi aurni skup podataka uz minimalan utroak raunarskih
resursa.
Logike zavisnosti izraavaju injenicu da jedan objekat zavisi od drugih
objekata. U emi relacije R(R;F) nad skupom atributa R=(A1, A2, ..., An) mogu
postojati razliita ogranienja zavisnosti kao posledica osobina i pravila
funkcionisanja realnog sistema koji se ovom relacijom modelira. Najee se sreu
funkcionalne i vieznane zavisnosti.
U procesu poveanja kvaliteta eme relacije mogu da se koriste razliiti faktori,
kao to su redukovanje redundantnih vrednosti u torkama, redukovanje NULL
vrednosti u torkama ili iskljuivanje lanih torki.
Pri obradi relacija mogu da se pojave razliite anomalije. Nepoeljno ponaanje
relacija pri izvoenju operacija auriranja naziva se anomalijom auriranja. Na
osnovu operacije koja indukuje anomalije auriranja razlikujemo:
anomalije unosa
anomalije brisanja
anomalije modifikacije
Anomalije auriranja emo razmotriti na primeru relacije radsek nad emom

relacije RADSEK(RMBR, RIME, RLD, SBR, SNAZIV, SRUK)
Oigledno je da se radi o loe projektovanoj emi relacije (slika 6-1.). Ova
relacija sadri atribute dva entiteta: RADNIK i SEKTOR. Entitet RADNIK je
opisan atributima {RMBR, RIME, RLD}, a entitet SEKTOR atributima {SBR,
SNAZIV, SRUK}.
RADSEK
RMBR RIME RLD
SBR SNAZIV
SRUK
111
Laza
100000
10
Projektni biro 333
222
Mara
60000
10
Projektni biro 333
333
Nada
150000
10
Projektni biro 333
444
Djura
50000
20
Kontrola
null
Slika 6-1. Primer loe projektovane relacije
U emi relacije RADSEK postoje sledee funkcionalne zavisnosti nad

atributima:
121

f1: RMBR {RIME, RLD, SBR}
f2: SBR {SNAZIV, SRUK}
Pri izvoenju operacija nad ovom relacijom javljaju se sve tri vrste anomalija.
Relacija RADSEK(RMBR, RIME, RLD, SBR, SNAZIV, SRUK) poseduje
anomalije unosa koje se ogledaju u sledeem :
U relaciju RADSEK se ne mogu uneti podaci o sektoru ukoliko u taj

sektor nije rasporeen nijedan radnik. Ukoliko bi se takav unos dozvolio
tada bi atributi RMBR,RIME i RLD imali nedefinisanu (NULL)
vrednost, to nije dozvoljeno budui da je RMBR primarni klu relacije
Pri unosu podataka o novom radniku potrebno je, uz konkretne vrednosti

za sve atribute entiteta RADNIK, uneti konkretne vrednosti za sve
atribute entiteta SEKTOR. Pri svakom unosu moramo voditi rauna da
podaci o sektoru budu konzistentni sa ve unetim podacima o tom
sektoru. Ponavljanje podataka o sektoru u torkama svih radnika tog
sektora govori o prisustvu redundance u relaciji.
Opisane anomalije su posledica sledee tranzitivne funkcionalne zavisnosti

meu atributima relacije:
RMBR {RIME, RLD, SBR},
SBR {SNAZIV, SRUK},
Pri emu SBR nije podskup kljua relacije.
Ove anomalije se mogu otkloniti dekompozicijom eme relacije RADSEK tako
da se svaka funkcionalna zavisnost predstavi posebnom relacijom. Rezultat ove
dekompozicije su sledee eme relacija:
RADNIK(RMBR, RIME, RLD, SBR)
SEKTOR(SBR, SNAZIV, SRUK)
Moe se uoiti da svaka nova ema relacije sadri samo atribute jednog entiteta.
anomalije brisanja koje se ogledaju u sledeem:
122
Ako iz relacije RADSEK obriemo sve radnike koji rade u nekom

sektoru, tada emo obrisati i podatke o tom sektoru. Na taj nain se iz
baze podataka gubi informacija o sektorima koji trenutno nemaju
rasporeene radnike. Ova pojava se naziva anomalijom brisanja, a
posledica je ranije pomenute tranzitivne zavisnosti meu atributima
relacije.
U sluaju dekompozicije relacije RADSEK na RADNIK i SEKTOR ne

postoji takav problem. Sada se podaci o svim sektorima memoriu u
posebnoj relaciji i to bez redundance.

anomalije modifikacije koje se ogledaju u sledeem:
Pri promeni vrednosti nekog od atributa entiteta SEKTOR (na primer,

SRUK) potrebno je da se izmeni vrednost atributa SRUK u torkama svih
radnika koji rade u tom sektoru. Dok proces izmene traje postoji
nekozistentnost u podacima. U naem primeru svi radnici koji rade u
sektoru iji atribut SRUK menjamo nee imati istu vrednost za SRUK.
Ova pojava se naziva anomalijom modifikacije, a posledica je ranije
pomenute tranzitivne zavisnosti meu atributima relacije.
Nakon dekompozicije relacija RADSEK na RADNIK i SEKTOR ova

anomalija se gubi. Sada je potrebno da se izmeni vrednost atributa
SRUK samo u tabeli SEKTOR
Razmatrane anomalije auriranja su posledica izvesnih neeljenih struktura

funkcionalnih zavisnosti u emi relacije. Eliminisanjem svih nepoeljnih struktura
funkcionalnih zavisnosti eliminiu se i anomalije auriranja. Za eme relacija koje
su formirane pod ovim restrikcijama kae se da su u normalnoj formi, a postupak
kojim se ema relacije prevodi u neku normalnu formu naziva se normalizacija.
Pri normalizaciji se koristi tehnika dekompozicije. Dekompozicija eme
relacije nije proizvoljna i po pravilu se zasniva na odreenoj strukturi
funkcionalnih zavisnosti meu atributima relacije. Dekompozicijom se svaka
funkcionalna zavisnost meu atributima eme relacije izoluje u posebnu emu
relacije. O normalizaciji i normalnim formama moete da naete vise detalja u
narednim odeljcima.
Dekompozicija relacija je proces zamene eme relacije R(R;F) skupom ema
relacija D={R1(R1;F1), ..., Rm(Rm;Fm)} pri emu moraju biti ispunjeni sledei
uslovi:
1. Ouvanje atributa: Nijedan atribut ne sme biti izgubljen, to znai da se
svaki atribut iz R mora nai bar u jednoj emi Ri dekompozicije D
2. Spoj-bez-gubitaka (neaditivni spoj) - osigurava da se pri prirodnom
spoju relacija dobijenih dekomponovanjem ne jave lane torke. Svojstvo
spoj-bez-gubitaka odnosi se na gubitak informacije, a ne na gubitak torki
3. Ouvanje zavisnosti. Dekompozicija obezbeuje ouvanje zavisnosti ako
su sve funkcionalne zavisnosti eme (R;F) zadrane u D
Dekompozicija je dobra ako je skup ema relacija D ekvivalentan emi R i ako
su iskljuene anomalije.
123

Dekompozicija D={R1,R2} eme relacije R(R;F) ima svojstvo spoj-bezgubitaka u odnosu na skup funkcionalnih zavisnosti F u R ako i samo ako vai:
(Uslov 1) R1R2R1 F+ ili
(Uslov 2) R1R2R2 F+
gde je:
o
Z=R1R2 skup zajednikih atributa obe komponente
(Uslov 1) Z je super klju komponente R1
(Uslov 2) Z je super klju komponente R2
Praktino, ako je R1R2 super klju eme relacije R1 ili R2, tada binarna
dekompozicija ima svojstvo spoj-bez-gubitaka. Za proveru da li je R1R2 super
klju treba koristiti algoritam za nalaenje zatvaraa skupa atributa
6.5 Normalne forme i normalizacija

Nakon projektovanja baze podataka sledi analiza projektovane eme i donoenje
odluke da li je projektovana ema dobra ili je treba dalje doterivati. Da bismo
doneli takvu odluku potrebno je da shvatimo koje probleme, ako ih ima, moe da
proizvede ta ema. Kao vodi za to slue normalne forme koje nam obezbeuju
informaciju o tome koji se problemi nee javiti ako je ema u nekoj normalnoj
formi. U teoriji relacionog modela podataka je predloeno vie normalnih formi.
Normalizacija je postupak kojim se dobija skup relacija sa eljenim osobinama
tj ogranienjima definisanim normalnom formom, kako bi se izbegle anomalije
auriranja. Proces normalizacije je formalna metoda koja se oslanja na
funkcionalnim zavisnostima, odnosno na zavisnostima izmeu kljueva (primarnog
i kandidata) i ostalih atributa relacije.
Osnovne karakteristike funkcionalnih zavisnosti kod normalizacije koje se
podrazumevaju su da:
Definiu jedan-na-jedan relacije izmeu atributa sa leve i atributa sa

desne strane FZ;
Postoje sve vreme;
Netrivijalne su.
Proces normalizacije
Normalizacija se izvrava u vie koraka. Svaki korak odgovara jednoj
normalnoj formi sa eljenim osobinama definisanim normalnom formom. Svaka
sledea normalna forma je stroa i uvodi vie restrikcija, samim tim i smanjuje
mogunost pojave anomalija.
Normalne forme, od onih sa najmanje restrikcija ka onima sa vie restrikcija:
124

1. Prva normalna forma (1NF)
2. Druga normalna forma (2NF)
3. Trea normalna forma (3NF)
4. Boyce-Coddova normalna forma (BCNF)
5. etvrta normalna forma (4NF)
6. Peta normalna forma (5NF) ili normalna forma projekcija-spoj (PJNF)
7. Normalna forma domen-klju (DKNF)
Prve etiri se definiu na osnovu funkcionalnih zavisnosti (FZ) meu
atributima. 4NF, 5NF i DKNF nisu predmet ovog materijala i uvodnog kursa iz
baza podataka. 4NF se zasniva na vieznanim zavisnostima, dok se 5NF zasniva
na zavisnosti spoja. DKNF uzima u obzir sve mogue zavisnosti i ogranienja.
6.5.1 Prva normalna forma

Definicija 1NF:
ema relacije R(R;F) je u prvoj normalnoj formi (1NF) ako i samo ako domeni
relacije R sadre samo proste (atomine) vrednosti.
Proste vrednosti su vrednosti koje se ne mogu dalje deliti ili ako u konkretnoj
situaciji nisu rastavljene na komponente.
U 1NF nisu dozvoljeni vievrednosni i kompozitni atributi i njihove
kombinacije, tj. nisu doputene relacije u relacijama (tzv. ugnedene relacije) ili
relacije kao atributi torki. Ovaj uslov je ukinut kod ugnedenog relacionog modela
i kod objektno-relacionih sistema. Istorijski je 1NF uvedena da bi se onemoguila
pojava vievrednosnih atributa, kompozitnih atributa i njihovih kombinacija.
Primer: 1NF
Nenormalizovana relacija (NNF), data na slici 6-2., se odnosi na klijente, koji
iznajmljuju (rentiraju) objekte na nekoj adresi, plaaju neku rentu vlasniku za
koga se uva ID i ime.
Ova relacija odnosno tabela sadri vie vrednosti atributa koje se ponavljaju
vrednosti atributa ObjekatID, zato to klijent moe da rentira vie objekata, a
samim tim i vrednosti ostalih atributa o objektu, rentiranju i vlasniku. Oigledno se
radi o loe projektovanoj relaciji koja je ovde navedena da bi se ilustrovala prva
normalna forma.
125

KlijentID
ImeK
Petar
Peri
CR76
Aca
Stani
CR56
ObjekatID
AdresaO
rentStart
rentKraj
renta
VlasnikID
PG4
Cvetna, 8
Ni
1-Jul-00
31-Aug-01
150
CO40
Glavna, 10
Beograd
1-Sep-02
1-Sep-02
250
CO93
PG4
Cvetna, 8
Ni
1-Sep-99
10-Jun-00
150
CO40
PG36
Kej, 12
Pirot
10-Oct-00
1-Dec-01
70
CO93
PG16
Glavna, 10
Beograd
1-Nov-02
1-Aug-03
250
CO93
PG16
ImeVlasnika
Tina Tinki
Toa Mani
Tina Tinki
Toa Mani
Toa Mani
Slika 6-2. Nenormalizovana relacija
Test za 1NF treba da izvri proveru da li postoje ovakve anomalije kao u

primeru, odnosno da li su vrednosti svih atributa atomine. Uslov prve normalne
forme definie da kod relacije koja je u 1NF presek jedne kolone i jedne vrste
sadri samo jednu vrednost. Ukoliko nisu, treba izvriti normalizaciju do 1NF.
Test za 1NF:
Proveriti da li su svi atributi eme relacije prosti (atomini).
Ako jesu, tada je ema relacije u 1NF.
Ako nisu, tada ema relacije nije u 1NF. Takvu emu treba prevesti u
1NF, tj. treba izvriti 1NF normalizaciju.
Normalizacija do 1NF obezbeuje da se uklone horizontalne redundance u

podacima, odnosno da ne postoje dve kolone koje uvaju istu informaciju, i ne
postoji kolona koja uva vie od jedne vrednosti. Svaka vrsta u relaciji treba da
bude jedinstvena, to se ostvaruje primarnim kljuem.
1NF normalizacijom treba izdvojiti grupu koja se ponavlja u novu relaciju,
koja sadri taj atribut kao i primarni klju originalne relacije.
Ako je relacija u 1NF obezbeuje se:
Lake zadavanje upita/ureenja
Skalabilnost
Svaka vrsta se moe identifikovati kod auriranja
Prva normalna forma je istorijski znaajna, ali u praksi se esto moe

zanemariti. Naime, ako se konceptualno projektovanje uradi kako treba, relacija je
sigurno u 1NF pa o proveri i normalizaciji ne morate da vodite rauna! Osim toga,
126

kod objektno-relacionih sistema uslov 1NF je ukinut (o tome u narednim
kursevima na viim godinama studija).
6.5.2 Druga normalna forma (2NF)

Druga normalna forma (2NF) se bazira na konceptu potpune funkcionalne
zavisnosti.
Podsetnik:
Funkcionalna zavisnost XY je potpuna funkcionalna zavisnost ako
izbacivanjem bilo kog atributa A iz X ova zavisnost vie ne vai.
Funkcionalna zavisnost XY je parcijalna funkcionalna zavisnost ako se
neki atribut AX moe izbaciti iz X i da zavisnost i dalje vai.
Definicija 2NF:
ema relacije R(R;F) je u drugoj normalnoj formi (2NF) ako svaki atribut A u R
ispunjava jedan od sledea dva uslova:
1) javlja se u nekom kljuu kandidatu
2) nije parcijalno zavisan od nekog kljua kandidata
Interpretacija definicije:
1. ema relacije R(R;F) je u drugoj normalnoj formi (2NF) ako svaki njen
nekljuni atribut nema parcijalnu zavisnost od nekog kljua eme relacije
2. ema relacije R(R;F) je u drugoj normalnoj formi (2NF) ako svaki njen
nekljuni atribut potpuno funkcionalno zavisi od svakog kljua eme relacije R
Test za 2NF
Treba proveriti da li je svaki nekljuni atribut potpuno funkcionalno

zavisi od svakog kljua kandidata.
Kod testiranja na 2NF mogu se iskoristiti specijalni sluajevi koji se odnose na

kljueve kandidate od jednog atributa. Ako se u emi relacije R svi kljuevi
kandidati sastoje samo od jednog atributa ili ako su svi atributi kljuni, onda je
ema relacije R u 2NF.
U praksi, 2NF relacija mora da bude i u 1NF, uz dodatni uslov da svaki
neprimarni atribut potpuno zavisi od kljua. Drugom normalnom formom se
poveava efikasnost uvanja podataka i smanjuje ponavljanja podataka.
127
Primer: Test za 2NF

Data je ema relacije R(R;F). Proveriti da li je ema relacije R(R;F) u 2NF?
R=(A,B,C,D)
F={ABC,BDC, BCA}
2NF test
1. Nai sve kljueve eme relacije (postupak po algoritmu za odreivanje svih
kljueva eme relacije koji je dat u odeljku 6.3):
K={B}
2. Kako jedini klju K={B} sadri jedan atribut, R je u 2NF (specijalni sluaj,
nema parcijalne zavisnosti).
3. KRAJ TESTA
Primer: Test za 2NF
Da li je data ema relacije R(R,F) u 2NF?
R=(A,B,C,D,E)
F={ABC,CDE,BD,E A}
2NF test
1. Nai sve kljueve eme relacije (postupak po algoritmu za odreivanje svih
kljueva eme relacije koji je dat u odeljku 6.3):
K1=A, K2=E, K3=BC,K4=CD
2. Nai sve kljune atribute (atributi koji se deo kljueva, A kao deo K1, E iz
K2, BC iz K3 i CD iz K4):
KA = {A, B,C,D,E}
3. Nai sve nekljune atribute (svi iz eme relacije koji nisu deo nekog kljua
u ovom sluaju ih nema):
NKA = { }
4. Kako su svi atributi kljuni, R je u 2NF (drugi specijalni sluaj).
5. KRAJ TESTA
128

Primer: Test za 2NF
Da li je data ema relacije R(R,F) u 2NF?
R=(S,A,I,P)
F={SIP, S A}
2NF test
1. Nai sve kljueve eme relacije
K=SI
2. Nai sve kljune atribute
KA = {S,I}
3. Nai sve nekljune atribute
NKA = {A,P }
4. Proveriti da li A parcijalno zavisi od kljua SI
Kako je za FZ: SA , S K, to nekljuni atribut A parcijalno zavisi od
kljua SI i ema relacije nije u 2NF.
KRAJ TESTA
Kod normalizacija do druge normalne forme treba eliminisati vertikalnu
redundancu u podacima, odnosno da se ista vrednost ne sme ponavljati u nekoj
vrsti. Podrazumeva se da sve kolone u vrsti moraju da se referenciraju na sve
delove kljua (kompozitni kljuevi).
2NF Normalizacija ima preduslov da relacija bude u 1NF, a nakon toga se vri
eliminacija parcijalnih zavisnosti: ako postoji parcijalna zavisnost, vrimo
dekompoziciju relacije na osnovu te FZ. U posebnu relaciju izdvajamo parcijalno
zavisne atribute i atribut koji ih odreuje (koji postaje klju nove relacije).
Primer: Normalizacija do 2NF
Pokazali smo da ema relacije data u prethodnom primeru:
R=(S,A,I,P)
F={SIP, S A}
nije u 2NF, zbog parcijalne zavisnosti S A.
klju ove relacije je SI.
Normalizacija dekompozicijom se vri na osnovu FZ S A, tako to se od

izdvajaju atributi S i A u novu relaciju R2 (S postaje klju te relacije), a iz
poetne se izbaciju samo parcijalno zavisni atributi (u ovom sluaju samo A):
129

R1=(S,I,P)
R2=(S,A)
Primer: Normalizacija do 2NF
ema relacije (pojava je data na slici 6-2):
KlijentRentira(KlijentID, ObjekatID, rentStart, rentKraj, ImeK,
AdresaO, renta, VlasnikID, ImeVl )
ima sledee FZ:
fz1
KlijentID, ObjekatID rentStart, rentKraj
(Primarni Klju)
fz2
KlijentID ImeK
(Parcijalna zavisnost)
fz3
ObjekatID AdresaO, renta,

VlasnikID, ImeVl
fz4
VlasnikID ImeVl
fz5
KlijentID, rentStart ObjekatID, AdresaO,

rentKraj, rent, VlasnikID, ImeVl
(Parcijalna zavisnost)
(Tranzitivna zavisnost)
(Klju kandidat)
ObjekatID, rentStart
fz6
KlijentID, ImeK, rentKraj
(Klju kandidat)
Eliminacija parcijalnih zavisnosti fz2 i fz3, podrazumeva kreiranje 3 nove

relacije (slika 6-3.), dve na osnovu datih FZ i originalna iz koje se izbaciju
parcijalno zavisni atributi:
Klijent (KlijentID, ImeK), po fz2.
VlasnikObjekta (ObjekatID, AdresaO, renta, VlasnikID, ImeVl), po fz3.
Rentira (KlijentID, ObjekatID, rentStart, rentKraj), ostatak originalne relacije
130

Rentira
Klijent
KlijentID
CR76
CR56
ImeK
Petar Peri
Aca Stani
VlasnikObjekta
KlijentID
CR76
CR76
CR56
CR56
CR56
ObjekatID
PG4
PG16
PG4
PG36
PG16
rentStart
1-Jul-00
1-Sep-02
1-Sep-99
10-Oct-00
1-Nov-02
ObjekatID
AdresaO
renta
VlasnikID
ImeVl
PG4
Cvetna 8, Ni
150
CO40
Tina Tinki
PG16
Glavna 10, Beograd
250
CO93
Toa Mani
PG36
Kej 12, Pirot
70
CO93
Toa Mani
rentKraj
31-Aug-01
1-Sep-02
10-Jun-00
1-Dec-01
1-Aug-03
Slika 6-3. Relacije nakon normalizacije do 2NF
6.5.3 Trea normalna forma (3NF)

Definicija 3NF:
ema relacije R(R;F) je u treoj normalnoj formi (3NF) u odnosu na skup
funkcionalnih zavisnosti F ako za svaku funkcionalnu zavisnost u F+ oblika
XA (XR, A jedan atribut iz R) vai :
1) AX (XA je trivijalna funkcionalna zavisnost), ili
2) X je super klju eme relacije R(R;F), ili
3) A je kljuni atribut eme relacije R(R;F)
Trea normalna forma definie stroe uslove u odnosu na drugu. Podrazumeva
se da je svaka 3NF relacija takoe u 2NF, ali da postoje relacije koje su u 2NF, a
nisu u 3NF.
Trei uslov 3NF definicije je zanimljiv za analizu poto vodi ka anomalijama
unosa, brisanja i modifikacije. Ako FZ XA ne zadovoljava ovaj uslov, razlozi
mogu biti:
1. X je pravi podskup nekog kljua K:
XA je parcijalna zavisnost i par (X,A) je redundantan
2. X nije pravi podskup nijednog kljua
XA je tranzitivna zavisnost zbog lanca zavisnosti KXA ( ne

moemo pridruiti X vrednost kljuu K, a da ne pridruimo A vrednost
X-u).
Na slici 6-4. su prikazeni sluajevi koji se odnose na varijante parcijalne i

tranzitivne zavisnosti.
131
Sluaj 1: A nije u kljuu, XK

parcijalna zavisnost
XA je parcijalna zavisnost
zavisnosti KA
Sluaj 2: A nije u kljuu, XK

tranzitivna zavisnost
KXA
Sluaj 3: A je u kljuu, XK
tranzitivna zavisnost
KXA
Slika 6-4. Ilustracija parcijalnih i tranzitivnih zavisnosti
Sluaj 1 se odnosi na parcijalnu zavisnost koja je, kako smo videli, vana za
2NF i 3NF. Za XA, ako A nije u kljuu i X je podskup kljua K, oigledna je
parcijalna zavisnost A od dela kljua. Sluaj 2 i 3 se odnose na dve varijante
tranzitivne zavisnosti koja je vana za 3NF. Sluaj 2 pokazuje tranzitivnu zavisnost
A od kljua K preko X (za koji postoji FZ XA), koji nije deo kljua ali je
odreen kljuem preko FZ KX. Sluaj 3 se odnosi na varijantu kada je A deo
kljua, a tranzitivno zavisi od njega preko X.
3NF test
Treba proveriti da li svaka zavisnost iz F+ zadovoljava uslov 1) ili 2) ili

3) iz 3NF definicije
Moe se dokazati da je dovoljno proveriti samo funkcionalne zavisnosti iz F (ne

iz F+) tako da ako nijedna od FZ iz F ne naruava 3NF ogranienja, tada to nee
initi nijedna zavisnost iz F+.
Ako F sadri FZ ije desne strane sadre vie od jednog atributa, tada primenom
pravila dekompozicije skup F treba transformisati u skup F gde sve FZ sadre po
jedan atribut sa desne strane.
Trea normalna forma obezbeuje da sve kolone moraju da direktno zavise od
primarnog kljua. U praksi, instanca eme koja nije u 3NF sadri redundantne
informacije koje su posledica FZ. Da bi ema relacije bila u 3NF ona mora da bude
u 2NF. esto, ako je relacija u 2NF, postoje dobre anse da je i u 3NF. Ako ste
dobro odradili konceptualno projektovanje u preslikavanje na relacioni model,
relacije su uglavnom u 3NF. Normalizacijom do 3NF se obezbeuje da nema
redundanse u podacima odnosno nema anomalija koje su posledica tranzitivnih
zavisnosti.
132

3NF normalizacija kao preduslov ima da je relacija u 2NF. Nakon toga se vri
eliminacija tranzitivnih zavisnosti. Elininacija se vri dekompozicijom na osnovu
svake takve zavisnosti. Izdvoje se atributi posmatrane problematine FZ u novu
relaciju zajedno sa kopijom atributa koji ih odreuje/ju (klju te relacije). Iz
originalne relacije se izbace zavisni atributi. Postupak se ponavlja za sve
tranzitivne zavisnosti, s tim da je ulaz pretohodno dobijeni skup ema relacija.
Primer: 3NF normalizacija
Pretohodni primer, u kome je izvrena normalizacija do 2NF, funkcionalne
zavisnosti za Klijent, Rentira i VlasnikObjekta su:
Klijent (KlijentID, ImeK)
fz2
KlijentID ImeK
(Prim.klju)
Rentira (KlijentID, ObjekatID, rentStart, rentKraj)

fz1
KlijentID, ObjekatID rentStart, rentKraj
(Primarni Klju)
fz5
KlijentID, rentStart ObjekatID, rentKraj
(Klju kandidat)
fz6
ObjekatID, rentStart KlijentID, rentKraj
(Klju kandidat)
VlasnikObjekta (ObjekatID, AdresaO, renta, VlasnikID, ImeVl)

fz3
ObjekatID AdresaO, renta,

VlasnikID, ImeVl
fz4
VlasnikID ImeVl
(Primarni Klju)
(Tranzitivna zavisnost)
Tranzitnvna zavisnost fz4 kod eme relacije VlasnikObjekta naruava 3NF.

Normalizacija dekompozicijom na osnovu fz4, VlasnikID ImeVl, uvodi
novu emu relacije Vlasnik (slika 6-5) na osnovu ove FZ koja sadri sve
atribute FZ (klju je leva strana te FZ, u ovom sluaju VlasnikID), a iz
originalne relacije VlasnikObjekta se izbacuju atributi koji su s leve strane
posmatrane FZ (ImeVl):
Klijent (KlijentID, ImeK)
Rentira (KlijentID, ObjekatID, rentStart, rentKraj)
VlasnikObjekta (ObjekatID, AdresaO, renta, VlasnikID) - ostatak originalne
relacije, bez atributa ImeVl
Vlasnik(VlasnikID, ImeVl), na osnovu fz4
133

Rentira
Klijent
KlijentID
CR76
CR56
ImeK
Petar Peri
Aca Stani
VlasnikObjekta
KlijentID
CR76
CR76
CR56
CR56
CR56
ObjekatID
PG4
PG16
PG4
PG36
PG16
ObjekatID
AdresaO
renta
VlasnikID
PG4
Cvetna 8, Ni
150
CO40
PG16
Glavna 10, Beograd
250
CO93
PG36
Kej 12, Pirot
70
CO93
rentStart
1-Jul-00
1-Sep-02
1-Sep-99
10-Oct-00
1-Nov-02
rentKraj
31-Aug-01
1-Sep-02
10-Jun-00
1-Dec-01
1-Aug-03
Vlasnik
VlasnikID
ImeVl
CO40
Tina Tinki
CO93
Toa Mani
Slika 6-5. Relacije nakon normalizacije do 3NF
6.5.4 Boyce-Codd-ova normalna forma (BCNF)

Definicija:
ema relacije R(R;F) je u Boyce-Codd-ovoj normalnoj formi (BCNF) u odnosu
na skup funkcionalnih zavisnosti F ako za svaku funkcionalnu zavisnost u F+
oblika XY (XR,YR) vai:
1) YX (XY je trivijalna funkcionalna zavisnost), ili
2) X je super klju eme relacije
U BCNF sve netrivijalne FZ su oblika:
super klju skup atributa
Iz definicije je oigledan odnos 3NF i BCNF - 3NF sadri trei uslov koji ne
postoji u BCNF, to predstavlja relaksaciju BCNF uslova. Svaka BCNF relacija je
takoe u 3NF, a postoje relacije koje su u 3NF, a nisu u BCNF.
BCNF test
Treba proveriti da li svaka zavisnost iz F+ zadovoljava ogranienje 1) ili

2) iz definicije BCNF
Moe se pokazati da je dovoljno proveriti samo funkcionalne zavisnosti iz F, pa

ako nijedna od FZ iz F ne naruava BCNF ogranienja, tada to nee initi nijedna
zavisnost iz F+.
U praksi, prvi uslov je jednostavno proveriti, pa se metoda za BCNF svodi na
proveru da li sve netrivijalne FZ XY iz F zadovoljavaju BCNF uslov 2), odnosno
da li je X super klju.
134
Algoritam za BCNF test

Ulaz: ema relacije R(R;F)
Izlaz: TRUE ako je ema relacije R(R;F) u BCNF ili
FALSE ako nije
1. Za svaku netrivijalnu FZ XY iz F do
2.
Izraunati X+F // zatvara skupa atributa X u odnosu na F
3.
if (X+F R) then return(FALSE) // X nije super klju, ema

// relacije nije u BCNF
4. enddo
5. return(TRUE) // ema relacije je u BCNF
Primer: Test za BCNF
Proveriti da li je data ema relacije R(R;F) u BCNF, ako je:
R={A,B,C,D} i
F={ABC, BCA, BD}
BCNF test:
Uslov (1): Sve FZ iz F su netrivijalne i treba ih proveriti na Uslov (2).
Uslov (2), za svaku FZ:
1. Proveriti da li FZ ABC zadovoljava BCNF ogranienje
Nai (AB)+F
o
(AB)+F =(A,B,C,D)
Kako je (AB)+F=R, zakljuujemo da ova FZ zadovoljava BCNF

ogranienje (AB je superklju relacije!)
2. Proveriti da li FZ BCA zadovoljava BCNF ogranienje
Nai (BC)+F
o
(BC)+F=(B,C, A,D)
Kako je (BC)+F=R zakljuujemo da ova FZ zadovoljava BCNF

ogranienje
3. Proveriti da li FZ BD zadovoljava BCNF ogranienje

135
Nai (B)+F
o
(B)+F=(B,D)
Kako je (B)F+ R zakljuujemo da ova FZ NE zadovoljava BCNF

ogranienje, ova ema nije u BCNF (zbog BD)
KRAJ TESTIRANJA
Da li je data ema relacije R(R;F) u BCNF?
R=(A,B,C,D)
F={ABC,BDC, BCA}
BCNF test
1. Proveriti da li FZ ABC zadovoljava BCNF uslov 2)
(AB)+=(A,B,C,D)
Kako je (AB)+=R, to je AB super klju, zadovoljava uslov 2)
2. Proveriti da li FZ BD zadovoljava BCNF uslove
(B)+=(A,B,C,D)
Kako je (B)+=R, to je B super klju, zadovoljava uslov 2)
3. Proveriti da li FZ BC zadovoljava BCNF uslove
(B)+=(A,B,C,D)
Kako je (B)+=R, to je B super klju, zadovoljava uslov 2)
4. Proveriti da li FZ BCA zadovoljava BCNF uslove
(BC)+=(A,B,C,D)
Kako je (BC)+=R, to je BC super klju, zadovoljava 2)
5. R je u BCNF, KRAJ TESTA
R=(A,B,C,D,E)
F={AB,BC E, ED A}
BCNF test: Za individualni rad
136

(Odgovor: nije u BCNF)
R=(C,S,Z)
F= {CSZ, ZC}
BCNF test: Za individualni rad
(Odgovor: nije u BCNF)
Ukoliko je ema relacije u BCNF, njena instanca ne sadri redundantne
informacije koje su posledica FZ. Anomalije modifikacije i brisanja se ne javljaju u
BCNF emama. Ipak, relacije sa vie od jednog kljua jo uvek mogu da imaju
anomalije unosa. Da bi se izbegao ovaj problem jedan od kljueva se oznaava za
primarni i zabranjuje se da njegovi atributi imaju NULL vrednosti.
Kod praktinog rada, kao posledica definicije moe da se iskoristi injenica da
je ema relacije u BCNF ako svaki skup atributa koji odreuje neki drugi skup
atributa je klju kandidat.
Razlika izmeu 3NF i BCNF je u tome to za zavisnost AB:
3NF dozvoljava da B moe da bude primarni atribut, dok A nije

kandidat za klju
BCNF zahteva da takva zavisnost moe da postoji samo ako je A

kandidat za klju
BCNF normalizacija se vri na isti nain prepoznaju se FZ koje su razlog da

relacija nije u BCNF i na osnovu njih se vri dekompozicija. Kreira se nova relacija
za svaku takvu FZ i iz poetne se izbace zavisni atributi iz tih FZ.
Primer: Normalizacija do BCNF
Neka je data relacija KlijentIntervju (slika 6-6.) i skup funkcionalnih zavisnosti:
KlijentIntervju (klijentID, intervjuDatum, intervjuVreme, zaposlID, prostorijaBr)
fz1: klijentID, intervjuDatum intervjuVreme, zaposlID, prostorijaBr
fz2: zaposlID, intervjuDatum, intervjuVreme klijentID
fz3: prostorijaBr, intervjuDatum, intervjuVreme klijentID, zaposlID
fz4: zaposlID, intervjuDatum prostorijaBr
137
KlijentIntervju
klijentID
CR76
CR76
CR74
CR56
intervjuDatum
13-May-02
13-May-02
13-May-02
1-Jul-02
intervjuVreme
10.30
12.00
12.00
10.30
zaposlID
SG5
SG5
SG37
SG5
prostorijaBr
G101
G101
G102
G102
Slika 6-6. Relacija KlijentIntervju
Funkcionalna zavisnost fz1 se odnosi na primarni klju relacije, dok fz2 i fz3
definiu kandidate za klju. Problematilna FZ je fz4, poto leva strana nije
klju kandidat i posledica su potencijalne anomalije auriranja (na primer, ako
treba aurirati dve torke tako da se menja vrednost prostorijaBr za zaposlID
SG5 i 13-May-02).
Da bi izvrili normalizaciju, moramo da eliminiemo FZ koja naruava BCNF
(u ovom sluaju fz4) tako to emo da uradimo dekompoziciju po toj FZ na dve
relacije (slika 6-7) Intervju (originalna relacije bez zavisnoh atributa koji su s
desne strane posmatrane FZ, u ovom sluaju prostorijaBR) i ZaposlProstorija
(nova relacija na osnovu fz4):
Intervju (klijentID, intervjuDatum, intervjuVreme, zaposlID)
ZaposlProstorija (zaposlID, intervjuDatum, prostorijaBr)
Intervju
klijentID
CR76
CR76
CR74
CR56
intervjuDatum
13-May-02
13-May-02
13-May-02
1-Jul-02
ZaposlProstorija
zaposlID intervjuDatum
SG5
13-May-02
SG37
13-May-02
SG5
1-Jul-02
intervjuVreme
10.30
12.00
12.00
10.30
zaposlID
SG5
SG5
SG37
SG5
prostorijaBr
G101
G102
G102
Slika 6-7. Relacija KlijentIntervju nakon normalizacije
6.5.5 Denormalizacija
Denormalizacija je postupak koji podrazumeva spajanje relacija u jednu kako bi
se poveala efikasnost nekih upita/pretraga. U praksi se koristi ako se proceni da je
dobitak kod pretrage vei od problema sa anomalijama. Ipak, u tom sluaju se
138

mora dodatno brinuti o integritetu podataka i anomalijama, kao posledici
denormalizacije. Cilj je da se doe do logiki i dalje korektnih, a tehniki
prihvatljivih reenja.
Preporuka: izvriti najpre normalizaciju kako treba, pa tek onda
denormalizaciju ako treba. Koristiti jedino ako ne postoji drugi nain optimizacije
izvrenja upita. Pokuajte sa temp tabelama, UNION-ma, VIEW-ma, ugnjedenim
upitima i sl.
139
7 UPITNI
JEZIK
SQL
Structured Query Language (SQL) predstavlja programski jezik koji je

projektovan za potrebe pretraivanja i upravljanja podacima u Sistemima za
upravljanje relacionim bazama podataka (Relational Database Management
Systems RDBMS), za kreiranje i modifikacija ema relacione baze podataka i za
kontrolu pristupa objektima baze podataka.
Prva verzija programskog jezika SQL razvijena je od strane kompanije IMB
krajem 1970-ih godina. Ova verzija, inicijalno nazvana SEQUEL, je razvijena za
potrebe manipulacije podacima System R sistemu za upravljanje relacionim
bazama podataka.
SQL je formalno standardizovan 1986 godine, od strane American National
Standards Institute (ANSI), pod nazivom SQL-86. Ovaj standard je kasnije
prihvaen id od strane International Organization for Standardization (ISO). Svi
SQL standardi koji su naknadno usvojeni predstavljaju zajednike standarde
organizacija ANSI i ISO.
SQL je programski jezik razvijen sa specifinom namenom . Njegova osnovna
karakteristika je da se radi o deklarativnom jeziku za upravljanje i manipulacijom
podacima u relacionim bazama podataka. SQL omoguava pribavljanje, dodavanje,
auriranje i brisanje podataka u relacionoj bazi podataka. Veina proizvoaa
RDBMS-a proiruje SQL standard dodajui proceduralne elemente, kontrolne
strukture, korisniki definisane tipove podataka i druge elemente. SQL standard
SQL-99 mnoga od ovih proirenja su formalno prihvaena kao delovi SQL jezika u
vidu SQL Persistent Stored Modules (SQL/PSM) (Tabela 1).
Veina proizvoaa relacionih DBMS-ova bezbeuje alat za kreiranje i
izvravanje naredbi SQL jezika. Ovaj alat moe biti obian Command-line
Interface (SQL/CLI) ili alat sa bogatim grafikim interfejsom. Takoe, u veini
sluajeva, je obezbeena programksa podrka koja omoguava da se SQL naredbe
kreiraju i koriste iz drugih programskih jezika.
Sve naredbe SQL jezika se mogu podeliti u dve velike grupe:
1. Data Definition Language (DDL) jezik koji se koristi za definisanje
strukture relacione baze podataka

2. Data Manipulation Language (DML) jezik za pribavljanje I auriranje
podataka u relacionoj bazi podataka.
U nastavku je najpre dat kratak opis baze podataka PREDUZEE koja je
koriena u primerima.
Tabela 1 : Proirenja SQL jezika koja su postala deo standarda
Proizvoa
Ime
Puno ime
ANSI/ISO Standard
SQL/PSM
SQL/Persistent Stored Modules
Interbase/Firebird
PSQL
Procedural SQL
IBM
SQL PL
SQL Procedural Language (implements

SQL/PSM)
Microsoft/Sybase
T-SQL
Transact-SQL
MySQL
SQL/PSM
SQL/Persistent Stored Module (implements

SQL/PSM
Oracle
PL/SQL
Procedural Language/SQL (based on Ada)
PostgreSQL
PL/pgSQL
Procedural
Language/PostgreSQL
Structured Query Language (bazira se na
Oracle PL/SQL)
PostgreSQL
PL/PSM
Procedural
Modules
Language/Persistent
Stored
7.1 Baza podataka PREDUZEE

Baza podataka PREDUZEE je jedan od uobiajenih primera koji se koristi u
literaturi o bazama podataka. ER dijagram ove baze podataka je dat u poglavlju 3,
na slici 3-25, a ema relacione baze podataka dobijena preslikavanjem sa ER
modela na relacioni, na slici 4-4. Na slici 7-1. prikazana je pojava ove baze
podataka koja prikazuje podatke koriene u primerima nadalje.
Tabela RADNIK uva podatke o radnicima preduzea. Za svakog radnika se
pamti matini broj, ime, srednje slovo, prezime, datum roenja, pol, plata, adresa,
matini broj neposrednog rukovodioca i broj sektora u kome radnik radi. Za
primarni klju je izabran matini broj radnika odnosno kolona MATBR. Tabela
ima dva strana kljua: MATBROJS i BRSEK. Kolona MATBROJS referencira
kolonu MatBr u istoj tabeli jer rukovodilac je jedan od radnika (rekurzivna veza).
Kolona BRSEK referencira kolonu SBROJ u tabeli SEKTOR.
Preduzee je podeljeno na vei broj sektora. U tabeli SEKTOR se pamte
sledei podaci o sektorima: broj sektora, naziv sektora, matini broj efa sektora i
datum kada je ef sektora postavljen na svoju dunost. Za primarni klju je izabran
broj sektora odnosno kolona SBROJ. Jedini strani klju je kolona MATBRR
142
Upitni jezik SQL

(predstavlja matini broj rukovodioca) koja referencira kolonu MATBR u tabeli
RADNIK (ef sektora je jedan od radnika u preduzeu).
RADNIK
RADI_NA
SEKTOR
PROJEKAT
CLAN_PORODICE
LOK_SEK
Slika 7-1. Relacija KlijentIntervju nakon normalizacije
Tabela PROJEKAT uva podatke o projektima koji su aktivni unutar

preduzea. Za svaki projekat se pamti: broj projekta, naziv projekta, lokacija
projekta i broj sektora koji je zaduen za projekat. Za primarni klju je izabran broj
projekta odnosno kolona BROJPR. Jedini strani klju je kolona BRS (broj sektora
koji je zaduen za projekat) koja referencira kolonu SBROJ u tabeli SEKTOR.
Tabela CLAN_PORODICE uva sledee podatke o lanovima porodica
radnika: matini broj radnika, ime lana porodice, pol, srodstvo sa radnikom i
datum roenja. Primarni klju je kompozitni i ine ga kolone MATBRRAD i IME.
Strani klju je kolona MATBRRAD (matini broj radnika za koga je lan porodice
vezan) koja referencira kolonu MATBR u tabeli RADNIK.
Tabela LOK_SEK uva podatke o lokacijama na kojima se nalazi odreeni
sektor: broj sektora i naziv lokacije. Primarni klju je kompozitni i ine ga kolone
143

BRS i LOKACIJA. Strani klju je kolona BRS (broj sektora za koji je lokacija
vezana) koja referencira kolonu SBROJ u tabeli SEKTOR.
Tabela RADI_NA predstavlja evidenciju angaovanja radnika na razliitim
projektima. Za svako angaovanje se pamti: matini broj angaovanog radnika,
broj projekta na kome je angaovan i broj radnih sati nedeljno koliko je angaovan
na projektu. Primarni klju je kompozitni i ine ga kolone MATBRRAD i BRPR.
Tabela ima dva strana kljua: MATBRRAD i BRPR. Kolona MATBRRAD
(predstavlja matini broj radnika na koga se odnosi angaovanje) referencira
kolonu MATBR u tabeli RADNIK, a kolona BRPR (broj projekta na kome je
radnik angaovan) referencira kolonu BROJPR u tabeli PROJEKAT.
7.2 SQL naredbe za kreiranje podataka

SQL DDL naredbe se koriste za kreiranje, izmenu i brisanje same relacione
baze podataka kao i objekata koji ine relacionu baze podataka. Centralni objekat
svake relacione baze podataka jeste tabela. Za kreiranje tabele koristi se SQL
naredba CREATE TABLE.
CREATE TABLE <ime_tabele>
(<lista_deklaracija_kolona>
[,<lista_deklaracija_organienja_tabele>]);
<ime_kolone><tip_podatka>[(<duina>)] [<ogranienje_kolone>],
Deklaracija kolone sadri ime kolone, tip podatka kolone, opciono duinu (ako
je neophodna, u zavisnosti od tipa podatka) i opciono, ogranienja za kolonu.
Deklaracije kolona se razdvojaju zapetama. U odeljku Tipovi podataka navedeni
su tipovi podataka koje moete koristiti. Ogranienja za kolonu su opciona i mogu
da sadre specifikaciju predefinisane vrednosti i niz specifikacija ogranienja, to
je detaljnije opisano u odeljku Ogranienja kolona.
Nakon deklaracije svih kolona navode se ogranienja koja vae za celu tabelu.
Specifikacije ogranienja za tabelu su navedena u odeljku Ogranienja tabele.
Navedena sintaksa naredbe CREATE TABLE nije kompletna. SQL standard
obezbeuju korienje velikog broja dodatnih klauzula koje korisnicima
omoguavaju preciznu kontrolu procesa kreiranja tabele. Osim toga proizvoai
RDBMS-ova prouruju CREATE TABLE naredbu klauzulama koje su posledica
specifinih osobina njihovih proizvoda.
7.2.1 Tipovi podataka

U Tabeli 2 su dati generiki tipovi podataka koje definie SQL standard. Ne
podravaju svi RDBMS-ovi tipove podataka definisane u SQL standardu.
144
Upitni jezik SQL

Tip podataka
integer
smallint
numeric(p,s)
decimal(p,s)
real
double precision
float(p)
char(x)
varchar2(x)
bit(x)
bit varying(x)
date
time
timestamp
time with time
zone
timestamp with
time zone
Interval
Tabela 2: Generiki SQL tipovi podataka

Opis
Celobrojna vrednost
Celobrojna vrednost
Argument p definie ukupan broj cifara broja dok argument s
definie broj cifara desno od decimalnog zareza. Npr.
numeric(6, 2) je broj koji ima 4 cifre ispred decimalnog zareza
i 2 cifre iza decimalnog zareza.
Argument p definie ukupan broj cifara broja dok argument s
definie broj cifara desno od decimalnog zareza. Npr.
numeric(6, 2) je broj koji ima 4 cifre ispred decimalnog zareza
i 2 cifre iza decimalnog zareza.
Broj u pokrenom zarezu jednostruke preciznosti
Broj u pokretnom zarezu dvostruke preciznosti
Argument p definie preciznost broja.
Argument x predstavlja maksimalan broj karaktera koji kolona
moe da prihvati. Ovaj tip definie tekstualne podatke fiksne
duine, odnosno podataka se dopunjuje blanko znacima sa
desne strane kako bi se obezbedila specificirana duina.
Argument x predstavlja maksimalan broj karaktera koji kolona
moe da prihvati. Ovaj tip definie tekstualne podatke
promenljive duine (nema dopunjavanja blanko znacima).
Argument x definie maksimalan broj bitova koje podataka
moe da prihvati. Podaci su fiksne duine.
Argument x definie maksimalan broj bitova koje podataka
moe da prihvati. Podaci su promenljive duine.
Datum.
Vreme.
Datum i vreme.
time koji ukljuuje i informaciju o vremenskoj zoni.
timestamp koji ukljuuje i informaciju o vremenskoj zoni..
Vremenski interval.
U nastavku su dati tipovi podataka koje na osnovu SQL standarda implementira

ORACLE RDBMS. Dobar deo ORACLE tipova podataka se poklapa sa
generikim SQL tipovima ali postoje i odstupanja.
CHAR(n)
Ovaj tip definie znakovne podatke fiksne duine. Obavezna se mora specificirati
duina kolone (u bajtovima ili karakterima) od 1 do 2000 bajtova. Podrazumevana
duina je 1 bajt. Duina se podrazumevano zadaje kao broj bajtova.
Ukoliko je podatak u koloni krai od specificirane duine on se dopunjuje blanko
znacima sa desne strane. Ukoliko je podataka vei od specificirane duine Oracle
145

DBMS vraa greku. Prilikom poreenja CHAR vrednosti uzimaju se u obzir i
dodati blanko znaci.
VARCHAR(n) i VARCHAR2(n)
Ovaj tip podataka definie znakovne podatke promenljive duine. Obavezna se
mora specificirati maksimalna duina kolone (u bajtovima ili karakterima) od 1 do
4000 bajtova. Podrazumevana duina je 1 bajt. Maksimalna duina se
podrazumevano zadaje kao broj bajtova.
Ukoliko je podataka vei od specificirane maksimalne duine Oracle DBMS vraa
greku. U koloni se pamti podatak bez dopunjavanja blanko znacima.
VARCHAR i VARCHAR2 su sinonimi (preporuuje se korienje VARCHAR2
tipa da bi se izbegli problemi sa buduom kompatibilnou).
Napomena: Kod razliitih kodnih rasporeda za predstavljanje karaktera se koristi
razliiti broj bajtova. Na primer, kod ASCII kodnog raporeda za predstavljanje
svakog karaktera se koristi tano jedan bajt. Za razliku od toga, kod UTF8 kodnog
rasporeda za predstavljanje karaktera se moe koristiti vie od jednog bajta
(maksimalno etiri). Za svaku ORACLE bazu podataka prilikom kreiranja je
definisan podrazumevani kodni raspored koji e se koristiti za predstavljanje
znakovnih podataka u toj bazi podataka.
NCHAR(n) i NVARCHAR(n)
Ova dva tipa podataka omoguavaje memorisanje znakovnih podataka korienjem
UTF kodnog rasporeda bez obzira ta je izabrano kao podrazumevani kodni
raspored prilikom kreiranja ORACLE baze podataka. Ova dva tipa podataka
omoguavaju memorisanje znakovnih podataka korienjem UTF8 (ili opciono
AL16UTF16) kodnog rasporeda.
NCHAR pamti UTF8 znakovne podatke fiksne duine, dok NVARCHAR pamti
UTF8 znakovne podatek promenljive duine. Duina se uvek specificira kao broj
karaktera. Maksimalna duina za NCHAR kolone je 2000 karaktera a za
NVARCHAR kolone je 4000 karaktera.
NUMBER(p, s)
Tip podataka koji se koristi za predstavljanje brojeva i u fiksnom i u pokretno
zarezu. Korienjem ovog tipa mogu se predstaviti sledee vrednosti:
pozitivni brojevi 1 x 10-130 do 9.99...9 x 10125 sa 38 znaajnih cifara
146
negativni brojevi -1 x 10-130 do -9.99...9 x 10125 sa 38 znaajnih cifara
nula
pozitivna i negativna beskonana vrednost
Upitni jezik SQL

Argument p (precision) definie ukupan broj cifara broja dok argument s (scale)
definie broj cifara desno od decimalnog zareza. Kombinacija vrednosti (*, s)
specificra da je maksimalan broj cifara 38 dok se broj cifara desno od decimalnog
zareza odrava u skladu sa navedenom vrednou. Negativna vrednost za scale
nalae Oracle-u da izvri zaokruivanje numerike vrednosti na specificirani broj
pozicija levo od decimalne take.
INTEGER, INT, SMALL INT
Tipovi podataka koji se koriste za memorisanje celobrojnih podataka. Umesto ovih
tipova preporuuje se korienje tipa NUMBER.
FLOAT, REAL, BINARY_FLOAT, BINARY_REAL
Tipovi podataka koji se koriste memorisanje razlomljenih brojnih vrednosti.
Umesto ovih tipova preporuuje se korienje tipa NUMBER.
LOB tipovi podataka
Ovi tipovi podataka se koriste za pamenje velikih blokova nestruktuiranih
podataka:
BLOB se koristi za pamenje binarnih podataka
CLOB i NCLOB s ekoriste za pamenje znakovnih podataka
BFILE omoguava pamenje podataka van baze podataka u file sistemu
Maksimalna koliina podataka koja se moe smestiti u kolonu ovog tipa je 128TB.
DATE, TIMESTAMP
Ovi tipovi podataka se koriste za memorisanje informacija o datumu i vremenu.
Pamti se informacija o godini, mesecu, danu, satu, minutu i sekundama:
standardni format za datume je DD-MMM-YYYY (Primer: '13-NOV92)
standardni format za pamenje vremena je HH:MI:SS. (Primer: '13NOV-92 11:12:32'
Ukoliko se navede samo datum podrazumevani podatak za vreme je 00:00:00

odnosno pono. Ukoliko se navede samo vreme podrazumevani datum je prvi dan
tekueg meseca.
TIMESTAMP moe da ukljuuje i delove sekundi i informaciju o vremenskoj
zoni.
Za razliku od SQL standarda ORACLE DBMS ne predvia postojanje posebnih
tipova za memorisanje vremena i datuma.
147

Primer: SQL DDL naredbe za kreiranje tabela RADNIK i SEKTOR
CREATE TABLE RADNIK
(
LIME VARCHAR2(15),
SSLOVO VARCHAR2(2),
PREZIME VARCHAR2(15),
MATBR NUMBER(10),
DATRODJ DATE,
POL CHAR(1),
PLATA NUMBER(8, 2),
ADRESA VARCHAR2(30),
MATBRS NUMBER(10),
BRSEK NUMBER(2)
);
CREATE TABLE SEKTOR
(
NAZIV VARCHAR2(15),
SBROJ NUMBER(2),
MATBRR NUMBER(10),
DATPOST DATE
);
7.2.2 Ogranienja kolone

Ogranienja koja moete da definiete za kolonu prilikom kreiranja tabela su:
148
NULL ili NOT NULL definie da kolona moe ili ne moe imatu
NULL vrednosti.
UNIQUE definie da kolona ima jedinstvene vrednosti (kandidati za

kljueve).
PRIMARY KEY definie da kolona predstavlja primarni klju tabele

(moe da se primeni na samo jednu kolonu u tabeli).
CHECK definie ogranienje za proveru vrednosti kolone (koristi se

kod upisa ili auriranja vrednosti).
DEFAULT definie podrazumevanu vrednost za kolonu (kolona

uzima ovu vrednost, ako vrednost kolone nije navedena).
Upitni jezik SQL
REFERENCES definie da kolona predstavlja spoljni klju tabele.
Za vrednost kolone se mogu specificirati ogranienja NULL ili NOT NULL

ime se dozvoljava ili zabranjuje NULL vrednost kolone. Stroe ogranienje je
UNIQUE, koje ne dozvoljava ponavljanje vrednosti u koloni.
Za kolonu podrazumevano ogranienje je NULL vrednost. To znai da
navodimo samo ogranienje NOT NULL, ako je definisano za konkretnu kolonu.
Kod navoenja PRIMARY KEY podrazumeva se NOT NULL ogranienje za
tu kolonu, tako da ga ne treba posebno navoditi.
Napomena: Prilikom navoenja PRIMARY KEY ogranienja, podrazumevaju
se UNIQUE i NOT NULL ogranienje za tu kolonu, tako da se ne moraju posebno
navoditi.
Pri kreiranju tabele u kojoj je atribut A primarni klju, a atribut B spoljni klju
moete koristi oblik naredbe sledei CREATE TABLE.
CREATE TABLE <imeTabele>
(
A <tip_podatka> PRIMARY KEY,
B <tip_podatka> REFERENCES <ime_ref_tabele>(<ime_ref_kolone>),
ostali atributi
);
Uoite da kod deklaracije spoljnog kljua tabele treba navesti iza kljune rei
REFERENCES ime referencirane tabele i opciono, u maloj zagradi, ime
referencirane kolone u toj tabeli. ORACLE SQL oekuje da je referencirana kolona
primarni klju (kolona deklarisana sa PRIMARY KEY) u referenciranoj tabeli ili
da je nad njom podignuto ogranienje UNIQUE.
Na taj nain atribit iza koga stoji klauzula REFERENCES definisan je kao
spoljni klju u odnosu na primarni klju tabele ije je ime navedeno iza klauzule
REFERENCES.
Primer: SQL DDL naredba za kreiranje tabele PROJEKAT
CREATE TABLE PROJEKAT
(
NAZIV VARCHAR(25) NOT NULL,
LOKPR VARCHAR(15) DEFAULT 'Ni',
BROJPR NUMBER(3) PRIMARY KEY,
BRS NUMBER(2) NOT NULL REFERENCES SEKTOR(SBROJ)
);
149
7.2.3 Ogranienja tabele

Za definisanje ogranienja koja vae za tabelu u celini moete koristiti:
PRIMARY KEY definie koja kolona ili koje kolone ine primarni
klju tabele.
UNIQUE definie koja kolona ili koje kolone imaju jedinstvene

vrednosti (kandidati za kljueve).
FOREIGN KEY definie koja kolona ili koje kolone ine spoljni
klju tabele.
CHECK definie ogranienja vrednosti kolone ili kolona koje DBMS

proverava kod upisa ili auriranja vrednosti te ili tih kolona.
Za kreiranje tabele u kojoj je skup atributa predstavlja primarni klju moete

koristiti oblik sledei oblik CREATE TABLE naredbe:
CREATE TABLE < ime_tabele >
(
<atributi i njihovi tipovi podataka>,
CONSTRAINT <ime ogranienja>
PRIMARY KEY (<lista_atributa_koji_ine_primarni_klju>)
);
Podrazumeva se da su atributi koji ine primarni klju prethodno definisani u

sekciji < atributi i njihovi tipovi podataka >.
Primer: DDL naredba za kreiranje tabele RADI_NA
CREATE TABLE RADI_NA
(
MBR NUMBER(10),
BRPR NUMBER(3),
SATI NUMBER(3) NOT NULL CHECK (SATI > 0),
CONSTRAINT RADI_NA_PK PRIMARY KEY (MBR, BRPR)
);
Napomena: Prilikom kreiranja kompozitnog primarnog kljua nije mogue

iskoristiti ogranienje kolone. Za sluaj kompozitnog primarnog kljua mora se
iskoristiti ogranienje tabele!!!
Primer: Primer POGRENO napisane CREATE TABLE naredbe
Kod ove naredbe se kreira kompozitni primarni klju. Ovako napisanu
CREATE TABEL naredbu ORACLE SQL tumai kao pokuaj kreiranja tabele
koja ima dva primarna kljua. Poto to nije mogue, dobiete odgovarajuu poruku
o greci.
150
Upitni jezik SQL

(
MBR INTEGER PRIMARY KEY,
BRPR INTEGER PRIMARY KEY,
SATI NUMBER(2,0)
);
Za definisanje ogranienja stranog kljua u tabeli u kojoj skup atributa ini

strani klju moe se koristiti sledei oblik CREATE TABLE naredbe:
CREATE TABLE <naziv_tabele>
(
<atributi i njihovi tipovi podataka>,
FOREIGN KEY (<lista_atributa_koji_ine_spoljni_klju>)
REFERENCES (<lista_referenciranih_atributa>)
[ON DELETE { NO ACTION | CASCADE | SET DEFAULT |SET NULL}]
[ON UPDATE { NO ACTION | CASCADE | SET DEFAULT |SET NULL}]
CHECK (<uslovni_izraz>)
);
Podrazumeva se da su atributi koji ine strani klju prethodno definisani u

sekciji <atributi i njihovi tipovi podataka>.
Kod deklaracije spoljnog kljua tabele iza kljune rei REFERENCES navodi
se ime referencirane tabele i opciono, u maloj zagradi, ime referencirane kolone u
toj tabeli. ORACLE SQL oekuje da referencirane kolone predstavlaju primarni
klju u referenciranoj tabeli ili je nad njima definisano ogranienje UNIQUE.
Ukoliko je izostavljena lista referenciranih kolona, ORACLE SQL automatski
podrazumeva primarni klju referencirane tabele.
U deklaraciji kolone ili tabele, nakon klauzule REFERENCES, mogu se
navesti klauzule ON DELETE ili ON UPDATE koje specificiraju aktivnosti u
sluaju naruavanja integriteta.
ON DELETE omoguava specifikaciju aktivnosti nad torkama relacije,
odnosno vrstama tabele u kojoj je navedeno ovo ogranienje, u sluaju brisanja
torki u referenciranoj tabeli.
ON UPDATE omoguava specifikaciju aktivnosti nad torkama u tabeli gde je
REFERENCES ogranienje specificirano u sluaju auriranja (promene)
referenciranoih kolona.
Napomena: ORACLE SQL ne podrava klauzulu ON UPDATE.
U oba sluaja, iza ovih klauzula se navodi jedna od klauzula koja definie
aktivnost koja e se izvriti nad torkama u tabeli u kojoj je ogranienje navedeno u
sluaju naruavanja referencijalnog integriteta (pokuava se brisanje vrsta u
referenciranoj tabeli ili se auriraju vrednosti referenciranih kolona):
NO ACTION ORACLE SQL definie poruku o greci u sluaju da

akcija brisanja ili auriranja mogu da dovedu do naruavanja
151

referencijalnog integriteta. Ovo
ogranienja tipa stranog kljua.
je
podrazumevano
ponaanje
CASCADE kaskadno izvrenje aktivnosti brisanja (briu se torke u

tabeli u kojoj se ogranienje nalazi) kod ON DELETE ili aktivnosti
auriranja (auriraju se vrednosti atributa koji ine primarni klju) kod
ON UPDATE.
SET DEFAULT vrednosti atributa stranog kljua se postavljaju na

podrazumevanu vrednost.
SET NULL vrednost atributa stranog kljua se postavlja na NULL.
Primer: DDL naredba za kreiranej tabele CLAN_PORODICE

CREATE TABLE CLAN_PORODICE
(
MATBRRAD NUMBER(10),
IME VARCHAR(15),
POL CHAR(1) DEFAULT 'M' CHECK (POL IN ('M', '')),
DATRODJ DATE,
CONSTRAINT CLAN_PORODICE_PK PRIMARY KEY (MATBRRAD, IME),
CONSTRAINT RODITELJ_FK FOREIGN KEY (MATBRRAD)
REFERENCES RADNIK(MATBR)
);
Primer: DDL naredbe za kreiranje baze podataka PREDUZEE

CREATE TABLE RADNIK
(
LIME VARCHAR(15) NOT NULL,
SSLOVO VARCHAR(2) NOT NULL,
PREZIME VARCHAR(15) NOT NULL,
MATBR NUMBER(10),
DATRODJ DATE,
POL CHAR(1) DEFAULT 'M' CHECK(POL IN ('M', '')),
PLATA NUMBER(8, 2) CHECK (PLATA > 1000),
ADRESA VARCHAR(30),
MATBRS NUMBER(10),
BRSEK NUMBER(2) NOT NULL,
CONSTRAINT RADNIK_PK PRIMARY KEY (MATBR),
CONSTRAINT SEKTOR_FK FOREIGN KEY (BRSEK)
REFERENCES SEKTOR(SBROJ,
CONSTRAINT RUKOVODI_FK FOREIGN KEY (MATBRS)
);
CREATE TABLE SEKTOR
(
SBROJ NUMBER(2),
MATBRR INT NOT NULL,
DATPOST Date,
152
Upitni jezik SQL

CONSTRAINT SEKTOR_PK PRIMARY KEY (SBROJ),
CONSTRAINT SEF_FK FOREIGN KEY (MATBRR)
);
(
BROJPR NUMBER(3),
BRS NUMBER(2) NOT NULL,
CONSTRAINT PROJEKATPK PRIMARY KEY (BROJPR),
CONSTRAINT NADLEZAN_FK FOREIGN KEY (BRS)
REFERENCES SEKTOR(SBROJ)
);
CREATE TABLE CLAN_PORODICE
(
MATBRRAD NUMBER(10),
IME VARCHAR(15),
POL CHAR(1) DEFAULT 'M' CHECK (POL IN ('M', '')),
DATRODJ Date,
CONSTRAINT CLAN_PORODICE_PK PRIMARY KEY (MATBRRAD, IME),
CONSTRAINT RODITELJ_FK FOREIGN KEY (MATBRRAD)
);
CREATE TABLE LOK_SEK
(
BRS NUMBER(2),
LOKACIJA VARCHAR(15),
CONSTRAINT LOKACIJA_PK PRIMARY KEY (BRS, LOKACIJA),
CONSTRAINT SEKTOR_FK2 FOREIGN KEY (BRS)
);
(
MBR NUMBER(10),
BRPR NUMBER(3),
SATI NUMBER(3) NOT NULL CHECK (SATI > 0),
CONSTRAINT RADI_NA_PK PRIMARY KEY (MBR, BRPR),
CONSTRAINT RADNIK_FK FOREIGN KEY (MBR)
REFERENCES RADNIK(MATBR),
CONSTRAINT PROJEKAT_FK FOREIGN KEY (BRPR)
REFERENCES PROJEKAT(BROJPR)
);
153
7.3 Modifikacija eme relacione baze podataka

Postoji veliki broj SQL DDL naredbi koje omoguavaju izmenu eme relacione
baze podataka. Prilikom korienja ovih naredbi potrebno je da budemo jako
oprezni kako grekom, ili usled nepanje ne bi obrisali neke objekte ili podatke koji
su nam od znaaja.
7.3.1 Brisanje tabele

Za brisanje tabela iz relacione baze podataka koristi se naredba DROP TABLE.
Ova naredba brie strukturu tabelu zajedno sa svim podacima koji se u tabeli
nalaze. ORACLE SQL definie sledei oblik DROP TABLE naredbe:
DROP TABLE <ime_tabele> [CASCADE CONSTRAINTS]
Opcija CASCADE CONSTRAINTS definie da se prilikom brisanja tabele

automatski briu i sva ogranienja koja referenciraju tabelu koja se brie.
Primer: SQL naredba koja brie tabelu RADNIK zajedno sa svim podacima
koji se u tabeli nalaze.
DROP TABLE RADNIK;
DBMS e spreiti brisanje tabele u sluaju da to dovodi do naruavanja

referencijalnog integriteta, odnosno brisanje tabele nije mogue ukoliko u bazi
podataka postoje ogranienja stranog kljua koja referenciraju tabelu koju elimo
da obriemo. U tom sluaju je mogue iskoristiti opciju CASCADE
CONSTRAINTS koja e najpre obrisati sva ogranienja a zatim e obrisati i samu
tabelu. U tom sluaju naredba za brisanej tabele RADNIK ima sledei oblik:
DROP TABLE RADNIK CASCADE CONSTRAINTS;
Modifikacija tabela
Za modifikaciju strukture tabela koristi se naredba ALTER TABLE. ORACLE
SQL definie sledei oblik ove naredbe:
ALTER TABLE <ime tabele>
ADD <definicija atributa> |
ADD <definicija ogranienja> |
DROP <ime atributa> |
DROP CONSTRAINT <ime ogranienja> |
154
Upitni jezik SQL

MODIFY < definicija atributa > |
DROP PRIMARY KEY
DROP UNIQUE <ime atributa>
Primer: SQL naredba koja u tabelu PROJEKAT dodaje novu kolonu.

ALTER TABLE PROJEKAT
ADD VREDNOST_PROJEKTA NUMBER(10, 2);
Prilikom dodavanja nove kolone ne moemo odmah primeniti NOT NULL

ogranienje jer bi u tom sluaju ogranienje odmah bilo narueno. Zbog toga se
kolona dodaje bez NOT NULL ogranienja, dodaju se neophodni podaci pa se
eventualno naknadno dodaje ogranienje.
Primer: SQL naredba koja modifikuje kolonu i uvodi NOT NULL ogranienje
nad kolonom.
MODIFY VREDNOST_PROJEKTA NUMBER(12, 2) NOT NULL;
Prilikom promene tipa neke kolone treba voditi rauna o podacima koji ve
postoje u toj koloni. ORACLE DBMS e pokuati da automatski izvri konverziju
postojeih podataka ukoliko je to mogue. Ukoliko nije mogue ORACLE DBMS
e prijaviti poruku o greci.
Primer: SQL naredba koja u tabelu dodaje novo ogranienje kojim se
obezbeuje da vrednost projekta uvek mora biti pozitivan broj.
ADD CONSTRAINT VREDNOST_PROJEKTA_CK
CHECK (VREDNOST_PROJEKTA > 0);
Primer: SQL naredba kojom se iz tabele PROJEKAT brie ogranienje.

DROP CONSTRAINT VREDNOST_PROJEKTA_CK;
Primer: SQL naredba kojoj se brie kolona iz tabele.

DROP COLUMN VREDNOST_PROJEKTA;
155
7.4 Pretraivanje podataka

Pretraivanje i pribavljanje podataka su najee operacije koje korisnici
izvravaju u relacionoj bazi podataka. Za pretraivanje i pribavljanje podataka SQL
programski jezik obezbeuje naredbu SELECT. Naredba SELECT pribavlja
podatke iz jedne tabele ili vie povezanih tabela koje se nalaze u relacionoj bazi
podataka. U svom osnovnom obliku naredba SELECT ne moe ni na koji nain da
izmeni podatke koji se nalaze u relacionoj bazi podataka.
Naredba SELECT je deklarativna naredba. Korienjem ove naredbe korisnici
imaju moguost samo da specificiraju rezultate koje ele. Sa druge strane RDBMS
je zaduen da isplanira, optimizuje i izvri fizike operacije neophodne za
generisanje specificiranih rezultata.
Rezultat SELECT naredbe je uvek relacija. Naredba SELECT koristi podatke iz
jedne ili veeg broja tabela, manipulite tim podacima i kao rezultat generie
tabelu. ak i kada je rezultat obrade skalarna vrednost ona se tretira kao tabela sa
jednom vrstom i jednom kolonom.
7.4.1 Naredba SELECT

Naredba SELECT je jedna od najkompleksnijih naredbi SQL programskog
jezika. Ukljuuje vei broj kljunih rei klauzula:
156
SELECT definie listu kolona koje e biti ukljuene u rezultujuu

tabelu
FROM definie tabele iz kojih se pribavljaju podaci za potrebe

generisanja rezultujue tabele. Klauzula FROM moe da ukljui jednu ili
vie opcionih JOIN klauzula za povezivanje tabela na osnovu
kriterijuma zadatih od strane korisnika.
WHERE definie predikat na osnovu koga se ograniava broj vrsta u

rezultujuoj tabeli. Ova klauzula iz rezultata eliminie sve vrste za koje
specificirani predikat ne vraa vrednost TRUE.
GROUP BY grupie vrste koje u odreenim kolonama imaju identine

vrednosti.
HAVING definie predikat na osnovu koga se elimiu vrste nakon to

je klauzula GROUP BY primenjena na rezultujuu tabelu.
ORDER BY koristi se za sortiranje rezultujue tabele. Korisnici

specificiraju kolone po kojima se vri sortiranje kao i smer sortiranja.
Upitni jezik SQL
7.4.2 Kaluzule SELECT i FROM

Klauzule SELECT i FROM su jedine obavezne u okviru SELECT naredbe.
klauzula FROM specificira tabele iz kojih se pribavljaju podaci. Ukoliko se
navede vie tabela potrebno je specificirati nain spajanja tabela. Spajanje tabela e
biti detaljno objanjeno u narednoj sekciji. Primeri u ovom odeljku e biti
ogranieni samo na na pribavljanje podataka iz jedne tabele.
Klauzula SELECT specificira kolone koje treba ukljuiti u rezultujuu tabelu.
Mogu se koristiti sledee opcije:
ALL u rezultujuoj tabeli prikazuju se sve vrste koje zadovoljavaju

navedeni predikat
DISTINCT iz rezultujue tabele izbacuju se duplikati vrsta
* - rezultujua tabela ukljuuje sve kolone tabele ili tabela iz kojih se

pribavljaju podaci
tabela.* - rezultujua tabela ukljuuje sve kolone specificirane tabele
izraz - ime kolone ili funkcije nad kolonama koja e biti ukljuena u
rezultujuu tabelu
AS pseudonim - novo ime kolone ili funkcije nad kolonama koje im se

dodeljuje u rezultujuoj tabeli
Primer: U nastavku je dat SQL upit koji prikazuje kompletan sadraj tabele
RADNIK
SELECT * FROM RADNIK;
Rezultat bi bio ekvivalenta da smo napisali upit kod koga su umesto * navedena
imena svih kolona u tabeli.
SELECT LIME, SSLOVO, PREZIME, MATBR, DATRODJ,
POL, PLATA, MATBRS, BRSEK
FROM RADNIK;
157

Primer: Ukoliko elimo da prikaemo samo odreene kolone iz tabele
RADNIK posle SELECT klauzule naveemo imena kolona koje su od interesa.
U nastavku je dat SQL upit koji prikazuje samo imena i prezimena radnika.
SELECT Ime, Prezime FROM RADNIK;
Redosled kojim su kolone navedene u klauzuli SELECT definie redosled

kolona u rezultujuoj tabeli. U nastavku je dat SQL upit koji prikazuje imena i
prezimena svih radnika ali u neto drugaijem redosledu.
SELECT Prezime, Ime FROM RADNIK;
Primer: U nastavku je dat SQL upit koji za svakog radnik odreuje matini broj
njegovog neposrednog rukovodioca.
SELECT MATBRS FROM RADNIK;
158
Upitni jezik SQL

Moemo da se primeti da se u rezultujuoj tabeli neki matini brojevi javljaju
vie puta. To je posledica injenice da vei broj radnika moe imati istog
rukovodioca.
Ekvivalantan SQL upit koristi kljunu re ALL. Kljuna re ALL nalae
ORACLE RDBMS-u da prikae sve vrste rezultujue tabe (ukljuujui i
duplikate). Kljuna re ALL je podrazumevana pa se najee izostavlja.
SELECT ALL MATBRS FROM RADNIK;
Ukoliko elimo da eliminiemo duplikate koristiemo kljunu re DISTINCT.

SELECT DISTINCT MATBRS FROM RADNIK;
7.4.3 Klauzula WHERE

Klauzula WHERE specificira uslov na osnovu koga se kreira rezultujua tabela.
U rezultujuu tabelu e biti ukljuene samo one vrste koje zadovoljavaju
specificirani uslov, odnosno za koje specificirani uslov ima vrednost TRUE. U
uslovu se mogu javiti:
1. Relacioni operatori
2. Logiki operatori
3. Operator BETWEEN
4. Operator IN
5. Operator LIKE
6. Operator IS NULL
SQL podrava est relacionih operatora koji imaju sledee znaenje:
1. = Jednako
2. <>
Nije jednako(razliito)
3. < Manje od
4. > Vee od
5. <=
Manje ili jednako a
6. >=
Vee ili jednako
Primer: U ovom primeru dat je SQL upit koji prikazuje podatke o radnicima
koji se prezivaju Petrovi.
159

SELECT *
FROM RADNIK
WHERE PREZIME = 'Petrovi';
Napomena: Treba primetiti da se tekstualni podaci zadaju korienjem

jednostrukih apostrofa:: 'Petrovi'.
Primer: Naredni primer sadri SQL upit koji prikazuje imena i prezimena
radnika ija je plata jednaka ili vea od 40000.
SELECT LIME, PREZIME
FROM RADNIK
WHERE PLATA >= 40000;
SQL omoguava korienje standardnih logikih operatore AND, OR i NOT,

ali i operatore IN i BETWEEN koji omoguavaju jednostavnije korienje
prethodno navedenih operatora u nekim sluajevima.
Prioritet logikih operatora je sledei:
1. NOT
2. AND
3. OR
Napomena: Logiki operatori AND i OR se koriste na standardni nain.
Meutim, kod SQL-a, logiki operator negacije NOT se navodi na poetku
logikog izraza, a ne ispred operatora poreenja. Na primer, NOT A = B je validni
WHERE uslov, ali A NOT = B nije.
Primer: Za prikaz podataka o radnicima koji se prezivaju Petrovi i ija je plata
jednaka ili vea od 40000 moe se koristiti SQL upit koji je dat u nastavku.
FROM RADNIK
WHERE PREZIME = 'Petrovi' AND PLATA >= 40000;
160
Upitni jezik SQL
Primer: U nastavku je dat SQL upit koji prikazuje podatke o radnicima koji se
prezivaju Petrovi i ija je plata manja od 40000 (nije jednaka ili vea od 40000).
FROM RADNIK
WHERE PREZIME = 'Petrovi' AND NOT PLATA >= 40000;
Primer: U nastavku je dat primer SQL upita koji prikazuje podatke o radnicima
koji se prezivaju 'Petrovi' ili se prezivaju 'Jovanovi'.
FROM RADNIK
WHERE PREZIME = 'Petrovi' OR PREZIME = 'Jovanovi';
Kljuna re IN zamenjuje viestruku upotrebu operatora OR i = . Operator

NOT IN prikazuje sve vrste osim onih odreenih IN listom.
Primer: Naredni primer predstavlja SQL upit koji korienjem operatora IN
izdvaja se samo radnike koji se prezivaju 'Petrovi' ili 'Jovanovi'.
FROM RADNIK
WHERE PREZIME IN ('Petrovi', 'Jovanovi');
Primer: Naredni SQL upit pribavlja podatke o svim radnicima osim onih koji
se prezivaju 'Petrovi' ili 'Jovanovi'.
161

FROM RADNIK
WHERE PREZIME NOT IN ('Petrovi', 'Jovanovi');
Operator BEETWEEN zamenjuje viestruku upotrebu operatora AND i =.

Ovaj operator omoguava ispitivanje da li je vrednost atributa/kolone u zadatom
opsegu (ukljuujui i granice opsega).
Primer: U nastavku je dat SQL upit koji koristi operator BETWEEN za
prikazivanje podataka o radnicima ija je plata u opsegu od 30000 do 40000
(ukljuujui i granice opsega).
SELECT MATBR, LIME, PREZIME
FROM RADNIK
WHERE PLATA BETWEEN 30000 AND 40000;
Alternativni SQL upit koji vraa identian rezultat bez korienja BETWEEN
operatora ima sledei oblik:
FROM RADNIK
WHERE PLATA >= 30000 AND PLATA <= 40000;
Operator IS NULL se koristi za poreenje sa NULL vrednostima, odnosno

omoguava proveru da i kolona ima NULL vrednost.
Primer: U nastavku je dat SQL upit koji izdvaja podatke o radnicima koji
nemaju neposrednog rukovodioca odnosno kod kojih kolona MATBRS ima
vrednost NULL (postoji samo jedan takav radnik koji se nalazi na funkciji glavnog
rukovodioca, odnosno on nema nikoga iznad sebe u hijerarhiji).
SELECT MATBR, LIME, PREZIME, MATBRS
FROM RADNIK
WHERE MATBRS IS NULL;
162
Upitni jezik SQL
Za sluaj da elimo da pronaemo sve radnike koji imaju neposredne

rukovodioce (kod kojih kolona MATBRS ima vrednost koja nije NULL)
odgovarajui SQL upit se moe napisati na jedan od naredna dva naina:
SELECT *
FROM RADNIK
WHERE NOT MATBRS IS NULL;
SELECT *
FROM RADNIK
WHERE MATBRS IS NOT NULL;
Napomena: Treba voditi rauna da se na NULL vrednosti ne moe primenti ni

jedan relacioni operator (sve NULL vrednosti su jedinstvene). Moe se samo
proveravati da li kolona ima NULL vrednost ili nema. Iz tog razloga naredni SQL
upit ne vraa ni jedan slog u rezultujuoj tabeli jer poreenje sa NULL vrednou
nije mogue. Pri tome ORACLE DBMS ne prijavljuje greku.
SELECT *
FROM RADNIK
WHERE MATBRS = NULL;
Operator LIKE omoguava poreenje znakovnih vrednosti (tekstualnih

podataka) sa zadatim ablonom. Za definisanje ablona koriste se simboli procenat
(%) i donja crta (_). Procenat (%) predstavlja bilo koji znak (broj, slovo,
interpunkcijski znak) ili skup znakova. Procenat (%) moe da zameni i prazan
string. Donja crta (_) zamenjuje samo jedan znak (Pojavljivanje znaka je
obavezno). Operator NOT LIKE prikazuje sve vrste koje ne odgovaraju prethodno
zadatom opisu
Primer: U narednom SQL upitu % iza slova 'J' oznaava proizvoljan broj
znakova, odnosno predstavlja uzorak za poklapanje koji sadri na poetku slovo 'J'
i proizvoljan broj znakova iza njega. Za nalaenje svih radnika koji imaju 'J' na
poetku prezimena, moe se koristiti ablon 'J%'.
FROM RADNIK
WHERE PREZIME LIKE 'J%';
163
Napomena: ORACLE DBMS kod tekstualnih podataka pravi razliku izmeu

malih i velikih slova. Zbog toga, predikat LIKE 'j%' u prethodnom upitu ne bi
vratio nijednu rezultujuu vrstu.
Za nalaenje svih radnika koji sadre slovo j negde u prezimenu mogao bi se
koristiti ablon '%j%'.
Primer: Ukoliko je neophodno prikazate podatke o radnicima koji su roeni
toko meseca septembra, odgovarajui SQL upit ima sledei oblik:
SELECT MATBR, LIME, PREZIME, DATRODJ
FROM RADNIK
WHERE DATRODJ LIKE '%SEP%';
Alternativni SQL upit koji vraa identian rezultat ima sledei oblik:
FROM RADNIK
WHERE DATRODJ LIKE '___SEP___';
Operator NOT LIKE prikazuje sve vrste koje ne odgovaraju prethodno

zadatom ablonu.
Primer: SQL upit koji pronalazi podatke o svim radnicima koji nisu roeni
tokom meseca septembra ima sledei oblik:
FROM RADNIK
WHERE DATRODJ NOT LIKE '%SEP%';
164
Upitni jezik SQL
7.4.4 Klauzula ORDER BY

Klauzula ORDER BY specificira redosled prikazivanja vrste rezultujue tabele,
sortiranjem po vrednosti nekih kolona u rastui (ASC) (predefinisana vrednost) ili
opadajui redosled (DESC). Ukoliko klauzula ORDER BY nije navedena vrste u
rezultujuoj tabeli su poreane po sluajnom principu i ne postoji nikakva
garancije da e isti upit uvek generisati rezultujuu tabelu ije su vrste poreane na
isti nain.
Primer: U nastavku je dat SQL upit koji prikazuje podatke o radnicima i sortira
ih prema prezimenu u rastuem redosledu.
SELECT MATBR, LIME, SSLOVO, PREZIME
FROM RADNIK
ORDER BY PREZIME ASC;
Napomena: Ukoliko se vrste sortiraju u rastuem redosledu (ASC) po vrednosti

neke kolone, nije potrebno eksplicitno navesti smer sortiranja. Rastui redosled je
podrazumevani redolsed sortiranja u ORDER BY klauzuli.
Primer: Alternativni SQL upit koji prikazuje podatke o radnicima sortirane
prema prezimenu u opadajuem redolsed ima sledei oblik:
SELECT MATBR, LIME, SSLOVO, PREZIME
FROM RADNIK
ORDER BY PREZIME DESC;
165
Napomena: Ukoliko se vrste sortiraju u opadajuem redosledu (DESC) po

vrednosti neke kolone, uvek je potrebno eksplicitno navesti smer sortiranja.
Sortiranje je mogue vriti prema vrednostima veg broja kolona. U tom sluaju
se sve kolone po kojima se rezultat sortira navode u ORDER BY klauzuli zajedno
sa smerom sortiranja. Redosled navoenja kolona definie redosled po kome e se
njihove vrednosti uzimati u obzir prilikom sortiranja rezultujue tabele.
Primer: NAredni SQL upit prikazuje podatke o radnicima i sortira ih prema
broju sektora u opadajuem redosledu a prema prezimenu u rastuem redosledu.
SELECT MATBR, LIME, SSLOVO, PREZIME, BRSEK
FROM RADNIK
ORDER BY BRSEK DESC, PREZIME ASC;
7.4.5 Aritmetike funkcije

SQL dozvoljava korienje matematikih funkcija u SELECT i WHERE
klauzulama. Na taj nain se kao rezultat pretraivanja mogu prikazati rezultati
izraunavanja nekog matematikog izraza.
Deo aritmetikih funkcija koje podrava ORACLE DBMS dat je u nastavku:
SQL dozvoljava korienje matematikih funkcija u SELECT i WHERE
klauzulama. Na taj nain se kao rezultat pretraivanja mogu prikazati rezultati
izraunavanja nekog matematikog izraza.
166
+, -, *, /
ROUND(broj[,d]) - zaokruivanje na d decimala
POWER(broj,e) - e-ti stepen zadatog broja
TRUNC(broj[,d]) - odsecanje na d decimala
Upitni jezik SQL
ABS(broj) - apsolutna vrednost broja

SIGN(broj) - znak broja
MOD(broj1, broj2) - broj1 mod broj2
SQRT(broj) - kvadratni koren broja
LEAST(izraz, ...) - najmanji navedeni izraz
GREATEST(izraz, ...) - najvei navedeni izraz
Primer: U nastavku je dat SQL upit koji prikazuje imena i prezimena radnika
kao i njihove plate uveane za bonus od 5000.
SELECT MATBR, LIME, SSLOVO, PREZIME,
PLATA + 5000 AS PLATA_SA_BONUSOM
FROM RADNIK;
Napomena: Rezultatu matematike funkcije (PLATA + 5000) je dodeljeno ime

korienjem sintakse pseudonima: AS PLATA_SA_BONUSOM. U rezultujuoj
tabeli rezultat ove aritmetike funkcije se pojavljuje kao nova kolona.
Primer: Naredni SQL upit prikazuje podatke o radnicima kod kojih iznos plate
uvean za 5000 ima vrednost veu od 40000.
SELECT MATBR, LIME, SSLOVO, PREZIME,
PLATA + 5000 AS PLATA_SA_BONUSOM
FROM RADNIK
WHERE PLATA + 5000 > 40000;
Primer: U nastavku je dat SQL upit koji demonstrira nain primene mehanizma
pseudonima za imenovanje kolona u rezultujuoj tabeli.
SELECT LIME AS IME, PREZIME,
PLATA + 5000 AS PLATA_SA_BONUSOM,
1 AS KONSTANTA, NULL NOVA_KOLONA
FROM RADNIK;
167
7.4.6 Funkcije za rad sa stringovima

Funkcije za rad sa stringovima omoguavaju manipulaciju znakovnim
podacima. U nastavku je dat deo fnkcija za rad sa stringovma koji je podran od
strane ORACLE DBMS-a:
string1 || string2 - konkatenacija stringova
LENGTH(string) - duina stringa
SUBSTR(s, i, j) - podniz od s duine j od pozicije i
INSTR(s1, s2[,k]) - trai s2 u s1 od pozicije k
UPPER(s) - prevodi s u velika slova
LOWER(s) - prevodi s u mala slova
TO_NUM(s) - prevodi s u numeriki tip
TO_CHAR(n) - prevodi numeriki u znakovni tip
LPAD(s, l[,c]) - popunjava s sa leve strane sa l znakova c
RPAD(s, l[,c]) - popunjava s sa desne strane sa l znakova c
NVL(s1, s2)
- ako vai s1 IS NULL, vraa s2; u suprotnom vraa s1.
Primer: U nastavku je dat SQL upit koji konkatenacijom formira puno ime svih
radnika.
SELECT LIME || ' ' || SSLOVO || '.' || ' ' || PREZIME AS PUNO_IME
FROM RADNIK;
168
Upitni jezik SQL
Primer: U nastavku je dat SQL upit koji prikazuje informacije o radnicima

ukljuujui i matine brojeve njihovih neposrednih rukovodioca. Za radnika koji
nema neposrednog rukovodioca ispisuje se poruka NEMA EFA.
SELECT LIME, PREZIME,
NVL(TO_CHAR(MATBRS), 'NEMA EFA') SEF
FROM RADNIK;
7.4.7 Funkcije agregacije

Funkcije agregacije su dobile naziv po tome to vre agregaciju rezultata upita.
Korienje ovih funkcija je jednostavno, poto se navode u listi kolona SELECT
klauzule koje se prikazuju. Znaenje funkcija je sledee:
AVG(kolona) - izraunava srednju vrednost datog atributa
SUM(kolona) - izraunava sumu svih vrednosti atributa
MIN(kolona) - nalazi minimalnu vrednost atributa
MAX(kolona) - nalazi najveu vrednost atributa
COUNT(*) - nalazi broj vrsta u tabeli (grupi)
COUNT(kolona) - nalazi broj broj vrsta sa ne NULL vrednostima

kolone
COUNT (DISTINCT kolona) - nalazi broj vrsta sa razliitim

vrednostima zadate kolone
169

Primer: Funkcija COUNT odreuje broj vrsta u rezultujuoj tabeli. SQL upit
koji je definisan u nastavku odreuje broj radnika o kojima se uvaju podaci u bazi
podataka.
SELECT COUNT(*) AS UKUPNO_RADNIKA
FROM RADNIK;
Primer: Sledei SQL upit odreuje maksimalnu, minimalnu, prosenu i ukupnu

platu svih radnika u preduzeu.
SELECT MAX(PLATA) AS MAX_PLATA,
MIN(PLATA) AS MIN_PLATA,
AVG(PLATA), SUM(PLATA)
FROM RADNIK;
Napomena: Funkcije agregacije nije mogue koristiti u WHERE klauzuli. To je

posledica injenice da se rezultat funkcija agregacija izraunava nakon to se
odrede vrste koje ulaze u sastav rezultujue tabele, odnosno nakon obrade predikta
koji je zadat u WHERE klauzuli. U nastavku je dat SQL upit koji se NE MOE
IZVRITI i koji e GENERISATI GREKU.
SELECT LIME, PREZIME, PLATA
FROM RADNIK
WHERE PLATA > AVG(PLATA);
7.5 Napredne klauzule SELECT naredbe i spajanje tabela

7.5.1 Spajanje tabela
Svi SQL upiti koji su razmatrani u prethodnoj sekciji su koristili podatke iz
samo jedne tabele. esto se javlja situacija da se traena informacija nalazi u
veem broju tabela. U takvim situacijama potrebno je izvriti spajanje vrsta iz
razliitih tabela i generisanje rezultujue tabele.
Za pribavljanje podataka iz veeg broja tabela dovoljno je u klauzuli FROM
navesti imena tabela iz kojih elimo da pribavimo podatke. Da bi spajanje tabela
bilo uspeno, osim u nekim specijalnim sluajevima, potrebno je da navedemo
170
Upitni jezik SQL

uslov spoja, odnosno da navedemo kolone na osnovu ijih vrednosti se vri
spajanje vrsta iz razliitih tabela. Spajanje tabela se vri tako to se najee
uparuje strani klju iz jedne tabele sa primarnim kljuem koji referencira u drugoj
tabeli. Uslov spajanja moe da se zada u okviru WHERE klauzule ili korienjem
kljune rei JOIN u okviru FROM klauzule.
Spoj na jednakost (equi-join) obezbeuje spajanje podataka iz dve ili vie
tabela na osnovu jednakosti odgovarajuih atributa, obino na osnovu primarnih i
stranih kljueva. Najjednostavniji sluaj navoenja spoja je kada se u WHERE
klauzuli specificira uslov spoja po jednakosti.
Dekartov proizvod je sluaj kada u WHERE klauzuli ne postoji uslov spoja, a
u FROM klauzuli je navedeno vie tabela. U tom sluaju nema spajanja vrsta po
vrednosti nekog atributa, ve se pravi kombinacija svake vrste iz jedne tabele sa
svakom vrstom iz druge tabele (u sluaju Dekartovog proizvoda dve tabele)
Spoljni spoj (outer-join) omoguava spajanje dve tabele po vrednosti nekog
atributa (kao kod equi-join), ali i ukljuivanje onih torki (vrsta) iz jedne ili druge
tabele (ili iz obe), koje ne zadovoljavaju uslov jednakosti.
SQL standard definie sledee tipove spojeva:
cross join
inner join
outer join
o
left outer join
right outer join
full outer join
Zbog jednostavnost za primere u nasatavku bie koriene neto jednostavnije

verzije tabela RADNIK i SEKTOR. Ove pojednostavljene verzije ove dve tabele su
prikazane u nastavku.
RADNIK
SEKTOR
Napomena: U pojednostavljenu verziju tabele RADNIK dodate su informacije

o radniku Borivoju Veljkoviu koji radi u nepostojeem sektoru iji je broj 10.
171

Napomena: U pojednostavljenu verziju tabele SEKTOR dodate su informacije
o sektoru Prodaja u kome ne radi nijedan radnik.
7.5.2 Dekartov proizvod (cross-join)

Cross join predstavlja Dekartov proizvod vrsta iz tabela koje se spajaju.
Dekartov proizvod dve tabele (A CROSS JOIN B) se dobija tako to se svaka
vrsta iz jedne tabele kombinuje sa svakom vrstom iz druge tabele.
Ne koristi se esto ali predstavlja osnovu za definisanje ostalih tipova spoja.
Ukoliko se u FROM klauzuli navede vei broj tabela a ne navede se tip i uslov
spoja podrazumeva se cross join.
SELECT *
FROM SEKTOR CROSS JOIN RADNIK;
SELECT *
FROM SEKTOR, RADNIK;
7.5.3 Unutranji spoj (inner-join)

Unutranji spoj (Inner join) predstavlja najee korieni tip spoja. Ovaj tip
spoja, u osnovi, definie presek vrsta iz tabela koje uestvuju u spoju.
Prilikom spajanja dve tabele (A INNER JOIN B) uzimaju se sve vrste iz tabele
A i pronalazi im se odgovarajua vrsta u tabeli B. Ukoliko vrsta iz tabele A nema
odgovarajuu vrstu u tabeli B ne ukljuuje se u rezultat. Ukoliko vrsti iz tabele A
odgovara vie vrsta tabele B ona se u rezultatu ponavlja vie puta (po jednom za
svaku odgovarajuu vrstu u tabeli B).
Napomena: Prilikom spajanja tabela treba voditi rauna o tome da kolone u
razliitim tabelama mogu imati ista imena. U takvim situacijama se koristi sintaksa
IME_TABELE.IME_KOLONE. U SQL upitima koji su dati u nastavku taj pristup
172
Upitni jezik SQL

je iskorien za kolone SEKTOR.SBROJ i RADNIK.BRSEK mada nije bilo
neophodno jer kolone imaju razliita imena. Isti pristup treba primeniti i za
klauzulu SELECT ukoliko se javi slian problem.
SELECT *
FROM SEKTOR INNER JOIN RADNIK
ON SEKTOR.SBROJ = RADNIK.BRSEK;
SELECT *
FROM SEKTOR JOIN RADNIK
SELECT *
FROM SEKTOR, RADNIK
WHERE SEKTOR.SBROJ = RADNIK.BRSEK;
7.5.4 Levi spoljanji spoj (left-outer join)

Levi spoljanji spoj (Left-outer Join) u osnovi predstavlja proireni inner-join.
Levi spoljanji spoj (A LEFT OUTER JOIN B) pored vrsta koje ukljuuje
unutranji spoj ukljuuje i vrste iz tabele A (leve tabele) koje nemaju
odgovarajuu vrstu u tabeli B (desnoj tabeli). U vrstama koje iz tabele A koje ne
mogu da se upare ni sa jednom vrstom iz tabele B, kolone iz tabele B imaju
vrednost NULL.
SELECT *
FROM SEKTOR LEFT OUTER JOIN RADNIK
SELECT *
FROM SEKTOR LEFT JOIN RADNIK
SELECT *
FROM SEKTOR, RADNIK
WHERE SEKTOR.SBROJ = RADNIK.BRSEK(+);
173
U rezultatu levog spoljanjeg spoja pojednostavljenih verzija tabela SEKTOR i

RADNIK pojavljuju se i podaci o sektoru Prodaja. U ovom sektoru nema radnika
pa se u sluaju unutranjeg spoja ne pojavljuje u rezultujuoj tabeli. U sluaju
levog spoljanjeg spoja, pojavljuje se jednom a nedostajee kolone iz desne tabele
(u ovom sluaju tabela RADNIK) postavljene su na vrednost NULL.
7.5.5 Desni spoljanji spoj (right-outer join)

Desni spoljanji spoj (Right outer join) funkcionie kao i left outer join samo je
sada uloga tabela promenjena. Desni spoljanji spoj (A RIGHT OUTER JOIN B)
pored vrsta koje ukljuuje unutranji spoj u rezultat ukljuuje vrste iz tabele B
(desne tabele) koje nemaju odgovarajuu vrstu u tabeli A (levoj tabeli). U vrstama
koje iz tabele B koje ne mogu da se upare ni sa jednom vrstom iz tabele A, kolone
iz tabele A imaju vrednost NULL.
SELECT *
FROM SEKTOR RIGHT OUTER JOIN RADNIK
SELECT *
FROM SEKTOR RIGHT JOIN RADNIK
SELECT *
FROM SEKTOR, RADNIK
WHERE SEKTOR.SBROJ (+)= RADNIK.BRSEK;
U rezultatu desnog spoljanjeg spoja pojednostavljenih verzija tabela SEKTOR

i RADNIK pojavljuju se i podaci o radniku Borivoju Veljkoviu. Ovaj radnik radi u
nepostojeem sektoru pa se u sluaju unutranjeg spoja ne pojavljuje u rezultujuoj
174
Upitni jezik SQL

tabeli. U sluaju desnog spoljanjeg spoja, pojavljuje se jednom a nedostajee
kolone iz leve tabele (u ovom sluaju tabela SEKTOR) postavljene su na vrednost
NULL.
7.5.6 Potpuni spoljanji spoj (full-outer join)

Potpuni spoljanji spoj (Full outer join) predstavlja kombinaciju rezultata koje
vraaju left outer i right outer join.
Potpuni spoljanji spoj (A FULL OUTER JOIN B) pored vrsta koje ukljuuje
unutranji spoj u rezultat ukljuuje i vrste iz obe tabele (i iz A i iz B) koje nemaju
odgovarajue slogove u drugoj tabeli. U vrstama koje ne mogu da se upare,
nedostajue kolone imaju vrednost NULL.
SELECT *
FROM SEKTOR FULL OUTER JOIN RADNIK
SELECT *
FROM SEKTOR FULL JOIN RADNIK
U rezultatu poptunog spoljanjeg spoja pojednostavljenih verzija tabela

SEKTOR i RADNIK pojavljuju se i podaci o radniku Borivoju Veljkoviu ali i
podaci o sektoru Prodaja.
Primer: Za sluaj da je neophodno kreirati spisak radnika koji rade u sektoru
'Razvoj', moe se uoiti da se informacije o radnicima nalaze u tabeli RADNIK a
da se naziv sektora uva u tabelu SEKTOR. Zahvaljujui tome to u tabeli
RADNIK postoji strani klju BRSEK koji referencira primarni klju tabele
SEKTOR, mogue je ove dve tabele povezati kako bi se dobili eljeni podaci.
Odgovarajui SQL upita je dat u nastavku:
SELECT LIME, PREZIME, NAZIV
FROM RADNIK INNER JOIN SEKTOR
ON RADNIK.BRSEK = SEKTOR.SBROJ
WHERE NAZIV = 'Razvoj';
175
Alternativni SQL upit koji vraa identian rezultat ima sledei oblik:
SELECT LIME, PREZIME, NAZIV
FROM RADNIK, SEKTOR
WHERE NAZIV = 'Razvoj'
AND RADNIK.BRSEK = SEKTOR.SBROJ;
Ovaj oblik upita podrazumeva da se u WHERE klauzuli osim uslova selekcije

NAZIV = 'Razvoj' (koji selektuje vrste koje e ui u rezultujuu tabelu) ukljuuje i
uslov spoja RADNIK.BRSEK = SEKTOR.SBROJ koji definie kako e tabele iz
FROM klauzule biti spojene.
Primer: Sledei SQL upit za radnike enskog pola odreuje imena projekata na
kojima su angaovane. Spajanje tabela u ovom upitu izvedeno je korienjem
WHERE klauzule.
Za potrebe pribavljanja traenih informacija podatke izvlaimo iz tri tabela:
RADNIK, RADI_NA i PROJEKAT. Broj tabela iz kojih izvlaimo podatke nije
niim ogranien. Potrebno je voditi rauna da spojevi izmeu tabela budu
definisani na odgovarajui nain kako bi dobili eljene podatke. Kako je ve
napomenuto spoj se najee definie izmeu spoljanjeg kljua u jednoj tabeli i
primarnog kljua koji se referencira u drugoj tabeli (RADI_NA.Radnik i
RADNIK.MatBr, RADI_NA.Projekat i PROJEKAT.Broj). Za spajanje razliitih
tabela mogu se kombinovati razliiti tipovi spoja.
SELECT R.MATBR, R.LIME, R.PREZIME, P.NAZIV
FROM RADNIK R, RADI_NA RN, PROJEKAT P
WHERE R.MATBR = RN.MBR
AND RN.BRPR = P.BROJPR
AND R.POL = '';
Napomena: Potrebno je obratiti panju da je prilikom definisanja SQL upita

iskoriena mogunost da se tabelama dodele pseudonimi radi jednostavnijeg
176
Upitni jezik SQL

zapisa. U konkretnom sluaju tabelama RADNIK, RADI_NA i PROJEKAT su
dodeljeni pseudonimi R, RN i P respektivno.
Alternativni oblikSQL naredbe koja vraa identine rezultate bi imao sledei
oblik:
SELECT R.MATBR, R.LIME, R.PREZIME, P.NAZIV
FROM RADNIK R INNER JOIN RADI_NA RN
ON R.MATBR = RN.MBR
INNER JOIN PROJEKAT P
ON RN.BRPR = P.BROJPR
WHERE R.POL = '';
Primer: SQL upit koji za sve projekte locirane u Niu prikazuje broj projekta,
broj sektora koji ga izvodi i ime, prezime i datum roenja rukovodioca ima sledei
oblik:
SELECT BROJPR, BRS, LIME,PREZIME, DATRODJ
FROM PROJEKAT INNER JOIN SEKTOR
ON SBROJ = BRS
INNER JOIN RADNIK
ON MATBR = MATBRR
WHERE LOKPR = 'Ni';

oblik:
SELECT BROJPR, BRS, LIME,PREZIME,DATRODJ
FROM PROJEKAT, SEKTOR, RADNIK
WHERE SBROJ = BRS
AND MATBR = MATBRR
AND LOKPR = 'Ni';
Primer: U nastavku je dat SQL upit koji za svakog radnika prikazuje ime i
prezime kao i ime i prezime njegovog efa:
SELECT X.LIME, X.PREZIME, Y.LIME, Y.PREZIME
FROM RADNIK X INNER JOIN RADNIK Y
ON X.MATBRS = Y.MATBR;
177
Ovaj SQL upit je karakteristian po tome to se javlja spoj koji je posledica

postojanja rekurzivne veze. Tabela RADNIK sadri strani klju MATBRS koji
referencira primarni klju u istoj tabeli odnosno u tabeli RADNIK. Zbog toga se u
upitu tabela RADNIK pojavljuje dva puta. Da bi to bilo mogue, obavezno je
korienje pseudonima tj. svakoj kopiji tabele RADNIK potrebno je obezbediti
poseban sinonim.
oblik:
SELECT X.LIME, X.PREZIME, Y.LIME, Y.PREZIME
FROM RADNIK X, RADNIK Y
WHERE X.MATBRS = Y.MATBR;
7.5.7 Klauzule GROUP BY i HAVING

Funkcije agregacije imaju zadatak da omogue generisanje sumarnih
informacija na osnovu podataka u relacionoj bazi podataka.
Klauzula GROUP BY ima zadatak da omogui grupisanje vrsta u rezultujuoj
tabeli na osnovu zajednikih vrednosti. Time se poveava vrednost funkcija
agregacije jer se u kombinaciji sa GROUP BY klauzulom mogu primenjivati na
odreene grupe vrsta a ne samo na itavu rezultujuu tabelu
Potrebno je voditi rauna, da ukoliko ne postoji GROUP BY klauzula, u
SELECT klauzuli nije mogue kombinovati funkcije agregacije sa imenima
kolona. U nastavku je dat SQL upit koji NE MOE DA SE IZVRI i koji e
dovesti do POJAVE GREKE.
SELECT MATBR, LIME, PREZIME, SUM(Plata)
FROM RADNIK;
Ovaj upit je mogu samo uz upotrebu GROUP BY klauzule.

Klauzula GROUP BY zahteva od DBMS-a da izvri sortiranje rezultujue
tabele prema specificiranim kolonama i izvri grupisanje vrsta koje imaju iste
vrednosti za specificirane kolone. Ukoliko su prisutne funkcije agregacije one e se
primeniti na tako dobijene grupe. Tek uz prisustvo GROUP BY klauzule mogue
je u SELECT klauzuli kombinovati imena kolona i funkcije agregacije.
178
Upitni jezik SQL

Bitno je da napomenuti da se klauzula GROUP BY izvrava nakon klauzule
WHERE odnosno da se grupisanje vri tek nakon to su odreene vrste koje treba
da uu u sastav rezultujue tabele.
Primer: U nastavku je dat primer SQL upita koji za svaki sektor rauna broj
radnika koji rade u njemu. Za grupisanje radnika po broju sektora u kome radi
iskoriena je GROUP BY klauzula.
SELECT BRSEK, COUNT(*)
FROM RADNIK
GROUP BY BRSEK;
Klauzula HAVING se koristi za filtriranje podataka rezultata dobijenih

korienjem GROUP BY klauzule i funkcija agregacije. Ova klauzula primenjuje
uslov filtriranje na formirane grupe.
Primer: SQL upit iz prethodnog primera je modifikovan, korienjem
HAVING klauzule, tako da su prikazani podaci samo o sektorima koji imaju vie
od jednog radnika.
FROM RADNIK
GROUP BY BRSEK
HAVING COUNT(*) > 1;
Klauzule GROUP BY i HAVING je mogue kombinovati sa WHERE

klauzulom. Pri tome treba voditi rauna o redosledu izvravanja (isti je redosled po
kome se klauzule reaju prilikom pisanja SELECT naredbe):
1. WHERE primenjuje se predikat koji odreuje vrste koje ulaze u sastav
rezultujue tabele
2. GROUP BY - vri se grupisanje vrsta u rezultujuoj tabeli
3. HAVING primenjuje se predikat koji odreuje vrste koje e ostati u
rezultatu upita
4. ORDER BY sortiranje rezultata se vri tek na kraju
179

Primer: SQL upit koji prikazuje brojeve sektora u kojima radi vie od jednog
radnika enskog pola ima sledei oblik:
FROM RADNIK
WHERE POL = ''
GROUP BY BRSEK
Klauzulu GROUP BY je mogue primeniti istovremeno na vei broj kolona.

Pri tome su kriterijum za formiranje grupa zajednike vrednosti u specificiranim
kolonama. Prilikom formiranja grupa vodi se rauna i o redosledu po kome su
kolone za grupisanje navedene (kao da se formiraju grupe sa podgrupama u okviru
njih).
Primer: U nastavku je dat SQL upit koji za svaki sektor prikazuje prosenu
zaradu po polovima.
SELECT BRSEK, POL, ROUND(AVG(PLATA), 2) AS PROSEK_PLATA
FROM RADNIK
GROUP BY BRSEK, POL
ORDER BY AVG(PLATA);
Napomena: Prilikom korienja klauzule GROUP BY, sve kolone koje su

navedene u klauzuli SELECT a na koje nije primenjena neka funkcija agregacije,
MORAJU BITI NAVEDENE U GROUP BY KLAUZULI. U suprotnom SQL
upit nee moi da se izvri.
Primer: SQL upit koji prikazuje naziv sektora i broj radnika koji rade u njima
dat je u nastavku:
SELECT S.SBROJ, S.NAZIV, COUNT(*) AS BROJ_RADNIKA
FROM SEKTOR S INNER JOIN RADNIK R
ON S.SBROJ=R.BRSEK
GROUP BY S.SBROJ, S.NAZIV;
180
Upitni jezik SQL
Primer: Naredni SQL upit za svaki sektor daje ukupan broj radnih sati koje
radnici provode na projektima za koje je taj sektor zaduen.
SELECT S.SBROJ, S.NAZIV, SUM(SATI) AS SATI_UKUPNO
FROM SEKTOR S INNER JOIN PROJEKAT P
ON S.SBROJ = P.BRS
INNER JOIN RADI_NA RN
ON P.BROJPR = RN.BRPR
GROUP BY S.SBROJ, S.NAZIV;
Primer: U nastavku je dat SQL upit koji za sve projekte koji imaju vie od dva
angaovana radnika prikazuje broj projekta, ime projekta i broj radnika koji na
njemu rade.
SELECT BROJPR, NAZIV, COUNT(*)
FROM PROJEKAT, RADI_NA
WHERE BROJPR = BRPR
GROUP BY BROJPR, NAZIV
7.5.8 Kombinovanje rezultata vie SQL upita

Programski jezik SQL dozvoljava kombinovanje rezultata veeg broj SQL upit
korienjem operacija za rad sa skupovima: unija (UNION), presek
(INTERSECT) i razlika (MINUS).
Klauzula UNION kombinuje rezultate dva ili vie upita u jednu rezultujuu
tabelu. Rezultati upita koji se kombinuju moraju imati kolone koje se slau po
broju (isti broj kolona), redosledu (odgovarajue kolone se nalaze na istim
pozicijama) i tipu (odgovarajue kolone moraju da imaju kompatibilne tipove).
Klauzula UNION kombinuje rezultate dva ili vie upita u jednu rezultujuu
tabelu. U rezultujuu tabelu ulaze svi slogovi iz svih rezultujuih tabela. Prilikom
izvravanje operacije UNION elimiu se duplikati. To znai da se slog koji se
181

pojavljuje u vie rezultujuih tabela, u rezultatu unije pojavljuje samo jednom.Zbog
toga je potrebno voditi rauna da rezultujue tabele koje se spajaju moraju da
ukljuuju atribute neophodne za jednoznanu identifikaciju slogva.
Primer: Potrebno je napisati SQL upit koji vraa nazive sektora u kojima rade
radnici koji se prezivaju 'Petrovi' i 'Jovanovi'. Ovaj problem moe da se rei tako
to se podeli na dva manja problema. Najpre se odrede nazivi sektora u kojima rade
radnici koji se prezivaju 'Petrovi', a zatim nazivi sektora u kojima rade radnici
koji se prezivaju 'Jovanovi'. Kombinovanjem ova dva rezultata dobijaju se eljeni
podaci.
SQL upit koji odreuje nazive sektora u kojima rade radnici koji se prezivaju
'Petrovi'.
SELECT DISTINCT NAZIV
FROM SEKTOR, RADNIK
WHERE SBROJ = BRSEK AND PREZIME = 'Petrovi';
SQL upit koji odreuje nazive sektora u kojima rade radnici koji se prezivaju
'Jovanovi'.
FROM SEKTOR, RADNIK
WHERE SBROJ = BRSEK AND PREZIME = 'Jovanovi';
Kombinovanjem ova dva upita korienjem klauzule UNION dobija se traeni

rezultat.
FROM SEKTOR, RADNIK
WHERE SBROJ = BRSEK AND PREZIME = 'Petrovi'
UNION
FROM SEKTOR, RADNIK
182
Upitni jezik SQL
Napomena: Bitno je uoiti da sektor 'Razvoj' koji se javlja kao rezultat i jednog
i drugog upita u uniji se pojavljuje samo jednom. To je posledica injenice da unija
eliminie sve duplikate iz rezultujue tabele.
Primer: SQL upit u nastavku prikazuje kako se korienjem
klauzule UNION moe implementirati full-outer join spoj.
SELECT *
FROM SEKTOR LEFT OUTER JOIN RADNIK
ON SEKTOR.SBROJ=RADNIK.BRSEK
UNION
SELECT *
FROM SEKTOR RIGHT OUTER JOIN RADNIK
ON SEKTOR.SBROJ=RADNIK.BRSEK;
Primer: U nastavku su dati POGRENO NAPISANI UPITI, koji ne mogu da

se kombinuju jer nema slaganja po tipu kolona.
FROM SEKTOR, RADNIK
UNION
SELECT DISTINCT SBROJ
FROM SEKTOR, RADNIK

se kombinuju jer nema slaganja po broju kolona.
FROM SEKTOR, RADNIK
UNION
SELECT DISTINCT SBROJ, NAZIV
FROM SEKTOR, RADNIK

se kombinuju jer nema slaganja po redosledu i tipu kolona.
SELECT DISTINCT NAZIV, SBROJ
FROM SEKTOR, RADNIK
UNION
183

SELECT DISTINCT SBROJ, NAZIV
FROM SEKTOR, RADNIK
Klauzula INTERSECT vraa samo vrste koje se javljaju u rezultujuim

tabelama svih SQL upita koji se kombinuju.
Primer: Za kreiranje spiska radnika koji rade u sektoru 'Administracija' i koji
imaju platu veu od 40000 mogue je iskoristiti dva SQL upita iji su rezultati
iskombinovani korienjem klauzule INTERSECT.
U nastavku je dat SQL upit koji vraa podatke o radnicima koji rade u sektoru
Administracija'.
FROM SEKTOR, RADNIK
WHERE SBROJ = BRSEK AND NAZIV = 'Administracija';
Naredni SQL upit vraa podatke o radnicima ija je plata vea od 40000.
FROM RADNIK
WHERE PLATA > 40000;
Traeni rezultat se dobija kombinovanjem rezultata ova dva upita korienjem

klauzule INTERSECT. U rezultatu se nalaze samo vrste koji se pojavljuju u
rezultujuim tabelama oba pojedinana upita upita.
FROM SEKTOR, RADNIK
WHERE SBROJ = BRSEK AND NAZIV = 'Administracija'
INTERSECT
FROM RADNIK
184
Upitni jezik SQL
Klauzula MINUS vraa samo one vrste koje se javljaju u rezultatu provg SQL
upita ali se ne javljaju i u rezultatima ostalih SQL upita.
Primer: Ukoliko je potrebno pribaviti podatke podake o radnicima koji rade u
sektoru 'Administracija' a nemaju platu veu od 40000, mogue je iskoristiti upit iz
prethodnog primera. SQL upit iz prethodnog primera treba modifikovati tako da se
umesto klauzule INTERSECT koristi klauzula MINUS.
FROM SEKTOR, RADNIK
WHERE SBROJ = BRSEK AND NAZIV = 'Administracija'
MINUS
FROM RADNIK
7.5.9 Ugnjedeni upiti

ORACLE SQL nudi razliite mehanizme za ugnjedavanje upita. Jedan od
mehanizama su takozvani virtuelni pogledi. Ovaj mehanizam omoguava
ugnjedavanje jednog SQL upita u FROM klauzuli drugog SQL upita. Ugnjedeni
SQL upit se u tom sluaju ponaa kao i bilo koja druga tabela iz baze podataka.
Primer: Za formiranje spiska radnika ija je plata, nakon uveanja, vea od
40000 mogue je iskoristiti mehanizam virtuelnih pogleda.
SELECT MATBR, LIME, PREZIME, UVECANA_PLATA
FROM (SELECT MATBR, LIME, PREZIME, PLATA + 5000 AS UVECANA_PLATA
FROM RADNIK)
WHERE UVECANA_PLATA > 40000;
Rezultat ugnjedenog upita koji kreira spisak radnika sa platama uveanim za

5000:
Spisak radnika ija je plata, nakon poveanja od 5000, vea od 40000:

185
Za ugnjedavanje upita mogue je iskoristiti i operator IN. U tom sluaju

ugnjedeni upit dinamiki generie skup vrednosti koje IN operator proverava.
Primer: Spisak radnika koji se nalaze na poziciji rukovodioca sektora moe se
kreirati koirenjem SQL upita koji je dat u nastavku.
FROM RADNIK
WHERE MATBR IN (SELECT MATBRR FROM SEKTOR);
Alternativno upit se moe napisati i na sledei nain:

FROM RADNIK
WHERE MATBR IN (333445555, 888665555, 987654321);
Prednost korienja ugnjedenog upita je ogromna jer se skup vrednosti

generie dinamiki, a samim tim e uvek uzimati u obzir aurne podatke iz baze
podataka.
Za ugnjedavanje upita mogue je iskoristiti i klauzulu EXISTS. Ova klauzula
proverava da li ugnjedeni upit vraa rezultujuu tabelu koja sadri vrste ili ne.
Primer: SQL upit koji je dat u nastavku pribavlja podatke o radnicima koji
imaju lanove porodice.
FROM RADNIK
WHERE EXISTS (SELECT IME
FROM CLAN_PORODICE
WHERE CLAN_PORODICE.MATBRRAD = RADNIK.MATBR);
186
Upitni jezik SQL

Da bi operator EXISTS funkcionisao na pravilan nain vrlo esto se javlja
potreba da ugnjedeni upit poveemo (koreliemo) sa spoljanjim upitom. U ovom
konkretno
sluaju
korelisanje
se
obavlja
uz
pomo
uslova
CLAN_PORODICE.MATBRRAD = RADNIK.MATBR. Zahvaljujui dodatnom
uslovu spoljanji i u gnjedeni upit su povezani i ugnjedeni upit vraa podatke
samo za konkretnog radnika odnosno vraa lanove porodice (ukoliko postoje)
samo za konretnog radnika. U spoljanjem upitu se za svakog radnika uz pomo
operatora EXISTS proverava d ali ugnjedeni upit vraa rezultujuu tabelu sa
vrstama odnosno da li radnik ima lanove porodice ili ne.
Ukoliko se izostavi uslov korelisanja dobio bi se upit koji NE VRAA
TRAENE PODATKE.
FROM RADNIK
WHERE EXISTS (SELECT IME FROM CLAN_PORODICE);
Ukoliko se analiziraju rezultati nekorelisanog upita, moe da se zakljui da su

vraeni podaci o svim radnicima bez obzira na to da li imaju lanove porodice ili
ne. Problem je nepostojanje korelacije izmeu spoljanjeg upita i ugnjedenog
upita. U ovom sluaju, kad god se proverava da li radnik ima lanove porodice ili
ne, ugnjedeni upit uvek vraa isti rezultat (sve lanove porodice). Zbog toga
EXISTS ima vrednost TRUE kod vsakog radnika odnosno rezultujua tabela
sadri podatke o svim radnicima.
Primer: Modifikacijom SQL upita iz prethodnog primera moe se dobiti upit
koji pribavlja podatke o radnicima koji nemaju lanove porodice.
FROM RADNIK
WHERE NOT EXISTS (SELECT 0
FROM CLAN_PORODICE
WHERE CLAN_PORODICE.MATBRRAD = RADNIK.MATBR);
187
Napomena: Potrebno je uoiti da ugnjedeni upit vraa samo konstantu

vrednost 0. Ovakvo reenje se primenjuje jako esto kada nisu neophodni podaci iz
ugnjedenog upita ve samo elimo da proverimo da li oni postoje ili ne.
Primer: Za pribavljanje podataka o radnicima koji imaju vie od dva lana
porodice mogue je iskoristiti SQL upit koji je dat u nastavku.
FROM RADNIK
WHERE (SELECT COUNT(*)
FROM CLAN_PORODICE
WHERE RADNIK.MATBR = CLAN_PORODICE.MATBRRAD) >= 2;
Neophodno je uoiti da su ugnjedeni i spoljanji upit korelisani.

Primer: U nastavku je dat SQL upit koji kreira listu projekata u koje je ukljuen
radnik sa imenom 'Petrovi' kao radnik ili rukovodilac sektora koji izvodi projekte.
FROM PROJEKAT
WHERE BROJBR IN (SELECT BROJPR
FROM PROJEKAT, SEKTOR, RADNIK
WHERE BRS = SBROJ
AND MATBR = MATBRR
AND PREZIME = 'Petrovi')
OR BROJPR IN (SELECT BRPR
FROM RADI_NA, RADNIK
WHERE MBR = MATBR
AND PREZIME = 'Petrovi');
188
Upitni jezik SQL

Primer: Naredni SQL upit pribavlja podatke o radnicima koji su na poziciji
rukovodioca sektora i imaju bar jednog lana porodice.
FROM RADNIK
WHERE EXISTS (SELECT *
FROM CLAN_PORODICE
WHERE MATBR = MATBRRAD)
AND EXISTS (SELECT *
FROM SEKTOR
WHERE MATBR = MATBRR);
7.5.10 Pseudo kolona ROWNUM

ORACLE DBMS svim rezultujuim tabelama koje se dobijaju izvravanjem
SQL upita pridruuje pseudo kolona pod nazivom ROWNUM. Ova pseudo kolona
sadri redni broj vrste u rezultujuoj tabeli. Brojanje poinje poinje od 1. Oracle
dodeljuje redni broj nakon filtriranja koje se vri na osnovu uslova selekcije iz
WHERE klauzule. ROWNUM kolona se moe koristit po slinom principu kao i
ostale kolone iz rezultujue tabele.
SELECT ROWNUM, LIME, PREZIME
FROM RADNIK
WHERE ROWNUM < 5;
ORACLE DDBMS dodeluje vrstama vrednosti ROWNUM kolone u trenutku

pribavljanja. Nepoznavanje ovo injenice moe da dovede do zabuna i
neoekivanih rezultata.
Primer: SQL upit koji je dat u nastavku nee vratiti ni jednu rezultujuu vrstu
zbog neadekvatnog naina na koji se koristi ROWNUM kolona.
SELECT *
FROM RADNIK
WHERE ROWNUM > 1;
189

Prilikom pribavljanja podataka, prva rezultujua vrsta koju treba pribaviti ima
ROWNUM = 1, pa samim tim ne zadovoljava uslov. Kao posledica dolazi do toga
da vrst anije pribavljena, odnosno ROWNUM i dalje ostaje 1. Naredna vrsta koju
treba pribaviti dobija ROWNUM 1 i nee biti pribavljen poto ne zadovoljava
uslov a ROWNUM i dalje ostaje 1. Zbog toga ni jedan red ne moe da zadovolji
uslov odnosno nema redova u rezultatu upita.
Pseudo kolona ROWNUM se esto koristi za kreiranje takozvanih top-N upita
odnosno SQL upita koji treba da vrate prvih N vrsta iz neke rezultujue tabele.
Primer: Tipian primer top-N upita moe da bude pribavljanje podataka o pet
radnika koji imaju najveu platu u firmi. Zbog neadekvatnog korienja
ROWNUM kolone, upit koji je dat u nastavku NEE PRIBAVITI oekivane
rezultate.
SELECT ROWNUM, LIME, PREZIME, PLATA
FROM RADNIK
WHERE ROWNUM <= 5
ORDER BY PLATA DESC;
Rezultujua tabela sa izmeanim vrednostima ROWNUM kolone:
Rezultat koji se dobija je netaan a posebno su interesantne izmeane vrednosti

u ROWNUM koloni. Oov je posledica injenice da se vrednost ROWNUM kolone
dodaje prilikom pribavljanja a pre sortiranja.
U nastavku je dato SQL upit koji na pravilan nain koristi ROWNUM kolonu i
pribavlja tane rezultate.
Primer: Podaci o pet radnika koji imaju najveu platu
SELECT ROWNUM, LIME, PREZIME, PLATA
FROM (SELECT LIME, PREZIME, PLATA
FROM RADNIK
ORDER BY PLATA DESC)
WHERE ROWNUM <= 5;
190
Upitni jezik SQL

U unutranjem upitu e ROWNUM vrednosti biti izmeane zato to su
generisane pre sortiranja. Ova ROWNUM kolona se NE KORISTI! Spoljanji
upit pribavlja redove iz rezultata ugnjedenog upita i u tom procesu se generiu
nove vrednosti za ROWNUM kolonu i te vrednosti se koriste u spoljanjem upitu.
Primer: U nastavku je dat SQL upit koji pribavlja podatke o radniku koji ima
najvie lanova porodice.
FROM (SELECT LIME, PREZIME, COUNT(*) AS BR_CLANOVA
FROM RADNIK, CLAN_PORODICE
WHERE RADNIK.MATBR = CLAN_PORODICE.MATBRRAD
GROUP BY LIME, PREZIME
ORDER BY BR_CLANOVA DESC)
WHERE ROWNUM = 1;
Ovako reenje ima jedan potencijalni nedostatak. To je situacija u kojoj vei

broj radnika koji zadovoljavaju uslov odnosno imaju isti najvei broj lanova
porodice. Zbog toga u nekim situacijama treba iskoristiti alternativno reenje koje
je dato u nastavku:
SELECT LIME, PREZIME, COUNT(*) AS BR_CLANOVA
GROUP BY LIME, PREZIME
HAVING COUNT(*) = (SELECT MAX(COUNT(*))
GROUP BY LIME, PREZIME);
Rezultat su svi radnici koji zadovoljavaju uslov da imaju najvei broj lanova
porodice:
Kada se pogleda ova rezultujua tabela, moe se uoiti da su sada ukljueni svi
radnici koji zadovoljavaju uslov bez obzira na njihov broj.
7.5.11 Klauzula CONNECT BY...START WITH

Klauzula CONNECT BY...START WITH se koristi za pribavljanje podataka
koji imaju hijerarhijske relacije tipa roditelj->dete (npr. ef->radnik, ureaj->deo).
191

Ovakve relcije su posledica postojanja rekurzivnih veza u okviru ER modela.
Klauzula START WITH odreuje vor od koga se kree sa formiranjem hijerarhije
odnosno odreuje koren hijerarhije. Klauzula PRIOR odreuje uslov povezivanja
izmeu roditeljskih vorova i vorova dece u hijerarhiji.
Primer: U nastavku je dat SQL upit koji prikazuje hijerarhijsku organizaciju
preduzea.
SELECT LIME, PREZIME, LEVEL
FROM RADNIK
CONNECT BY PRIOR MATBR = MATBRS
START WITH LIME = 'Jovan';
U prethodnom primeru klauzulom START WITH je definisano da e koren

hijerarhije biti radnik ije je ime 'Jovan' a uz pomo klauzule PRIOR je
definisano da se hijerarhija uspostavlja od radnika na vie nivou (od efova) ka
radnika na niem nivou. Pored toga iskoriena je i pseudo kolona LEVEL da se
prikae hijerarhijski nivo na kome se radnik nalazi.
Primer: Naredni SQL upit promenom uslova u klauzuli PRIOR menja nain
organizovanja hijerarhije. U ovom sluaju hijerarhija se organizuje od radnika ka
nadreenim efovima.
SELECT LIME, PREZIME, LEVEL
FROM RADNIK
CONNECT BY PRIOR MATBRS = MATBR
START WITH LIME = 'Stanko';
7.6 SQL naredbe za manipulaciju podacima

Ova sekcija se odnosi na ostatak DML naredbi odnosno obradiemo naredbe
koje omoguavaju modifikaciju podataka u relacionoj bazi podataka.
Postoje tri mogue operacije za modifikovanje podataka:
192
Upitni jezik SQL

1. Dodavanje novih podataka (dodavanje novih vrsta u tabelu)
2. Auriranje podataka (izmena vrednosti kolona u postojeim vrstama tabele)
3. Brisanje podataka (brisanje vrsta iz tabele)
7.6.1 Dodavanje novih podataka

Za dodavanje podataka u tabelu koristi se SQL naredba INSERT...INTO.
Naredba INSERT...INTO dodaje nove vrste u tabelu relacione baze podataka.
Vrednosti kolona se definiu zadavanjem vrednosti u obliku konstanti ili
korienjem rezultata SQL upita. U zavisnosti od naina zadavanja vrednosti
kolona postoje razliiti oblici INSERT..INTO naredbe.
Svi primeri u nastavku e biti razmatrani za sluaj tabele PROJEKAT. U
nastavku je data CREATE TABLE naredba koja je iskoriena za kreiranje ove
tabele kao i test podaci dati u prethodnim odeljcima ovog poglavlja.
(
BROJPR NUMBER(3),
BRS NUMBER(2) NOT NULL,
CONSTRAINT PROJEKATPK PRIMARY KEY (BROJPR),
CONSTRAINT NadlezanFK FOREIGN KEY (BRS)
);
U nastavku je dat oblik INSERT..INTO naredbe koji se koristi u situacijama

kada se vrednosti kolona zadaju korienjem konstanti.
INSERT INTO <ime_tabele>
[(<ime_kolone1> [,<ime_kolone2>]...)]
VALUES (<vrednost_kolone1> [{, <vrednost_kolone2>}...]);
Iz definicije moemo zakljuiti da je lista kolona opciona. Ukoliko je lista

kolona izostavljena, u listi vrednosti kolona moraju se navesti vrednosti za svaku
kolonu koja postoji u tabeli u koju se dodaje nova vrsta. U tom sluaju lista
vrednosti kolona mora da odgovara redosledu kojim su kolone navedene prilikom
kreiranja tabele (u CREATE TABLE naredbi). Takoe, vrednosti kolona, moraju
biti kompatibilne po tipu sa tipovima podataka koji su za kolone navedeni prilikom
kreiranja tabele.
193

Primer: U nastavku je data SQL naredba kojom se dodaje nova vrsta u tabelu
PROJEKAT. Dodaju se informacije o projektu iji je broj 100, zove se ProizvodA,
lociran je u Prokuplje i za njega je zaduen sektor iji je broj 5.
INSERT INTO PROJEKAT
VALUES ('ProizvodA', 'Prokuplje', 100, 5);
Ukoliko se u INSERT...INTO naredbi zadaje lista kolona, mogue je promeniti

redosled zadavanja kolona u odnosu na onaj koji je specificiran u CREATE
TABLE naredbi.
Primer: Za dodavanje novog projekta iji je broj 101, zove se ProjekatB,
lociran je u Svrljigu i za njega je zaduen sektor broj 4 moe se iskoristiti naredna
SQL naredba.
(NAZIV, BROJPR, BRS, LOKPR)
VALUES ('ProizvodB', 101, 4, 'Svrljig');
Prilikom dodavanja nove vrste u tabelu bie proverena sva ogranienja koja su
definisana nad tabelom: tip podataka, duina polja, primarni klju, NOT NULL,
CHECK... Ukoliko bar jedno ogranienje nije zadovoljeno DBMS e prijaviti
poruku o greci i nee izvriti naredbu.
Lista kolona u pojedinim sluajevima ne mora biti kompletna. Iz liste se mogu
izostaviti kolone kod kojih nije definisano NOT NULL ogranienje i kolone koje
imaju definisano DEFAULT ogranienje. Za istovljene kolone se upisuje
podrazumevana vrednost definisana DEFAULT ogranienjem ili se upisuje NULL
vrednost ukoliko DEFAULT ogranienje ne postoji.
194
Upitni jezik SQL

Primer: U narednom primeru iz liste kolona je izbaena kolona LOKPR.
(NAZIV, BROJPR, BRS)
VALUES ('ProizvodC', 102, 5);
Poto je u tabeli za kolonu LOKPR definisano DEFAULT ogranienje,

prilikom dodavanja nove vrste u tu kolonu e biti upisana vrednost 'Ni'. Da
DEFAULT ogranienje ne postoji u kolonu Lokacija bi bila upisana vrednost
NULL. Za sluaj da je nad kolonom LOKPR definisano NOT NULL ogranienje,
DBMS bi generisao odgovarajuu greku i naredba za dodavanje novog projekta ne
bi imala efekta.
Ukoliko se vrednosti kolona zadaju
INSERT...INTO ima neto drugaiji oblik.
korienjem
upita,
naredba
INSERT INTO <ime_tabele>

[(<ime_kolone1> [,<ime_kolone2>]...)]
<upit>;
U ovom sluaju za listu kolona vae ista pravila kao i u prethodnim situacijama.
Vrednosti kolona se sada ne zadaju kako konstante ve se zadaju kao rezultujua
tabela nekog upita. Redosled i tip kolona u rezultujuoj tabeli upita mora da
odgovara redosledu i tipu kolona u listi.
Primer: U nastavku je dat primer INSERT...INTO naredbe koja koristi SQL
upit da bi u fiktivnu tabelu PROJEKAT_NEW dodala podatke iz tabele
PROJEKAT.
CREATE TABLE PROJEKAT_NEW
(
BROJ NUMBER(3),
LOKACIJA VARCHAR(15)
);
INSERT INTO PROJEKAT_NEW
(BROJ, NAZIV, LOKACIJA)
SELECT BROJPR, NAZIV, LOKPR
FROM PROJEKAT;
195
Primer: U nastavku je dat SQL upit za kreiranje nove tabele na osnovu

podataka koji vraa naredba SELECT. Bitno je uoiti da kreirana tabela nema
nijedno ogranienja (mi primarni klju).
CREATE TABLE SEK_INFO
AS SELECT NAZIV, COUNT(*), AVG(PLATA)
FROM SEKTOR, RADNIK
WHERE BRSEK = SBROJ
GROUP BY NAZIV;
7.6.2 Auriranje podataka

Za auriranje podataka se koristi SQL naredba UPDATE...SET. Osnovni oblik
ove komande je dat unastavku.
UPDATE <ime_tabele>
SET <ime_kolone> = <izraz> [,<ime_kolone> = <izraz>...]
[WHERE <uslov>];
Klauzula SET definie u kojoj se koloni menja vrednost definisana zadatim

izrazom. Izraz moe bti konstantna vrednost, vrednost nekog izraza ili vrednost
koju vraa SQL upit.
Ako se navede WHERE klauzula, auriranje se vri samo za kolone koje
ispunjavaju navednost nekog navedenog uslova.
Primer: U nastavku je dat SQL upit koji lokacije projekta iji je broj 101 menja
na vrednost 'Beograd'.
UPDATE PROJEKAT
SET LOKPR = 'Beograd'
WHERE BROJPR = 101;
Napomena: Treba biti jako oprezan prilikom korienja UPDATE...SET

naredbe. UKOLIKO SE U PRETHODNOM PRIMERU IZOSTAVI WHERE
196
Upitni jezik SQL

KLAUZULA ILI USLOV NIJE DOBRO DEFINISAN, LAKO MOEMO DA
IZMENIMO I VRSTE KOJE NISMO ELELI DA MENJAMO, ODNOSNO DA
IZGUBIMO NEKE DRAGOCENE PODATKE.
Korienjem UPDATE...SET naredbe mogue je istovremeno menjati vrednosti
veeg broja kolona.
Primer:U sledeem primeru svi projekti koji u nazivu sadre re 'Proizvod' se
premetaju u Ni u nadlenost sektora broj 4.
UPDATE PROJEKAT
SET LOKPR = 'Ni', BRS = 4
WHERE NAZIV LIKE '%Proizvod%';
Primer: U nastavku je dat SQL upit kojim se projekat broj 3 prebacuje u

Beograd u nalenost sektora broj 5.
UPDATE PROJEKAT
SET LOKPR = 'Beograd', BRS = 5
WHERE BROJPR= 3;
Primer: Izmene nad podacima kojima se projekti za koje je zaduen sektor broj
4 prbacuju u nadlenost sektora 'Razvoj'.
UPDATE PROJEKAT
SET BRS = (SELECT SBROJ
FROM SEKTOR
WHERE NAZIV ='Razvoj')
WHERE BRS = 4;
197
7.6.3 Brisanje podataka

Za brisanje podataka iz relacione baze podataka koristi se naredba DELETE.
U svom osnovnom obliku naredba DELETE ima sledeu sintaksu:
DELETE FROM <ime_tabele>
[WHERE <uslov>];
Primer: SQL naredba kojom se iz tabele PROJEKAT briu podaci o svim

projektima iji se naziv zavrava slovom 'A' data je u nastavku.
DELETE
FROM PROJEKAT
WHERE NAZIV LIKE '%A';
Uslov koji navedete u WHERE definie kriterijume za selekciju torki koje

treba obrisati iz zadate tabele. AKO SE NE NAVEDE WHERE KLAUZULA,
NAREDBA DELETE BRIE SVE VRSTE IZ TABELE IJE SE IME
NAVEDE U FROM KLAUZULI. Zbog toga treba biti jako oprezan prilikom
korienja naredbe DELETE. Ukoliko izostavite uslov ili je uslov neadekvatno
definisan moe doi do trajnog brisanja podataka koje nismo eleli da obriemo.
Primer: U nastavku je data SQL naredba koja brie podatke o svim projektima.
DELETE
FROM PROJEKAT;
198
Upitni jezik SQL

Primer: SQL naredba koja je data u nastavku brie podatke o svim projektima
za koje je zaduen sektor broj 1.
DELETE
FROM PROJEKAT
WHERE BRS = 1;
Primer: Za brisanje podataka o svim projektima koji su locirani u 'Beogradu' ili

'Novom Sadu' i za koje je zaduen sektor 'Administracija' moe se iskoristiti SQL
naredba koja je data u nastavku.
DELETE FROM PROJEKAT
WHERE LOKPR IN ('Beograd', 'Novi Sad')
AND BRS = (SELECT SBROJ
FROM SEKTOR
WHERE NAZIV = 'Administracija');
Primer: U nastavku je data SQL naredba koja brie podatke o svim projektima
na kojima nije angaovan nijedan radnik.
WHERE BROJPR NOT IN (SELECT BRPR
FROM RADI_NA);
Takoe, kao alternativno reenje koje ima isti efekat mogue je iskoristiti i
sledeu SQL naredbu.
WHERE NOT EXISTS (SELECT 0
FROM RADI_NA
WHERE RADI_NA.BRPR = PROJEKAT.BROJPR);
Prilikom korienja naredbe DELETE treba voditi rauna i o efektima koji

mogu da se jave kao posledica postojanja ogranienja stranog kljua. Moemo za
primer uzmemo tabele RADNIK i SEKTOR iz baze podataka PREDUZEE, i da
pokuamo da obriemo podatke o sektoru iji je naziv 'Administracija'.
DELETE
FROM SEKTOR
WHERE Naziv = 'Administracija';
Izvravanjem ove naredbe mogue je da se javi jedna od naredne tri situacije:

1. Ukoliko u tabeli radnik ne postoje radnici koji rade u sektoru
'Administracija', iz tabele SEKTOR bie obrisani podaci o sektoru iji je
naziv 'Administracija'.
199

2. Ukoliko u tabeli RADNIK postoje radnici koji rade u sektoru
'Administracija' i strani klju je definisan korienjem opcije ON
DELETE NO ACTION, DBMS e prijaviti greku i nee izvriti
brisanje. Brisanje u ovom sluaju nije mogue jer bi u tabeli RADNIK
dobili vrste koje referenciraju nepostojei sektor ime bi bio naruen
referencijalni integritet.
3. Ukoliko u tabeli radnik postoje radnici koji rade u sektoru 'Administracija'
i strani klju je definisan korienjem opcije ON DELETE CASCADE, iz
tabele SEKTOR bie obrisani podaci o sektoru iji je naziv
'Administracija' ali e i iz tabele RADNIK biti obrisani podaci o
radnicima koji rade u sektoru 'Administracija. Za razliku od prethodnog
sluaja gde e DBMS spreiti brisanje da ne bi dolo do naruavanja
referencijalnog integriteta, u ovom sluaju DBMS automatski brie sve
podatke kod kojih moe doi do naruavanja referencijalnog
integriteta. Ovo je jo jedan razlog vie zbog ega treba biti jako oprezan
prilikom korienja DELETE naredbe.
7.7 Naredbe za rad sa pogledima

Pogled u bazi podataka predstavlja logiku tabelu koja se kreira na osnovu
jedne ili vie tabela ili drugih pogleda. Pogled se tretira kao virtuelna tabela koja
sadri podatke koji predstavljaju rezultat izvravanja uskladitenog upita. Pogled
ne postoji fiziki, odnosno podaci se ne dupliraju.
Prilikom svakom pristupanja pogledu njegovi podaci se formiraju dinamiki
izvravanjem uskladitenog upita.
Osnovni oblik naredbe za kreiranje pogleda dat je u nastavku:
CREATE VIEW <ime_pogled>
AS <upit>;
Kreirani pogled moe se obrisati korienjem naredne SQL naredbe:

DROP VIEW <ime_pogled>;
U nastavku su date neke od prednosti korienja pogleda:

pogled moe da sadri samo podskup podataka iz tabele
200
pogled moe da spoji podatke iz veeg broja tabela u jednu virtuelnu

tabelu
Upitni jezik SQL
pogled moe da sadri podatke koji predstavljaju rezultat izvravanja

funkcija (artimetike funkcije, funkcije za rad sa stringovima, funkcije
agregacije).
pogledi mogu da sakriju kompleksnost podataka
poveava se bezbednost baze podataka
sakrivaju detalje o emi baze podataka od korisnika.
Primer: U nastavku je data SQL naredba koja kreira pogled

RADNIK_PROJEKAT koji sadri imena i prezimena radnika, imena projekata na
kojima rade kao i broj radnih asova koje tokom nedelje provode na tom projektu.
CREATE VIEW RADNIK_PROJEKAT
AS SELECT LIME, PREZIME, NAZIV, SATI
FROM RADNIK, PROJEKAT, RADI_NA
WHERE MATBR = MBR AND BRPR = BROJPR;
Nakon kreiranja, pogled se moe koristiti u SQL upitima kao i bilo koja druga
tabela. Naredna SQL naredba prikazuje podatke iz kreiranog pogleda
RADNIK_PROJEKAT.
SELECT * FROM RADNIK_PROJEKAT;
Primer: SQL naredba koja je data u nastavku kreira pogled SEK_INFO koji
sadri informacije o nazivu sektora, o broju radnika koji rade u sektoru i prosenoj
zaradi radnika u sektoru.
CREATE VIEW SEK_INFO
AS
SELECT NAZIV NAZIV_SEKTORA,
COUNT(*) BROJ_RADNIKA,
201

AVG(PLATA) PROSECNA_PLATA
FROM SEKTOR, RADNIK
WHERE BRSEK = SBROJ
GROUP BY NAZIV;
Ukoliko SQL upit sadri kolone ija vrednost se rauna a kojima nije dodeljen
pseudonim, prilikom kreiranja pogleda je takvim kolonama neophodno dodeliti
ime. U tom sluaju bi se za prethodni primer isoristila alternativna naredba data u
nastavku.
CREATE VIEW SEK_INFO
(NAZIV_SEKTORA, BROJ_RADNIKA, PROSECNA_PLATA)
AS
SELECT NAZIV, COUNT(*), AVG(PLATA)
FROM SEKTOR, RADNIK
WHERE BRSEK = SBROJ
GROUP BY NAZIV;
Pogledi se mogu koristiti za auriranje podataka u tabelama koje se nalaze u

pozadini (u FROM klauzuli uskladitenog upita). Da bi auriranje podataka
korienjem tabela bilo mogue, DBMS mora da bude u stanju da mapira strukturu
pogleda na strukturu tabela u pozadini (kolone i vrste). Za auriranje podataka
korienjem pogleda koriste se standardne SQL naredbe za auriranje podataka:
INSERT...INTO, UPDATE...SET, DELETE FROM. Pri tome treba voditi
rauna da nije mogue auriranje vrednosti kolona pogleda koje su dobijene kao
tezultat SQL funkcija (aritmetikih funkcija, funkcija za rad sa stringovima ili
funkcija agregacije).
Primer: U nastavku je data SQL naredba koja kreira pogled RAD_SEK_1 koji
sadri matine brojeve, puna imena i plate svih radnika koji rade u sektoru 1.
CREATE VIEW RAD_SEK_1
AS
SELECT MATBR, LIME || ' ' || PREZIME PUNO_IME, PLATA
FROM RADNIK
WHERE BRSEK = 1;
Ovako kreiran pogled se moe iskoristiti za auriranje tabele RADNIK na

osnovu koje je pogled kreiran. U nastavku je data SQL naredba koja aurira platu
radnika korienjem kreiranog pogleda.
202
Upitni jezik SQL

UPDATE RAD_SEK_1
SET PLATA = 1.1 * PLATA;
Napomena: Potrebno je uoiti da se kreirani pogled ne moe iskoristiti za

auriranje podataka o punom imenu radnika.
7.8 Naredbe za rad sa indeksima

Indeks je struktura podataka koja poboljava performanse pretraivanje u
relacionoj bazi podataka i najee se implementiraju kao stabla traenja. Mogu se
kreirati nad jednom ili veim brojem kolona tabele relacione baze podataka. Indeks
sadri kopiju vrednosti kolona nad kojima se kreira (kljuevi indeksa). Pojedini
DBMS-ovi omoguavaju da se indeksi kreiraju i nad rezultatima operacija nad
kolonama tabela. U optem sluaju, indeksi se ne mogu kreirati nad pogledima.
Svaki indeks fiziki postoji odnosno neophodan je prostor na disku u kome e
se uvati struktura indeksa.
Prilikom kreiranja primarnog kljua automatski se kreira i indeks nad kolonama
koje ine primarni klju. Svi ostali indeksi moraju da se kreiraju eksplicitno.
Obino se indeksiraju strani kljuevi u tabeli (da bi se ubrzale operacije spajanja
tabela) i kolone (ili grupe kolona) koje se koriste za postavljanje uslova u upitima.
Osnovna namena indeksa je da ubrzaju operacije za pretragu podataka.
Meutim, sa druge strane indeksi usporavaju operacije auriranja podataka. Zbog
toga niej dobro reenje kreirati indekse nad svim kolonama u bazi podataka. Jako je
bitno da se pravilno izbalansira korienje indeksa u bazi podataka kako bi se
postigli optimalni rezultati.
U SELECT naredni nije potrebno posebno specificirati indekse. Analizom SQL
upita DBMS sam odreuje koje indekse treba koristiti za optimalno izvravanje
upita.
U nastavku je dat osnovni oblik SQL naredbe za kreiranje indeksa:
CREATE [UNIQUE] INDEX <ime_indeksa>
ON {ime_tabele (ime_kolone[ASC I DESC]
[, ime_kolone[ASC I DESC]]...)};
Opcija UNIQUE se koristi kada se kreira indeks koji namee i ogranienje

jedinstvenost, odnosno zahteva da svi kljuevi indeksa (kombinacija vrednosti
kolona koje ine indeks) bude jedinstvena. Indeksi koji se kreiraju prilikom
kreiranja primarnog kljua imaju ukljuenu ovu opciju.
Sintaksa SQL naredbe za brisanej indeksa:
DROP INDEX <ime_indeksa>;
203

Primer: SQL naredba koja kreira indeks nad kolonom lokacija projekta.
CREATE INDEX PROJEKAT_LOK_IND ON PROJEKAT(LOKPR);
Primer: SQL naredba koja kreira indeks nad kolonama ime I preyime radnika
projekta.
CREATE INDEX RADNIK_IME_IND ON RADNIK(LIME DESC, PREZIME ASC);
Primer: SQL naredba koja kreira indeks za potrebe primarnog kljua (prilikom
kreiranja ogranienja primarnog kljua DBMS automatski kreira i UNIQUE
indeks).
CREATE UNIQUE INDEX RADNIK_MATBR_IND ON RADNIK(MATBR);
204
8 KREIRANJE
KORISNIKIH
APLIKACIJA:
AD O.N ET
8.1 Osnove ADO.NET-a

Veina trenutno prisutnih korisnikih aplikacija vri obradu podataka, a najei
nain skladitenja i korienja ovih podataka je preko baza podataka. U
najjednostavnijem sluaju, aplikacije koje pristupaju bazi podataka omoguavaju
svojim korisnicima da pretrauju podatke i prikazuju ih u tabelarnom obliku. Za
pristup podacima projektanti aplikacija mogu koristiti razliite tehnologije.
U prolosti je razvijeno vie standardnih interfejsa za pristup bazama podataka.
Svaki sistem za upravljanje bazama poseduje sopstveni programski interfejs (eng.
application programming interface-API) ijim korienjem je mogue iz
programskog koda odnosno iz aplikacije, vriti manipulaciju podacima u bazi
podataka. Programski interfejs (API) predstavlja kolekciju objekata i metoda koji
omoguavaju pozivanje funkcija DBMS-a iz programskog koda. Svaki DBMS
poseduje svoj programski interfejs pa je bilo neophodno razviti standarde za
pristup bazama podataka kako projektanti aplikacija ne bi morali da koriste
razliite intefejse u zavisnosti od konkretnog DBMS-a koji koriste.
Open Database Connectivity (ODBC) standard je razvijen sa ciljem da obezbedi
naine za manipulaciju podacima u relacionim bazama podataka koji bi bili
nezavisni od konkretnog DBMS-a. Microsoft je razvio OLE DB, objektnoorijentisani interfejs koji enkapsulira funkcionalnosti servera baza podataka. OLE
DB je razvijen ne samo za relacione baze podataka ve ima i mogunost korienje
drugih tipova podataka. Ovaj interfejs nisu mogli koristiti projektanti koji su svoje
aplikacije razvijali korienjem Visual Basic-a i script jezika pa je Microsoft razvio
Active Data Object (ADO) interfejs. ADO koristi funkcionalnosti OLE DB
interfejsa i moe biti korien iz bilo kog programskog jezika.
ADO.NET je naslednik ADO-a i deo je Microsoft-ove .NET platforme.
ADO.NET ima niz karakteristika koje ga razlikuju u odnosu na prethodne
tehnologije za pristup podacima. Funkcionalnosti ADO.NET-a baziraju se na
korienju novog objekta pod nazivom DataSet. DataSet predstavlja lokalnu kopiju
podataka pribavljenih iz baze podataka i moe sadrati vie od jedne tabele.
Verovatno najbitnija karakteristika ovog objekta je injenica da prua mogunost

manipulacije nad podacima bez potrebe da veza sa bazom podataka bude u svakom
trenutku otvorena. Prethodne tehnologije za pristup podacima su pretpostavljale da
je veza sa bazom podataka aktivna za vreme izvrenja koda koji vri obradu
podataka. Stalno aktivna konekcija dozvoljavala je trenutne izmene podataka i
nadgledanje promena za vreme izvrenja koda. Problem je predstavljao ogranieni
broj konekcija koje je server baze podataka mogao da prui korisnicima pa su
nakon zauzea svih dostupnih konekcija ostali korisnici morali da ekaju da se
neka od konekcija oslobodi.
ADO.NET ima u potpunosti drugaiji pristup u odnosu na prethodnike.
Konekcija sa bazom podataka se i dalje kreira ali je mogue mnogo ranije
osloboditi konekciju i uiniti je dostupnom ostalim korisnicima. Razlog je
mogunost pribavljanja kopije podataka iz baze i skladitenja ovih podataka u
DataSet objektu. Nakon pribavljanja podataka, mogue je zatvoriti konekciju pre
poetka obrade podataka. Naravno, nakon zavretka obrade podataka izmenjena je
jedino lokalna kopija podataka pa je neophodno ponovo otvoriti konekciju ka bazi
podataka kako bi bilo mogue snimiti izmene.
8.2 ADO.NET Data Provider-i

Za razliku od ADO-a, ADO.NET ne poseduje jedinstveni skup tipova objekata
koji komuniciraju sa razliitim sistemima za upravljanje bazama podataka
(DBMS). ADO.NET poseduje vie skupova tipova objekata koji komuniciraju sa
DBMS-im. Ove skupove tipova objekata nazivamo data provider-ima. Svaki od
data provider-a optimizovan je za interakciju sa konkretnim DBMS-om. Prednost
ovakvog pristupa je mogunost pojedinanih data provider-a da imaju mogunost
manipulacije objektima koji su specifini za posmatrani DBMS. Jo jedna od
prednosti je nain komunikacije izmeu data provider-a i DBMS-a. Naime, s
obzirom da je svaki data provider optimizovan za rad sa konkretnim DBMS-om, on
komunicira direktno sa DBMS-om tj. ne postoji meusloj koji bi prilagodio
zahteve korisnika konkretnom DBMS-u.
Data provider je najlake posmatrati kao skup tipova objekata definisanih u
odreenom prostoru imena tipova (eng. namespace) koji imaju mogunost direktne
komunikacija sa konkretnim DBMS-om. Svaki od data provired-a poseduje skup
klasa koje omoguavaju izvrenje osnovnih funkcionalnosti. Sve klase konkretnih
data provider-a imaju zajednike roditeljske klase tj. izvedene su iz istog skupa
klasa i interfejsa, koje se nalaze u System.Data.Common prostoru imena odnosno u
System.Data prostoru imena. Osnovni objekti ADO.NET Data Provider tipa
objekta prikazani su u nastavku, u tabeli 3.
Iako e se imena konkretnih objekata svakog od konkretnih Data Provider
objekata razlikovati (npr. SqlConnection, OracleConnection, OdbcConnection ili
MySqlConnection), svi su izvedeni iz iste klase i implementiraju iste interfejse pa
je nakon savladavanja korienja jednog od data provider-a relativno jednostavno
206
Kreiranje korisnikih aplikacija: ADO.NET

koristiti sve ostale. Struktura data provider-a .NET platforme prikazana je na slici
8-1.
Tabela 3: Struktura data provider-a .NET platforme
Objekat
Connection
Roditeljska
klasa
DbConnection
Implementira
interfejs
IDbConnection
Command
DbCommand
IDbCommand
DataReader
DbDataReader
IDataReader,
IDataRecord
DataAdapter
DbDataAdapter
IDataAdapter,
IDbDataAdapter
Parameter
DbParameter
Transaction
DbTransaction
IDataParameter,
IDbDataParameter
IDbTransaction
Znaenje
Omoguava otvaranje i zatvaranje
konekcije ka bazi podataka
Predstavlja SQL upit ili uskladitenu
proceduru. Omoguava pristup
DataReader objektu konkretnog data
provider-a
Omoguava itanje podataka
korienjem kursora na serverskoj
strani
Prenosi DataSet objekte izmeu
klijenta i izvora podataka. Poseduje
konekciju i skup od etiri osnovne
operacije za selektovanje, dodavanje,
izmenu i brisanje podataka u izvoru
podataka
Predstavlja imenovani parametar u
parametrizovanom upitu
Enkapsulira transakciju baze
podataka
Slika 8-1. Struktura Data Provider-a .NET platforme
Microsoft .NET platforma poseduje niz ugraenih data provider-a za razliite

DBMS-ove. Spisak ugraenih data provider-a prikazan je u nastavku u tabeli 4.
207

Tabela 4: Spisak ugraenih data provider-a
Prostor imena tipova
Biblioteka
(namespace)
OLE DB
System.Data.OleDb
System.Data.dll
Microsoft SQL Server
System.Data.SqlClient
System.Data.dll
System.Data.SqlServerCe
System.Data.SqlServerCe.dll
Mobile
ODBC
System.Data.Odbc
System.Data.dll
Oracle
System.Data.OracleClient
System.Data.OracleClient.dll
Data Provider
Pored data provider-a koji su ugraeni u .NET platformu, mogue je koristiti

data provider-e koje obezbeuju pojedinani proizvoai besplatnih ili
komercijalnih DBMS-ova poput SQLite, DB2, MySQL, PostgreSQL ili Sybase.
Pored predstavljenih prostora imena, .NET platforma poseduje skup dodatnih
prostora imena koji svojim funkcionalnostima pripadaju skupu ADO.NET prostora
imena. Neki od ovih prostora imena prikazani su u nastavku u tabeli 5.
Tabela 5: Spisak prostora imena ADO.NETa
Prostor imena tipova
(namespace)
System.Data
System.Data.Common
System.Data.Sql
System.Data.SqlTypes
Znaenje
Definie osnovne ADO.NET tipove koje koriste svi data
provider-i
Sadri tipove koje dele svi ADO.NET data provider-i
Sadri tipove koji omoguavaju otkrivanje instanci MS SQL
Server-a u lokalnoj mrei
Sadri tipove podataka koje koristi Microsoft SQL Server
Od svih ADO.NET prostora imena (namespace-a), System.Data je najoptiji.

Svaka aplikacija koja eli da pristupa podacima korienjem ADO.NET-a mora
koristiti klase definisane ovim prostorom imena. System.Data sadri klase koje su
zajednike za sve data provider-e. U nastavku, u tabeli 6, prikazani su osnovni
lanovi System.Data prostora imena.
Tabela 6: Osnovni lanovi System.Data prostora imena
Znaenje
Predstavlja ogranienje primenjeno na DataColumn objekat
Predstavlja jednu kolonu DataTable objekta
Predstavlja roditelj/dete odnos izmeu dva DataTable objekta
Predstavlja jedan red u DataTable objektu
Predstavlja lokalnu kopiju podataka u memoriji klijentskog
raunara koji se sastoji od niza povezanih DataTable objekata
DataTable
Predstavlja lokalnu kopiju tabele baze podataka
DataTableReader Omoguava itanje podataka iz DataTable objekta red po red
DataView
Predstavlja pogled na tabelu baze podataka i koirsti se za
sortiranje, filtriranje, pretraivanje i izmenu podataka
Klasa
Constraint
DataColumn
DataRelation
DataRow
DataSet
208
8.3 Direktan pristup podacima korienjem ADO.NET-a

Najlaki nain izvrenja svih operacija nad bazom podataka je direktno
izvrenje svih operacija pri emu se ne vodi rauna o lokalnim kopijama podataka.
Ovakav model je najblii tradicionalnom ADO programiranju i otklanja probleme
konkurentnog izvrenja operacija nad bazom podataka koji se deavaju kada vie
korisnika istovremeno izvrava operacije nad istim podskupom podataka. Ovakav
nain izvrenja operacija nad bazom podataka je dobro reenje kada je potrebno
proitati podatke ili izmeniti podake u jednom redu neke od tabela relacione baze
podataka. Ovakav pristup nije efikasan ukoliko je potrebno modifikovati vie
razliitih redova iz jedne ili vie tabela.
Uobiajeni redosled operacija prilikom pribavljanja podataka korienjem
ovakvog pristupa sastoji se iz sledeih koraka:
Kreirati Connection, Command i DataReader objekte

Otvoriti konekciju
Koristiti DataReader za itanje podataka iz baze podataka
Zatvoriti konekciju
8.4 Kreiranje konekcije ka bazi podataka

Pre pribavljanja ili izmene podataka neophodno je kreirati konekciju ka izvoru
podataka. Broj raspoloivih konekcija je ogranien pa je potrebno drati konekciju
otvorenom to je krae mogue. Konekcija ka izvoru podataka u ADO.NET-u
enkapsulirana je klasom Connection. Prilikom kreiranja instance klase Connection
neophodno je definisati ConnectionString atribut ove klase. ConnectionString
atribut predstavlja formatirani niz karaktera sastavljen od niza ime/vrednost parova
odvojenih meusobno karakterom ;. Ovaj atribut sadri informacije o imenu
maine kojoj pristupamo, nainu autentifikacije korisnika, imenu baze kojoj
pristupamo i sl. U nastavku su dati primeri kreiranja konekcije korienjem
Microsoft SQL Server data provider-a i Oracle data provider-a.
SqlConnection conn = new SqlConnection();
conn.ConnectionString
=
Data
Source=localhost;Initial
Catalog=PREDUZECE;Integrated Security=SSPI;
Oracle
OracleConnection conn = new OracleConnection();
conn.ConnectionString = Data
Source=160.99.9.139/gislab.elfak.ni.ac.rs;User
Id=S1010;Password=S1010;
Data Source ukazuje na ime servera na kome se nalazi baza podataka kojoj
pristupamo. Initial Catalog predstavlja ime baze podataka kojoj emo pristupati
209

korienjem kreirane konekcije. Integrated Security ukazuje na nain
autentifikacije korisnika. U posmatranom sluaju pristupa se korienjem Windows
korisnikog naloga. Alternativno, mogue je proslediti identifikator korisnika (eng.
User Id) i lozinku (eng. Password) naloga koji elimo da koristimo za pristup bazi
podataka, kako je to uinjeno u primeru za korienje Oracle data provider-a.
Pre korienja konekcije neophodno je eksplicitno otvoriti konekciju pozivom
metode Open objekta Connection:
conn.Open();
Nakon ekplicitnog poziva funkcije za otvaranje konekcije, otvorena je i aktivna

konekcija ka bazi podataka. Nakon zavretka obrade podataka neophodno je
zatvoriti konekciju pozivom funkcije Close ili Dispose za zatvaranje konekcije:
conn.Close();
conn.Dispose();
Objekti klase Connection poseduju skup atributa kojima je mogue upravljati

tokom izvrenja transakcija nad bazom podataka i pribaviti informacije vezane za
izvor podataka kome se pristupa.
8.5 Kreiranje SQL komande

Nakon kreiranja konekcija ka bazi podataka, neophodno je izvriti SQL narebde
za manipulaciju nad podacima. Ukoliko koristimo Microsoft SQL Server data
provider, SQL naredbe se izvravaju korienjem instanci klase SqlCommand tj
korienjem SqlCommand objekta. Ukoliko koristimo Oracle data provider, SQL
naredbe se izvravaju korienjem instanci klase OracleCommand tj korienjem
OracleCommand objekta. Objekti klasa SqlCommand i OracleCommand
predstavljaju objektno-orijentisanu reprezentaciju SQL upita, imena tabela ili
uskladitenih procedura. Dakle, komande mogu biti razliitog tipa. Tip komande
specificiran je CommandType atributom objekata klasa SqlCommand ili
OracleCommand i moe imati neku od vrednosti iz ComandType enumeracije.
public enum CommandType
{
StoredProcedure,
TableDirect,
Text
}
Prilikom kreiranja komande mogue je navesti SQL upit kao argument

konstruktora objekta ili korienjem CommandText atributa SqlCommand ili
OracleCommand objekta. Prilikom kreiranja komande neophodno je navesti
konekciju koja e se koristiti za izvrenje komande. Konekciju je mogue navesti
210

kao argument konstruktora objekta ili korienjem Connection atributa
SqlCommand ili OracleCommand objekta.
String strSQL = Select * from RADNIK;
SqlCommand comm = new SqlCommand(strSQL, conn);
SqlCommand newComm = new SqlCommand();
newComm.Connection = conn;
newComm.CommandText = strSQL;
Oracle
OracleCommand comm = new OracleCommand(strSQL, conn);
OracleCommand newComm = new OracleCommand();
newComm.Connection = conn;
newComm.CommandText = strSQL;
Prosto kreiranje SqlCommand ili OracleCommand objekta, ili bilo koje druge
komande ako se koristi neki drugi data provider, ne znai da je SQL upit sadran u
komandi automatski prosleen na izvrenje. Objekat koji predstavlja komandu je
nakon kreiranja samo pripremljen za dalju upotrebu. Najbitnije metode lanice
SqlCommand i OracleCommand objekta prikazane su u nastavku, u tabeli 7.
Tabela 7: Osnovni lanovi System.Data prostora imena
Metoda
Znaenje
Cancel()
Ponitava izvrenje komande
ExecuteReader()
Povratna vrednost funkcije je DataReader objekat izabranog data
provider-a
ExecuteNonQuery() Izvrava komandu od koje se ne oekuje da kao povratne
vrednosti daje podatke
ExecuteScalar()
Varijanta ExecuteNonQuery() koja kao povratnu vrednost vraa
jedan podatak
8.6 Korienje DataReader objekta

Nakon uspostavljanja konekcije ka bazi podataka i kreiranja SQL upita,
neophodno je izvriti kreirani upit kako bi se pribavili podaci. Ukoliko se koristi
SQL Server data provider ili Oracle data provider, najlaki i najbri nain za
pribavljanje podataka je korienje DataReader objekata. DataReader objekti
mogu samo da itaju podatke i to red po red unapred. Imajui ovo u vidu, jasno je
211

da je upotreba DataReader objekata korisna samo u situacijama kada je kreirani
upit SELECT SQL naredba. DataReader objekti posebno su korisni kada je
potrebno brzo iterirati kroz veliku koliinu podataka pri emu nije potrebno
posedovati lokalne kopije jednom oitanih podataka. DataReader objekti kreiraju
se pozivom ExecuteReader() metode kreirane komande. Nakon kreiranja
DataReader
objekta, jedan red rezultujue tabele podataka pribavlja se
korienjem Read() metode.
Ukoliko pretpostavimo da je kreirana konekcija ka bazi, da bi se oitali podaci
iz baze podataka neophodno je napisati SQL upit koji selektuje potrebne
informacije, kreirati komandu koja e izvriti upit i kreirati DataReader objekat
koji e pribaviti podatke. U nastavku e biti prikazan deo programskog koda koji
izvrava selektovanje svih redova iz tabele RADNIK u bazi podataka
PREDUZECE.
conn.ConnectionString
=
"Data
Source=localhost;User
Id=admin;Password=admin;Initial Catalog=PREDUZECE;";
SqlDataReader reader;
reader = comm.ExecuteReader();
while(reader.Read())
{
//programski kod koji vri obradu pribavljenih podataka
}
Oracle
conn.ConnectionString = "Data
Id=S1010;Password=S1010; ";
String strSQL = SELECT * FROM RADNIK;
OracleDataReader reader;
reader = comm.ExecuteReader();
while(reader.Read())
{
//programski kod koji vri obradu pribavljenih podataka
}
212

Pored izvrenja SQL upita koji vre selektovanje podataka, mogue je izvriti
SQL upite koji vre dodavanje, izmenu ili brisanje podataka iz baze podataka. U
nastavku e biti prikazan deo programskog koda koji vri dodavanje novog
radnika, izmenu podataka o radniku i brie podatke o radniku u tabeli RADNIK
baze podataka PREDUZECE.

conn.ConnectionString = "Data Source=localhost;User
try
{
conn.Open();
//dodavanje novog radnika
String strSQL1 = "Insert into RADNIK values
('123456789','Marko',
'J', 'Petrovic',
'1/9/1965','Obiliev Venac', 'M', '30000')";
SqlCommand comm1 = new SqlCommand(strSQL1, conn);
comm1.ExecuteNonQuery();
//izmena podataka o radniku
String strSQL2 = "Update RADNIK set Plata=50000 where
MatBr='123456789'";
//brisanje podataka o radniku
String strSQL3 = "Delete from RADNIK where
MatBr='123456789'";
}
catch (Exception exc)
{
}
finally
{
conn.Close();
}
213

Oracle
conn.ConnectionString = "Data
try
{
conn.Open();
//dodavanje novog radnika
String strSQL1 = "INSERT INTO RADNIK VALUES
('123456789','Marko',
'J', 'Petrovic',
'1/9/1965','Obiliev Venac', 'M', '30000')";
OracleCommand comm1 = new OracleCommand(strSQL1, conn);
//izmena podataka o radniku
String strSQL2 = "UPDATE RADNIK SET PLATA=50000 WHERE
MATBR='123456789'";
//brisanje podataka o radniku
String strSQL3 = "DELETE FROM RADNIK WHERE
MATBR='123456789'";
}
{
}
finally
{
conn.Close();
}
esto je neophodno parametrizovati upite koji se prosleuju bazi podataka na

osnovu podataka koje su korisnici uneli u aplikaciju. Kako bi prosleivanje
podataka koje su korisnici uneli bilo to sigurnije, ADO.NET poseduje mogunost
kreiranja parametrizovanih komandi. Svaka ADO.NET komanda poseduje
kolekciju individualnih parametara. Svaki od parametara predstavlja nezavisni
objekat koji je mogue kreirati i dodati u kolekciju ADO.NET Command objekta.
Parametri zauzimaju odreeno mesto u SQL upitu koji komanda izvrava. Kako bi
se ukazala pozicija u SQL upitu na kojoj e se nai odreeni parametar, koristi se
214

prefix @ praen imenom odgovarajueg parametra u sluaju korienja
Microsoft SQL Server data provider-a, odnosno prefix : u sluaju korienja
Oracle data provider-a. U nastavku e biti prikazan primer kreiranja i izvrenja
parametrizovane komande. U sluaju korienja SQL Server data provider-a,
parametri su instance klase SqlParameter, dok su u sluaju korienja Oracle data
provider-a parametri instance klase OracleParameter.

//kreiranje parametra
SqlParameter param = new SqlParameter();
param.ParameterName = "@parameter";
param.Value = "Marko";
param.SqlDbType = SqlDbType.NVarChar;
//kreiranje parametrizovanog upita
String strSQL = "Select * from RADNIK where
Ime=@parameter";
//dodavanje parametra u kolekciju parametara komande
comm.Parameters.Add(param);
try
{
conn.Open();
SqlDataReader dr = comm.ExecuteReader();
while (dr.Read())
{
//obrada podataka
}
}
{
}
finally
{
conn.Close();
}
215

Oracle
conn.ConnectionString = "Data Source=160.99.9.139gislab.elfak.ni.ac.rs;User Id=S1010;Password=S1010; ";
//kreiranje parametra
OracleParameter param = new SqlParameter();
param.ParameterName = "parameter";
param.Value = "Marko";
param.OracleDbType = OracleDbType.NVarchar2;
//kreiranje parametrizovanog upita
String strSQL = "SELECT * FROM RADNIK WHERE
Ime=:parameter";
//dodavanje parametra u kolekciju parametara komande
comm.Parameters.Add(param);
try
{
conn.Open();
OracleDataReader dr = comm.ExecuteReader();
while (dr.Read())
{
//obrada podataka
}
}
{
}
finally
{
conn.Close();
}
8.7 Korienje bezkonekcionog

pristup podacima
sloja
ADO.NET-A
za
Korienje Connection, Command i DataReader objekata podrazumeva da je

veza ka izvoru informacija (bazi podataka) otvorena za sve vreme trajanja obrade
podataka. Prednosti i mane ovakvog naina pristupanja podacima opisane su u
prethodnim poglavljima. ADO.NET pored ovakvog naina pristupa podacima
poseduje i drugaiji mehanizam, tzv. beskonekcioni pristup podacima.
216

Korienje bezkonekcionog naina pristupa podacima zasnovano je na kreiranju
lokalne kopije podataka koji se uvaju u operativnoj memoriji klijentskog raunara.
Korienjem tipova objekata iz System.Data ADO.NET prostora imena mogue je
kreirati lokalni model podataka koji e pored sirovih podataka posedovati veze
izmeu tabela, ogranienja primenjena na kolone, primarne kljueve, poglede i sve
druge karakteristike modela podataka korienog za kreiranje baze podataka.
Lokalni model podataka dozvoljava korisnicima kreiranje i izvravanje upita nad
lokalnim podacima, njihovo filtriranje, sortiranje i snimanje u bazu podataka.
U veini sluajeva, ak i prilikom korienja bezkonekcionog sloja ADO.NETa, neophodno je kreirati objekte koji predstavljaju konekciju i komandu. Za
pribavljanje i auriranje podataka se u sluaju bezkonekcionog pristupa podacima
koristi tzv. data adapter objekat koji predstavlja instancu DataAdapter klase. Za
razliku od direktnog pristupa podacima, podaci pribavljeni korienjem data
adapter objekta se ne pribavljaju korienjem DataReader objekata. Data adapter
objekti koriste DataSet objekte za prenos podataka od i ka bazi podataka. Svaki
DataSet objekat moe biti sastavljen od veeg broja DataTable (tabela podataka)
objekata koji poseduju kolekcije DataRow (red tabele) i DataColumn (kolona
tabele) objekata.
Data adapter objekat koji se koristi upravlja konekcijom ka bazi podataka
automatski. Kako bi se poboljala funkcionalnost, data adapter objekat e
konekciju ka bazi drati otvorenom minimalni period vremena. Kada se na
klijentskoj strani kreira DataSet objekat, data adapter e prekinuti konekciju sa
bazom podataka ostavljajui potpuno samostalnu kopiju podataka na klijentskom
raunaru. Klijentska aplikacija moe nakon toga nesmetano vriti izmene nad
pribavljenom kopijom podataka. Ovaj proces prikazan je na slici 8-2.
Slika 8-2. Bezkonekcioni pristup podacima
Da bi kreirali lokalnu kopiju podataka korienjem data adapter-a i DataSet

objekata, neophodno je najpre kreirati konekciju ka bazi podataka i komandu na
osnovu koje e biti kreirana lokalna kopija podataka. U nastavku je prikazan
primer programskog koda koji vri uitavanje svih radnika iz tabele radnik.
217

String strSQL = "Select * from RADNIK";
SqlDataAdapter adapter = new SqlDataAdapter(comm);
DataSet ds = new DataSet();
try
{
conn.Open();
adapter.Fill(ds, "Radnici");
}
catch(Exception exc)
{
//obrada izuzetka
}
finally
{
conn.Close();
}
Oracle
conn.ConnectionString = " Data
String strSQL = "SELECT * FROM RADNIK";
OracleDataAdapter adapter = new OracleDataAdapter(strSQL,
comm);
DataSet ds = new DataSet();
try
{
conn.Open();
adapter.Fill(ds, "RADNICI");
}
catch(Exception exc)
{
//obrada izuzetka
}
218

finally
{
conn.Close();
}
Nakon kreiranja lokalne kopije podataka tj DataSet objekta, mogue je aurirati

pribavljene podatke. U nastavku je prikazan primer programskog koda koji vri
auriranje podataka o sivm radnicima ije je ime Milo postavljajui im platu na
vrednost 30000.
foreach(DataRow dr in ds.Tables[Radnici].Rows)
{
if(dr[Ime].ToString() == Milo)
{
dr[Plata] = 30000;
}
}
Oracle
foreach(DataRow dr in ds.Tables[RADNICI].Rows)
{
if(dr[IME].ToString() == MILO)
{
dr[PLATA] = 30000;
}
}
Mogue je takoe i obrisati neki od redova u lokalnoj kopiji podataka ili dodati
novi red.
int i = 0;
{
{
dr.Delete();
}
}
{
219

{
dr[MatBr] = 123456789;
dr[Ime] = Strahinja;
dr[Prezime] = Bogdanovi;
dr[SSlovo] = M;
dr[DatRodj] = 1/1/2011;
dr[Adresa] = Bulevar Nemanjia 5/11;
dr[Plata] = 50000;
ds.Tables[Radnici].Rows.Add(row);
}
}
Oracle
int i = 0;
{
{
dr.Delete();
}
}
{
{
dr[MATBR] = 123456789;
dr[IME] = Strahinja;
dr[PREZIME] = Bogdanovi;
dr[SSLOVO] = M;
dr[DATRODJ] = 1/1/2011;
dr[ADRESA] = Bulevar Nemanjia 5/11;
dr[PLATA] = 50000;
ds.Tables[RADNICI].Rows.Add(row);
}
}
Sve izmene uinjene na lokalnoj kopiji podataka mogu se snimiti u bazu

podataka korienjem Update() metode DataAdapter objekta.
220

conn.Open();
adapter.UpdateCommand = new SqlCommand("UPDATE RADNIK SET
Ime='" + dr["Ime"].ToString() + "' WHERE MatBr=" +
dr["MatBr"].ToString(), conn);
int izmenjeniRedovi = adapter.Update(ds, "Radnici");
conn.Close();
Oracle
conn.Open();
adapter.UpdateCommand = new SqlCommand("UPDATE RADNIK SET
IME='" + dr["IME"].ToString() + "' WHERE MATBR=" +
dr["MATBR"].ToString(), conn);
int izmenjeniRedovi = adapter.Update(ds, "RADNICI");
conn.Close();
ADO.NET odrava informacije o originalnim i trenutnim vrednostima svih

podataka koji se nalaze u DataSet objektu. Prilikom auriranja podataka,
ADO.NET trai redove koji u potpunosti odgovaraju originalnim vrednostima
podataka u redovima DataSet objekta i po pronalaenju ih zamenjuje novim
redovima tj. podacima iz redova lokalne kopije. U ovom trenutku lako je uoiti da
e problem nastati ukoliko neki drugi korisnik izmeni podatke pre nego to naa
aplikacija snimi izmenjene podatke. Naime, drugi korisnici mogu izmeniti podatke
u bazi pa prilikom uporeivanja originalnih vrednosti lokalnih kopija podataka i
podataka u bazi nee doi do poklapanja. U ovakvim situacijama desie se
izuzetak.
Ovakve
situacije
mogue
je
preduprediti
korienjem
DataAdapter.RowUpdated dogaaja. Ovaj dogaaj deava se prilikom izvrenja
svake insert, update ili delete operacije ali pre nego to se desi izuzetak pa nam
daje mogunost da spreimo deavanje izuzetka. DataAdapter.RowUpdated
dogaaj deava se u trenucima dok aplikacija radi sa DataSet objektom i otvara
novu konekciju ka bazi podataka pa je preporuljivo uneti da programski kod koji
se izvrava u ovim situacijama bude to manji.
Zadaci za vebu:
1. Korienjem ADO.NET direktnog pritupa podacima pronai radnika iji je
matini broj 123456789 i izmeniti njegovo ime na Aleksandar. Za pristup
podacima koristiti SQL Server data provider. Podaci o radnicima uvaju se u tabeli
RADNIK baze podataka PREDUZECE.
2. Korienjem beskonekcionog sloja ADO.NET-a kreirati lokalnu kopiju
podataka o svim radnicima, poveati svim radnicima platu za 15% i snimiti
izmenjene podatke. Za pristup podacima koristiti SQL Server data provider. Podaci
o radnicima uvaju se u tabeli RADNIK baze podataka PREDUZECE.
221
9 L I T E R AT U R A
1. R. Elmastri & S. Navathe, Fundamentals of Database Systems, Pearson

International Education, Addison Wesley, 6th edition, 2010.
2. S.orevi-Kajan, L.Stoimenov, Baze podataka, praktikum za vebe na
raunaru, Elektronski fakultet u Niu, Edicija pomoni udbenici, 2004.
3. D.Kroenke, D.Auer, Database Concepts, Third Edition, Pearson Prentice Hall,
2008.
4. T.M.Connolly, C.E.Begg, Database Systems: A Practical Approach to Design,
Implementation and Management, Fourth Edition, Pearson International
Education, Addison Wesley, 2004.
5. Mogin P, Lukovi I, Govedarica M, 2000, Principi projektovanja baza
podataka, Univerzitet u Novom Sadu, Novi Sad.
Univerzitet u Niu
Leonid Stoimenov

Edicija: Udbenici
ISBN: 978-86-6125-099-6
Ni, 2013

Leonid Stoimenov - Uvod U Baze Podataka PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Leonid Stoimenov - Uvod U Baze Podataka PDF

Uploaded by

Copyright:

Available Formats

Univerzitet u Niu

SELECT STUDENT.Ime, STUDENT.Prezime

Uvod u Baze podataka

Prof. dr Leonid Stoimenov

Glavni i odgovorni urednik: Prof. dr Dragan Tasi

Pretampavanje ili umnoavanje ove knjige nije dozvoljeno bez pismene

tampa: Elektronski fakultet, Ni

Uvod u baze podataka: Sadraj

PODACI I INFORMACIJE ......................................................................................1

2 MODELI PODATAKA I PROCES PROJEKTOVANJA BAZE PODATAKA .... 15

NIVOI APSTRAKCIJE U DBMS-U ...................................................................... 15

3 KONCEPTUALNO PROJEKTOVANJE BAZE PODATAKA .............................. 23

Uvod u baze podataka: Sadraj

6 NORMALIZACIJA I NORMALNE FORME......................................................... 109

Uvod u baze podataka: Sadraj

OSNOVE ADO.NET-A................................................................................... 205

9 LITERATURA ........................................................................................................... 223

Uvod u baze podataka: Sadraj

Uvod u baze podataka: Sadraj

3-22. Primer oznaavanja strukturalnih ogranienja ............................... 46

Uvod u baze podataka: Sadraj

6-4. Ilustracija parcijalnih i tranzitivnih zavisnosti ............................... 132

Moderne kompanije i institucije poseduju razliite elektronske (raunarske,

1.1 Podaci i informacije

Uvod u baze podataka

1.2 Konvencionalni sistemi u odnosu na baze podataka

postoji datoteka ili skup datoteka podataka potrebnih za definisanu

Aplikacioni program nabavke

Slika 1-1. Konvencionalni sistem zasnovan na datotekama

Na slici 1-1 prikazan je konvencionalni sistem sa dve aplikacije jednog

Baze podataka osnovni pojmovi

Ugraeni su opisi fizikih karakteristika podataka (ili fizikih struktura

Prednosti konvencionalne obrade zasnovane na datotekama su jednostavnost

Posledice navednih nedostataka su da je obrada podataka skupa i da se zahteva

Nezavisnost struktura podataka od programa koji ih obrauju.

Obrada zasnovana na bazama podataka prikazana je na slici 1-2. Baze podataka

Uvod u baze podataka

Sistem baze podataka

Slika 1-2. Obrada zasnovana na bazama podataka

1.3 Sistem baza podataka

Baze podataka osnovni pojmovi

Slika 1-3. Komponente sistema baza podataka

Aplikacija nad bazom podataka predstavlja jednu ili vie aplikacija

1.4 ta je baza podataka?

Uvod u baze podataka

Entitetima objektima realnog sveta, kao to su:

Osnovna namena baze podataka je da bude repozitorijum (skladite) za

Baze podataka osnovni pojmovi

Slika 1-4. Tabela u bazi podataka sa oznaenom vrstom i kolonom

Koje e tabele da sadri baza podataka zavisi od problema za koji treba

Slika 1-5. Meusobna povezanost podataka u bazi podataka

Meusobna povezanost podataka je ono po emu se baza podataka razlikuje u

Uvod u baze podataka

1.5 ta je Sistem za upravljanje bazama podataka?

Definisanje se odnosi na specificiranje tipova podataka, struktura i

Za kontrolisani pristup podacima u bazi podataka DBMS treba da obezbedi:

Sigurnosni sistem, koji onemoguava pristup bazi podataka

Baze podataka osnovni pojmovi

Sistem za kontrolu i upravljanje oporavkom baze podataka, koji

DBMS obino nudi jezike koji omoguavaju kontrolisani pristup i rad sa

Jezik za opis podataka (eng. Data Definition Language - DDL), koji

Prednosti koje obezbeuje DBMS u odnosu na tradicionalni pristup zasnovan

Nezavisnost podataka - Aplikacioni programi su nezavisni od