Sveuˇciliˇste u Zagrebu

Prirodoslovno Matematiˇcki Fakultet
- Matematiˇcki odjel
Robert Manger
BAZE PODATAKA
skripta
Korigirano prvo izdanje
Zagreb, veljaˇca 2008.
Sadrˇzaj
1 UVOD U BAZE PODATAKA 3
1.1 Osnovni pojmovi vezani uz baze podataka . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Baza podataka, DBMS, model podataka . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Ciljevi koji se nastoje posti´ci koriˇstenjem baza podataka . . . . . . . . . . . . . . 4
1.1.3 Arhitektura baze podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.4 Jezici za rad s bazama podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.5 Poznati softverski paketi za rad s bazama podataka . . . . . . . . . . . . . . . . 6
1.2
ˇ
Zivotni ciklus baze podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Analiza potreba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Modeliranje podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Implementacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Testiranje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.5 Odrˇzavanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 MODELIRANJE PODATAKA 9
2.1 Modeliranje entiteta i veza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Entiteti i atributi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Veze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Prikaz ER-sheme pomo´cu dijagrama . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4 Sloˇzenije veze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Relacijski model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Relacija, atribut, n-torka, kljuˇc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Pretvaranje ER-sheme u relacijsku . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Usporedba relacijskog modela s mreˇznim i hijerarhijskim . . . . . . . . . . . . . . 15
2.3 Normalizacija relacijske sheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Funkcionalna ovisnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 Druga normalna forma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.3 Tre´ca normalna forma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.4 Boyce-Codd-ova normalna forma . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.5 Viˇseznaˇcna ovisnost i ˇcetvrta normalna forma . . . . . . . . . . . . . . . . . . . . 19
2.3.6 Razlozi zbog kojih se moˇze odustati od normalizacije . . . . . . . . . . . . . . . . 20
3 JEZICI ZA RELACIJSKE BAZE PODATAKA 21
3.1 Relacijska algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Skupovni operatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.2 Selekcija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.3 Projekcija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.4 Kartezijev produkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.5 Prirodni spoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.6 Theta-spoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.7 Dijeljenje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.8 Vanjski spoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Relacijski raˇcun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 Raˇcun orijentiran na n-torke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 Raˇcun orijentiran na domene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1
2 SADR
ˇ
ZAJ
3.3 Jezik SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 Postavljanje upita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2 Aˇzuriranje relacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Optimizacija upita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1 Odnos izmedu relacijske algebre i raˇcuna . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.2 Osnovna pravila za optimizaciju . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 FIZI
ˇ
CKA GRADA BAZE PODATAKA 35
4.1 Elementi fiziˇcke grade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 Vanjska memorija raˇcunala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.2 Datoteke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.3 Smjeˇstaj datoteke u vanjskoj memoriji . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.4 Pointeri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.5 Fiziˇcka grada cijele baze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Pristup na osnovu primarnog kljuˇca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 Jednostavna datoteka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.2 Hash datoteka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.3 Datoteka s indeksom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.4 B-stablo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Pristup na osnovu drugih podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.1 Invertirana datoteka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Viˇsestruke vezane liste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.3 Podijeljena hash funkcija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5 IMPLEMENTACIJA RELACIJSKIH OPERACIJA 47
5.1 Implementacija prirodnog spoja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.1 Algoritam ugnijeˇzdenih petlji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.2 Algoritam zasnovan na sortiranju i saˇzimanju . . . . . . . . . . . . . . . . . . . . 48
5.1.3 Algoritam zasnovan na indeksu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.4 Algoritam zasnovan na hash funkciji i razvrstavanju . . . . . . . . . . . . . . . . 49
5.2 Implementacija selekcije, projekcije i ostalih operacija . . . . . . . . . . . . . . . . . . . 50
5.2.1 Implementacija selecije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.2 Implementacija projekcije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.3 Implementacija ostalih operacija. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3 Optimalno izvrednjavanje algebarskog izraza . . . . . . . . . . . . . . . . . . . . . . . . 51
6 INTEGRITET I SIGURNOST PODATAKA 53
6.1
ˇ
Cuvanje integriteta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.1 Ograniˇcenja kojima se ˇcuva integritet domene . . . . . . . . . . . . . . . . . . . . 53
6.1.2 Ograniˇcenja kojima se ˇcuva integritet unutar relacije . . . . . . . . . . . . . . . . 53
6.1.3 Ograniˇcenja kojima se ˇcuva referencijalni integritet . . . . . . . . . . . . . . . . . 54
6.2 Istovremeni pristup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.1 Transakcije i serijalizabilnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.2 Lokoti i zakljuˇcavanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.3 Dvofazni protokol zakljuˇcavanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.4 Vremenski ˇzigovi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3 Oporavak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.1 Rezervna kopija baze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.2
ˇ
Zurnal datoteka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.3 Neutralizacija jedne transakcije . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.4 Ponovno uspostavljanje baze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4 Zaˇstita od neovlaˇstenog pristupa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.1 Identifikacija korisnika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.2 Pogledi kao mehanizam zaˇstite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.3 Ovlaˇstenja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
1
UVOD U BAZE PODATAKA
1.1 Osnovni pojmovi vezani uz baze podataka
Baze podataka predstavljaju viˇsu razinu rada s podacima u odnosu na klasiˇcne programske jezike.
Rijeˇc je o tehnologiji koja je nastala s namjerom da se uklone slabosti tradicionalne “automatske
obrade podataka” iz 60-tih i 70-tih godina 20. stolje´ca. Ta tehnologija osigurala je ve´cu produktivnost,
kvalitetu i pouzdanost u razvoju aplikacija koje se svode na pohranjivanje i pretraˇzivanje podataka u
raˇcunalu.
1.1.1 Baza podataka, DBMS, model podataka
Baza podataka je skup medusobno povezanih podataka, pohranjenih u vanjskoj memoriji raˇcunala.
Podaci su istovremeno dostupni raznim korisnicima i aplikacijskimprogramima. Ubacivanje, promjena,
brisanje i ˇcitanje podataka obavlja se posredstvom zajedniˇckog softvera. Korisnici i aplikacije pritom
ne moraju poznavati detalje fiziˇckog prikaza podataka, ve´c se referenciraju na logiˇcku strukturu baze.
Sustav za upravljanje bazom podataka (Data Base Management System - DBMS) je posluˇzitelj
(server) baze podataka. On oblikuje fiziˇcki prikaz baze u skladu s traˇzenom logiˇckom strukturom.
Takoder, on obavlja u ime klijenata sve operacije s podacima. Dalje, on je u stanju podrˇzati razne
baze, od kojih svaka moˇze imati svoju logiˇcku strukturu, no u skladu s istim modelom. Isto tako, brine
se za sigurnost podataka, te automatizira administrativne poslove s bazom.
Podaci u bazi su logiˇcki organizirani u skladu s nekim modelom podataka. Model podataka je
skup pravila koja odreduju kako moˇze izgledati logiˇcka struktura baze. Model ˇcini osnovu za koncipi-
ranje, projektiranje i implementiranje baze. Dosadaˇsnji DBMS-i obiˇcno su podrˇzavali neki od sljede´cih
modela:
Relacijski model. Zasnovan na matematiˇckom pojmu relacije. I podaci i veze medu podacima
prikazuju se “pravokutnim” tabelama.
Mreˇzni model. Baza je predoˇcena usmjerenim grafom.
ˇ
Cvorovi su tipovi zapisa, a lukovi definiraju
veze medu tipovima zapisa.
Hijerarhijski model. Specijalni sluˇcaj mreˇznog. Baza je predoˇcena jednim stablom ili skupom sta-
bala.
ˇ
Cvorovi su tipovi zapisa, a hijerarhijski odnos “nadredeni-podredeni” izraˇzava veze medu
tipovima zapisa.
Objektni model. Inspiriran je objektno-orijentiranim programskim jezicima. Baza je skup trajno
pohranjenih objekata koji se sastoje od svojih internih podataka i “metoda” (operacija) za ruko-
vanje s tim podacima. Svaki objekt pripada nekoj klasi. Izmedu klasa se uspostavljaju veze
nasljedivanja, agregacije, odnosno medusobnog koriˇstenja operacija.
Hijerarhijski i mreˇzni model bili su u uptrebi u 60-tim i 70-tim godinama 20. stolje´ca. Od 80-tih godina
pa sve do danaˇsnjih dana prevladava relacijski model. Oˇcekivani prijelaz na objektni model za sada
se nije desio, tako da danaˇsnje baze podataka uglavnom joˇs uvijek moˇzemo poistovjetiti s relacijskim
bazama.
3
4 1. UVOD U BAZE PODATAKA
1.1.2 Ciljevi koji se nastoje posti´ci koriˇstenjem baza podataka
Spomenuli smo da baze podataka predstavljaju viˇsu razinu rada s podacima u odnosu na klasiˇcne
programske jezike. Ta viˇsa razina rada oˇcituje se u tome ˇsto tehnologija baza podataka nastoji (i u
velikoj mjeri uspijeva) ispuniti sljede´ce ciljeve.
Fiziˇcka nezavisnost podataka. Razdvaja se logiˇcka definicija baze od njene stvarne fiziˇcke grade.
Znaˇci, ako se fiziˇcka grada promijeni (na primjer, podaci se prepiˇsu u druge datoteke na drugim
diskovima), to ne´ce zahtijevati promjene u postoje´cim aplikacijama.
Logiˇcka nezavisnost podataka. Razdvaja se globalna logiˇcka definicija cijele baze podataka od
lokalne logiˇcke definicije za jednu aplikaciju. Znaˇci, ako se logiˇcka definicija promijeni (na primjer
uvede se novi zapis ili veza), to ne´ce zahtijevati promjene u postoje´cim aplikacijama. Lokalna
logiˇcka definicija obiˇcno se svodi na izdvajanje samo nekih elemenata iz globalne definicije, uz
neke jednostavne transformacije tih elemenata.
Fleksibilnost pristupa podacima. U starijim mreˇznim i hijerarhijskim bazama, staze pristupanja
podacima bile su unaprijed definirane, dakle korisnik je mogao pretraˇzivati podatke jedino onim
redoslijedom koji je bio predviden u vrijeme projektiranja i implementiranja baze. Danas se
zahtijeva da korisnik moˇze slobodno prebirati po podacima, te po svom nahodenju uspostavljati
veze medu podacima. Ovom zahtjevu zaista zadovoljavaju jedino relacijske baze.
Istovremeni pristup do podataka. Baza mora omogu´citi da ve´ci broj korisnika istovremeno koristi
iste podatke. Pritom ti korisnici ne smiju ometati jedan drugoga, te svaki od njih treba imati
dojam da sam radi s bazom.
ˇ
Cuvanje integriteta. Nastoji se automatski saˇcuvati korektnost i konzistencija podataka, i to u
situaciji kad postoje greˇske u aplikacijama, te konfliktne istrovremene aktivnosti korisnika.
Mogu´cnost oporavka nakon kvara. Mora postojati pouzdana zaˇstita baze u sluˇcaju kvara hard-
vera ili greˇsaka u radu sistemskog softvera.
Zaˇstita od neovlaˇstenog koriˇstenja. Mora postojati mogu´cnost da se korisnicima ograniˇce prava
koriˇstenja baze, dakle da se svakom korisniku reguliraju ovlaˇstenja ˇsto on smije a ˇsto ne smije
raditi s podacima.
Zadovoljavaju´ca brzina pristupa. Operacije s podacima moraju se odvijati dovoljno brzo, u skladu
s potrebama odredene aplikacije. Na brzinu pristupa moˇze se utjecati odabirom pogodnih fiziˇckih
struktura podataka, te izborom pogodnih algoritama za pretraˇzivanje.
Mogu´cnost podeˇsavanja i kontrole. Velika baza zahtijeva stalnu brigu: pra´cenje performansi, mi-
jenjanje parametara u fiziˇckoj gradi, rutinsko pohranjivanje rezervnih kopija podataka, reguliranje
ovlaˇstenja korisnika. Takoder, svrha baze se vremenom mijenja, pa povremeno treba podesiti i
logiˇcku strukturu. Ovakvi poslovi moraju se obavljati centralizirano. Odgovorna osoba zove
se administrator baze podataka. Administratoru trebaju stajati na raspolaganju razni alati i
pomagala.
1.1.3 Arhitektura baze podataka
Arhitektura baze podataka sastoji se od tri “sloja” i suˇcelja medu slojevima, kao ˇsto je prikazano na
Slici 1.1. Rijeˇc je o tri razine apstrakcije
Fiziˇcka razina odnosi se na fiziˇcki prikaz i raspored podataka na jedinicama vanjske memorije. To je
aspekt kojeg vide samo sistemski programeri (oni koji su razvili DBMS). Sama fiziˇcka razina moˇze
se dalje podijeliti na viˇse pod-razina apstrakcije, od sasvim konkretnih staza i cilindara na disku,
do ve´c donekle apstraktnih pojmova datoteke i zapisa kakve susre´cemo u klasiˇcnim programskim
jezicima. Raspored pohranjivanja opisuje kako se elementi logiˇcke definicije baze preslikavaju
na fiziˇcke uredaje.
Globalna logiˇcka razina odnosi se na logiˇcku strukturu cijele baze. To je aspekt kojeg vidi projek-
tant baze odnosno njen administrator. Zapis logiˇcke definicije naziva se shema (engleski takoder
schema). Shema je tekst ili dijagram koji definira logiˇcku strukturu baze, i u skladu je sa zadanim
1.1. OSNOVNI POJMOVI VEZANI UZ BAZE PODATAKA 5
modelom. Dakle imenuju se i definiraju svi tipovi podataka i veze medu tim tipovima, u skladu
s pravilima koriˇstenog modela. Takoder, shema uvodi i ograniˇcenja kojim se ˇcuva integritet
podataka.
Lokalna logiˇcka razina odnosi se na logiˇcku predodˇzbu o dijelu baze kojeg koristi pojedina aplikacija.
To je aspekt kojeg vidi korisnik ili aplikacijski programer. Zapis jedne lokalne logiˇcke definicije
zove se pogled (engleski view) ili pod-shema. To je tekst ili dijagramkojimse imenuju i definiraju
svi lokalni tipovi podataka i veze medu tim tipovima, opet u skladu s pravilima koriˇstenog modela.
Takoder, pogled zadaje preslikavanje kojim se iz globalnih podataka i veza izvode lokalni.
Aplikacijski
program 1
Aplikacijski
program 2
Aplikacijski
program 3
`
·
`
·
`
·
Pogled 1 Pogled 2 Pogled 3

´

`
·

»
Shema
`
·
Raspored
pohranjivanja

»
´

Datoteke Datoteke
Lokalna
logiˇcka
razina
Globalna
logiˇcka
razina
Fiziˇcka
razina
Slika 1.1: Arhitektura baze podataka
Za stvaranje baze podataka potrebno je zadati samo shemu i poglede. DBMS tada automatski
generira potrebni raspored pohranjivanja i fiziˇcku bazu. Administrator moˇze samo donekle utjecati na
fiziˇcku gradu baze, podeˇsavanjem njemu dostupnih parametara.
Programi i korisnici ne pristupaju izravno fiziˇckoj bazi, ve´c dobivaju ili pohranjuju podatke posred-
stvom DBMS-a. Komunikacija programa odnosno korisnika s DBMS-om obavlja se na lokalnoj logiˇckoj
razini.
1.1.4 Jezici za rad s bazama podataka
Komunikacija korisnika odnosno aplikacijskog programa i DBMS-a odvija se pomo´cu posebnih jezika.
Ti jezici tradicionalno se dijele na sljede´ce kategorije.
Jezik za opis podataka (Data Description Language - DDL). Sluˇzi projektantu baze ili administra-
toru u svrhu zapisivanja sheme ili pogleda. Dakle tim jezikom definiramo podatke i veze medu
podacima, i to na logiˇckoj razini. Koji puta postoji posebna varijanta jezika za shemu, a posebna
za poglede. Naredbe DDL obiˇcno podsije´caju na naredbe za definiranje sloˇzenih tipova podataka
u jezicima poput COBOL, PL/I, C, Pascal.
Jezik za manipuliranje podacima (Data Manipulation Language - DML). Sluˇzi programeru za
uspostavljanje veze izmedu aplikacijskog programa i baze. Naredbe DML omogu´cuju “manevri-
ranje” po bazi, te jednostavne operacije kao ˇsto su upis, promjena, brisanje ili ˇcitanje zapisa. U
nekim softverskim paketima, DML je zapravo biblioteka potprograma: “naredba” u DML svodi
se na poziv potprograma. U drugim paketima zaista se radi o posebnom jeziku: programer tada
piˇse program u kojem su izmijeˇsane naredbe dvaju jezika, pa takav program treba prevoditi s
dva prevodioca (DML-precompiler, obiˇcni compiler).
6 1. UVOD U BAZE PODATAKA
Jezik za postavljanje upita (Query Language - QL). Sluˇzi neposrednom korisniku za interaktivno
pretraˇzivanje baze. To je jezik koji podsije´ca na govorni (engleski) jezik Naredbe su neprocedu-
ralne, dakle takve da samo specificiraju rezultat kojeg ˇzelimo dobiti, a ne i postupak za dobivanje
rezultata.
Ovakva podjela na tri jezika danas je ve´c priliˇcno zastarjela. Naime, kod relacijskih baza postoji
tendencija da se sva tri jezika objedine u jedan sveobuhvatni. Primjer takvog integriranog jezika
za relacijske baze je SQL: on sluˇzi za definiranje podataka, manipuliranje i pretraˇzivanje. Integrirani
jezik se moˇze koristiti interaktivno (preko on-line interpretera) ili se on moˇze pojavljivati uklopljen u
aplikacijske programe.
Naglasimo da gore spomenute vrste jezika nisu programski jezici. Dakle ti jezici su nam nuˇzni da
bi se povezali s bazom, no oni nam nisu dovoljni za razvoj aplikacija koje ´ce neˇsto raditi s podacima iz
baze.
Tradicionalni naˇcin razvoja aplikacija koje rade s bazom je koriˇstenje klasiˇcnih programskih jezika
(COBOL, PL/I, C, Pascal . . . ) s ugnijeˇzdenim DML-naredbama. U 80-timgodinama 20. stolje´ca bili su
dosta popularni i tzv. jezici 4. generacije (4-th Generation Languages - 4GL): rijeˇc je o jezicima koji
su bili namijenjeni iskljuˇcivo za rad s bazama, te su zato u tom kontekstu bili produktivniji od klasiˇcnih
programskih jezika op´ce namjene. Problem s jezicima 4. generacije je bio u njihovoj nestandardnosti:
svaki od njih je u pravilu bio dio nekog odredenog softverskog paketa za baze podataka, te se nije
mogao koristiti izvan tog paketa (baze).
U danaˇsnje vrijeme, aplikacije se najˇceˇs´ce razvijaju u standardnim objektno orijentiranim pro-
gramskim jezicima (Java, C++, . . . ). Za interakcije s bazom koriste se unaprijed pripremljene klase
objekata. Ovakva tehnika je dovoljno produktivna zbog koriˇstenja gotovih klasa, a rezultiraju´ci pro-
gram se lako dotjeruje, uklapa u ve´ce sustave ili prenosi s jedne baze na drugu.
1.1.5 Poznati softverski paketi za rad s bazama podataka
Baze podataka se u pravilu realiziraju koriˇstenjem nekog od provjerenih softverskih paketa. Tabelarni
prikaz 1.1 daje pregled softvera koji u ovom trenutku predstavljaju tehnoloˇski vrh te imaju znaˇcajan
udjel na svjetskom trˇziˇstu.
Gotovo svi danaˇsnji softverski paketi podrˇzavaju relacijski model i SQL. Svaki od njih sadrˇzi svoj
DBMS, uobiˇcajene klijente (na primjer interaktivni interpreter SQL), te biblioteke i alate za razvoj
aplikacija. Svaki paket isporuˇcuje se u verzijama za razne raˇcunalne platforme (operacijske sustave).
Konkurencija medu proizvodaˇcima softvera za baze podataka je izuzetno velika, tako da je posljed-
njih godina ˇcesto dolazilo do njihovog nestanka, spajanja ili preuzimanja. Lista relevantnih softverskih
paketa zato je svake godine sve kra´ca. Jedino osvjeˇzenje predstavlja nedavna pojava public-domain
sotvera poput MySQL.
1.2
ˇ
Zivotni ciklus baze podataka
Uvodenje baze podataka u neko poduze´ce ili ustanovu predstavlja sloˇzeni zadatak koji zahtijeva tim-
ski rad struˇcnjaka raznih profila. To je projekt koji se moˇze podijeliti u pet faza: analiza potreba,
modeliranje podataka, implementacija, testiranje i odrˇzavanje.
1.2.1 Analiza potreba
Prouˇcavaju se tokovi informacija u poduze´cu. Uoˇcavaju se podaci koje treba pohranjivati i veze medu
njima. U velikom poduze´cima, gdje postoje razne grupe korisnika, pojavit ´ce se razni “pogledi” na
podatke. Te poglede treba uskladiti tako da se eliminira redundancija i nekonzistentnost. Na primjer,
treba u raznim pogledima prepoznati sinonime i homonime, te uskladiti terminologiju.
Analiza potreba takoder treba obuhvatiti analizu transakcija (operacija) koje ´ce se obavljati nad
bazom podataka, budu´ci da to moˇze isto imati utjecaja na sadrˇzaj i konaˇcni oblik baze. Vaˇzno je
procijeniti frekvenciju i opseg pojedinih transakcija, te zahtjeve na performanse.
Rezultat analize je dokument (pisan neformalno u prirodnom jeziku) koji se zove specifikacija
potreba.
1.2.
ˇ
ZIVOTNI CIKLUS BAZE PODATAKA 7
Proizvodaˇc Produkt Operacijski sustav Jezici
IBM Corporation DB2 Linux, UNIX (razni), SQL,
MS Windows NT/2000/XP, COBOL,
VMS, MVS, VM, OS/400 Java, . . .
Oracle Corporation Oracle MS Windows (razni), SQL,
Mac OS, UNIX (razni), Java i
Linux i drugi drugi
IBM Corporation Informix UNIX (razni), Linux, SQL,
(prije : Informix MS Windows NT/2000/XP Java i
Software Inc.) drugi
Microsoft MS SQL Server MS Windows NT/2000/XP SQL,
C++, . . .
MySQL AB MySQL Linux, UNIX (razni), SQL,
MS Windows (razni), Mac OS C, PHP, . . .
Sybase Inc. Sybase MS Windows NT/2000, OS/2, SQL,
SQL Server Mac, UNIX (razni), UNIXWare COBOL, . . .
Hewlett Packard Co. Allbase/SQL UNIX (HP-UX) SQL,
4GL, C, . . .
Cincom Supra MS Windows NT/2000, Linux, SQL,
Systems Inc. UNIX (razni), VMS, MVS, VM COBOL, . . .
Microsoft Corporation MS Access MS Windows (razni) Access
Basic,
SQL
Tabelarni prikaz 1.1: Poznati softverski paketi za rad s bazama podataka
1.2.2 Modeliranje podataka
Razliˇciti pogledi na podatke, otkriveni u fazi analize, sintetiziraju se u jednu cjelinu - globalnu shemu.
Precizno se utvrduju tipovi podataka. Shema se dalje dotjeruje (“normalizira”) tako da zadovolji neke
zahtjeve kvalitete. Takoder, shema se prilagodava ograniˇcenjima koje postavlja zadani model podataka,
te se dodatno modificira da bi bolje mogla udovoljiti zahtjevima na performanse. Na kraju se iz sheme
izvode pogledi (pod-sheme) za pojedine aplikacije (grupe korisnika).
1.2.3 Implementacija
Na osnovu sheme i pod-shema, te uz pomo´c dostupnog DBMS-a, fiziˇcki se realizira baza podataka
na raˇcunalu. U DBMS-u obiˇcno postoje parametri kojima se moˇze utjecati na fiziˇcku organizaciju
baze. Parametri se podeˇsavaju tako da se osigura efikasan rad najvaˇznijih transakcija. Razvija se skup
programa koji realiziraju pojedine transakcije te pokrivaju potrebe raznih aplikacija. Baza se inicijalno
puni podacima.
8 1. UVOD U BAZE PODATAKA
1.2.4 Testiranje
Korisnici pokusno rade s bazom i provjeravaju da li ona zadovoljava svim zahtjevima. Nastoje se
otkriti greˇske koje su se mogle potkrasti u svakoj od faza razvoja: dakle u analizi potreba, modeliranju
podataka, implementaciji. Greˇske u ranijim fazama imaju teˇze posljedice. Na primjer, greˇska u analizi
potreba uzrokuje da transakcije moˇzda korektno rade, no ne ono ˇsto korisnicima treba ve´c neˇsto drugo.
Dobro bi bilo kad bi takve propuste otkrili prije implementacije. Zato se u novije vrijeme, prije
prave implementacije, razvijaju i pribliˇzni prototipovi baze podataka, te se oni pokazuju korisnicima.
Jeftinu izradu prototipova omogu´cuju jezici 4. generacije i objektno-orijentirani jezici.
1.2.5 Odrˇzavanje
Odvija se u vrijeme kad je baza ve´c uˇsla u redovnu upotrebu. Sastoji se od sljede´ceg: popravak greˇsaka
koje nisu bile otkrivene u fazi testiranja; uvodenje promjena zbog novih zahtjeva korisnika; podeˇsavanje
parametara u DBMS u svrhu poboljˇsavanja performansi. Odrˇzavanje zahtijeva da se stalno prati rad
s bazom, i to tako da to pra´cenje ne ometa korisnike. Administratoru baze podataka trebaju stajati
na raspolaganju odgovaraju´ci alati (utility programi).
2
MODELIRANJE PODATAKA
2.1 Modeliranje entiteta i veza
Bavimo se pitanjem: kako oblikovati shemu za bazu podataka, uskladenu s pravilima relacijskog modela.
U stvarnim situacijama dosta je teˇsko direktno pogoditi relacijsku shemu. Zato se sluˇzimo jednom
pomo´cnom fazom koja se zove modeliranje entiteta i veza (Entity-Relationship Modelling). Rijeˇc
je o oblikovanju jedne manje precizne, konceptualne sheme, koja predstavlja apstrakciju realnog svijeta.
Ta tzv. ER-shema se dalje, viˇse-manje automatski, pretvara u relacijsku. Modeliranje entiteta i veza
zahtijeva da se svijet promatra preko tri kategorije:
entiteti: objekti ili dogadaji koji su nam od interesa;
veze: odnosi medu entitetima koji su nam od interesa;
atributi: svojstva entiteta i veza koja su nam od interesa.
2.1.1 Entiteti i atributi
Entitet je neˇsto o ˇcemu ˇzelimo spremati podatke, neˇsto ˇsto je u stanju postojati ili ne postojati, te se
moˇze identificirati. Entitet moˇze biti objekt ili bi´ce (na primjer ku´ca, student, auto), odnosno dogadaj
ili pojava (na primjer nogometna utakmica, praznik, servisiranje auta).
Entitet je opisan atributima (na primjer atributi ku´ce su: adresa, broj katova, boja fasade, . . . ).
Ukoliko neki atribut i sam zahtijeva svoje atribute, tada ga radije treba smatrati novim entitetom (na
primjer model auta). Isto pravilo vrijedi i ako atribut moˇze istovremeno imati viˇse vrijedenosti (na
primjer kvar koji je popravljen pri servisiranju auta).
Ime entiteta, zajedno sa pripadnim atributima, zapravo odreduje tip entiteta. Moˇze postojati
mnogo primjeraka (pojava) entiteta zadanog tipa (na primjer STUDENT je tip ˇciji primjerci su
Petrovi´c Petar, Markovi´c Marko, . . . ).
Kandidat za kljuˇc je atribut, ili skup atributa, ˇcije vrijednosti jednoznaˇcno odreduju primjerak
entiteta zadanog tipa. Dakle, ne mogu postojati dva razliˇcita primjerka entiteta istog tipa s istim
vrijednostima kandidata za kljuˇc. (Na primjer za tip entiteta AUTO, kandidat za kljuˇc je atribut
REG BROJ). Ukoliko jedan tip entiteta ima viˇse kandidata za kljuˇc, tada biramo jednog od njih i
proglaˇsavamo ga primarnim kljuˇcem. (Na primjer primarni kljuˇc za tip entiteta STUDENT mogao
bi biti atribut BROJ INDEKSA.
2.1.2 Veze
Veze se uspostavljaju izmedu dva ili viˇse tipova entiteta (na primjer veza IGRA ZA izmedu tipova
entiteta IGRA
ˇ
C i TIM). Zapravo je rijeˇc o imenovanoj binarnoj ili k-narnoj relaciji izmedu prim-
jeraka entiteta zadanih tipova. Za sada ´cemo se ograniˇciti na veze izmedu toˇcno dva tipa entiteta.
Funkcionalnost veze moˇze biti:
Jedan-naprama-jedan (1 : 1). Jedan primjerak prvog tipa entiteta moˇze biti u vezi s najviˇse jednim
primjerkom drugog tipa entiteta, te takoder jedan primjerak drugog tipa moˇze biti u vezi s
najviˇse jednim primjerkom prvog tipa. Na primjer veza JE PRO
ˇ
CELNIK izmedu tipova entiteta
NASTAVNIK i ZAVOD (na fakultetu).
9
10 2. MODELIRANJE PODATAKA
Jedan-naprama-mnogo (1 : N). Jedan primjerak prvog tipa entiteta moˇze biti u vezi s 0, 1 ili viˇse
primjeraka drugog tipa entiteta, no jedan primjerak drugog tipa moˇze biti u vezi s najviˇse jed-
nim primjerkog prvog tipa. Na primjer veza PREDAJE izmedu tipova entiteta NASTAVNIK i
KOLEGIJ.
Mnogo-naprama-mnogo (M : N). Jedan primjerak prvog tipa entiteta moˇze biti u vezi s 0, 1 ili
viˇse primjeraka drugog tipa entiteta, te takoder jedan primjerak drugog tipa moˇze biti u vezi s
0, 1 ili viˇse primjeraka prvog tipa. Na primjer veza UPISAO izmedu tipova entiteta STUDENT
i KOLEGIJ.
Veza moˇze imati i svoje atribute koje ne moˇzemo pripisati ni jednom od tipova entiteta (na primjer
veza UPISAO moˇze imati atribut DATUM UPISA).
Ako svaki primjerak entiteta nekog tipa mora sudjelovati u zadanoj vezi, tada kaˇzemo da tip entiteta
ima obavezno ˇclanstvo u toj vezi. Inaˇce tip entiteta ima neobavezno ˇclanstvo. (Na primjer izmedu
tipova entiteta ISPIT i KOLEGIJ zadana je veza IZ, koja ima funkcionalnost (N : 1). ISPIT ima
obavezno ˇclanstvo u vezi IZ, jer svaki ispit mora biti iz nekog kolegija.) Odluka da li je ˇclanstvo
obavezno ili neobavezno koji put je stvar dogovora odnosno projektantove odluke (na primjer ˇclanstvo
za KOLEGIJ u vezi PREDAJE).
2.1.3 Prikaz ER-sheme pomo´cu dijagrama
Obiˇcaj je da se ER-shema nacrta kao dijagram u kojem pravokutnici predstavljaju tipove entiteta, a
rombovi veze. Veze su povezane bridovima s odgovaraju´cim tipovima entiteta. Imena tipova entiteta
i veza, te funkcionalnost veza, uneseni su u dijagram. Posebno se prilaˇze lista atributa za svaki entitet
odnosno vezu. U toj listi moˇzemo specificirati obaveznost ˇclanstva u vezama.
STUDENT

UPISAO
KOLEGIJ

PREDAJE NASTAVNIK

NUDI

JE
PRO
ˇ
CEL
NIK

JE U
ZAVOD
>
>
>
>
>

M
N
N
N 1
1
1
1
N
1
Slika 2.1: ER-shema baze podataka o fakultetu
Kao primjer, pogledajmo dijagram na Slici 2.1 koji prikazuje bazu podataka o fakultetu. Tipovi
entiteta su:
1. ZAVOD, s atributima IME ZAVODA, ADRESA, . . .
2. KOLEGIJ, s atributima BR KOLEGIJA, NASLOV, SEMESTAR, . . .
3. STUDENT, s atributima BR INDEKSA, IME STUDENTA, ADRESA, SPOL, . . .
2.1. MODELIRANJE ENTITETA I VEZA 11
4. NASTAVNIK, s atributima IME NASTAVNIKA(pretpostavljamo da je jedinstveno), BR SOBE,
. . .
Podvuˇceni atributi ˇcine primarni kljuˇc. Veze su:
1. JE PRO
ˇ
CELNIK, bez atributa. ZAVOD ima obavezno ˇclanstvo.
2. JE U, bez atributa. NASTAVNIK ima obavezno ˇclanstvo.
3. NUDI , bez atributa. KOLEGIJ ima obavezno ˇclanstvo.
4. UPISAO, s atributom DATUM UPISA.
5. PREDAJE, bez atributa. KOLEGIJ ima na primjer obavezno ˇclanstvo.
2.1.4 Sloˇzenije veze
U stvarnim situacijama pojavljuju se i sloˇzenije veze od onih koje smo do sada promatrali. Navest
´cemo neke od njih.
Involuirana veza povezuje jedan tip entiteta s tim istim tipom. Dakle rijeˇc je o binarnoj relaciji
izmedu raznih primjeraka entiteta istog tipa. Funkcionalnost takve veze opet moˇze biti (1 : 1), (1 : N),
odnosno (M : N).
DIO PROIZVODA

SADR
ˇ
ZI

N
M
SURADNIK

JE
ˇ
SEF
ZA

.
1
N
OSOBA

U
BRAKU
S

1
1
Slika 2.2: Primjeri za involuirane veze
Slika 2.2 sadrˇzi primjere za involuirane veze s razliˇcitim funkcionalnostima. Prvi dijagram na Slici
2.2 napravljen je pod pretpostavkom da su proˇsli brakovi osobe zaboravljeni, a poligamija zabranjena.
ˇ
Clanstvo u u vezi U BRAKU S je neobavezno. Drugi dijagram na Slici 2.2 ima ucrtanu strelicu
koja pokazuje smjer tumaˇcenja veze JE
ˇ
SEF ZA. Moˇzemo uzeti da je ˇclanstvo u toj vezi neobavezno,
jer postoji barem jedan suradnik koji nema ˇsefa. Tre´ci dijagram na Slici 2.2 odnosi se na dijelove
proizvoda koji se proizvode u nekoj tvornici. Pritom jedan sloˇzeniji dio sadrˇzi viˇse jednostavnijih. Isti
jednostavniji dio pojavljuje se u viˇse sloˇzenih.
Pod-tipovi. Tip entiteta E
1
je podtip tipa entiteta E
2
ako je svaki primjerak od E
1
takoder i
primjerak od E
2
. E
1
nasljeduje sve atribute od E
2
, no E
1
moˇze imati i dodatne atribute. Situaciju
opisujemo pomo´cu specijalne (1 : 1) veze JE (engleski IS A koja se moˇze pojaviti viˇse puta unutar
ER-sheme.
Slika 2.3 sadrˇzi primjer ER-sheme s pod-tipovima i nad-tipovima. Rijeˇc je o tipovima entiteta za
osobe koje se pojavljuju na fakultetu. NASTAVNIK ukljuˇcuje profesore, docente i asistente.
12 2. MODELIRANJE PODATAKA
STUDENT

JE
OSOBA
PROFESOR

JE
NASTAVNIK

JE
>
>
>
>
`

º
1
1
1 1
1 1
Slika 2.3: Primjer ER-sheme s pod-tipovima entiteta
PROIZVOD

IZVOZI
ZEMLJA
KOMPANIJA

`
`
`
`
P N
M
Slika 2.4: Primjer ternarne veze
Ternarne veze uspostavljaju se izmedu tri tipa entiteta. Znaˇci rijeˇc je o ternarnoj relaciji izmedu
primjeraka triju tipova entiteta. Postoje brojne mogu´cnosti za funkcionalnost ternarne veze, na primjer
(N : M : P), (1 : N : M), (1 : 1 : N) ili ˇcak (1 : 1 : 1).
Primjer ternarne veze sa Slike 2.4 odnosi se na podatke o kompanijama, proizvodima koje one
proizvode i zemljama u koje one izvoze svoje proizvode. Funkcionalnost ove veze je mnogo-naprama-
mnogo-naprama-mnogo, dakle (N : M : P), jer na primjer za zadani par (kompanija, proizvod) postoji
mnogo zemalja u koje ta kompanija izvozi taj proizvod, itd.
Ternarnu vezu uvodimo samo onda kad se ona ne moˇze rastaviti na dvije binarne. Uzmimo da
u primjeru sa Slike 2.4 vrijedi pravilo: ako kompanija izvozi u neku zemlju, tada ona odmah izvozi
sve svoje proizvode u tu zemlju. Uz ovo pravilo, razmatrana ternarna veza moˇze se zamijeniti s dvije
binarne, u skladu s dijagramom na Slici 2.5.
ER model dovoljno je jednostavan da ga ljudi razliˇcitih struka mogu razumjeti. Zato ER shema sluˇzi
za komunikaciju projektanta baze podataka i korisnika, i to u najranijoj fazi razvoja baze. Postoje´ci
DBMS ne mogu direktno implementirati ER shemu, ve´c zahtijevaju da se ona detaljnije razradi, te
modificira u skladu s pravilima relacijskog, mreˇznog, odnosno hijerarhijskog modela.
2.2. RELACIJSKI MODEL 13
PROIZVOD

RADI
ZEMLJA

PRODAJE
KOMPANIJA
>
>
>
>

M M
N N
Slika 2.5: Rastavljanje ternarne veze na dvije binarne
2.2 Relacijski model
Relacijski model bio je teoretski zasnovan joˇs krajem 60-tih godina 20. stolje´ca, u radovima E.F.
Codd-a. Model se dugo pojavljivao samo u akademskim raspravama i knjigama. Prve realizacije na
raˇcunalu bile su suviˇse spore i neefikasne. Zahvaljuju´ci intenzivnom istraˇzivanju, te napretku samih
raˇcunala, efikasnost relacijskih baza postepeno se poboljˇsavala. Sredinom 80-tih godina 20. stolje´ca
relacijski model je postao prevladavaju´ci. I danas ve´cina DBMS koristi taj model.
2.2.1 Relacija, atribut, n-torka, kljuˇc
Relacijski model zahtijeva da se baza podataka sastoji od skupa pravokutnih tabela - tzv. relacija.
Svaka relacija ima svoje ime po kojem je razlikujemo od ostalih u istoj bazi. Jedan stupac relacije
obiˇcno sadrˇzi vrijednost jednog atributa (za entitet ili vezu) - zato stupac poistovje´cujemo s atributom
i obratno. Atribut ima svoje ime po kojem ga razlikujemo od ostalih u istoj relaciji. Vrijednosti jednog
atributa su podaci istog tipa. Dakle, definiran je skup dozvoljenih vrijednosti za atribut, koji se zove
domena atributa. Vrijednost atributa mora biti jednostruka i jednostavna (ne da se rastaviti na
dijelove). Pod nekim uvjetima toleriramo situaciju da vrijednost atributa nedostaje (nije upisana).
Jedan redak relacije obiˇcno predstavlja jedan primjerak entiteta, ili biljeˇzi vezu izmedu dva ili viˇse
primjeraka. Redak nazivamo n-torka. U jednoj relaciji ne smiju postojati dvije jednake n-torke. Broj
atributa je stupanj relacije, a broj n-torki je kardinalnost relacije.
Kao primjer, navodimo u Tabelarnom prikazu 2.1 relaciju AUTO, s atributima REG BROJ,
PROIZVODA
ˇ
C, MODEL, GODINA. Relacija sadrˇzi podatke o automobilimakoji se nalaze na popravku
u nekoj radionici.
AUTO
REG BROJ PROIZVODA
ˇ
C MODEL GODINA
ZID654 Ford Fiesta 1997
BXI930 Volkswagen Golf 1996
COI453 Nissan Primera 1997
ZXI675 Ford Escort 1995
RST786 Fiat Punto 1993
TXI521 Ford Orion 1995
HCY675 Volkswagen Jetta 1997
Tabelarni prikaz 2.1: Relacija s podacima o automobilima.
Relacija ne propisuje nikakav redoslijed svojih n-torki i atributa. Dakle, permutiranjem redaka i
stupaca tabele dobivamo drukˇciji zapis iste relacije.
Uvedena terminologija potjeˇce iz matematike. Naime, neka je R relacija stupnja n i neka su domene
njenih atributa redom D
1
, D
2
, . . . , D
n
. Tada se R moˇze interpretirati kao podskup Kartezijevog
produkta D
1
D
2
. . . D
n
. Znaˇci, naˇs pojam relacije odgovara matematiˇckom pojmu n-narne
14 2. MODELIRANJE PODATAKA
relacije. U komercijalnim DBMS, umjesto “matematiˇckih” termina (relacija, n-torka, atribut), ˇceˇs´ce
se koriste neposredni termini (tabela, redak, stupac) ili termini iz tradicionalnih programskih jezika
(datoteka, zapis, polje).
Kljuˇc K relacije R je podskup atributa od R koji ima sljede´ca “vremenski neovisna” svojstva:
1. Vrijednosti atributa iz K jednoznaˇcno odreduju n-torku u R. Dakle ne mogu u R postojati dvije
n-torke s istim vrijednostima atributa iz K.
2. Ako izbacimo iz K bilo koji atribut, tada se naruˇsava svojstvo 1.
Budu´ci da su sve n-torke u R medusobno razliˇcite, K uvijek postoji. Naime, skup svih atributa
zadovoljava svojstvo 1. Izbacivanjem suviˇsnih atributa do´ci ´cemo do podskupa koji zadovoljava i
svojstvo 2.
Deˇsava se da relacija ima viˇse kandidata za kljuˇc. Tada jedan on njih proglaˇsavamo primarnim
kljuˇcem. Atributi koji sastavljaju primarni kljuˇc zovu se primarni atributi. Vrijednost primarnog
atributa ne smije ni u jednoj n-torki ostati neupisana.
Gradu relacije kratko opisujemo tzv. shemom relacije, koja se sastoji od imena relacije i popisa
imena atributa u zagradama. Primarni atributi su podvuˇceni. Na primjer, za relaciju o automobilima
(Tabelarni prikaz 2.1), shema izgleda ovako:
AUTO ( REG BROJ, PROIZVODA
ˇ
C, MODEL, GODINA ) .
2.2.2 Pretvaranje ER-sheme u relacijsku
U nastavku objaˇsnjavamo kako se pojedini elementi ER-sheme pretvaraju u relacije. Na taj naˇcin
pokazat ´cemo kako se iz cijele ER-sheme dobiva relacijska shema.
Pretvorba tipova entiteta. Svaki tip entiteta prikazuje se jednom relacijom. Atributi tipa postaju
atributi relacije. Jedan primjerak entiteta prikazan je jednom n-torkom. Primarni kljuˇc entiteta
postaje primarni kljuˇc relacije. Na primer tip STUDENT iz naˇse fakultetske baze podataka sa Slike
2.1 prikazuje se relacijom:
STUDENT ( BR INDEKSA, IME STUDENTA, ADRESA, SPOL, . . . ) .
Doduˇse, sudjelovanje entiteta u vezama moˇze zahtijevati da se u relaciju dodaju joˇs neki atributi koji
nisu postojali u odgovaraju´cem tipu entiteta.
Pretvorba binarnih veza. Ako tip entiteta E
2
ima obavezno ˇclanstvo u (N : 1) vezi s tipom E
1
, tada
relacija za E
2
treba ukljuˇciti primarne atribute od E
1
. Na primjer ako u ER-shemi sa Slike 2.1 svaki
kolegij mora biti ponuden od nekog zavoda, tada se veza NUDI svodi na to da u relaciju KOLEGIJ
ubacimo kljuˇc relacije ZAVOD :
KOLEGIJ ( BR KOLEGIJA, IME ZAVODA, NASLOV, SEMESTAR, . . . ) .
Kljuˇc jedne relacije koji je prepisan u drugu relaciju zove se strani kljuˇc (u toj drugoj relaciji).
Ako tip entiteta E
2
ima neobavezno ˇclanstvo u (N : 1) vezi s tipom E
1
, tada vezu moˇzemo prikazati
na prethodni naˇcin, ili uvodenjem nove relacije ˇciji atributi su primarni atributi od E
1
i E
2
.
POSUDIVA
ˇ
C

POSUDBA KNJIGA
1 N
Slika 2.6: ER-shema za dio baze podataka o knjiˇznici
Kao primjer, promotrimo vezu na Slici 2.6 koja prikazuje posudivanje knjiga u knjiˇznici. Odgo-
varaju´ce relacije za prikaz te veze i pripadnih entiteta mogle bi biti:
POSUDIVA
ˇ
C ( BR ISKAZNICE, PREZIME IME, ADRESA, . . . ) ,
KNJIGA ( REG BROJ, BR ISKAZNICE, NASLOV, . . . ) .
Ovdje smo u relaciju KNJIGA dodali BR ISKAZNICE osobe koja je posudila knjigu. Vrijednost
atributa BR ISKAZNICE bit ´ce prazna u mnogim n-torkama relacije KNJIGA, tj. za sve knjige koje
trenutno nisu posudene. Drugo rjeˇsenje zahtijeva tri relacije:
2.2. RELACIJSKI MODEL 15
POSUDIVA
ˇ
C ( BR ISKAZNICE, PREZIME IME, ADRESA, . . . ) ,
KNJIGA ( REG BROJ, NASLOV, . . . ) ,
POSUDBA ( REG BROJ, BR ISKAZNICE ) .
Samo one knjige koje su trenutno posudene predstavljene su n-torkom u relaciji POSUDBA. Posebna
relacija za prikaz veze je pogotovo preporuˇcljiva ako relacija ima svoje atribute. Na primjer u relaciju
POSUDBA mogli bi uvesti atribut DATUM VRA
´
CANJA.
(N : M) veza se uvijek prikazuje posebnom relacijom, koja se sastoji od primarnih atributa za oba
tipa entiteta zajedno s eventualnim atributima veze. Na primjer veza UPISAO iz fakultetske baze sa
Slike 2.1 prikazuje se relacijom:
UPISAO ( BR INDEKSA, BR KOLEGIJA, DATUM UPISA ) .
ˇ
Cinjenica da je jedan student upisao jedan kolegij prikazuje se jednom n-torkom u relaciji UPISAO.
Kljuˇc za UPISAO je oˇcito sloˇzen od atributa BR INDEKSA i BR KOLEGIJA, jer ni jedan od ovih
atributa sam nije dovoljan da jednoznaˇcno odredi n-torku u toj relaciji.
Pretvorba involuiranih veza. Obavlja se sliˇcno kao za binarne veze. Posluˇzit ´cemo se primjerima sa
Slike 2.2. Tip entiteta OSOBA i (1 : 1) vezu U BRAKU S najbolje je (zbog neobaveznosti) prikazati
pomo´cu dvije relacije:
OSOBA ( JMBG, PREZIME IME, ADRESA, . . . ) ,
BRAK ( JMBG MU
ˇ
ZA, JMBG
ˇ
ZENE, DATUM VJEN
ˇ
CANJA ) .
Tip entiteta SURADNIK i (1 : N) vezu JE
ˇ
SEF ZA prikazujemo jednom relacijom:
SURADNIK ( ID BR, ID BR
ˇ
SEFA, PREZIME IME, . . . ) .
Ovo ne´ce uzrokovati mnogo praznih vrijednosti atributa, budu´ci da ve´cina suradnika ima ˇsefa. Tip
entiteta DIO PROIZVODA i (N : M) vezu SADR
ˇ
ZI moramo prikazati pomo´cu dvije relacije:
DIO PROIZVODA ( BR DIJELA, IME DIJELA, OPIS, . . . ) ,
SADR
ˇ
ZI ( BR DIJELA SLO
ˇ
ZENOG, BR DIJELA JEDNOSTAVNOG, KOLI
ˇ
CINA ) .
Dodali smo i atribut KOLI
ˇ
CINA koji kaˇze koliko jednostavnih dijelova ulazi u jedan sloˇzeni.
Pretvorba pod-tipova. Pod-tip se prikazuje posebnom relacijom koja sadrˇzi primarne atribute
nadredenog tipa i atribute specifiˇcne za taj pod-tip. Na primjer hijerarhija tipova sa Slike 2.3 prikazuje
se sljede´cim relacijama.
OSOBA ( JMBG, . . . atributi zajedniˇcki za sve tipove osoba . . . ) ,
STUDENT ( JMBG, . . . atributi specifiˇcni za studente . . . ) ,
NASTAVNIK ( JMBG, . . . atributi specifiˇcni za nastavnike . . . ) ,
PROFESOR ( JMBG, . . . atributi specifiˇcni za profesore . . . ) .
Veza JE uspostavlja se na osnovu pojavljivanja istog JMBG u raznim relacijama.
Pretvorba ternarnih veza. Ternarna veza prikazuje se posebnom relacijom, koja sadrˇzi primarne
atribute svih triju tipova entiteta zajedno s eventualnim atributima veze. Za primjer sa Slike 2.4
imamo:
KOMPANIJA ( IME KOMPANIJE, . . . ) ,
PROIZVOD ( IME PROIZVODA, . . . ) ,
ZEMLJA ( IME ZEMLJE, . . . ) ,
IZVOZI ( IME KOMPANIJE, IME PROIZVODA, IME ZEMLJE ) .
ˇ
Cinjenica da se jedan proizvod jedne kompanije izvozi u jednu zemlju prikazana je jednom n-torkom
u relaciji IZVOZI . Kod ternarnih veza ˇcija funkcionalnost nije (M : N : P) broj primarnih atributa je
manji.
2.2.3 Usporedba relacijskog modela s mreˇznim i hijerarhijskim
Mreˇzni i hijerarhijski model su priliˇcno sliˇcni. Ustvari, hijerarhijski model moˇzemo smatrati specijalnom
vrstom mreˇznog. S druge strane, relacijski model se po svom pristupu bitno razlikuje od ostala dva.
Osnovna razlika je u naˇcinu prikazivanja veza medu entitetima, te naˇcinu koriˇstenja tih veza.
16 2. MODELIRANJE PODATAKA
• U mreˇznom ili hijerarhijskom modelu mogu´ce je izravno prikazati vezu. Doduˇse, postoje ogra-
niˇcenja na funkcionalnost veze, te na konfiguraciju svih veza u shemi. Veza se “materijalizira”
pomo´cu pointera, tj. u jednom zapisu piˇse adresa drugog (vezanog) zapisa. Mreˇzni odnosno
hijerarhijski DML omogu´cuje samo jednostavne operacije s jednim zapisom (upis, promjena,
brisanje, ˇcitanje), te “manevriranje” kroz shemu putem veza (dohvat prvog zapisa, koji je u
zadanoj vezi sa zadanimzapisom, dohvat idu´ceg zapisa, . . . ). Ovakav pristup ima svoje prednosti i
mane. Prednost je da je rad s bazom u tehniˇckom pogledu brz i efikasan. Mana je da korisnik moˇze
upotrijebiti samo one veze koje su predvidene shemom pa su u skladu s time i materijalizirane.
• U relacijskom modelu veze su samo implicitno naznaˇcene time ˇsto se isti ili sliˇcan atribut po-
javljuje u viˇse relacija. Veza nije materijalizirana, ve´c se dinamiˇcki uspostavlja za vrijeme rada
s podacima, usporedbom vrijednosti atributa u n-torkama raznih relacija. Relacijski DML, osim
jednostavnih operacija s jednom relacijom, mora omogu´citi slobodno kombiniranje podataka iz
raznih relacija. I ovaj pristup ima svoje prednosti i mane. Mana je da se veza svaki put mora
iznova uspostavljati; potrebno je pretraˇzivanje podataka, a to troˇsi vrijeme. Prednost je da ko-
risnik moˇze uspostaviti i one veze koje nisu bile predvidene u fazi modeliranja podataka.
ˇ
Stoviˇse,
kao kriterij za povezivanje, osim jednakosti za vrijednost atributa, mogu posluˇziti i razni drugi
(sloˇzeniji) kriteriji. To joˇs viˇse pove´cava fleksibilnost koriˇstenja baze.
Iz upravo reˇcenog vidi se da je u relacijskom modelu teˇziˇste baˇceno na dinamiˇcki aspekt (manje
pohranjivanja a viˇse manipuliranja). Zato upotrebljivost relacijskog DBMS bitno ovisi o izraˇzajnim
mogu´cnostima njegovog jezika za rad s podacima. Poˇzeljno je takoder da taj jezik bude u ˇsto ve´coj
mjeri neproceduralan i razumljiv neposrednim korisnicima. U Poglavlju 3 upoznat ´cemo neke relacijske
jezike. Njih treba smatrati sastavnim dijelom relacijskog modela.
2.3 Normalizacija relacijske sheme
Relacijska shema, dobivena iz ER-sheme na osnovu prethodnih uputa, moˇze sadrˇzavati nedoreˇcenosti
koje treba otkloniti prije implementacije. Proces daljnjeg dotjerivanja sheme zove se normalizacija.
Teorija normalizacije zasnovana je na pojmu normalnih formi. Relacije dobivene u skladu s pot-
poglavljem 2.2 morale bi u najmanju ruku biti u prvoj normalnoj formi (1NF). Naime, relacija je u
1NF ako je vrijednost svakog atributa jednostruka i nedjeljiva - to svojstvo ve´c je bilo ukljuˇceno u naˇsu
definiciju relacije. U svojim radovima (1970-1974. godina) E.F. Codd je najprije definirao drugu i
tre´cu normalnu formu (2NF, 3NF), a zatim i poboljˇsanu varijantu 3NF koja se zove Boyce-Codd-
ova normalna forma (BCNF). R. Fagin je 1977. i 1979. uveo ˇcetvrtu i petu normalnu formu
(4NF, 5NF). U praksi je lako nai´ci na relacije koje odstupaju od 2NF, 3NF, BCNF, no vrlo rijetko
se susre´cu relacije u BCNF koje nisu u 4NF i 5NF. Zato su “viˇse” normalne forme prvenstveno od
teorijskog znaˇcaja.
Teorija normalizacije nije niˇsta drugo nego formalizacija nekih intuitivno prihvatljivih principa o
“zdravom” oblikovanju sheme. Ukoliko ve´c na poˇcetku dobro uoˇcimo sve potrebne entitete, atribute i
veze, tada nam nikakva daljnja normalizacija ne´ce biti potrebna. No ako je polazna relacijska shema
bila loˇse oblikovana, tada ´ce postupak normalizacije ispraviti te greˇske.
2.3.1 Funkcionalna ovisnost
Za zadanu relaciju R, atribut B od R je funkcionalno ovisan o atributu A od R (oznaka: A → B)
ako vrijednost od A jednoznaˇcno odreduje vrijednost od B. Dakle ako u isto vrijeme postoje u R
dvije n-torke s jednakom vrijednoˇs´cu A, tada te n-torke moraju imati jednaku vrijednost B. Analogna
definicija primjenjuje se i za sluˇcaj kad su A i B sloˇzeni atributi (dakle skupovi atributa).
Kao primjer, promotrimo sljede´cu (loˇse oblikovanu) relaciju:
IZVJE
ˇ
STAJ ( BR INDEKSA, BR KOLEGIJA, NASLOV KOLEGIJA, IME NASTAVNIKA,
BR SOBE NASTAVNIKA, OCJENA ) .
Pretpostavimo da svaki kolegij ima jednog nastavnika, a svaki nastavnik jednu sobu. Navodimo neke
od funkcionalnih ovisnosti:
(BR INDEKSA, BR KOLEGIJA) → OCJENA ,
BR KOLEGIJA → NASLOV KOLEGIJA ,
2.3. NORMALIZACIJA RELACIJSKE SHEME 17
BR KOLEGIJA → IME NASTAVNIKA ,
BR KOLEGIJA → BR SOBE NASTAVNIKA ,
IME NASTAVNIKA → BR SOBE NASTAVNIKA .
Za zadanu relaciju R, atribut B od R je potpuno funkcionalno ovisan o (sloˇzenom) atributu
A od R ako vrijedi: B je funkcionalno ovisan o A, no B nije funkcionalno ovisan ni o jednom pravom
podskupu od A.
Svaki atribut relacije je funkcionalno ovisan o kljuˇcu, no ta ovisnost ne mora biti potpuna. Na prim-
jer OCJENA je potpuno funkcionalno ovisna o primarnom kljuˇcu (BR INDEKSA, BR KOLEGIJA). S
druge strane, NASLOV KOLEGIJA, IME NASTAVNIKA i BR SOBE NASTAVNIKA su parcijalno
ovisni o kljuˇcu, budu´ci da su ovisni samo o BR KOLEGIJA, a ne i o BR INDEKSA.
Za BR SOBE NASTAVNIKA se kaˇze da je tranzitivno ovisan o BR KOLEGIJA, budu´ci da je
ovisan o IME NASTAVNIKA, koji je opet ovisan o BR KOLEGIJA.
Parcijalne i tranzitivne ovisnosti mogu uzrokovati probleme kod manipuliranja s podacima, pa ih
je poˇzeljno ukloniti.
2.3.2 Druga normalna forma
Relacija je u drugoj normalnoj formi (2NF) ako je u 1NF i ako je svaki ne-primarni atribut potpuno
funkcionalno ovisan o primarnom kljuˇcu.
Malo prije definirana relacija IZVJE
ˇ
STAJ nije u 2NF, i to dovodi do anomalija:
• Ako u bazu ˇzelimo unijeti podatke o novom kolegiju, to ne moˇzemo uˇciniti sve dok bar jedan
student ne upiˇse taj kolegij (naime ne smijemo imati praznu vrijednost primarnog atributa
BR INDEKSA). Sliˇcno, ako ˇzelimo unijeti podatke o novom nastavniku i njegovoj sobi, to ne
moˇzemo uˇciniti dok nastavnika ne zaduˇzimo s bar jednim kolegijem i dok bar jedan student ne
upiˇse taj kolegij.
• Ako ˇzelimo promijeniti naslov kolegija 361 iz “Linearna algebra” u “Vektorski prostori”, tada
moramo na´ci sve n-torke koje sadrˇze tu vrijednost za BR KOLEGIJA, te promijeniti vrijednost
za NASLOV KOLEGIJA u svim takvim n-torkama. Bit ´ce onoliko promjena koliko ima studenata
koji su upisali kolegij 361. Ako zaboravimo izvrˇsiti neku od promjena, imat ´cemo kontradiktorne
podatke.
• Pretpostavimo da svi studenti koji su upisali kolegij 361 odustanu od tog kolegija. Ako shodno
tome pobriˇsemo odgovaraju´ce n-torke, iz baze ´ce nestati svi podaci o kolegiju 361.
Ove anomalije rjeˇsavamo svodenjem relacije u 2NF. Polaznu relaciju razbijamo u dvije, tako da iz
stare relacije prebacimo u novu sve one atribute koji su parcijalno ovisni o kljuˇcu:
IZVJE
ˇ
STAJ ( BR INDEKSA, BR KOLEGIJA, OCJENA ) ,
KOLEGIJ ( BR KOLEGIJA, NASLOV KOLEGIJA, IME NASTAVNIKA,
BR SOBE NASTAVNIKA ) .
Obje relacije su sada u 2NF. No relacija KOLEGIJ zahtijeva daljnju normalizaciju; naime u njoj joˇs
uvijek postoji tzv. tranzitivna ovisnost, gdje srednji atribut nije kandidat za kljuˇc:
BR KOLEGIJA → IME NASTAVNIKA → BR SOBE NASTAVNIKA .
2.3.3 Tre´ca normalna forma
Relacija je u tre´coj normalnoj formi (3NF) ako je u 2NF i ako ne sadrˇzi tranzitivne ovisnosti.
Preciznije, relacija R je u 3NF ako za svaku funkcionalnu ovisnost X → A u R, takvu da A nije u X,
vrijedi: X sadrˇzi kljuˇc za R ili je A primarni atribut.
Prije navedena relacija KOLEGIJ nije u 3NF jer imamo ovisnost
IME NASTAVNIKA → BR SOBE NASTAVNIKA ,
i pritom IME NASTAVNIKA nije kljuˇc, a BR SOBE NASTAVNIKA nije primarni atribut. Ova tranz-
itivna ovisnost moˇze dovesti do anomalija:
18 2. MODELIRANJE PODATAKA
• Ne moˇzemo unijeti podatke o novom nastavniku i njegovoj sobi, sve dok ga nismo zaduˇzili s
kolegijem.
• Da bi promijenili broj sobe nastavnika, moramo izvrˇsiti promjenu u svakoj n-torki koja odgovara
nekom kolegiju kojeg predaje taj nastavnik.
• Ako nastavnik (privremeno) ne predaje ni jedan kolegij, tada iz baze nestaju svi podaci o tom
nastavniku i njegovoj sobi.
Da bi relaciju KOLEGIJ prebacili u 3NF, razbijamo je u dvije, i time prekidamo tranzitivnu
ovisnost. Konaˇcna relacijska shema koja zamjenjuje polaznu relaciju IZVJE
ˇ
STAJ izgleda ovako:
IZVJE
ˇ
STAJ ( BR INDEKSA, BR KOLEGIJA, OCJENA ) ,
KOLEGIJ ( BR KOLEGIJA, NASLOV KOLEGIJA, IME NASTAVNIKA ) ,
NASTAVNIK ( IME NASTAVNIKA, BR SOBE NASTAVNIKA ) .
Relacije su sada do kraja normalizirane. Primijetimo da bi konaˇcnu shemu odmah dobili da smo u fazi
modeliranja entiteta postupili ispravno, te studente, kolegije i nastavnike odmah prikazali posebnim
tipovima entiteta.
2.3.4 Boyce-Codd-ova normalna forma
Determinanta je atribut (ili kombinacija atributa) o kojem je neki drugi atribut potpuno funkcionalno
ovisan.
Relacija je u Boyce-Codd-ovoj normalnoj formi (BCNF) ako je svaka njezina determinanta
ujedno i kandidat za kljuˇc.
Oˇcito je relacija koja je u BCNF takoder i u 2NF i 3NF. No postoje relacije koje su u 3NF, no nisu
u BCNF. Primjer za to moˇzemo konstruirati tako da gledamo relaciju u kojoj postoje dva kandidata
za kljuˇc, oba kljuˇca su sloˇzena, i preklapaju se u bar jednom atributu.
Na primjer neka na fakultetu jedan kolegij predaje viˇse nastavnika, ali svaki nastavnik predaje samo
jedan kolegij. Svaki student upisuje viˇse kolegija, no ima samo jednog nastavnika za zadani kolegij.
Situacija se moˇze opisati relacijom:
UPISAO ( BR INDEKSA, IME NASTAVNIKA, BR KOLEGIJA ) .
Relacija nije ni u 2NF, jer postoji parcijalna ovisnost:
IME NASTAVNIKA → BR KOLEGIJA.
No mi moˇzemo drukˇcije izabrati primarni kljuˇc:
UPISAO ( BR INDEKSA, BR KOLEGIJA, IME NASTAVNIKA ) .
Sad je relacija u 3NF, no ne i u BCNF jer postoji ovisnost:
IME NASTAVNIKA → BR KOLEGIJA
i pritom IME NASTAVNIKA nije kandidat za kljuˇc.
Zbog odstupanja od BCNF nastaju sliˇcne anomalije kao kod odstupanja od 3NF. Ne moˇzemo
evidentirati ˇcinjenicu da zadani nastavnik predaje zadani kolegij, sve dok bar jedan student ne upiˇse
taj kolegij kod tog nastavnika. Takoder, veza nastavnika i kolegija je zapisana s velikomredundancijom,
onoliko puta koliko ima studenata, ˇsto oteˇzava aˇzuriranje. Ako svi studenti odustanu, briˇse se evidencija
da zadani nastavnik predaje zadani kolegij.
Rjeˇsenje problema je, kao i prije, razbijanje relacije na dvije. Prekida se nepoˇzeljna funkcionalna
ovisnost.
KLASA ( BR INDEKSA, IME NASTAVNIKA ) ,
PREDAJE ( IME NASTAVNIKA, BR KOLEGIJA ) .
Sad su obje relacije u BCNF.
Problemi s relacijom UPISAO izbjegli bi se da smo ve´c u fazi modeliranja entiteta i veza uoˇcili da
zapravo imamo posla s dvije nezavisne binarne veze: (N : M) veza izmedu STUDENT i NASTAVNIK,
te (1 : N) veza izmedu KOLEGIJ i NASTAVNIK. Ternarna veza je tada suviˇsna.
2.3. NORMALIZACIJA RELACIJSKE SHEME 19
2.3.5 Viˇseznaˇcna ovisnost i ˇcetvrta normalna forma
ˇ
Cetvrtu normalnu formu najlakˇse je opisati pomo´cu primjera. Promatrajmo relaciju koja prikazuje
vezu izmedu kompanija, proizvoda i zemalja:
IZVOZI ( KOMPANIJA, PROIZVOD, ZEMLJA ) .
Jedna n-torka oznaˇcava da zadana kompanija zadani proizvod izvozi u zadanu zemlju. Relacija moˇze u
jednom trenutku izgledati kao na Tabelarnom prikazu 2.2. Lagano je provjeriti da je relacija u BCNF.
IZVOZI
KOMPANIJA PROIZVOD ZEMLJA
IBM Desktop Francuska
IBM Desktop Italija
IBM Desktop Velika Britanija
IBM Mainframe Francuska
IBM Mainframe Italija
IBM Mainframe Velika Britanija
HP Desktop Francuska
HP Desktop
ˇ
Spanjolska
HP Desktop Irska
HP Server Francuska
HP Server
ˇ
Spanjolska
HP Server Irska
Fujitsu Mainframe Italija
Fujitsu Mainframe Francuska
Tabelarni prikaz 2.2: Relacija koja nije u ˇcetvrtoj normalnoj formi.
U nastavku uzimamo da vrijedi pravilo: ˇcim kompanija izvozi u neku zemlju, ona odmah izvozi sve
svoje proizvode u tu zemlju. Tada relacija oˇcito sadrˇzi veliku dozu redundancije. Na primjer, da bi
dodali novi proizvod IBM-a, moramo upisati n-torku za svaku zemlju u koju IBM izvozi. Sliˇcno, ako
HP poˇcne izvoziti u Kinu, morat ´ce se ubaciti posebna n-torka za svaki njegov proizvod.
Redundancija ´ce se eliminirati ako zamijenimo polaznu relaciju IZVOZI s dvije manje relacije RADI
i PRODAJE:
RADI ( KOMPANIJA, PROIZVOD ) ,
PRODAJE ( KOMPANIJA, ZEMLJA ) .
Podacima iz prethodnog Tabelarnog prikaza 2.2 tada odgovaraju podaci iz Tabelarnog prikaza 2.3.
RADI
KOMPANIJA PROIZVOD
IBM Desktop
IBM Mainframe
HP Desktop
HP Server
Fujitsu Mainframe
PRODAJE
KOMPANIJA ZEMLJA
IBM Francuska
IBM Italija
IBM Velika Britanija
HP Francuska
HP
ˇ
Spanjolska
HP Irska
Fujitsu Italija
Fujitsu Francuska
Tabelarni prikaz 2.3: Svodenje na ˇcetvrtu normalnu formu.
Dosadaˇsnja pravila normalizacije nam ne pomaˇzu da eliminiramo redundanciju u relaciji IZVOZI .
To je zato ˇsto redundancija nije bila uzrokovana funkcionalnim ovisnostima, ve´c tzv. viˇseznaˇcnim
ovisnostima:
20 2. MODELIRANJE PODATAKA
KOMPANIJA →→ PROIZVOD ,
KOMPANIJA →→ ZEMLJA .
Zadana je relacija R(A, B, C). Viˇseznaˇcna ovisnost A →→ B vrijedi ako: skup B-vrijednosti
koje se u R pojavljuju uz zadani par (A-vrijednost, C-vrijednost) ovisi samo o A-vrijednosti, a ne i o
C-vrijednosti. Ista definicija primjenjuje se i kad su A, B i C sloˇzeni atributi (dakle skupovi atributa).
U gornjem primjeru, skup zemalja u koje zadana kompanija izvozi zadani proizvod ovisi samo o
kompaniji a ne i o proizvodu. Sliˇcno, skup proizvoda koje zadana kompanija izvozi u zadanu zemlju
ovisi samo o kompaniji a ne o zemlji.
Relacija R je u ˇcetvrtoj normalnoj formi (4NF) ako vrijedi: kad god postoji viˇseznaˇcna ovisnost
u R, na primjer A →→ B, tada su svi atributi od R funkcionalno ovisni o A.
Ekvivalentno, R je u 4NF ako je u BCNF i sve viˇseznaˇcne ovisnosti u R su zapravo funkcionalne
ovisnosti.
U naˇsoj relaciji IZVOZI , ni jedna od uoˇcenih viˇseznaˇcnih ovisnosti nije funkcionalna ovisnost.
Znaˇci, IZVOZI nije u 4NF i zato je treba rastaviti na RADI i PRODAJE (koje jesu u 4NF).
Odstupanje od 4NF opet moˇzemo tumaˇciti kao greˇsku u modeliranju entiteta i veza. Promatrana
relacija IZVOZI nastala je zbog pokuˇsaja da se odnos triju tipova entiteta KOMPANIJA, PROIZVOD,
ZEMLJA tretira kao ternarna veza. Zapravo se ovdje radi o dvije nezavisne binarne veze.
Postoje, naravno, i prave ternarne veze. Na primjer ako skup proizvoda koje zadana kompanija
izvozi varira od zemlje do zemlje, tada prije uoˇcene viˇseznaˇcne ovisnosti ne vrijede, relacija IZVOZI je
u 4NF i ne moˇzemo je rastaviti na dvije manje relacije.
2.3.6 Razlozi zbog kojih se moˇze odustati od normalizacije
Za ve´cinu praktiˇcnih primjera dovoljno je relacije normalizirati do 3NF. Koji put je potrebno neku
relaciju i dalje normalizirati do BCNF ili 4NF. Peta normalna forma, koja se takoder navodi u literaturi,
nije od praktiˇcnog znaˇcaja.
Postoje razlozi zbog kojih iznimno moˇzemo odustati od pune normalizacije. Navesti ´cemo dva takva
razloga.
Sloˇzeni atribut . Deˇsava se da nekoliko atributa u relaciji ˇcine cjelinu koja se u aplikacijama nikad
ne rastavlja na sastavne dijelove. Na primjer, promatrajmo relaciju
KUPAC ( PREZIME IME, PO
ˇ
STANSKI BROJ, GRAD, ULICA ) .
Strogo govore´ci, GRAD je funkcionalno ovisan o PO
ˇ
STANSKI BROJ, pa relacija nije u 3NF. No
mi znamo da PO
ˇ
STANSKI BROJ, GRAD i ULICA ˇcine cjelinu koja se zove adresa. Budu´ci da
se podaci iz adrese koriste i aˇzuriraju “u paketu”, ne moˇze do´ci do prije spominjanih anomalija.
Nije preporuˇcljivo razbijati ovu relaciju na dvije.
Efikasno ˇcitanje podataka . Normalizacijom se velike relacije razbijaju na mnogo manjih. Kod
ˇcitanja je ˇcesto potrebno podatke iz malih relacija ponovo sastaviti u ve´ce n-torke. Uspostavljanje
veza medu podacima u manjim relacijama traje znatno dulje nego ˇcitanje podataka koji su ve´c
povezani i upisani u jednu veliku relaciju.
Projektant baze podataka treba procijeniti kada treba provesti normalizaciju do kraja a kada ne.
Za tu procjenu je vaˇzno razumijevanje znaˇcenja podataka i naˇcina kako ´ce se oni koristiti.
3
JEZICI ZA RELACIJSKE BAZE
PODATAKA
3.1 Relacijska algebra
Relacijsku algebru uveo je E.F. Codd u svojim radovima iz 70-tih godina 20. stolje´ca. Rijeˇc je o
teorijskoj (matematiˇckoj) notaciji, a ne o praktiˇcnom jeziku kojeg bi ljudi zaista neposredno koristili.
Zato niti ne postoji standardna sintaksa.
Relacijska algebra se svodi na izvrednjavanje algebarskih izraza, gradenih od relacija te unarnih i bi-
narnih operatora (ˇciji operandi su relacija a rezultat je opet relacija). Svaki algebarski izraz predstavlja
jedan upit (pretraˇzivanje).
U ovom i idu´cin poglavljima, kao primjer ´ce sluˇziti pojednostavnjena (engleska) verzija naˇse baze
o fakultetu:
STUDENT ( SNO, SNAME, LEVEL ) ,
COURSE ( CNO, TITLE, LNAME ) ,
REPORT ( SNO, CNO, MARK ) ,
LECTURER ( LNAME, ROOMNO ) .
Uzimamo da relacije sadrˇze n-torke koje se vide u Tabelarnom prikazu 3.1.
STUDENT
SNO SNAME LEVEL
876543 Jones 2
864532 Burns 1
856434 Cairns 3
876421 Hughes 2
COURSE
CNO TITLE LNAME
216 Database Systems Black
312 Software Engineering Welsh
251 Numerical Analysis Quinn
121 Compilers Holt
REPORT
SNO CNO MARK
876543 216 82
864532 216 75
864532 312 71
856434 121 49
876421 312 39
876543 251 70
864532 251 69
864532 121 78
LECTURER
LNAME ROOMNO
Black 1017
Welsh 1024
Holt 2014
Quinn 1010
Tabelarni prikaz 3.1: Demo-baza o fakultetu.
Relacija STUDENT popisuje studente, COURSE nabraja kolegije, a LECTURER sadrˇzi podatke
o nastavnicima. Student je jednoznaˇcno odreden svojim brojem iz indeksa SNO, kolegij je jednoznaˇcno
21
22 3. JEZICI ZA RELACIJSKE BAZE PODATAKA
odreden svojomˇsifrom CNO, a nastavnici se razlikuju po svojim imenima LNAME. Za svakog studenta
pamtimo njegovo ime SNAME i godinu studija LEVEL. Za kolegij se pamti njegov naslov TITLE i
ime (jednog) nastavnika koji ga predaje LNAME. Za svakog nastavnika poznat nam je broj njegove
sobe ROOMNO. Relacija REPORT biljeˇzi koji je student upisao koji kolegij i koju ocjenu MARK je
dobio.
3.1.1 Skupovni operatori
Relacije su ustvari skupovi n-torki. Zato na njih moˇzemo primjenjivati uobiˇcajene skupovne operatore.
Neka R i S oznaˇcavaju relacije. Tada je:
R union S . . . skup n-torki koje su u R ili u S (ili u obje relacije).
R intersect S . . . skup n-torki koje su u R i takoder u S.
R minus S . . . skup n-torki koje su u R no nisu u S.
Da bi se operatori mogli primijeniti, relacije R i S moraju biti “kompatibilne”, to jest moraju imati
isti stupanj i iste atribute (ista imena i tipove). Primijetimo da uvijek vrijedi:
R intersect S = R minus (R minus S) .
Znaˇci, intersect nije nuˇzan.
Za primjer, promatramo relaciju NEW STUDENT, gradenu kao STUDENT, u kojoj se nalaze n-
torke popisane u Tabelarnom prikazu 3.2. Tada primjenom skupovnih operatora dobivamo rezultate
iz Tabelarnog prikaza 3.3.
NEW STUDENT
SNO SNAME LEVEL
876342 Smith 3
865698 Turner 2
875923 Murphy 2
856434 Cairns 3
871290 Noble 1
Tabelarni prikaz 3.2: Relacija kompatibilna sa STUDENT.
STUDENT union NEW STUDENT
SNO SNAME LEVEL
876543 Jones 2
864532 Burns 1
856434 Cairns 3
876421 Hughes 2
876342 Smith 3
865698 Turner 2
875923 Murphy 2
871290 Noble 1
STUDENT intersect NEW STUDENT
SNO SNAME LEVEL
856434 Cairns 3
STUDENT minus NEW STUDENT
SNO SNAME LEVEL
876543 Jones 2
864532 Burns 1
876421 Hughes 2
Tabelarni prikaz 3.3: Rezultati skupovnih operacija.
3.1. RELACIJSKA ALGEBRA 23
3.1.2 Selekcija
Selekcija je unarni operator koji izvlaˇci iz relacije one n-torke koje zadovoljavaju zadani Booleovski
uvjet. Selekciju na relaciji R u skladu s Booleovskim uvjetom B oznaˇcavamo s R where B. Uvjet B
je formula koja se sastoji od:
• operanada koji su ili konstante ili atributi,
• operatora za usporedivanje =, <, >, ≤, ≥, =,
• logiˇckih operatora and, or, not.
Navest ´cemo nekoliko primjera od kojih svaki sadrˇzi jedan upit sa selekcijom i odgovaraju´ci izraz u
relacijskoj algebri. Izraˇcunate vrijednosti izraza (odgovori na upite) vide se u Tabelarnom prikazu 3.4.
Upit 1: Pronadi sve studente na stupnju (godini) 1.
RESULT1 := STUDENT where LEVEL = 1 .
Upit 2: Pronadi sve kolegije s naslovom ‘Database Systems’.
RESULT2 := COURSE where TITLE = ‘Database Systems’ .
Upit 3: Pronadi sve studente koji su iz kolegija 216 dobili ocjenu ve´cu od 70.
RESULT3 := REPORT where ((CNO=216) and (MARK>70)) .
RESULT1
SNO SNAME LEVEL
864532 Burns 1
RESULT2
CNO TITLE LNAME
216 Database Systems Black
RESULT3
SNO CNO MARK
876543 216 82
864532 216 75
Tabelarni prikaz 3.4: Rezultati selekcije.
3.1.3 Projekcija
Projekcija je unarni operator koji iz relacije izvlaˇci zadane atribute, s time da se u rezultiraju´coj relaciji
eliminiraju n-torke duplikati. Projekciju relacije R na njene atribute A
1
, A
2
, . . . , A
m
oznaˇcavat ´cemo
s R[A
1
, A
2
, . . . , A
m
]. Smatrat ´cemo da projekcija ima viˇsi prioritet od ostalih operacija.
Navest ´cemo dva primjera koji se sastoje od upita s projekcijom i odgovaraju´ceg izraza u relacijskoj
algebri. Izraˇcunate vrijednosti izraza (odgovori na upite) vide se u Tabelarnom prikazu 3.5.
Upit 1: Pronadi brojeve soba od svih nastavnika.
RESULT1 := LECTURER[ROOMNO] .
Upit 2: Pronadi ime nastavnika koji predaje kolegij 312.
RESULT2 := ( COURSE where CNO = 312 )[LNAME] .
24 3. JEZICI ZA RELACIJSKE BAZE PODATAKA
RESULT1
ROOMNO
1017
1024
2014
1010
RESULT2
LNAME
Welsh
Tabelarni prikaz 3.5: Rezultati projekcije.
3.1.4 Kartezijev produkt
Neka su R i S relacije stupnja n
1
odnosno n
2
. Tada algebarski izraz R times S daje Kartezijev produkt
od R i S, dakle skup svih (n
1
+ n
2
)-torki ˇcijih prvih n
1
komponenti ˇcine n
1
-torku u R, a zadnjih n
2
komponenti ˇcine n
2
-torku u S.
Atribut u R times S ima isto ime kao odgovaraju´ci atribut u R odnosno S, s time da se po potrebi
to ime proˇsiruje imenom polazne relacije (sliˇcno kao za komponentu zapisa u C-u).
Kao primjer koriˇstenja Kartezijevog produkta, ispisat ´cemo za svakog studenta sve kolegije koje on
nije upisao:
ALL COMB := STUDENT[SNO] times COURSE[CNO] ,
DO NOT TAKE := ALL COMB minus REPORT[SNO, CNO] .
Drugi primjer pronalazi sve parove studenata koji su na istom stupnju (godini). Za to nam je potrebno
napraviti Kartezijev produkt relacije STUDENT sa samom sobom. Da ne bi doˇslo do pometnje s
imenima atributa. specijalnim operatorom aliases uvodimo “pseudonim” (drugo ime, nadimak) za
relaciju STUDENT:
TEMP aliases STUDENT ,
PAIRS := ( (TEMP times STUDENT)
where ( (TEMP.LEVEL = STUDENT.LEVEL)
and (TEMP.SNO < STUDENT.SNO)) )
[TEMP.SNAME, STUDENT.SNAME] .
Rezultati za oba upita vide se u Tabelarnom prikazu 3.6.
DO NOT TAKE
SNO CNO
876543 312
876543 121
856434 216
856434 312
856434 251
876421 216
876421 251
876421 121
PAIRS
TEMP.SNAME STUDENT.SNAME
Hughes Jones
Tabelarni prikaz 3.6: Rezultati primjene Kartezijevog produkta.
3.1.5 Prirodni spoj
Prirodni spoj (natural join) je binarni operator primjenjiv na dvije relacije R i S koje imaju bar jedan
zajedniˇcki atribut. R join S sastoji se od svih n-torki dobivenih spajanjem jedne n-torke iz R s jednom
n-torkom iz S koja ima iste vrijednosti zajedniˇckih atributa. U rezultiraju´coj relaciji zajedniˇcki atribut
se pojavljuje samo jednom.
Primjer za prirodni spoj vidi se u Tabelarnom prikazu 3.7. Pretpostavlja se da su zajedniˇcki atributi
dviju relacija toˇcno oni koji imaju ista imena.
Prirodni spoj omogu´cuje nam da u naˇsoj fakultetskoj bazi podataka odgovorimo na sloˇzenije upite
koji zahtijevaju uspostavljanje veza izmedu podataka u raznim tablicama.
3.1. RELACIJSKA ALGEBRA 25
R
A B C
a
1
b
1
c
1
a
2
b
1
c
1
a
3
b
2
c
2
a
4
b
2
c
3
S
B C D
b
1
c
1
d
1
b
1
c
1
d
2
b
2
c
3
d
3
R join S
A B C D
a
1
b
1
c
1
d
1
a
1
b
1
c
1
d
2
a
2
b
1
c
1
d
1
a
2
b
1
c
1
d
2
a
4
b
2
c
3
d
3
Tabelarni prikaz 3.7: Primjer prirodnog spoja.
Upit 1: Pronadi imena svih studenata koji su upisali kolegij 251.
RESULT1 := ( (REPORT where CNO = 251) join STUDENT ) [SNAME] .
Upit 2: Pronadi broj sobe nastavnika koji predaje kolegij 351.
RESULT2 := ( (COURSE where CNO = 351) join LECTURER ) [ROOMNO] .
Upit 3: Pronadi imena nastavnika koji predaju kolegije koje je upisao bar jedan student na stupnju
(godini) 2.
RESULT3 := ( ( (STUDENT where LEVEL=2) join REPORT ) join COURSE ) [LNAME] .
U Tabelarnom prikazu 3.8 nalazi se detaljnije izvrednjavanje Upita 3.
STUDENT where LEVEL = 2
SNO SNAME LEVEL
876543 Jones 2
876421 Hughes 2
(STUDENT where LEVEL=2) join REPORT
SNO SNAME LEVEL CNO MARK
876543 Jones 2 216 82
876543 Jones 2 251 70
876421 Hughes 2 312 39
( (STUDENT where LEVEL=2) join REPORT ) join COURSE
SNO SNAME LEVEL CNO MARK TITLE LNAME
876543 Jones 2 216 82 Database Systems Black
876543 Jones 2 251 70 Numerical Analysis Quinn
876421 Hughes 2 312 39 Software Engineering Welsh
RESULT3
LNAME
Black
Quinn
Welsh
Tabelarni prikaz 3.8: Izvrednjavanje Upita 3 s prirodnim spojem.
Prirodni spoj uvijek se moˇze izraziti preko ostalih operatora. Na primjer, za relacije R(A, B, C) i
S(C, D) vrijedi:
R join S = ( (R times S) where R.C = S.C ) [A,B,C,D].
26 3. JEZICI ZA RELACIJSKE BAZE PODATAKA
3.1.6 Theta-spoj
Theta-spoj relacija R i S, pisano R join(Aθ B) S, je skup onih n-torki Kartezijevog produkta R sa S
za koje je predikat R.A θ S.B istina. Simbol θ predstavlja jedan od operatora za usporedbu (=, >, <
, =, ≤, ≥). Theta-spoj se uvijek moˇze izraziti pomo´cu Kartezijevog produkta i selekcije. Prirodni spoj
se moˇze smatrati specijalnim sluˇcajem theta-spoja.
3.1.7 Dijeljenje
Neka je R relacija stupnja n, a S relacija stupnja m, i neka se svi atributi od S pojavljuju i u R.
Rezultat dijeljenja R sa S, oznakom R divideby S, je skup svih (n − m)-torki 'x` takvih da se n-
torke 'x, y` pojavljuju u R za sve m-torke 'y` u S. Ovdje x i y predstavljaju grupu od jedne ili viˇse
vrijednosti atributa.
U Tabelarnom prikazu 3.9 nalazi se najprije jedan apstraktni primjer dijeljenja. Dalje slijede prim-
jeri s naˇsom fakultetskom bazom podataka.
R1
SNO CNO
s
1
c
1
s
1
c
2
s
1
c
3
s
2
c
1
s
2
c
2
s
3
c
1
s
4
c
4
R2
CNO
c
1
R3
CNO
c
1
c
2
c
3
R1 divideby R2
SNO
s
1
s
2
s
3
R1 divideby R3
SNO
s
1
Tabelarni prikaz 3.9: Apstraktni primjer djeljenja.
Upit 1: Pronadi imena studenata koji su upisali sve kolegije.
RESULT1 := ( (REPORT[SNO,CNO] divideby COURSE[CNO]) join STUDENT ) [SNAME].
Za naˇse konkretne podatke, jedini student koji zadovoljava upit je Burns.
Upit 2: Pronadi brojeve onih studenata koji su upisali barem one kolegije koje je upisao student s
brojem 856434 (i moˇzda joˇs neke kolegije).
RESULT2 := REPORT [SNO,CNO] divideby (REPORT where SNO=856434)[CNO] .
Kao odgovor dobivamo brojeve studenata 856434, 864532.
Operator dijeljenja predstavlja naˇcin implementiranja univerzalne kvantifikacije ∀ u relacijskoj alge-
bri. Dijeljenje se takoder moˇze izraziti pomo´cu prethodno opisanih operatora. Na primjer, ako imamo
relacije R(A, B, C, D) i S(C, D), tada je:
R divideby S = R[A,B] minus ( (R[A,B] times S) minus R )[A,B] .
3.1.8 Vanjski spoj
Vanjski spoj (outer join) je binarni operator vrlo sliˇcan prirodnom spoju. Primjenjiv je pod istim
uvjetima i daje kao rezultat relaciju s istom gradom (shemom). No sadrˇzaj od R outerjoin S je neˇsto
bogatiji nego sadrˇzaj R join S. Naime, pored svih n-torki iz R join S, relacija R outerjoin S sadrˇzi i
sve “nesparene” (nespojene) n-torke iz R odnosno S (s time da su te nesparene n-torke na odgovaraju´ci
naˇcin proˇsirene null vrijednostima).
3.2. RELACIJSKI RA
ˇ
CUN 27
Dakle za isti primjer R i S kao u Tabelarnom prikazu 3.7, R outerjoinS izgleda kao na Tabelarnom
prikazu 3.10.
R
A B C
a
1
b
1
c
1
a
2
b
1
c
1
a
3
b
2
c
2
a
4
b
2
c
3
S
B C D
b
1
c
1
d
1
b
1
c
1
d
2
b
2
c
3
d
3
R outerjoin S
A B C D
a
1
b
1
c
1
d
1
a
1
b
1
c
1
d
2
a
2
b
1
c
1
d
1
a
2
b
1
c
1
d
2
a
4
b
2
c
3
d
3
a
3
b
2
c
2

Tabelarni prikaz 3.10: Primjer vanjskog spoja.
Vanjski spoj obiˇcno se koristi za traˇzenje podataka koji ne zadovoljavaju neki uvjet. Na primjer:
Upit 1: Pronadi imena studenata koji nisu upisali ni jedan kolegij.
RESULT1 := ( (STUDENT outerjoin REPORT) where (CNO is null) ) [SNAME] .
3.2 Relacijski raˇcun
Relacijski raˇcun takoder je bio predloˇzen od E.F. Codd-a, kao alternativa relacijskoj algebri. Rijeˇc je
o matematiˇckoj notaciji zasnovanoj na predikatnom raˇcunu. Upit se izraˇzava tako da zadamo predikat
kojeg n-torke moraju zadovoljavati.
Postoje dvije vrste relacijskog raˇcuna: raˇcun orijentiran na n-torke (gdje su osnovni objekti n-torke)
i raˇcun orijentiran na domene (gdje su osnovni objekti vrijednosti iz domena za atribute).
3.2.1 Raˇcun orijentiran na n-torke
U izrazima se pojavljuju sljede´ci elementi:
Varijable-n-torke poprimaju vrijednosti iz imenovane relacije. Ako je t varijabla koja “prolazi”
relacijom R, tada t.A oznaˇcava A-komponentu od t, gdje je A atribut od R.
Uvjeti oblika x θ y, gdje je θ operator za usporedivanje (=, <, >, =, ≤, ≥). Bar jedno od x i y mora
biti oblika t.A, a drugo moˇze biti konstanta. Uvjeti takoder mogu biti oblika R(t), ˇsto znaˇci da
je t n-torka u relaciji R.
Dobro oblikovane formule (WFF) gradene od logiˇckih veznika (and, or, not) i kvantifikatora ∃
(postoji) i ∀ (za svako), u skladu sa sljede´cim pravilima:
• Svaki uvjet je WFF.
• Ako su f
1
i f
2
WFF, tada su to i f
1
and f
2
, f
1
or f
2
, not f
1
, i not f
2
.
• Ako je f jedna WFF u kojoj se t pojavljuje kao slobodna varijabla, tada su ∃ t (f) i
∀ t (f) takoder WFF. (Pojava varijable u WFF je vezana ukoliko je ta varijabla uvedena
kvantifikatorom. Inaˇce je slobodna).
• Niˇsta drugo nije WFF.
28 3. JEZICI ZA RELACIJSKE BAZE PODATAKA
Izraz raˇcuna orijentiranog na n-torke je oblika: ¦t.A, u.B, v.C, . . . [ f¦, gdje su t, u, v, . . . varijable-
n-torke, A, B, C, . . . su atributi odgovaraju´cih relacija, a f je WFF koja sadrˇzi t, u, v, . . . kao slobodne
varijable. Dalje slijede primjeri vezani uz naˇsu fakultetsku bazu podataka (potpoglavlje 3.1).
Upit 1: Pronadi sve brojeve kolegija.
¦c.CNO [ COURSE(c)¦ .
Upit 2: Pronadi brojeve svih studenata na stupnju 1.
¦s.SNO [ STUDENT(s) and s.LEVEL = 1¦ .
Upit 3: Pronadi brojeve i imena studenata koji su upisali kolegij 121.
¦s.SNO, s.SNAME [ STUDENT(s) and ∃ r (REPORT(r)
andr.SNO = s.SNO and r.CNO = 121)¦ .
Upit 4: Pronadi brojeve onih kolegija koje je upisao bar jedan student na stupnju 1.
¦c.CNO [ COURSE(c) and ∃ r (REPORT(r) and r.CNO = c.CNO
and ∃ s (STUDENT(s) and s.SNO = r.SNO and s.LEVEL = 1))¦ .
Upit 5: Pronadi imena onih studenata koji su upisali sve kolegije.
¦s.SNAME [ STUDENT(s) and ∀c ∃r (COURSE(c) and
REPORT(r) and c.CNO = r.CNO and r.SNO = s.SNO)¦ .
3.2.2 Raˇcun orijentiran na domene
Varijable “prolaze” domenama a ne relacijama. Takoder, imamo takozvane uvjete ˇclanstva oblika:
R(A : v
1
, B : v
2
, C : v
3
, . . .), gdje su A, B, C, . . . atributi od relacije R, a v
1
, v
2
, v
3
. . . su ili var-
ijable ili konstante. Na primjer, uvjet STUDENT(SNO : 872501, LEVEL : 1) je istina ako i samo
ako postoji n-torka u relaciji STUDENT takva da je SNO = 872501, LEVEL = 1. Pravila za WFF
su ista kao u raˇcunu orijentiranom na n-torke. Slijede primjeri upita za naˇsu fakultetsku bazu podataka.
Upit 1: Pronadi sve brojeve kolegija.
¦C [ COURSE(CNO : C)¦ .
Upit 2: Pronadi brojeve svih studenata na stupnju 1.
¦S [ STUDENT(SNO : S, LEVEL : 1)¦ .
Upit 3: Pronadi brojeve i imena studenata koji su upisali kolegij 121.
¦S, N [ STUDENT(SNO : S, SNAME : N) and REPORT(SNO : S, CNO : 121)¦ .
Upit 4: Pronadi brojeve i naslova kolegija koje je upisao bar jedan student na stupnju 1.
¦C, T [ COURSE(CNO : C, TITLE : T) and
∃ S (REPORT(CNO : C, SNO : S) and STUDENT(SNO : S, LEVEL : 1))¦ .
3.3. JEZIK SQL 29
Upit 5: Pronadi imena onih studenata koji su upisali sve kolegije.
¦N [ ∃ S (STUDENT(SNO : S, SNAME : N) and
∀ C(if COURSE(CNO : C) then REPORT(SNO : S, CNO : C)))¦
(ovdje se implikacija if . . . then moˇze zapisati pomo´cu and, or i not).
Relacijski raˇcun je u ve´coj mjeri “neproceduralan” nego relacijska algebra. Stoga praktiˇcni relacijski
jezici (namijenjeni neposrednim korisnicima) viˇse liˇce na raˇcun nego na algebru. Najraˇsireniji danaˇsnji
jezik SQL zasnovan je na raˇcunu orijentiranom na n-torke. Drugi poznati jezik QBE (Query By
Example) koristi raˇcun orijentiran na domene.
3.3 Jezik SQL
Structured Query Language (SQL) razvio je IBM u sklopu projekta “System R” (Chamberlin i drugi,
kasne 70-te godine 20. stolje´ca). Jezik se postepeno usavrˇsavao, a njegova dotjerana varijanta pojavljuje
se u danaˇsnjem IBM-ovom relacijskom DBMS-u zvanom DB2. Druge softverske ku´ce (na primjer Oracle
Corporation) ugradile su SQL u svoje DBMS-e, te ga time uˇcinile vrlo popularnim i dostupnim na svim
vaˇznijim raˇcunalnim platformama. Preostale ku´ce (INGRES Corporation, DEC, . . . ) koje su razvijale
svoje jezike, bile su prisiljene da se prilagode SQL-u. Zbog pojave raznih “dijalekata” donesen je
ISO/ANSI standard za SQL (zadnja verzija 1998. godine).
SQL je uglavnom zasnovan na relacijskom raˇcunu, s time da je matematiˇcka notacija zamijenjena
kljuˇcnim rijeˇcima nalik na govorni engleski jezik. No lagano se realiziraju i sve operacije iz relacijske al-
gebre. Osim postavljanja upita, jezik takoder omogu´cuje: definiranje relacija, aˇzuriranje relacija (upis,
promjena, brisanje n-torki), sortiranje i formatiranje ispisa, neke aritmetiˇcke operacije s podacima,
definiranje “pogleda” (virtuelnih relacija izvedenih iz postoje´cih), utjecaj na fiziˇcku gradu baze (na
primjer stvaranje tzv. indeksa), te kontrolu sigurnosti. SQL ´cemo detaljnije proraditi na vjeˇzbama.
Sada ´cemo navesti samo nekoliko primjera.
3.3.1 Postavljanje upita
Upit se postavlja fleksibilnom naredbom SELECT (nije isto ˇsto i operacija selekcije u relacijskoj
algebri). Rezultat upita se shva´ca kao nova privremena relacija, izvedena iz stalnih (po tome je SQL
sliˇcan relacijskoj algebri).
Upit 1: Pronadi brojeve i imena svih studenata na stupnju 1.
SELECT SNO, SNAME
FROM STUDENT
WHERE LEVEL = 1;
ili (ukoliko ˇzelimo uzlazno sortirani ispis)
SELECT SNO, SNAME
FROM STUDENT
WHERE LEVEL = 1
ORDER BY SNAME;
Upit 2: Pronadi brojeve i imena studenata koji su upisali kolegij 121.
SELECT STUDENT.SNO, STUDENT.SNAME
FROM STUDENT, REPORT
WHERE STUDENT.SNO = REPORT.SNO
AND REPORT.CNO = 121;
30 3. JEZICI ZA RELACIJSKE BAZE PODATAKA
Ovdje smo morali proˇsiriti imena atributa da bi izbjegli dvoznaˇcnost. Vidimo kako SQL SE-
LECT naredba zamjenjuje prirodni spoj iz relacijske algebre.
ˇ
Stoviˇse, to je mogao biti i theta-
spoj. Drugo rjeˇsenje za isti upit glasi:
SELECT SNO, SNAME
FROM STUDENT
WHERE SNO IN
(SELECT SNO
FROM REPORT
WHERE CNO = 121);
Upit 3: Pronadi brojeve i imena studenata koji su upisali bar jedan kolegij kojeg predaje Quinn.
SELECT SNO, SNAME
FROM STUDENT
WHERE SNO IN
(SELECT SNO
FROM REPORT
WHERE CNO IN
(SELECT CNO
FROM COURSE
WHERE LNAME = ’Quinn’));
Drugo rjeˇsenje za isti upit glasi:
SELECT STUDENT.SNO, STUDENT.SNAME
FROM STUDENT, REPORT, COURSE
WHERE STUDENT.SNO = REPORT.SNO
AND REPORT.CNO = COURSE.CNO
AND COURSE.LNAME = ’Quinn’;
Upit 4: Pronadi sve parove brojeva studenata takve da su odgovaraju´ci studenti na istom stupnju.
SELECT TEMP1.SNO, TEMP2.SNO
FROM STUDENT TEMP1, STUDENT TEMP2
WHERE TEMP1.SNO < TEMP2.SNO
AND TEMP1.LEVEL = TEMP2.LEVEL;
Ovdje smo uveli drugo ime (alias) za relaciju STUDENT.
Upit 5: Pronadi sve podatke o studentima koji nisu upisali kolegij 121.
SELECT *
FROM STUDENT
WHERE SNO NOT IN
(SELECT SNO
FROM REPORT
WHERE CNO = 121);
Znak * ovdje oznaˇcava sve atribute relacije.
Upit 6: Pronadi brojeve onih studenata koji su upisali sve kolegije. Budu´ci da SQL nema univerzalni
kvantifikator ali ima egzistencijalni, upit moramo ovako preformulirati: “Pronadi brojeve onih
studenata za koje ne postoji kolegij kojeg oni nisu upisali”.
3.4. OPTIMIZACIJA UPITA 31
SELECT SNO
FROM STUDENT
WHERE NOT EXISTS
(SELECT *
FROM COURSE
WHERE NOT EXISTS
(SELECT *
FROM REPORT
WHERE REPORT.SNO = STUDENT.SNO
AND REPORT.CNO = COURSE.CNO));
Ovdje je EXISTS (SELECT . . . ) istina ukoliko je rezultat ukljuˇcene SELECT naredbe
neprazan.
3.3.2 Aˇzuriranje relacija
Upis, promjena, odnosno brisanje n-torke u relaciji postiˇze se naredbomINSERT, UPDATE, odnosno
DELETE. Sve tri naredbe gradene su po analogiji sa SELECT.
Primjer 1: Upiˇsi u relaciju STUDENT novu n-torku sa sljede´cim vrijednostima atributa: SNO =
867520, SNAME = ’Smith’, LEVEL = 2.
INSERT
INTO STUDENT
VALUES (867520, ’Smith’, 2);
Primjer 2: Promijeni nastavnika kolegija 251 iz Quinn u Black.
UPDATE COURSE
SET LNAME = ’Black’
WHERE CNO = 251;
Ova naredba mijenja svaku n-torku u kojoj je CNO = 251.
Primjer 3: Briˇsi sve studente na stupnju 3.
DELETE
FROM STUDENT
WHERE LEVEL = 3;
3.4 Optimizacija upita
Jezici za relacijske baze podataka daju korisniku veliku slobodu u postavljanju upita. Teret efikasnog
odgovaranja na te raznolike upite prebaˇcen je na DBMS. Naime, odgovor na jedan te isti upit obiˇcno
se moˇze dobiti na razne naˇcine, a zadatak DBMS-a je da odabere najefikasniji naˇcin. Odabir dobrog
postupka za odgovaranje zove se optimizacija upita. Moderni DBMS provodi optimizaciju na dvije
razine:
viˇsa (logiˇcka) razina : preformuliranje algebarskog izraza u oblik koji je ekvivalentan polaznom, ali
je pogodniji sa stanoviˇsta izvrednjavanja;
niˇza (fiziˇcka) razina : odabir dobrog algoritma za izvrednjavanje svake od osnovnih operacija u alge-
barskom izrazu. Pritom se nastoji iskoristiti eventualno prisustvo pomo´cnih struktura podataka
(indeksi i sliˇcno).
32 3. JEZICI ZA RELACIJSKE BAZE PODATAKA
U ovom poglavlju bavimo se viˇsom razinom optimizacije, dok ´ce niˇza razina biti obradena u poglavlju
5. Preˇsutno smo pretpostavili da je upit zadan pomo´cu relacijske algebre. Slijedi opravdanje za tu
pretpostavku.
3.4.1 Odnos izmedu relacijske algebre i raˇcuna
Svaki upit zapisan u relacijskoj algebri moˇze se zamijeniti ekvivalentnimupitomzapisanim u relacijskom
raˇcunu. Strogi dokaz ove tvrdnje moˇze se na´ci u literaturi. Mi kao ilustraciju navodimo ekvivalente za
“bitne” algebarske operacije:
R
1
union R
2
. . . ¦t [ R
1
(t) or R
2
(t)¦ ,
R
1
minus R
2
. . . ¦t [ R
1
(t) and not R
2
(t)¦ ,
R
1
times R
2
. . . ¦< t, r > [ R
1
(t) and R
2
(r)¦ ,
R
1
where f(X) . . . ¦t [ R
1
(t) and f(t.X)¦ ,
R
1
[X] . . . ¦t.X [ R
1
(t)¦ .
Ovdje < t, r > znaˇci kombinaciju n-torki t i r. E.F. Codd je u svom ˇclanku iz 1972. godine dokazao
i obratnu tvrdnju, tj. da se svaki upit zapisan pomo´cu relacijskog raˇcuna moˇze formulirati i pomo´cu
relacijske algebre.
ˇ
Stoviˇse, Codd je izloˇzio redukcijski algoritam kojim se izraz u raˇcunu pretvara u
izraz u algebri.
Praktiˇcni jezici poput SQL kombiniraju elemente raˇcuna i algebre. Stoga je oˇcigledno da se upiti
zapisani u tim jezicima takoder mogu preformulirati u relacijsku algebru.
Zahvaljuju´ci ovim rezultatima, prilikom razmatranja optimizacije moˇzemo bez gubitka op´cenitosti
smatrati da je upit ve´c zapisan u relacijskoj algebri. Naime, ako to nije tako, tada bi prvi korak
optimizacije bila pretvorba upita u algebarski izraz.
3.4.2 Osnovna pravila za optimizaciju
Znaˇcajna uˇsteda vremena postiˇze se mijenjanjem redoslijeda operacija, u cilju da se ˇsto prije smanji
veliˇcina relacija s kojima radimo.
Kombiniranje selekcija . Oˇcito vrijedi ekvivalencija:
(R where B
1
) where B
2
= R where (B
1
and B
2
).
Ovime smanjujemo potrebno vrijeme ukoliko se obje selekcije odvijaju podjednako “sporo” (tj.
pregledom cijele relacije). Ako se jedna relacija odvija brzo (na primjer zahvaljuju´ci prisustvu
pomo´cnih fiziˇckih struktura podataka) a druga sporo, tada se kombiniranje ne isplati, jer ´ce rezul-
tiraju´ca selekcija takoder biti spora. Znaˇci, odlukaˇsto je bolje ovisi o fiziˇckoj gradi baze podataka.
Izvlaˇcenje selekcije ispred prirodnog spoja odnosno Kartezijevog produkta . Ako uvjet B
sadrˇzi samo atribute od R, a ne one od S, tada vrijedi:
(R join S) where B = (R where B) join S,
(R times S) where B = (R where B) times S.
Ova transformacija moˇze znatno smanjiti broj n-torki koje ulaze u prirodni spoj odnosno Kartez-
ijev produkt. Op´cenitije, ako B rastavimo na B = B
R
and B
S
and B
C
and B

, gdje B
R
sadrˇzi
samo atribute od R, B
S
sadrˇzi samo atribute od S, B
C
sadrˇzi zajedniˇcke atribute od R i S, B

predstavlja ostatak od B, tada vrijedi:
(R join S) where B =
( (R where (B
R
and B
C
)) join (S where (B
S
and B
C
)) ) where B

.
Sliˇcna ekvivalencija moˇze se napisati i za operator times.
Na primjer, ˇzelimo na´ci brojeve svih studenata na stupnju 1 koji su upisali neki kolegij kod nas-
tavnika Quinna i dobili ocjenu iznad 70 iz tog kolegija. Tada se to moˇze izraziti kao:
3.4. OPTIMIZACIJA UPITA 33
RESULT := ( (STUDENT join REPORT join COURSE)where
(LEVEL=1 and MARK>70 and LNAME=’Quinn’) ) [SNO].
Primjenom transformacije dobivamo:
RESULT := ( ((STUDENT where (LEVEL=1) join
(REPORT where MARK>70)) join
(COURSE where LNAME=’Quinn’) ) [SNO] .
Izvlaˇcenje selekcije ispred projekcije . Ako uvjet B sadrˇzi samo projicirane atribute X, tada je:
R[X] where B = (R where B) [X] .
Projiciranje moˇze dugo trajati zbog eliminacije “duplikata”. Zato je dobro najprije smanjiti
broj n-torki selektiranjem. To je posebno preporuˇcljivo onda kad postoje fiziˇcka sredstva za brzu
selekciju.
Kombiniranje projekcija . Ako su X, Y i Z atributi od relacije R, tada vrijedi:
((R[X, Y, Z])[X, Y ])[X] = R[X] .
Umjesto tri projekcije dovoljna je samo jedna. U ovom jednostavnom sluˇcaju, ta jednakost
je oˇcigledna. No u dugaˇckim i kompliciranim izrazima nije lako uoˇciti redundantno projiciranje.
Izvlaˇcenje projekcije ispred prirodnog spoja . Moramo paziti da projiciranjem ne izbacimo za-
jedniˇcki atribut iz relacija prije nego ˇsto je bio obavljen prirodni spoj. Ako X oznaˇcava zajedniˇcke
atribute od R i S, tada je:
(R join S)[X] = R[X] join S[X] .
No pravilo ne vrijedi za proizvoljni skup atributa X. Neka su A
R
atributi od R, A
S
atributi
od S, A
C
= A
R
∩ A
S
zajedniˇcki atributi od R i S. Tada vrijedi:
(R join S)[X] = ( R[(X ∩ A
R
) ∪ A
C
] join S[(X ∩A
S
) ∪ A
C
] )[X] .
Opet se smanjuje broj n-torki koje ulaze u prirodni spoj. Zahvat ne mora uvijek biti koristan, jer
projekcija moˇze sprijeˇciti efikasnu implementaciju prirodnog spoja. Na primjer, projekcija moˇze
stvoriti privremenu relaciju na koju nisu primjenjive postoje´ce pomo´cne fiziˇcke strukture. Znaˇci,
odluka ˇsto je bolje opet ovisi o fiziˇckoj gradi.
Optimizacija skupovnih operatora . Koji put su od koristi sljede´ca pravila:
(R union S) where B = (R where B) union (S where B) ,
(R minus S) where B = (R where B) minus (S where B) ,
(R union S)[X] = R[X] union S[X] ,
(R minus S)[X] = R[X] minus S[X] ,
(R where B
1
)[X] union (R where B
2
)[X] = ( R where (B
1
or B
2
) )[X] .
Predzadnja jednakost vrijedi pod pretpostavkom da X sadrˇzi kljuˇcne atribute od R (a time i
od S). Transformacijama se nastoji smanjiti broj n-torki koje sudjeluju u operacijama union i
minus. Operator intersect je specijalni sluˇcaj od join, pa za njega vrijede ista pravila kao za
join.
34 3. JEZICI ZA RELACIJSKE BAZE PODATAKA
4
FIZI
ˇ
CKA GRADA BAZE
PODATAKA
4.1 Elementi fiziˇcke grade
Baza podataka se u fiziˇckom smislu svodi na gomilu bitova pohranjenih na magnetskim diskovima.
Takav doslovni naˇcin gledanja je bez sumnje istinit, no on ne omogu´cuje da stvarno razumijemo fiziˇcku
gradu baze. Umjesto toga, bolje je promatrati malo apstraktnije objekte, kao ˇsto su zapisi, datoteke i
pointeri. Rijeˇc je o prvom, sasvim niskom nivou apstrakcije koji je vrlo blizak fiziˇckoj stvarnosti.
4.1.1 Vanjska memorija raˇcunala
Operacijski sustav raˇcunala dijeli vanjsku memoriju u jednako velike blokove. Veliˇcina bloka je kon-
stanta operacijskog sustava, i ona moˇze iznositi na primjer 512 byte ili 4096 byte. Svaki blok jed-
noznaˇcno je zadan svojom adresom. Osnovna operacija s vanjskom memorijom je prijenos bloka sa
zadanom adresom iz vanjske memorije u glavnu, ili obratno. Dio glavne memorije koji sudjeluje u
prijenosu (i ima jednaku veliˇcinu kao i sam blok) zove se buffer. Blok je najmanja koliˇcina podataka
koja se moˇze prenijeti; na primjer ako ˇzelimo proˇcitati samo jedan byte iz vanjske memorije, tada
moramo prenijeti cijeli odgovaraju´ci blok, pretraˇziti buffer u glavnoj memoriji i izdvojiti traˇzeni byte.
Vrijeme potrebno za prijenos bloka nije konstantno ve´c ovisi o trenutnom poloˇzaju glave diska. Ipak,
to vrijeme (mjereno u milisekundama) neusporedivo je ve´ce od vremena potrebnog za bilo koju ma-
nipulaciju u glavnoj memoriji (mjereno u mikro- i nanosekundama). Zato je brzina nekog algoritma za
rad s vanjskom memorijom odredena brojem blokova koje algoritam mora prenijeti, a vrijeme potrebno
za raˇcunanje i manipuliranje u glavnoj memoriji je zanemarivo.
4.1.2 Datoteke
Osnovni problem fiziˇckog prikazivanja baze podataka je organizacija datoteke. Datoteka je konaˇcni
niz zapisa istog tipa pohranjenih u vanjskoj memoriji. Tip zapisa zadaje se kao uredena n-torka
osnovnih podataka (komponenti), gdje je svaki osnovni podatak opisan svojim imenom i tipom (int,
float, character string, . . . ). Primijetimo da je tip zapisa definiran neˇsto uˇze nego na primjer u C-u,
naime nije dozvoljena hijerarhijska ni varijabilna grada zapisa. Sam zapis sastoji se od konkretnih
vrijednosti osnovnih podataka. Smatramo da su zapisi fiksne duljine, dakle jedan zapis ima toˇcno
jednu vrijednost svakog od osnovnih podataka i ta vrijednost je prikazana fiksiranim brojem byte-ova.
Tipiˇcne operacije koje se obavljaju nad datotekom su:
• ubaciti novi zapis,
• promijeniti zapis,
• izbaciti zapis,
• na´ci zapis ili zapise gdje zadani podaci imaju zadane vrijednosti.
35
36 4. FIZI
ˇ
CKA GRADA BAZE PODATAKA
Sloˇzenost grade datoteke ovisi o tome koliko efikasno ˇzelimo obavljati pojedine od ovih operacija.
(Kandidat za) kljuˇc je osnovni podatak, ili kombinacija osnovnih podataka, ˇcija vrijednost jed-
noznaˇcno odreduje zapis. Ukoliko ima viˇse kandidata za kljuˇc, tada odabiremo jednog od njih da bude
primarni kljuˇc. Ne mora svaka datoteka imati kljuˇc, jer mogu postojati zapisi-duplikati.
876543 Jones 2
864532 Burns 1
856434 Cairns 3
1
2
3
Slika 4.1: Datoteka sa zapisima o studentima
Kao primjer, promatrajmo datoteku o studentima fakulteta. Tip zapisa definiran u jeziku C je:
typedef struct ¦
int SNO;
char SNAME[15];
char LEVEL;
¦ STUDENT;
Prvih nekoliko zapisa izgleda kao na Slici 4.1. Svaki zapis ima svoj redni broj. Duljina zapisa je 20
byte. Vrijednost prvog osnovnog podatka zauzima 1. do 4. byte, vrijednost drugog osnovnog podatka
5. do 19. byte, a tre´ci podatak je u 20. byte-u.
4.1.3 Smjeˇstaj datoteke u vanjskoj memoriji
Zapis je obiˇcno znatno manji od bloka. Stoga se viˇse zapisa sprema u jedan blok. Uzimamo da je u
bloku smjeˇsten cijeli broj zapisa, ˇsto znaˇci da je dio bloka moˇzda neiskoriˇsten. Adresa zapisa gradi
se kao uredeni par (adresa bloka, pomak unutar bloka). Kod nekih organizacija datoteki mogu neka
mjesta za zapise u bloku ostati prazna. Kako da razlikujemo puna i prazna mjesta? Jedno rjeˇsenje je:
proˇsiriti zapis s jednim bitom koji oznaˇcava da li je mjesto “puno” ili “prazno”. Koji put je potrebno
“poniˇstiti” zapis (uˇciniti ga nevaˇze´cim), ali tako da njegovo mjesto i dalje bude zauzeto. Kako da
razlikujemo vaˇze´ce i nevaˇze´ce zapise? Opet proˇsirimo zapis jednim bitom koji oznaˇcava da li zapis
“vaˇzi” ili “ne vaˇzi”. Sve se ovo vidi na Slici 4.2.
1 0 . . . (zapis 5) . . .
1 1 . . . (zapis 4) . . .
0 1 . . . (zapis 3) . . .
1 0 . . . (zapis 2) . . .
0 0 . . . (zapis 1) . . .
`
·
blok
puno/prazno
vaˇzi/ne vaˇzi
/
/
/
/-

-
Slika 4.2: Prikaz zapisa unutar bloka
Cijela datoteka obiˇcno zauzima viˇse blokova, kao ˇsto je ilustrirano Slikom 4.3. Naˇcin kako se
odreduju adrese tih blokova ovisi o organizaciji datoteke (vidi potpoglavlje 4.2). U svakom sluˇcaju, ne
mora se raditi o nizu uzastopnih adresa. Naime, zbog pisanja i brisanja podataka, vanjska memorija
se prije ili kasnije isparcelira, pa smo prisiljeni koristiti njene nepovezane dijelove.
4.2. PRISTUP NA OSNOVU PRIMARNOG KLJU
ˇ
CA 37
. . .
. . .
. . .
. . .
. . .
blok N
.
.
.
. . .
. . .
. . .
. . .
. . .
blok 3
. . .
. . .
. . .
. . .
. . .
blok 2
. . .
. . .
. . .
. . .
. . .
blok 1
Slika 4.3: Prikaz datoteke kao niza blokova
4.1.4 Pointeri
Pointer je vrijednost unutar jednog zapisa koja pokazuje na neki drugi zapis (u istoj ili drugoj datoteci).
Pointer moˇze biti:
• adresa zapisa (“fiziˇcki” pointer),
• vrijednost primarnog kljuˇca (“logiˇcki” pointer).
Postoje i prijelazni oblici izmedu fiziˇckog i logiˇckog pointera, na primjer redni broj zapisa; no smisao
takvih vrijednosti ovisi o konkretnoj organizaciji datoteke i mi ih ne´cemo razmatrati.
Pointeri omogu´cuju uspostavljanje veze izmedu zapisa, dakle oni omogu´cuju da iz jednog zapisa
pristupimo drugom. Pointer-adresa omogu´cuje brzi pristup. Pointer-kljuˇc je “spor” - on samo implic-
itno odreduje zapis kojeg tek treba prona´ci nekim mehanizmom za traˇzenje na osnovu kljuˇca.
Prisustvo pointera-adrese moˇze uzrokovati probleme kod aˇzuriranja ili reorganiziranja datoteke.
Ako na zapis pokazuje pointer-adresa, kaˇzemo da je zapis prikovan (pinned) - zapis se naime ne
smije fiziˇcki pomicati sa svog mjesta jer bi nakon pomaka pointer krivo pokazivao. Jedini naˇcin da
pomaknemo prikovani zapis je da takoder aˇzuriramo i pointer, no problem je da za zadani zapis obiˇcno
ne znamo gdje se sve mogu nalaziti pointeri koji na njega pokazuju.
Prisustvo pointera-kljuˇca ne uzrokuje nikakve probleme kod aˇzuriranja ili reorganizacije datoteke.
To je i razlog zaˇsto koristimo takve pointere, unatoˇc njihovoj “sporosti”.
4.1.5 Fiziˇcka grada cijele baze
Cijela baza je gradena kao skup datoteki. Zapisi u datotekama mogu biti medusobno povezani pointer-
ima. Sve operacije s bazom svode se na osnovne operacije s datotekama. Zbog toga se u potpoglavljima
4.2 i 4.3 bavimo iskljuˇcivo datotekama.
Ukoliko imamo posla s relacijskim bazama, tada se svaka relacija prikazuje jednom datotekom.
Atributi relacije odgovaraju osnovnim podacima u zapisu. Jedna n-torka relacije prikazana je jednim
zapisom. Primarni kljuˇc relacije odreduje primarni kljuˇc datoteke. Primijetimo da se ovakvim fiziˇckim
prikazom uvodi umjetni redoslijed medu atributima relacije, te umjetni redoslijed n-torki. No, relacijski
DBMS u stanju je promijeniti taj redoslijed prilikom rada s relacijom.
Osim osnovnih datoteki koje odgovaraju pojedinim relacijama, fiziˇcka grada relacijske baze moˇze
sadrˇzavati i dodatne pomo´cne datoteke koje ubrzavaju pretraˇzivanje i uspostavljanje veza medu po-
dacima. Tipiˇcni primjeri takvih datoteki su indeksi.
4.2 Pristup na osnovu primarnog kljuˇca
Vaˇzna operacija u radu s datotekama je pristup na osnovu primarnog kljuˇca. Dakle, za zadanu vri-
jednost primarnog kljuˇca treba odrediti adresu (najviˇse jednog) zapisa koji sadrˇzi tu vrijednost kljuˇca.
Prouˇcit ´cemo razne organizacije datoteki i naˇcine kako da se za njih realizira pristup na osnovu pri-
marnog kljuˇca.
38 4. FIZI
ˇ
CKA GRADA BAZE PODATAKA
4.2.1 Jednostavna datoteka
Zapravo se radi o odsustvu bilo kakve organizacije. Zapise datoteke poredamo u onoliko blokova
koliko je potrebno. Blokovi koji ˇcine datoteku mogu biti povezani u vezanu listu (svaki blok sadrˇzi
adresu idu´ceg bloka) ili moˇze postojati tablica adresa svih blokova (koja zauzima prvi ili prvih nekoliko
blokova). Te dvije varijante jednostavne datoteke vide se na Slici 4.4.
. . .
. . .
. . .
. . .
. . . .
blok N
.
.
.
. . .
. . .
. . .
. . .
... a
»
blok 3
. . .
. . .
. . .
. . .
... a
»
blok 2
. . .
. . .
. . .
. . .
... a
»
blok 1

. . .
. . .
. . .
. . .
. . .
blok N
.
.
.
. . .
. . .
. . .
. . .
. . .
blok 3
. . .
. . .
. . .
. . .
. . .
blok 2
. . .
. . .
. . .
. . .
. . .
blok 1
a a a
. . .
a

¬
`
`
`
`
`

`
`
`
`
`
`
`
`
``-
zaglavlje

Slika 4.4: Jednostavna datoteka (dvije varijante)
Traˇzenje zapisa sa zadanom vrijednoˇs´cu kljuˇca zahtijeva sekvencijalno ˇcitanje cijele datoteke (ili
bar pola datoteke u prosjeku), sve dok ne naidemo na traˇzeni zapis. Ako je datoteka velika, morat
´cemo uˇcitati mnogo blokova, pa pristup traje dugo.
Da bi ubacili novi zapis, stavljamo ga na prvo slobodno mjesto u prvom nepopunjenom bloku, ili
prikljuˇcujemo novi blok ukoliko su svi postoje´ci blokovi popunjeni.
Ako su zapisi prikovani, tada ne smijemo zaista izbacivati zapise, ve´c ih samo moˇzemo proglasiti
nevaˇze´cima. No ako zapisi nisu prikovani, tada ih smijemo izbacivati, pa ´ce se time ispraˇznjena mjesta
koristiti kod budu´cih ubacivanja. Promjena zapisa obavlja se bez ograniˇcenja.
4.2.2 Hash datoteka
Zapise datoteke smjeˇstamo u P pretinaca, oznaˇcenih rednim brojevima 0, 1, 2, . . . , P − 1. Svaki
pretinac sastoji se od jednog ili viˇse blokova. Zadana je tzv. hash funkcija h, koja daje redni broj
h(k) pretinca u kojem se treba nalaziti zapis s vrijednoˇs´cu kljuˇca k.
Skup mogu´cih vrijednosti kljuˇca obiˇcno je znatno ve´ci od broja pretinaca. Vaˇzno je da h uniformno
distribuira vrijednosti kljuˇca na pretince. Tada se ne´ce deˇsavati da se pretinci neravnomjerno pune.
Dajemo primjer dobre hash funkcije:
• vrijednosti kljuˇca promatraju se kao nizovi bitova fiksne duljine;
• zadani niz bitova se podijeli na skupine fiksne duljine, s time da se zadnja skupina nadopuni
nulama ako je potrebno;
• skupine bitova se zbroje kao cijeli brojevi;
• zbroj se podijeli s brojem pretinaca;
• ostatak kod dijeljenja je traˇzeni redni broj pretinca.
Hash datoteka obiˇcno se realizira tako da pretinci budu vezane liste blokova. Adrese poˇcetaka tih
listi ˇcine zaglavlje koje se smjeˇsta u prvi blok ili prvih nekoliko blokova datoteke. Cijela organizacija
hash datoteke vidljiva je na Slici 4.5. Zaglavlje je obiˇcno dovoljno malo, pa se za vrijeme rada s
datotekom moˇze drˇzati u glavnoj memoriji.
Zapis sa zadanom vrijednoˇs´cu kljuˇca k traˇzimo tako da izraˇcunamo h(k), te sekvencijalno pretraˇzimo
h(k)-ti pretinac. Ako je hash funkcija zaista uniformna, te ako je broj pretinaca dobro odabran, tada
ni jedan od pretinaca nije suviˇse velik. Pristup na osnovu kljuˇca zahtijeva svega nekoliko ˇcitanja bloka
(obiˇcno oko 2 ˇcitanja).
4.2. PRISTUP NA OSNOVU PRIMARNOG KLJU
ˇ
CA 39
. . .
. . .
. . .
. . .
... a
. . .
. . .
. . .
. . .
... a
. . .
. . .
. . .
. . .
... a
.
.
.
. . .
. . .
. . .
. . .
... a
. . .
. . .
. . .
. . .
... a
. . .
. . .
. . .
. . .
... a
a
.
.
.
.
.
.
.
.
.
a
a

P − 1
1
0
zaglavlje
(pretinac P −1)
(pretinac 1)
(pretinac 0)

Slika 4.5: Hash datoteka
Novi zapis s vrijednoˇs´cu kljuˇca k ubacuje se u h(k)-ti pretinac, u prvi blok gdje ima mjesta. Ako
su svi blokovi h(k)-te vezane liste puni, tada na kraj te vezane liste prikljuˇcujemo novi blok.
Ako su svi zapisi prikovani, tada ih ne smijemo izbacivati, ve´c ih samo moˇzemo proglasiti “nevaˇze-
´cima”. Ako zapisi nisu prikovani, tada ih smijemo izbacivati, ˇcime oslobadamo mjesta za budu´ca
ubacivanja.
Kod promjene zapisa ne smije se mijenjati vrijednost kljuˇca, jer bi se time mogao promijeniti broj
pretinca kojem zapis mora pripadati (takvu promjenu moˇzemo ostvariti izbacivanjem stare verzije
zapisa te ubacivanjem nove verzije).
Hash datoteka zahtijeva povremene reorganizacije (pove´canje broja pretinaca). Takoder, ona nije
pogodna onda kad obradujemo zapise u sortiranom redoslijedu po kljuˇcu.
4.2.3 Datoteka s indeksom
Indeks je mala pomo´cna datoteka koja olakˇsava traˇzenje u velikoj (osnovnoj) datoteci. Izloˇzit ´cemo
dvije varijante datoteke s indeksom.
Indeks sekvencijalna organizacija zahtijeva da zapisi u osnovnoj datoteci budu sortirani po
vrijednostima kljuˇca (na primjer uzlazno). Blokovi ne moraju biti sasvim popunjeni. Dodajemo tzv.
razrijedeni indeks. Svaki zapis u indeksu odgovara jednom bloku osnovne datoteke i oblika je (k, a),
gdje je k najmanja vrijednost kljuˇca u dotiˇcnom bloku, a je adresa bloka. Sam indeks je takoder
sortiran po kljuˇcu i za sada zamiˇsljamo da je jednostavno organiziran. Cijela organizacija vidljiva je
na Slici 4.6.
-
46
42
blok 5
38
31
28
blok 4
-
27
23
blok 3
-
11
10
blok 2
8
5
3
blok 1
a
23
10
3
a
a
a
·
a
-
42
28
a
a
a

`
`
`
`
`
`
`
`
``

`
`
`
`
`
`
`

`
`
`
`
`
``·
`
`
`
`

(razrijedeni
indeks)
(osnovna
datoteka)
Slika 4.6: Indeks-sekvencijalna organizacija datoteke
40 4. FIZI
ˇ
CKA GRADA BAZE PODATAKA
Da bi u osnovnoj datoteci naˇsli zapis sa zadanom vrijednoˇs´cu kljuˇca k
0
, ˇcitamo indeks te traˇzimo
najve´ci k
1
takav da je k
1
≤ k
0
i pritom par (k
1
, a
1
) postoji u indeksu. Zatim uˇcitamo i pretraˇzimo
blok s adresom a
1
. Pristup po primarnom kljuˇcu zahtijeva (u najgorem sluˇcaju) onoliko ˇcitanja bloka
koliko ima blokova u indeksu +1.
Pretpostavimo da zapisi iz osnovne datoteke nisu prikovani, tj. da na njih ne pokazuju drugi pointeri-
adrese osim onih iz indeksa. Tada moˇzemo obavljati ubacivanja i izbacivanja zapisa.
Opisujemo ubacivanje novog zapisa u osnovnu datoteku. Najprije uz pomo´c indeksa odredimo blok
koji bi morao sadrˇzavati taj novi zapis. Pokuˇsamo umetnuti zapis u blok, i to na pravo mjesto u smislu
sortiranog redoslijeda. Ukoliko u tome ne uspijemo (blok bi se prepunio), tada pokuˇsamo zadnji zapis
iz tog prepunjenog bloka prebaciti u idu´ci blok. Ako ni u tome ne uspijemo (ne postoji idu´ci blok ili je
i on pun) tada u osnovnu datoteku iza prepunjenog bloka ukljuˇcimo novi blok, te u njega prebacimo
zadnji zapis iz prepunjenog bloka. Ubacivanje zapisa u osnovnu datoteku ponekad zahtijeva promjene
u indeksu. Na primjer, ako se u starom bloku promijenila najmanja vrijednost kljuˇca, tada aˇzuriramo
odgovaraju´ci par (k, a) u indeksu. Takoder, ukljuˇcivanje novog bloka zahtijeva ubacivanje novog para
(k, a) u indeks; to se obavlja po algoritmu koji je sliˇcan upravo opisanom.
Ako se izbacivanjem zapisa neki od blokova osnovne datoteke isprazni, iskljuˇcujemo ga iz datoteke.
Izbacivanje zapisa u osnovnoj datoteci takoder moˇze zahtijevati promjene u indeksu. Kod promjene
zapisa u osnovnoj datoteci ne smije se mijenjati vrijednost kljuˇca, jer bi se time promijenio poloˇzaj
zapisa u sortiranom redoslijedu. Indeks-sekvencijalna organizacija omogu´cuje (sekvencijalno) ˇcitanje
osnovne datoteke u sortiranom redoslijedu po kljuˇcu.
Indeks-direktna organizacija dopuˇsta da zapisi u osnovnoj datoteci budu upisani u proizvoljnom
redoslijedu. Dodajemo tzv. gusti indeks. Svaki zapis u indeksu odgovara jednom zapisu osnovne
datoteke i oblika je (k, a), gdje je k vrijednost kljuˇca u dotiˇcnom zapisu osnovne datoteke, a je pointer-
adresa zapisa iz osnovne datoteke. Za razliku od nesortirane osnovne datoteke, indeks je sortiran po
kljuˇcu. Zamiˇsljamo da je indeks jednostavno organiziran. Cijela organizacija prikazana je na Slici 4.7.
-
-
27
blok 5
38
8
3
blok 4
31
46
23
blok 3
-
42
11
blok 2
5
28
10
blok 1
a
8
5
3
a
a
a
·
a
23
11
10
a
a
a
·
a
-
28
27
a
a
a
·
a
-
38
31
a
a
a
·
a
-
46
42
a
a
a

·

¬

¬
`

`
`
(gusti
indeks)
(osnovna
datoteka)
Slika 4.7: Indeks-direktna organizacija datoteke
Da bi u osnovnoj datoteci naˇsli zapis sa zadanom vrijednoˇs´cu kljuˇca k
0
, ˇcitamo indeks te traˇzimo
par (k
0
, a
0
). Direktno ˇcitamo blok u kojem je zapis s adresom a
0
. Zapise iz osnovne datoteke moˇzemo
ubacivati i izbacivati pod pretpostavkom da nisu prikovani. Postupak je sliˇcan kao kod jednostavne
organizacije. Svaki put se mora aˇzurirati indeks, na naˇcin sliˇcan onom za indeks-sekvencijalnu orga-
nizaciju. Ako kod promjene zapisa iz osnovne datoteke promijenimo i vrijednost kljuˇca, potrebno je
jedno ubacivanje i jedno izbacivanje u indeksu.
Indeks-direktna organizacija omogu´cuje ˇcitanje cijele osnovne datoteke u sortiranom redoslijedu
po kljuˇcu (preko indeksa). No oˇcekujemo da to traje znatno dulje nego kod indeks-sekvencijalne
organizacije, jer se deˇsava da zbog raznih zapisa viˇse puta uˇcitavamo isti blok.
4.2. PRISTUP NA OSNOVU PRIMARNOG KLJU
ˇ
CA 41
Prednost indeks-direktne organizacije u odnosu na indeks-sekvencijalnu je jednostavnije ubacivanje i
izbacivanje. Takoder, manje je rasipanje memorije u osnovnoj datoteci. Daljnja prednost je mogu´cnost
odgovora na pitanje da li postoji zadana vrijednost kljuˇca, bez da uop´ce ˇcitamo osnovnu datoteku.
Mana indeks-direktne organizacije je: znatno ve´ci indeks.
4.2.4 B-stablo
U proˇslom odjeljku zamiˇsljali smo da je indeks jednostavno organiziran. To je prihvatljivo rjeˇsenje
samo onda kad je indeks jako mali, tako da stane u svega nekoliko blokova. No kod velikih osnovnih
datoteki, indeks (pogotovo gusti) je takoder velik, pa bi njegovo sekvencijalno pretraˇzivanje trajalo
predugo. Potrebna je bolja organizacija indeksa. Danaˇsnji DBMS-i u tu svrhu redovito koriste tzv.
B-stabla.
B-stablo reda m je m-narno stablo sa sljede´cim svojstvima:
• korijen je ili list ili ima bar dvoje djece;
• svaki ˇcvor, izuzev korijena i listova, ima izmedu m/2| i m djece;
• svi putovi od korijena do lista imaju istu duljinu.
U nastavku promatramo prikaz gustog indeksa pomo´cu B-stabla (prikaz razrijedenog indeksa ide
analogno). Indeks je tada jedno B-stablo sagradeno od blokova vanjske memorije, i to tako da jedan ˇcvor
bude jedan blok. Veza roditelj-dijete realizira se tako da adresa bloka-djeteta piˇse u bloku-roditelju.
Takoder vrijedi:
• Unutraˇsnji ˇcvor ima sadrˇzaj (a
0
, k
1
, a
1
, k
2
, a
2
, . . . , k
r
, a
r
), gdje je a
i
adresa i-tog djeteta dotiˇcnog
ˇcvora (0 ≤ i ≤ r), k
i
je vrijednost kljuˇca (1 ≤ i ≤ r). Vrijednosti kljuˇca unutar ˇcvora su sortirane,
dakle k
1
≤ k
2
≤ . . . ≤ k
r
. Sve vrijednosti kljuˇca u pod-stablu koje pokazuje a
0
su manje od k
1
.
Za 1 ≤ i < r, sve vrijednosti kljuˇca u pod-stablu kojeg pokazuje a
i
su u poluotvorenom intervalu
[k
i
, k
i+1
). Sve vrijednosti kljuˇca u pod-stablu kojeg pokazuje a
r
su ve´ce ili jednake k
r
.
• List sadrˇzi parove oblika (k, a), gdje je k vrijednost kljuˇca, a je pointer-adresa pripadnog zapisa
u osnovnoj datoteci. Parovi unutar lista su uzlazno sortirani po k. List ne mora biti sasvim
popunjen. Jednom zapisu osnovne datoteke odgovara toˇcno jedan par (k, a) u listovima B-stabla.
a
18
a
-
a
-
a
-
a
a
10
a
12
a
-
a
-
a a
22
a
28
a
34
a
38
a
4 6 8
a a a
10 - -
a a a
12 14 16
a a a
18 20 -
a a a
22 24 26
a a a
28 30 32
a a a
34 36 -
a a a
38 40 42
a a a

.
· . . » ¬
··· · ··· ·· ··· ··· ·· ···
Slika 4.8: Gusti indeks prikazan kao B-stablo reda 5
Na slici 4.8 vidimo gusti indeks neke osnovne datoteke, prikazan kao B-stablo reda 5. Primijetimo
da se indeks prikazan pomo´cu B-stabla moˇze shvatiti kao hijerarhija manjih jednostavnih indeksa.
Traˇzenje.
ˇ
Zelimo u B-stablu prona´ci par (k, a), gdje je k zadana vrijednost kljuˇca, a je pointer-
adresa pripadnog zapisa u osnovnoj datoteci. U tu svrhu slijedimo put od korijena do lista koji bi morao
sadrˇzavati k. To se radi tako da redom ˇcitamo unutraˇsnje ˇcvorove oblika (a
0
, k
1
, a
1
, k
2
, a
2
, . . . , k
r
, a
r
),
te usporedimo k s k
1
, k
2
, . . . , k
r
. Ako je k
i
≤ k < k
i+1
, dalje ˇcitamo ˇcvor kojeg pokazuje a
i
. Ako je
k < k
1
, dalje ˇcitamo ˇcvor s adresom a
0
. Ako je k ≥ k
r
, koristimo adresu a
r
. Kad nas taj postupak
konaˇcno dovede u list, traˇzimo u njemu zadani k.
Ubacivanje. Da bi ubacili novi par (k, a) u B-stablo, prvo pronademo list L kojem bi k morao
pripadati. Pokuˇsamo umetnuti par (k, a) u L, i to na pravo mjesto u sortiranom redoslijedu. Ukoliko
u tome uspijemo, tada smo gotovi.
Ukoliko umetanje ne uspije (L bi se prepunio), uzimamo novi blok L

, te premjestimo u L

zadnju
polovicu sortiranog sadrˇzaja prepunjenog L. Neka je P roditelj od L, k

najmanja vrijednost kljuˇca u
42 4. FIZI
ˇ
CKA GRADA BAZE PODATAKA
L

, a

adresa od L

. Potrebno je L

ukljuˇciti u B-stablo kao list. U tu svrhu u P umetnemo k

i a

.
Postupak umetanja u P je analogan ve´c opisanom postupku umetanja u L.
Ako P ve´c ima m adresa, umetanje k

i a

uzrokovat ´ce da se P rascijepi na dva bloka, pa ´cemo
morati umetnuti nove vrijednosti u roditelja od P. Umetanje se rekurzivno ponavlja i moˇze do´ci
najdalje do korijena stabla. Ako se i korijen rascijepi, tada stvaramo novi korijen ˇcija dva djeteta su
dvije polovice starog korijena; visina B-stabla se time pove´cala za 1. Na Slici 4.9 vidi se B-stablo
dobiveno iz stabla sa Slike 4.8 umetanjem nove vrijednosti kljuˇca 23.
a
18
a
28
a
-
a
-
a
a
10
a
12
a
-
a
-
a a
22
a
24
a
-
a
-
a a
34
a
38
a
-
a
-
a
4 6 8
a a a
10 - -
a a a
12 14 16
a a a
18 20 -
a a a
22 23 -
a a a
24 26 -
a a a
28 30 32
a a a
34 36 -
a a a
38 40 42
a a a

.
· · ¬
·
··· · ··· ·· ·· ·· ··· ·· ···
Slika 4.9: Ubacivanje u B-stablo
Izbacivanje. Da bi izbacili par (k, a) iz B-stabla, prvo pronademo list L koji ga sadrˇzi. Izbacimo
(k, a) iz L. Ako je to bio prvi zapis u L, tada idemo u ˇcvor P koji je roditelj od L, te korigiramo
vrijednost kljuˇca u P koja se odnosi na L. Pritom, ako je L prvo dijete od P, najmanja vrijednost
kljuˇca u L se ne pojavljuje u P ve´c u nekom pretku od P, pa tada moramo proslijediti korekciju duˇz
puta od L do korijena.
Ako je L nakon izbacivanja postao prazan, iskljuˇcujemo ga iz stabla. Takoder, moramo korigirati
sadrˇzaj od P u skladu s nestankom L. Ako je broj djece od P sad pao ispod m/2, gledamo ˇcvor P

koji je neposredno lijevi (ili neposredno desni) brat od P. Ako P

ima bar m/2| + 1 djece, jednako
raspodijelimo vrijednosti kljuˇca i adrese u P i P

tako da oba ˇcvora imaju bar m/2| djece. Dalje
korigiramo vrijednosti kljuˇca za P i P

u roditelju od P, s time da po potrebi proslijedimo korekciju
na viˇse pretke od P.
Ako P

ima toˇcno m/2| djece, ujedinimo P i P

u jedan ˇcvor s 2m/2|−1 djece (to je ≤ m). Tada
takoder moramo izbaciti vrijednost kljuˇca i adresu za P

iz roditelja od P. To izbacivanje se obavlja
rekurzivnom primjenom upravo opisane procedure.
Ako se posljedice izbacivanja proˇsire cijelim putom natrag do korijena, moˇze se desiti da trebamo
ujediniti jedina dva djeteta korijena. U tom sluˇcaju rezultiraju´ci kombinirani ˇcvor postaje novi korijen,
a stari korijen se iskljuˇcuje iz stabla. Visina B-stabla se time smanjila za 1. Na Slici 4.10 vidi se B-stablo
dobiveno iz stabla sa Slike 4.9 nakon izbacivanja vrijednosti kljuˇca 10.
a
28
a
-
a
-
a
-
a
a
12
a
18
a
22
a
24
a a
34
a
38
a
-
a
-
a
4 6 8
a a a
12 14 16
a a a
18 20 -
a a a
22 23 -
a a a
24 26 -
a a a
28 30 32
a a a
34 36 -
a a a
38 40 42
a a a

.
·
··· ··· ·· ·· ·· ··· ·· ···
Slika 4.10: Izbacivanje iz B-stabla
Neka B-stablo sadrˇzi u svojim listovima n parova oblika (k, a). Neka je u jednom listu smjeˇsteno u
prosjeku b parova (k, a). Broj ˇcitanja bloka potrebnih za pristup na osnovu kljuˇca proporcionalan je
visini stabla, a to je u najgorem sluˇcaju ≈ log
m/2
n/b|. U praksi m i b mogu biti veliki, pa B-stablo
obiˇcno ima svega nekoliko (3-4) nivoa. Znaˇci, pristup preko indeksa B-stabla je skoro jednako brz kao
pristup u hash datoteku, mada najˇceˇs´ce ipak malo sporiji. Prednost B-stabla pred hash datotekom je
ˇcuvanje sortiranog redoslijeda zapisa po kljuˇcu.
4.3. PRISTUP NA OSNOVU DRUGIH PODATAKA 43
4.3 Pristup na osnovu drugih podataka
Osim pristupa na osnovu primarnog kljuˇca, u radu s datotekama javlja se i potreba za pristupom na
osnovu drugih podataka. Dakle, traˇze se zapisi u kojima zadani podatak (koji nije kljuˇc) ima zadanu
vrijednost. Takvih zapisa moˇze biti i viˇse. Op´cenitije, mogu se traˇziti zapisi u kojima istovremeno
podatak A
1
ima zadanu vrijednost v
1
, podatak A
2
ima vrijednost v
2
, . . . , podatak A
r
ima vrijednost
v
r
. Problem se uvijek moˇze rijeˇsiti sekvencijalnim pregledom cijele datoteke. No ukoliko ˇzelimo da se
pristup obavlja brzo, potrebne su posebne organizacije datoteke.
4.3.1 Invertirana datoteka
Svi indeksi koje smo razmatrali u Potpoglavlju 4.2 mogli bi se zvati primarni indeksi, jer olakˇsavaju
pristup na osnovu primarnog kljuˇca. U ovom poglavlju uvodimo sekundarni indeks - to je mala
(pomo´cna) datoteka koja olakˇsava pristup zapisima velike (osnovne) datoteke na osnovu podatka koji
nije kljuˇc. Sekundarni indeks za podatak A sastoji se od zapisa oblika (v, ¦p
1
, p
2
, p
3
, . . .¦), gdje je
v vrijednost za A, a ¦p
1
, p
2
, p
3
, . . .¦ je skup pointera na zapise u osnovnoj datoteci u kojima A ima
vrijednost v. Ukoliko postoji ovakav indeks, kaˇze se da je osnovna datoteka invertirana po podatku
A. Datoteka koja je invertirana po svakom od svojih podataka zove se potpuno invertirana.
Kao primjer, promatramo Tabelarni prikaz 4.1. Rijeˇc je o datoteci nastavnika na fakultetu. Ako
invertiramo tu datoteku po svakom podatku osim IME, dobivamo gusti primarni indeks za kljuˇc
MAT BR i tri sekundarna indeksa za ODJEL, DOB i STUPANJ. Indeks za DOB sadrˇzi intervale
umjesto pojedinaˇcnih vrijednosti.
Osnovna datoteka o nastavnicima
MAT BR IME ODJEL DOB STUPANJ
a
1
12453 Mati´c, R. Matematika 35 Dr.sc.
a
2
16752 Pavi´c, D. Matematika 26 Dipl.inˇz.
a
3
27453 Horvat, I. Raˇcunarstvo 37 Dr.sc.
a
4
34276 Dimi´c, J. Fizika 55 Dr.sc.
a
5
37564 Kati´c, K. Raˇcunarstvo 45 Dipl.inˇz.
a
6
43257 Radi´c, M. Matematika 32 Mr.sc.
a
7
45643 Jani´c, Z. Fizika 24 Dipl.inˇz.
a
8
56321 Popovi´c, G. Raˇcunarstvo 34 Dr.sc.
a
9
57432 Simi´c, J. Matematika 52 Dr.sc.
Gusti primarni indeks
MAT BR Pointer na zapis
12453 a
1
16752 a
2
27453 a
3
34276 a
4
37564 a
5
43257 a
6
45643 a
7
56321 a
8
57432 a
9
Sekundarni indeks za DOB
DOB Pointer na zapis
21-30 a
2
, a
7
31-40 a
1
, a
3
, a
6
, a
8
41-50 a
5
51-65 a
4
, a
9
Sekundarni indeks za ODJEL
ODJEL Pointer na zapis
Fizika a
4
, a
7
Matematika a
1
, a
2
, a
6
, a
9
Raˇcunarstvo a
3
, a
5
, a
8
Sekundarni indeks za STUPANJ
STUPANJ Pointer na zapis
Dipl.inˇz a
2
, a
5
, a
7
Mr.sc. a
6
Dr.sc. a
1
, a
3
, a
4
, a
8
, a
9
Tabelarni prikaz 4.1: Invertirana organizacija datoteke.
Invertirani podaci mogli bi se u principu ispustiti iz osnovne datoteke. No to se obiˇcno ne radi,
zato da se ne bi troˇsilo vrijeme na ponovno sastavljanje zapisa.
44 4. FIZI
ˇ
CKA GRADA BAZE PODATAKA
Pristup na osnovu bilo kojeg podatka ostvaruje se tako da u odgovaraju´cem indeksu pronademo
zadanu vrijednost podatka, proˇcitamo popis pointera, te za svaki od pointera proˇcitamo zapis u os-
novnoj datoteci. Invertirana organizacija omogu´cuje i brz odgovor na pitanja o postojanju ili broju
zapisa sa zadanim svojstvima. Na primjer, promatramo upit: “Koliko nastavnika u odjelu Raˇcunarstvo
ima doktorat?” Odgovor nalazimo tako da u sekundarnim indeksima nademo skup pointera na nas-
tavnike iz Raˇcunarstva, odnosno skup pointera na doktore. U presjeku tih dvaju skupova nalaze se
samo dva pointera. Dakle odgovor smo dobili bez ˇcitanja osnovne datoteke.
Zapisi osnovne datoteke u proˇslom primjeru bili su prikovani jer su sekundarni indeksi sadrˇzavali
pointere-adrese. Prikovanost se moˇze izbje´ci ako pointere-adrese u sekundarnim indeksima zamijenimo
pointerima-vrijednostima kljuˇca. To ´ce olakˇsati aˇzuriranje i reorganizaciju osnovne datoteke, no usporit
´ce pristup na osnovu ne-kljuˇcnih podataka - naime stalno ´cemo morati pretraˇzivati primarni indeks da bi
vrijednosti kljuˇca prevodili u stvarne adrese. Na primjer, sekundarni indeks s pointerima-vrijednostima
kljuˇca za podatak ODJEL izgledao bi kao u Tabelarnom prikazu 4.2
Sekundarni indeks za ODJEL
ODJEL Pointer na zapis
Fizika 34276, 45643
Matematika 12453, 16752, 43257, 57432
Raˇcunarstvo 27453, 37564, 56321
Tabelarni prikaz 4.2: Sekundarni indeks s pointerima-vrijednostima kljuˇca.
Mana invertirane organizacije je utroˇsak memorije za indekse. No joˇs ve´ca mana je viˇsestruko
pove´canje posla prilikom svakog aˇzuriranja osnovne datoteke. Naime, kod svakog ubacivanja, izbaci-
vanja ili promjene zapisa u osnovnoj datoteci, mora se napraviti i korekcija u svakom od indeksa.
Zapisi u sekundarnom indeksu oblika (v, ¦p
1
, p
2
, p
3
, . . .¦) su varijabilne duljine. Oni se fiziˇcki
prikazuju kao viˇse zapisa fiksne duljine: (v, p
1
), (v, p
2
), (v, p
3
), . . . . Cijeli sekundarni indeks moˇze
biti priliˇcno glomazan, te se redovito fiziˇcki prikazuje kao B-stablo. Prikaz je sliˇcan onome za primarni
gusti indeks (vidi Potpoglavlje 4.2), s time da listovi stabla mogu sadrˇzavati viˇse parova oblika (v, p) s
istom vrijednoˇs´cu v. To zahtijeva da se definicija unutarnjih ˇcvorova B-stabla malo poop´ci.
4.3.2 Viˇsestruke vezane liste
Pristup na osnovu zadanog ne-kljuˇcnog podatka A moˇzemo ubrzati tako da sve zapise osnovne datoteke
s istim vrijednostima za A poveˇzemo u vezanu listu. Veza se ostvaruje pomo´cu pointera kojeg smo
uklopili u zapis kao dodatni podatak. Potreban nam je joˇs i takozvani indeks listi za podatak A - to
je mala (pomo´cna) datoteka sastavljena od zapisa oblika (v, p), gdje je v vrijednost za A, a p je pointer
na poˇcetak odgovaraju´ce vezane liste zapisa u osnovnoj datoteci.
Ukoliko sve ovo uˇcinimo za viˇse ne-kljuˇcnih podataka, imat ´cemo viˇse indeksa listi, a jedan zapis
osnovne datoteke imat ´ce viˇse uklopljenih pointera te ´ce istovremeno biti ukljuˇcen u viˇse vezanih listi.
U Tabelarnom prikazu 4.3 ponovo se vidi primjer datoteke nastavnika. No sada su uvedene vezane
liste za podatke ODJEL i STUPANJ. U skladu s time, pojavljuju se odgovaraju´ci indeksi listi.
Organizacija pomo´cu vezanih listi pogodna je onda kad su upiti unaprijed fiksirani i svode se
na zadavanje vrijednosti samo jednog podatka. Na primjer: “Ispiˇsi imena svih nastavnika iz odjela
Raˇcunarstvo”, ili “Ispiˇsi imena svih doktora”. Prednost u odnosu na invertiranu organizaciju je manji
i jednostavniji indeks, u kojem nema viˇsestrukih vrijednosti podataka.
Vezane liste su manje pogodne onda kad su u upitu zadane vrijednosti za viˇse podataka. Na primjer,
odgovor na upit “Ispiˇsi imena doktora iz odjela Raˇcunarstvo” moˇze se dobiti na dva naˇcina:
• ˇcitamo vezanu listu doktora i uvaˇzimo samo one koji su iz odjela Raˇcunarstvo,
• ˇcitamo vezanu listu nastavnika iz odjela Raˇcunarstvo i uvaˇzimo samo one koji su doktori.
U oba sluˇcaja proˇcitat ´cemo viˇse zapisa nego ˇsto ih ima u odgovoru. Od dvije vezane liste bolje je
odabrati kra´cu - zato je zgodno ako u indeksu listi piˇse i duljina svake liste.
Organizacija pomo´cu vezanih listi zahtijeva izuzetno mnogo posla prilikom aˇzuriranja osnovne da-
toteke. Da bi ubacili, izbacili ili promijenili zadani zapis u osnovnoj datoteci, potrebno je prekrojiti
nekoliko vezanih listi, a to se moˇze ostvariti jedino tako da prodemo svim tim listama te promijenimo
i razne druge zapise osim zadanog. Koji put se takoder mora obaviti korekcija u indeksu listi.
4.3. PRISTUP NA OSNOVU DRUGIH PODATAKA 45
Osnovna datoteka o nastavnicima
MAT BR IME ODJEL DOB STUPANJ Pointer Pointer
za ODJEL za STUPANJ
a
1
12453 Mati´c, R. Matematika 35 Dr.sc. a
2
a
3
a
2
16752 Pavi´c, D. Matematika 26 Dipl.inˇz. a
6
a
5
a
3
27453 Horvat, I. Raˇcunarstvo 37 Dr.sc. a
5
a
4
a
4
34276 Dimi´c, J. Fizika 55 Dr.sc. a
7
a
8
a
5
37564 Kati´c, K. Raˇcunarstvo 45 Dipl.inˇz. a
8
a
7
a
6
43257 Radi´c, M. Matematika 32 Mr.sc. a
9
-
a
7
45643 Jani´c, Z. Fizika 24 Dipl.inˇz. - -
a
8
56321 Popovi´c, G. Raˇcunarstvo 34 Dr.sc. - a
9
a
9
57432 Simi´c, J. Matematika 52 Dr.sc. - -
Indeks listi za ODJEL
ODJEL Pointer na poˇcetak
vezane liste
Fizika a
4
Matematika a
1
Raˇcunarstvo a
3
Indeks listi za STUPANJ
STUPANJ Pointer na poˇcetak
vezane liste
Dipl.inˇz a
2
Mr.sc. a
6
Dr.sc. a
1
Tabelarni prikaz 4.3: Organizacija datoteke s viˇsestrukim vezanim listama.
4.3.3 Podijeljena hash funkcija
Rijeˇc je o poop´cenju hash organizacije iz Potpoglavlja 4.2, s time da hash funkcija osim kljuˇca uzima
kao argument i ne-kljuˇcne podatke. Pretpostavimo da se redni broj pretinca moˇze izraziti kao niz od
B bitova. Postupamo na sljede´ci naˇcin.
• Podijelimo B bitova u skupine: b
1
bitova za podatak A
1
, b
2
bitova za podatak A
2
, . . . , b
r
bitova
za podatak A
r
.
• Zadamo pogodne “male” hash funkcije h
i
(v
i
), i = 1, 2, . . . , r, gdje h
i
preslikava vrijednost v
i
podatka A
i
u niz od b
i
bitova.
• Redni broj pretinca za zapis u kojem je A
1
= v
1
, A
2
= v
2
, . . . , A
r
= v
r
zadaje se spajanjem
malih nizova bitova, Dakle: h(v
1
, v
2
, . . . , v
r
) = h
1
(v
1
)[h
2
(v
2
)[ . . . [h
r
(v
r
). Ovdje je [ oznaka za
“lijepljenje” nizova bitova.
Doprinos jednog podatka u razdijeljenoj hash funkciji treba biti proporcionalan s veliˇcinom domene tog
podatka i s frekvencijom njegovog pojavljivanja u upitima. Dakle, ve´ca domena ili ˇceˇs´ce pojavljivanje
u upitima zahtijeva ve´ci broj bitova.
Kao primjer, promatramo zapise o studentima fakulteta i ˇzelimo ih spremati u hash datoteku s
1024 (= 2
10
) pretinaca. Definicija tipa zapisa u jeziku C izgleda ovako:
typedef struct ¦
int SNO;
char SNAME[20];
enum ¦1,2,3,4¦ LEVEL;
enum ¦M,F¦ GENDER;
¦ STUDENT;
Podijelimo 10 bitova u rednom broju pretinca na sljede´ci naˇcin: 4 bita za SNO, 3 bita za SNAME, 2
bita za LEVEL, 1 bit za GENDER. Zadajemo sljede´ce hash funkcije, gdje su v
1
, v
2
, v
3
, v
4
vrijednosti za
SNO, SNAME, LEVEL, GENDER:
h
1
(v
1
) = v
1
% 16 (ostatak kod dijeljenja s 16),
h
2
(v
2
) = (broj znakova u v
2
koji su razliˇciti od bjeline) % 8,
46 4. FIZI
ˇ
CKA GRADA BAZE PODATAKA
h
3
(v
3
) = v
3
− 1,
h
4
(v
4
) = (0 za v
4
jednak M, 1 inaˇce).
Tada je redni broj pretinca za zapis (58651, Smith, 3, M) zadan s (1101[101[10[0)
2
= (748)
10
.
Da bi pronaˇsli zapis (ili viˇse njih) u kojem je A
1
= v
1
, A
2
= v
2
, . . . , A
r
= v
r
, raˇcunamo redni
broj pretinca h(v
1
, v
2
, . . . , v
r
) i sekvencijalno pretraˇzimo taj jedan pretinac. Ako u upitu nije fiksirana
vrijednost podatka A
i
, tada b
i
bitova u rednom broju pretinca ostaje nepoznato, a broj pretinaca koje
moramo pretraˇziti pove´cava se 2
bi
puta.
ˇ
Sto manje vrijednosti za A
1
, A
2
, . . . , A
r
je poznato, to ´ce biti
ve´ci broj pretinaca koje moramo pretraˇziti.
Na primjer, ako traˇzimo sve muˇske studente na drugoj godini, tada su nam u rednom broju pretinca
poznata zadnja 3 bita: 010, no prvih 7 bitova je nepoznato. Treba pretraˇziti 2
7
= 128 pretinaca, dakle
1/8 datoteke.
Prednost podijeljene hash funkcije u odnosu na invertiranu datoteku je da se ne troˇsi dodatni prostor
za indekse. Takoder, operacije ubacivanja, izbacivaja i promjene zapisa su znatno jednostavnije budu´ci
da nema indeksa koje treba odrˇzavati. No traˇzenje zapisa u kojem su specificirane vrijednosti samo
nekih od podataka traje dulje nego kod invertirane organizacije. Smatra se da je organizacija pomo´cu
podijeljene hash funkcije dobra za datoteke koje nisu prevelike i ˇciji sadrˇzaj se ˇcesto mijenja.
5
IMPLEMENTACIJA
RELACIJSKIH OPERACIJA
5.1 Implementacija prirodnog spoja
Gradivo izloˇzeno u Poglavlju 4 uglavnom predstavlja “statiˇcki” aspekt fiziˇcke organizacije baze po-
dataka. No, kod relacijskih baza teˇziˇste je baˇceno na “dinamiˇcki” aspekt, koji se svodi na izvrednjavanje
izraza u relacijskoj algebri. Stoga, da bi bolje razumjeli ˇsto se sve deˇsava unutar jednog relacijskog
DBMS-a, potrebno je prouˇciti kako se fiziˇcki odvija izvrednjavanje algebarskog izraza. Osnovni korak
je izvrednjavanje pojedine algebarske operacije. Raspravljat ´cemo o implementaciji triju najvaˇznijih
operacija: prirodnog spoja (ovo potpoglavlje), te selekcije i projekcije (idu´ce potpoglavlje). U zadnjem
potpoglavlju re´ci ´cemo neˇsto o optimalnom izvrednjavanju cijelog izraza.
Promatramo relacije R
1
(A, B) i R
2
(B, C) sa zajedniˇckim atributom B. Oznaˇcimo sa S(A, B, C)
prirodni spoj od R
1
i R
2
. Svaka od ovih triju relacija fiziˇcki se prikazuje jednom (istoimenom) da-
totekom; n-torke se pretvaraju u zapise, a atributi u istoimene osnovne podatke. Razmotrit ´cemo
nekoliko naˇcina kako da se pomo´cu datoteki R
1
i R
2
generira datoteka S.
5.1.1 Algoritam ugnijeˇzdenih petlji
To je oˇcigledan, makar ne nuˇzno i najefikasniji naˇcin. Osnovna ideja je sljede´ca.
inicijaliziraj praznu S;
uˇcitaj prvi zapis iz R
1
;
dok ( nismo preˇsli kraj od R
1
) ¦
uˇcitaj prvi zapis iz R
2
;
dok ( nismo preˇsli kraj od R
2
) ¦
ako ( teku´ci zapisi iz R
1
i R
2
sadrˇze istu vrijednost za B )
stvori kombinirani zapis i ispiˇsi ga u S;
pokuˇsaj uˇcitati idu´ci zapis iz R
2
;
¦
pokuˇsaj uˇcitati idu´ci zapis iz R
1
;
¦
Za svaki zapis iz R
1
moramo iznova sekvencijalno ˇcitati cijelu datoteku R
2
. Algoritam se moˇze
poboljˇsati tako da u glavnu memoriju uˇcitamo segment od ˇsto viˇse blokova iz R
1
. Preinaˇcimo petlje tako
da usporedujemo svaki zapis uˇcitan iz R
2
sa svakim zapisom iz R
1
koji je trenutno u glavnoj memoriji.
Nakon ˇsto smo proˇcitali cijelu R
2
i obavili sva potrebna usporedivanja, uˇcitamo idu´ci segment od R
1
u glavnu memoriju te ponavljamo postupak. R
1
se oˇcigledno ˇcita samo jednom. R
2
se ˇcita onoliko
puta koliko ima segmenata u R
1
. Poboljˇsana verzija algoritma osobito je dobra onda kad je jedna od
datoteki dovoljno mala da cijela stane u glavnu memoriju. Tada se i R
1
i R
2
ˇcitaju samo jednom.
47
48 5. IMPLEMENTACIJA RELACIJSKIH OPERACIJA
5.1.2 Algoritam zasnovan na sortiranju i saˇzimanju
Pretpostavimo da su datoteke R
1
i R
2
uzlazno sortirane po zajedniˇckom podatku B. Tada u R
1
i u R
2
moˇzemo uoˇciti skupine uzastopnih zapisa s istom vrijednoˇs´cu za B. Datoteka S koja sadrˇzi prirodni
spoj od R
1
i R
2
lagano se moˇze generirati sljede´cim algoritmom koji podsije´ca na klasiˇcno saˇzimanje.
inicijaliziraj praznu S;
uˇcitaj prvu skupinu zapisa iz R
1
;
uˇcitaj prvu skupinu zapisa iz R
2
;
dok ( nismo preˇsli kraj ni od R
1
ni od R
2
) ¦
ako ( teku´ca skupina zapisa iz R
1
sadrˇzi manju
vrijednost za B nego teku´ca skupina zapisa iz R
2
)
pokuˇsaj uˇcitati idu´cu skupinu zapisa iz R
1
;
inaˇce ako ( teku´ca skupina zapisa iz R
2
sadrˇzi
manju vrijednost za B nego teku´ca skupina zapisa iz R
1
)
pokuˇsaj uˇcitati idu´cu skupinu zapisa iz R
2
;
inaˇce ¦
svaki zapis iz teku´ce skupine iz R
1
kombiniraj sa svakim zapisom
iz teku´ce skupine iz R
2
te sve generirane zapise ispiˇsi u S;
pokuˇsaj uˇcitati idu´cu skupinu zapisa iz R
1
;
pokuˇsaj uˇcitati idu´cu skupinu zapisa iz R
2
;
¦
¦
Pretpostavili smo da su skupine zapisa iz R
1
odnosno R
2
s istom vrijednoˇs´cu za B dovoljno male
tako da stanu u glavnu memoriju. Pod ovakvim pretpostavkama se i R
1
i R
2
ˇcitaju samo jednom.
Ukoliko skupine ne stanu u glavnu memoriju, algoritam treba preraditi tako da uˇcitava segment po
segment od svake skupine. Segmenti jedne od datoteki ´ce se tada morati viˇse puta uˇcitavati.
Ako R
1
i R
2
nisu sortirane kao ˇsto se traˇzilo u opisanom algoritmu, tada ih najprije treba sortirati,
pa tek onda raˇcunati prirodni spoj. U literaturi postoje mnogi dobri algoritmi za sortiranje, no oni
obiˇcno predvidaju da cijela datoteka stane u glavnu memoriju. Da bi sortirali ve´cu datoteku, dijelimo
je na segmente koji stanu u glavnu memoriju, posebno sortiramo svaki segment i ispisujemo ga natrag
u vanjsku memoriju. Dalje se sortirani segmenti postepeno saˇzimaju u sve ve´ce i ve´ce, sve dok na
kraju ne dobijemo cijelu sortiranu datoteku. Rijeˇc je o priliˇcno dugotrajnom postupku koji zahtijeva
viˇsestruko prepisivanje cijele datoteke. Dakle sortiranje polaznih R
1
i R
2
trajat ´ce znatno dulje nego
generiranje S od ve´c sortiranih R
1
i R
2
. Ipak, ako su R
1
i R
2
jako velike, cijeli postupak se isplati u
odnosu na algoritam ugnijeˇzdenih petlji.
5.1.3 Algoritam zasnovan na indeksu
Pretpostavimo da jedna od datoteki R
1
i R
2
, na primjer R
2
, ima sekundarni indeks za zajedniˇcki
podatak B. Tada se datoteka S, koja sadrˇzi prirodni spoj od R
1
i R
2
, moˇze generitati na sljede´ci
naˇcin.
inicijaliziraj praznu S;
uˇcitaj prvi zapis iz R
1
;
dok ( nismo preˇsli kraj od R
1
) ¦
pomo´cu indeksa pronadi i uˇcitaj sve zapise iz R
2
koji imaju istu vrijednost za B kao teku´ci zapis iz R
1
;
teku´ci zapis iz R
1
kombiniraj sa svakim od uˇcitanih
zapisa iz R
2
te generirane zapise ispiˇsi u S;
pokuˇsaj uˇcitati idu´ci zapis iz R
1
;
¦
Algoritam jednom proˇcita cijelu R
1
. No iz R
2
se neposredno ˇcitaju samo oni zapisi koji sudjeluju
u prirodnom spoju. To moˇze dovesti do znaˇcajne uˇstede u obimu posla. Ako i R
1
i R
2
imaju indeks
za B, tada treba sekvencijalno ˇcitati manju datoteku, a koristiti indeks ve´ce datoteke.
5.1. IMPLEMENTACIJA PRIRODNOG SPOJA 49
5.1.4 Algoritam zasnovan na hash funkciji i razvrstavanju
Zadajemo hash funkciju h koja ovisi o zajedniˇckom podatku B. Kombinacija zadanog zapisa iz datoteke
R
1
sa zadanim zapisom iz datoteke R
2
pojavljuje se u prirodnom spoju S ako i samo ako oba zadana
zapisa imaju jednaku vrijednost za B. Zato hash funkcija za oba takva zapisa daje istu vrijednost.
Razvrstavanjem zapisa iz R
1
i R
2
u skupine onih s bliskom vrijednoˇs´cu h lakˇse ´cemo odrediti koji
parovi zapisa se mogu kombinirati.
Korak 1:
`
·
`
·
`
·
interval 1
interval 2
interval 3
P − 1
2
1
0
Korak 2:
R1
R1,3
R1,2
R1,1
>
>
>
>
>
>

h() u
intervalu 3
h() u
intervalu 2
h() u
intervalu 1
Korak 3:
R2
R2,3
R2,2
R2,1
>
>
>
>
>
>

h() u
intervalu 3
h() u
intervalu 2
h() u
intervalu 1
Korak 4:
R2,i
R1,i
S

`
`
`
`
`
`

glavna memorija
kombinacije
zapisa
Slika 5.1: Izvrednjavanje prirodnog spoja pomo´cu hash funkcije i razvrstavanja
Neka je R
1
manja od R
2
. Algoritam se tada sastoji od sljede´cih pet koraka. Pritom su koraci 1, 2,
3 i 4 ilustrirani na Slici 5.1.
1. Inicijaliziraj praznu datoteku S. Odaberi hash funkciju h. Podijeli ukupni raspon hash vrijednosti
na k podjednakih intervala. Pritom je k odabran tako da 1/k od datoteke R
1
stane u glavnu
memoriju.
2.
ˇ
Citaj sekvencijalno R
1
i razvrstaj njene zapise u k skupina (pomo´cnih datoteki) tako da jedna
skupina sadrˇzi sve zapise iz R
1
koje h preslikava u jedan od intervala. Ako je h zaista uniformna
hash funkcija, tada su sve skupine podjednako velike - znaˇci da jedna skupina stane u glavnu
memoriju.
3.
ˇ
Citaj sekvencijalno R
2
i razvrstaj njene zapise u k skupina (pomo´cnih datoteki), sliˇcno kao ˇsto
smo to napravili s datotekom R
1
.
4. Odaberi jedan od intervala za vrijednost h. Uˇcitaj u glavnu memoriju odgovaraju´cu skupinu
zapisa iz R
1
. Sekvencijalno ˇcitaj odgovaraju´cu skupinu zapisa iz R
2
. Kombiniraj teku´ci zapis iz
R
2
sa svim zapisima iz R
1
(u glavnoj memoriji) koji imaju jednaku vrijednost za B. Dobivene
kombinacije ispiˇsi u S.
50 5. IMPLEMENTACIJA RELACIJSKIH OPERACIJA
5. Ponovi korak 4, s time da odabereˇs novi interval za vrijednost od h. Ako smo u koraku 4 ve´c
obradili svaki od k intervala, tada je algoritam zavrˇsen.
Analizom algoritma lagano se vidi da se svaka od datoteki R
1
i R
2
ˇcita toˇcno dvaput.
Na kraju ovog potpoglavlja usporedit ´cemo ˇcetiri izloˇzena naˇcina za implementiranje prirodnog
spoja.
• Ako su datoteke R
1
i R
2
ve´c sortirane po zajedniˇckom podatku B, tada je najefikasniji algoritam
zasnovan na sortiranju i saˇzimanju.
• Ukoliko je jedna datoteka dovoljno mala da stane u glavnu memoriju, treba odabrati algoritam
ugnijeˇzdenih petlji.
• Ako je jedna datoteka znatno ve´ca od druge i ima odgovaraju´ci indeks, tada je najbolji algoritam
zasnovan na indeksu.
• Za velike datoteke R
1
i R
2
bez indeksa, najbolji je algoritam zasnovan na hash funkciji i razvrsta-
vanju.
Ovime nisu iscrpljeni svi sluˇcajevi. Op´cenito ne moˇzemo baˇs lako odrediti koji algoritam je najbolji,
ve´c to zahtijeva detaljnije procjene koje ovise o veliˇcini R
1
i R
2
, o veliˇcini glavne memorije, distribuciji
vrijednosti za B itd.
5.2 Implementacija selekcije, projekcije i ostalih operacija
Osim prirodnog spoja, najvaˇznije relacijske operacije su selekcija i projekcija. Izloˇzit ´cemo osnovne
ideje za implementaciju tih dviju operacija, a zatim ´cemo kratko napomenuti kako se implementiraju
ostale operacije.
5.2.1 Implementacija selecije
Zadana je relacija R i Booleovski uvjet B. R je fiziˇcki prikazana istoimenom datotekom, na standardni
naˇcin. Implementacija selekcije R where B ovisi o obliku uvjeta B, no obiˇcno se svodi na traˇzenje
zapisa u datoteci R sa zadanom vrijednoˇs´cu nekih podataka. Dakle, obiˇcno se radi o pristupu na osnovu
primarnog kljuˇca ili o pristupu na osnovu ostalih podataka. U poglavlju 4 ve´c smo opisali algoritme
za pristup. Sad ´cemo samo ukratko rezimirati ideje.
Naivni algoritam bio bi: sekvencijalno ˇcitanje cijele R i provjera svakog zapisa da li on zadovaljava
B. Ako je R velika, to traje predugo, pa teba izgraditi pomo´cne strukture podataka koje omogu´cuju di-
rektniji pristup do traˇzenih zapisa. Invertiranje datoteki pomo´cu indeksa je vjerojatno najfleksibilnija
metoda. Ve´cina danaˇsnjih relacijskih DBMS-a oslanja se na jednostavno organizirane datoteke nadop-
unjene sekundarnim indeksima koji su prikazani B-stablima (primarni gusti indeks je samo specijalni
sluˇcaj sekundarnog). Rjede se koriste hash organizacije i viˇsestruke vezane liste. Neki oblici uvjeta
B zahtijevaju da u R traˇzimo zapise gdje vrijednost zadanog podatka nije fiksirana, ve´c se kre´ce u
zadanom intervalu. Primijetimo da indeks-B-stablo podrˇzava ovakvo intervalno pretraˇzivanje, budu´ci
da je u njemu saˇcuvan sortirani redoslijed zapisa po dotiˇcnom podatku. Hash organizacija ne podrˇzava
intervalno pretraˇzivanje.
5.2.2 Implementacija projekcije
Zadana je relacija R i njen atribut A. R je fiziˇcki prikazana istoimenom datotekom na standardni naˇcin.
Da bi generirali datoteku koja odgovara projekciji S = R[A], oˇcito treba proˇcitati cijelu datoteku R i
izdvojiti sve vrijednosti podatka A koje se pojavljuju. No ista vrijednost za A moˇze se pojaviti viˇse
puta. Osnovni problem implementiranja projekcije je: kako u S eliminirati zapise-duplikate?
Najjednostavniji algoritam za implementaciju projekcije zasnovan je na ugnijeˇzdenim petljama.
Vanjska petlja ˇcita datoteku R, a unutraˇsnja petlja prolazi trenutno stvorenim dijelom datoteke S:
5.3. OPTIMALNO IZVREDNJAVANJE ALGEBARSKOG IZRAZA 51
inicijaliziraj praznu S;
uˇcitaj prvi zapis iz R;
dok ( nismo preˇsli kraj od R ) ¦
duplikat = 0;
uˇcitaj prvi zapis iz S;
dok ( nismo preˇsli kraj od S i duplikat==0 ) ¦
ako ( teku´ci zapisi iz R i S sadrˇze istu vrijednost za A ) duplikat = 1;
pokuˇsaj uˇcitati idu´ci zapis iz S;
¦
ako ( duplikat == 0 )
prepiˇsi vrijednost za A iz teku´ceg zapisa iz R na kraj od S kao novi zapis;
pokuˇsaj uˇcitati idu´ci zapis iz R;
¦
Ako je R velika, algoritam s ugnijeˇzdenim petljama zahtijeva previˇse vremena. Tada je bolje
postupiti na sljede´ci naˇcin: izdvojiti sve vrijednosti za A koje se pojavljuju u R te zatim sortirati niz
izdvojenih vrijednosti. U sortiranom nizu duplikati ´ce se pojavljivati jedan izad drugoga, pa ih je lako
eliminirati jednim sekvencijalnim ˇcitanjem. Druga ideja je: razvrstati izdvojene vrijednosti za A u
skupine pomo´cu hash funksije. Duplikati ´ce se tada na´ci u istoj skupini, pa ih je opet lako eliminirati.
5.2.3 Implementacija ostalih operacija.
Kartezijev produkt dviju relacija R
1
i R
2
implementira se ugnijeˇzdenom petljom. Bolji algoritam nije
mogu´c jer se ionako svaki zapis iz datoteke R
1
mora kombinirati sa svakim zapisom iz datoteke R
2
.
Unija dviju relacija R
1
i R
2
implementira se na oˇcigledni naˇcin, s time da, sliˇcno kao kod projekcije,
treba eliminirati zapise-duplikate. Opet pomaˇze sortiranje datoteke R
1
i R
2
, ili koriˇstenje hash funkcije.
Presjek dviju relacija moˇze se shvatiti kao specijalni sluˇcaj prirodnog spoja gdje su svi atributi
zajedniˇcki. Zato algoritmi za raˇcunanje presjeka liˇce na one za raˇcunanje prirodnog spoja. Implemen-
tiranje skupovne razlike je takoder sliˇcno.
Daljnji relacijski operatori mogu se izraziti pomo´cu ve´c razmatranih, pa se oni obiˇcno ne imple-
mentiraju zasebno.
5.3 Optimalno izvrednjavanje algebarskog izraza
Relacijski DBMS interno reprezentira korisnikov upit kao izraz u relacijskoj algebri. U potpoglavlju 3.4
govorili smo o viˇsoj (logiˇckoj) razini optimizacije upita, koji se svodi na preformuliranje izraza u oblik
ekvivalentan polaznom ali pogodniji sa stanoviˇsta izvrednjavanja. U ovom potpoglavlju govorimo o
niˇzoj (fiziˇckoj) razini optimizacije, koja se svodi na izbor dobrih algoritama za izvrednjavanje izraza
dobivenog nakon “logiˇcke” faze.
Izvrednjavanje izraza oˇcito se svodi na izvrednjavanje svake od osnovnih operacija. Obiˇcno je rijeˇc
o operacijama prirodnog spoja, selekcije, projekcije, te moˇzda o joˇs ponekoj. Za svaku od osnovnih
operacija DBMS raspolaˇze s nekoliko algoritama. Takoder, DBMS-u su poznati parametri kao ˇsto su:
kardinalnost relacija (datoteki), veliˇcina glavne memorije, postojanje ili nepostojanje odgovaraju´cih
indeksa, i sliˇcno. Sluˇze´ci se tim parametrima, DBMS za zadanu operaciju i svaki od raspoloˇzivih
algoritama procjenjuje vrijeme potrebno da se ta operacija izvrˇsi tim algoritmom. Procjene se dobi-
vaju na osnovu ugradenih heuristiˇckih pravila. DBMS zatim za zadanu operaciju odabire algoritam s
najmanjim procijenjenim vremenom.
Osim ovakve izolirane optimizacije pojedinih operacija, suvremeni DBMS-i nastoje takoder proma-
trati i izraz kao cjelinu, te otkriti daljnje mogu´cnosti za uˇstedu posla. Na primjer, zamislimo da treba
izvrijedniti izraz:
( (R
1
join R
2
) join (R
3
where A = 10) ) [A, B] .
Tada nije potrebno do kraja izraˇcunati prvi prirodni spoj prije nego ˇsto poˇcnemo raˇcunati drugi
prirodni spoj te zatim projekciju. Umjesto toga, svaki puta kad proizvedemo novu n-torku iz (R
1
join
R
2
), proslijedimo je odmah da bude spojena sa selektiranim n-torkama iz R
3
, a rezultiraju´ce n-torke se
52 5. IMPLEMENTACIJA RELACIJSKIH OPERACIJA
odmah projiciraju na atribute A i B. Ovakva “pipeline” strategija moˇze rezultirati velikim uˇstedama
u vremenu, budu´ci da se privremene relacije ne moraju spremati u vanjsku memoriju ni ponovo ˇcitati.
I na logiˇckom i na fiziˇckom nivou optimizacije upita relacijski DBMS donosi odluke sluˇze´ci se
ugradenim “znanjem”. U tom smislu, relacijski DBMS predstavlja primjer ekspertnog sustava, dakle
radi se o softveru s osobinama umjetne inteligencije. Pravila za donoˇsenje odluka nisu ni izdaleka
savrˇsena, te su predmet daljnjeg intenzivnog istraˇzivanja.
6
INTEGRITET I SIGURNOST
PODATAKA
6.1
ˇ
Cuvanje integriteta
Poglavlje 6 posve´ceno je raznim aspektima integriteta i sigurnosti podataka. Rijeˇc je o problemima
ˇcije rjeˇsavanje je nuˇzno da bi velika viˇsekorisniˇcka baza podataka mogla uspjeˇsno funkcionirati. U
ovom potpoglavlju bavimo se ˇcuvanjem integriteta baze. Pod time se misli na ˇcuvanje korektnosti
i konzistentnosti podataka. Integritet se lako moˇze naruˇsiti na primjer pogreˇsnim upisom neopeznih
korisnika ili pogreˇsnim radom aplikacijskog programa.
Voljeli bismo kad bi se baza podataka mogla sama braniti od naruˇsavanja integriteta. U tu svrhu,
suvremeni DBMS-i dozvoljavaju projektantu baze da definira tzv. ograniˇcenja (constraints). Rijeˇc je
o uvjetima (pravilima) koje korektni i konzistentni podaci moraju zadovoljavati. Kod svake promjene
podataka DBMS ´ce automatski provjeravati da li su sva ograniˇcenja zadovoljena. Ako neko ograniˇcenje
nije zadovoljeno, tada DBMS ne´ce izvrˇsiti traˇzenu promjenu, ve´c ´ce poslati poruku o greˇski.
6.1.1 Ograniˇcenja kojima se ˇcuva integritet domene
Izraˇzavaju ˇcinjenicu da vrijednost atributa mora biti iz zadane domene. Zahtjev da vrijednost pri-
marnog atributa ne smije biti prazna takoder spada u ovu kategoriju.
Uzmimo na primjer da u relaciji STUDENT postoji atribut DOB. Tada bi ograniˇcenje moglo biti:
“Vrijednost za DOB je cijeli broj izmedu 10 i 60”. U ve´cini DBMS-a orijentiranih na SQL, ograniˇcenje
na integritet domene prvenstveno se izraˇzava time ˇsto se u naredbi CREATE atributu pridruˇzi tip
(uz eventualnu klauzulu NOT NULL). Popis podrˇzanih tipova obiˇcno nije velik (standardno to su
char-stringovi fiksirane duljine, brojevi s fiksnom toˇckom, cijeli brojevi, brojevi s plivaju´com toˇckom,
datumi, . . . ). Zato na taj naˇcin obiˇcno ne´cemo biti u mogu´cnosti da precizno izrazimo naˇse ograniˇcenje.
Na primjer, morat ´cemo zadati da je DOB tipa SMALLINT. DBMS ´ce tada automatski sprijeˇciti
upis vrijednosti 12.5 za DOB, ali ´ce propustiti -5. Integritet domene tada se u potpunosti moˇze ˇcuvati
jedino tako da ugradimo kontrole u naˇs aplikacijski program. Neki DBMS-i omogu´cuju da se unutar
naredbe CREATE ugradi i precizniji uvjet kojeg vrijednosti zadanog tipa moraju zadovoljavati da
bi mogle biti vrijednosti dotiˇcnog atributa. Kod takvih DBMS-a mogli bi u potpunosti zadati naˇse
ograniˇcenje za DOB: deklarirali bi da je DOB tipa SMALLINT, uz dodatni uvjet: (DOB >= 10)
AND (DOB <= 60).
6.1.2 Ograniˇcenja kojima se ˇcuva integritet unutar relacije
ˇ
Cuva se korektnost veza izmedu atributa unutar relacije (na primjer funkcionalne ovisnosti). Najvaˇzniji
primjer takvog ograniˇcenja je ono koje traˇzi da dvije n-torke unutar iste relacije ne smiju imati jednaku
vrijednost kljuˇca.
Stariji DBMS-i orijentirani na SQL nisu pruˇzali mogu´cnost da se direktno izrazi svojstvo kljuˇca.
Postojao je doduˇse jedan zaobilazni naˇcin - UNIQUE indeks. Noviji standardi za SQL predvidaju
klauzulu PRIMARY KEY odnosno UNIQUE unutar naredbe CREATE, ˇsto znaˇci da se traˇzeno
ograniˇcenje za kljuˇc moˇze eksplicitno zadati. Na primjer:
53
54 6. INTEGRITET I SIGURNOST PODATAKA
CREATE TABLE STUDENT
(SNO INTEGER NOT NULL,
SNAME CHAR(20),
LEVEL SMALLINT,
PRIMARY KEY(SNO));
CREATE TABLE COURSE
(CNO INTEGER NOT NULL,
TITLE CHAR(40),
LNAME CHAR(20),
PRIMARY KEY(CNO));
Nakon ovih definicija, DBMS ne´ce dozvoliti da se u relaciju STUDENT upiˇsu dvije n-torke s istim
SNO, niti da se u relaciju COURSE upiˇsu dvije n-torke s istim CNO.
6.1.3 Ograniˇcenja kojima se ˇcuva referencijalni integritet
ˇ
Cuva se korektnost i konzistentnost veza izmedu relacija. Uglavnom je rijeˇc o ograniˇcenjima koja se
odnose na strani kljuˇc, dakle na atribut u jednoj relaciji koji je ujedno primarni kljuˇc u drugoj relaciji.
Svaka vrijednost takvog atributa u prvoj relaciji mora biti prisutna i u drugoj relaciji.
Stariji DBMS-i orijentirani na SQL nisu pruˇzali mogu´cnost da se izrazi svojstvo stranog kljuˇca.
Odgovaraju´cu provjeru morao je obavljati aplikacijski program. Noviji standardi za SQL predvidaju
klauzulu FOREIGN KEY u naredbi CREATE, kojom se zadaje odgovaraju´ce ograniˇcenje. Na
primjer, u kontekstu prethodnih definicija, moˇzemo dalje pisati:
CREATE TABLE REPORT
(SNO INTEGER NOT NULL,
CNO INTEGER NOT NULL,
MARK SMALLINT,
PRIMARY KEY(SNO,CNO),
FOREIGN KEY(SNO) REFERENCES STUDENT,
FOREIGN KEY(CNO) REFERENCES COURSE);
Nakon ovih definicija DBMS ne´ce dozvoliti da se naruˇsi referencijalni integritet za tri tabele. Na prim-
jer, u REPORT se ne´ce mo´ci upisati n-torka s vrijednoˇs´cu SNO koja se ne pojavljuje u STUDENT. Ili
na primjer, iz COURSE se ne´ce mo´ci brisati n-torka s vrijednoˇs´cu CNO koja se pojavljuje u REPORT.
Izbor ograniˇcenja u danaˇsnjim DBMS-ima ipak nije dovoljan da izrazi sva mogu´ca pravila in-
tegriteta. Takoder, mogu´cnosti pojedinih DBMS-a se razlikuju. Ipak, danaˇsnji DBMS-i u tom pogledu
su znatno napredniji od onih prije 15-tak godina. Treba biti svjestan da svako ograniˇcenje predstavlja
teret prilikom aˇzuriranja podataka (troˇsi se vrijeme na provjeru). Zato prilikom zadavanja ograniˇcenja
ne treba pretjerivati.
6.2 Istovremeni pristup
Ve´cina baza podataka po svojoj prirodi je viˇsekorisniˇcka. Znaˇci jedan te isti podatak, pohranjen
na jednom mjestu, potreban je raznim osobama i raznim aplikacijama, moˇzda ˇcak u isto vrijeme. Na
primjer, broj prodanih avionskih karata za isti let treba simultano biti dostupan raznim poslovnicama
avionske kompanije. Od DBMS-a se zato traˇzi da korisnicima omogu´ci istovremeni pristup do
podataka. Obiˇcno je rijeˇc o prividnoj istovremenosti (dijeljenje vremena istog raˇcunala). Ipak, DBMS
i u tom sluˇcaju mora paˇzljivo koordinirati konfliktne radnje. Svaki korisnik treba imati dojam da sam
radi s bazom.
6.2.1 Transakcije i serijalizabilnost
Rad korisnika s bazom podataka svodi se na pokretanje unaprijed definiranih procedura, tzv. transak-
cija. Makar jedna transakcija sa korisniˇckog stanoviˇsta predstavlja jednu nedjeljivu cjelinu, ona se
6.2. ISTOVREMENI PRISTUP 55
obiˇcno realizira kao niz od nekoliko elementarnih zahvata u samoj bazi. Na primjer, za avionsku kom-
paniju prodaja jedne avionske karte moˇze predstavljati jednu transakciju. U sklopu jedne karte obiˇcno
je ukljuˇceno viˇse letova (prelasci, povratak), pa to povlaˇci nekoliko operacija upisa u bazu.
Osnovno svojstvo transakcije je da ona prevodi bazu iz jednog konzistentnog stanja u drugo. No
medu-stanja, koja nastaju nakon pojedinih operacija unutar transakcije, mogu biti nekonzistentna. Da
bi se ˇcuvao integritet baze, transakcija mora u cijelosti biti izvrˇsena, ili uop´ce ne smije biti izvrˇsena.
Transakcija koja iz bilo kojeg razloga nije do kraja bila obavljena, mora biti neutralizirana - dakle
svi podaci koje je ona do trenutka prekida promijenila moraju natrag dobiti svoje polazne vrijednosti.
U SQL-u se poˇcetak transakcije odreduje implicitno ili posebnom naredbom, dok zavrˇsetak (i naˇcin
zavrˇsetka) mora eksplicitno biti zadan. Sljede´ci nizovi SQL naredbi predstavljaju uspjeˇsno izvrˇsenu
transakciju, odnosno neuspjeˇsnu i neutraliziranu transakciju:
BEGIN WORK ;
naredba 1 ;
naredba 2 ;
. . . . . . ;
naredba k ;
COMMIT WORK ;
odnosno
BEGIN WORK ;
naredba 1 ;
naredba 2 ;
. . . . . . ;
(greˇska) ;
ROLLBACK WORK ;
U viˇsekorisniˇckoj bazi deˇsavat ´ce se da se nekoliko transakcija izvodi paralelno. Osnovne operacije
koje pripadaju raznim trasakcijama tada ´ce se vremenski ispreplesti. Traˇzimo da uˇcinak tih transak-
cija bude isti kao da su se one izvrˇsavale sekvencijalno, dakle jedna iza druge u nekom (bilo kojem)
redoslijedu. Traˇzeno svojstvo, da uˇcinak istovremenog izvrˇsavanja transakcija mora biti ekvivalen-
tan nekom sekvencijalnom izvrˇsavanju, naziva se serijalizabilnost. Dakle, ukoliko to svojstvo zaista
vrijedi, kaˇzemo da je dotiˇcno paralelno izvrˇsavanje skupa transakcija bilo serijalizabilno. Sljede´ci
primjer s avionskom kompanijom pokazuje da se a priori ne moˇze garantirati serijalizabilnost, te da
nekontrolirano paralelno izvrˇsavanje transakcija moˇze dovesti do neˇzeljenih efekata.
Dva putnika istovremeno stiˇzu u dvije razliˇcite poslovnice avionske kompanije i traˇze kartu
za isti let istog dana. U tom trenutku postoji samo jedno slobodno sjedalo. Sluˇzbenici
sa svojih terminala pokre´cu dvije transakcije, T
1
i T
2
, koje DBMS “istovremeno” obavlja.
Dolazi do slijede´ceg vremenskog redoslijeda obavljanja elementarnih operacija.
1. T
1
uˇcitava iz baze broj slobodnih sjedala.
2. T
1
smanjuje proˇcitanu vrijednost s 1 na 0. Promjena je za sada uˇcinjena samo u radnoj
memoriji raˇcunala.
3. T
2
uˇcitava iz baze broj slobodnih sjedala. Budu´ci da je stanje baze joˇs uvijek nepromi-
jenjeno, uˇcitani broj je neaˇzuran, dakle 1.
4. T
2
smanjuje proˇcitanu vrijednost s 1 na 0. Promjena je opet uˇcinjena samo u radnoj
memoriji.
5. T
1
unosi u bazu promijenjenu vrijednost za broj slobodnih sjedala. Dakle u bazi sada
piˇse da nema slobodnih sjedala.
6. Sliˇcno i T
2
unosi u bazu svoju promijenjenu vrijednost za broj slobodnih sjedala. Dakle
u bazu se ponovo upisuje da nema slobodnih sjedala.
7. Budu´ci da je na poˇcetku svog rada naiˇsla na broj slobodnih sjedala ve´ci od 0, T
1
izdaje
putniku kartu.
8. Iz istih razloga i T
2
izdaje drugom putniku kartu.
Vidimo da je avionska kompanija prodala jednu kartu previˇse. Ili, drugim rijeˇcima, dva
putnika sjede na istom sjedalu.
Ozbiljni DBMS ne smije dopustiti slijed dogadaja iz prethodnog primjera, dakle DBMS u svakom
trenutku mora garantirati serijalizabilnost. Znaˇci, jedan (bilo koji) putnik trebao je dobiti kartu,
dok je drugi trebao dobiti obavijest da viˇse nema slobodnih mjesta. Zato je potrebna neka vrsta
kontrole (koordinacije) istovremenog izvrˇsavanja transakcija. Razni DBMS-i to rade na razne naˇcine.
Uobiˇcajena tehnika zasniva se na lokotima.
56 6. INTEGRITET I SIGURNOST PODATAKA
6.2.2 Lokoti i zakljuˇcavanje
Lokoti su pomo´cni podaci koji sluˇze za koordinaciju konfliktnih tadnji. Baza je podijeljena na viˇse
dijelova, tako da jednom dijelu odgovara toˇcno jedan lokot. Transakcija koja ˇzeli pristupiti nekom
podatku najprije mora “uzeti” odgovaraju´ci lokot i time zakljuˇcati dotiˇcni dio baze.
ˇ
Cim je obavila
svoju operaciju, transakcija treba “vratiti” lokot i time otkljuˇcati podatke. Kad transakcija naide
na podatke koji su ve´c zakljuˇcani, ona mora ˇcekati dok ih prethodna transakcija ne otkljuˇca. Time se
zapravo izbjegava (sasvim) istovremeni pristup istom podatku.
Ovaj mehanizam dovoljan je da otkloni probleme iz proˇslog primjera. Zamislimo da sada obje
transakcije T
1
i T
2
zakljuˇcavaju podatak u bazi kojem misle pristupiti. Tada ´ce T
1
prva zakljuˇcati broj
slobodnih sjedala, a otkljuˇcat ´ce ga tek nakon ˇsto ga aˇzurira. T
2
´ce (nakon kratkog ˇcekanja) uˇcitati
ve´c aˇzuriranu vrijednost (0 slobodnih sjedala), pa drugi putnik ne´ce dobiti kartu. Znaˇci “istovremeno”
izvrˇsavanje T
1
i T
2
sada je serijalizabilno.
Veliˇcina dijela baze kojem je pridruˇzen jedan lokot odreduje zrnatost zakljuˇcavanja (granularity).
ˇ
Sto je zrno krupnije, to je kontrola zakljuˇcavanja jednostavnija za DBMS, no stupanj paralelnosti rada
je manji. Zrnatost suvremenih DBMS-a je obiˇcno reda veliˇcine n-torke ili bar fiziˇckog bloka.
Upotreba lokota krije u sebi i odredene opasnosti. Najve´ca od njih je mogu´cnost medusobne
blokade dviju ili viˇse transakcija (tzv. “deadlock”). Da bi toˇcnije objasnili o ˇcemu se radi, opet
´cemo se posluˇziti jednim zamiˇsljenim “scenarijem” vezanim uz naˇsu avionsku kompaniju.
Uzmimo da za zadani let i za svako sjedalo u avionu baza podataka pohranjuje ime put-
nika koji sjedi na tom sjedalu. Pretpostavimo da postoji transakcija kojom dva putnika
mogu zamijeniti sjedala (na primjer puˇsaˇc i nepuˇsaˇc). Zamislimo sada da su istovremeno
pokrenute dvije transakcije ovakve vrste, nazovimo ih T
1
i T
2
. Neka T
1
mijenja imena put-
nika na sjedalima 1 i 2, a T
2
obavlja istu zamjenu ali u suprotnom redoslijedu. Tada je
mogu´c slijede´ci naˇcin obavljanja elementarnih operacija.
1. T
1
zakljuˇca podatak o sjedalu 1 jer mu misli pristupiti.
2. Iz istih razloga T
2
zakljuˇca podatak o sjedalu 2.
3. T
1
traˇzi lokot za sjedalo 2, ali mora ˇcekati jer je T
2
ve´c zakljuˇcala dotiˇcni podatak.
4. Sliˇcno T
2
traˇzi lokot za sjedalo 1, ali mora ˇcekati jer je T
1
ve´c zakljuˇcala taj podatak.
Oˇcigledno ni T
1
ni T
2
viˇse ne mogu nastaviti rad - one ´ce vjeˇcno ˇcekati jedna drugu.
Software koji koristi lokote mora raˇcunati s upravo opisanom mogu´cnoˇs´cu blokade transakcija, te
mora osigurati da se ta blokada sprijeˇci ili prekine. Rjeˇsenje koje se danas najˇceˇs´ce koristi je sljede´ce.
Privremeno se dopuˇsta blokada, no povremeno se kontrolira da li ima blokiranih transakcija
(traˇzi se ciklus u usmjerenom grafu koji prikazuje koja transakcija ˇceka koju). Ukoliko takve
blokirane transakcije postoje, tada se jedna od njih prekida, neutralizira se njen dotadaˇsnji
uˇcinak, te se ona se ponovo starta u nekom kasnijem trenutku.
6.2.3 Dvofazni protokol zakljuˇcavanja
Na osnovu do sada pokazanih primjera, moglo bi se povjerovati da koriˇstenje lokota (uz izbjegavanje
blokade) daje garanciju za serijalizabilnost. To na ˇzalost nije toˇcno, a pogreˇsni utisak stekao se zato
ˇsto su primjeri bili suviˇse jednostavni. Naime, postoji mogu´cnost za nekorektno izvrˇsavanje istovre-
menih transakcija i onda kad se podaci zakljuˇcavaju. Da bi to pokazali, joˇs jednom ´cemo se posluˇziti
zamiˇsljenim “scenarijem” vezanim uz naˇsu avionsku kompaniju.
Opet promatramo transakciju kojomna zadanom letu dva putnika mijenjaju sjedala. Uzmimo
da su istovremeno pokrenute dvije identiˇcne transakcije, T
1
i T
2
, koje obje mijenjaju imena
putnika na istim sjedalima 1 i 2. Neka na poˇcetku na tim sjedalima sjede Ivan i Marko.
Tada je mogu´c slijede´ci redoslijed obavljanja elementarnih operacija.
1. T
1
zakljuˇca sjedalo 1, ˇcita ime Ivan i pamti ga kao prvo ime, te otkljuˇca sjedalo 1.
2. T
1
zakljuˇca sjedalo 2, ˇcita ime Marko i pamti ga kao drugo ime, te otkljuˇca sjedalo 2.
3. T
1
ponovo zakljuˇca sjedalo 1, upisuje mu zapam´ceno drugo ime (dakle Marko), te
otkljuˇca sjedalo 1.
6.3. OPORAVAK 57
4. T
2
zakljuˇca sjedalo 1, ˇcita ime Marko i pamti ga kao svoje prvo ime, te otkljuˇca sjedalo
1.
5. T
2
zakljuˇca sjedalo 2, ˇcita ime Marko i pamti ga kao svoje drugo ime, te otkljuˇca
sjedalo 2.
6. T
1
ponovo zakljuˇca sjedalo 2, upisuje mu zapam´ceno prvo ime (dakle Ivan), te otkljuˇca
sjedalo 2.
7. T
2
ponovo zakljuˇca sjedalo 1, upisuje mu svoje zapam´ceno drugo ime (dakle Marko),
te otkljuˇca sjedalo 1.
8. T
2
ponovo zakljuˇca sjedalo 2, upisuje mu svoje zapam´ceno prvo ime (dakle opet
Marko), te otkljuˇca sjedalo 2.
Vidimo da sada na oba sjedala sjedi Marko, a Ivana nema nigdje. Znaˇci opisani naˇcin
izvrˇsavanja transakcija T
1
i T
2
nije serijalizabilan. Naime, bilo koji sekvencijalni redoslijed
izvrˇsavanja proizveo bi dvostruku zamjenu, tj. Ivan bi opet bio na sjedalu 1, a Marko na
sjedalu 2.
Upravo navedeni primjer uvjerio nas je da zakljuˇcavanje podataka samo po sebi nije garancija za
serijalizabilnost. No sre´com, stvar se lagano moˇze spasiti. Dovoljno je od transakcija zahtijevati da
se pokoravaju nekom stroˇzem “pravilu ponaˇsanja”. Preciznije, moˇze se dokazati da vrijedi slijede´ca
tvrdnja.
Ako u svakoj od transakcija sva zakljuˇcavanja slijede prije prvog otkljuˇcavanja, tada proizvoljno
istovremeno izvrˇsavanje tih transakcija mora biti serijalizabilno.
Navedeno pravilo zove se dvofazni protokol zakljuˇcavanja. Naime, zakljuˇcavanja i otkljuˇcavanja
se zbivaju u dvije razdvojene faze tokom izvrˇsavanja transakcije.
Dvofazni protokol zakljuˇcavanja bit ´ce bolje razumljiv ukoliko se vratimo prethodnom primjeru s
dvostrukom zamjenom sjedala. Razlog zaˇsto transakcije T
1
i T
2
nisu korektno radile je baˇs taj ˇsto se
one nisu pokoravale protokolu. Zaista, obje su otkljuˇcavale podatke, pa ih zatim opet zakljuˇcavale.
Da bi bila u skladu sa protokolom, transakcija mora samo jednom zakljuˇcati podatak o sjedalu (prije
ˇcitanja), te ga samo jednom otkljuˇcati (nakon aˇzuriranja). U razdoblju izmedu ˇcitanja i aˇzuriranja
podatak mora ostati zakljuˇcan. Lako se uvjeriti da, uz ovu promjenu “ponaˇsanja”, redoslijed dogadaja
iz proˇslog primjera viˇse nije mogu´c. U najmanju ruku, koraci 5 i 6 morati ´ce zamijeniti redoslijed,
jer T
2
ne´ce mo´ci pristupiti sjedalu 2 dok ga T
1
nije aˇzurirala i otkljuˇcala. Obje transakcije tada ´ce
korektno obaviti svoj posao.
6.2.4 Vremenski ˇzigovi
Dvofazni protokol zakljuˇcavanja (uz izbjegavanje blokade) predstavlja primjer tehnike za koordinaciju
paralelnog izvrˇsavanja transakcija zasnovane na lokotima. No postoje i metode koje ne koriste lokote.
Kao primjer, kratko spominjemo tehniku zasnovanu na vremenskim ˇzigovima (time stamps).
Svakoj transakciji pridruˇzuje se identifikacijski broj, tzv. vremenski ˇzig.
ˇ
Citanja i promjene istog
podatka dozvoljavaju se samo ako se one odvijaju u redoslijedu vremenskih ˇzigova pripadnih transak-
cija. U sluˇcaju naruˇsavanja tog redoslijeda, jedna od transakcija mora se prekinuti, neutralizirati i
ponovo startati s ve´cim vremenskim ˇzigom. Na primjer, ako T
1
ima ˇzig t
1
, T
2
ima ˇzig t
2
> t
1
, T
1
ˇzeli
proˇcitati podatak x, a T
2
je ve´c mijenjala taj isti x, tada se T
1
mora neutralizirati.
Opisani naˇcin izvraˇsavanja transakcija garantira serijalizabilnost. Naime, ukupni uˇcinak svih transak-
cija je isti kao da se svaka od njih izvrˇsavala trenutaˇcno, u posebnom trenutku.
6.3 Oporavak
U toku svog rada, baza podataka moˇze se na´ci u “neispravnom” stanju. Razlozi koji mogu dovesti do
“oˇste´cenja” baze su:
• prekid transakcije (naredba ROLLBACK WORK, posljedica kontrole istovremenog rada, nes-
tanak struje, . . . );
• pogreˇsan rad same transakcije;
58 6. INTEGRITET I SIGURNOST PODATAKA
• greˇska u DBMS-u ili operacijskom sustavu;
• hardverska greˇska (na primjer kvar diska) ili ˇcak fiziˇcko uniˇstenje cijelog raˇcunala.
Od suvremenog DBMS-a oˇcekuje se da u svim ovim sluˇcajevima omogu´ci “oporavak” baze, dakle njen
povratak u stanje koje je ˇsto aˇzurnije i pritom joˇs uvijek konzistentno. Taj povratak bi se trebao
obavljati po mogu´cnosti automatski, ili bar na relativno jednostavan naˇcin. Da bi oporavak bio mogu´c,
DBMS osim same baze mora odrˇzavati joˇs i neka pomo´cna sredstva; tipiˇcno to su: rezervna kopija
baze (backup copy) i ˇzurnal datoteka (journal file, log file). Rezervna kopija i ˇzurnal datoteka
omogu´cuju razne vrste oporavka. Dva najvaˇznija oblika su: neutralizacija prekinute ili pogreˇsne
transakcije, te ponovno uspostavljanje baze nakon njenog znatnijeg oˇste´cenja.
6.3.1 Rezervna kopija baze
Dobiva se snimanjem cijele baze na drugi medij (magnetska traka ili drugi disk), i to u trenutku kad
smatramo da je baza u konzistentnom stanju. Za vrijeme kopiranja ne smije se obavljati nikakva
transakcija koja mijenja podatke. Stvaranje rezervne kopije je dugotrajna operacija koja ometa re-
dovni rad korisnika. Zato se kopiranje ne obavlja suviˇse ˇcesto, ve´c periodiˇcki u unaprijed predvidenim
terminima (na primjer jednom tjedno).
6.3.2
ˇ
Zurnal datoteka
Rijeˇc je o datoteci gdje je ubiljeˇzena “povijest” svake transakcije koja je mijenjala bazu nakon stvaranja
zadnje rezervne kopije. Za jednu transakciju ˇzurnal evidentira:
• identifikator transakcije,
• adresu svakog podatka kojeg je transakcija promijenila, zajedno s prethodnom vrijednoˇs´cu tog
podatka (pre-image) i novom vrijednoˇs´cu (post-image),
• kontrolne toˇcke (checkpoints) u napredovanju transakcije: toˇcka poˇcetka, toˇcka isporuke (commit)
odnosno odustajanja (rollback).
6.3.3 Neutralizacija jedne transakcije
Rijeˇc je o rutinskoj i vrlo ˇcestoj operaciji koju DBMS obiˇcno obavlja automatski. Primjenjuje se za
neutralizaciju transakcije koja je poˇcela pisati u bazu no nije doˇsla do kraja. Isti postupak mogao bi
se primijeniti za neutralizaciju ve´c dovrˇsene transakcije za koju se ustanovilo da je pogreˇsna. Svodi se
na to da se podacima koje je transakcija mijenjala vrate prethodne vrijednosti. Uobiˇcajeni postupak
naziva se odmotavanje unatrag (roll-back):
• ˇcita se ˇzurnal i pronalaze se stare vrijednosti (pre-images) podataka koje je transakcija mijenjala;
• te stare vrijednosti se ponovo upisuju na odgovaraju´ca mjesta u bazu.
Osim toga, ako je neka druga transakcija proˇcitala u bazi vrijednost unesenu od upravo neutralizirane
transakcije, tada treba i tu drugu transakciju neutralizirati (i ponovo startati). Detalji cijelog postupka
mogu biti dosta komplicirani i oni ovise o tome kako se obavlja koordinacija paralelnog rada viˇse
transakcija.
Stvari se bitno pojednostavnjuju ukoliko zamislimo da DBMS odjednom obavlja samo jednu transak-
ciju. Tada se neutralizacija prekinute transakcije elegantno rjeˇsava tzv. tehnikomodgodenog pisanja
(deferred write). Ta tehnika zahtijeva da se promjene podataka (nastale kao rezultat rada transakcije)
ne upisuju u bazu odmah, nego tek nakon ˇsto transakcija unese u ˇzurnal toˇcku isporuke. Znaˇci, rad
transakcije se odvija u dvije faze, kao ˇsto se vidi na Slici 6.1:
• transakcija upisuje u ˇzurnal sve promjene koje bi trebala napraviti u bazi, te nakon toga biljeˇzi
toˇcku isporuke;
• ˇcim je ubiljeˇzena toˇcka isporuke, DBMS prenosi odjednom sve promjene iz ˇzurnala u bazu.
Uz primjenu ove tehnike, problem neutralizcije prekinute transakcije postaje trivijalan. Naime
prekinuta transakcija ne uspijeva u ˇzurnal ubiljeˇziti toˇcku isporuke, pa stoga DBMS ne prenosi njene
promjene u bazu.
6.4. ZA
ˇ
STITA OD NEOVLA
ˇ
STENOG PRISTUPA 59
transakcija ˇzurnal

baza

promjene commit
Slika 6.1: Izvrˇsavanje transakcije primjenom tehnike odgodenog pisanja
6.3.4 Ponovno uspostavljanje baze
Rijeˇc je o izvanrednoj i opseˇznoj operaciji koja se pokre´ce na zahtjev administratora. Primjenjuje se
nakon znatnijeg oˇste´cenja baze ili u sluˇcaju njenog potpunog uniˇstenja. Svodi se na ponovni upis svih
podataka.
Uobiˇcajeni postupak naziva se odmotavanje prema naprijed (roll-forward). U ˇzurnalu moraju
biti upisane posebne kontrolne toˇcke koje oznaˇcavaju trenutke kad je baza joˇs bila konzistentna (obiˇcno
su to trenutci kad nije bilo aktivnih transakcija). Postupak je tada sljede´ci:
• uspostavlja se stanje baze zabiljeˇzeno zadnjom rezervnom kopijom (snimanje s magnetskih traka
na disk);
• odredi se zadnja (posebna) kontrolna toˇcka u ˇzurnalu;
• proˇcita se dio ˇzurnala od poˇcetka do zadnje kontrolne toˇcke;
• ponovo se unose u bazu promjene podataka (post-images), i to redom za svaku isporuˇcenu transak-
ciju iz promatranog dijela ˇzurnala.
Nakon ovoga, uspostavit ´ce se stanje baze koje odgovara zadnjoj (posebnoj) kontrolnoj toˇcki. To je
najbolje ˇsto moˇzemo uˇciniti.
6.4 Zaˇstita od neovlaˇstenog pristupa
Baza podataka mora biti zaˇsti´cena od nedopuˇstenih ili ˇcak zlonamjernih radnji. Osnovni vid zaˇstite je
fiziˇcko ograniˇcenje pristupa do samog raˇcunala. Dalje, ograniˇcava se udaljeni pristup do raˇcunala kroz
mreˇzu. No nas ovdje prvenstveno zanima finiji softverski vid zaˇstite, koji je ugraden u DBMS. Njime
se ljudima koji imaju mogu´cnost rada na dotiˇcnom raˇcunalu ograniˇcavaju mogu´cnosti rada s bazom.
6.4.1 Identifikacija korisnika
Uobiˇcajeno je da svaki korisnik baze ima svoje korisniˇcko ime (username) i lozinku (password). Da
bi smio raditi s bazom, korisnik se mora predstaviti DBMS-u navodenjem imena, te mora dokazati svoj
identitet navodenjem lozinke. DBMS raspolaˇze popisom korisniˇckih imena i pripadnih lozinki. Ukoliko
korisnik navede ime i lozinku koji ne odgovaraju popisu, DBMS mu ne dopuˇsta rad. Zaˇstita se zasniva
na tajnosti lozinke. DBMS se moˇze osloniti na imena i lozinke koji ve´c postoje u operacijskom sustavu
raˇcunala, ili se moˇze sluˇziti vlastitim popisom.
6.4.2 Pogledi kao mehanizam zaˇstite
U Poglavlju 1 spomenuli smo poglede (pod-sheme) kao sredstvo za postizavanje logiˇcke neovisnosti
podataka. No pogledi ujedno sluˇze i za zaˇstitu podataka. Naime, DBMS moˇze odredenom korisniku
pridruˇziti njegov pogled na bazu. Korisnik tada “vidi” samo dio baze, pa su time bitno ograniˇcene
njegove mogu´cnosti rada.
U relacijskom modelu, i globalna shema i pogled (pod-shema) zadaju se kao skup relacija. Pritom
se relacije koje ˇcine pogled izvode iz relacija koje ˇcine globalnu shemu. U SQL-u se relacija-pogled
zadaje naredbom CREATE VIEW, a izvodenje iz globalnih relacija opisuje se naredbom SELECT
koja je ugnijeˇzdena u CREATE VIEW.
U nastavku navodimo primjer globalne sheme i pripadnih pogleda kojima se povjerljivi podaci skri-
vaju od neovlaˇstenih korisnika. Cijelu bazu ˇcine dvije relacije, koje predstavljaju zaposlene u poduze´cu
i njihove odjele.
60 6. INTEGRITET I SIGURNOST PODATAKA
EMPLOYEE ( EMPNO, ENAME, ADDRESS, SALARY, DEPTNO )
DEPARTMENT ( DEPTNO, DNAME, MANAGERNO )
Poglede ´cemo opisati pomo´cu SQL naredbi CREATE VIEW.
Prvi pogled namijenjen je korisniku koji smije pristupiti podacima o zaposlenima, no ne i njihovim
pla´cama:
CREATE VIEW EMPVIEW1
AS SELECT EMPNO, ENAME, ADDRESS, DEPTNO
FROM EMPLOYEE ;
Korisnik vidi samo “vertikalni” segment relacije.
Drugi pogled namijenjen je korisniku koji smije pristupiti cijeloj n-torki o zaposlenima, no samo za
zaposlene u odjelu broj 3:
CREATE VIEW EMPVIEW2
AS SELECT *
FROM EMPLOYEE
WHERE DEPTNO = 3 ;
Korisnik vidi samo “horizontalni” segment relacije.
Tre´ci pogled sluˇzi za korisnika-menadˇzera. On smije pristupiti samo podacima o osobama koje su
zaposlene u njegovim odjelima:
CREATE VIEW EMPVIEW3
AS SELECT EMPLOYEE.EMPNO, EMPLOYEE.ENAME, EMPLOYEE.SALARY,
DEPARTMENT.DEPTNO, DEPARTMENT.DNAME
FROM EMPLOYEE, DEPARTMENT
WHERE EMPLOYEE.DEPTNO = DEPARTMENT.DEPTNO
AND DEPARTMENT.MANAGERNO = . . . (menadˇzerov identifikacijski broj) . . . ;
Korisnik vidi relaciju koja zapravo ne postoji u bazi, ve´c se dobiva kombiniranjem podataka iz pos-
toje´cih relacija.
6.4.3 Ovlaˇstenja
Pogled odreduje kako korisnik “vidi podatke”, no on ne odreduje ˇsto korisnik moˇze raditi s tim
podacima. Osim pogleda, DBMS uz korisnika veˇze njegova ovlaˇstenja (authorities). Uobiˇcajena
ovlaˇstenja u SQL-u su:
SELECT - ovlaˇstenje ˇcitanja podataka iz zadane relacije (pogleda);
INSERT - ovlaˇstenje ubacivanja novih n-torki u zadanu relaciju (pogled);
DELETE - ovlaˇstenje brisanja n-torki u zadanoj relaciji (pogledu);
UPDATE - ovlaˇstenje mijenjanja podataka u zadanoj relaciji (pogledu);
ALTER - ovlaˇstenje mijenjanja grade zadane relacije (na primjer, dodavanje novih atributa);
CONNECT - ovlaˇstenje korisniku raˇcunala da se smije prijaviti za rad s bazom;
DBA - ovlaˇstenje koje korisniku daje status administratora baze (i povlaˇci sva ostala ovlaˇstenja).
Neka korisnikova ovlaˇstenja zadaju se posebno za svaku relaciju (pogled), a neka se zadaju uni-
verzalno. Ovlaˇstenje UPDATE se kod nekih DBMS-a moˇze zadati posebno za svaki atribut. Na
primjer, menadˇzer koji koristi pogled EMPVIEW3 moˇze imati ovlaˇstenje SELECT za pogled EM-
PVIEW3, te ovlaˇstenje UPDATE za atribut SALARY u pogledu EMPVIEW3. Takoder, moˇzemo
uskratiti INSERT i DELETE za isti pogled. Tada bi manager mogao mijenjati pla´ce svojim surad-
nicima, no ne bi ih mogao izbacivati iz poduze´ca, niti bi mogao dovoditi nove suradnike.
6.4. ZA
ˇ
STITA OD NEOVLA
ˇ
STENOG PRISTUPA 61
Ukoliko korisnik pokuˇsa obaviti radnju za koju nije ovlaˇsten, DBMS ne´ce izvrˇsiti dotiˇcnu operaciju
te ´ce umjesto toga ispisati poruku o greˇski (povreda ovlaˇstenja).
U velikom bazama podataka, brigu oko zaˇstite od neovlaˇstenog pristupa preuzima administrator
baze. On upisuje popis korisnika, zadaje poglede i podeˇsava ovlaˇstenja. Da bi sve to mogao raditi, sam
administrator mora imati najve´ca mogu´ca ovlaˇstenja. Neka od posebnih administratorovih ovlaˇstenja
su:
• pravo stvaranja ili brisanja cijelih relacija ili indeksa;
• pravo definiranja pogleda ili brisanja tih pogleda;
• pravo upravljanja fiziˇckim resursima od kojih se gradi baza (prostor na disku, datoteke);
• pravo davanja i oduzimanja ovlaˇstenja drugim korisnicima baze.
U nekim DBMS-ima administrator moˇze neke od svojih specifiˇcnih ovlaˇstenja prenijeti drugima. Tako
na primjer administrator moˇze nekom korisniku dati ovlaˇstenje UPDATE za zadanu relaciju, uz
dozvolu da taj korisnik to isto ovlaˇstenje dalje daje drugim korisnicima.
62 6. INTEGRITET I SIGURNOST PODATAKA
Literatura
[1] Date C.J.: An Introduction to Database Systems, 8th Edition. Addison-Wesley, Reading MA, 2003.
[2] Silberschatz A., Korth H.F., Sudarshan S.: Database System Concepts, 5th Edition. McGraw-Hill,
New York, 2005.
[3] Ramakrishnan R., Gehrke J.: Database Management Systems, 3rd Edition. McGraw-Hill, New
York, 2002.
[4] Abiteboul S., Hull R., Vianu V.: Foundations of Databases. Addison-Wesley, Reading MA, 1995.
[5] Van der Lans R.F.: Introduction to SQL, 4th Edition. Addison-Wesley, Reading MA, 2006.
[6] Tharp A.L.: File Organization and Processing. John Wiley and Sons, New York, 1988.
[7] Varga M.: Baze podataka - konceptualno, logiˇcko i fiziˇcko modeliranje podataka. DRIP, Zagreb,
1994.
[8] Widenius M., Axmark D.: MySQL Reference Manual . O’Reilly, Sebastopol CA, 2002.
63

Sadrˇaj z
1 UVOD U BAZE PODATAKA 1.1 Osnovni pojmovi vezani uz baze podataka . . . . . . . . . . . . 1.1.1 Baza podataka, DBMS, model podataka . . . . . . . . . 1.1.2 Ciljevi koji se nastoje posti´i koriˇtenjem baza podataka c s 1.1.3 Arhitektura baze podataka . . . . . . . . . . . . . . . . 1.1.4 Jezici za rad s bazama podataka . . . . . . . . . . . . . 1.1.5 Poznati softverski paketi za rad s bazama podataka . . ˇ 1.2 Zivotni ciklus baze podataka . . . . . . . . . . . . . . . . . . . 1.2.1 Analiza potreba . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Modeliranje podataka . . . . . . . . . . . . . . . . . . . 1.2.3 Implementacija . . . . . . . . . . . . . . . . . . . . . . . 1.2.4 Testiranje . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.5 Odrˇavanje . . . . . . . . . . . . . . . . . . . . . . . . . z 3 3 3 4 4 5 6 6 6 7 7 8 8 9 9 9 9 10 11 13 13 14 15 16 16 17 17 18 19 20 21 21 22 23 23 24 24 26 26 26 27 27 28

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

2 MODELIRANJE PODATAKA 2.1 Modeliranje entiteta i veza . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Entiteti i atributi . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Veze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Prikaz ER-sheme pomo´u dijagrama . . . . . . . . . . . . c 2.1.4 Sloˇenije veze . . . . . . . . . . . . . . . . . . . . . . . . . z 2.2 Relacijski model . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Relacija, atribut, n-torka, kljuˇ . . . . . . . . . . . . . . . c 2.2.2 Pretvaranje ER-sheme u relacijsku . . . . . . . . . . . . . 2.2.3 Usporedba relacijskog modela s mreˇnim i hijerarhijskim . z 2.3 Normalizacija relacijske sheme . . . . . . . . . . . . . . . . . . . 2.3.1 Funkcionalna ovisnost . . . . . . . . . . . . . . . . . . . . 2.3.2 Druga normalna forma . . . . . . . . . . . . . . . . . . . . 2.3.3 Tre´a normalna forma . . . . . . . . . . . . . . . . . . . . c 2.3.4 Boyce-Codd-ova normalna forma . . . . . . . . . . . . . . 2.3.5 Viˇeznaˇna ovisnost i ˇetvrta normalna forma . . . . . . . s c c 2.3.6 Razlozi zbog kojih se moˇe odustati od normalizacije . . . z 3 JEZICI ZA RELACIJSKE BAZE PODATAKA 3.1 Relacijska algebra . . . . . . . . . . . . . . . . . . 3.1.1 Skupovni operatori . . . . . . . . . . . . . 3.1.2 Selekcija . . . . . . . . . . . . . . . . . . . 3.1.3 Projekcija . . . . . . . . . . . . . . . . . . 3.1.4 Kartezijev produkt . . . . . . . . . . . . . 3.1.5 Prirodni spoj . . . . . . . . . . . . . . . . 3.1.6 Theta-spoj . . . . . . . . . . . . . . . . . 3.1.7 Dijeljenje . . . . . . . . . . . . . . . . . . 3.1.8 Vanjski spoj . . . . . . . . . . . . . . . . . 3.2 Relacijski raˇun . . . . . . . . . . . . . . . . . . . c 3.2.1 Raˇun orijentiran na n-torke . . . . . . . c 3.2.2 Raˇun orijentiran na domene . . . . . . . c 1

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

2 3.3 Jezik SQL . . . . . . . . . . . . . . . . . 3.3.1 Postavljanje upita . . . . . . . . 3.3.2 Aˇuriranje relacija . . . . . . . . z 3.4 Optimizacija upita . . . . . . . . . . . . 3.4.1 Odnos izmedu relacijske algebre i 3.4.2 Osnovna pravila za optimizaciju . . . . . . . . . . . . . . . . . . . . raˇuna . c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ˇ SADRZAJ . . . . . . . . . . . . . . . . . . . . . . . . 29 29 31 31 32 32 35 35 35 35 36 37 37 37 38 38 39 41 43 43 44 45 47 47 47 48 48 49 50 50 50 51 51 53 53 53 53 54 54 54 56 56 57 57 58 58 58 59 59 59 59 60

ˇ 4 FIZICKA GRADA BAZE PODATAKA 4.1 Elementi fiziˇke grade . . . . . . . . . . . . . c 4.1.1 Vanjska memorija raˇunala . . . . . . c 4.1.2 Datoteke . . . . . . . . . . . . . . . . 4.1.3 Smjeˇtaj datoteke u vanjskoj memoriji s 4.1.4 Pointeri . . . . . . . . . . . . . . . . . 4.1.5 Fiziˇka grada cijele baze . . . . . . . . c 4.2 Pristup na osnovu primarnog kljuˇa . . . . . c 4.2.1 Jednostavna datoteka . . . . . . . . . 4.2.2 Hash datoteka . . . . . . . . . . . . . 4.2.3 Datoteka s indeksom . . . . . . . . . . 4.2.4 B-stablo . . . . . . . . . . . . . . . . . 4.3 Pristup na osnovu drugih podataka . . . . . . 4.3.1 Invertirana datoteka . . . . . . . . . . 4.3.2 Viˇestruke vezane liste . . . . . . . . . s 4.3.3 Podijeljena hash funkcija . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

5 IMPLEMENTACIJA RELACIJSKIH OPERACIJA 5.1 Implementacija prirodnog spoja . . . . . . . . . . . . . . . . 5.1.1 Algoritam ugnijeˇdenih petlji . . . . . . . . . . . . . z 5.1.2 Algoritam zasnovan na sortiranju i saˇimanju . . . . z 5.1.3 Algoritam zasnovan na indeksu . . . . . . . . . . . . 5.1.4 Algoritam zasnovan na hash funkciji i razvrstavanju 5.2 Implementacija selekcije, projekcije i ostalih operacija . . . 5.2.1 Implementacija selecije . . . . . . . . . . . . . . . . . 5.2.2 Implementacija projekcije . . . . . . . . . . . . . . . 5.2.3 Implementacija ostalih operacija. . . . . . . . . . . . 5.3 Optimalno izvrednjavanje algebarskog izraza . . . . . . . . 6 INTEGRITET I SIGURNOST PODATAKA ˇ 6.1 Cuvanje integriteta . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Ograniˇenja kojima se ˇuva integritet domene . . . . c c 6.1.2 Ograniˇenja kojima se ˇuva integritet unutar relacije c c 6.1.3 Ograniˇenja kojima se ˇuva referencijalni integritet . c c 6.2 Istovremeni pristup . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Transakcije i serijalizabilnost . . . . . . . . . . . . . 6.2.2 Lokoti i zakljuˇavanje . . . . . . . . . . . . . . . . . c 6.2.3 Dvofazni protokol zakljuˇavanja . . . . . . . . . . . . c 6.2.4 Vremenski ˇigovi . . . . . . . . . . . . . . . . . . . . z 6.3 Oporavak . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Rezervna kopija baze . . . . . . . . . . . . . . . . . . ˇ 6.3.2 Zurnal datoteka . . . . . . . . . . . . . . . . . . . . . 6.3.3 Neutralizacija jedne transakcije . . . . . . . . . . . . 6.3.4 Ponovno uspostavljanje baze . . . . . . . . . . . . . 6.4 Zaˇtita od neovlaˇtenog pristupa . . . . . . . . . . . . . . . s s 6.4.1 Identifikacija korisnika . . . . . . . . . . . . . . . . . 6.4.2 Pogledi kao mehanizam zaˇtite . . . . . . . . . . . . s 6.4.3 Ovlaˇtenja . . . . . . . . . . . . . . . . . . . . . . . s

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

On oblikuje fiziˇki prikaz baze u skladu s traˇenom logiˇkom strukturom. s c Rijeˇ je o tehnologiji koja je nastala s namjerom da se uklone slabosti tradicionalne “automatske c obrade podataka” iz 60-tih i 70-tih godina 20. Baza je predoˇena usmjerenim grafom. od kojih svaka moˇe imati svoju logiˇku strukturu. tako da danaˇnje baze podataka uglavnom joˇ uvijek moˇemo poistovjetiti s relacijskim s s z bazama. promjena.1 Osnovni pojmovi vezani uz baze podataka Baze podataka predstavljaju viˇu razinu rada s podacima u odnosu na klasiˇne programske jezike. Inspiriran je objektno-orijentiranim programskim jezicima. c c kvalitetu i pouzdanost u razvoju aplikacija koje se svode na pohranjivanje i pretraˇivanje podataka u z raˇunalu. I podaci i veze medu podacima c prikazuju se “pravokutnim” tabelama. Cvorovi su tipovi zapisa. te automatizira administrativne poslove s bazom. Izmedu klasa se uspostavljaju veze nasljedivanja. Objektni model. ˇ Mreˇni model. Svaki objekt pripada nekoj klasi. Dosadaˇnji DBMS-i obiˇno su podrˇavali neki od sljede´ih s c z c modela: Relacijski model. no u skladu s istim modelom. Ta tehnologija osigurala je ve´u produktivnost. c Podaci su istovremeno dostupni raznim korisnicima i aplikacijskim programima. Ubacivanje. Model podataka je c skup pravila koja odreduju kako moˇe izgledati logiˇka struktura baze. agregacije.DBMS) je posluˇitelj z (server) baze podataka. Oˇekivani prijelaz na objektni model za sada s c se nije desio. stolje´a.1. on obavlja u ime klijenata sve operacije s podacima. DBMS. c c c Sustav za upravljanje bazom podataka (Data Base Management System . Korisnici i aplikacije pritom c c ne moraju poznavati detalje fiziˇkog prikaza podataka. pohranjenih u vanjskoj memoriji raˇunala. Specijalni sluˇaj mreˇnog. ve´ se referenciraju na logiˇku strukturu baze. odnosno medusobnog koriˇtenja operacija. Podaci u bazi su logiˇki organizirani u skladu s nekim modelom podataka. 3 . Od 80-tih godina z c pa sve do danaˇnjih dana prevladava relacijski model. a hijerarhijski odnos “nadredeni-podredeni” izraˇava veze medu z tipovima zapisa.1 Baza podataka. model podataka Baza podataka je skup medusobno povezanih podataka. Model ˇini osnovu za koncipiz c c ranje. stolje´a. Isto tako. Dalje. Hijerarhijski model.1 UVOD U BAZE PODATAKA 1. on je u stanju podrˇati razne z baze. brine z c se za sigurnost podataka. Zasnovan na matematiˇkom pojmu relacije. Baza je skup trajno pohranjenih objekata koji se sastoje od svojih internih podataka i “metoda” (operacija) za rukovanje s tim podacima. c z c Takoder. Baza je predoˇena jednim stablom ili skupom stac z c ˇ bala. a lukovi definiraju z c veze medu tipovima zapisa. Cvorovi su tipovi zapisa. s Hijerarhijski i mreˇni model bili su u uptrebi u 60-tim i 70-tim godinama 20. projektiranje i implementiranje baze. brisanje i ˇitanje podataka obavlja se posredstvom zajedniˇkog softvera. c 1.

u skladu c s potrebama odredene aplikacije. Ovom zahtjevu zaista zadovoljavaju jedino relacijske baze. Ovakvi poslovi moraju se obavljati centralizirano. Razdvaja se globalna logiˇka definicija cijele baze podataka od c c lokalne logiˇke definicije za jednu aplikaciju. to ne´e zahtijevati promjene u postoje´im aplikacijama. te svaki od njih treba imati dojam da sam radi s bazom. Sama fiziˇka razina moˇe c z se dalje podijeliti na viˇe pod-razina apstrakcije. Mora postojati mogu´nost da se korisnicima ograniˇe prava koriˇtenja baze. od sasvim konkretnih staza i cilindara na disku. to ne´e zahtijevati promjene u postoje´im aplikacijama. ˇ Cuvanje integriteta. te izborom pogodnih algoritama za pretraˇivanje.1. U starijim mreˇnim i hijerarhijskim bazama. Takoder. ako se logiˇka definicija promijeni (na primjer c c c uvede se novi zapis ili veza). 1. c Globalna logiˇka razina odnosi se na logiˇku strukturu cijele baze. Lokalna c c logiˇka definicija obiˇno se svodi na izdvajanje samo nekih elemenata iz globalne definicije. Odgovorna osoba zove c se administrator baze podataka. Operacije s podacima moraju se odvijati dovoljno brzo. mic s c jenjanje parametara u fiziˇkoj gradi. rutinsko pohranjivanje rezervnih kopija podataka. Ta viˇa razina rada oˇituje se u tome ˇto tehnologija baza podataka nastoji (i u s c s velikoj mjeri uspijeva) ispuniti sljede´e ciljeve.1. te konfliktne istrovremene aktivnosti korisnika. pa povremeno treba podesiti i s logiˇku strukturu. Znaˇi. Istovremeni pristup do podataka. Fleksibilnost pristupa podacima. Nastoji se automatski saˇuvati korektnost i konzistencija podataka. c Fiziˇka nezavisnost podataka. c c Logiˇka nezavisnost podataka. Danas se zahtijeva da korisnik moˇe slobodno prebirati po podacima. te po svom nahodenju uspostavljati z veze medu podacima. ako se fiziˇka grada promijeni (na primjer. s Mogu´nost oporavka nakon kvara. i u skladu je sa zadanim c . UVOD U BAZE PODATAKA 1. dakle korisnik je mogao pretraˇivati podatke jedino onim z redoslijedom koji je bio predviden u vrijeme projektiranja i implementiranja baze.3 Arhitektura baze podataka Arhitektura baze podataka sastoji se od tri “sloja” i suˇelja medu slojevima. Zadovoljavaju´a brzina pristupa. Na brzinu pristupa moˇe se utjecati odabirom pogodnih fiziˇkih z c struktura podataka. s do ve´ donekle apstraktnih pojmova datoteke i zapisa kakve susre´emo u klasiˇnim programskim c c c jezicima. To je aspekt kojeg vidi projekc c tant baze odnosno njen administrator.1. Administratoru trebaju stajati na raspolaganju razni alati i pomagala. Baza mora omogu´iti da ve´i broj korisnika istovremeno koristi c c iste podatke. svrha baze se vremenom mijenja. Mora postojati pouzdana zaˇtita baze u sluˇaju kvara hardc s c vera ili greˇaka u radu sistemskog softvera. To je c c aspekt kojeg vide samo sistemski programeri (oni koji su razvili DBMS). uz c c neke jednostavne transformacije tih elemenata. Razdvaja se logiˇka definicija baze od njene stvarne fiziˇke grade. Zapis logiˇke definicije naziva se shema (engleski takoder c schema). s s s s c c Zaˇtita od neovlaˇtenog koriˇtenja. Raspored pohranjivanja opisuje kako se elementi logiˇke definicije baze preslikavaju c na fiziˇke uredaje. Shema je tekst ili dijagram koji definira logiˇku strukturu baze. podaci se prepiˇu u druge datoteke na drugim c c s diskovima).4 1. staze pristupanja z podacima bile su unaprijed definirane. z Mogu´nost podeˇavanja i kontrole. dakle da se svakom korisniku reguliraju ovlaˇtenja ˇto on smije a ˇto ne smije s s s s raditi s podacima. i to u c situaciji kad postoje greˇke u aplikacijama. Rijeˇ je o tri razine apstrakcije c Fiziˇka razina odnosi se na fiziˇki prikaz i raspored podataka na jedinicama vanjske memorije. Velika baza zahtijeva stalnu brigu: pra´enje performansi. reguliranje c ovlaˇtenja korisnika. Pritom ti korisnici ne smiju ometati jedan drugoga. kao ˇto je prikazano na c s Slici 1.2 Ciljevi koji se nastoje posti´i koriˇtenjem baza podataka c s Spomenuli smo da baze podataka predstavljaju viˇu razinu rada s podacima u odnosu na klasiˇne s c programske jezike. c c c Znaˇi.

promjena.1: Arhitektura baze podataka Za stvaranje baze podataka potrebno je zadati samo shemu i poglede.DDL). Lokalna logiˇka razina odnosi se na logiˇku predodˇbu o dijelu baze kojeg koristi pojedina aplikacija. opet u skladu s pravilima koriˇtenog modela. Sluˇi programeru za z uspostavljanje veze izmedu aplikacijskog programa i baze. shema uvodi i ograniˇenja kojim se ˇuva integritet s c c podataka. Zapis jedne lokalne logiˇke definicije c zove se pogled (engleski view) ili pod-shema. s Takoder. C. To je tekst ili dijagram kojim se imenuju i definiraju svi lokalni tipovi podataka i veze medu tim tipovima. c c z To je aspekt kojeg vidi korisnik ili aplikacijski programer. te jednostavne operacije kao ˇto su upis. Jezik za manipuliranje podacima (Data Manipulation Language . podeˇavanjem njemu dostupnih parametara. Koji puta postoji posebna varijanta jezika za shemu. Naredbe DML omogu´uju “manevric ranje” po bazi. 1. Aplikacijski program 1 T c Pogled 1 s d ‚ d Aplikacijski program 2 T c Pogled 2 T c Shema T c Raspored pohranjivanja      © Aplikacijski program 3 T c Pogled 3 Lokalna logiˇka c razina Globalna logiˇka c razina      ©    Datoteke s d ‚  d   Datoteke    Fiziˇka c razina Slika 1.1. ve´ dobivaju ili pohranjuju podatke posredc c stvom DBMS-a. c . Takoder. Dakle imenuju se i definiraju svi tipovi podataka i veze medu tim tipovima. DBMS tada automatski generira potrebni raspored pohranjivanja i fiziˇku bazu.4 Jezici za rad s bazama podataka Komunikacija korisnika odnosno aplikacijskog programa i DBMS-a odvija se pomo´u posebnih jezika. brisanje ili ˇitanje zapisa. Dakle tim jezikom definiramo podatke i veze medu podacima. U drugim paketima zaista se radi o posebnom jeziku: programer tada piˇe program u kojem su izmijeˇane naredbe dvaju jezika. Pascal. PL/I. c Jezik za opis podataka (Data Description Language . Sluˇi projektantu baze ili administraz toru u svrhu zapisivanja sheme ili pogleda. OSNOVNI POJMOVI VEZANI UZ BAZE PODATAKA 5 modelom. pa takav program treba prevoditi s s s dva prevodioca (DML-precompiler. Administrator moˇe samo donekle utjecati na c z fiziˇku gradu baze. i to na logiˇkoj razini. Komunikacija programa odnosno korisnika s DBMS-om obavlja se na lokalnoj logiˇkoj c razini. obiˇni compiler). pogled zadaje preslikavanje kojim se iz globalnih podataka i veza izvode lokalni. a posebna c za poglede. Naredbe DDL obiˇno podsije´aju na naredbe za definiranje sloˇenih tipova podataka c c z u jezicima poput COBOL. u skladu s pravilima koriˇtenog modela.1. c s Programi i korisnici ne pristupaju izravno fiziˇkoj bazi. c Ti jezici tradicionalno se dijele na sljede´e kategorije.DML). DML je zapravo biblioteka potprograma: “naredba” u DML svodi se na poziv potprograma.1. U s c nekim softverskim paketima.

Tabelarni s prikaz 1. Vaˇno je c z z c z procijeniti frekvenciju i opseg pojedinih transakcija.5 Poznati softverski paketi za rad s bazama podataka Baze podataka se u pravilu realiziraju koriˇtenjem nekog od provjerenih softverskih paketa. Uoˇavaju se podaci koje treba pohranjivati i veze medu c c c njima. U 80-tim godinama 20. To je jezik koji podsije´a na govorni (engleski) jezik Naredbe su neproceduz c ralne. uobiˇajene klijente (na primjer interaktivni interpreter SQL).1 Analiza potreba Prouˇavaju se tokovi informacija u poduze´u. te uskladiti terminologiju. UVOD U BAZE PODATAKA Jezik za postavljanje upita (Query Language . Pascal . Jedino osvjeˇenje predstavlja nedavna pojava public-domain c z sotvera poput MySQL. generacije (4-th Generation Languages . Integrirani z z jezik se moˇe koristiti interaktivno (preko on-line interpretera) ili se on moˇe pojavljivati uklopljen u z z aplikacijske programe. Primjer takvog integriranog jezika za relacijske baze je SQL: on sluˇi za definiranje podataka. budu´i da to moˇe isto imati utjecaja na sadrˇaj i konaˇni oblik baze. spajanja ili preuzimanja. c z modeliranje podataka. . a rezultiraju´i pros c gram se lako dotjeruje. Naglasimo da gore spomenute vrste jezika nisu programski jezici. te biblioteke i alate za razvoj c aplikacija. Na primjer.1 daje pregled softvera koji u ovom trenutku predstavljaju tehnoloˇki vrh te imaju znaˇajan s c udjel na svjetskom trˇiˇtu. te se nije mogao koristiti izvan tog paketa (baze). c c Konkurencija medu proizvodaˇima softvera za baze podataka je izuzetno velika. te zahtjeve na performanse. 1. Svaki od njih sadrˇi svoj s z z DBMS. Za interakcije s bazom koriste se unaprijed pripremljene klase objekata. Tradicionalni naˇin razvoja aplikacija koje rade s bazom je koriˇtenje klasiˇnih programskih jezika c s c (COBOL. pojavit ´e se razni “pogledi” na c c podatke. dakle takve da samo specificiraju rezultat kojeg ˇelimo dobiti. Ovakva podjela na tri jezika danas je ve´ priliˇno zastarjela. . C++. generacije je bio u njihovoj nestandardnosti: c svaki od njih je u pravilu bio dio nekog odredenog softverskog paketa za baze podataka. To je projekt koji se moˇe podijeliti u pet faza: analiza potreba. Dakle ti jezici su nam nuˇni da z bi se povezali s bazom. c Analiza potreba takoder treba obuhvatiti analizu transakcija (operacija) koje ´e se obavljati nad bazom podataka. aplikacije se najˇeˇ´e razvijaju u standardnim objektno orijentiranim pros c sc gramskim jezicima (Java. testiranje i odrˇavanje. ). Naime. Sluˇi neposrednom korisniku za interaktivno z pretraˇivanje baze. Problem s jezicima 4. treba u raznim pogledima prepoznati sinonime i homonime. c 1. U velikom poduze´ima. . Rezultat analize je dokument (pisan neformalno u prirodnom jeziku) koji se zove specifikacija potreba. Te poglede treba uskladiti tako da se eliminira redundancija i nekonzistentnost. no oni nam nisu dovoljni za razvoj aplikacija koje ´e neˇto raditi s podacima iz c s baze.4GL): rijeˇ je o jezicima koji c su bili namijenjeni iskljuˇivo za rad s bazama.6 1. manipuliranje i pretraˇivanje. uklapa u ve´e sustave ili prenosi s jedne baze na drugu. . zs Gotovo svi danaˇnji softverski paketi podrˇavaju relacijski model i SQL. Svaki paket isporuˇuje se u verzijama za razne raˇunalne platforme (operacijske sustave). tako da je posljedc njih godina ˇesto dolazilo do njihovog nestanka. Ovakva tehnika je dovoljno produktivna zbog koriˇtenja gotovih klasa. implementacija. Lista relevantnih softverskih c paketa zato je svake godine sve kra´a.QL). C. jezici 4.1. z 1. te su zato u tom kontekstu bili produktivniji od klasiˇnih c c programskih jezika op´e namjene. U danaˇnje vrijeme. a ne i postupak za dobivanje z rezultata.2. PL/I.2 ˇ Zivotni ciklus baze podataka Uvodenje baze podataka u neko poduze´e ili ustanovu predstavlja sloˇeni zadatak koji zahtijeva timc z ski rad struˇnjaka raznih profila. ) s ugnijeˇdenim DML-naredbama. . gdje postoje razne grupe korisnika. . stolje´a bili su z c dosta popularni i tzv. kod relacijskih baza postoji c c tendencija da se sva tri jezika objedine u jedan sveobuhvatni.

ˇ 1.2. ZIVOTNI CIKLUS BAZE PODATAKA

7

Proizvodaˇ c

Produkt

Operacijski sustav

Jezici

IBM Corporation

DB2

Linux, UNIX (razni), MS Windows NT/2000/XP, VMS, MVS, VM, OS/400 MS Windows (razni), Mac OS, UNIX (razni), Linux i drugi UNIX (razni), Linux, MS Windows NT/2000/XP

SQL, COBOL, Java, . . . SQL, Java i drugi SQL, Java i drugi SQL, C++, . . . SQL, C, PHP, . . . SQL, COBOL, . . . SQL, 4GL, C, . . . SQL, COBOL, . . . Access Basic, SQL

Oracle Corporation

Oracle

IBM Corporation (prije : Informix Software Inc.) Microsoft

Informix

MS SQL Server

MS Windows NT/2000/XP

MySQL AB

MySQL

Linux, UNIX (razni), MS Windows (razni), Mac OS MS Windows NT/2000, OS/2, Mac, UNIX (razni), UNIXWare UNIX (HP-UX)

Sybase Inc.

Sybase SQL Server Allbase/SQL

Hewlett Packard Co.

Cincom Systems Inc. Microsoft Corporation

Supra

MS Windows NT/2000, Linux, UNIX (razni), VMS, MVS, VM MS Windows (razni)

MS Access

Tabelarni prikaz 1.1: Poznati softverski paketi za rad s bazama podataka

1.2.2

Modeliranje podataka

Razliˇiti pogledi na podatke, otkriveni u fazi analize, sintetiziraju se u jednu cjelinu - globalnu shemu. c Precizno se utvrduju tipovi podataka. Shema se dalje dotjeruje (“normalizira”) tako da zadovolji neke zahtjeve kvalitete. Takoder, shema se prilagodava ograniˇenjima koje postavlja zadani model podataka, c te se dodatno modificira da bi bolje mogla udovoljiti zahtjevima na performanse. Na kraju se iz sheme izvode pogledi (pod-sheme) za pojedine aplikacije (grupe korisnika).

1.2.3

Implementacija

Na osnovu sheme i pod-shema, te uz pomo´ dostupnog DBMS-a, fiziˇki se realizira baza podataka c c na raˇunalu. U DBMS-u obiˇno postoje parametri kojima se moˇe utjecati na fiziˇku organizaciju c c z c baze. Parametri se podeˇavaju tako da se osigura efikasan rad najvaˇnijih transakcija. Razvija se skup s z programa koji realiziraju pojedine transakcije te pokrivaju potrebe raznih aplikacija. Baza se inicijalno puni podacima.

8

1. UVOD U BAZE PODATAKA

1.2.4

Testiranje

Korisnici pokusno rade s bazom i provjeravaju da li ona zadovoljava svim zahtjevima. Nastoje se otkriti greˇke koje su se mogle potkrasti u svakoj od faza razvoja: dakle u analizi potreba, modeliranju s podataka, implementaciji. Greˇke u ranijim fazama imaju teˇe posljedice. Na primjer, greˇka u analizi s z s potreba uzrokuje da transakcije moˇda korektno rade, no ne ono ˇto korisnicima treba ve´ neˇto drugo. z s c s Dobro bi bilo kad bi takve propuste otkrili prije implementacije. Zato se u novije vrijeme, prije prave implementacije, razvijaju i pribliˇni prototipovi baze podataka, te se oni pokazuju korisnicima. z Jeftinu izradu prototipova omogu´uju jezici 4. generacije i objektno-orijentirani jezici. c

1.2.5

Odrˇavanje z

Odvija se u vrijeme kad je baza ve´ uˇla u redovnu upotrebu. Sastoji se od sljede´eg: popravak greˇaka c s c s koje nisu bile otkrivene u fazi testiranja; uvodenje promjena zbog novih zahtjeva korisnika; podeˇavanje s parametara u DBMS u svrhu poboljˇavanja performansi. Odrˇavanje zahtijeva da se stalno prati rad s z s bazom, i to tako da to pra´enje ne ometa korisnike. Administratoru baze podataka trebaju stajati c na raspolaganju odgovaraju´i alati (utility programi). c

2

MODELIRANJE PODATAKA
2.1 Modeliranje entiteta i veza

Bavimo se pitanjem: kako oblikovati shemu za bazu podataka, uskladenu s pravilima relacijskog modela. U stvarnim situacijama dosta je teˇko direktno pogoditi relacijsku shemu. Zato se sluˇimo jednom s z pomo´nom fazom koja se zove modeliranje entiteta i veza (Entity-Relationship Modelling). Rijeˇ c c je o oblikovanju jedne manje precizne, konceptualne sheme, koja predstavlja apstrakciju realnog svijeta. Ta tzv. ER-shema se dalje, viˇe-manje automatski, pretvara u relacijsku. Modeliranje entiteta i veza s zahtijeva da se svijet promatra preko tri kategorije: entiteti: objekti ili dogadaji koji su nam od interesa; veze: odnosi medu entitetima koji su nam od interesa; atributi: svojstva entiteta i veza koja su nam od interesa.

2.1.1

Entiteti i atributi

Entitet je neˇto o ˇemu ˇelimo spremati podatke, neˇto ˇto je u stanju postojati ili ne postojati, te se s c z s s moˇe identificirati. Entitet moˇe biti objekt ili bi´e (na primjer ku´a, student, auto), odnosno dogadaj z z c c ili pojava (na primjer nogometna utakmica, praznik, servisiranje auta). Entitet je opisan atributima (na primjer atributi ku´e su: adresa, broj katova, boja fasade, . . . ). c Ukoliko neki atribut i sam zahtijeva svoje atribute, tada ga radije treba smatrati novim entitetom (na primjer model auta). Isto pravilo vrijedi i ako atribut moˇe istovremeno imati viˇe vrijedenosti (na z s primjer kvar koji je popravljen pri servisiranju auta). Ime entiteta, zajedno sa pripadnim atributima, zapravo odreduje tip entiteta. Moˇe postojati z mnogo primjeraka (pojava) entiteta zadanog tipa (na primjer STUDENT je tip ˇiji primjerci su c Petrovi´ Petar, Markovi´ Marko, . . . ). c c Kandidat za kljuˇ je atribut, ili skup atributa, ˇije vrijednosti jednoznaˇno odreduju primjerak c c c entiteta zadanog tipa. Dakle, ne mogu postojati dva razliˇita primjerka entiteta istog tipa s istim c vrijednostima kandidata za kljuˇ. (Na primjer za tip entiteta AUTO, kandidat za kljuˇ je atribut c c REG BROJ ). Ukoliko jedan tip entiteta ima viˇe kandidata za kljuˇ, tada biramo jednog od njih i s c proglaˇavamo ga primarnim kljuˇem. (Na primjer primarni kljuˇ za tip entiteta STUDENT mogao s c c bi biti atribut BROJ INDEKSA.

2.1.2

Veze

Veze se uspostavljaju izmedu dva ili viˇe tipova entiteta (na primjer veza IGRA ZA izmedu tipova s ˇ entiteta IGRAC i TIM ). Zapravo je rijeˇ o imenovanoj binarnoj ili k-narnoj relaciji izmedu primc jeraka entiteta zadanih tipova. Za sada ´emo se ograniˇiti na veze izmedu toˇno dva tipa entiteta. c c c Funkcionalnost veze moˇe biti: z Jedan-naprama-jedan (1 : 1). Jedan primjerak prvog tipa entiteta moˇe biti u vezi s najviˇe jednim z s z primjerkom drugog tipa entiteta, te takoder jedan primjerak drugog tipa moˇe biti u vezi s ˇ najviˇe jednim primjerkom prvog tipa. Na primjer veza JE PROCELNIK izmedu tipova entiteta s NASTAVNIK i ZAVOD (na fakultetu). 9

. z Ako svaki primjerak entiteta nekog tipa mora sudjelovati u zadanoj vezi. NASLOV . uneseni su u dijagram. koja ima funkcionalnost (N : 1). tada kaˇemo da tip entiteta z ima obavezno ˇlanstvo u toj vezi. IME STUDENTA. pogledajmo dijagram na Slici 2. 1 ili viˇe z s primjeraka drugog tipa entiteta.1 koji prikazuje bazu podataka o fakultetu. U toj listi moˇemo specificirati obaveznost ˇlanstva u vezama. z c ZAVOD €€ €€ 1 ¨¨ €€ 1 ¨ d1 €€ ¨ ¨ d €  d  d  d   d   JE d   d   NUDI d  PROCELd   JE U d ˇ d   d NIK   d   d   d   d   d  d  d  r 1 r ¡  d N N r r ¡   d 1 N   d PREDAJE KOLEGIJ NASTAVNIK d   d   N d   d   d   UPISAO d d   d   d  M STUDENT Slika 2.10 2. . ADRESA. ZAVOD. jer svaki ispit mora biti iz nekog kolegija. MODELIRANJE PODATAKA Jedan-naprama-mnogo (1 : N ). KOLEGIJ . . a c rombovi veze. Na primjer veza UPISAO izmedu tipova entiteta STUDENT s i KOLEGIJ . 1 ili z viˇe primjeraka drugog tipa entiteta. SPOL. . ADRESA. 1 ili viˇe primjeraka prvog tipa. Tipovi entiteta su: 1. Jedan primjerak prvog tipa entiteta moˇe biti u vezi s 0. Posebno se prilaˇe lista atributa za svaki entitet z odnosno vezu. s atributima BR INDEKSA. . s atributima IME ZAVODA. Imena tipova entiteta c i veza. no jedan primjerak drugog tipa moˇe biti u vezi s najviˇe jedz s nim primjerkog prvog tipa. SEMESTAR.3 Prikaz ER-sheme pomo´u dijagrama c Obiˇaj je da se ER-shema nacrta kao dijagram u kojem pravokutnici predstavljaju tipove entiteta. . Na primjer veza PREDAJE izmedu tipova entiteta NASTAVNIK i KOLEGIJ .1: ER-shema baze podataka o fakultetu Kao primjer. STUDENT . te takoder jedan primjerak drugog tipa moˇe biti u vezi s s z 0. . . . Inaˇe tip entiteta ima neobavezno ˇlanstvo. (Na primjer izmedu c c c tipova entiteta ISPIT i KOLEGIJ zadana je veza IZ . ISPIT ima obavezno ˇlanstvo u vezi IZ . Jedan primjerak prvog tipa entiteta moˇe biti u vezi s 0. s atributima BR KOLEGIJA. Mnogo-naprama-mnogo (M : N ). 2. Veze su povezane bridovima s odgovaraju´im tipovima entiteta. 2. te funkcionalnost veza.1.) Odluka da li je ˇlanstvo c c obavezno ili neobavezno koji put je stvar dogovora odnosno projektantove odluke (na primjer ˇlanstvo c za KOLEGIJ u vezi PREDAJE ). . 3. Veza moˇe imati i svoje atribute koje ne moˇemo pripisati ni jednom od tipova entiteta (na primjer z z veza UPISAO moˇe imati atribut DATUM UPISA).

c 2. 5. Pritom jedan sloˇeniji dio sadrˇi viˇe jednostavnijih. Moˇemo uzeti da je ˇlanstvo u toj vezi neobavezno.. PREDAJE . KOLEGIJ ima na primjer obavezno ˇlanstvo. NASTAVNIK ukljuˇuje profesore. Navest z ´emo neke od njih. c 4. s atributima IME NASTAVNIKA (pretpostavljamo da je jedinstveno). JE U . NASTAVNIK . c Involuirana veza povezuje jedan tip entiteta s tim istim tipom. MODELIRANJE ENTITETA I VEZA 11 4. KOLEGIJ ima obavezno ˇlanstvo. ZAVOD ima obavezno ˇlanstvo. 3. docente i asistente.2 ima ucrtanu strelicu ˇ koja pokazuje smjer tumaˇenja veze JE SEF ZA. bez atributa.1. c . Veze su: c c c ˇ 1. Rijeˇ je o tipovima entiteta za z c osobe koje se pojavljuju na fakultetu. . Drugi dijagram na Slici 2. s ˇ Clanstvo u u vezi U BRAKU S je neobavezno. c c 2. 1d       U d   BRAKU d OSOBA d   € €€ d S   €€ € d  1 N    d  A    JE d   SEF d ˇ SURADNIK d   € €€ d ZA   €€ € d  1 M    d     d   SADRZI d ˇ DIO PROIZVODA d   € €€ d   € € N €d  Slika 2.1. bez atributa. s z Pod-tipovi. BR SOBE . (1 : N ). Dakle rijeˇ je o binarnoj relaciji c izmedu raznih primjeraka entiteta istog tipa. s atributom DATUM UPISA. z odnosno (M : N ). E1 nasljeduje sve atribute od E2. NASTAVNIK ima obavezno ˇlanstvo. Funkcionalnost takve veze opet moˇe biti (1 : 1). c z c jer postoji barem jedan suradnik koji nema ˇefa. Prvi dijagram na Slici z c 2.2: Primjeri za involuirane veze Slika 2. no E1 moˇe imati i dodatne atribute. Tip entiteta E1 je podtip tipa entiteta E2 ako je svaki primjerak od E1 takoder i primjerak od E2. Podvuˇeni atributi ˇine primarni kljuˇ. bez atributa.2 odnosi se na dijelove s c proizvoda koji se proizvode u nekoj tvornici. Slika 2. JE PROCELNIK . bez atributa. Isti z z s jednostavniji dio pojavljuje se u viˇe sloˇenih. UPISAO.2.. Situaciju z opisujemo pomo´u specijalne (1 : 1) veze JE (engleski IS A koja se moˇe pojaviti viˇe puta unutar c z s ER-sheme.2 sadrˇi primjere za involuirane veze s razliˇitim funkcionalnostima. NUDI .2 napravljen je pod pretpostavkom da su proˇli brakovi osobe zaboravljeni. a poligamija zabranjena.4 Sloˇenije veze z U stvarnim situacijama pojavljuju se i sloˇenije veze od onih koje smo do sada promatrali. Tre´i dijagram na Slici 2.3 sadrˇi primjer ER-sheme s pod-tipovima i nad-tipovima.

ER model dovoljno je jednostavan da ga ljudi razliˇitih struka mogu razumjeti. Funkcionalnost ove veze je mnogo-napramamnogo-naprama-mnogo.12 2. Ternarnu vezu uvodimo samo onda kad se ona ne moˇe rastaviti na dvije binarne. te c modificira u skladu s pravilima relacijskog. z . Uzmimo da z u primjeru sa Slike 2.4 odnosi se na podatke o kompanijama. i to u najranijoj fazi razvoja baze. razmatrana ternarna veza moˇe se zamijeniti s dvije z binarne. proizvodima koje one proizvode i zemljama u koje one izvoze svoje proizvode. proizvod) postoji mnogo zemalja u koje ta kompanija izvozi taj proizvod. c Primjer ternarne veze sa Slike 2. (1 : 1 : N ) ili ˇak (1 : 1 : 1).5. (1 : N : M ). ve´ zahtijevaju da se ona detaljnije razradi. Znaˇi rijeˇ je o ternarnoj relaciji izmedu c c primjeraka triju tipova entiteta.3: Primjer ER-sheme s pod-tipovima entiteta KOMPANIJA M  d   d   IZVOZI d  e ¡d   eP N ¡ d d  ¡ e ¡ e PROIZVOD ZEMLJA Slika 2. Postoje brojne mogu´nosti za funkcionalnost ternarne veze. mreˇnog.4 vrijedi pravilo: ako kompanija izvozi u neku zemlju. Postoje´i c DBMS ne mogu direktno implementirati ER shemu. Zato ER shema sluˇi c z za komunikaciju projektanta baze podataka i korisnika. u skladu s dijagramom na Slici 2. Uz ovo pravilo. jer na primjer za zadani par (kompanija. tada ona odmah izvozi sve svoje proizvode u tu zemlju. MODELIRANJE PODATAKA OSOBA B ¨ 1 ¨ ¨ ¨  d   d   JE d d   d   d  1 STUDENT ‰ r 1 r rr  d   d   JE d d   d   d  1 NASTAVNIK T 1  d   d   JE d d   d   d  1 PROFESOR Slika 2. dakle (N : M : P ). na primjer c (N : M : P ). itd. odnosno hijerarhijskog modela.4: Primjer ternarne veze Ternarne veze uspostavljaju se izmedu tri tipa entiteta.

Relacija sadrˇi podatke o automobilima koji se nalaze na popravku z u nekoj radionici. Prve realizacije na raˇunalu bile su suviˇe spore i neefikasne.1 Relacija. n-torka.2. × Dn . efikasnost relacijskih baza postepeno se poboljˇavala. Vrijednosti jednog atributa su podaci istog tipa. stolje´a c s c relacijski model je postao prevladavaju´i. D2 . GODINA. Znaˇi. c Uvedena terminologija potjeˇe iz matematike. Model se dugo pojavljivao samo u akademskim raspravama i knjigama.1: Relacija s podacima o automobilima. MODEL. ili biljeˇi vezu izmedu dva ili viˇe c z s primjeraka. Pod nekim uvjetima toleriramo situaciju da vrijednost atributa nedostaje (nije upisana). definiran je skup dozvoljenih vrijednosti za atribut. Broj atributa je stupanj relacije. . Jedan stupac relacije obiˇno sadrˇi vrijednost jednog atributa (za entitet ili vezu) . . Dn . Sredinom 80-tih godina 20. neka je R relacija stupnja n i neka su domene c njenih atributa redom D1 . Kao primjer.5: Rastavljanje ternarne veze na dvije binarne 2. .F. permutiranjem redaka i stupaca tabele dobivamo drukˇiji zapis iste relacije.zato stupac poistovje´ujemo s atributom c z c i obratno. Redak nazivamo n-torka. stolje´a. kljuˇ c Relacijski model zahtijeva da se baza podataka sastoji od skupa pravokutnih tabela . . AUTO REG BROJ ZID654 BXI930 COI453 ZXI675 RST786 TXI521 HCY675 ˇ PROIZVODAC Ford Volkswagen Nissan Ford Fiat Ford Volkswagen MODEL Fiesta Golf Primera Escort Punto Orion Jetta GODINA 1997 1996 1997 1995 1993 1995 1997 Tabelarni prikaz 2. Tada se R moˇe interpretirati kao podskup Kartezijevog z produkta D1 × D2 × . Svaka relacija ima svoje ime po kojem je razlikujemo od ostalih u istoj bazi.2 Relacijski model Relacijski model bio je teoretski zasnovan joˇ krajem 60-tih godina 20. Zahvaljuju´i intenzivnom istraˇivanju. U jednoj relaciji ne smiju postojati dvije jednake n-torke. s atributima REG BROJ .1 relaciju AUTO. u radovima E. I danas ve´ina DBMS koristi taj model. Relacija ne propisuje nikakav redoslijed svojih n-torki i atributa. naˇ pojam relacije odgovara matematiˇkom pojmu n-narne c s c . ˇ PROIZVODAC . Atribut ima svoje ime po kojem ga razlikujemo od ostalih u istoj relaciji. . navodimo u Tabelarnom prikazu 2. Jedan redak relacije obiˇno predstavlja jedan primjerak entiteta.2. Naime.2. Dakle. Vrijednost atributa mora biti jednostruka i jednostavna (ne da se rastaviti na dijelove). atribut. . Dakle.tzv. s c Codd-a. a broj n-torki je kardinalnost relacije. te napretku samih c s c z raˇunala. c c 2. relacija. RELACIJSKI MODEL 13 KOMPANIJA ¨ r N N ¨ r ¨ rr ¨  d  d   d   d   RADI d   d PRODAJE d   d   d   d   d  d  M M PROIZVOD ZEMLJA Slika 2. koji se zove domena atributa.

Ako tip entiteta E2 ima obavezno ˇlanstvo u (N : 1) vezi s tipom E1. Ako izbacimo iz K bilo koji atribut. Deˇava se da relacija ima viˇe kandidata za kljuˇ. 2. Na taj naˇin s c pokazat ´emo kako se iz cijele ER-sheme dobiva relacijska shema. K uvijek postoji. ADRESA.1). za sve knjige koje c trenutno nisu posudene. Doduˇe.2 Pretvaranje ER-sheme u relacijsku U nastavku objaˇnjavamo kako se pojedini elementi ER-sheme pretvaraju u relacije.1 svaki c kolegij mora biti ponuden od nekog zavoda. Vrijednost atributa BR ISKAZNICE bit ´e prazna u mnogim n-torkama relacije KNJIGA. Dakle ne mogu u R postojati dvije c n-torke s istim vrijednostima atributa iz K. Izbacivanjem suviˇnih atributa do´i ´emo do podskupa koji zadovoljava i s c c svojstvo 2. shema izgleda ovako: ˇ AUTO ( REG BROJ. tada se naruˇava svojstvo 1. Jedan primjerak entiteta prikazan je jednom n-torkom. Tada jedan on njih proglaˇavamo primarnim s s c s kljuˇem. Atributi tipa postaju atributi relacije. Kljuˇ K relacije R je podskup atributa od R koji ima sljede´a “vremenski neovisna” svojstva: c c 1. stupac) ili termini iz tradicionalnih programskih jezika (datoteka. zapis. ) . tj. redak. . . Drugo rjeˇenje zahtijeva tri relacije: s . koja se sastoji od imena relacije i popisa imena atributa u zagradama. Ovdje smo u relaciju KNJIGA dodali BR ISKAZNICE osobe koja je posudila knjigu. ) . SPOL. Svaki tip entiteta prikazuje se jednom relacijom. . Na primer tip STUDENT iz naˇe fakultetske baze podataka sa Slike c s 2. Atributi koji sastavljaju primarni kljuˇ zovu se primarni atributi.1 prikazuje se relacijom: STUDENT ( BR INDEKSA. . IME STUDENTA. ˇeˇ´e c c sc se koriste neposredni termini (tabela. KNJIGA ( REG BROJ. Na primjer ako u ER-shemi sa Slike 2. . atribut). tada c relacija za E2 treba ukljuˇiti primarne atribute od E1. Gradu relacije kratko opisujemo tzv. tada se veza NUDI svodi na to da u relaciju KOLEGIJ ubacimo kljuˇ relacije ZAVOD : c KOLEGIJ ( BR KOLEGIJA. c c Ako tip entiteta E2 ima neobavezno ˇlanstvo u (N : 1) vezi s tipom E1. NASLOV. . 2. Na primjer. Naime.2. n-torka. MODELIRANJE PODATAKA relacije. za relaciju o automobilima c (Tabelarni prikaz 2. polje). c c  d   d 1   dN POSUDBA d   d   d  ˇ POSUDIVAC KNJIGA Slika 2. SEMESTAR. U komercijalnim DBMS. . tada vezu moˇemo prikazati c z na prethodni naˇin. s c Budu´i da su sve n-torke u R medusobno razliˇite.6 koja prikazuje posudivanje knjiga u knjiˇnici. skup svih atributa c zadovoljava svojstvo 1.6: ER-shema za dio baze podataka o knjiˇnici z Kao primjer. Primarni atributi su podvuˇeni. . . Vrijednost primarnog c c atributa ne smije ni u jednoj n-torki ostati neupisana. ) . Kljuˇ jedne relacije koji je prepisan u drugu relaciju zove se strani kljuˇ (u toj drugoj relaciji). Vrijednosti atributa iz K jednoznaˇno odreduju n-torku u R. . PREZIME IME. ili uvodenjem nove relacije ˇiji atributi su primarni atributi od E1 i E2.14 2. . MODEL. Odgoz varaju´e relacije za prikaz te veze i pripadnih entiteta mogle bi biti: c ˇ POSUDIVAC ( BR ISKAZNICE. promotrimo vezu na Slici 2. GODINA ) . NASLOV. Primarni kljuˇ entiteta c postaje primarni kljuˇ relacije. . sudjelovanje entiteta u vezama moˇe zahtijevati da se u relaciju dodaju joˇ neki atributi koji s z s nisu postojali u odgovaraju´em tipu entiteta. ) . IME ZAVODA. c Pretvorba binarnih veza. c Pretvorba tipova entiteta. ADRESA. BR ISKAZNICE. umjesto “matematiˇkih” termina (relacija. shemom relacije. PROIZVODAC.

.4 imamo: KOMPANIJA ( IME KOMPANIJE. . ˇ Dodali smo i atribut KOLICINA koji kaˇe koliko jednostavnih dijelova ulazi u jedan sloˇeni. S druge strane. . POSUDBA ( REG BROJ. c Veza JE uspostavlja se na osnovu pojavljivanja istog JMBG u raznim relacijama. OPIS. Kljuˇ za UPISAO je oˇito sloˇen od atributa BR INDEKSA i BR KOLEGIJA. . Na primjer u relaciju c ´ POSUDBA mogli bi uvesti atribut DATUM VRACANJA. 2. . Za primjer sa Slike 2.2. . . PROIZVOD ( IME PROIZVODA. .1 prikazuje se relacijom: UPISAO ( BR INDEKSA. ) . ID BR SEFA. ) . . te naˇinu koriˇtenja tih veza.2. IZVOZI ( IME KOMPANIJE. atributi zajedniˇki za sve tipove osoba . ) . ˇ ˇ ˇ SADRZI ( BR DIJELA SLOZENOG. . . c c s . ADRESA. . PREZIME IME. c NASTAVNIK ( JMBG. z Osnovna razlika je u naˇinu prikazivanja veza medu entitetima. NASLOV. Posluˇit ´emo se primjerima sa c z c Slike 2. Pretvorba ternarnih veza. ) . (N : M ) veza se uvijek prikazuje posebnom relacijom. Tip c c c s ˇ entiteta DIO PROIZVODA i (N : M ) vezu SADRZI moramo prikazati pomo´u dvije relacije: c DIO PROIZVODA ( BR DIJELA. . . . . . ˇ Cinjenica da je jedan student upisao jedan kolegij prikazuje se jednom n-torkom u relaciji UPISAO. . Ovo ne´e uzrokovati mnogo praznih vrijednosti atributa. . jer ni jedan od ovih c c z atributa sam nije dovoljan da jednoznaˇno odredi n-torku u toj relaciji. budu´i da ve´ina suradnika ima ˇefa. . 15 Samo one knjige koje su trenutno posudene predstavljene su n-torkom u relaciji POSUDBA. . ) . . IME DIJELA. KNJIGA ( REG BROJ. . JMBG ZENE. c OSOBA ( JMBG. c PROFESOR ( JMBG. . ) . ZEMLJA ( IME ZEMLJE. IME ZEMLJE ) . Tip entiteta OSOBA i (1 : 1) vezu U BRAKU S najbolje je (zbog neobaveznosti) prikazati pomo´u dvije relacije: c OSOBA ( JMBG. hijerarhijski model moˇemo smatrati specijalnom z c c z vrstom mreˇnog. Obavlja se sliˇno kao za binarne veze. ˇ ˇ ˇ BRAK ( JMBG MUZA. ) . IME PROIZVODA. . KOLICINA ) .3 Usporedba relacijskog modela s mreˇnim i hijerarhijskim z Mreˇni i hijerarhijski model su priliˇno sliˇni. ) . c Pretvorba involuiranih veza. . Pod-tip se prikazuje posebnom relacijom koja sadrˇi primarne atribute z nadredenog tipa i atribute specifiˇne za taj pod-tip. z z Pretvorba pod-tipova. atributi specifiˇni za profesore . koja sadrˇi primarne z atribute svih triju tipova entiteta zajedno s eventualnim atributima veze. atributi specifiˇni za nastavnike . c STUDENT ( JMBG. BR ISKAZNICE ) . Posebna relacija za prikaz veze je pogotovo preporuˇljiva ako relacija ima svoje atribute. PREZIME IME. . . Ustvari.3 prikazuje c se sljede´im relacijama. Na primjer hijerarhija tipova sa Slike 2. . BR DIJELA JEDNOSTAVNOG. ) . . relacijski model se po svom pristupu bitno razlikuje od ostala dva. Na primjer veza UPISAO iz fakultetske baze sa Slike 2. . atributi specifiˇni za studente . . . DATUM VJENCANJA ) . ˇ Tip entiteta SURADNIK i (1 : N ) vezu JE SEF ZA prikazujemo jednom relacijom: ˇ SURADNIK ( ID BR. . Kod ternarnih veza ˇija funkcionalnost nije (M : N : P ) broj primarnih atributa je c manji. ) . ) . . BR KOLEGIJA. . . . . PREZIME IME. . DATUM UPISA ) . . ADRESA. . . ˇ Cinjenica da se jedan proizvod jedne kompanije izvozi u jednu zemlju prikazana je jednom n-torkom u relaciji IZVOZI .2. Ternarna veza prikazuje se posebnom relacijom. koja se sastoji od primarnih atributa za oba tipa entiteta zajedno s eventualnim atributima veze. RELACIJSKI MODEL ˇ POSUDIVAC ( BR ISKAZNICE.2. ) . .

Njih treba smatrati sastavnim dijelom relacijskog modela. ). a zatim i poboljˇanu varijantu 3NF koja se zove Boyce-Coddc s ova normalna forma (BCNF). moˇe sadrˇavati nedoreˇenosti z z c koje treba otkloniti prije implementacije. Pretpostavimo da svaki kolegij ima jednog nastavnika. Stoviˇe.3 Normalizacija relacijske sheme Relacijska shema. atribut B od R je funkcionalno ovisan o atributu A od R (oznaka: A → B) ako vrijednost od A jednoznaˇno odreduje vrijednost od B. Mana je da se veza svaki put mora iznova uspostavljati. Mana je da korisnik moˇe c z upotrijebiti samo one veze koje su predvidene shemom pa su u skladu s time i materijalizirane. ˇitanje). I ovaj pristup ima svoje prednosti i mane. relacija je u 1NF ako je vrijednost svakog atributa jednostruka i nedjeljiva . OCJENA ) . a to troˇi vrijeme. Doduˇe. . MODELIRANJE PODATAKA • U mreˇnom ili hijerarhijskom modelu mogu´e je izravno prikazati vezu. Veza se “materijalizira” c pomo´u pointera. Ukoliko ve´ na poˇetku dobro uoˇimo sve potrebne entitete. c brisanje. z s kao kriterij za povezivanje. u jednom zapisu piˇe adresa drugog (vezanog) zapisa. To joˇ viˇe pove´ava fleksibilnost koriˇtenja baze.3. Analogna sc definicija primjenjuje se i za sluˇaj kad su A i B sloˇeni atributi (dakle skupovi atributa). BR KOLEGIJA → NASLOV KOLEGIJA . atribute i c c c veze. promotrimo sljede´u (loˇe oblikovanu) relaciju: c s ˇ IZVJESTAJ ( BR INDEKSA. Proces daljnjeg dotjerivanja sheme zove se normalizacija.to svojstvo ve´ je bilo ukljuˇeno u naˇu c c s definiciju relacije. Relacijski DML. Naime. No ako je polazna relacijska shema c bila loˇe oblikovana. mogu posluˇiti i razni drugi z (sloˇeniji) kriteriji. tj. Prednost je da je rad s bazom u tehniˇkom pogledu brz i efikasan. • U relacijskom modelu veze su samo implicitno naznaˇene time ˇto se isti ili sliˇan atribut poc s c javljuje u viˇe relacija.1 Funkcionalna ovisnost Za zadanu relaciju R. U praksi je lako nai´i na relacije koje odstupaju od 2NF. usporedbom vrijednosti atributa u n-torkama raznih relacija. dobivena iz ER-sheme na osnovu prethodnih uputa. a svaki nastavnik jednu sobu. Fagin je 1977. c Teorija normalizacije nije niˇta drugo nego formalizacija nekih intuitivno prihvatljivih principa o s “zdravom” oblikovanju sheme. 3NF). osim jednostavnih operacija s jednom relacijom. godina) E. NASLOV KOLEGIJA. U Poglavlju 3 upoznat ´emo neke relacijske c jezike. Teorija normalizacije zasnovana je na pojmu normalnih formi. mora omogu´iti slobodno kombiniranje podataka iz c raznih relacija. te na konfiguraciju svih veza u shemi. R. promjena. 5NF). tada nam nikakva daljnja normalizacija ne´e biti potrebna. postoje ograz c s niˇenja na funkcionalnost veze.F. no vrlo rijetko c se susre´u relacije u BCNF koje nisu u 4NF i 5NF. . s c s 2. 2. uveo ˇetvrtu i petu normalnu formu c (4NF. Codd je najprije definirao drugu i tre´u normalnu formu (2NF. c z Kao primjer. z s s c s Iz upravo reˇenog vidi se da je u relacijskom modelu teˇiˇte baˇeno na dinamiˇki aspekt (manje c zs c c pohranjivanja a viˇe manipuliranja). Prednost je da koz s ˇ risnik moˇe uspostaviti i one veze koje nisu bile predvidene u fazi modeliranja podataka. . BR SOBE NASTAVNIKA. Ovakav pristup ima svoje prednosti i c mane. tada ´e postupak normalizacije ispraviti te greˇke. BR KOLEGIJA) → OCJENA . Poˇeljno je takoder da taj jezik bude u ˇto ve´oj c z s c mjeri neproceduralan i razumljiv neposrednim korisnicima. . koji je u c zadanoj vezi sa zadanim zapisom. te “manevriranje” kroz shemu putem veza (dohvat prvog zapisa. i 1979. Relacije dobivene u skladu s potpoglavljem 2. Navodimo neke od funkcionalnih ovisnosti: (BR INDEKSA. dohvat idu´eg zapisa. Zato su “viˇe” normalne forme prvenstveno od c s teorijskog znaˇaja. osim jednakosti za vrijednost atributa. Dakle ako u isto vrijeme postoje u R c dvije n-torke s jednakom vrijednoˇ´u A. 3NF. IME NASTAVNIKA.2 morale bi u najmanju ruku biti u prvoj normalnoj formi (1NF).16 2. U svojim radovima (1970-1974. Veza nije materijalizirana. Mreˇni odnosno c s z hijerarhijski DML omogu´uje samo jednostavne operacije s jednim zapisom (upis. Zato upotrebljivost relacijskog DBMS bitno ovisi o izraˇajnim s z mogu´nostima njegovog jezika za rad s podacima. BCNF. ve´ se dinamiˇki uspostavlja za vrijeme rada s c c s podacima. potrebno je pretraˇivanje podataka. tada te n-torke moraju imati jednaku vrijednost B. BR KOLEGIJA.

Ova tranzc itivna ovisnost moˇe dovesti do anomalija: z . BR SOBE NASTAVNIKA ) . takvu da A nije u X. pa ih je poˇeljno ukloniti. imat ´emo kontradiktorne s c podatke. s • Ako ˇelimo promijeniti naslov kolegija 361 iz “Linearna algebra” u “Vektorski prostori”. budu´i da su ovisni samo o BR KOLEGIJA. Na primc jer OCJENA je potpuno funkcionalno ovisna o primarnom kljuˇu (BR INDEKSA. Obje relacije su sada u 2NF. koji je opet ovisan o BR KOLEGIJA. no B nije funkcionalno ovisan ni o jednom pravom podskupu od A. 17 Za zadanu relaciju R. tako da iz s stare relacije prebacimo u novu sve one atribute koji su parcijalno ovisni o kljuˇu: c ˇ IZVJESTAJ ( BR INDEKSA. BR KOLEGIJA → BR SOBE NASTAVNIKA . S c druge strane. relacija R je u 3NF ako za svaku funkcionalnu ovisnost X → A u R. BR KOLEGIJA). naime u njoj joˇ s uvijek postoji tzv. OCJENA ) . gdje srednji atribut nije kandidat za kljuˇ: c BR KOLEGIJA → IME NASTAVNIKA → BR SOBE NASTAVNIKA . IME NASTAVNIKA i BR SOBE NASTAVNIKA su parcijalno ovisni o kljuˇu. budu´i da je z c ovisan o IME NASTAVNIKA. a BR SOBE NASTAVNIKA nije primarni atribut. NASLOV KOLEGIJA. te promijeniti vrijednost c z za NASLOV KOLEGIJA u svim takvim n-torkama. Polaznu relaciju razbijamo u dvije. i pritom IME NASTAVNIKA nije kljuˇ. 2. No relacija KOLEGIJ zahtijeva daljnju normalizaciju. NASLOV KOLEGIJA. z c Prije navedena relacija KOLEGIJ nije u 3NF jer imamo ovisnost IME NASTAVNIKA → BR SOBE NASTAVNIKA . Svaki atribut relacije je funkcionalno ovisan o kljuˇu.3. • Pretpostavimo da svi studenti koji su upisali kolegij 361 odustanu od tog kolegija. NORMALIZACIJA RELACIJSKE SHEME BR KOLEGIJA → IME NASTAVNIKA . c z Preciznije. ako ˇelimo unijeti podatke o novom nastavniku i njegovoj sobi. tranzitivna ovisnost. c c Za BR SOBE NASTAVNIKA se kaˇe da je tranzitivno ovisan o BR KOLEGIJA. to ne moˇemo uˇiniti sve dok bar jedan z z c student ne upiˇe taj kolegij (naime ne smijemo imati praznu vrijednost primarnog atributa s BR INDEKSA). c ˇ Malo prije definirana relacija IZVJESTAJ nije u 2NF. no ta ovisnost ne mora biti potpuna. s c c Ove anomalije rjeˇavamo svodenjem relacije u 2NF. IME NASTAVNIKA → BR SOBE NASTAVNIKA .2. IME NASTAVNIKA. z 2. Ako zaboravimo izvrˇiti neku od promjena. a ne i o BR INDEKSA. vrijedi: X sadrˇi kljuˇ za R ili je A primarni atribut.2 Druga normalna forma Relacija je u drugoj normalnoj formi (2NF) ako je u 1NF i ako je svaki ne-primarni atribut potpuno funkcionalno ovisan o primarnom kljuˇu. atribut B od R je potpuno funkcionalno ovisan o (sloˇenom) atributu z A od R ako vrijedi: B je funkcionalno ovisan o A. BR KOLEGIJA. Parcijalne i tranzitivne ovisnosti mogu uzrokovati probleme kod manipuliranja s podacima. to ne c z moˇemo uˇiniti dok nastavnika ne zaduˇimo s bar jednim kolegijem i dok bar jedan student ne z c z upiˇe taj kolegij. Sliˇno. iz baze ´e nestati svi podaci o kolegiju 361. i to dovodi do anomalija: • Ako u bazu ˇelimo unijeti podatke o novom kolegiju. KOLEGIJ ( BR KOLEGIJA.3 Tre´a normalna forma c Relacija je u tre´oj normalnoj formi (3NF) ako je u 2NF i ako ne sadrˇi tranzitivne ovisnosti. tada z moramo na´i sve n-torke koje sadrˇe tu vrijednost za BR KOLEGIJA.3.3. Ako shodno tome pobriˇemo odgovaraju´e n-torke. Bit ´e onoliko promjena koliko ima studenata c koji su upisali kolegij 361.

KOLEGIJ ( BR KOLEGIJA. razbijanje relacije na dvije. NASLOV KOLEGIJA. te (1 : N ) veza izmedu KOLEGIJ i NASTAVNIK . s Situacija se moˇe opisati relacijom: z UPISAO ( BR INDEKSA. sve dok ga nismo zaduˇili s z z kolegijem. Ne moˇemo c z evidentirati ˇinjenicu da zadani nastavnik predaje zadani kolegij. i time prekidamo tranzitivnu ˇ ovisnost. Relacije su sada do kraja normalizirane. kao i prije. BR KOLEGIJA. NASTAVNIK ( IME NASTAVNIKA. tada iz baze nestaju svi podaci o tom nastavniku i njegovoj sobi. s . Primjer za to moˇemo konstruirati tako da gledamo relaciju u kojoj postoje dva kandidata z za kljuˇ. Problemi s relacijom UPISAO izbjegli bi se da smo ve´ u fazi modeliranja entiteta i veza uoˇili da c c zapravo imamo posla s dvije nezavisne binarne veze: (N : M ) veza izmedu STUDENT i NASTAVNIK . no ne i u BCNF jer postoji ovisnost: IME NASTAVNIKA → BR KOLEGIJA i pritom IME NASTAVNIKA nije kandidat za kljuˇ. Ako svi studenti odustanu. Relacija nije ni u 2NF. MODELIRANJE PODATAKA • Ne moˇemo unijeti podatke o novom nastavniku i njegovoj sobi. ˇto oteˇava aˇuriranje. Sad je relacija u 3NF. IME NASTAVNIKA ) . No mi moˇemo drukˇije izabrati primarni kljuˇ: z c c UPISAO ( BR INDEKSA. IME NASTAVNIKA ) . c Oˇito je relacija koja je u BCNF takoder i u 2NF i 3NF. BR SOBE NASTAVNIKA ) . OCJENA ) . i preklapaju se u bar jednom atributu. oba kljuˇa su sloˇena. Sad su obje relacije u BCNF. no nisu c u BCNF. KLASA ( BR INDEKSA. Rjeˇenje problema je. BR KOLEGIJA ) . kolegije i nastavnike odmah prikazali posebnim tipovima entiteta. onoliko puta koliko ima studenata. Primijetimo da bi konaˇnu shemu odmah dobili da smo u fazi c modeliranja entiteta postupili ispravno. IME NASTAVNIKA ) . Svaki student upisuje viˇe kolegija. razbijamo je u dvije. PREDAJE ( IME NASTAVNIKA. Da bi relaciju KOLEGIJ prebacili u 3NF. • Da bi promijenili broj sobe nastavnika. briˇe se evidencija s z z s da zadani nastavnik predaje zadani kolegij. ali svaki nastavnik predaje samo s jedan kolegij. IME NASTAVNIKA. Takoder. c Zbog odstupanja od BCNF nastaju sliˇne anomalije kao kod odstupanja od 3NF. Prekida se nepoˇeljna funkcionalna s z ovisnost. BR KOLEGIJA. moramo izvrˇiti promjenu u svakoj n-torki koja odgovara s nekom kolegiju kojeg predaje taj nastavnik. no ima samo jednog nastavnika za zadani kolegij. c c z Na primjer neka na fakultetu jedan kolegij predaje viˇe nastavnika.3. veza nastavnika i kolegija je zapisana s velikom redundancijom.18 2. BR KOLEGIJA ) . Ternarna veza je tada suviˇna. • Ako nastavnik (privremeno) ne predaje ni jedan kolegij. te studente. Relacija je u Boyce-Codd-ovoj normalnoj formi (BCNF) ako je svaka njezina determinanta ujedno i kandidat za kljuˇ. 2.4 Boyce-Codd-ova normalna forma Determinanta je atribut (ili kombinacija atributa) o kojem je neki drugi atribut potpuno funkcionalno ovisan. No postoje relacije koje su u 3NF. Konaˇna relacijska shema koja zamjenjuje polaznu relaciju IZVJESTAJ izgleda ovako: c ˇ IZVJESTAJ ( BR INDEKSA. sve dok bar jedan student ne upiˇe c s taj kolegij kod tog nastavnika. jer postoji parcijalna ovisnost: IME NASTAVNIKA → BR KOLEGIJA.

proizvoda i zemalja: IZVOZI ( KOMPANIJA. Relacija moˇe u c z jednom trenutku izgledati kao na Tabelarnom prikazu 2.3.2. c U nastavku uzimamo da vrijedi pravilo: ˇim kompanija izvozi u neku zemlju. viˇeznaˇnim s c s c ovisnostima: . Jedna n-torka oznaˇava da zadana kompanija zadani proizvod izvozi u zadanu zemlju. moramo upisati n-torku za svaku zemlju u koju IBM izvozi. da bi c z dodali novi proizvod IBM-a. ve´ tzv. ako c HP poˇne izvoziti u Kinu. morat ´e se ubaciti posebna n-torka za svaki njegov proizvod.2.2: Relacija koja nije u ˇetvrtoj normalnoj formi. PROIZVOD.3: Svodenje na ˇetvrtu normalnu formu. Tada relacija oˇito sadrˇi veliku dozu redundancije.2 tada odgovaraju podaci iz Tabelarnog prikaza 2. Podacima iz prethodnog Tabelarnog prikaza 2. s z To je zato ˇto redundancija nije bila uzrokovana funkcionalnim ovisnostima. ZEMLJA ) . PROIZVOD ) . Lagano je provjeriti da je relacija u BCNF. Na primjer. IZVOZI KOMPANIJA IBM IBM IBM IBM IBM IBM HP HP HP HP HP HP Fujitsu Fujitsu PROIZVOD Desktop Desktop Desktop Mainframe Mainframe Mainframe Desktop Desktop Desktop Server Server Server Mainframe Mainframe ZEMLJA Francuska Italija Velika Britanija Francuska Italija Velika Britanija Francuska ˇ Spanjolska Irska Francuska ˇ Spanjolska Irska Italija Francuska Tabelarni prikaz 2. NORMALIZACIJA RELACIJSKE SHEME 19 2. PRODAJE KOMPANIJA IBM IBM IBM HP HP HP Fujitsu Fujitsu RADI KOMPANIJA IBM IBM HP HP Fujitsu PROIZVOD Desktop Mainframe Desktop Server Mainframe ZEMLJA Francuska Italija Velika Britanija Francuska ˇ Spanjolska Irska Italija Francuska Tabelarni prikaz 2. ZEMLJA ) . PRODAJE ( KOMPANIJA. Sliˇno. ona odmah izvozi sve c svoje proizvode u tu zemlju.3. Promatrajmo relaciju koja prikazuje s c vezu izmedu kompanija. c c Redundancija ´e se eliminirati ako zamijenimo polaznu relaciju IZVOZI s dvije manje relacije RADI c i PRODAJE : RADI ( KOMPANIJA.5 Viˇeznaˇna ovisnost i ˇetvrta normalna forma s c c ˇ Cetvrtu normalnu formu najlakˇe je opisati pomo´u primjera.3. c Dosadaˇnja pravila normalizacije nam ne pomaˇu da eliminiramo redundanciju u relaciji IZVOZI .

IZVOZI nije u 4NF i zato je treba rastaviti na RADI i PRODAJE (koje jesu u 4NF). Projektant baze podataka treba procijeniti kada treba provesti normalizaciju do kraja a kada ne. z U gornjem primjeru. Normalizacijom se velike relacije razbijaju na mnogo manjih. na primjer A →→ B. s c s c Znaˇi. naravno. U naˇoj relaciji IZVOZI . R je u 4NF ako je u BCNF i sve viˇeznaˇne ovisnosti u R su zapravo funkcionalne s c ovisnosti. Promatrana z c s relacija IZVOZI nastala je zbog pokuˇaja da se odnos triju tipova entiteta KOMPANIJA. C-vrijednost) ovisi samo o A-vrijednosti. z 2. z c c c . pa relacija nije u 3NF. relacija IZVOZI je c s c u 4NF i ne moˇemo je rastaviti na dvije manje relacije. Ekvivalentno. z z c Nije preporuˇljivo razbijati ovu relaciju na dvije. promatrajmo relaciju ˇ KUPAC ( PREZIME IME. Na primjer ako skup proizvoda koje zadana kompanija izvozi varira od zemlje do zemlje. PROIZVOD. tada prije uoˇene viˇeznaˇne ovisnosti ne vrijede. a ne i o C-vrijednosti. KOMPANIJA →→ ZEMLJA . Ista definicija primjenjuje se i kad su A. C). Relacija R je u ˇetvrtoj normalnoj formi (4NF) ako vrijedi: kad god postoji viˇeznaˇna ovisnost c s c u R. POSTANSKI BROJ. Peta normalna forma. 2. Za tu procjenu je vaˇno razumijevanje znaˇenja podataka i naˇina kako ´e se oni koristiti. Zapravo se ovdje radi o dvije nezavisne binarne veze. Postoje. No c ˇ mi znamo da POSTANSKI BROJ . ni jedna od uoˇenih viˇeznaˇnih ovisnosti nije funkcionalna ovisnost. GRAD je funkcionalno ovisan o POSTANSKI BROJ . c Efikasno ˇitanje podataka . c Odstupanje od 4NF opet moˇemo tumaˇiti kao greˇku u modeliranju entiteta i veza. GRAD. Koji put je potrebno neku c c relaciju i dalje normalizirati do BCNF ili 4NF. nije od praktiˇnog znaˇaja. Deˇava se da nekoliko atributa u relaciji ˇine cjelinu koja se u aplikacijama nikad z s c ne rastavlja na sastavne dijelove. Sloˇeni atribut . Budu´i da c c se podaci iz adrese koriste i aˇuriraju “u paketu”. MODELIRANJE PODATAKA Zadana je relacija R(A. Sliˇno.3. ULICA ) . s ZEMLJA tretira kao ternarna veza. Kod c ˇitanja je ˇesto potrebno podatke iz malih relacija ponovo sastaviti u ve´e n-torke. koja se takoder navodi u literaturi. skup zemalja u koje zadana kompanija izvozi zadani proizvod ovisi samo o kompaniji a ne i o proizvodu. Viˇeznaˇna ovisnost A →→ B vrijedi ako: skup B-vrijednosti s c koje se u R pojavljuju uz zadani par (A-vrijednost. ˇ Strogo govore´i. B i C sloˇeni atributi (dakle skupovi atributa). Navesti ´emo dva takva z c razloga. Uspostavljanje c c c veza medu podacima u manjim relacijama traje znatno dulje nego ˇitanje podataka koji su ve´ c c povezani i upisani u jednu veliku relaciju. i prave ternarne veze. skup proizvoda koje zadana kompanija izvozi u zadanu zemlju c ovisi samo o kompaniji a ne o zemlji.6 Razlozi zbog kojih se moˇe odustati od normalizacije z Za ve´inu praktiˇnih primjera dovoljno je relacije normalizirati do 3NF.20 KOMPANIJA →→ PROIZVOD . tada su svi atributi od R funkcionalno ovisni o A. c c Postoje razlozi zbog kojih iznimno moˇemo odustati od pune normalizacije. ne moˇe do´i do prije spominjanih anomalija. B. GRAD i ULICA ˇine cjelinu koja se zove adresa. Na primjer.

c c Zato niti ne postoji standardna sintaksa. a LECTURER sadrˇi podatke z c o nastavnicima.1: Demo-baza o fakultetu.F. COURSE nabraja kolegije.1 Relacijska algebra Relacijsku algebru uveo je E. Uzimamo da relacije sadrˇe n-torke koje se vide u Tabelarnom prikazu 3. REPORT ( SNO. SNAME. stolje´a. TITLE. gradenih od relacija te unarnih i binarnih operatora (ˇiji operandi su relacija a rezultat je opet relacija). a ne o praktiˇnom jeziku kojeg bi ljudi zaista neposredno koristili. Svaki algebarski izraz predstavlja c jedan upit (pretraˇivanje). ROOMNO ) . LECTURER ( LNAME.3 JEZICI ZA RELACIJSKE BAZE PODATAKA 3. kao primjer ´e sluˇiti pojednostavnjena (engleska) verzija naˇe baze c c z s o fakultetu: STUDENT ( SNO. Rijeˇ je o c c teorijskoj (matematiˇkoj) notaciji. Student je jednoznaˇno odreden svojim brojem iz indeksa SNO. COURSE ( CNO. Relacija STUDENT popisuje studente. CNO. Relacijska algebra se svodi na izvrednjavanje algebarskih izraza. kolegij je jednoznaˇno c 21 . z STUDENT SNO SNAME 876543 Jones 864532 Burns 856434 Cairns 876421 Hughes COURSE CNO TITLE 216 Database Systems 312 Software Engineering 251 Numerical Analysis 121 Compilers LEVEL 2 1 3 2 LNAME Black Welsh Quinn Holt REPORT SNO CNO 876543 216 864532 216 864532 312 856434 121 876421 312 876543 251 864532 251 864532 121 MARK 82 75 71 49 39 70 69 78 LECTURER LNAME ROOMNO Black 1017 Welsh 1024 Holt 2014 Quinn 1010 Tabelarni prikaz 3. LNAME ) . z U ovom i idu´in poglavljima. MARK ) .1. LEVEL ) . Codd u svojim radovima iz 70-tih godina 20.

3: Rezultati skupovnih operacija. Za svakog studenta s pamtimo njegovo ime SNAME i godinu studija LEVEL. R minus S . intersect nije nuˇan. .2: Relacija kompatibilna sa STUDENT . skup n-torki koje su u R ili u S (ili u obje relacije).1 Skupovni operatori Relacije su ustvari skupovi n-torki. c z Za primjer. Za kolegij se pamti njegov naslov TITLE i ime (jednog) nastavnika koji ga predaje LNAME . Da bi se operatori mogli primijeniti.22 3.3. z c Neka R i S oznaˇavaju relacije. relacije R i S moraju biti “kompatibilne”. Primijetimo da uvijek vrijedi: R intersect S = R minus (R minus S) . Tada primjenom skupovnih operatora dobivamo rezultate iz Tabelarnog prikaza 3. skup n-torki koje su u R no nisu u S. .2. Znaˇi. skup n-torki koje su u R i takoder u S. . Relacija REPORT biljeˇi koji je student upisao koji kolegij i koju ocjenu MARK je z dobio. to jest moraju imati isti stupanj i iste atribute (ista imena i tipove). Tada je: c R union S . Zato na njih moˇemo primjenjivati uobiˇajene skupovne operatore. u kojoj se nalaze ntorke popisane u Tabelarnom prikazu 3. NEW STUDENT SNO SNAME 876342 Smith 865698 Turner 875923 Murphy 856434 Cairns 871290 Noble LEVEL 3 2 2 3 1 Tabelarni prikaz 3. gradenu kao STUDENT . STUDENT union NEW STUDENT SNO SNAME LEVEL 876543 Jones 2 864532 Burns 1 856434 Cairns 3 876421 Hughes 2 876342 Smith 3 865698 Turner 2 875923 Murphy 2 871290 Noble 1 STUDENT minus SNO SNAME 876543 Jones 864532 Burns 876421 Hughes NEW STUDENT LEVEL 2 1 2 STUDENT intersect NEW STUDENT SNO SNAME LEVEL 856434 Cairns 3 Tabelarni prikaz 3. . 3. a nastavnici se razlikuju po svojim imenima LNAME . .1. . promatramo relaciju NEW STUDENT . JEZICI ZA RELACIJSKE BAZE PODATAKA odreden svojom ˇifrom CNO. R intersect S . Za svakog nastavnika poznat nam je broj njegove sobe ROOMNO. .

<.1. RESULT1 := STUDENT where LEVEL = 1 . c Upit 1: Pronadi sve studente na stupnju (godini) 1. =. A2 . c RESULT3 := REPORT where ((CNO=216) and (MARK >70)) . Izraˇunate vrijednosti izraza (odgovori na upite) vide se u Tabelarnom prikazu 3. Upit 2: Pronadi sve kolegije s naslovom ‘Database Systems’. • logiˇkih operatora and. RELACIJSKA ALGEBRA 23 3. Selekciju na relaciji R u skladu s Booleovskim uvjetom B oznaˇavamo s R where B. Smatrat ´emo da projekcija ima viˇi prioritet od ostalih operacija.3. Projekciju relacije R na njene atribute A1 . Am ]. . .4: Rezultati selekcije. >. RESULT2 := COURSE where TITLE = ‘Database Systems’ . RESULT1 SNO SNAME 864532 Burns LEVEL 1 RESULT2 CNO TITLE 216 Database Systems LNAME Black RESULT3 SNO CNO 876543 216 864532 216 MARK 82 75 Tabelarni prikaz 3. Izraˇunate vrijednosti izraza (odgovori na upite) vide se u Tabelarnom prikazu 3. . 3. RESULT2 := ( COURSE where CNO = 312 )[LNAME ] . c Navest ´emo nekoliko primjera od kojih svaki sadrˇi jedan upit sa selekcijom i odgovaraju´i izraz u c z c relacijskoj algebri. Upit 3: Pronadi sve studente koji su iz kolegija 216 dobili ocjenu ve´u od 70. A2. .1. ≤. .5. not. • operatora za usporedivanje =. c s Navest ´emo dva primjera koji se sastoje od upita s projekcijom i odgovaraju´eg izraza u relacijskoj c c algebri. or.2 Selekcija Selekcija je unarni operator koji izvlaˇi iz relacije one n-torke koje zadovoljavaju zadani Booleovski c uvjet. .1. . Am oznaˇavat ´emo c c s R[A1. Upit 2: Pronadi ime nastavnika koji predaje kolegij 312. s time da se u rezultiraju´oj relaciji c c eliminiraju n-torke duplikati.3 Projekcija Projekcija je unarni operator koji iz relacije izvlaˇi zadane atribute. ≥.4. RESULT1 := LECTURER[ROOMNO] . . . c Upit 1: Pronadi brojeve soba od svih nastavnika. Uvjet B c je formula koja se sastoji od: • operanada koji su ili konstante ili atributi.

Tada algebarski izraz R times S daje Kartezijev produkt c c od R i S.SNAME . DO NOT TAKE SNO CNO 876543 312 876543 121 856434 216 856434 312 856434 251 876421 216 876421 251 876421 121 PAIRS TEMP.SNO)) ) [TEMP.6.SNO < STUDENT. 3. a zadnjih n2 komponenti ˇine n2-torku u S.7. s time da se po potrebi c to ime proˇiruje imenom polazne relacije (sliˇno kao za komponentu zapisa u C-u). PAIRS := ( (TEMP times STUDENT ) where ( (TEMP. STUDENT. Da ne bi doˇlo do pometnje s s imenima atributa. s c Kao primjer koriˇtenja Kartezijevog produkta.24 RESULT1 ROOMNO 1017 1024 2014 1010 3. JEZICI ZA RELACIJSKE BAZE PODATAKA RESULT2 LNAME Welsh Tabelarni prikaz 3.SNAME ] . Drugi primjer pronalazi sve parove studenata koji su na istom stupnju (godini). nadimak) za relaciju STUDENT : TEMP aliases STUDENT .1. DO NOT TAKE := ALL COMB minus REPORT [SNO.LEVEL) and (TEMP. Rezultati za oba upita vide se u Tabelarnom prikazu 3.5 Prirodni spoj Prirodni spoj (natural join) je binarni operator primjenjiv na dvije relacije R i S koje imaju bar jedan zajedniˇki atribut. Primjer za prirodni spoj vidi se u Tabelarnom prikazu 3. Pretpostavlja se da su zajedniˇki atributi c dviju relacija toˇno oni koji imaju ista imena. c Prirodni spoj omogu´uje nam da u naˇoj fakultetskoj bazi podataka odgovorimo na sloˇenije upite c s z koji zahtijevaju uspostavljanje veza izmedu podataka u raznim tablicama. ispisat ´emo za svakog studenta sve kolegije koje on s c nije upisao: ALL COMB := STUDENT [SNO] times COURSE [CNO] . . U rezultiraju´oj relaciji zajedniˇki atribut c c c se pojavljuje samo jednom.1. CNO] . 3. c Atribut u R times S ima isto ime kao odgovaraju´i atribut u R odnosno S.SNAME Hughes STUDENT. dakle skup svih (n1 + n2 )-torki ˇijih prvih n1 komponenti ˇine n1 -torku u R.6: Rezultati primjene Kartezijevog produkta. R join S sastoji se od svih n-torki dobivenih spajanjem jedne n-torke iz R s jednom c n-torkom iz S koja ima iste vrijednosti zajedniˇkih atributa. specijalnim operatorom aliases uvodimo “pseudonim” (drugo ime.5: Rezultati projekcije.SNAME Jones Tabelarni prikaz 3. Za to nam je potrebno napraviti Kartezijev produkt relacije STUDENT sa samom sobom.4 Kartezijev produkt Neka su R i S relacije stupnja n1 odnosno n2.LEVEL = STUDENT.

D) vrijedi: R join S = ( (R times S) where R. za relacije R(A.C.C ) [A. C) i z S(C. Prirodni spoj uvijek se moˇe izraziti preko ostalih operatora. Upit 1: Pronadi imena svih studenata koji su upisali kolegij 251. RELACIJSKA ALGEBRA R A a1 a2 a3 a4 S B b1 b1 b2 25 B b1 b1 b2 b2 C c1 c1 c2 c3 C c1 c1 c3 D d1 d2 d3 R join S A B a1 b1 a1 b1 a2 b1 a2 b1 a4 b2 C c1 c1 c1 c1 c3 D d1 d2 d1 d2 d3 Tabelarni prikaz 3. U Tabelarnom prikazu 3. RESULT1 := ( (REPORT where CNO = 251) join STUDENT ) [SNAME ] .8 nalazi se detaljnije izvrednjavanje Upita 3.D]. Upit 3: Pronadi imena nastavnika koji predaju kolegije koje je upisao bar jedan student na stupnju (godini) 2. Na primjer.3. . B.1.B.8: Izvrednjavanje Upita 3 s prirodnim spojem.7: Primjer prirodnog spoja. RESULT2 := ( (COURSE where CNO = 351) join LECTURER ) [ROOMNO] . RESULT3 := ( ( (STUDENT where LEVEL=2) join REPORT ) join COURSE ) [LNAME ] . STUDENT where SNO SNAME 876543 Jones 876421 Hughes LEVEL = 2 LEVEL 2 2 (STUDENT where SNO SNAME 876543 Jones 876543 Jones 876421 Hughes LEVEL=2) join LEVEL CNO 2 216 2 251 2 312 REPORT MARK 82 70 39 RESULT3 LNAME Black Quinn Welsh ( (STUDENT where LEVEL=2) join REPORT ) join COURSE SNO SNAME LEVEL CNO MARK TITLE 876543 Jones 2 216 82 Database Systems 876543 Jones 2 251 70 Numerical Analysis 876421 Hughes 2 312 39 Software Engineering LNAME Black Quinn Welsh Tabelarni prikaz 3. Upit 2: Pronadi broj sobe nastavnika koji predaje kolegij 351.C = S.

26 3. Rezultat dijeljenja R sa S.B] . Kao odgovor dobivamo brojeve studenata 856434.B istina. Na primjer. tada je: R divideby S = R[A. C.9 nalazi se najprije jedan apstraktni primjer dijeljenja. jedini student koji zadovoljava upit je Burns. Primjenjiv je pod istim c uvjetima i daje kao rezultat relaciju s istom gradom (shemom). RESULT1 := ( (REPORT [SNO. Dijeljenje se takoder moˇe izraziti pomo´u prethodno opisanih operatora. c s . U Tabelarnom prikazu 3.A θ S. Prirodni spoj z c se moˇe smatrati specijalnim sluˇajem theta-spoja. z s RESULT2 := REPORT [SNO. Ovdje x i y predstavljaju grupu od jedne ili viˇe s vrijednosti atributa. je skup onih n-torki Kartezijevog produkta R sa S za koje je predikat R.8 Vanjski spoj Vanjski spoj (outer join) je binarni operator vrlo sliˇan prirodnom spoju. 3. pisano R join(A θ B) S. D) i S(C. 864532. D).7 Dijeljenje Neka je R relacija stupnja n. s R1 SNO s1 s1 s1 s2 s2 s3 s4 CNO c1 c2 c3 c1 c2 c1 c4 R2 CNO c1 R3 CNO c1 c2 c3 R1 divideby R2 SNO s1 s2 s3 R1 divideby R3 SNO s1 Tabelarni prikaz 3. z c 3.6 Theta-spoj Theta-spoj relacija R i S. ako imamo z c relacije R(A. ≥).CNO] divideby COURSE [CNO]) join STUDENT ) [SNAME ]. Theta-spoj se uvijek moˇe izraziti pomo´u Kartezijevog produkta i selekcije. Simbol θ predstavlja jedan od operatora za usporedbu (=. < . >. a S relacija stupnja m. ≤. =. Operator dijeljenja predstavlja naˇin implementiranja univerzalne kvantifikacije ∀ u relacijskoj algec bri.1. s Upit 2: Pronadi brojeve onih studenata koji su upisali barem one kolegije koje je upisao student s brojem 856434 (i moˇda joˇ neke kolegije). Dalje slijede primjeri s naˇom fakultetskom bazom podataka.B] minus ( (R[A. je skup svih (n − m)-torki x takvih da se ntorke x. oznakom R divideby S. Upit 1: Pronadi imena studenata koji su upisali sve kolegije. JEZICI ZA RELACIJSKE BAZE PODATAKA 3. B.9: Apstraktni primjer djeljenja.1. i neka se svi atributi od S pojavljuju i u R.B] times S) minus R )[A. Naime. y pojavljuju u R za sve m-torke y u S.1. No sadrˇaj od R outerjoin S je neˇto z s bogatiji nego sadrˇaj R join S. pored svih n-torki iz R join S. relacija R outerjoin S sadrˇi i z z sve “nesparene” (nespojene) n-torke iz R odnosno S (s time da su te nesparene n-torke na odgovaraju´i c naˇin proˇirene null vrijednostima).CNO] divideby (REPORT where SNO=856434)[CNO] . Za naˇe konkretne podatke.

s . Vanjski spoj obiˇno se koristi za traˇenje podataka koji ne zadovoljavaju neki uvjet. tada t. not f1 .2. not) i kvantifikatora ∃ c (postoji) i ∀ (za svako).2 Relacijski raˇun c Relacijski raˇun takoder je bio predloˇen od E. gdje je A atribut od R. >. • Ako je f jedna WFF u kojoj se t pojavljuje kao slobodna varijabla. Ako je t varijabla koja “prolazi” relacijom R. i not f2 . Na primjer: c z Upit 1: Pronadi imena studenata koji nisu upisali ni jedan kolegij. ˇto znaˇi da z s c je t n-torka u relaciji R. Dobro oblikovane formule (WFF) gradene od logiˇkih veznika (and.7. R outerjoin S izgleda kao na Tabelarnom prikazu 3.10: Primjer vanjskog spoja. Upit se izraˇava tako da zadamo predikat c c z kojeg n-torke moraju zadovoljavati. Uvjeti takoder mogu biti oblika R(t). R A a1 a2 a3 a4 S B b1 b1 b2 B b1 b1 b2 b2 C c1 c1 c2 c3 C c1 c1 c3 D d1 d2 d3 R outerjoin S A B C D a1 b1 c1 d1 a1 b1 c1 d2 a2 b1 c1 d1 a2 b1 c1 d2 a4 b2 c3 d3 a3 b2 c2 − Tabelarni prikaz 3.A oznaˇava A-komponentu od t. =. f1 or f2 . u skladu sa sljede´im pravilima: c • Svaki uvjet je WFF.ˇ 3.F. kao alternativa relacijskoj algebri. • Ako su f1 i f2 WFF.1 Raˇun orijentiran na n-torke c U izrazima se pojavljuju sljede´i elementi: c Varijable-n-torke poprimaju vrijednosti iz imenovane relacije. 3. <. RESULT1 := ( (STUDENT outerjoin REPORT ) where (CNO is null) ) [SNAME ] . c Uvjeti oblika x θ y. Inaˇe je slobodna). tada su ∃ t (f) i ∀ t (f) takoder WFF. ≥).A. Postoje dvije vrste relacijskog raˇuna: raˇun orijentiran na n-torke (gdje su osnovni objekti n-torke) c c i raˇun orijentiran na domene (gdje su osnovni objekti vrijednosti iz domena za atribute). c 3. (Pojava varijable u WFF je vezana ukoliko je ta varijabla uvedena kvantifikatorom. ≤. gdje je θ operator za usporedivanje (=.10. a drugo moˇe biti konstanta. c • Niˇta drugo nije WFF. RELACIJSKI RACUN 27 Dakle za isti primjer R i S kao u Tabelarnom prikazu 3. or. Rijeˇ je c z c o matematiˇkoj notaciji zasnovanoj na predikatnom raˇunu. Bar jedno od x i y mora biti oblika t.2. tada su to i f1 and f2 . Codd-a.

SNO = s. CNO : 121)} . C. B : v2. Slijede primjeri upita za naˇu fakultetsku bazu podataka. .SNO | STUDENT (s) and s.28 3. Upit 3: Pronadi brojeve i imena studenata koji su upisali kolegij 121. .CNO | COURSE(c) and ∃ r (REPORT (r) and r. a f je WFF koja sadrˇi t. Dalje slijede primjeri vezani uz naˇu fakultetsku bazu podataka (potpoglavlje 3.2. s Upit 1: Pronadi sve brojeve kolegija. atributi od relacije R. Upit 2: Pronadi brojeve svih studenata na stupnju 1. kao slobodne c z varijable. .CNO and r. JEZICI ZA RELACIJSKE BAZE PODATAKA Izraz raˇuna orijentiranog na n-torke je oblika: {t. {C | COURSE (CNO : C)} .CNO = r. su ili varijable ili konstante. N | STUDENT (SNO : S.B. .SNO = r. {c. . . . SNO : S) and STUDENT (SNO : S.SNAME | STUDENT (s) and ∃ r (REPORT (r) and r. SNAME : N ) and REPORT (SNO : S. {S.2 Raˇun orijentiran na domene c Varijable “prolaze” domenama a ne relacijama. T | COURSE(CNO : C. . s. imamo takozvane uvjete ˇlanstva oblika: c R(A : v1. .SNO and r.). TITLE : T ) and ∃ S (REPORT (CNO : C. .A. v. Upit 5: Pronadi imena onih studenata koji su upisali sve kolegije. Upit 3: Pronadi brojeve i imena studenata koji su upisali kolegij 121.SNO and s. varijablec n-torke. c s Upit 1: Pronadi sve brojeve kolegija. {c.SNO)} . Upit 2: Pronadi brojeve svih studenata na stupnju 1. {s. Na primjer.SNO. v3 . {s. u. . 3. . | f}. LEVEL : 1)} . a v1 .SNAME | STUDENT (s) and ∀c ∃r (COURSE (c) and REPORT (r) and c. LEVEL : 1) je istina ako i samo ako postoji n-torka u relaciji STUDENT takva da je SNO = 872501. gdje su A. . A. {S | STUDENT (SNO : S.CNO = 121)} . . gdje su t. . C : v3. . v. Pravila za WFF su ista kao u raˇunu orijentiranom na n-torke.1). v2 . LEVEL : 1))} . u. v. su atributi odgovaraju´ih relacija. C. {s.SNO = s.CNO | COURSE(c)} . {C. . . Takoder. Upit 4: Pronadi brojeve onih kolegija koje je upisao bar jedan student na stupnju 1.C. . B. LEVEL = 1. B. .CNO = c. uvjet STUDENT (SNO : 872501. Upit 4: Pronadi brojeve i naslova kolegija koje je upisao bar jedan student na stupnju 1.LEVEL = 1))} . u. .CNO and ∃ s (STUDENT (s) and s.LEVEL = 1} .

. aˇuriranje relacija (upis. CNO : C)))} (ovdje se implikacija if .SNO = REPORT. Najraˇireniji danaˇnji s c c s s jezik SQL zasnovan je na raˇunu orijentiranom na n-torke. sortiranje i formatiranje ispisa. SNAME : N ) and ∀ C (if COURSE (CNO : C) then REPORT (SNO : S. Stoga praktiˇni relacijski c c c jezici (namijenjeni neposrednim korisnicima) viˇe liˇe na raˇun nego na algebru. Upit 2: Pronadi brojeve i imena studenata koji su upisali kolegij 121. SELECT STUDENT. SQL ´emo detaljnije proraditi na vjeˇbama. te ga time uˇinile vrlo popularnim i dostupnim na svim c vaˇnijim raˇunalnim platformama. Jezik se postepeno usavrˇavao. jezik takoder omogu´uje: definiranje relacija. No lagano se realiziraju i sve operacije iz relacijske alc c gebre. Rezultat upita se shva´a kao nova privremena relacija. indeksa). STUDENT. then moˇe zapisati pomo´u and. godine). c c SQL je uglavnom zasnovan na relacijskom raˇunu. SNAME FROM STUDENT WHERE LEVEL = 1 ORDER BY SNAME . . DEC. stolje´a). . c 3.1 Postavljanje upita Upit se postavlja fleksibilnom naredbom SELECT (nije isto ˇto i operacija selekcije u relacijskoj s algebri). c definiranje “pogleda” (virtuelnih relacija izvedenih iz postoje´ih). . Zbog pojave raznih “dijalekata” donesen je ISO/ANSI standard za SQL (zadnja verzija 1998. REPORT WHERE STUDENT. te kontrolu sigurnosti.SNO AND REPORT.3.CNO = 121.SNAME FROM STUDENT.SNO. z c 29 Relacijski raˇun je u ve´oj mjeri “neproceduralan” nego relacijska algebra. kasne 70-te godine 20. c 3. brisanje n-torki).3 Jezik SQL Structured Query Language (SQL) razvio je IBM u sklopu projekta “System R” (Chamberlin i drugi. neke aritmetiˇke operacije s podacima. bile su prisiljene da se prilagode SQL-u. SELECT SNO. c Upit 1: Pronadi brojeve i imena svih studenata na stupnju 1. . Druge softverske ku´e (na primjer Oracle s c Corporation) ugradile su SQL u svoje DBMS-e. s time da je matematiˇka notacija zamijenjena kljuˇnim rijeˇima nalik na govorni engleski jezik. ili (ukoliko ˇelimo uzlazno sortirani ispis) z SELECT SNO. JEZIK SQL Upit 5: Pronadi imena onih studenata koji su upisali sve kolegije.3. c z Sada ´emo navesti samo nekoliko primjera. ) koje su razvijale z c c svoje jezike. or i not). izvedena iz stalnih (po tome je SQL c sliˇan relacijskoj algebri). Osim postavljanja upita. Drugi poznati jezik QBE (Query By c Example) koristi raˇun orijentiran na domene. utjecaj na fiziˇku gradu baze (na c c primjer stvaranje tzv. Preostale ku´e (INGRES Corporation. a njegova dotjerana varijanta pojavljuje c s se u danaˇnjem IBM-ovom relacijskom DBMS-u zvanom DB2. SNAME FROM STUDENT WHERE LEVEL = 1. . c z promjena. {N | ∃ S (STUDENT (SNO : S.3.

SNO FROM STUDENT TEMP1. SNAME FROM STUDENT WHERE SNO IN (SELECT SNO FROM REPORT WHERE CNO = 121).SNAME FROM STUDENT.SNO AND REPORT.SNO. REPORT.30 3. c SELECT TEMP1. Budu´i da SQL nema univerzalni kvantifikator ali ima egzistencijalni.LNAME = ’Quinn’. upit moramo ovako preformulirati: “Pronadi brojeve onih studenata za koje ne postoji kolegij kojeg oni nisu upisali”.SNO < TEMP2.LEVEL. SNAME FROM STUDENT WHERE SNO IN (SELECT SNO FROM REPORT WHERE CNO IN (SELECT CNO FROM COURSE WHERE LNAME = ’Quinn’)).SNO. Stoviˇe. Upit 4: Pronadi sve parove brojeva studenata takve da su odgovaraju´i studenti na istom stupnju. to je mogao biti i thetas spoj.CNO AND COURSE. . TEMP2. c c Upit 6: Pronadi brojeve onih studenata koji su upisali sve kolegije.LEVEL = TEMP2.CNO = COURSE. Ovdje smo uveli drugo ime (alias) za relaciju STUDENT . JEZICI ZA RELACIJSKE BAZE PODATAKA Ovdje smo morali proˇiriti imena atributa da bi izbjegli dvoznaˇnost. Vidimo kako SQL SEs c ˇ LECT naredba zamjenjuje prirodni spoj iz relacijske algebre. Upit 5: Pronadi sve podatke o studentima koji nisu upisali kolegij 121. SELECT * FROM STUDENT WHERE SNO NOT IN (SELECT SNO FROM REPORT WHERE CNO = 121). Drugo rjeˇenje za isti upit glasi: s SELECT SNO. Drugo rjeˇenje za isti upit glasi: s SELECT STUDENT. COURSE WHERE STUDENT. STUDENT.SNO = REPORT. SELECT SNO.SNO AND TEMP1. STUDENT TEMP2 WHERE TEMP1. Znak * ovdje oznaˇava sve atribute relacije. Upit 3: Pronadi brojeve i imena studenata koji su upisali bar jedan kolegij kojeg predaje Quinn.

s DELETE FROM STUDENT WHERE LEVEL = 3. . LEVEL = 2. Teret efikasnog odgovaranja na te raznolike upite prebaˇen je na DBMS.CNO = COURSE. odnosno z DELETE. Pritom se nastoji iskoristiti eventualno prisustvo pomo´nih struktura podataka c (indeksi i sliˇno). ’Smith’. Odabir dobrog z c c postupka za odgovaranje zove se optimizacija upita. SNAME = ’Smith’. 3. 31 Ovdje je EXISTS (SELECT . OPTIMIZACIJA UPITA SELECT SNO FROM STUDENT WHERE NOT EXISTS (SELECT * FROM COURSE WHERE NOT EXISTS (SELECT * FROM REPORT WHERE REPORT.3. 2).SNO = STUDENT.4. c . ali s c je pogodniji sa stanoviˇta izvrednjavanja. . Naime. odgovor na jedan te isti upit obiˇno c c se moˇe dobiti na razne naˇine.2 Aˇuriranje relacija z Upis. UPDATE COURSE SET LNAME = ’Black’ WHERE CNO = 251. promjena. 3. ) istina ukoliko je rezultat ukljuˇene SELECT naredbe c neprazan.4 Optimizacija upita Jezici za relacijske baze podataka daju korisniku veliku slobodu u postavljanju upita. INSERT INTO STUDENT VALUES (867520. Moderni DBMS provodi optimizaciju na dvije razine: viˇa (logiˇka) razina : preformuliranje algebarskog izraza u oblik koji je ekvivalentan polaznom.SNO AND REPORT. s niˇa (fiziˇka) razina : odabir dobrog algoritma za izvrednjavanje svake od osnovnih operacija u algez c barskom izrazu. Primjer 2: Promijeni nastavnika kolegija 251 iz Quinn u Black.CNO)).3. Primjer 1: Upiˇi u relaciju STUDENT novu n-torku sa sljede´im vrijednostima atributa: SNO = s c 867520. odnosno brisanje n-torke u relaciji postiˇe se naredbom INSERT. Primjer 3: Briˇi sve studente na stupnju 3. Ova naredba mijenja svaku n-torku u kojoj je CNO = 251. a zadatak DBMS-a je da odabere najefikasniji naˇin. UPDATE. Sve tri naredbe gradene su po analogiji sa SELECT.

a ne one od S. 3. . c c s c Izvlaˇenje selekcije ispred prirodnog spoja odnosno Kartezijevog produkta . Preˇutno smo pretpostavili da je upit zadan pomo´u relacijske algebre. tada vrijedi: (R join S) where B = ( (R where (BR and BC )) join (S where (BS and BC )) ) where B . ako B rastavimo na B = BR and BS and BC and B .. Codd je izloˇio redukcijski algoritam kojim se izraz u raˇunu pretvara u s z c izraz u algebri. E. da se svaki upit zapisan pomo´u relacijskog raˇuna moˇe formulirati i pomo´u c c z c ˇ relacijske algebre. Stoviˇe. r > | R1(t) and R2(r)} . Ova transformacija moˇe znatno smanjiti broj n-torki koje ulaze u prirodni spoj odnosno Kartezz ijev produkt. Mi kao ilustraciju navodimo ekvivalente za c z c “bitne” algebarske operacije: R1 union R2 R1 minus R2 R1 times R2 R1 where f(X) R1 [X] . Codd je u svom ˇlanku iz 1972.. jer ´e rezulc c c tiraju´a selekcija takoder biti spora. Naime. {t | R1(t) and f(t.4. Ako uvjet B c sadrˇi samo atribute od R. 3. c Kombiniranje selekcija . tada vrijedi: z (R join S) where B = (R where B) join S. {t | R1(t) and not R2(t)} . Praktiˇni jezici poput SQL kombiniraju elemente raˇuna i algebre. JEZICI ZA RELACIJSKE BAZE PODATAKA U ovom poglavlju bavimo se viˇom razinom optimizacije. gdje BR sadrˇi c z samo atribute od R. pregledom cijele relacije). ˇelimo na´i brojeve svih studenata na stupnju 1 koji su upisali neki kolegij kod nasz c tavnika Quinna i dobili ocjenu iznad 70 iz tog kolegija. Ovdje < t. Ovime smanjujemo potrebno vrijeme ukoliko se obje selekcije odvijaju podjednako “sporo” (tj. tada se kombiniranje ne isplati. Ako se jedna relacija odvija brzo (na primjer zahvaljuju´i prisustvu c pomo´nih fiziˇkih struktura podataka) a druga sporo. (R times S) where B = (R where B) times S. prilikom razmatranja optimizacije moˇemo bez gubitka op´enitosti c z c smatrati da je upit ve´ zapisan u relacijskoj algebri. r > znaˇi kombinaciju n-torki t i r. Sliˇna ekvivalencija moˇe se napisati i za operator times..1 Odnos izmedu relacijske algebre i raˇuna c Svaki upit zapisan u relacijskoj algebri moˇe se zamijeniti ekvivalentnim upitom zapisanim u relacijskom z raˇunu. Oˇito vrijedi ekvivalencija: c (R where B1 ) where B2 = R where (B1 and B2 ). {t | R1(t) or R2 (t)} . Stoga je oˇigledno da se upiti c c c zapisani u tim jezicima takoder mogu preformulirati u relacijsku algebru. . BS sadrˇi samo atribute od S.X)} ..F. {t.4.X | R1(t)} . tada bi prvi korak c optimizacije bila pretvorba upita u algebarski izraz.. u cilju da se ˇto prije smanji c s z s veliˇina relacija s kojima radimo. . dok ´e niˇa razina biti obradena u poglavlju s c z 5. tj.. Zahvaljuju´i ovim rezultatima. {< t. Slijedi opravdanje za tu s c pretpostavku... godine dokazao c c i obratnu tvrdnju. ako to nije tako. .32 3.. Znaˇi. c z Na primjer. Op´enitije. BC sadrˇi zajedniˇke atribute od R i S. B z z c predstavlja ostatak od B.. Strogi dokaz ove tvrdnje moˇe se na´i u literaturi.2 Osnovna pravila za optimizaciju Znaˇajna uˇteda vremena postiˇe se mijenjanjem redoslijeda operacija. odluka ˇto je bolje ovisi o fiziˇkoj gradi baze podataka. Tada se to moˇe izraziti kao: z .

c Izvlaˇenje projekcije ispred prirodnog spoja . Projiciranje moˇe dugo trajati zbog eliminacije “duplikata”. pa za njega vrijede ista pravila kao za c join. minus S)[X] = R[X] minus S[X] . Y i Z atributi od relacije R. c c c c odluka ˇto je bolje opet ovisi o fiziˇkoj gradi. Ako X oznaˇava zajedniˇke c s c c atribute od R i S. Z])[X. Operator intersect je specijalni sluˇaj od join. OPTIMIZACIJA UPITA RESULT := ( (STUDENT join REPORT join COURSE )where (LEVEL=1 and MARK >70 and LNAME =’Quinn’) ) [SNO]. Zato je dobro najprije smanjiti z broj n-torki selektiranjem. U ovom jednostavnom sluˇaju. jer projekcija moˇe sprijeˇiti efikasnu implementaciju prirodnog spoja. Zahvat ne mora uvijek biti koristan. AS atributi od S. Y. tada vrijedi: ((R[X. union S)[X] = R[X] union S[X] . No u dugaˇkim i kompliciranim izrazima nije lako uoˇiti redundantno projiciranje. Neka su AR atributi od R.4. No pravilo ne vrijedi za proizvoljni skup atributa X. where B1 )[X] union (R where B2 )[X] = ( R where (B1 or B2 ) )[X] . AC = AR ∩ AS zajedniˇki atributi od R i S. Ako uvjet B sadrˇi samo projicirane atribute X. Tada vrijedi: c (R join S)[X] = ( R[(X ∩ AR ) ∪ AC ] join S[(X ∩ AS ) ∪ AC ] )[X] . . s c Optimizacija skupovnih operatora . projekcija moˇe z c z stvoriti privremenu relaciju na koju nisu primjenjive postoje´e pomo´ne fiziˇke strukture. 33 Izvlaˇenje selekcije ispred projekcije .3. Moramo paziti da projiciranjem ne izbacimo zajedniˇki atribut iz relacija prije nego ˇto je bio obavljen prirodni spoj. Primjenom transformacije dobivamo: RESULT := ( ((STUDENT where (LEVEL=1) join (REPORT where MARK >70)) join (COURSE where LNAME =’Quinn’) ) [SNO] . tada je: c z R[X] where B = (R where B) [X] . minus S) where B = (R where B) minus (S where B) . Kombiniranje projekcija . Na primjer. Opet se smanjuje broj n-torki koje ulaze u prirodni spoj. Koji put su od koristi sljede´a pravila: c (R (R (R (R (R union S) where B = (R where B) union (S where B) . Ako su X. To je posebno preporuˇljivo onda kad postoje fiziˇka sredstva za brzu c c selekciju. tada je: (R join S)[X] = R[X] join S[X] . Predzadnja jednakost vrijedi pod pretpostavkom da X sadrˇi kljuˇne atribute od R (a time i z c od S). Transformacijama se nastoji smanjiti broj n-torki koje sudjeluju u operacijama union i minus. Umjesto tri projekcije dovoljna je samo jedna. Y ])[X] = R[X] . ta jednakost c c c c je oˇigledna. Znaˇi.

JEZICI ZA RELACIJSKE BAZE PODATAKA .34 3.

c 4. character string.i nanosekundama). i ona moˇe iznositi na primjer 512 byte ili 4096 byte. no on ne omogu´uje da stvarno razumijemo fiziˇku c c c gradu baze. c 35 .4 ˇ FIZICKA GRADA BAZE PODATAKA 4. sasvim niskom nivou apstrakcije koji je vrlo blizak fiziˇkoj stvarnosti.1 Elementi fiziˇke grade c Baza podataka se u fiziˇkom smislu svodi na gomilu bitova pohranjenih na magnetskim diskovima. ). Ipak. float. Datoteka je konaˇni c c niz zapisa istog tipa pohranjenih u vanjskoj memoriji.2 Datoteke Osnovni problem fiziˇkog prikazivanja baze podataka je organizacija datoteke. Primijetimo da je tip zapisa definiran neˇto uˇe nego na primjer u C-u. Sam zapis sastoji se od konkretnih vrijednosti osnovnih podataka. . c Takav doslovni naˇin gledanja je bez sumnje istinit. pretraˇiti buffer u glavnoj memoriji i izdvojiti traˇeni byte. ili obratno. datoteke i s pointeri. na primjer ako ˇelimo proˇitati samo jedan byte iz vanjske memorije. Svaki blok jedz noznaˇno je zadan svojom adresom.1. • izbaciti zapis. Rijeˇ je o prvom. Tip zapisa zadaje se kao uredena n-torka osnovnih podataka (komponenti). gdje je svaki osnovni podatak opisan svojim imenom i tipom (int. c z to vrijeme (mjereno u milisekundama) neusporedivo je ve´e od vremena potrebnog za bilo koju mac nipulaciju u glavnoj memoriji (mjereno u mikro. kao ˇto su zapisi. . Dio glavne memorije koji sudjeluje u prijenosu (i ima jednaku veliˇinu kao i sam blok) zove se buffer. dakle jedan zapis ima toˇno c jednu vrijednost svakog od osnovnih podataka i ta vrijednost je prikazana fiksiranim brojem byte-ova. Umjesto toga. Blok je najmanja koliˇina podataka c c koja se moˇe prenijeti. • na´i zapis ili zapise gdje zadani podaci imaju zadane vrijednosti. Osnovna operacija s vanjskom memorijom je prijenos bloka sa c zadanom adresom iz vanjske memorije u glavnu. . Zato je brzina nekog algoritma za rad s vanjskom memorijom odredena brojem blokova koje algoritam mora prenijeti. • promijeniti zapis. c z z Vrijeme potrebno za prijenos bloka nije konstantno ve´ ovisi o trenutnom poloˇaju glave diska. Smatramo da su zapisi fiksne duljine. bolje je promatrati malo apstraktnije objekte. c c 4. Veliˇina bloka je konc c stanta operacijskog sustava.1. a vrijeme potrebno za raˇunanje i manipuliranje u glavnoj memoriji je zanemarivo. tada z z c moramo prenijeti cijeli odgovaraju´i blok.1 Vanjska memorija raˇunala c Operacijski sustav raˇunala dijeli vanjsku memoriju u jednako velike blokove. Tipiˇne operacije koje se obavljaju nad datotekom su: c • ubaciti novi zapis. s z naime nije dozvoljena hijerarhijska ni varijabilna grada zapisa.

. . . (zapis 5) . Sve se ovo vidi na Slici 4. . . Duljina zapisa je 20 byte. jer mogu postojati zapisi-duplikati. Kako da s c z c razlikujemo vaˇe´e i nevaˇe´e zapise? Opet proˇirimo zapis jednim bitom koji oznaˇava da li zapis z c z c s c “vaˇi” ili “ne vaˇi”. ali tako da njegovo mjesto i dalje bude zauzeto. Naˇin kako se c s s c odreduju adrese tih blokova ovisi o organizaciji datoteke (vidi potpoglavlje 4. . (zapis 1) . Ukoliko ima viˇe kandidata za kljuˇ. c blok T Slika 4. kao ˇto je ilustrirano Slikom 4. c c 3 856434 Cairns 2 864532 Burns 1 876543 Jones 2 1 3 Slika 4. . do 4. Kod nekih organizacija datoteki mogu neka mjesta za zapise u bloku ostati prazna. U svakom sluˇaju. . tada odabiremo jednog od njih da bude c s c primarni kljuˇ. Naime. byte. .2. .3. (zapis 3) . do 19. char SNAME[15]. .2: Prikaz zapisa unutar bloka Cijela datoteka obiˇno zauzima viˇe blokova.1. . z z (Kandidat za) kljuˇ je osnovni podatak. . . . zbog pisanja i brisanja podataka. . ili kombinacija osnovnih podataka. . . .36 ˇ 4.1: Datoteka sa zapisima o studentima Kao primjer. Uzimamo da je u c s bloku smjeˇten cijeli broj zapisa. (zapis 2) . . z z puno/prazno ¢ z z ¢ vaˇi/ne vaˇi ¢ ¡  ¢  ¡ 0 1 0 1 1 0 0 1 1 0 . c 4. ˇija vrijednost jedc c noznaˇno odreduje zapis. Svaki zapis ima svoj redni broj. Adresa zapisa gradi s s c z s se kao uredeni par (adresa bloka. Ne mora svaka datoteka imati kljuˇ. Koji put je potrebno s c “poniˇtiti” zapis (uˇiniti ga nevaˇe´im). byte-u. . . Vrijednost prvog osnovnog podatka zauzima 1. (zapis 4) .2). a tre´i podatak je u 20. . . Tip zapisa definiran u jeziku C je: typedef struct { int SNO. ˇto znaˇi da je dio bloka moˇda neiskoriˇten. . pa smo prisiljeni koristiti njene nepovezane dijelove. promatrajmo datoteku o studentima fakulteta. pomak unutar bloka). byte. char LEVEL. ne c mora se raditi o nizu uzastopnih adresa. Prvih nekoliko zapisa izgleda kao na Slici 4. vrijednost drugog osnovnog podatka 5. FIZICKA GRADA BAZE PODATAKA Sloˇenost grade datoteke ovisi o tome koliko efikasno ˇelimo obavljati pojedine od ovih operacija. vanjska memorija se prije ili kasnije isparcelira.1. } STUDENT. Stoga se viˇe zapisa sprema u jedan blok. Kako da razlikujemo puna i prazna mjesta? Jedno rjeˇenje je: s proˇiriti zapis s jednim bitom koji oznaˇava da li je mjesto “puno” ili “prazno”.3 Smjeˇtaj datoteke u vanjskoj memoriji s Zapis je obiˇno znatno manji od bloka.

Prisustvo pointera-kljuˇa ne uzrokuje nikakve probleme kod aˇuriranja ili reorganizacije datoteke.. ... Primijetimo da se ovakvim fiziˇkim c c c prikazom uvodi umjetni redoslijed medu atributima relacije... Jedna n-torka relacije prikazana je jednim zapisom... . kaˇemo da je zapis prikovan (pinned) . no smisao c c takvih vrijednosti ovisi o konkretnoj organizaciji datoteke i mi ih ne´emo razmatrati... Pointer moˇe biti: z • adresa zapisa (“fiziˇki” pointer). ... z z Ako na zapis pokazuje pointer-adresa. . .. dakle oni omogu´uju da iz jednog zapisa c c pristupimo drugom.. . Tipiˇni primjeri takvih datoteki su indeksi.1. No. . . . relacijski DBMS u stanju je promijeniti taj redoslijed prilikom rada s relacijom.. c . c s z c Prouˇit ´emo razne organizacije datoteki i naˇine kako da se za njih realizira pristup na osnovu pric c c marnog kljuˇa. PRISTUP NA OSNOVU PRIMARNOG KLJUCA . . . tada se svaka relacija prikazuje jednom datotekom. te umjetni redoslijed n-torki.zapis se naime ne z smije fiziˇki pomicati sa svog mjesta jer bi nakon pomaka pointer krivo pokazivao... Primarni kljuˇ relacije odreduje primarni kljuˇ datoteke...on samo implicc c itno odreduje zapis kojeg tek treba prona´i nekim mehanizmom za traˇenje na osnovu kljuˇa. .5 Fiziˇka grada cijele baze c Cijela baza je gradena kao skup datoteki... za zadanu vriz c jednost primarnog kljuˇa treba odrediti adresu (najviˇe jednog) zapisa koji sadrˇi tu vrijednost kljuˇa..2.3: Prikaz datoteke kao niza blokova 4. c c Postoje i prijelazni oblici izmedu fiziˇkog i logiˇkog pointera. . c • vrijednost primarnog kljuˇa (“logiˇki” pointer). c Pointeri omogu´uju uspostavljanje veze izmedu zapisa. . Jedini naˇin da c c pomaknemo prikovani zapis je da takoder aˇuriramo i pointer. Dakle. c z To je i razlog zaˇto koristimo takve pointere.1.2 i 4... Pointer-kljuˇ je “spor” . ...4 Pointeri Pointer je vrijednost unutar jednog zapisa koja pokazuje na neki drugi zapis (u istoj ili drugoj datoteci). . Atributi relacije odgovaraju osnovnim podacima u zapisu...2 Pristup na osnovu primarnog kljuˇa c Vaˇna operacija u radu s datotekama je pristup na osnovu primarnog kljuˇa... . . Pointer-adresa omogu´uje brzi pristup..ˇ 4. c 4. c z c Prisustvo pointera-adrese moˇe uzrokovati probleme kod aˇuriranja ili reorganiziranja datoteke. Zapisi u datotekama mogu biti medusobno povezani pointerima. . no problem je da za zadani zapis obiˇno z c ne znamo gdje se sve mogu nalaziti pointeri koji na njega pokazuju.. 37 blok 1 blok 2 blok 3 blok N Slika 4. c Ukoliko imamo posla s relacijskim bazama. .. unatoˇ njihovoj “sporosti”. Osim osnovnih datoteki koje odgovaraju pojedinim relacijama.3 bavimo iskljuˇivo datotekama.... .. na primjer redni broj zapisa... Zbog toga se u potpoglavljima 4. fiziˇka grada relacijske baze moˇe c z sadrˇavati i dodatne pomo´ne datoteke koje ubrzavaju pretraˇivanje i uspostavljanje veza medu poz c z dacima.. Sve operacije s bazom svode se na osnovne operacije s datotekama. s c 4.. .

No ako zapisi nisu prikovani. 2... ... c c Da bi ubacili novi zapis.. .. Blokovi koji ˇine datoteku mogu biti povezani u vezanu listu (svaki blok sadrˇi c z adresu idu´eg bloka) ili moˇe postojati tablica adresa svih blokova (koja zauzima prvi ili prvih nekoliko c z blokova). • skupine bitova se zbroje kao cijeli brojevi. koja daje redni broj s h(k) pretinca u kojem se treba nalaziti zapis s vrijednoˇ´u kljuˇa k... . c • zadani niz bitova se podijeli na skupine fiksne duljine. pa ´e se time ispraˇnjena mjesta z c c z koristiti kod budu´ih ubacivanja.. c c Ako su zapisi prikovani... Ako je hash funkcija zaista uniformna.. sc c Skup mogu´ih vrijednosti kljuˇa obiˇno je znatno ve´i od broja pretinaca.. oznaˇenih rednim brojevima 0.. .. ve´ ih samo moˇemo proglasiti c z nevaˇe´ima. Ako je datoteka velika. ... Vaˇno je da h uniformno c c c c z distribuira vrijednosti kljuˇa na pretince. . . 1. Zapise datoteke poredamo u onoliko blokova koliko je potrebno... a ‚ aaa . z z Zapis sa zadanom vrijednoˇ´u kljuˇa k traˇimo tako da izraˇunamo h(k)...1 Jednostavna datoteka Zapravo se radi o odsustvu bilo kakve organizacije...38 ˇ 4... . ... ... Promjena zapisa obavlja se bez ograniˇenja. . .. te ako je broj pretinaca dobro odabran. .. Zadana je tzv. z Hash datoteka obiˇno se realizira tako da pretinci budu vezane liste blokova.. . ... Pristup na osnovu kljuˇa zahtijeva svega nekoliko ˇitanja bloka s c c (obiˇno oko 2 ˇitanja).. . .. . • zbroj se podijeli s brojem pretinaca. ili prikljuˇujemo novi blok ukoliko su svi postoje´i blokovi popunjeni. . .. .. Svaki s c pretinac sastoji se od jednog ili viˇe blokova. ..4. . .5.4: Jednostavna datoteka (dvije varijante) Traˇenje zapisa sa zadanom vrijednoˇ´u kljuˇa zahtijeva sekvencijalno ˇitanje cijele datoteke (ili z sc c c bar pola datoteke u prosjeku).. FIZICKA GRADA BAZE PODATAKA 4. pa pristup traje dugo.. Zaglavlje je obiˇno dovoljno malo... stavljamo ga na prvo slobodno mjesto u prvom nepopunjenom bloku.ae fe zaglavlje f e … f e f e f e … f f f x f ‚ ...2.. .. Te dvije varijante jednostavne datoteke vide se na Slici 4. tada ne smijemo zaista izbacivati zapise. • ostatak kod dijeljenja je traˇeni redni broj pretinca. . ... .2. .. a© a© © % blok 1 blok 2 blok 3 blok 1 blok 2 blok 3 blok N blok N Slika 4.. .. Tada se ne´e deˇavati da se pretinci neravnomjerno pune.... . s time da se zadnja skupina nadopuni nulama ako je potrebno. .2 Hash datoteka Zapise datoteke smjeˇtamo u P pretinaca. pa se za vrijeme rada s c datotekom moˇe drˇati u glavnoj memoriji.. . ... c c 4. . . .. . . tada ni jedan od pretinaca nije suviˇe velik... .. morat z ´emo uˇitati mnogo blokova... . .. hash funkcija h.. c c s Dajemo primjer dobre hash funkcije: • vrijednosti kljuˇa promatraju se kao nizovi bitova fiksne duljine. sve dok ne naidemo na traˇeni zapis.. .. ... tada ih smijemo izbacivati. ..... te sekvencijalno pretraˇimo sc c z c z h(k)-ti pretinac. . Adrese poˇetaka tih c c listi ˇine zaglavlje koje se smjeˇta u prvi blok ili prvih nekoliko blokova datoteke.. .. P − 1. .. ‚ . . Cijela organizacija c s hash datoteke vidljiva je na Slici 4.. . . . c c .

. Ako zapisi nisu prikovani. Takoder. c razrijedeni indeks. a . Blokovi ne moraju biti sasvim popunjeni.. ......... . .. (pretinac P − 1) Slika 4. . . ona nije c pogodna onda kad obradujemo zapise u sortiranom redoslijedu po kljuˇu. (pretinac 0) (pretinac 1) ‚ . .. tada ih ne smijemo izbacivati.. ˇime oslobadamo mjesta za budu´a c c c ubacivanja.. Dodajemo tzv. . . PRISTUP NA OSNOVU PRIMARNOG KLJUCA ‚ 0 1 39 a a . .. Izloˇit ´emo c s z z c dvije varijante datoteke s indeksom.. tada ih smijemo izbacivati.. tada na kraj te vezane liste prikljuˇujemo novi blok. c Ako su svi zapisi prikovani.. .. ve´ ih samo moˇemo proglasiti “nevaˇec z z ´ima”.. jer bi se time mogao promijeniti broj c pretinca kojem zapis mora pripadati (takvu promjenu moˇemo ostvariti izbacivanjem stare verzije z zapisa te ubacivanjem nove verzije).. Svaki zapis u indeksu odgovara jednom bloku osnovne datoteke i oblika je (k. Sam indeks je takoder c c sortiran po kljuˇu i za sada zamiˇljamo da je jednostavno organiziran....6: Indeks-sekvencijalna organizacija datoteke . ... Ako sc c su svi blokovi h(k)-te vezane liste puni. . a . .. . a . . a ..6.2.. a  . a).af e a fe t ” t (razrijedeni f e f e indeks) f e f e f e … f f d ‚ d ‚ blok 2 blok 3 blok 4 blok 5 Slika 4.ˇ 4. . . ..3 Datoteka s indeksom Indeks je mala pomo´na datoteka koja olakˇava traˇenje u velikoj (osnovnoj) datoteci.. (osnovna datoteka) 3 5 8 10 11 23 27 28 31 38 42 46 blok 1 E 3 a 10 a 23a a  t  ~  c t 28 a t ae 42 t . a . ... ‚ .5: Hash datoteka Novi zapis s vrijednoˇ´u kljuˇa k ubacuje se u h(k)-ti pretinac..... u prvi blok gdje ima mjesta... . .. Indeks sekvencijalna organizacija zahtijeva da zapisi u osnovnoj datoteci budu sortirani po vrijednostima kljuˇa (na primjer uzlazno). . .. .. . ... a je adresa bloka. ..2.. . P −1 a zaglavlje E . Kod promjene zapisa ne smije se mijenjati vrijednost kljuˇa. ..... . .... Hash datoteka zahtijeva povremene reorganizacije (pove´anje broja pretinaca). . ‚ .. gdje je k najmanja vrijednost kljuˇa u dotiˇnom bloku. Cijela organizacija vidljiva je c s na Slici 4. . ‚ ... c 4..

Postupak je sliˇan kao kod jednostavne c organizacije. Zatim uˇitamo i pretraˇimo c c z blok s adresom a1. c Ako se izbacivanjem zapisa neki od blokova osnovne datoteke isprazni. da na njih ne pokazuju drugi pointeriadrese osim onih iz indeksa. Direktno ˇitamo blok u kojem je zapis s adresom a0. tada pokuˇamo zadnji zapis s iz tog prepunjenog bloka prebaciti u idu´i blok. Pristup po primarnom kljuˇu zahtijeva (u najgorem sluˇaju) onoliko ˇitanja bloka c c c koliko ima blokova u indeksu +1. i to na pravo mjesto u smislu z s sortiranog redoslijeda. Ako kod promjene zapisa iz osnovne datoteke promijenimo i vrijednost kljuˇa. Ako ni u tome ne uspijemo (ne postoji idu´i blok ili je c c i on pun) tada u osnovnu datoteku iza prepunjenog bloka ukljuˇimo novi blok. te u njega prebacimo c zadnji zapis iz prepunjenog bloka. tj. indeks je sortiran po kljuˇu. jer bi se time promijenio poloˇaj c z zapisa u sortiranom redoslijedu. Pretpostavimo da zapisi iz osnovne datoteke nisu prikovani. Za razliku od nesortirane osnovne datoteke. Takoder. Tada moˇemo obavljati ubacivanja i izbacivanja zapisa. Svaki zapis u indeksu odgovara jednom zapisu osnovne datoteke i oblika je (k. Najprije uz pomo´ indeksa odredimo blok c koji bi morao sadrˇavati taj novi zapis. Pokuˇamo umetnuti zapis u blok. c Indeks-direktna organizacija dopuˇta da zapisi u osnovnoj datoteci budu upisani u proizvoljnom s redoslijedu. Dodajemo tzv. No oˇekujemo da to traje znatno dulje nego kod indeks-sekvencijalne c c organizacije. ukljuˇivanje novog bloka zahtijeva ubacivanje novog para c (k. a) u indeksu.40 ˇ 4. iskljuˇujemo ga iz datoteke. Svaki put se mora aˇurirati indeks. FIZICKA GRADA BAZE PODATAKA Da bi u osnovnoj datoteci naˇli zapis sa zadanom vrijednoˇ´u kljuˇa k0. ako se u starom bloku promijenila najmanja vrijednost kljuˇa. a je pointerc c adresa zapisa iz osnovne datoteke. a0). ˇitamo indeks te traˇimo s sc c c z najve´i k1 takav da je k1 ≤ k0 i pritom par (k1. ˇitamo indeks te traˇimo s sc c c z par (k0.a a (osnovna datoteka) 10  28 E ! 5 I  z 11 42 blok 1 ‚ blok 2 23 46 !  31 ‡ … 3 8 E 38 … 27 - blok 3 blok 4 (gusti indeks) blok 5 Slika 4. Ukoliko u tome ne uspijemo (blok bi se prepunio).7: Indeks-direktna organizacija datoteke Da bi u osnovnoj datoteci naˇli zapis sa zadanom vrijednoˇ´u kljuˇa k0. jer se deˇava da zbog raznih zapisa viˇe puta uˇitavamo isti blok. Zamiˇljamo da je indeks jednostavno organiziran. Zapise iz osnovne datoteke moˇemo c z ubacivati i izbacivati pod pretpostavkom da nisu prikovani. tada aˇuriramo c z c odgovaraju´i par (k.a a c 42 a 46 a . c s 3 a 5 a 8a a c 10 a 11 a 23a a c 27 a 28 a . Indeks-sekvencijalna organizacija omogu´uje (sekvencijalno) ˇitanje c c osnovne datoteke u sortiranom redoslijedu po kljuˇu.7. Cijela organizacija prikazana je na Slici 4.a a c 31 a 38 a . potrebno je c jedno ubacivanje i jedno izbacivanje u indeksu. gdje je k vrijednost kljuˇa u dotiˇnom zapisu osnovne datoteke. gusti indeks. c Izbacivanje zapisa u osnovnoj datoteci takoder moˇe zahtijevati promjene u indeksu. Ubacivanje zapisa u osnovnu datoteku ponekad zahtijeva promjene u indeksu. na naˇin sliˇan onom za indeks-sekvencijalnu orgaz c c nizaciju. z Opisujemo ubacivanje novog zapisa u osnovnu datoteku. Na primjer. a1) postoji u indeksu. Indeks-direktna organizacija omogu´uje ˇitanje cijele osnovne datoteke u sortiranom redoslijedu c c po kljuˇu (preko indeksa). a). to se obavlja po algoritmu koji je sliˇan upravo opisanom. s s c . Kod promjene z zapisa u osnovnoj datoteci ne smije se mijenjati vrijednost kljuˇa. a) u indeks.

Ukoliko s u tome uspijemo. i to tako da jedan ˇvor c bude jedan blok. Jednom zapisu osnovne datoteke odgovara toˇno jedan par (k. a). z c s c te usporedimo k s k1. gdje je k zadana vrijednost kljuˇa. uzimamo novi blok L . prikazan kao B-stablo reda 5. Ukoliko umetanje ne uspije (L bi se prepunio). gdje je ai adresa i-tog djeteta dotiˇnog s c z c ˇvora (0 ≤ i ≤ r). . . . koristimo adresu ar . a) u listovima B-stabla. Zelimo u B-stablu prona´i par (k. a1.ˇ 4. Kad nas taj postupak c c konaˇno dovede u list. kr . k1. List ne mora biti sasvim popunjen. a je pointeradresa pripadnog zapisa u osnovnoj datoteci. te premjestimo u L zadnju polovicu sortiranog sadrˇaja prepunjenog L. . To se radi tako da redom ˇitamo unutraˇnje ˇvorove oblika (a0 . c z Ubacivanje. To je prihvatljivo rjeˇenje s s s samo onda kad je indeks jako mali. k1. . Ako je c c k < k1. • svaki ˇvor. ki+1). .8: Gusti indeks prikazan kao B-stablo reda 5 Na slici 4. Sve vrijednosti kljuˇa u pod-stablu koje pokazuje a0 su manje od k1. c 4. indeks (pogotovo gusti) je takoder velik. . Potrebna je bolja organizacija indeksa. k2. k2. i to na pravo mjesto u sortiranom redoslijedu. c z ˇ z c c Traˇenje. traˇimo u njemu zadani k. tako da stane u svega nekoliko blokova. c Za 1 ≤ i < r. prvo pronademo list L kojem bi k morao pripadati. . Indeks je tada jedno B-stablo sagradeno od blokova vanjske memorije. U nastavku promatramo prikaz gustog indeksa pomo´u B-stabla (prikaz razrijedenog indeksa ide c analogno). s B-stabla. dalje ˇitamo ˇvor s adresom a0 . . a2. a je pointer-adresa pripadnog zapisa z c u osnovnoj datoteci.8 vidimo gusti indeks neke osnovne datoteke. . ar ).4 B-stablo U proˇlom odjeljku zamiˇljali smo da je indeks jednostavno organiziran.2. manje je rasipanje memorije u osnovnoj datoteci. ima izmedu m/2 i m djece.2. . kr . sve vrijednosti kljuˇa u pod-stablu kojeg pokazuje ai su u poluotvorenom intervalu c [ki. a) u L. c • svi putovi od korijena do lista imaju istu duljinu. a). ≤ kr . s Takoder vrijedi: • Unutraˇnji ˇvor ima sadrˇaj (a0. Vrijednosti kljuˇa unutar ˇvora su sortirane. a2. gdje je k vrijednost kljuˇa. Ako je ki ≤ k < ki+1 . c c • List sadrˇi parove oblika (k. dalje ˇitamo ˇvor kojeg pokazuje ai . . a) u B-stablo. c c c c dakle k1 ≤ k2 ≤ . Daljnja prednost je mogu´nost c odgovora na pitanje da li postoji zadana vrijednost kljuˇa. Primijetimo da se indeks prikazan pomo´u B-stabla moˇe shvatiti kao hijerarhija manjih jednostavnih indeksa. Takoder. kr . bez da uop´e ˇitamo osnovnu datoteku. No kod velikih osnovnih datoteki. Parovi unutar lista su uzlazno sortirani po k. Sve vrijednosti kljuˇa u pod-stablu kojeg pokazuje ar su ve´e ili jednake kr . c c c Mana indeks-direktne organizacije je: znatno ve´i indeks. Ako je k ≥ kr . Pokuˇamo umetnuti par (k. Da bi ubacili novi par (k. U tu svrhu slijedimo put od korijena do lista koji bi morao sadrˇavati k. ar ). c ‚ a % 10 4 6 8 a a a c a 12 ‚ 10 - ccc a a a c a - a a - 18 j - 12 14 16 a a a a a - a % - j a - 18 20 - ccc a a a cc a a 22 % 22 24 26 a a a a 28 © 28 30 32 ccc a a a a 34 a 38 … 34 36 - ccc a a a cc a j 38 40 42 a a a ccc Slika 4. k2. PRISTUP NA OSNOVU PRIMARNOG KLJUCA 41 Prednost indeks-direktne organizacije u odnosu na indeks-sekvencijalnu je jednostavnije ubacivanje i izbacivanje. ki je vrijednost kljuˇa (1 ≤ i ≤ r). Danaˇnji DBMS-i u tu svrhu redovito koriste tzv. tada smo gotovi. Neka je P roditelj od L. pa bi njegovo sekvencijalno pretraˇivanje trajalo z predugo. . . k najmanja vrijednost kljuˇa u z c . izuzev korijena i listova. B-stablo reda m je m-narno stablo sa sljede´im svojstvima: c • korijen je ili list ili ima bar dvoje djece. Veza roditelj-dijete realizira se tako da adresa bloka-djeteta piˇe u bloku-roditelju. a1.

Na Slici 4. pa B-stablo c obiˇno ima svega nekoliko (3-4) nivoa. a) iz B-stabla. Tada c c takoder moramo izbaciti vrijednost kljuˇa i adresu za P iz roditelja od P . moramo korigirati c sadrˇaj od P u skladu s nestankom L. c ‚ a % 12 4 6 8 a a a c a 18 ‚ 12 14 16 ccc a a a a 22 a a 24 28 j 18 20 - ccc a a a cc a a - a - j a - j 22 23 - a a a cc j a a 34 24 26 - a a a cc a 38 j 28 30 32 a a a a - a - j 34 36 - ccc a a a cc a q 38 40 42 a a a ccc Slika 4. Ako je broj djece od P sad pao ispod m/2.9 vidi se B-stablo c dobiveno iz stabla sa Slike 4. a) iz L. a). mada najˇeˇ´e ipak malo sporiji. najmanja vrijednost c kljuˇa u L se ne pojavljuje u P ve´ u nekom pretku od P . Dalje c c korigiramo vrijednosti kljuˇa za P i P u roditelju od P . te korigiramo c vrijednost kljuˇa u P koja se odnosi na L. moˇe se desiti da trebamo s z ujediniti jedina dva djeteta korijena. Izbacimo z (k. c c c a stari korijen se iskljuˇuje iz stabla. Pritom. tada idemo u ˇvor P koji je roditelj od L. Na Slici 4.10 vidi se B-stablo c dobiveno iz stabla sa Slike 4. ako je L prvo dijete od P . c ‚ a % 10 4 6 8 a a a c a 12 ‚ 10 - ccc a a a c a - a a - 18 j - 12 14 16 a a a a a 28 ‚ a a 22 - 18 20 - ccc a a a cc c a a 24 - … 22 23 - a a a cc a a - a - j 24 26 - a a a cc a q a 34 28 30 32 a a a c a 38 ‚ 34 36 - ccc a a a cc a - a - j 38 40 42 a a a a ccc Slika 4. Ako se i korijen rascijepi. s Ako P ima toˇno m/2 djece. Broj ˇitanja bloka potrebnih za pristup na osnovu kljuˇa proporcionalan je c c visini stabla. ujedinimo P i P u jedan ˇvor s 2 m/2 − 1 djece (to je ≤ m). Visina B-stabla se time smanjila za 1. gledamo ˇvor P z c koji je neposredno lijevi (ili neposredno desni) brat od P . Umetanje se rekurzivno ponavlja i moˇe do´i z c najdalje do korijena stabla.10: Izbacivanje iz B-stabla Neka B-stablo sadrˇi u svojim listovima n parova oblika (k.9 nakon izbacivanja vrijednosti kljuˇa 10. Ako je to bio prvi zapis u L. Neka je u jednom listu smjeˇteno u z s prosjeku b parova (k. a). FIZICKA GRADA BAZE PODATAKA L . pa tada moramo proslijediti korekciju duˇ c c z puta od L do korijena. iskljuˇujemo ga iz stabla.8 umetanjem nove vrijednosti kljuˇa 23. umetanje k i a uzrokovat ´e da se P rascijepi na dva bloka. Znaˇi. a adresa od L . s time da po potrebi proslijedimo korekciju c na viˇe pretke od P . To izbacivanje se obavlja c rekurzivnom primjenom upravo opisane procedure. pristup preko indeksa B-stabla je skoro jednako brz kao c c pristup u hash datoteku. U tu svrhu u P umetnemo k i a . prvo pronademo list L koji ga sadrˇi. Prednost B-stabla pred hash datotekom je c sc ˇuvanje sortiranog redoslijeda zapisa po kljuˇu. Ako P ima bar m/2 + 1 djece. Ako se posljedice izbacivanja proˇire cijelim putom natrag do korijena. c Postupak umetanja u P je analogan ve´ opisanom postupku umetanja u L. jednako raspodijelimo vrijednosti kljuˇa i adrese u P i P tako da oba ˇvora imaju bar m/2 djece. c Ako P ve´ ima m adresa. U tom sluˇaju rezultiraju´i kombinirani ˇvor postaje novi korijen. Potrebno je L ukljuˇiti u B-stablo kao list. a to je u najgorem sluˇaju ≈ logm/2 n/b . U praksi m i b mogu biti veliki. Ako je L nakon izbacivanja postao prazan. tada stvaramo novi korijen ˇija dva djeteta su c dvije polovice starog korijena. c c .9: Ubacivanje u B-stablo Izbacivanje. visina B-stabla se time pove´ala za 1. pa ´emo c c c morati umetnuti nove vrijednosti u roditelja od P . Takoder.42 ˇ 4. Da bi izbacili par (k.

gdje je c v vrijednost za A. . No ukoliko ˇelimo da se z s z pristup obavlja brzo. Sekundarni indeks za podatak A sastoji se od zapisa oblika (v. c Fizika 37564 Kati´. Invertirani podaci mogli bi se u principu ispustiti iz osnovne datoteke. . a6 Dr. . U ovom poglavlju uvodimo sekundarni indeks . c Osnovna datoteka o nastavnicima MAT BR IME ODJEL 12453 Mati´. No to se obiˇno ne radi. a7 Mr.sc. a8 c a1 a2 a3 a4 a5 a6 a7 a8 a9 DOB 35 26 37 55 45 32 24 34 52 STUPANJ Dr.1.sc. . Ako c invertiramo tu datoteku po svakom podatku osim IME . p3. a4 . c zato da se ne bi troˇilo vrijeme na ponovno sastavljanje zapisa. a8 41-50 a5 51-65 a4.1: Invertirana organizacija datoteke. J.sc. M. Z.inˇ. . p3. Dakle. . 4. a9 Tabelarni prikaz 4. {p1 . s . a7 31-40 a1. Dipl.3. I. Dr. a8 . a7 Matematika a1 .to je mala c (pomo´na) datoteka koja olakˇava pristup zapisima velike (osnovne) datoteke na osnovu podatka koji c s nije kljuˇ. a5 . J. traˇe se zapisi u kojima zadani podatak (koji nije kljuˇ) ima zadanu z c vrijednost. PRISTUP NA OSNOVU DRUGIH PODATAKA 43 4. p2. z Dr. z Dr. Datoteka koja je invertirana po svakom od svojih podataka zove se potpuno invertirana. c Matematika 16752 Pavi´. Dr.3.sc. jer olakˇavaju s pristup na osnovu primarnog kljuˇa. mogu se traˇiti zapisi u kojima istovremeno z s c z podatak A1 ima zadanu vrijednost v1. c Matematika 45643 Jani´.sc. Dipl. kaˇe se da je osnovna datoteka invertirana po podatku z A. a2 . D.3 Pristup na osnovu drugih podataka Osim pristupa na osnovu primarnog kljuˇa. Ukoliko postoji ovakav indeks. Sekundarni indeks za DOB DOB Pointer na zapis 21-30 a2. Dipl.4. .sc.inˇ. a6 .inˇ. u radu s datotekama javlja se i potreba za pristupom na c osnovu drugih podataka. p2. potrebne su posebne organizacije datoteke.} je skup pointera na zapise u osnovnoj datoteci u kojima A ima vrijednost v. a9 Sekundarni indeks za STUPANJ STUPANJ Pointer na zapis Dipl. Problem se uvijek moˇe rijeˇiti sekvencijalnim pregledom cijele datoteke.2 mogli bi se zvati primarni indeksi. DOB i STUPANJ . Kao primjer. a3. a1 . Raˇunarstvo c c 57432 Simi´.1 Invertirana datoteka Svi indeksi koje smo razmatrali u Potpoglavlju 4. Raˇunarstvo c 34276 Dimi´.sc. podatak A2 ima vrijednost v2 . a3 .sc. z Mr. c Raˇunarstvo c 43257 Radi´. a6. K.}). c Fizika 56321 Popovi´. G. R. . . c Matematika Gusti primarni indeks MAT BR Pointer na zapis 12453 a1 16752 a2 27453 a3 34276 a4 37564 a5 43257 a6 45643 a7 56321 a8 57432 a9 Sekundarni indeks za ODJEL ODJEL Pointer na zapis Fizika a4 . . a {p1. podatak Ar ima vrijednost vr . dobivamo gusti primarni indeks za kljuˇ c MAT BR i tri sekundarna indeksa za ODJEL. a5 . Indeks za DOB sadrˇi intervale z umjesto pojedinaˇnih vrijednosti. Takvih zapisa moˇe biti i viˇe. Rijeˇ je o datoteci nastavnika na fakultetu. a9 Raˇunarstvo a3 . c Matematika 27453 Horvat. Op´enitije. promatramo Tabelarni prikaz 4.inˇ z a2 .

To zahtijeva da se definicija unutarnjih ˇvorova B-stabla malo poop´i.naime stalno ´emo morati pretraˇivati primarni indeks da bi c c c z vrijednosti kljuˇa prevodili u stvarne adrese. potrebno je prekrojiti nekoliko vezanih listi.44 ˇ 4. Na primjer. Cijeli sekundarni indeks moˇe s z biti priliˇno glomazan. No sada su uvedene vezane liste za podatke ODJEL i STUPANJ . pojavljuju se odgovaraju´i indeksi listi. 37564.2 Viˇestruke vezane liste s Pristup na osnovu zadanog ne-kljuˇnog podatka A moˇemo ubrzati tako da sve zapise osnovne datoteke c z s istim vrijednostima za A poveˇemo u vezanu listu. 16752. c Zapisi osnovne datoteke u proˇlom primjeru bili su prikovani jer su sekundarni indeksi sadrˇavali s z pointere-adrese. s Vezane liste su manje pogodne onda kad su u upitu zadane vrijednosti za viˇe podataka. Na primjer. 45643 Matematika 12453. p2.3. c Mana invertirane organizacije je utroˇak memorije za indekse. c c z U oba sluˇaja proˇitat ´emo viˇe zapisa nego ˇto ih ima u odgovoru. izbacili ili promijenili zadani zapis u osnovnoj datoteci. Na primjer. odnosno skup pointera na doktore. Dakle odgovor smo dobili bez ˇitanja osnovne datoteke. promatramo upit: “Koliko nastavnika u odjelu Raˇunarstvo c ima doktorat?” Odgovor nalazimo tako da u sekundarnim indeksima nademo skup pointera na nastavnike iz Raˇunarstva.2 c Sekundarni indeks za ODJEL ODJEL Pointer na zapis Fizika 34276. s odgovor na upit “Ispiˇi imena doktora iz odjela Raˇunarstvo” moˇe se dobiti na dva naˇina: s c z c • ˇitamo vezanu listu doktora i uvaˇimo samo one koji su iz odjela Raˇunarstvo. c z c • ˇitamo vezanu listu nastavnika iz odjela Raˇunarstvo i uvaˇimo samo one koji su doktori. ili “Ispiˇi imena svih doktora”. sekundarni indeks s pointerima-vrijednostima c kljuˇa za podatak ODJEL izgledao bi kao u Tabelarnom prikazu 4. p1 ). no usporit c c s z ´e pristup na osnovu ne-kljuˇnih podataka . (v. 43257. p3. Prikovanost se moˇe izbje´i ako pointere-adrese u sekundarnim indeksima zamijenimo z c pointerima-vrijednostima kljuˇa.}) su varijabilne duljine. c c Ukoliko sve ovo uˇinimo za viˇe ne-kljuˇnih podataka. p). a jedan zapis c s c c s osnovne datoteke imat ´e viˇe uklopljenih pointera te ´e istovremeno biti ukljuˇen u viˇe vezanih listi. . . (v. Od dvije vezane liste bolje je c c c s s odabrati kra´u . c s Organizacija pomo´u vezanih listi zahtijeva izuzetno mnogo posla prilikom aˇuriranja osnovne dac z toteke. No joˇ ve´a mana je viˇestruko s s c s pove´anje posla prilikom svakog aˇuriranja osnovne datoteke. p2). .3 ponovo se vidi primjer datoteke nastavnika. Naime. Veza se ostvaruje pomo´u pointera kojeg smo z c uklopili u zapis kao dodatni podatak. izbacic z vanja ili promjene zapisa u osnovnoj datoteci. Koji put se takoder mora obaviti korekcija u indeksu listi.2). s time da listovi stabla mogu sadrˇavati viˇe parova oblika (v.to s je mala (pomo´na) datoteka sastavljena od zapisa oblika (v. Zapisi u sekundarnom indeksu oblika (v. . . Oni se fiziˇki c prikazuju kao viˇe zapisa fiksne duljine: (v. 57432 Raˇunarstvo 27453. Prednost u odnosu na invertiranu organizaciju je manji c s i jednostavniji indeks. imat ´emo viˇe indeksa listi. 56321 c Tabelarni prikaz 4. U skladu s time. a p je pointer c na poˇetak odgovaraju´e vezane liste zapisa u osnovnoj datoteci. proˇitamo popis pointera. Da bi ubacili. sc c c 4. Prikaz je sliˇan onome za primarni c c c gusti indeks (vidi Potpoglavlje 4. . {p1.2: Sekundarni indeks s pointerima-vrijednostima kljuˇa. FIZICKA GRADA BAZE PODATAKA Pristup na osnovu bilo kojeg podatka ostvaruje se tako da u odgovaraju´em indeksu pronademo c zadanu vrijednost podatka. kod svakog ubacivanja. c s c c s U Tabelarnom prikazu 4. te za svaki od pointera proˇitamo zapis u osc c novnoj datoteci. c Organizacija pomo´u vezanih listi pogodna je onda kad su upiti unaprijed fiksirani i svode se c na zadavanje vrijednosti samo jednog podatka. te se redovito fiziˇki prikazuje kao B-stablo. Potreban nam je joˇ i takozvani indeks listi za podatak A . a to se moˇe ostvariti jedino tako da prodemo svim tim listama te promijenimo z i razne druge zapise osim zadanog. To ´e olakˇati aˇuriranje i reorganizaciju osnovne datoteke.zato je zgodno ako u indeksu listi piˇe i duljina svake liste. mora se napraviti i korekcija u svakom od indeksa. gdje je v vrijednost za A. . p3 ). p) s z s istom vrijednoˇ´u v. Na primjer: “Ispiˇi imena svih nastavnika iz odjela s Raˇunarstvo”. . Invertirana organizacija omogu´uje i brz odgovor na pitanja o postojanju ili broju c zapisa sa zadanim svojstvima. U presjeku tih dvaju skupova nalaze se c samo dva pointera. u kojem nema viˇestrukih vrijednosti podataka.

v2. . Dipl. SNAME. Definicija tipa zapisa u jeziku C izgleda ovako: typedef struct { int SNO. .sc. D. J.3 Podijeljena hash funkcija Rijeˇ je o poop´enju hash organizacije iz Potpoglavlja 4. . K. gdje su v1. . • Redni broj pretinca za zapis u kojem je A1 = v1. c Matematika Matematika Raˇunarstvo c Fizika Raˇunarstvo c Matematika Fizika Raˇunarstvo c Matematika 45 DOB 35 26 37 55 45 32 24 34 52 STUPANJ Dr. c Horvat. (broj znakova u v2 koji su razliˇiti od bjeline) % 8. gdje hi preslikava vrijednost vi podatka Ai u niz od bi bitova.sc. |hr (vr ). I.4. . c Radi´. c Simi´. z Dr. vr ) = h1 (v1 )|h2(v2 )| .4} LEVEL. . c . s time da hash funkcija osim kljuˇa uzima c c c kao argument i ne-kljuˇne podatke. . a1 Tabelarni prikaz 4. Ar = vr zadaje se spajanjem malih nizova bitova.F} GENDER.inˇ. Podijelimo 10 bitova u rednom broju pretinca na sljede´i naˇin: 4 bita za SNO.sc. G. Dakle. J. i = 1. . A2 = v2 .inˇ. R. 2.sc. . r.2. .sc. c Kati´. z Dr.sc. 3 bita za SNAME. a6 Dr. Ovdje je | oznaka za “lijepljenje” nizova bitova. c c • Podijelimo B bitova u skupine: b1 bitova za podatak A1 . b2 bitova za podatak A2 . c Jani´. LEVEL. GENDER: h1(v1 ) h2(v2 ) = = v1 % 16 (ostatak kod dijeljenja s 16). c Kao primjer. Dakle: h(v1 . Dipl. z Mr. s 4. PRISTUP NA OSNOVU DRUGIH PODATAKA Osnovna datoteka o nastavnicima MAT BR IME ODJEL a1 a2 a3 a4 a5 a6 a7 a8 a9 12453 16752 27453 34276 37564 43257 45643 56321 57432 Mati´. Dimi´. . } STUDENT. br bitova za podatak Ar .inˇ z a2 Mr..3.sc. . • Zadamo pogodne “male” hash funkcije hi (vi ). Doprinos jednog podatka u razdijeljenoj hash funkciji treba biti proporcionalan s veliˇinom domene tog c c c sc podatka i s frekvencijom njegovog pojavljivanja u upitima. . M. ve´a domena ili ˇeˇ´e pojavljivanje u upitima zahtijeva ve´i broj bitova. . c Pavi´. Z. Pointer za ODJEL a2 a6 a5 a7 a8 a9 - Pointer za STUPANJ a3 a5 a4 a8 a7 a9 - Indeks listi za ODJEL ODJEL Pointer na poˇetak c vezane liste Fizika a4 Matematika a1 Raˇunarstvo a3 c Indeks listi za STUPANJ STUPANJ Pointer na poˇetak c vezane liste Dipl.inˇ. Pretpostavimo da se redni broj pretinca moˇe izraziti kao niz od c z B bitova. 2 c c bita za LEVEL. enum {M. . Postupamo na sljede´i naˇin. Dr. . v2.sc. 1 bit za GENDER. . char SNAME[20]. v3. Zadajemo sljede´e hash funkcije. Dr. Dipl. v4 vrijednosti za c SNO.3. promatramo zapise o studentima fakulteta i ˇelimo ih spremati u hash datoteku s z 1024 (= 210) pretinaca.2. c Popovi´.3: Organizacija datoteke s viˇestrukim vezanim listama. enum {1.3.

dakle z 1/8 datoteke. c z Na primjer. . Smith. c z c . Prednost podijeljene hash funkcije u odnosu na invertiranu datoteku je da se ne troˇi dodatni prostor s za indekse. no prvih 7 bitova je nepoznato. v2. ako traˇimo sve muˇke studente na drugoj godini. . Smatra se da je organizacija pomo´u c podijeljene hash funkcije dobra za datoteke koje nisu prevelike i ˇiji sadrˇaj se ˇesto mijenja. vr ) i sekvencijalno pretraˇimo taj jedan pretinac. . . to ´e biti z c c ve´i broj pretinaca koje moramo pretraˇiti. FIZICKA GRADA BAZE PODATAKA v3 − 1. c Tada je redni broj pretinca za zapis (58651. Takoder. a broj pretinaca koje ˇ moramo pretraˇiti pove´ava se 2bi puta. A2. . tada bi bitova u rednom broju pretinca ostaje nepoznato. 3. . A2 = v2 . Da bi pronaˇli zapis (ili viˇe njih) u kojem je A1 = v1. Sto manje vrijednosti za A1. . raˇunamo redni s s c broj pretinca h(v1 . Ako u upitu nije fiksirana z vrijednost podatka Ai . Treba pretraˇiti 27 = 128 pretinaca. . Ar je poznato. Ar = vr . M) zadan s (1101|101|10|0)2 = (748)10. . izbacivaja i promjene zapisa su znatno jednostavnije budu´i c da nema indeksa koje treba odrˇavati. tada su nam u rednom broju pretinca z s poznata zadnja 3 bita: 010. No traˇenje zapisa u kojem su specificirane vrijednosti samo z z nekih od podataka traje dulje nego kod invertirane organizacije. operacije ubacivanja. 1 inaˇe). . (0 za v4 jednak M.46 h3(v3 ) h4(v4 ) = = ˇ 4. . .

Raspravljat ´emo o implementaciji triju najvaˇnijih c z operacija: prirodnog spoja (ovo potpoglavlje). Algoritam se moˇe c z poboljˇati tako da u glavnu memoriju uˇitamo segment od ˇto viˇe blokova iz R1. Svaka od ovih triju relacija fiziˇki se prikazuje jednom (istoimenom) dac totekom. Oznaˇimo sa S(A. te selekcije i projekcije (idu´e potpoglavlje). No. Preinaˇimo petlje tako s c s s c da usporedujemo svaki zapis uˇitan iz R2 sa svakim zapisom iz R1 koji je trenutno u glavnoj memoriji. C) sa zajedniˇkim atributom B. a atributi u istoimene osnovne podatke. c dok ( nismo preˇli kraj od R2) { s ako ( teku´i zapisi iz R1 i R2 sadrˇe istu vrijednost za B ) c z stvori kombinirani zapis i ispiˇi ga u S. koji se svodi na izvrednjavanje zs c c izraza u relacijskoj algebri. c z c c inicijaliziraj praznu S.1. B. c dok ( nismo preˇli kraj od R1 ) { s uˇitaj prvi zapis iz R2. uˇitaj prvi zapis iz R1. kod relacijskih baza teˇiˇte je baˇeno na “dinamiˇki” aspekt. Osnovni korak c c je izvrednjavanje pojedine algebarske operacije. c 47 . potrebno je prouˇiti kako se fiziˇki odvija izvrednjavanje algebarskog izraza. C) c c prirodni spoj od R1 i R2. Poboljˇana verzija algoritma osobito je dobra onda kad je jedna od s datoteki dovoljno mala da cijela stane u glavnu memoriju. Razmotrit ´emo c nekoliko naˇina kako da se pomo´u datoteki R1 i R2 generira datoteka S. B) i R2(B. Osnovna ideja je sljede´a. n-torke se pretvaraju u zapise. da bi bolje razumjeli ˇto se sve deˇava unutar jednog relacijskog s s DBMS-a.1 Algoritam ugnijeˇdenih petlji z To je oˇigledan. s pokuˇaj uˇitati idu´i zapis iz R2. s c c } Za svaki zapis iz R1 moramo iznova sekvencijalno ˇitati cijelu datoteku R2. U zadnjem c potpoglavlju re´i ´emo neˇto o optimalnom izvrednjavanju cijelog izraza.5 IMPLEMENTACIJA RELACIJSKIH OPERACIJA 5. c c s Promatramo relacije R1(A. uˇitamo idu´i segment od R1 s c c c u glavnu memoriju te ponavljamo postupak. Tada se i R1 i R2 ˇitaju samo jednom. c Nakon ˇto smo proˇitali cijelu R2 i obavili sva potrebna usporedivanja. R2 se ˇita onoliko c c c puta koliko ima segmenata u R1. Stoga. s c c } pokuˇaj uˇitati idu´i zapis iz R1 . R1 se oˇigledno ˇita samo jednom.1 Implementacija prirodnog spoja Gradivo izloˇeno u Poglavlju 4 uglavnom predstavlja “statiˇki” aspekt fiziˇke organizacije baze poz c c dataka. makar ne nuˇno i najefikasniji naˇin. c c 5.

na primjer R2 . a koristiti indeks ve´e datoteke. c dok ( nismo preˇli kraj od R1 ) { s pomo´u indeksa pronadi i uˇitaj sve zapise iz R2 c c koji imaju istu vrijednost za B kao teku´i zapis iz R1. algoritam treba preraditi tako da uˇitava segment po c segment od svake skupine. U literaturi postoje mnogi dobri algoritmi za sortiranje. dijelimo c c je na segmente koji stanu u glavnu memoriju. To moˇe dovesti do znaˇajne uˇtede u obimu posla. s z pa tek onda raˇunati prirodni spoj. Dakle sortiranje polaznih R1 i R2 trajat ´e znatno dulje nego s c generiranje S od ve´ sortiranih R1 i R2. Datoteka S koja sadrˇi prirodni z c sc z z c c c z spoj od R1 i R2 lagano se moˇe generirati sljede´im algoritmom koji podsije´a na klasiˇno saˇimanje. posebno sortiramo svaki segment i ispisujemo ga natrag u vanjsku memoriju. c teku´i zapis iz R1 kombiniraj sa svakim od uˇitanih c c zapisa iz R2 te generirane zapise ispiˇi u S. tada ih najprije treba sortirati. s c c inaˇe ako ( teku´a skupina zapisa iz R2 sadrˇi c c z manju vrijednost za B nego teku´a skupina zapisa iz R1 ) c pokuˇaj uˇitati idu´u skupinu zapisa iz R2. koja sadrˇi prirodni spoj od R1 i R2. s c c } c Algoritam jednom proˇita cijelu R1.1.3 Algoritam zasnovan na indeksu Pretpostavimo da jedna od datoteki R1 i R2 . s c c } } Pretpostavili smo da su skupine zapisa iz R1 odnosno R2 s istom vrijednoˇ´u za B dovoljno male sc tako da stanu u glavnu memoriju. tada treba sekvencijalno ˇitati manju datoteku. no oni c obiˇno predvidaju da cijela datoteka stane u glavnu memoriju. Tada u R1 i u R2 c moˇemo uoˇiti skupine uzastopnih zapisa s istom vrijednoˇ´u za B. ako su R1 i R2 jako velike. cijeli postupak se isplati u c odnosu na algoritam ugnijeˇdenih petlji. sve dok na z c c kraju ne dobijemo cijelu sortiranu datoteku. uˇitaj prvu skupinu zapisa iz R1. Da bi sortirali ve´u datoteku. c s pokuˇaj uˇitati idu´u skupinu zapisa iz R1. s c c pokuˇaj uˇitati idu´u skupinu zapisa iz R2. s c c inaˇe { c svaki zapis iz teku´e skupine iz R1 kombiniraj sa svakim zapisom c iz teku´e skupine iz R2 te sve generirane zapise ispiˇi u S. uˇitaj prvi zapis iz R1. c c . c dok ( nismo preˇli kraj ni od R1 ni od R2) { s ako ( teku´a skupina zapisa iz R1 sadrˇi manju c z vrijednost za B nego teku´a skupina zapisa iz R2 ) c pokuˇaj uˇitati idu´u skupinu zapisa iz R1. c s c Ako R1 i R2 nisu sortirane kao ˇto se traˇilo u opisanom algoritmu. c uˇitaj prvu skupinu zapisa iz R2. Ako i R1 i R2 imaju indeks z c s za B. z 5. ima sekundarni indeks za zajedniˇki c podatak B. Rijeˇ je o priliˇno dugotrajnom postupku koji zahtijeva c c viˇestruko prepisivanje cijele datoteke. IMPLEMENTACIJA RELACIJSKIH OPERACIJA 5.1.2 Algoritam zasnovan na sortiranju i saˇimanju z Pretpostavimo da su datoteke R1 i R2 uzlazno sortirane po zajedniˇkom podatku B. Tada se datoteka S.48 5. c inicijaliziraj praznu S. c Ukoliko skupine ne stanu u glavnu memoriju. Ipak. inicijaliziraj praznu S. Dalje se sortirani segmenti postepeno saˇimaju u sve ve´e i ve´e. moˇe generitati na sljede´i z z c naˇin. Pod ovakvim pretpostavkama se i R1 i R2 ˇitaju samo jednom. No iz R2 se neposredno ˇitaju samo oni zapisi koji sudjeluju c u prirodnom spoju. s pokuˇaj uˇitati idu´i zapis iz R1 . Segmenti jedne od datoteki ´e se tada morati viˇe puta uˇitavati.

IMPLEMENTACIJA PRIRODNOG SPOJA 49 5. Sekvencijalno ˇitaj odgovaraju´u skupinu zapisa iz R2.1: Izvrednjavanje prirodnog spoja pomo´u hash funkcije i razvrstavanja c Neka je R1 manja od R2.3 R1. Dobivene kombinacije ispiˇi u S. ˇ 3. c 3 i 4 ilustrirani na Slici 5.4 Algoritam zasnovan na hash funkciji i razvrstavanju Zadajemo hash funkciju h koja ovisi o zajedniˇkom podatku B.1.1. tada su sve skupine podjednako velike . 1.1.2 R2.znaˇi da jedna skupina stane u glavnu c memoriju. Pritom su koraci 1. Kombiniraj teku´i zapis iz c c c R2 sa svim zapisima iz R1 (u glavnoj memoriji) koji imaju jednaku vrijednost za B.1 c Korak 3: h() u intervalu 3 Korak 4: B ¨ ¨ ¨ ¨ ¨¨ h() u E intervalu 2 glavna memorija R2.1 e e kombinacije e zapisa e e e … e S Slika 5. 4. Algoritam se tada sastoji od sljede´ih pet koraka.i h() u d intervalu 1 d d          ‚ d R2. Odaberi jedan od intervala za vrijednost h.2 c T interval 3 h() u d intervalu 1 d P −1 d ‚ d R1.5. sc s c Razvrstavanjem zapisa iz R1 i R2 u skupine onih s bliskom vrijednoˇ´u h lakˇe ´emo odrediti koji parovi zapisa se mogu kombinirati. ˇ 2. Podijeli ukupni raspon hash vrijednosti na k podjednakih intervala. Zato hash funkcija za oba takva zapisa daje istu vrijednost. Citaj sekvencijalno R2 i razvrstaj njene zapise u k skupina (pomo´nih datoteki). Odaberi hash funkciju h. Uˇitaj u glavnu memoriju odgovaraju´u skupinu c c zapisa iz R1. Kombinacija zadanog zapisa iz datoteke c R1 sa zadanim zapisom iz datoteke R2 pojavljuje se u prirodnom spoju S ako i samo ako oba zadana zapisa imaju jednaku vrijednost za B. Pritom je k odabran tako da 1/k od datoteke R1 stane u glavnu memoriju.3 c T interval 2 R1. Korak 1: T interval 1 0 1 2 Korak 2: B ¨ ¨ ¨ ¨¨ ¨ R1 h() u E intervalu 2 h() u intervalu 3 R1. Ako je h zaista uniformna z hash funkcija. sliˇno kao ˇto c c s smo to napravili s datotekom R1. Citaj sekvencijalno R1 i razvrstaj njene zapise u k skupina (pomo´nih datoteki) tako da jedna c skupina sadrˇi sve zapise iz R1 koje h preslikava u jedan od intervala. s .i R2 R2. 2. Inicijaliziraj praznu datoteku S.

tada je najefikasniji algoritam c c zasnovan na sortiranju i saˇimanju. Op´enito ne moˇemo baˇ lako odrediti koji algoritam je najbolji. R je fiziˇki prikazana istoimenom datotekom. o veliˇini glavne memorije. Implementacija selekcije R where B ovisi o obliku uvjeta B. c Naivni algoritam bio bi: sekvencijalno ˇitanje cijele R i provjera svakog zapisa da li on zadovaljava c B. Ako je R velika. Rjede se koriste hash organizacije i viˇestruke vezane liste. z 5. a unutraˇnja petlja prolazi trenutno stvorenim dijelom datoteke S: c s . ve´ se kre´e u z c c zadanom intervalu. no obiˇno se svodi na traˇenje c c z zapisa u datoteci R sa zadanom vrijednoˇ´u nekih podataka. Hash organizacija ne podrˇava c c z intervalno pretraˇivanje. IMPLEMENTACIJA RELACIJSKIH OPERACIJA 5. najbolji je algoritam zasnovan na hash funkciji i razvrstavanju. s time da odabereˇ novi interval za vrijednost od h. s Analizom algoritma lagano se vidi da se svaka od datoteki R1 i R2 ˇita toˇno dvaput. oˇito treba proˇitati cijelu datoteku R i c c izdvojiti sve vrijednosti podatka A koje se pojavljuju. z Vanjska petlja ˇita datoteku R. tada je algoritam zavrˇen.50 5. c c z s ve´ to zahtijeva detaljnije procjene koje ovise o veliˇini R1 i R2. na standardni c naˇin. 5. a zatim ´emo kratko napomenuti kako se implementiraju c ostale operacije. Ovime nisu iscrpljeni svi sluˇajevi. obiˇno se radi o pristupu na osnovu sc c primarnog kljuˇa ili o pristupu na osnovu ostalih podataka. Osnovni problem implementiranja projekcije je: kako u S eliminirati zapise-duplikate? Najjednostavniji algoritam za implementaciju projekcije zasnovan je na ugnijeˇdenim petljama.2. z • Ukoliko je jedna datoteka dovoljno mala da stane u glavnu memoriju. Izloˇit ´emo osnovne z z c ideje za implementaciju tih dviju operacija. R je fiziˇki prikazana istoimenom datotekom na standardni naˇin. c c Da bi generirali datoteku koja odgovara projekciji S = R[A]. budu´i z z c da je u njemu saˇuvan sortirani redoslijed zapisa po dotiˇnom podatku. pa teba izgraditi pomo´ne strukture podataka koje omogu´uju dic c rektniji pristup do traˇenih zapisa. Dakle. • Ako su datoteke R1 i R2 ve´ sortirane po zajedniˇkom podatku B. to traje predugo. • Za velike datoteke R1 i R2 bez indeksa. distribuciji c c c vrijednosti za B itd. z • Ako je jedna datoteka znatno ve´a od druge i ima odgovaraju´i indeks.1 Implementacija selecije Zadana je relacija R i Booleovski uvjet B. 5. c c Na kraju ovog potpoglavlja usporedit ´emo ˇetiri izloˇena naˇina za implementiranje prirodnog c c z c spoja. U poglavlju 4 ve´ smo opisali algoritme c c za pristup. Invertiranje datoteki pomo´u indeksa je vjerojatno najfleksibilnija z c metoda.2 Implementacija projekcije Zadana je relacija R i njen atribut A. projekcije i ostalih operacija Osim prirodnog spoja. Ponovi korak 4. Ako smo u koraku 4 ve´ s c obradili svaki od k intervala. najvaˇnije relacijske operacije su selekcija i projekcija. No ista vrijednost za A moˇe se pojaviti viˇe z s puta.2 Implementacija selekcije. treba odabrati algoritam ugnijeˇdenih petlji.2. Ve´ina danaˇnjih relacijskih DBMS-a oslanja se na jednostavno organizirane datoteke nadopc s unjene sekundarnim indeksima koji su prikazani B-stablima (primarni gusti indeks je samo specijalni sluˇaj sekundarnog). Neki oblici uvjeta c s B zahtijevaju da u R traˇimo zapise gdje vrijednost zadanog podatka nije fiksirana. Sad ´emo samo ukratko rezimirati ideje. tada je najbolji algoritam c c zasnovan na indeksu. Primijetimo da indeks-B-stablo podrˇava ovakvo intervalno pretraˇivanje.

5. te otkriti daljnje mogu´nosti za uˇtedu posla. s c c } ako ( duplikat == 0 ) prepiˇi vrijednost za A iz teku´eg zapisa iz R na kraj od S kao novi zapis. Bolji algoritam nije z mogu´ jer se ionako svaki zapis iz datoteke R1 mora kombinirati sa svakim zapisom iz datoteke R2 . pa ih je lako c eliminirati jednim sekvencijalnim ˇitanjem. uˇitaj prvi zapis iz S. Zato algoritmi za raˇunanje presjeka liˇe na one za raˇunanje prirodnog spoja. z s Presjek dviju relacija moˇe se shvatiti kao specijalni sluˇaj prirodnog spoja gdje su svi atributi z c zajedniˇki. ili koriˇtenje hash funkcije. c c c 5. Sluˇe´i se tim parametrima. Umjesto toga. s c pokuˇaj uˇitati idu´i zapis iz R. pa se oni obiˇno ne implec c c mentiraju zasebno. projekcije. te moˇda o joˇ ponekoj. Druga ideja je: razvrstati izdvojene vrijednosti za A u c skupine pomo´u hash funksije. postojanje ili nepostojanje odgovaraju´ih c c indeksa. algoritam s ugnijeˇdenim petljama zahtijeva previˇe vremena. c Izvrednjavanje izraza oˇito se svodi na izvrednjavanje svake od osnovnih operacija. Takoder.3 Implementacija ostalih operacija. Opet pomaˇe sortiranje datoteke R1 i R2. U ovom potpoglavlju govorimo o s niˇoj (fiziˇkoj) razini optimizacije. c dok ( nismo preˇli kraj od R ) { s duplikat = 0. koja se svodi na izbor dobrih algoritama za izvrednjavanje izraza z c dobivenog nakon “logiˇke” faze. Kartezijev produkt dviju relacija R1 i R2 implementira se ugnijeˇdenom petljom. B] . c dok ( nismo preˇli kraj od S i duplikat==0 ) { s ako ( teku´i zapisi iz R i S sadrˇe istu vrijednost za A ) duplikat = 1. OPTIMALNO IZVREDNJAVANJE ALGEBARSKOG IZRAZA 51 inicijaliziraj praznu S. veliˇina glavne memorije. s time da. DBMS za zadanu operaciju i svaki od raspoloˇivih c z c z algoritama procjenjuje vrijeme potrebno da se ta operacija izvrˇi tim algoritmom. uˇitaj prvi zapis iz R. U potpoglavlju 3. c z pokuˇaj uˇitati idu´i zapis iz S. suvremeni DBMS-i nastoje takoder promatrati i izraz kao cjelinu. a rezultiraju´e n-torke se c . c c c treba eliminirati zapise-duplikate. svaki puta kad proizvedemo novu n-torku iz (R1 join R2 ). Obiˇno je rijeˇ c c c o operacijama prirodnog spoja. s c c } z s Ako je R velika. koji se svodi na preformuliranje izraza u oblik s c ekvivalentan polaznom ali pogodniji sa stanoviˇta izvrednjavanja. DBMS zatim za zadanu operaciju odabire algoritam s c najmanjim procijenjenim vremenom. sliˇno kao kod projekcije. Procjene se dobis vaju na osnovu ugradenih heuristiˇkih pravila. Tada je bolje postupiti na sljede´i naˇin: izdvojiti sve vrijednosti za A koje se pojavljuju u R te zatim sortirati niz c c izdvojenih vrijednosti. c Daljnji relacijski operatori mogu se izraziti pomo´u ve´ razmatranih. Na primjer.4 govorili smo o viˇoj (logiˇkoj) razini optimizacije upita.2. c Unija dviju relacija R1 i R2 implementira se na oˇigledni naˇin. proslijedimo je odmah da bude spojena sa selektiranim n-torkama iz R3 . Osim ovakve izolirane optimizacije pojedinih operacija. selekcije. U sortiranom nizu duplikati ´e se pojavljivati jedan izad drugoga. Implemenc c c c tiranje skupovne razlike je takoder sliˇno.5. Tada nije potrebno do kraja izraˇunati prvi prirodni spoj prije nego ˇto poˇnemo raˇunati drugi c s c c prirodni spoj te zatim projekciju. pa ih je opet lako eliminirati.3.3 Optimalno izvrednjavanje algebarskog izraza Relacijski DBMS interno reprezentira korisnikov upit kao izraz u relacijskoj algebri. DBMS-u su poznati parametri kao ˇto su: z s kardinalnost relacija (datoteki). i sliˇno. Za svaku od osnovnih z s operacija DBMS raspolaˇe s nekoliko algoritama. Duplikati ´e se tada na´i u istoj skupini. zamislimo da treba c s izvrijedniti izraz: ( (R1 join R2) join (R3 where A = 10) ) [A.

dakle radi se o softveru s osobinama umjetne inteligencije. te su predmet daljnjeg intenzivnog istraˇivanja. c c I na logiˇkom i na fiziˇkom nivou optimizacije upita relacijski DBMS donosi odluke sluˇe´i se c c z c ugradenim “znanjem”. Pravila za donoˇenje odluka nisu ni izdaleka s savrˇena.52 5. IMPLEMENTACIJA RELACIJSKIH OPERACIJA odmah projiciraju na atribute A i B. budu´i da se privremene relacije ne moraju spremati u vanjsku memoriju ni ponovo ˇitati. U tom smislu. Ovakva “pipeline” strategija moˇe rezultirati velikim uˇtedama z s u vremenu. s z . relacijski DBMS predstavlja primjer ekspertnog sustava.

ograniˇenje c c na integritet domene prvenstveno se izraˇava time ˇto se u naredbi CREATE atributu pridruˇi tip z s z (uz eventualnu klauzulu NOT NULL). . c c c datumi. Zato na taj naˇin obiˇno ne´emo biti u mogu´nosti da precizno izrazimo naˇe ograniˇenje. ograniˇenja (constraints).1 ˇ Cuvanje integriteta Poglavlje 6 posve´eno je raznim aspektima integriteta i sigurnosti podataka. morat ´emo zadati da je DOB tipa SMALLINT. z c c Postojao je doduˇe jedan zaobilazni naˇin . 6. s Voljeli bismo kad bi se baza podataka mogla sama braniti od naruˇavanja integriteta.1. . cijeli brojevi.1. Kod svake promjene podataka DBMS ´e automatski provjeravati da li su sva ograniˇenja zadovoljena. Tada bi ograniˇenje moglo biti: c “Vrijednost za DOB je cijeli broj izmedu 10 i 60”. Popis podrˇanih tipova obiˇno nije velik (standardno to su z c char-stringovi fiksirane duljine. Rijeˇ je o problemima c c ˇije rjeˇavanje je nuˇno da bi velika viˇekorisniˇka baza podataka mogla uspjeˇno funkcionirati.6 INTEGRITET I SIGURNOST PODATAKA 6.1 Ograniˇenja kojima se ˇuva integritet domene c c Izraˇavaju ˇinjenicu da vrijednost atributa mora biti iz zadane domene. Noviji standardi za SQL predvidaju s c klauzulu PRIMARY KEY odnosno UNIQUE unutar naredbe CREATE. ˇto znaˇi da se traˇeno s c z ograniˇenje za kljuˇ moˇe eksplicitno zadati. Zahtjev da vrijednost priz c marnog atributa ne smije biti prazna takoder spada u ovu kategoriju. Integritet domene tada se u potpunosti moˇe ˇuvati c z c jedino tako da ugradimo kontrole u naˇ aplikacijski program. Kod takvih DBMS-a mogli bi u potpunosti zadati naˇe c s ograniˇenje za DOB: deklarirali bi da je DOB tipa SMALLINT. tada DBMS ne´e izvrˇiti traˇenu promjenu. s suvremeni DBMS-i dozvoljavaju projektantu baze da definira tzv.5 za DOB. uz dodatni uvjet: (DOB >= 10) c AND (DOB <= 60). Na primjer: c c z 53 . Integritet se lako moˇe naruˇiti na primjer pogreˇnim upisom neopeznih z s s korisnika ili pogreˇnim radom aplikacijskog programa. Pod time se misli na ˇuvanje korektnosti c c i konzistentnosti podataka. Ako neko ograniˇenje c c c nije zadovoljeno. Rijeˇ je c c o uvjetima (pravilima) koje korektni i konzistentni podaci moraju zadovoljavati. U tu svrhu.2 Ograniˇenja kojima se ˇuva integritet unutar relacije c c ˇ Cuva se korektnost veza izmedu atributa unutar relacije (na primjer funkcionalne ovisnosti). Najvaˇniji z primjer takvog ograniˇenja je ono koje traˇi da dvije n-torke unutar iste relacije ne smiju imati jednaku c z vrijednost kljuˇa. c Stariji DBMS-i orijentirani na SQL nisu pruˇali mogu´nost da se direktno izrazi svojstvo kljuˇa. DBMS ´e tada automatski sprijeˇiti c c c upis vrijednosti 12.UNIQUE indeks. ali ´e propustiti -5. U c s z s c s ovom potpoglavlju bavimo se ˇuvanjem integriteta baze. ). U ve´ini DBMS-a orijentiranih na SQL. Neki DBMS-i omogu´uju da se unutar s c naredbe CREATE ugradi i precizniji uvjet kojeg vrijednosti zadanog tipa moraju zadovoljavati da bi mogle biti vrijednosti dotiˇnog atributa. Uzmimo na primjer da u relaciji STUDENT postoji atribut DOB. ve´ ´e poslati poruku o greˇki. . brojevi s fiksnom toˇkom. brojevi s plivaju´om toˇkom. c s z cc s 6. c c c c s c Na primjer.

Znaˇi jedan te isti podatak.2. Od DBMS-a se zato traˇi da korisnicima omogu´i istovremeni pristup do z c podataka. Na z c primjer. PRIMARY KEY(SNO. LEVEL SMALLINT. Takoder. dakle na atribut u jednoj relaciji koji je ujedno primarni kljuˇ u drugoj relaciji. transakcija. PRIMARY KEY(SNO)). Nakon ovih definicija DBMS ne´e dozvoliti da se naruˇi referencijalni integritet za tri tabele. DBMS ne´e dozvoliti da se u relaciju STUDENT upiˇu dvije n-torke s istim c s s SNO. Uglavnom je rijeˇ o ograniˇenjima koja se c c odnose na strani kljuˇ. Treba biti svjestan da svako ograniˇenje predstavlja c teret prilikom aˇuriranja podataka (troˇi se vrijeme na provjeru). Na primc s jer. 6. DBMS c c c i u tom sluˇaju mora paˇljivo koordinirati konfliktne radnje. TITLE CHAR(40). Zato prilikom zadavanja ograniˇenja z s c ne treba pretjerivati. MARK SMALLINT. Stariji DBMS-i orijentirani na SQL nisu pruˇali mogu´nost da se izrazi svojstvo stranog kljuˇa. CREATE TABLE COURSE (CNO INTEGER NOT NULL. FOREIGN KEY(SNO) REFERENCES STUDENT .3 Ograniˇenja kojima se ˇuva referencijalni integritet c c ˇ Cuva se korektnost i konzistentnost veza izmedu relacija. pohranjen c s c c na jednom mjestu. c c sc Izbor ograniˇenja u danaˇnjim DBMS-ima ipak nije dovoljan da izrazi sva mogu´a pravila inc s c tegriteta. iz COURSE se ne´e mo´i brisati n-torka s vrijednoˇ´u CNO koja se pojavljuje u REPORT . INTEGRITET I SIGURNOST PODATAKA CREATE TABLE STUDENT (SNO INTEGER NOT NULL. Ipak.1 Transakcije i serijalizabilnost Rad korisnika s bazom podataka svodi se na pokretanje unaprijed definiranih procedura. SNAME CHAR(20). Svaki korisnik treba imati dojam da sam c z radi s bazom. c c Svaka vrijednost takvog atributa u prvoj relaciji mora biti prisutna i u drugoj relaciji. Na c c primjer. CNO INTEGER NOT NULL. mogu´nosti pojedinih DBMS-a se razlikuju. u REPORT se ne´e mo´i upisati n-torka s vrijednoˇ´u SNO koja se ne pojavljuje u STUDENT . PRIMARY KEY(CNO)). broj prodanih avionskih karata za isti let treba simultano biti dostupan raznim poslovnicama avionske kompanije. LNAME CHAR(20).2 Istovremeni pristup Ve´ina baza podataka po svojoj prirodi je viˇekorisniˇka. danaˇnji DBMS-i u tom pogledu c s su znatno napredniji od onih prije 15-tak godina. potreban je raznim osobama i raznim aplikacijama. Obiˇno je rijeˇ o prividnoj istovremenosti (dijeljenje vremena istog raˇunala). u kontekstu prethodnih definicija. FOREIGN KEY(CNO) REFERENCES COURSE ). kojom se zadaje odgovaraju´e ograniˇenje. 6. Ili c c sc na primjer. niti da se u relaciju COURSE upiˇu dvije n-torke s istim CNO. moˇda ˇak u isto vrijeme. Makar jedna transakcija sa korisniˇkog stanoviˇta predstavlja jednu nedjeljivu cjelinu. z c c Odgovaraju´u provjeru morao je obavljati aplikacijski program. moˇemo dalje pisati: z CREATE TABLE REPORT (SNO INTEGER NOT NULL.1.CNO). ona se c s . tzv.54 6. 6. Noviji standardi za SQL predvidaju c klauzulu FOREIGN KEY u naredbi CREATE. Ipak. Nakon ovih definicija.

. koja nastaju nakon pojedinih operacija unutar transakcije.. Budu´i da je stanje baze joˇ uvijek nepromic c s jenjeno. Dakle c u bazu se ponovo upisuje da nema slobodnih sjedala. Osnovne operacije s c s c koje pripadaju raznim trasakcijama tada ´e se vremenski ispreplesti. T1 unosi u bazu promijenjenu vrijednost za broj slobodnih sjedala. te da z nekontrolirano paralelno izvrˇavanje transakcija moˇe dovesti do neˇeljenih efekata. Sluˇbenici z sa svojih terminala pokre´u dvije transakcije. drugim rijeˇima.. Ozbiljni DBMS ne smije dopustiti slijed dogadaja iz prethodnog primjera. dakle 1. Na primjer. mora biti neutralizirana . kaˇemo da je dotiˇno paralelno izvrˇavanje skupa transakcija bilo serijalizabilno. dakle jedna iza druge u nekom (bilo kojem) s redoslijedu. 8. COMMIT WORK .. mogu biti nekonzistentna. Znaˇi. c s c s Transakcija koja iz bilo kojeg razloga nije do kraja bila obavljena. T2 smanjuje proˇitanu vrijednost s 1 na 0.. dakle DBMS u svakom trenutku mora garantirati serijalizabilnost. c Dolazi do slijede´eg vremenskog redoslijeda obavljanja elementarnih operacija. Sljede´i nizovi SQL naredbi predstavljaju uspjeˇno izvrˇenu s c s s transakciju. (greˇka) . za avionsku komc paniju prodaja jedne avionske karte moˇe predstavljati jednu transakciju. uˇitani broj je neaˇuran. c z 4. jedan (bilo koji) putnik trebao je dobiti kartu. naredba 1 .. s z z Dva putnika istovremeno stiˇu u dvije razliˇite poslovnice avionske kompanije i traˇe kartu z c z za isti let istog dana. naredba 2 . Budu´i da je na poˇetku svog rada naiˇla na broj slobodnih sjedala ve´i od 0. s 6. c s c Osnovno svojstvo transakcije je da ona prevodi bazu iz jednog konzistentnog stanja u drugo. naziva se serijalizabilnost. odnosno U viˇekorisniˇkoj bazi deˇavat ´e se da se nekoliko transakcija izvodi paralelno. dva s c putnika sjede na istom sjedalu. Iz istih razloga i T2 izdaje drugom putniku kartu. naredba k .. Dakle u bazi sada piˇe da nema slobodnih sjedala. naredba 1 . da uˇinak istovremenog izvrˇavanja transakcija mora biti ekvivalenz c s tan nekom sekvencijalnom izvrˇavanju..dakle svi podaci koje je ona do trenutka prekida promijenila moraju natrag dobiti svoje polazne vrijednosti. Dakle. naredba 2 . ili uop´e ne smije biti izvrˇena. 5. Sliˇno i T2 unosi u bazu svoju promijenjenu vrijednost za broj slobodnih sjedala. Da bi se ˇuvao integritet baze. T1 uˇitava iz baze broj slobodnih sjedala. koje DBMS “istovremeno” obavlja. 7. Promjena je za sada uˇinjena samo u radnoj c c memoriji raˇunala. povratak). c 2... Ili. Traˇimo da uˇinak tih transakc z c cija bude isti kao da su se one izvrˇavale sekvencijalno. Vidimo da je avionska kompanija prodala jednu kartu previˇe. ISTOVREMENI PRISTUP 55 obiˇno realizira kao niz od nekoliko elementarnih zahvata u samoj bazi... c . c 1. . T1 izdaje c c s c putniku kartu. c 3. Zato je potrebna neka vrsta s kontrole (koordinacije) istovremenog izvrˇavanja transakcija. Traˇeno svojstvo. dok zavrˇetak (i naˇin c s c zavrˇetka) mora eksplicitno biti zadan. U sklopu jedne karte obiˇno z c je ukljuˇeno viˇe letova (prelasci. Razni DBMS-i to rade na razne naˇine. Sljede´i primjer s avionskom kompanijom pokazuje da se a priori ne moˇe garantirati serijalizabilnost. pa to povlaˇi nekoliko operacija upisa u bazu. s ROLLBACK WORK . T1 smanjuje proˇitanu vrijednost s 1 na 0. s c Uobiˇajena tehnika zasniva se na lokotima. transakcija mora u cijelosti biti izvrˇena.2. T2 uˇitava iz baze broj slobodnih sjedala.6. c dok je drugi trebao dobiti obavijest da viˇe nema slobodnih mjesta. U SQL-u se poˇetak transakcije odreduje implicitno ili posebnom naredbom. No medu-stanja. BEGIN WORK . Promjena je opet uˇinjena samo u radnoj c c memoriji. U tom trenutku postoji samo jedno slobodno sjedalo. T1 i T2 . ukoliko to svojstvo zaista s z c s c vrijedi. odnosno neuspjeˇnu i neutraliziranu transakciju: s BEGIN WORK . .

c c c 2. Znaˇi “istovremeno” c z c c izvrˇavanje T1 i T2 sada je serijalizabilno.one ´e vjeˇno ˇekati jedna drugu. T1 ponovo zakljuˇa sjedalo 1. to je kontrola zakljuˇavanja jednostavnija za DBMS. T1 zakljuˇa podatak o sjedalu 1 jer mu misli pristupiti. ali mora ˇekati jer je T1 ve´ zakljuˇala taj podatak. te otkljuˇa sjedalo 2. ˇita ime Ivan i pamti ga kao prvo ime.2. T1 zakljuˇa sjedalo 1. Zrnatost suvremenih DBMS-a je obiˇno reda veliˇine n-torke ili bar fiziˇkog bloka. c c c c c 1. Tada ´e T1 prva zakljuˇati broj slobodnih sjedala. s s Opet promatramo transakciju kojom na zadanom letu dva putnika mijenjaju sjedala. z c c c c 4.56 6. Kad transakcija naide c na podatke koji su ve´ zakljuˇani. c z c ˇ Sto je zrno krupnije. T1 i T2 . c Tada je mogu´ slijede´i redoslijed obavljanja elementarnih operacija. Baza je podijeljena na viˇe c z s dijelova. ˇita ime Marko i pamti ga kao drugo ime. upisuje mu zapam´eno drugo ime (dakle Marko). s Veliˇina dijela baze kojem je pridruˇen jedan lokot odreduje zrnatost zakljuˇavanja (granularity). Tada je mogu´ slijede´i naˇin obavljanja elementarnih operacija. nazovimo ih T1 i T2 . Ukoliko takve z c blokirane transakcije postoje. transakcija treba “vratiti” lokot i time otkljuˇati podatke. c . “deadlock”). Rjeˇenje koje se danas najˇeˇ´e koristi je sljede´e. Iz istih razloga T2 zakljuˇa podatak o sjedalu 2. c c c 1. Time se c c c c zapravo izbjegava (sasvim) istovremeni pristup istom podatku. no povremeno se kontrolira da li ima blokiranih transakcija s (traˇi se ciklus u usmjerenom grafu koji prikazuje koja transakcija ˇeka koju). te c c sc mora osigurati da se ta blokada sprijeˇi ili prekine.2. Uzmimo da su istovremeno pokrenute dvije identiˇne transakcije. Neka T1 mijenja imena putnika na sjedalima 1 i 2. pa drugi putnik ne´e dobiti kartu. c z c c c Oˇigledno ni T1 ni T2 viˇe ne mogu nastaviti rad . c s c c c Software koji koristi lokote mora raˇunati s upravo opisanom mogu´noˇ´u blokade transakcija. Da bi toˇnije objasnili o ˇemu se radi.3 Dvofazni protokol zakljuˇavanja c Na osnovu do sada pokazanih primjera. Zamislimo sada da su istovremeno s c pokrenute dvije transakcije ovakve vrste. c 3. Transakcija koja ˇeli pristupiti nekom c z ˇ podatku najprije mora “uzeti” odgovaraju´i lokot i time zakljuˇati dotiˇni dio baze. Naime. Sliˇno T2 traˇi lokot za sjedalo 1. T2 ´e (nakon kratkog ˇekanja) uˇitati c c s z c c c ve´ aˇuriranu vrijednost (0 slobodnih sjedala). Cim je obavila c c c svoju operaciju. joˇ jednom ´emo se posluˇiti c s c z zamiˇljenim “scenarijem” vezanim uz naˇu avionsku kompaniju. INTEGRITET I SIGURNOST PODATAKA 6. a pogreˇni utisak stekao se zato z c s ˇto su primjeri bili suviˇe jednostavni. ona mora ˇekati dok ih prethodna transakcija ne otkljuˇa. te otkljuˇa sjedalo 1. Pretpostavimo da postoji transakcija kojom dva putnika s c mogu zamijeniti sjedala (na primjer puˇaˇ i nepuˇaˇ). opet s c c ´emo se posluˇiti jednim zamiˇljenim “scenarijem” vezanim uz naˇu avionsku kompaniju. Najve´a od njih je mogu´nost medusobne c c blokade dviju ili viˇe transakcija (tzv. a T2 obavlja istu zamjenu ali u suprotnom redoslijedu. te otkljuˇa sjedalo 1. postoji mogu´nost za nekorektno izvrˇavanje istovres s c s menih transakcija i onda kad se podaci zakljuˇavaju.2 Lokoti i zakljuˇavanje c Lokoti su pomo´ni podaci koji sluˇe za koordinaciju konfliktnih tadnji. koje obje mijenjaju imena c putnika na istim sjedalima 1 i 2. c c 3. tada se jedna od njih prekida. Ovaj mehanizam dovoljan je da otkloni probleme iz proˇlog primjera. tako da jednom dijelu odgovara toˇno jedan lokot. c c c Upotreba lokota krije u sebi i odredene opasnosti. te se ona se ponovo starta u nekom kasnijem trenutku. ali mora ˇekati jer je T2 ve´ zakljuˇala dotiˇni podatak. Da bi to pokazali. To na ˇalost nije toˇno. c 2. T1 traˇi lokot za sjedalo 2. neutralizira se njen dotadaˇnji s uˇinak. Neka na poˇetku na tim sjedalima sjede Ivan i Marko. c s c sc c Privremeno se dopuˇta blokada. c 6. no stupanj paralelnosti rada c je manji. moglo bi se povjerovati da koriˇtenje lokota (uz izbjegavanje s blokade) daje garanciju za serijalizabilnost. Zamislimo da sada obje s c c c transakcije T1 i T2 zakljuˇavaju podatak u bazi kojem misle pristupiti. T1 zakljuˇa sjedalo 2. c z s s Uzmimo da za zadani let i za svako sjedalo u avionu baza podataka pohranjuje ime putnika koji sjedi na tom sjedalu. a otkljuˇat ´e ga tek nakon ˇto ga aˇurira.

te ga samo jednom otkljuˇati (nakon aˇuriranja).3. Naime. u posebnom trenutku. T2 ponovo zakljuˇa sjedalo 1. s c 6. Ako u svakoj od transakcija sva zakljuˇavanja slijede prije prvog otkljuˇavanja. Citanja i promjene istog z z podatka dozvoljavaju se samo ako se one odvijaju u redoslijedu vremenskih ˇigova pripadnih transakz cija. pa ih zatim opet zakljuˇavale. c 8. tj. upisuje mu svoje zapam´eno prvo ime (dakle opet c c Marko). transakcija mora samo jednom zakljuˇati podatak o sjedalu (prije c ˇitanja). te otkljuˇa sjedalo 1. vremenski ˇig. . T2 zakljuˇa sjedalo 2. Preciznije. nestanak struje. c c c 5. 6. te otkljuˇa sjedalo 2.2. T1 ponovo zakljuˇa sjedalo 2. s . No sre´om. No postoje i metode koje ne koriste lokote. 6. T2 zakljuˇa sjedalo 1. . Ivan bi opet bio na sjedalu 1. U sluˇaju naruˇavanja tog redoslijeda. a Ivana nema nigdje. ˇita ime Marko i pamti ga kao svoje drugo ime. Na primjer. Obje transakcije tada ´e c c z c c korektno obaviti svoj posao. Dovoljno je od transakcija zahtijevati da c z se pokoravaju nekom stroˇem “pravilu ponaˇanja”. Lako se uvjeriti da. .6. s Navedeno pravilo zove se dvofazni protokol zakljuˇavanja. c Vidimo da sada na oba sjedala sjedi Marko. tzv. uz ovu promjenu “ponaˇanja”. T2 ponovo zakljuˇa sjedalo 2. upisuje mu svoje zapam´eno drugo ime (dakle Marko). jedna od transakcija mora se prekinuti. ˇita ime Marko i pamti ga kao svoje prvo ime. te otkljuˇa sjedalo c c c 1. ukupni uˇinak svih transakc s c cija je isti kao da se svaka od njih izvrˇavala trenutaˇno. Naime. Naime.4 Vremenski ˇigovi z Dvofazni protokol zakljuˇavanja (uz izbjegavanje blokade) predstavlja primjer tehnike za koordinaciju c paralelnog izvrˇavanja transakcija zasnovane na lokotima. baza podataka moˇe se na´i u “neispravnom” stanju. zakljuˇavanja i otkljuˇavanja c c c s se zbivaju u dvije razdvojene faze tokom izvrˇavanja transakcije. T2 ima ˇig t2 > t1. te otkljuˇa c c c sjedalo 2. Zaista. OPORAVAK 4. stvar se lagano moˇe spasiti. • pogreˇan rad same transakcije. T1 ˇeli c z z z z proˇitati podatak x. Dvofazni protokol zakljuˇavanja bit ´e bolje razumljiv ukoliko se vratimo prethodnom primjeru s c c dvostrukom zamjenom sjedala. Razlozi koji mogu dovesti do z c “oˇte´enja” baze su: s c • prekid transakcije (naredba ROLLBACK WORK. ako T1 ima ˇig t1 . Znaˇi opisani naˇin c c izvrˇavanja transakcija T1 i T2 nije serijalizabilan. tada proizvoljno c c istovremeno izvrˇavanje tih transakcija mora biti serijalizabilno. redoslijed dogadaja c s iz proˇlog primjera viˇe nije mogu´. Razlog zaˇto transakcije T1 i T2 nisu korektno radile je baˇ taj ˇto se s s s one nisu pokoravale protokolu. bilo koji sekvencijalni redoslijed s izvrˇavanja proizveo bi dvostruku zamjenu. kratko spominjemo tehniku zasnovanu na vremenskim ˇigovima (time stamps). s s c c jer T2 ne´e mo´i pristupiti sjedalu 2 dok ga T1 nije aˇurirala i otkljuˇala. moˇe se dokazati da vrijedi slijede´a z s z c tvrdnja. U najmanju ruku. a Marko na s sjedalu 2.3 Oporavak U toku svog rada. a T2 je ve´ mijenjala taj isti x. c c Opisani naˇin izvraˇavanja transakcija garantira serijalizabilnost. tada se T1 mora neutralizirati. koraci 5 i 6 morati ´e zamijeniti redoslijed. te otkljuˇa sjedalo 2. c c Da bi bila u skladu sa protokolom. posljedica kontrole istovremenog rada. 57 Upravo navedeni primjer uvjerio nas je da zakljuˇavanje podataka samo po sebi nije garancija za c serijalizabilnost. s Kao primjer. c c 7. neutralizirati i c s ponovo startati s ve´im vremenskim ˇigom. upisuje mu zapam´eno prvo ime (dakle Ivan). ). U razdoblju izmedu ˇitanja i aˇuriranja c c z c z podatak mora ostati zakljuˇan. obje su otkljuˇavale podatke. z ˇ Svakoj transakciji pridruˇuje se identifikacijski broj.

Uobiˇajeni postupak c naziva se odmotavanje unatrag (roll-back): • ˇita se ˇurnal i pronalaze se stare vrijednosti (pre-images) podataka koje je transakcija mijenjala. tehnikom odgodenog pisanja s (deferred write). . kao ˇto se vidi na Slici 6. problem neutralizcije prekinute transakcije postaje trivijalan. 6. Naime prekinuta transakcija ne uspijeva u ˇurnal ubiljeˇiti toˇku isporuke.3. tada treba i tu drugu transakciju neutralizirati (i ponovo startati). INTEGRITET I SIGURNOST PODATAKA • hardverska greˇka (na primjer kvar diska) ili ˇak fiziˇko uniˇtenje cijelog raˇunala. sc • kontrolne toˇke (checkpoints) u napredovanju transakcije: toˇka poˇetka.3. s c c s c Od suvremenog DBMS-a oˇekuje se da u svim ovim sluˇajevima omogu´i “oporavak” baze. Taj povratak bi se trebao s z s obavljati po mogu´nosti automatski. Ta tehnika zahtijeva da se promjene podataka (nastale kao rezultat rada transakcije) ne upisuju u bazu odmah.3 Neutralizacija jedne transakcije Rijeˇ je o rutinskoj i vrlo ˇestoj operaciji koju DBMS obiˇno obavlja automatski. Isti postupak mogao bi c s se primijeniti za neutralizaciju ve´ dovrˇene transakcije za koju se ustanovilo da je pogreˇna. Za jednu transakciju ˇurnal evidentira: z • identifikator transakcije.58 • greˇka u DBMS-u ili operacijskom sustavu. Svodi se c s s na to da se podacima koje je transakcija mijenjala vrate prethodne vrijednosti.1 Rezervna kopija baze Dobiva se snimanjem cijele baze na drugi medij (magnetska traka ili drugi disk). Stvaranje rezervne kopije je dugotrajna operacija koja ometa redovni rad korisnika. te nakon toga biljeˇi z z toˇku isporuke. toˇka isporuke (commit) c c c c odnosno odustajanja (rollback). rad s z c c transakcije se odvija u dvije faze.2 ˇ Zurnal datoteka Rijeˇ je o datoteci gdje je ubiljeˇena “povijest” svake transakcije koja je mijenjala bazu nakon stvaranja c z zadnje rezervne kopije. • adresu svakog podatka kojeg je transakcija promijenila. ako je neka druga transakcija proˇitala u bazi vrijednost unesenu od upravo neutralizirane c transakcije. c • ˇim je ubiljeˇena toˇka isporuke. Da bi oporavak bio mogu´. log file). ve´ periodiˇki u unaprijed predvidenim s c c c terminima (na primjer jednom tjedno). s 6.1: s • transakcija upisuje u ˇurnal sve promjene koje bi trebala napraviti u bazi. Primjenjuje se za c c c neutralizaciju transakcije koja je poˇela pisati u bazu no nije doˇla do kraja. i to u trenutku kad smatramo da je baza u konzistentnom stanju. c z c z Uz primjenu ove tehnike. Detalji cijelog postupka mogu biti dosta komplicirani i oni ovise o tome kako se obavlja koordinacija paralelnog rada viˇe s transakcija. Rezervna kopija i ˇurnal datoteka z z omogu´uju razne vrste oporavka. pa stoga DBMS ne prenosi njene z z c promjene u bazu. ili bar na relativno jednostavan naˇin. 6. dakle njen c c c povratak u stanje koje je ˇto aˇurnije i pritom joˇ uvijek konzistentno. Dva najvaˇnija oblika su: neutralizacija prekinute ili pogreˇne c z s transakcije. c Osim toga. c z • te stare vrijednosti se ponovo upisuju na odgovaraju´a mjesta u bazu. Znaˇi. Za vrijeme kopiranja ne smije se obavljati nikakva transakcija koja mijenja podatke. Tada se neutralizacija prekinute transakcije elegantno rjeˇava tzv. te ponovno uspostavljanje baze nakon njenog znatnijeg oˇte´enja. Stvari se bitno pojednostavnjuju ukoliko zamislimo da DBMS odjednom obavlja samo jednu transakciju. s c 6. tipiˇno to su: rezervna kopija z s c c baze (backup copy) i ˇurnal datoteka (journal file. DBMS prenosi odjednom sve promjene iz ˇurnala u bazu. zajedno s prethodnom vrijednoˇ´u tog sc podatka (pre-image) i novom vrijednoˇ´u (post-image).3. c c c DBMS osim same baze mora odrˇavati joˇ i neka pomo´na sredstva. nego tek nakon ˇto transakcija unese u ˇurnal toˇku isporuke. Zato se kopiranje ne obavlja suviˇe ˇesto.

te mora dokazati svoj identitet navodenjem lozinke.1 Identifikacija korisnika Uobiˇajeno je da svaki korisnik baze ima svoje korisniˇko ime (username) i lozinku (password). pa su time bitno ograniˇene z c njegove mogu´nosti rada.ˇ ˇ 6. koje predstavljaju zaposlene u poduze´u s c c i njihove odjele. c U relacijskom modelu. • odredi se zadnja (posebna) kontrolna toˇka u ˇurnalu.4. No pogledi ujedno sluˇe i za zaˇtitu podataka. ograniˇava se udaljeni pristup do raˇunala kroz c c c c c mreˇu.4. z Nakon ovoga. U SQL-u se relacija-pogled c c zadaje naredbom CREATE VIEW. DBMS moˇe odredenom korisniku z s z pridruˇiti njegov pogled na bazu. ZASTITA OD NEOVLASTENOG PRISTUPA   baza    59 transakcija promjene E ˇurnal z commit E Slika 6. c z • proˇita se dio ˇurnala od poˇetka do zadnje kontrolne toˇke. c z c c • ponovo se unose u bazu promjene podataka (post-images). Da c c bi smio raditi s bazom.2 Pogledi kao mehanizam zaˇtite s U Poglavlju 1 spomenuli smo poglede (pod-sheme) kao sredstvo za postizavanje logiˇke neovisnosti c podataka. Dalje. DBMS se moˇe osloniti na imena i lozinke koji ve´ postoje u operacijskom sustavu z c raˇunala. a izvodenje iz globalnih relacija opisuje se naredbom SELECT koja je ugnijeˇdena u CREATE VIEW. DBMS raspolaˇe popisom korisniˇkih imena i pripadnih lozinki. uspostavit ´e se stanje baze koje odgovara zadnjoj (posebnoj) kontrolnoj toˇki. Pritom se relacije koje ˇine pogled izvode iz relacija koje ˇine globalnu shemu. c z z 6.4 Zaˇtita od neovlaˇtenog pristupa s s Baza podataka mora biti zaˇti´ena od nedopuˇtenih ili ˇak zlonamjernih radnji. Korisnik tada “vidi” samo dio baze. ili se moˇe sluˇiti vlastitim popisom. Uobiˇajeni postupak naziva se odmotavanje prema naprijed (roll-forward). Svodi se na ponovni upis svih s c c s podataka. U ˇurnalu moraju c z biti upisane posebne kontrolne toˇke koje oznaˇavaju trenutke kad je baza joˇ bila konzistentna (obiˇno c c s c su to trenutci kad nije bilo aktivnih transakcija).1: Izvrˇavanje transakcije primjenom tehnike odgodenog pisanja s 6. c c c c c 6. To je c c najbolje ˇto moˇemo uˇiniti. Cijelu bazu ˇine dvije relacije. i to redom za svaku isporuˇenu transakc ciju iz promatranog dijela ˇurnala. Zaˇtita se zasniva s s na tajnosti lozinke. z U nastavku navodimo primjer globalne sheme i pripadnih pogleda kojima se povjerljivi podaci skrivaju od neovlaˇtenih korisnika. Naime. Ukoliko z c korisnik navede ime i lozinku koji ne odgovaraju popisu. Primjenjuje se c z c nakon znatnijeg oˇte´enja baze ili u sluˇaju njenog potpunog uniˇtenja. . koji je ugraden u DBMS. Postupak je tada sljede´i: c • uspostavlja se stanje baze zabiljeˇeno zadnjom rezervnom kopijom (snimanje s magnetskih traka z na disk). DBMS mu ne dopuˇta rad.4.4 Ponovno uspostavljanje baze Rijeˇ je o izvanrednoj i opseˇnoj operaciji koja se pokre´e na zahtjev administratora. s z c 6.3. No nas ovdje prvenstveno zanima finiji softverski vid zaˇtite. korisnik se mora predstaviti DBMS-u navodenjem imena. Osnovni vid zaˇtite je s c s c s fiziˇko ograniˇenje pristupa do samog raˇunala. Njime z s se ljudima koji imaju mogu´nost rada na dotiˇnom raˇunalu ograniˇavaju mogu´nosti rada s bazom. i globalna shema i pogled (pod-shema) zadaju se kao skup relacija.

no samo za zaposlene u odjelu broj 3: CREATE VIEW EMPVIEW2 AS SELECT * FROM EMPLOYEE WHERE DEPTNO = 3 . Na s z primjer. ve´ se dobiva kombiniranjem podataka iz posc toje´ih relacija. Korisnik vidi samo “vertikalni” segment relacije. . Drugi pogled namijenjen je korisniku koji smije pristupiti cijeloj n-torki o zaposlenima. moˇemo s z uskratiti INSERT i DELETE za isti pogled. Ovlaˇtenje UPDATE se kod nekih DBMS-a moˇe zadati posebno za svaki atribut. ADDRESS.ovlaˇtenje brisanja n-torki u zadanoj relaciji (pogledu). DBMS uz korisnika veˇe njegova ovlaˇtenja (authorities). MANAGERNO ) Poglede ´emo opisati pomo´u SQL naredbi CREATE VIEW. Tre´i pogled sluˇi za korisnika-menadˇera. te ovlaˇtenje UPDATE za atribut SALARY u pogledu EMPVIEW3 . EMPLOYEE. EMPLOYEE. s ALTER . ADDRESS. . .DNAME FROM EMPLOYEE.60 6. ENAME. s CONNECT . s DELETE . DEPARTMENT WHERE EMPLOYEE. On smije pristupiti samo podacima o osobama koje su c z z zaposlene u njegovim odjelima: CREATE VIEW EMPVIEW3 AS SELECT EMPLOYEE. Osim pogleda. s UPDATE .SALARY.4.3 Ovlaˇtenja s Pogled odreduje kako korisnik “vidi podatke”. DEPARTMENT. dodavanje novih atributa).ovlaˇtenje mijenjanja podataka u zadanoj relaciji (pogledu).MANAGERNO = .DEPTNO AND DEPARTMENT.ovlaˇtenje ˇitanja podataka iz zadane relacije (pogleda). ENAME. DNAME. c c Prvi pogled namijenjen je korisniku koji smije pristupiti podacima o zaposlenima.ovlaˇtenje ubacivanja novih n-torki u zadanu relaciju (pogled). DEPTNO FROM EMPLOYEE . Takoder. Tada bi manager mogao mijenjati pla´e svojim suradc nicima. DEPTNO ) DEPARTMENT ( DEPTNO. Korisnik vidi samo “horizontalni” segment relacije.ovlaˇtenje mijenjanja grade zadane relacije (na primjer. DEPARTMENT. . z Korisnik vidi relaciju koja zapravo ne postoji u bazi. s c s Neka korisnikova ovlaˇtenja zadaju se posebno za svaku relaciju (pogled). c . Uobiˇajena z s c ovlaˇtenja u SQL-u su: s SELECT . (menadˇerov identifikacijski broj) . no on ne odreduje ˇto korisnik moˇe raditi s tim s z podacima.DEPTNO.ovlaˇtenje koje korisniku daje status administratora baze (i povlaˇi sva ostala ovlaˇtenja). no ne i njihovim pla´ama: c CREATE VIEW EMPVIEW1 AS SELECT EMPNO.ENAME. s c DBA .ovlaˇtenje korisniku raˇunala da se smije prijaviti za rad s bazom. s c INSERT .EMPNO. niti bi mogao dovoditi nove suradnike. INTEGRITET I SIGURNOST PODATAKA EMPLOYEE ( EMPNO. c 6. . a neka se zadaju unis verzalno. no ne bi ih mogao izbacivati iz poduze´a.DEPTNO = DEPARTMENT. SALARY. menadˇer koji koristi pogled EMPVIEW3 moˇe imati ovlaˇtenje SELECT za pogled EMz z s PVIEW3 .

Da bi sve to mogao raditi. s . Tako z c s na primjer administrator moˇe nekom korisniku dati ovlaˇtenje UPDATE za zadanu relaciju. s U nekim DBMS-ima administrator moˇe neke od svojih specifiˇnih ovlaˇtenja prenijeti drugima. sam s s administrator mora imati najve´a mogu´a ovlaˇtenja. On upisuje popis korisnika. uz z s dozvolu da taj korisnik to isto ovlaˇtenje dalje daje drugim korisnicima. • pravo upravljanja fiziˇkim resursima od kojih se gradi baza (prostor na disku. datoteke). c • pravo davanja i oduzimanja ovlaˇtenja drugim korisnicima baze. ZASTITA OD NEOVLASTENOG PRISTUPA 61 Ukoliko korisnik pokuˇa obaviti radnju za koju nije ovlaˇten. zadaje poglede i podeˇava ovlaˇtenja.4. DBMS ne´e izvrˇiti dotiˇnu operaciju s s c s c te ´e umjesto toga ispisati poruku o greˇki (povreda ovlaˇtenja). brigu oko zaˇtite od neovlaˇtenog pristupa preuzima administrator s s baze.ˇ ˇ 6. c s s U velikom bazama podataka. • pravo definiranja pogleda ili brisanja tih pogleda. Neka od posebnih administratorovih ovlaˇtenja c c s s su: • pravo stvaranja ili brisanja cijelih relacija ili indeksa.

62 6. INTEGRITET I SIGURNOST PODATAKA .

Zagreb. 5th Edition.F. Addison-Wesley.L.: Introduction to SQL. Reading MA. Korth H. Addison-Wesley.: Foundations of Databases. c c 1994. Addison-Wesley. McGraw-Hill. [2] Silberschatz A. 2005.J. [6] Tharp A..: Baze podataka . Gehrke J.. John Wiley and Sons. New York. Hull R. 2003.: An Introduction to Database Systems. New York. Sebastopol CA. 3rd Edition. New York. [4] Abiteboul S. 8th Edition. DRIP. O’Reilly.F. 2002.: File Organization and Processing.. Axmark D. [8] Widenius M. logiˇko i fiziˇko modeliranje podataka. 2006.: Database Management Systems. Reading MA. Vianu V. [7] Varga M. McGraw-Hill.. 4th Edition.: Database System Concepts. [5] Van der Lans R. [3] Ramakrishnan R.. Reading MA.konceptualno. 63 . Sudarshan S.Literatura [1] Date C. 1995. 2002.: MySQL Reference Manual. 1988..

Sign up to vote on this title
UsefulNot useful