Baze 1

SVEUČILIŠTE U MOSTARU
FAKULTET STROJARSTVA I RAČUNARSTVA
BAZE PODATAKA
Nastavnik: Prof.dr.sc. Draţena Gašpar

Asistent: Goran Kraljević, dipl.ing.rač.
Ak.god. 2010/2011. BAZE PODATAKA 1
O predmetu
Web
http://www2.fsr.ba/nastava/baze
Pitanja, primjedbe, dogovor za konzultacije ...
 To: goran.kraljevic@hteronet.ba
 Subject: Baze
1
Polaganje ispita ...
Modeliranje 25 bodova
SQL 50 bodova
Teorija 25 bodova
Ukupno : 100 bodova
 Prolazna ocjena na ispitu: min. 50 bodova

50-64 bod. .......... dovoljan (2)
65-79 bod. .......... dobar (3)
80-89 bod. .......... vrlodobar (4)
90-100 bod. ........ izvrstan (5)
Uvod u baze podataka
2
Baza podataka
• Baza podataka je skup meĎusobno povezanih podataka,

pohranjenih zajedno bez štetne ili nepotrebne (nekontrolirane)
zalihosti (redundancije), s ciljem da ih koriste različite aplikacije.
Podaci su pohranjeni u obliku neovisnom od programa koji ih
koriste. Unos, izmjena i dohvat podataka obavlja se ISKLJUČIVO
kroz zajedničko i kontrolirano sučelje.
Zajedničke osobine za sve sustave baza podataka (Ullman)
• Apstraktni model podataka

• Visoka razina pristupa ili upitnih jezika
• Upravljanje transakcijama u višekorisničkom okruženju
• Kontrola pristupa i vlasništvo nad podacima
• Validacija podataka i provjera konzistentnosti
• Konzistentni oporavak podataka nakon ispada sustava i/ili
strojne opreme
3
Ciljevi razvoja baza podataka
• Razdvajanje podataka od aplikacija koje ih koriste
• Prezentiranje logičkog pogleda na podatke neovisno od fizičkih

detalja njihove pohrane u bazu podataka
• Omogućavanje različitih pogleda na istu bazu podataka, ovisno

o korisničkim i aplikativnim potrebama
Faze razvoja baza podataka
FAZE razvoja Baza podataka Aplikacija

Izrada modela podataka UtvrĎivanje zahtjeva za
Zahtjevi Specificiranje podataka aplikaciju
(analiza) Definiranje ograničenja i
poslovnih pravila
Tablice Forme
Relacije Izvješća (Reports)
Dizajn Indeksi Upiti (Queries)
Ograničenja Kod aplikacije
Pohranjene procedure i okidači
Kreiranje tablica Kreiranje formi
Kreiranje relacija Kreiranje izvješća
Implementiranje Kreiranje ograničenja Kreiranje Upita
Pisanje procedura i okidača Pisanje koda aplikacije
Punjenje baze podataka Testiranje
Testiranje
4
Sustav za upravljanje bazama podataka
• SUBP (DBMS - Database Management System)

Programski sustav koji omogućava upravljanje bazom podataka je
sustav za upravljanje bazama podataka.
• Korisnički programi ne pristupaju podacima

direktno već preko DBMS-a
• Korisnik ili korisnički program postavlja zahtjev

za obavljanjem neke operacije s podacima, a
SUBP ga analizira, provjerava, optimizira,
transformira u niz operacija koje je potrebno
obaviti na fizičkoj razini, obavlja operacije i
vraća rezultat.
Funkcije SUBP-a:
• Definiranje baze podataka (DDL–Data Definition Language)
• Manipuliranje podacima u bazi (DML–Data Manipulation Language)
• Upravljačke funkcije:
̶ Sigurnost i zaštita od neovlaštenog pristupa
̶ Očuvanje integriteta (backup i recovery)
̶ Statističko praćenje rada baze podataka
̶ Optimizacija rada
5
Fizička i logička organizacija podataka
• Važna posljedica primjene SUBP jest

razdvajanje fizičke i logičke organizacije
podataka. Dok logička organizacija
podataka predstavlja organizaciju sa
stanovišta korisnika baze podataka ili
programera te je koncentrirana na vrste
podataka i njihove meĎusobne logičke
veze, fizička organizacija predstavlja
organizaciju fizičke pohrane podataka
unutar računala. Oblik i organizacija
pohranjenih podataka tu su često
potpuno različiti od njihovog logičkog
oblika i organizacije.
• U okviru toga, zadaća je SUBP-a
omogućiti korisniku (programeru)
manipuliranje podacima uz poznavanje
samo logičkog opisa baze podataka, a
ne nužno i poznavanja načina fizičke
pohrane podataka.
Glavni proizvoĎači SUBP (DBMS)
• Oracle
• IBM DB2
• Microsoft SQL Server
• Sybase
• Informix (sada IBM)
• MySQL
• PostgreSQL
• ...
6
Povijesni razvoj baza podataka
Sustavi bazirani na datotečnim sustavima (filesystem)

• podaci su spremljeni u datotekama (files)
• svaka datoteka ima svoj format
̶ programi koji koriste bazu moraju poznavati taj format
• Problemi:
̶ nema standarda
̶ višestruko ponavljanje podataka
̶ meĎuovisnost podataka
̶ teško je vršiti neuobičajena pretraživanja
̶ integritet podataka
̶ sigurnost
̶ istovremeni pristup, ...
Modeli podataka
• Model podataka je skup pravila koji odreĎuju kako može

izgledati logička struktura baze
• U 60-tim i 70-tim godinama su bili u upotrebi hijerarhijski i
mrežni model
• Hijerarhijski model
̶ baza je predočena stablom ili skupom stabala
̶ jedan član može imati samo jednog vlasnika
̶ putovi pretraživanja su fiksni
• Mreţni model
̶ opći slučaj hijerarhijskog modela
̶ odnosi definirani eksplicitno
̶ aplikacija mora poznavati interni model baze podataka
• Implementacije u računalu koristile su pokazivače koji izravno
adresiraju mjesto zapisa na disku
7
Hijerarhijski i mreţni model
Hijerarhijski model podataka Mreţni model podataka

Ograničenja hijerarhijskih i mreţnih baza:
- Nemaju pokriće u formalnoj teoriji
- Sva pretraživanja se izvode po unaprijed definiranim i točno navedenim putovima
- Svi odnosi izmeĎu objekata se moraju unaprijed i točno definirati
- Optimizacija se provodi ručno - programer sam optimizira kod i odreĎuje metodu
koja će biti korištena pri komunikaciji izmeĎu aplikacije i baze podataka
Modeli podataka
• Relacijski model
̶ 1970 dogaĎa se relacijska "revolucija“
̶ E.F.Codd objavljuje članak "A Relational Model of Data for
Large Shared Databanks" koji postavlja osnove skoro svim
današnjim sustavima baza podataka
̶ ...
• Objektni model
̶ inspiriran objektno orijentiranim programskim jezicima
̶ baza je skup objekata koji se sastoje od podataka i metoda
koje vrše operacija nad njima
8
Relacijski model podataka
• Relacijski model je osnovne koncepte preuzeo iz matematičke

teorije skupova, a to su:
̶ Relacija
̶ Atribut
̶ Domena
9
• Relacijski model podataka se temelji na matematičkoj teoriji relacija

• Većina suvremenih DBMS je bazirana na relacijskom modelu
• Informacije su pohranjene kao zapisi ili slogovi (records) u
relacijama (tablicama)
• Baza podataka je skup relacija (tablica)
̶ Podaci su u n-torkama (redovima)

̶ Zaglavlje definira atribute (stupce) relacije
Ključevi u relacijskoj bazi podataka
• Super ključ (superkey) – atribut ili skup atributa koji

jedinstveno odreĎuje n-torku unutar relacije.
• Kandidat ključ (candidate key) – super ključ takav da nema

nijedan odgovarajući podskup koji bi bio super ključ unutar relacije.
• Primarni ključ (primary key) – kandidat ključ koji je odabran

da jedinstveno odredi n-torku unutar relacije.
• Jedinstveni ključ (unique key) – kandidat ključ koji nije

odabran da bude primarni ključ.
10
Kandidat (za PRIMARNI) ključ mora zadovoljiti 2 uvjeta:

• Jedinstvenost … na relacijskoj shemi niti u jednom
trenutku ne mogu postojati dvije n-torke s jednakim
vrijednostima skupa atributa K.
• Minimalnost … niti jedan pravi podskup od skupa atributa
K nema svojstvo jednoznačnosti.
 I primarni i jedinstveni ključ moraju ispuniti uvjete

jedinstvenosti i minimalnosti, ali relacija moţe imati
SAMO JEDAN primarni ključ, dok jedinstvenih ključeva
moţe imati više.
Primjer:
• Super ključ: npr. {Matbr, Prezime}

• Kandidat ključ: {Matbr}, {JMBG}
• Primarni ključ: {Matbr}
• Jedinstveni ključ: {JMBG}
11
• Vanjski ili strani ključ (foreign key) – atribut ili skup

atributa unutar jedne relacije koji odgovara kandidat ključu neke
(moguće i iste) relacije.
• Vanjski ključevi omogućuju povezivanje n-torki iz različitih tablica.
Primjer:
Ograničenja u relacijskom modelu podataka
Dva opća ograničenja:
• Entitetski integritet
- povezan sa primarnim ključem
• Referencijalni integritet
- povezan sa stranim ključem
12
Entitetski integritet
• Vrijednost primarnog ključa kao cjeline, ne smije biti

jednaka NULL vrijednosti. Ako je primarni ključ relacije
sloţen, niti jedna njegova komponenta ne smije
poprimiti NULL vrijednost.
(Codd, 1970)
Primjeri:
NASTAVNIK = {SifNas, PrezNas}

PK (NASTAVNIK) = {SifNas} → SifNas ne smije biti NULL
ISPIT = {Matbr, SifPred, DatIsp}

PK (ISPIT) = {Matbr, SifPred, DatIsp} → Matbr, SifPred, DatIsp ne
smiju biti NULL
Referencijalni integritet
• Ako u relacijskoj shemi R postoji strani ključ (foreign key)

koji odgovara primarnom ključu (primary key) relacijske
sheme S, tada svaka vrijednost stranog ključa u relaciji r(R)
mora biti ili jednaka vrijednosti primarnog ključa neke n-
torke iz relacije s(S) ili jednaka NULL vrijednosti
Primjer:
Relacije OSOBA i MJESTO ne zadovoljavaju pravilo referencijalnog integriteta jer u

relaciji OSOBA postoji vrijednost stranog ključa (77000) za koju ne postoji
odgovarajuća n-torka u relaciji MJESTO.
13
Ograničenja u relacijskom modelu podataka
Domenski integritet
• Kako svaki atribut ima pridruženu domenu, postoje ograničenja
(engl. domain constraints) koja čine restrikcije nad skupom
dozvoljenih vrijednosti atributa relacije.
NULL / NOT NULL

• NULL – predstavlja vrijednost atributa koja je trenutno
nepoznata ili nije primjenjiva za konkretnu n-torku.
• NULL je način rada s nepotpunim podacima ili izuzetcima.
• NULL nije nula (0) za numeričke vrijednosti ili “spaces” za tekst.
• NULL znači ODSUSTVO (nepostojanje) vrijednosti.
Operacije u relacijskom modelu
Osnovne operacije u relacijskom modelu:
• Unija
• Razlika
• Presjek
• Kartezijev produkt
• Projekcija
• Selekcija
• Spajanje (join)
14
• Unija … relacija koju čine sve n-torke prve i druge relacije
• Razlika … relacija koju čine sve n-torke koje se nalaze u prvoj,

ali se ne nalaze u drugoj relaciji
15
• Presjek … relacija koju čine n-torke zajedničke za obje relacije
• Kartezijev produkt … relacija koju čine sve moguće kombinacije

parova n-torki s tim da je prva n-torka iz prve, a druga iz druge
relacije
16
• Projekcija … rezultat je izbor odreĎenih atributa polazne relacije
• Selekcija (ograničenje, restrikcija, izbor) … rezultat su samo

one n-torke koje zadovoljavaju postavljene uvjete
17
• Spajanje … iz dvije relacije stvara novu relaciju od svih

kombinacija parova n-torki koji zadovoljavaju postavljene uvjete
• U svakoj se tablici (relaciji) bira stupac (polje) preko čijih se
vrijednosti uspostavlja veza
• Opisane operacije relacijske algebre primjenjuju se uvijek u

kombinaciji:
̶ iz više tablica selektiramo samo one zapise koji udovoljavaju
uvjetima
̶ napravimo spajanje (join)
̶ projekcijom odaberemo željena polja
• Na taj se način iz vrlo malog broja osnovnih operacija relacijske

algebre može izvesti veliki broj kombinacija za obradu i analizu
podataka.
• Prijevod operacija relacijske algebre u jezik za definiciju i

manipulaciju podacima koji danas predstavlja osnovni standard
za relacijske baze podataka: SQL.
18
Modeliranje podataka
19
ER modeliranje
Model entiteti - veze (entity-relationship model)

• ili bolje: model entiteti - veze - atributi
ER modeliranje:
• je sastavljeno iz entiteta, veza i atributa
• je slikovni prikaz sustava baze podataka
• je neovisno o DBMS i hardveru
• predstavlja konceptualni model visokog nivoa
• podržava korisnikovu percepciju podataka
• je alat za projektiranje
Entitet
• Entitet je bilo koji objekt u sustavu koji ţelimo modelirati i

o kojem ţelimo sačuvati informaciju
̶ Pojedinačni objekti zovu se entiteti

̶ Skupine objekata istog tipa zovu se tipovi entiteta ili skupovi
entiteta
̶ Moguća su dva tipa entiteta: jaki i slabi
20
Jaki i slabi tip entiteta
• JAKI entitet – tip entiteta čija egzistencija nije vezana za

postojanje nekog drugog tipa entiteta.
• SLABI entitet – tip entiteta čija egzistencija ovisi o postojanju

nekog drugog tipa entiteta, tj. onaj tip entiteta koji ne može
postojati u bazi podataka ukoliko neki drugi tip entiteta takoĎer
ne postoji u bazi.
• ID-ovisan entitet – tip entiteta kod kojega identifikator jednog

entiteta uključuje identifikator drugog entiteta.
Atribut
• Atribut je svaki detalj koji sluţi da pobliţe odredi,

identificira, klasificira, kvantificira ili izrazi stanje entiteta.
• Predstavlja opis entiteta
21
Veze
• Entiteti se mogu povezivati jedan s drugim u veze (relacije).

• Broj entiteta u vezi predstavlja STUPANJ VEZE.
Binarna veza
veza 2 entiteta
Ternarna veza
veza 3 entiteta
Unarna veza
isti entitet više puta
egzistira u različitim
ulogama
Kardinalnost veze
• Odnos omjera meĎu povezanim entitetima nazivamo

kardinalnost veze
- Jedan na jedan (1:1)
- Jedan na više (1:m)
- Više na jedan (m:1)
- Više na više (m:n)
22
Grafički prikaz veze
Razbijanje M:N veza
• Veza m:n u ER modelu se moţe razbiti uvoĎenjem novog

posredničkog entiteta.
Primjer:
• Vezu više na više možemo razbiti uvoĎenjem entiteta najam, koji sadrži
atribut datum_najma
23
Preslikavanje ER modela u relacije
VEZA JEDAN:VIŠE
• Primarni ključ entiteta sa strane veze JEDAN doda se kao
strani ključ u entitet sa strane veze VIŠE.
VEZA VIŠE:VIŠE
• Doda se novi entitet, koji sadrži primarne ključeve obaju
rubnih entiteta.
• Ti atributi zajedno tvore složeni primarni ključ novonastalog
entiteta.
Usporedne i povratne veze
Usporedne veze – dvije usporedne veze izmeĎu dva entiteta ...
Povratne veze – veza entiteta “na samog sebe” ...
24
Preslikavanje ER modela u relacije
Usporedne veze
• Svaku vezu zamijenimo s po jednim stranim ključem u relaciji
na strani veze VIŠE (usporedne veze se preslikaju u jednu, ali
s uvoĎenjem dodatnog stranog ključa).
• Da bi razlikovali veze meĎu entitetima stranim ključevima
damo različite nazive.
Povratne veze
• Doda se strani ključ jednak primarnom ključu relacije.
• Za povratne veze vrijedi da je strani ključ jednak primarnom
ključu relacije, ali pod drugim imenom.
UML (Unified Modeling Language)
Zašto UML (odnosno korištenje jedne notacije)?

• Korištenje jednog jezika i notacije bitno olakšava komunikaciju
izmeĎu članova različitih timova (projektanti baze podataka,
analitičari, programeri aplikacije) i time doprinosi da se svi
sudionici koji participaraju u projektu osjećaju dijelom jedne
cjeline.
25
Relacije u UML-u
 ZAVISNOST (dependency)
 ASOCIJACIJA (association) 1 1..*
 AGREGACIJA (aggregation)
 GENERALIZACIJA (generalization)
 REALIZACIJA (realization)
UML notacija ...
26
Normalizacija podataka
• Normalizacija je proces kojime se nastoji eliminirati

redundancija, ali tako da se sačuva integritet podataka u bazi
• Redundancija se izražava kroz pojam funkcijske zavisnosti
• Definiraju se normalne forme (NF)
̶ prva NF, druga NF, treća NF, itd.

̶ svaka normalna forma garantira da nema odreĎenog tipa
zavisnosti
̶ svaka viša NF uključuje prethodnu NF te dodatno ureĎuje
model, tj. eliminira dodatne redundantnosti
27
Definicije funkcijskih ovisnosti
Funkcijska ovisnost atributa

• Ako promatramo tablicu R sa atributima X i Y koji mogu biti
kompozitni tj. složeni: za atribut Y tablice R kaže se da je
funkcijski ovisan o atributu X iste tablice
R.X->R.Y
ako je svaka pojedina vrijednost atributa X povezana sa samo
jednom vrijednošću atributa Y.
Potpuna funkcijska ovisnost atributa

• U tablici R s atributima X i Y koji mogu biti kompozitni tj. složeni,
Y je potpuno funkcijski ovisan o X ako vrijedi da je Y funkcijski
ovisan o X i nije funkcijski ovisan niti o jednom manjem podskupu
atributa X.
Odnosno, ako vrijedi X->Y tada ne smije postojati niti jedan
podskup Z koji sadrži samo dio atributa od kojih se sastoji atribut
X, za koji bi vrijedilo da je Z->Y.
28
Tranzitivna funkcijska ovisnost atributa

• Ako vrijedi X->Y i Y-/->X (Y je funkcijski ovisan o X, a X nije
funkcijski ovisan o Y), i ako Y->A (A je funkcijski ovisan o Y) tada
vrijedi da je A funkcijski ovisan i o X (X->A).
Ako vrijedi A-/->Y tada je A striktno tranzitivno ovisan o X.
1NF
Prva normalna forma (1NF)

Tablica se nalazi u prvoj normalnoj formi ako su svi
neključni atributi funkcijski ovisni o ključu.
 Uklanjanje ponavljajućih atributa ili grupa atributa
29
2NF
Druga normalna forma (2NF)

Tablica je u drugoj normalnoj formi ako i samo ako je
u 1NF i ako su svi neključni atributi potpuno funkcijski
ovisni o ključu.
Uklanjanje atributa ovisnih samo o dijelu jedinstvenog

identifikatora.
3NF
Treća normalna forma (3NF)

Tablica je u trećoj normalnoj formi ako i samo ako je u
2NF i ako niti jedan neključni atribut nije tranzitivno
ovisan o ključu.
Uklanjanje atributa ovisnih o atributima koji nisu dio

jedinstvenog identifikatora.
30
Primjer normalizacije podataka
• Na slici je dana denormalizirana tablica s nazivima stupaca i

vrijednostima redaka.
Napraviti normalizirani model podataka s pripadajućim

entitetima, atributima i vezama izmeĎu njih.
Normalizacija podataka (1NF)
– Postoji funkcijska zavisnost :

Matbr → Prezime, Ime
– Ne postoji funkcijska zavisnost : Matbr → SifPred Matbr → NazPred

Matbr → DatIsp Matbr → Ocjena
Matbr → SifNas Matbr → PrezNas
31
Rješenje:
 PK (STUDENT) = {Matbr}
 PK (ISPIT) = {Matbr, SifPred, DatIsp}
 {Matbr, SifPred, DatIsp} → {NazPred}

 {SifPred} → {NazPred} dakle, ne postoji potpuna funkcijska ovisnost
neključnih atributa o ključu
ISPIT ne zadovoljava 2 NF !
Rješenje:
32
 {Matbr, SifPred, DatIsp} → {SifNas}

 {SifNas} → {PrezNas} dakle, postoji tranzitivna funkcijska ovisnost
(koju je potrebno eliminirati)
ISPIT ne zadovoljava 3 NF !
Rješenje:
Sve tablice zadovoljavaju 3 NF !
 STUDENT (Matbr, Prezime, Ime)

 PREDMET (SifPred, NazPred)
 NASTAVNIK (SifNas, PrezNas)
 ISPIT (Matbr, SifPred, DatIsp, Ocjena, SifNas)
Vaţno:
- Baza podataka treba biti barem u 3 NF !
33
Relacijski model (UML notacija)
Primjeri
34
Primjer 1.
• Profesionalni programer Marko Marković odlučio je napraviti program

za evidentiranje svih programa koje je uradio, korisnika kod kojih ti
programi rade, kao i ostvarene zarade po svakom programu.
Za svaki program se evidentira vrijeme utrošeno za njegovu izradu,

kao i vrijeme utrošeno kod korisnika za prilagodbu programa
korisničkim zahtjevima, kad je program pušten u rad kod korisnika,
kao i koliko je od korisnika naplaćeno za taj program. TakoĎer se
evidentira da li je program u uporabi tj. aktivan ili ne.
Primjer 1. ( ER model )
35
Primjer 1. ( Relacijski model )
Primjer 2.
• Faktura je dokument koji se šalje kupcu kako bi mogao izvršiti plaćanje

kupljene robe. Da bi se napravila faktura moraju postojati osnovni
podaci o kupcu (naziv, adresa, telefon i sl.), podaci o fakturi (broj
fakture, datum izdavanja, broj narudžbe prema kojoj je raĎena, rok
plaćanja, iznos za plaćanje i sl.), kao i podaci o kupljenim artiklima
(naziv, jedinica mjere, kupljena količina, cijena i sl.).
Faktura se sastoji od 2 osnovna dijela:

- Zaglavlje fakture koje sadrži zajedničke, opće podatke
- Stavke fakture s pojedinačnim artiklima, količinama i cijenama.
Definirati sve entitete, atribute i veze za proces Fakturiranja kupcima.
36
37
Primjer 3.
• Na Fakultetu strojarstva i računarstva u Mostaru evidentirani su podaci o

kandidatima koji su se prijavili na razradbeni ispit i njihovim rezultatima.
Evidentiraju se podaci o:
- kandidatu: JMBG, ime, prezime, mjesto roĎenja, završena srednja
škola (šifra, naziv, adresa, poštanski broj mjesta, mjesto, šifra općine i
naziv općine u kojoj se škola nalazi)
- za svakog kandidata ocjena iz pojedinih predmeta iz srednje škole –
šifra i naziv predmeta, razred i ocjena. Šifra odreĎuje predmet u nekom
razredu (godini), npr. Matematika u 1.razredu i Matematika u 2.razredu
imaju različite šifre. Isti predmeti u različitim školama imaju istu šifru
npr. Matematika iz 1.razreda ima istu šifru za sve škole
- podaci o zadacima na razradbenom ispitu – redni broj zadatka, tekst
zadatka, točan odgovor (A, B, C, D ili E)
- za svakog kandidata odgovori koje je dao na zadatke (odgovor za svaki
pojedini zadatak mogu biti A, B, C, D, E ili ništa)
38
Primjer 4.
• U bazi podataka potrebno je evidentirati podatke o zrakoplovima,

aerodromima i letovima.
Zrakoplov je identificiran svojim jedinstvenim registracijskim brojem (npr.
N6061U). Za zrakoplov se evidentiraju godina proizvodnje i tip zrakoplova.
Za svaki tip zrakoplova evidentira se šifra tipa i naziv tipa zrakoplova (npr.
šifra: 123, naziv tipa: "Airbus-A319") te najveća ukupna dozvoljena težina
pri polijetanju. Za svaki aerodrom se evidentira šifra i naziv aerodroma.
Zrakoplov prema namjeni može biti ili putnički ili teretni (jedno isključuje
drugo). Za svaki pojedini zrakoplov, ovisno o njegovoj namjeni, evidentira
se je li u zrakoplov ugraĎena dodatna oprema: za svaki pojedini putnički
zrakoplov evidentira se ima li ugraĎenu internu televiziju, ima li ureĎaj za
satelitsku komunikaciju, a za svaki pojedini teretni zrakoplov broj dodatno
ugraĎenih klimatiziranih kontejnera za prijevoz životinja i je li ugraĎen
katapult za izbacivanje tereta padobranom.
39
Primjer 4.
(nastavak zadatka ...)
...
Evidentiraju se letovi samo putničkih zrakoplova. Let je identificiran šifrom
i datumom leta (npr. "OU763", 1.6.2001), a za let se evidentira s kojeg
aerodroma zrakoplov polijeće, na koji aerodrom slijeće te vrijeme
polijetanja i vrijeme slijetanja. Evidentira se koji zrakoplov leti na kojem
letu.
Evidentiraju se kategorije cijena karata. Svaka kategorija cijena ima svoju
šifru (jedinstveno identificira kategoriju) i naziv (npr. "poslovna",
"ekonomska", "s popustom za zaposlenika kompanije", "s popustom za
osobe mlaĎe od 27 godina", itd). Putnik kupuje kartu točno odreĎene
kategorije cijene za odreĎeni let. Putnik ne može za jedan let kupiti više
od jedne karte. Za svakog putnika se evidentira jmbg (jedinstveno
odreĎuje putnika), prezime i ime.
40
Primjer 5.
• U procesu proizvodnje prati se utrošak sirovina u proizvodnji 5

proizvoda na osnovu radnog naloga koji sadrži informacije o broju
radnog naloga, datumu kreiranja naloga, datumu izvršenja naloga
(proizvodnje), djelatniku koji ga je inicirao, proizvedenom gotovom
proizvodu, količini gotovog proizvoda i utrošenoj količini i vrijednosti
sirovina za svaki gotovi proizvod pojedinačno i sl.
Za proizvodnju svakog pojedinog proizvoda pravi se poseban radni
nalog samo za taj proizvod.
U bazi podataka nalaze se podaci o djelatnicima (šifra, ime, prezime,
stručna sprema, šifra radnog mjesta i sl.), radnim mjestima (šifra,
opis, šifra organizacijske jedinice), organizacijskim jedinicama (šifra,
naziv, adresa), proizvodima (šifra, naziv), sirovinama (šifra, naziv,
vrijednost).
41
Primjeri za vjeţbu
42
Primjer 1. (Evidentiranje objavljenih radova)
• Profesor programiranja Marko Marković odlučio je napraviti program

za evidentiranje svojih objavljenih radova.
To podrazumijeva evidentiranje svih do sada objavljenih radova,
naslova radova, koautora koji su s njim učestvovali u pisanju radova,
godina objavljivanja kao i časopisa u kojima je objavljivano.
TakoĎer treba uspostaviti klasifikaciju radova po principu: znanstveni,
stručni ili pregledni rad, te da li je rad objavljen u meĎunarodnom ili
domaćem časopisu.
Za svaki rad unose se podaci o naslovu rada, klasifikacijama,
koautorima i časopisu u kojem je rad objavljen.
Primjer 2. (Ugovori)
• Na slici je dana denormalizirana tablica UGOVORI s nazivima stupaca i

vrijednostima redaka. Napraviti normalizirani model podataka s
pripadajućim entitetima, atributima i vezama izmeĎu njih.
43
Primjer 3. (Videoteka)
• U videoteci su evidentirani filmovi i primjerci filmova. Za svaki film

evidentira se žanr (oznaka i naziv) i distributer (šifra i naziv). Uz svaki
film evidentiraju se različiti izvoĎači (šifra, prezime i ime) i funkcije
koje su obavljali u filmu. Funkcije su predstavljene kraticom i nazivom,
a mogu biti npr. GL-glumac, RED-redatelj, SC-scenarist, SKL-skladatelj,
itd. Primjerci filma su odreĎeni šifrom filma i rednim brojem primjerka.
Uz svaki primjerak evidentira se datum nabavke.
Obratite pozornost na tip veze izmeĎu entiteta funkcija, izvoĎač i film:
Primjer 4. (Tvrtka informatičke opreme)
• Tvrtka koja se bavi prodajom informatičke opreme prilikom prodaje

iste sa svojim kupcima dogovara uvjete servisiranja opreme. U tvrtki
radi više servisera i pri kupnji se ugovara koji je serviser zadužen za
kojeg kupca s tim da na jednog servisera doĎe više kupaca. Jednim
ugovorom se definira točno razdoblje servisiranja (od kojeg do kojeg
datuma), a podrazumijeva više izlazaka servisera na teren unutar
definiranog vremenskog razdoblja. Naravno, intervencija servisera nije
nužna. Prilikom izlaska na teren potrebno je zabilježiti točno vrijeme
odlaska i povratka, vrijeme provedenu na terenu izraženo u satima, te
na kojoj je komponenti, ili više njih, vršena popravka.
Napraviti normalizirani model podataka s pripadajućim entitetima,
atributima i vezama izmeĎu entiteta.
44
Primjer 5. (Tehnički biro)
• Napraviti normalizirani model podataka s pripadajućim entitetima, atributima i

vezama izmeĎu entiteta koji bi osigurao evidentiranje projekata, rokova i
izvršitelja u jednom tehničkom birou.
Osnovni način poslovanja tehničkog biroa jeste rad na izradi odreĎenih projekata,
što znači da se za svaki projekt trebaju evidentirati osnovni podaci o naručitelju
projekta (šifra, naziv, adresa, telefon, mail). Za svaki projekt postoji samo jedan
glavni naručitelj s kojim se sklapa ugovor o poslu. O projektu se vode slijedeći
podaci: naziv projekta, opis projekta, planirani datum početka rada na projektu,
planirani svršetak rada na projektu, stvarni početak rada na projektu, stvarni
svršetak rada na projektu, vrijednost projekta, ugovoreni penali za kašnjenje,
dodatna napomena. Na svakom projektu radi više djelatnika iz biroa (šifra, ime,
prezime, zanimanje, titula, adresa, telefon, mail) koji rade na odreĎenom
radnom mjestu u birou (šifra, naziv radnog mjesta, opis). Projekt se razlaže na
više različitih poslova (zadataka). Svakom članu projektnog tima dodjeljuje se
točno odreĎeni posao (zadatak) što se posebno i evidentira. Uz svaki posao
(zadatak) evidentira se i naziv zadatka, kratak opis, planirani početak, planirani
svršetak, stvarni početak, stvarni svršetak, vrijednost i napomena.
Sigurnost baze podataka
45
Sigurnost i integritet
• Sigurnost baze podataka se brine da samo ovlašteni korisnici

pristupaju podacima
• Integritet baze podataka se brine da ovlašteni korisnici

koriste podatke na ispravan način
Integritet:
̶ korektnost (dopuštene zdravorazumske vrijednosti podataka)
̶ konzistencija (meĎusobna suglasnost podataka)
Korisnici i sigurnost
46
Korisnici i sigurnost
• CREATE USER pero IDENTIFIED BY pero;
• CONNECT pero/pero;
• ALTER USER pero IDENTIFIED BY pero1;
Sistemske privilegije
• više od 100 sistemskih privilegija
• Tipične DBA privilegije:

– CREATE USER
– DROP USER
– DROP ANY TABLE
– BACKUP ANY TABLE
– SELECT ANY TABLE
– CREATE ANY TABLE
47
• Osnovna sintaksa za dodjeljivanje sistemskih privilegija:
GRANT sistemske_privilegije
TO korisnik|uloga|PUBLIC
[WITH ADMIN OPTION]
• Osnovna sintaksa za ukidanje sistemskih privilegija:
REVOKE sistemske_privilegije
FROM korisnik|uloga|PUBLIC
Primjeri:
• GRANT create session, create table,

create sequence, create view
TO pero;
• REVOKE create view

FROM pero;
48
Uloga (Role)
Korisnici
Uloga
Privilegije
Dodjeljivanje privilegija korisnicima Dodjeljivanje privilegija korisnicima

bez definirane uloge nakon definiranja uloge
Uloga (Role)
• CREATE ROLE uloga_1 IDENTIFIED BY uloga_1;
• GRANT create session, create table, create view

TO uloga_1;
• GRANT uloga_1
TO pero;
49
Objektne privilegije
Najčešće korištene objektne privilegije su:
• SELECT – tablice, pogledi, sekvence

• INSERT, UPDATE, DELETE – tablice, pogledi
• INDEX, REFERENCES – tablice
• ALTER – tablice, sekvence
• EXECUTE – procedure
• ALL, ALL PRIVILEGES
• Osnovna sintaksa za dodjeljivanje objektnih privilegija:

GRANT objektne_privilegije
ON ime_objekta
TO korisnik|uloga|PUBLIC
[WITH GRANT OPTION]
• Osnovna sintaksa za ukidanje objektnih privilegija:

REVOKE objektne_privilegije
ON ime_objekta
FROM korisnik|uloga|PUBLIC
50
Primjer:
• GRANT select, insert

ON djelatnik
TO pero, mate
WITH GRANT OPTION;
• GRANT select
ON opcina
TO PUBLIC;
Upravljanje transakcijama
51
• Pod transakcijom se podrazumijeva aktivnost ili niz

aktivnosti koje izvršava jedan korisnik ili aplikacijski
program, a koja čita ili aţurira sadrţaj baze podataka.
• To je logička radna jedinica baze podataka
• Transakcija se logički mora provesti kao nedjeljiva cjelina

̶ svaka transakcija unosi promjenu u bazi
̶ pojedinačne operacije unutar transakcije nisu bitne same za
sebe
500 KM
Račun 1 Račun 2
5.000 KM 1.000 KM
1) UPDATE racun SET saldo=saldo-500

WHERE id_racuna=1;
2) UPDATE racun SET saldo=saldo+500
WHERE id_racuna=2;
Transakcija se mora izvršiti u potpunosti (u gornjem slučaju obe

UPDATE naredbe) ili nikako – “SVE ili NIŠTA”
52
Osobine transakcija
Tzv. ACID osobine transakcija:
• Atomicity – „sve ili ništa‟ (transakcije nije moguće samo

djelomično izvršiti)
• Consistency – transakcija mora transformirati bazu iz jednog

konzistentnog stanja u drugo
• Isolation – učinak transakcije postaje vidljiv drugim transakcijama

tek nakon završetka transakcije promatrajući izvana transakcija može
biti ili izvedena ili ne
• Durability – rezultat uspješno završenih (potvrĎenih) transakcija

se trajno bilježi u bazu podataka i ne smije se izgubiti zbog
naknadnih grešaka (čak ni u slučaju pada sustava)
Upravljanje transakcijama (ORACLE)
• 2 tipa transakcija:
– DML – sadrži jedan ili više DML iskaza
– DDL – sadrži jedan DDL iskaz
• Transakcija započinje kada je:

– DDL naredba izdana
– Pokrenut prvi DML iskaz nakon COMMIT-a
• Transakcija se moţe završiti na sljedeći način:

– COMMIT iskazom – potvrdi sve izmjene
– ROLLBACK iskazom – poništi sve izmjene
– DDL iskazom → automatski COMMIT
– Padom sustava → automatski ROLLBACK
53
• Stanje sustava prije izvršavanje COMMIT ili ROLLBACK

naredbe:
– moguće je vratiti sustav u stanje prije izvršavanja naredbi
iz transakcije
– korisnik koji radi izmjene podataka kroz transakciju može
vidjeti efekte tih izmjena (npr. izvršavanjem SELECT iskaza)
– ostali korisnici ne mogu vidjeti efekte navedenih izmjena
– n-torke nad kojima se rade izmjene kroz transakciju
(INSERT, UPDATE, DELETE) automatski se zaključavaju i
ostali korisnici ih ne mogu mijenjati.
Napomena: U Oracle sustavu implicitno zaključavanje će
se desiti za sve SQL iskaze osim SELECT-a
• Stanje sustava nakon izvršavanja COMMIT naredbe:

– izmjene podataka u bazi postaju trajne
– sustav se više ne može vratiti u stanje prije izvršavanja
naredbi iz transakcije
– svi korisnici mogu vidjeti efekte izmjena učinjenih kroz
transakciju
– n-torke nad kojima su vršene izmjene kroz transakciju nisu
više zaključane i navedene n-torke postaju dostupne za
izmjenu i drugim korisnicima.
54
• Stanje sustava nakon izvršavanja ROLLBACK naredbe:

– izmjene podataka u bazi se poništavaju
– sustav se vraća u stanje prije izvršavanja naredbi iz
transakcije
– n-torke koje su bile implicitno zaključane kroz transakciju
nisu više zaključane te postaju dostupne za izmjenu i
drugim korisnicima.
Primjer
Vrijeme Sesija 1 Sesija 2
SELECT placa FROM djelatnik

t1 WHERE id_djelatnika=1;
UPDATE djelatnik
2000 SET placa=placa+1000
t3 SELECT placa FROM djelatnik SELECT placa FROM djelatnik

WHERE id_djelatnika=1; WHERE id_djelatnika=1;
2000 3000
t4 COMMIT;

3000 3000
55
Primjer
SELECT placa FROM djelatnik

UPDATE djelatnik
2000 SET placa=placa+1000

2000 3000
t4 ROLLBACK;

2000 2000
Tehnike kontrole konkurentnosti
• Konzervativne (pesimistične) uzrokuju odgaĎanje

transakcija u slučaju da će biti u konfliktu s drugim
transakcijama u budućnosti.
- Zaključavanje (locking)
- Timestamp
• Optimistične su bazirane na pretpostavci da su konflikti

rijetki tako da dozvoljavaju transakcijama da nastave i
nesinkronizirane i samo provjeravaju konflikt na kraju, kada
se transakcija potvrĎuje.
56
Zaključavanje (locking)
• mehanizam zabrane pristupa zapisima koje netko obraĎuje

̶ prije obavljanja operacije podaci se zaključavaju
̶ transakcija koja traži zaključavanje mora čekati dok ono ne bude
odobreno
Dijeljeno zaključavanje (shared lock, read lock)

̶ obavlja se prije čitanja
Ekskluzivno zaključavanje (exclusive lock, write lock)

̶ prethodi zapisivanju
Što se zaključava?
̶ granulacija: polje, zapis, tablica, stranica (fizički blok na
kojem su zapisi pohranjeni)
Razine izolacije (isolation levels)
• Kod zapisivanja se uvijek traži ekskluzivno zaključavanje koje se

zadržava do kraja transakcije.
• Kod čitanja možemo imati različite načine zaključavanja:

̶ read uncommitted
čitanje bez zaključavanja;
̶ read committed
zahtijeva dijeljeno zaključavanje za sve zapise koji su dohvaćeni upitima;
otključava zapise odmah nakon što su pročitani;
̶ repeatable read
zahtijeva dijeljeno zaključavanje za sve zapise koji su dohvaćeni upitima;
podaci ostaju zaključani do kraja transakcije;
57
Mrtva točka (Deadlock)
• Mrtva točka (deadlock) nastaje kada dvije (ili više)

transakcija, obje (sve) čekaju da se otpusti zaključavanje
koje drži druga transakcija.
Deadlock
Primjer
UPDATE djelatnik
t1 SET placa=placa+1000
WHERE id_djelatnika=1; UPDATE djelatnik
t2 SET placa=placa-500
WHERE id_djelatnika=2;
UPDATE djelatnik
t3 SET placa=placa-500
UPDATE djelatnik
t4 SET placa=placa+1000
t5 → ORA-00060: deadlock detected while waiting for resource
58
Ostali objekti u bazi podataka
VIEW, SEQUENCE, INDEX, SYNONYM
Objekti u bazi podataka
• TABLE – Tablica
• VIEW – Pogled
• INDEX – Indeks
• SEQUENCE – Sekvenca
(ORACLE)
• SYNONYM – Sinonim
(ORACLE)
59
Pogled (VIEW)
Što je pogled?
- “prozor” u podatke
- podaci se izvode, ne posjeduju
- pohranjuje se kao SELECT izraz u rječnik podataka
Uporaba pogleda
- za ograničenje pristupa podacima
- za pojednostavljenje složenih upita
- za omogućavanje neovisnosti podataka
- za prikaz različitih pogleda na iste podatke
Pogled (VIEW)
Jednostavni pogled
- podaci su iz jedne tablice
- ne sadrži funkcije ili grupe
- može izvršiti DML
Sloţeni pogled
- podaci su iz više tablica
- sadrži funkcije ili grupe
- ne može izvršiti DML
60
Kreiranje pogleda (VIEW)
CREATE OR REPLACE VIEW djelatnik_imenik

AS
SELECT id_djelatnika, ime, prezime, email, telefon
FROM djelatnik;
CREATE VIEW radno_mj_stat (radmj,minplac,maxplac,prosjek)

AS
SELECT rm.naziv_radmj, min(placa), max(placa), avg(placa)
FROM djelatnik d, radno_mjesto rm
WHERE d.sifra_radmj=rm.sifra_radmj
GROUP BY rm.naziv_radmj;
Pogled (VIEW)
61
Brisanje pogleda (VIEW)
• Pogled možete izbrisati bez ikakvog gubitka podataka

jer je pogled (view) baziran na tablicama u bazi.
Brisanje pogleda nema nikakvog utjecaja na te tablice.
DROP VIEW ime_pogleda
Indeks (INDEX)
– Brzina pristupa podacima u relaciji je važno svojstvo sustava za

upravljanje podacima. Najjednostavniji način pristupa,
sekvencijalna pretraga, u većini slučajeva ne zadovoljava.
– Kreiranjem indeksa formira se struktura B-stabla koja omogućava

nesekvencijalni pristup do n-torke u relaciji. Nesekvencijalni
pristup moguć je prema vrijednostima onih atributa nad kojima je
izgraĎena indeksna struktura.
– Nad jednom relacijom može biti izgraĎeno više indeksa, od kojih

svaki može sadržavati jedan ili više atributa.
– Osim radi poboljšanja performansi sustava, indeksi se kreiraju i

radi osiguranja jedinstvenosti vrijednosti atributa u relaciji.
62
Kreiranje indeksa (INDEX)
– AUTOMATSKI
• UNIQUE INDEX se automatski kreira kada se definira
PRIMARY KEY ili UNIQUE CONSTRAINT u definiciji
tablice
– RUČNO
• Korisnik može ručno dodati indeks na neki drugi
atribut (radi ubrzanja pristupa podacima)
Primjer:
• CREATE INDEX djelatnik_prez_idx
ON djelatnik(prezime);
Indeks (INDEX)
– Indekse bi u principu trebalo primjenjivati u

sljedećim slučajevima:
• za atribute prema kojima se obavlja spajanje relacija

• za atribute koji se često koriste za postavljanje uvjeta
selekcije
• za atribute prema kojima se često obavlja grupiranje
ili sortiranje
63
Indeks (INDEX)
– Prilikom kreiranja indeksa treba voditi računa i o

nekim njihovim negativnim aspektima, te ih treba
koristiti samo tamo gdje je njihova uporaba
opravdana, jer:
• indeksi zauzimaju značajan prostor

• ažuriranje vrijednosti atributa nad kojima je izgraĎen
indeks traje znatno dulje nego ažuriranje vrijednosti
nad kojima nema indeksa (ovdje treba razlikovati
atribute prema kojima se pronalaze n-torke koje
treba ažurirati, od atributa čije se vrijednosti
ažuriraju)
Indeks (INDEX)
– Indekse ne bi trebalo primjenjivati ukoliko:
• vrijednosti atributa za kojeg se gradi indeks imaju

relativno mali broj različitih vrijednosti (npr.
spol_osobe s dopuštenim vrijednostima M, Ţ, u
relaciji s 30 000 n-torki)
• u relaciji predstoji velik broj upisa, izmjena ili brisanja
n-torki. Preporučljivo je u takvim slučajevima
postojeće indekse izbrisati, te ih ponovo izgraditi tek
nakon obavljenih promjena na podacima.
• relacija sadrži vrlo mali broj n-torki (npr. do stotinu).
U takvim slučajevima sustav lakše pristupa
sekvencijalnom pretragom, nego prolaskom kroz
strukturu B-stabla.
64
Sekvence (SEQUENCES)
Što je sekvenca?
- automatski generira jedinstveni broj

- obično se koristi za dodijeljivanje vrijednosti
PRIMARNOM KLJUČU
- sekvenci može pristupati više korisnika
• CREATE SEQUENCE sequence

[INCREMENT BY n]
[START WITH n]
[{MAXVALUE n | NOMAXVALUE}]
[{MINVALUE n | NOMINVALUE}]
[{CYCLE | NOCYCLE}]
[{CACHE n | NOCACHE}];
65
• CREATE SEQUENCE dept_deptid_seq

INCREMENT BY 10
START WITH 120
MAXVALUE 9999
NOCACHE
NOCYCLE;
• INSERT INTO odjel (sifra_odjela, naziv_odjela)

VALUES (odjel_sifra_seq.NEXTVAL, 'Strategija i razvoj');
• SELECT odjel_sifra_seq.CURRVAL
FROM dual;
66
Sinonimi (SYNONYMS)
Sinonim je drugi naziv za objekt koristan kod

referenciranja na objekte drugih korisnika.
Primjer:
CREATE [PUBLIC] SYNONYM ime_sinonima
FOR [vlasnik.]ime_objekta;
CREATE SYNONYM djelatnik

FOR fsr.djelatnik;
O predmetu
Web
http://www2.fsr.ba/nastava/baze
Pitanja, primjedbe, dogovor za konzultacije ...
 To: goran.kraljevic@hteronet.ba
 Subject: Baze
67

Baze 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Baze 1

Uploaded by

Copyright:

Available Formats

SVEUČILIŠTE U MOSTARU

FAKULTET STROJARSTVA I RAČUNARSTVA

Nastavnik: Prof.dr.sc. Draţena Gašpar

Ak.god. 2010/2011. BAZE PODATAKA 1

Pitanja, primjedbe, dogovor za konzultacije ...

Ak.god. 2010/2011. BAZE PODATAKA 2

 Prolazna ocjena na ispitu: min. 50 bodova

Ak.god. 2010/2011. BAZE PODATAKA 3

Uvod u baze podataka

Ak.god. 2010/2011. BAZE PODATAKA 4

• Baza podataka je skup meĎusobno povezanih podataka,

Ak.god. 2010/2011. BAZE PODATAKA 5

Zajedničke osobine za sve sustave baza podataka (Ullman)

• Apstraktni model podataka

Ak.god. 2010/2011. BAZE PODATAKA 6

• Razdvajanje podataka od aplikacija koje ih koriste

• Prezentiranje logičkog pogleda na podatke neovisno od fizičkih

• Omogućavanje različitih pogleda na istu bazu podataka, ovisno

Ak.god. 2010/2011. BAZE PODATAKA 7

Faze razvoja baza podataka

FAZE razvoja Baza podataka Aplikacija

Ak.god. 2010/2011. BAZE PODATAKA 8

• SUBP (DBMS - Database Management System)

• Korisnički programi ne pristupaju podacima

• Korisnik ili korisnički program postavlja zahtjev

Ak.god. 2010/2011. BAZE PODATAKA 9

Sustav za upravljanje bazama podataka

Ak.god. 2010/2011. BAZE PODATAKA 10

• Važna posljedica primjene SUBP jest

Ak.god. 2010/2011. BAZE PODATAKA 11

Sustav za upravljanje bazama podataka

Glavni proizvoĎači SUBP (DBMS)

Ak.god. 2010/2011. BAZE PODATAKA 12

Sustavi bazirani na datotečnim sustavima (filesystem)

Ak.god. 2010/2011. BAZE PODATAKA 13

• Model podataka je skup pravila koji odreĎuju kako može

Ak.god. 2010/2011. BAZE PODATAKA 14

Hijerarhijski model podataka Mreţni model podataka

Ak.god. 2010/2011. BAZE PODATAKA 15

Ak.god. 2010/2011. BAZE PODATAKA 16

Ak.god. 2010/2011. BAZE PODATAKA 17

Relacijski model podataka

• Relacijski model je osnovne koncepte preuzeo iz matematičke

Ak.god. 2010/2011. BAZE PODATAKA 18

• Relacijski model podataka se temelji na matematičkoj teoriji relacija

̶ Podaci su u n-torkama (redovima)

Ak.god. 2010/2011. BAZE PODATAKA 19

Ključevi u relacijskoj bazi podataka

• Super ključ (superkey) – atribut ili skup atributa koji

• Kandidat ključ (candidate key) – super ključ takav da nema

• Primarni ključ (primary key) – kandidat ključ koji je odabran

• Jedinstveni ključ (unique key) – kandidat ključ koji nije

Ak.god. 2010/2011. BAZE PODATAKA 20

Kandidat (za PRIMARNI) ključ mora zadovoljiti 2 uvjeta:

 I primarni i jedinstveni ključ moraju ispuniti uvjete

Ak.god. 2010/2011. BAZE PODATAKA 21

Ključevi u relacijskoj bazi podataka

• Super ključ: npr. {Matbr, Prezime}

Ak.god. 2010/2011. BAZE PODATAKA 22

• Vanjski ili strani ključ (foreign key) – atribut ili skup

• Vanjski ključevi omogućuju povezivanje n-torki iz različitih tablica.

Ak.god. 2010/2011. BAZE PODATAKA 23

Ograničenja u relacijskom modelu podataka