Ekonomski fakultet

Sveuilite u Rijeci
Ivana Filipovia 4

BAZE PODATAKA: Teorijske znaajke, modeli

podataka i dijagram objekti veze

Martina Jurai, 0081094361

Dijana Petrovi, 0081127781

1. UVOD U BAZE PODATAKA

Osnovni pojmovi vezani uz baze podataka
Baze podataka predstavljaju viu razinu rada s podacima u odnosu na klasine programske
jezike. Rije je o tehnologiji koja je nastala s namjerom da se uklone slabosti tradicionalne
automatske obrade podataka iz 60-tih i 70-tih godina 20. stoljea. Ta tehnologija osigurala
je veu produktivnost, kvalitetu i pouzdanost u razvoju aplikacija koje se svode na
pohranjivanje i pretraivanje podataka u raunalu.
1

Baza podataka je organizirana zbirka podataka. Termin je izvorno nastao unutar raunalne
industrije, a njegovo se znaenje proirilo popularnom upotrebom toliko da Europska
direktiva za baze podataka (koja za baze podataka donosi prava za intelektualno vlasnitvo)
ukljuuje i ne elektronske baze podataka unutar svoje definicije. Ovaj lanak je ogranien vie
na tehniku upotrebu termina, iako ak i meu raunalnim profesionalcima neki pripisuju
mnogo ire znaenje rijei od drugih.
Jedna od moguih definicija baze podataka glasi da je to zbirka zapisa pohranjenih u raunalu
na sustavni nain, takav da joj se raunalni program moe obratiti prilikom odgovaranja na
problem. Svaki se zapis za bolji povratak i razvrstavanje obino prepoznaje kao skup
elemenata (injenica) podataka. Predmeti vraeni u odgovoru na upitnike postaju informacije
koje se mogu koristiti za stvaranje odluka koje bi inae mogle biti mnogo tee ili nemogue
za stvaranje. Raunalni program koriten za upravljanje i ispitivanje baze podataka nazvan je
sustav upravljanja bazom podataka (SUBP). Svojstva i dizajn sustava baze podataka ukljueni
su u prouavanje informatike znanosti.
Sredinji koncept baze podataka je jednak onome od zbirke zapisa ili dijelova znanja. Za danu
bazu podataka tipino postoji strukturni opis vrste injenica sadranih u toj bazi podataka: taj
opis naziva se shema. Shema opisuje predmete koji su prikazani u bazi podataka, te odnose
meu njima. Postoje brojni razliiti naini organiziranja sheme, to jest od modeliranja
strukture baze podataka: oni se zovu modeli baza podataka (ili modeli podataka). Model u
najrairenijoj upotrebi danas je odnosni model, koji laiki reeno prikazuje sve informacije u
obliku mnogostrukih odnosnih tablica od kojih se svaka sastoji od redova i stupaca (prava
definicija koristi matematiku terminologiju). Ovaj model prikazuje odnose upotrebom
vrijednosti koje su zajednike za vie od jedne tablice. Ostali modeli poput hijerarhijskog
modela i mrenog modela koriste prikaze i odnose koji su mnogo eksplicitniji.
Naziv baza podataka se strogo govorei odnosi na zbirku zapisa, a na softver bi se trebalo
odnositi kao na sustav upravljanja bazom podataka ili SUBP. Kada je kontekst nedvojben,
mnogi administratori za baze podataka i programeri ipak koriste termin baza podataka da
pokriju oba znaenja.
Mnogi profesionalci e smatrati da zbirka podataka stvara bazu podataka jedino ako ima
odreena svojstva: primjerice, ako se podacima upravlja kako bi osigurali svoj integritet i
kvalitetu, ako omoguuje zajedniki pristup nekoj zajednici korisnika, ako ima shemu, ili ako
podrava upitni jezik. Ipak dogovorena definicija ovih svojstava ne postoji.

Varga M., Baze podataka, Zagreb 1994.; str. 10

Sustavi upravljanja bazom podataka obino se kategoriziraju prema modelu podataka koji
podravaju: odnosni, orijentirani prema objektu, mreni i tako dalje.
Modeli baza podataka
Razliite tehnike se koriste za strukturu modela podataka. Veina sustava baza podataka se
grade oko jednog odreenog modela podataka, iako je u porastu zajedniko proizvodima da
nude podrku za vie od jednog modela. Za bilo koji logiki model mogu biti mogue razliite
fizikalne provedbe, a veina e proizvoda ponuditi korisniku neku razinu kontrole u ugaanju
fizikalne provedbe, poto uinjeni izbori imaju znaajan uinak na performansu. Primjer toga
je odnosni model: sve ozbiljne provedbe odnosnog modela doputaju stvaranje indeksa, koji
omoguuju brzi pristup redovima u tablici, ako su poznate vrijednosti odreenih stupaca.
Model podataka nije samo nain strukturiranja podataka: on takoer definira skup operacija
koje se mogu izvoditi na podacima. Odnosni model, primjerice, definira operacije kao to su
selekcija ili odabir, projekcija i spajanje. Iako ove operacije ne moraju biti eksplicitne u
odreenom query jeziku, one omoguuju temelje na kojima je query jezik izgraen.
Ravni model
Neki se ne bi sloili da ovo spada u vrste modela podataka zbog gornje definicije.
Ravni model|Ravni (ili tablini) model sastoji se od pojedinanog, dvodimenzionalnog reda
elemenata podataka, gdje se za sve lanove danog stupca pretpostavlja da su sline
vrijednosti, te da su svi lanovi reda povezani jedni s drugima. Na primjer, stupci za ime i
lozinku mogu se koristiti kao dio sigurnosnog sustava baze podataka. Svaki red bi imao
specifinu lozinku povezanu s individualnim korisnikom. Stupci tablice esto imaju tip
povezan s njima, definirajui ih kao oznake podataka, datum ili vremensku informaciju,
cjelinu ili brojeve lebdeih toaka. Ovaj model je sluajno i baza tablinog raunanja.
Mreni model
2

Mreni model opisan je skupom meusobno povezanih slogova. Slog, preciznije tip
(odnosno vrsta) sloga, u mnogim je aspektima slian tipu entiteta modela entiteta veze.
Jedan slog sadri podatke jedne pojave entiteta. Sastoji se od polja koja odgovaraju
atributima. Savako polje sadri jednu vrijednost atributa. Slogovi se povezuju fizikim
vezama (eng. link) koje su srodne binarnim vezama modela entiteti-veze.
Struktura podataka mrenog modela opisuje se dijagramom strukture podataka, ija je
namjena jednaka dijagramu entiteti veze. Slog se oznaava pravokutnikom, a veza linijom
izmeu dva sloga.
Mreni model (definiran prema CODASYL specifikaciji) organizira podatke upotrebom dvije
fundamentalne konstrukcije, nazvane zapisi i skupovi. Zapisi sadre polja (koja mogu biti
organizirana hijerarhijski kao u COBOL-u). Skupovi (ne treba se zabuniti s matematikim
skupovima) definiraju odnose "jednog naprama svima" izmeu zapisa: jedan vlasnik, mnogo
lanova. Zapis moe biti i vlasnik i lan u bilo kojem broju skupova.

Varga M., Baze podataka, Zagreb 1994.; str. 160

Operacije mrenog modela navigacijske su u stilu da: program odrava tekui poloaj i
upravlja od jednog do drugog zapisa slijedei odnose u kojima sudjeluje zapis. Zapisi mogu
takoer biti smjeteni dobavljanjem kljunih vrijednosti.
Iako nije bitno obiljeje modela, mrena baza podataka openito provodi skup odnosa
sredstvima pokazivaa koji izravno adresiraju mjesto zapisa na disku. To daje izvrsne
povratne performanse na raun operacija poput uitavanja i reorganizacije baze podataka.
Odnosni model
Odnosni model je uveo E. F. Codd 1970. godine u svom akademskom radu kao nain
stvaranja sustava upravljanja bazom podataka neovisnije od bilo koje druge posebne
primjene. To je matematiki model definiran u terminima predikatne logike i teorije skupova.
Iako je osnovna ideja odnosne baze podataka bila veoma popularna, relativno malen broj ljudi
razumije matematiku definiciju, a samo nekoliko njih primjenjuje nejasne SUBP-ove u
potpunosti i bez nekakvih dopuna. Oracle baza podataka, primjerice, moe se koristiti na isto
relativni nain, ali takoer doputa i tablicama koje omoguuju dvostruke redove da se
definiraju kao -- dodatak (ili prijestup) odnosnog modela. U uobiajenoj upotrebi hrvatskog
jezika, SUBP se naziva odnosnim ako podrava odnosne operacije, bez obzira da li provodi
strogo pristajanje prema formalnom odnosnom modelu. Sljedee objanjenje je neformalno,
ne tehniko objanjenje kako "odnosni" sustavi upravljanja bazom podataka obino
funkcioniraju.
Odnosna baza podataka sadri mnogostruke tablice, svaka slina onoj u "ravnom" modelu
baza podataka. Ipak, za razliku od mrenih baza podataka, tablice nisu povezane
pokazivaima. Umjesto toga kljuevi se koriste za slaganje redova podataka u razliitim
tablicama. Klju je samo jedan ili vie stupaca u jednoj tablici koja odgovara stupcima u
drugoj tablici. Svaki stupac moe biti klju ili se mnogostruki stupci mogu grupirati zajedno u
pojedinaan klju. Za razliku od pokazivaa, nije potrebno definirati sve kljueve unaprijed;
stupac se moe koristiti kao klju ak ako nije izvorno namjeravao biti jednim od njih.
Klju koji se moe koristiti za jedinstveno identificiranje reda u tablici naziva se jedinstvenim
kljuem. Tipino je jedan od jedinstvenih kljueva preferirani nain za povezivanje njega s
redom; takav klju definira se kao tablini primarni klju.
Kada se klju sastoji od podataka koji imaju vanjsko, realno znaenje (poput osobnog imena,
ISBN knjige ili serijskog broja automobila), naziva se "prirodni" klju. Ako nijedan prirodni
klju nije prikladan (razmislite o brojnim ljudima s prezimenom Babi), moe se dodijeliti
arbitraran klju (poput davanja zaposlenicima ID brojeve). U praksi veina baza podataka ima
i generirane i prirodne kljueve, jer se generirani kljuevi mogu koristiti interno za stvaranje
poveznica izmeu redova koji ne mogu puknuti, dok se prirodni klju moe koristiti, manje
pouzdano, za istraivanja i integraciju s drugim bazama podataka. (Na primjer, zapisi u dvije
neovisno razvijene baze podataka mogu se povezati preko broja socijalnog osiguranja, osim
kada su brojevi socijalnog osiguranja netoni, nedostaju ili su promijenjeni.)

Odnosne operacije
Korisnici (ili programi) potrauju podatke iz odnosne baze podataka slanjem upitnika koji je
napisan u posebnom jeziku, obino dijalektu SQL-a. Iako je SQL izvorno namijenjen za
krajnje korisnike, mnogo je uobiajenije za SQL upitnike da se ugrauju u softver koji
omoguuje jednostavnije korisniko suelje. (Mnoge web stranice izvode SQL upitnike
prilikom stvaranja stranice.)
Baza podataka u odgovoru na upitnik vraa skup rezultata, koji je samo popis redova koji
sadre odgovore. Najjednostavniji upitnik je samo vraanje svih redova iz tablice, ali se
mnogo ee redovi filtriraju na odreeni nain da povrate samo traeni odgovor.
esto se podaci iz mnogostrukih tablica spajaju u jednu, tj. provodi se spajanje. To se radi
koncepcijski uzimanjem svih moguih kombinacija redova ("presjeni proizvod") te zatim
filtriranjem svega osim odgovora. U praksi sustavi upravljanja odnosnim bazama podataka
prepisuju ("optimiziraju") upitnike da se izvode bre, upotrebom razliitih tehnika.

Primjer upita

Fleksibilnost odnosnih baza podataka doputa programerima pisanje upitnika u kojem nisu
sudjelovali dizajneri baza podataka. Kao rezultat, odnosne se baze podataka mogu koristiti u
mnogostrukim primjenama na naine koje originalni dizajneri nisu predvidjeli, to je naroito
vano za baze podataka koje su se moda koristile desetljeima. To je uinilo vrlo popularnim
ideju i primjenu odnosnih baza podataka u trgovini.

Dimenzijski model
Dimenzijski model je specijalizirana preradba odnosnog modela koritenog za prikazivanje
podataka u spremitima podataka na nain na koji se podaci mogu lako saeti upotrebom
OLAP upitnik. U dimenzijskom modelu baza podataka se sastoji od jedne velike tablice
injenica koje su opisane upotrebom dimenzija i veliina.
6

Dimenzija omoguuje kontekst injenice (poput tko je sudjelovao, kada i gdje se dogodilo i
njezin tip), a koristi se u upitnicima za zajedniko grupiranje srodnih injenica.
Dimenzije tee da budu zasebne, a esto su i hijerarhijske; na primjer, mjesto moe ukljuivati
zgradu, regiju i dravu. Veliina je koliina koja opisuje injenicu kao to je dohodak. Vano
je da veliine mogu biti znaajno nagomilane - na primjer, dohodak s razliitih mjesta moe
se zajedno pridodati.
U OLAP upitniku dimenzije su odabrane, a injenice grupirane te pridodane zajedno da stvore
saetak.
Dimenzijski model se esto provodi na vrhu odnosnog modela upotrebom zvjezdaste sheme
koja se sastoji od jedne tablice koja sadri injenice i okolne tablice koja sadri dimenzije.
Komplicirane dimenzije mogu posebice biti prikazane upotrebom mnogostrukih tablica,
rezultirajui u pahuljinoj shemi.
Spremite podataka moe sadravati mnogostruke zvjezdaste sheme koje meusobno dijele
dimenzijske tablice, omoguujui im da se zajedno koriste. Pojavljivanje sa standardnim
skupom dimenzija vaan je dio dimenzijskog modeliranja.
Provedbe i indeksiranje
Sve ovdje navedene vrste baza podataka stjeu mogu stei prednost indeksiranja za poveanje
svoje brzine, pa se ta tehnologija uasno unaprijedila od svojih ranih upotreba u 1960-im i
1970-im. Najuobiajenija vrsta indeksa je razvrstani popis sadraja nekog posebnog stupca u
tablici, s pokazivaima u redu kojem je pridruena vrijednost. Indeks omoguuje skupu
redova tablice da povee neki kriterij radi breg pronalaenja. Obino se koriste razliite
metode indeksiranja: B-stabla, heevi i povezani popisi. Sve navedene su uobiajene tehnike
indeksiranja.
Odnosni SUBP-ovi imaju prednost u kojoj se indeksi mogu stvoriti ili ispustiti bez promjene
postojeih aplikacija, jer aplikacije ne koriste izravno indekse. Umjesto toga softver baze
podataka odluuje o prednosti aplikacije ako se upotrijebe najpogodniji indeksi. Pri tom baza
podataka odabire meu mnogim razliitim strategijama utemeljenima na onoj za koju procjeni
da e joj omoguiti najbri rad.
Odnosni SUBP-ovi upotrebljavaju mnoge razliite algoritme radi izraunavanja rezultata SQL
tvrdnje. OSUBP-ovi e proizvesti plan kako izvriti upitnik, koji je stvoren analiziranjem
vremena rada razliitih algoritama i odabirom najbreg. Neki od kljunih algoritama koji se
bave sa spajanjima jesu slaganje ugnijeenih prstenova, spajanje sloi-spoji i he slaganje.

Kartiranje predmeta u bazama podataka

Tijekom nedavnih godina paradigma orijentirana prema predmetu primjenjivala se jednako i
na baze podataka, stvarajui tako novi programski model poznat kao predmetne baze
podataka. Ove baze podataka pokuavaju nadvladati neke potekoe pri upotrebi predmeta sa

SQL SUBP-ovima. Program orijentiran prema predmetu omoguuje predmetima istog tipa da
se razliito provode i ponaaju onoliko dugo dok imaju isto suelje (polimorfizam). To se ne
uklapa dobro s SQL bazama podataka gdje se korisniko-odreeni tipovi teko definiraju i
koriste, te gdje opstaju Dvije velike zablude: identifikacija razreda tablicama (ispravna
identifikacija je od razreda s tipovima i od predmeta s vrijednostima) i upotreba pokazivaa.
Do sada su isprobani razliiti naini spremanja predmeta u bazu podatka, ali ipak ne postoji
velika suglasnost kako bi se to trebalo uiniti. Provedba predmetnih baza podataka uklanja
pogodnosti odnosnog modela uvoenjem pokazivaa i stvaranjem mnogo tee ad hoc
upitnika. To je zato jer su oni bitne adaptacije zastarjele mree i hijerarhijskih baza podataka
na programiranju orijentiranome prema predmetu. Posljedica predmetne baze podataka tee
da budu koritene u specijaliziranim primjenama, dok ope namjenske predmetne baze
podataka nisu veoma popularne. Umjesto toga predmeti se esto spremaju u SQL baze
podataka upotrebom softvera s kompliciranim kartiranjem. Istovremeno prodavai SQL
SUBP-a su nadodali obiljeja kako bi omoguili predmetima mnogo pouzdaniju pohranu,
razvijajui dalje do odnosnog modela.
Primjene baza podataka
Baze podataka se koriste u mnogim aplikacijama, proteui se na stvarno itav opseg
raunalnog softvera. Baze podataka su poeljna metoda spremanja velikih multikorisnikih
aplikacija gdje je potrebna koordinacija izmeu mnogih korisnika. ak ih individualni
korisnici smatraju pouzdanima, iako se mnogi elektroniki potanski programi i osobni
organizatori temelje na standardnoj tehnologiji baza podataka. Softverski pokretai baza
podataka su dostupni za veinu platformi baza podataka tako da aplikacijski softver moe
koristiti zajedniko aplikacijsko programsko suelje (APS) kako bi povratio informacije
pohranjene u bazi podataka. Jedan primjer APS pokretaa baze podataka je JDBC.
Transakcije i podudarnost
Pored njihovog modela podataka veina praktinih baza podataka ("transakcijske baze
podataka")pokuava provesti model transakcije baze podataka koji ima poeljna svojstva za
integraciju podataka. Softver baze podataka bi trebao prema zamisli provoditi ACIP pravila
saeta ovdje:

Atomnost - Ili sve zadae u transakciji trebaju biti napravljene ili nijedna. Transakcija
mora biti dovrena ili se mora ponititi (vratiti natrag).
Dosljednost - Svaka transakcija mora sauvati integritetnu prinudnost -- izriita
pravila dosljednosti -- baze podataka. Ona ne moe smjestiti podatke u
kontradiktornom poloaju.

Izolacija - Dvije simultane transakcije ne mogu interferirati, tj. kriati se.

Meurezultati unutar transakcije nisu vidljivi drugim transakcijama.

Postojanost - Dovrene transakcije se ne mogu kasnije prekinuti ili da se njihovi

rezultati odbace. One se moraju nastaviti kroz (na primjer) ponovo pokretanje SUBP-a
nakon njegova kraha.

U praksi mnogi SUBP-ovi doputaju veini ovih pravila da se selektivno ublae radi bolje
performanse.

Kontrola podudarnosti je naziv za metodu koritenu radi osiguravanja da se transakcije

izvravaju na siguran nain i da slijede ACIP pravila. SUBP mora osigurati da su doputeni
serijabilni, nadoknadni rasporedi, te da nijedna radnja poinjenih transakcija nije izgubljena
prilikom ponitenja prekinutih transakcija.
Veliki dio internog inenjerstva SUBP-a, ipak je neovisan o modelu podataka, te je zaokupljen
upravljanjem faktorima poput performansi, podudarnosti, integriteta i obnove nakon
hardverskih propusta. U ovim podrujima postoje velike razlike meu proizvodima.

2. RAZVOJ BAZE PODATAKA KROZ POVIJEST

Najranija poznata upotreba termina baza podataka potjee iz lipnja 1963. kada je Drutvo za
razvoj sustava uzelo pod pokroviteljstvo simpozij pod naslovom Razvoj i upravljanje
raunalno centriranom bazom podataka. Baza podataka (eng. ) kao jedinstvena rije postala
je uobiajena u Europi u ranim 1970-ima, a krajem desetljea koristila se u glavnim
amerikim novinama. (Banka podataka, usporedni termin, koristio se vrlo rano u novinama
Washington Post, 1966.)
Prvi sustavi upravljanja bazom podataka razvijeni su u 1960-ima. Zaetnik u tom polju bio je
Charles Bachman. Bachmanovi rani radovi pokazuju da je njegov cilj bio stvaranje
djelotvornije upotrebe novih ureaja s izravnim pristupom pohrane koji su postali dostupni:
do tada se obrada podataka temeljila na buenim karticama i magnetskoj vrpci, pa je tako
serijska obrada bila dominantna aktivnost. Dva su se kljuna modela podataka pojavila u to
vrijeme: CODASYL je razvio mreni model baziran na Bachmanovim idejama, te se
(oigledno neovisno) hijerarhijski model koristio u sustavu koji je razvio North American
Rockwell, a kojeg je kasnije prihvatio IBM kao kamen temeljac svojeg SUI proizvoda.
Odnosni model je predloio E. F. Codd 1970. godine. On je kritizirao postojee modele zbog
zbrke apstraktnih opisa informacijskih struktura s opisima mehanizama fizikalnog pristupa.
Ipak je dugo vremena odnosni model ostao samo u podruju akademskog interesa. Dok su
CODASYL sustavi i SUI bili zamiljeni kao rjeenja praktinog inenjerstva, uzimajui u
obzir tehnologiju koja je postojala u ono vrijeme, odnosni model je zauzeo mnogo veu
teoretsku perspektivu, smatrajui (ispravno) da e hardverska i softverska tehnologija uhvatiti
korak s vremenom. Meu prvim provedbama bili su Stonebrakerov Ingres na Berkeleyju, te
projekt Sustav R u IBM-u. Oba navedena su bili istraivaki prototipovi objavljeni tijekom
1976. Prvi komercijalni proizvodi, Oracle i DB2, nisu se pojavili sve do oko 1980.
Tijekom 1980-ih istraivaka aktivnost se usredotoila na sustave distributivnih baza
podataka i na strojeve baza podataka meutim taj je napredak imao malen uinak na trite.
Druga vana teoretska zamisao bio je funkcionalni model podataka, ali bez obzira na neke
specijalizirane primjene u genetici, molekularnoj biologiji i istraivanju prijevara, svijet nije
na njega obratio veliku panju.
U 1990-im panja se prebacila na baze podataka orijentirane prema objektu.
To je poluilo nekakav uspjeh u poljima gdje je bilo potrebno rukovati kompleksnijim
podacima nego to bi se mogli udobno nositi odnosni sustavi: prostorne baze podataka,
inenjerski podaci (ukljuujui odlagalita softverskog inenjerstva), multimedijski podaci.

Neke od tih ideja prihvatili su odnosni prodavai, koji su kao posljedicu integrirali nove
osobine u svoje proizvode; neovisni prodavai predmetnih baza podataka uvelike su nestali sa
scene.
U 2000-im pomodno podruje za inovacije postale su XML baze podataka. To je izbacilo, kao
s predmetnim bazama podataka, novu zbirku pokrenutih drutava, ali su se istovremeno
kljune ideje integrirale u uspostavljene odnosne proizvode.
XML baze podataka ciljaju ukloniti tradicionalnu podjelu izmeu dokumenata i podataka,
doputajui svim organizacijskim informacijskim resursima da se dre na jednom mjestu bez
obzira da li su visoko strukturirani ili ne.

Baza podataka, DBMS, model podataka

Baza podataka je skup meusobno povezanih podataka, pohranjenih u vanjskoj memoriji
raunala.
Podaci su istovremeno dostupni raznim korisnicima i aplikacijskim programima. Ubacivanje,
promjena, brisanje i itanje podataka obavlja se posredstvom zajednikog softvera. Korisnici
i aplikacije pritom ne moraju poznavati detalje fizikog prikaza podataka, vec se
referenciraju na logiku strukturu baze.
Sustav za upravljanje bazom podataka (Data Base Management System - DBMS) je
posluitelj (server) baze podataka. On oblikuje fiziki prikaz baze u skladu s traenom
logikom strukturom. Takoer, on obavlja u ime klijenata sve operacije s podacima. Dalje, on
je u stanju podrati razne baze, od kojih svaka moe imati svoju logiku strukturu, no u
skladu s istim modelom. Isto tako, brine se za sigurnost podataka, te automatizira
administrativne poslove s bazom.
Podaci u bazi su logiki organizirani u skladu s nekim modelom podataka. Model podataka je
skup pravila koja odreuju kako moe izgledati logika struktura baze. Model ini osnovu za
koncipiranje, projektiranje i implementiranje baze.

10

Dosadanji DBMS-i obino su podravali neki od sljedeih modela:

Relacijski model. Zasnovan na matematikom pojmu relacije.
medu podacima prikazuju se pravokutnim tabelama.

I podaci i veze

Mreni model. Baza je predoena usmjerenim grafom. vorovi su tipovi zapisa, a

lukovi definiraju veze medu tipovima zapisa.
Hijerarhijski model. Specijalni sluaj mrenog. Baza je predoena jednim stablom ili
skupom stabala. vorovi su tipovi zapisa, a hijerarhijski odnos nadreeni-podreeni
izraava veze meu 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 rukovanje s tim podacima. Svaki objekt pripada nekoj klasi. Izmeu
klasa se uspostavljaju veze nasljeivanja, agregacije, odnosno meusobnog koritenja
operacija.
Hijerarhijski i mreni model bili su u upotrebi u 60-tim i 70-tim godinama 20. stoljea. Od
80-tih godina pa sve do dananjih dana prevladava relacijski model. Oekivani prijelaz na
objektni model za sada se nije desio, tako da dananje baze podataka uglavnom jo uvijek
moemo poistovjetiti s relacijskim bazama.
Ciljevi koji se nastoje postii koritenjem baza podataka
Spomenuli smo da baze podataka predstavljaju visu razinu rada s podacima u odnosu na
klasine programske jezike. Ta via razina rada oituje se u tome to tehnologija baza
podataka nastoji (i u velikoj mjeri uspijeva) ispuniti sljedee ciljeve.
Fizika nezavisnost podataka. Razdvaja se logika definicija baze od njene stvarne
fizike grade. Znai, ako se fizika grada promijeni (na primjer, podaci se prepiu u druge
datoteke na drugim diskovima), to nece zahtijevati promjene u postojeim aplikacijama.
Logika nezavisnost podataka. Razdvaja se globalna logika definicija cijele baze
podataka od lokalne logike definicije za jednu aplikaciju. Znai, ako se logika
definicija promijeni (na primjer uvede se novi zapis ili veza), to nee zahtijevati promjene
u postojeim aplikacijama. Lokalna logika definicija obino se svodi na izdvajanje samo
nekih elemenata iz globalne definicije, uz neke jednostavne transformacije tih elemenata.
Fleksibilnost pristupa podacima. U starijim mrenim i hijerarhijskim bazama, staze
pristupanja podacima bile su unaprijed definirane, dakle korisnik je mogao pretraivati
podatke jedino onim redoslijedom koji je bio predvien u vrijeme projektiranja i
implementiranja baze.
Danas se zahtijeva da korisnik moe slobodno prebirati po
podacima, te po svom nahoenju uspostavljati veze medu podacima. Ovom zahtjevu
zaista zadovoljavaju jedino relacijske baze.
Istovremeni pristup do podataka. Baza mora omoguiti da vei 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.

11

 uvanje integriteta. Nastoji se automatski sauvati korektnost i konzistencija

podataka, i to u situaciji kad postoje greke u aplikacijama, te konfliktne istrovremene
aktivnosti korisnika.
Mogunost oporavka nakon kvara. Mora postojati pouzdana zatita baze u sluaju
kvara hardvera ili greaka u radu sistemskog softvera.
Zatita od neovlatenog koritenja. Mora postojati mogunost da se korisnicima
ogranice prava koritenja baze, dakle da se svakom korisniku reguliraju ovlatenja sto on
smije a to ne smije raditi s podacima.
Zadovoljavajua brzina pristupa. Operacije s podacima moraju se odvijati dovoljno
brzo, u skladu s potrebama odreene aplikacije. Na brzinu pristupa moe se utjecati
odabirom pogodnih fizikih struktura podataka, te izborom pogodnih algoritama za
pretraivanje.
Mogunost podeavanja i kontrole. Velika baza zahtijeva stalnu brigu: praenje
performansi, mijenjanje parametara u fizikoj gradi, rutinsko pohranjivanje rezervnih
kopija podataka, reguliranje ovlatenja korisnika. Takoer, svrha baze se vremenom
mijenja, pa povremeno treba podesiti i logiku strukturu. Ovakvi poslovi moraju se
obavljati centralizirano.
Odgovorna osoba zove se administrator baze podataka.
Administratoru trebaju stajati na raspolaganju razni alati i pomagala.
Arhitektura baze podataka
Arhitektura baze podataka sastoji se od tri sloja i suelja medu slojevima, kao to je
prikazano na Slici 1.1.
Rije je o tri razine apstrakcije:
Fizika razina odnosi se na fiziki prikaz i raspored podataka na jedinicama vanjske
memorije. To je aspekt kojeg vide samo sistemski programeri (oni koji su razvili DBMS).
Sama fizika razina moe se dalje podijeliti na vie pod razina apstrakcije, od sasvim
konkretnih staza i cilindara na disku, do ve donekle apstraktnih pojmova datoteke i
zapisa kakve susreemo u klasinim programskim jezicima. Raspored pohranjivanja
opisuje kako se elementi logike definicije baze preslikavaju na fizike ureaje.
Globalna logika razina odnosi se na logiku strukturu cijele baze. To je aspekt kojeg
vidi projektant baze odnosno njen administrator. Zapis logike definicije naziva se shema
(engleski takoer schema). Shema je tekst ili dijagram koji definira logiku strukturu
baze, i u skladu je sa zadanim
Lokalna logika razina odnosi se na logiku predodbu o dijelu baze kojeg koristi
pojedina aplikacija. To je aspekt kojeg vidi korisnik ili aplikacijski programer. Zapis
jedne lokalne logike definicije zove se pogled (engleski view) ili pod-shema. To je tekst
ili dijagram kojim se imenuju i definiraju svi lokalni tipovi podataka i veze medu tim
tipovima, opet u skladu s pravilima koritenog modela.
Takoer, pogled zadaje preslikavanje kojim se iz globalnih podataka i veza izvode lokalni.

12

Aplikacijski
program 1

Aplikacijski
program 2

Aplikacijski
program 3

Lokalna
logika

Pogled 1

Pogled 2

Pogled 3

razina

Shema
Globalna
logika

Raspored
programiranja

razina
Fizika

Datoteke

Datoteke

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 fiziku bazu. Administrator moe samo donekle
utjecati na fiziku gradu baze, podeavanjem njemu dostupnih parametara. Programi i
korisnici ne pristupaju izravno fizikoj bazi, ve dobivaju ili pohranjuju podatke posredstvom
DBMS-a. Komunikacija programa odnosno korisnika s DBMS-om obavlja se na lokalnoj
logikoj razini.

13

Jezici za rad s bazama podataka

Komunikacija korisnika odnosno aplikacijskog programa i DBMS-a odvija se pomou
posebnih jezika.
Ti jezici tradicionalno se dijele na sljedee kategorije.
Jezik za opis podataka (Data Description Language - DDL). Slui projektantu baze ili
administratoru u svrhu zapisivanja sheme ili pogleda. Dakle tim jezikom definiramo
podatke i veze medu podacima, i to na logikoj razini. Koji puta postoji posebna varijanta
jezika za shemu, a posebna za poglede. Naredbe DDL obino podsijeaju na naredbe za
definiranje sloenih tipova podataka u jezicima poput COBOL, PL/I, C, Pascal.
Jezik za manipuliranje podacima (Data Manipulation Language - DML). Slui
programeru za uspostavljanje veze izmeu aplikacijskog programa i baze. Naredbe DML
omoguuju manevriranje po bazi, te jednostavne operacije kao sto su upis, promjena,
brisanje ili itanje 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 pie program u kojem su izmijeane naredbe
dvaju jezika, pa takav program treba prevoditi s dva prevodioca (DML-precompiler,
obini compiler).
Jezik za postavljanje upita (Query Language - QL). Slui neposrednom korisniku za
interaktivno pretraivanje baze. To je jezik koji podsjea na govorni (engleski) jezik
Naredbe su ne proceduralne, dakle takve da samo specificiraju rezultat kojeg elimo
dobiti, a ne i postupak za dobivanje rezultata. 3Access je baza podataka koja koristi tekst,
brojke, logike, datumske i memo podatke.
Ovakva podjela na tri jezika danas je ve prilino 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 slui za definiranje podataka,
manipuliranje i pretraivanje. Integrirani jezik se moe koristiti interaktivno (preko on-line
interpretera) ili se on moe pojavljivati uklopljen u aplikacijske programe.
Naglasimo da gore spomenute vrste jezika nisu programski jezici. Dakle ti jezici su nam
nuni da bi se povezali s bazom, no oni nam nisu dovoljni za razvoj aplikacija koje ce nesto
raditi s podacima iz baze.
Tradicionalni nain razvoja aplikacija koje rade s bazom je koritenje klasinih programskih
jezika (COBOL, PL/I, C, Pascal . . . ) s ugnijedenim DML-naredbama.

U 80-tim godinama 20. stoljea bili su dosta popularni i tzv. jezici 4. generacije (4-th
Generation Languages - 4GL): rije je o jezicima koji su bili namijenjeni iskljuivo za rad s
3

Marina iin ajin, Slavomir Vukmirovi, Zvonko apko, 2006., str. 31

14

bazama, te su zato u tom kontekstu bili produktivniji od klasinih programskih jezika ope
namjene.
Problem s jezicima 4. generacije je bio u njihovoj nestandardnosti: svaki od njih je u pravilu
bio dio nekog odreenog softverskog paketa za baze podataka, te se nije mogao koristiti izvan
tog paketa (baze).
U dananje vrijeme, aplikacije se najee razvijaju u standardnim objektno orijentiranim
programskim jezicima (Java, C++, . . . ).
Za interakcije s bazom koriste se unaprijed pripremljene klase objekata. Ovakva tehnika je
dovoljno produktivna zbog koritenja gotovih klasa, a rezultirajui program se lako dotjeruje,
uklapa u vee sustave ili prenosi s jedne baze na drugu.
Poznati softverski paketi za rad s bazama podataka
Baze podataka se u pravilu realiziraju koristenjem nekog od provjerenih softverskih paketa.
Tabelarni prikaz 1.1 daje pregled softvera koji u ovom trenutku predstavljaju tehnoloki vrh
te imaju znaajan udjel na svjetskom tritu.
Gotovo svi dananji softverski paketi podravaju relacijski model i SQL. Svaki od njih sadri
svoj DBMS, uobiajene klijente (na primjer interaktivni interpreter SQL), te biblioteke i alate
za razvoj aplikacija. Svaki paket isporuuje se u verzijama za razne raunalne platforme
(operacijske sustave).
Konkurencija medu proizvodacima softvera za baze podataka je izuzetno velika, tako da je
posljednjih godina cesto dolazilo do njihovog nestanka, spajanja ili preuzimanja. Lista
relevantnih softverskih paketa zato je svake godine sve kraa. Jedino osvjeenje predstavlja
nedavna pojava public-domain sotvera poput MySQL.
ivotni ciklus baze podataka
Uvoenje baze podataka u neko poduzee ili ustanovu predstavlja sloeni zadatak koji
zahtijeva timski rad strunjaka raznih profila.
To je projekt koji se moe podijeliti u pet faza:
analiza potreba,
modeliranje podataka,
implementacija,
testiranje i
odravanje.

Analiza potreba
15

Prouavaju se tokovi informacija u poduzeu. Uoavaju se podaci koje treba pohranjivati i

veze medu njima. U velikom poduzeima, gdje postoje razne grupe korisnika, pojavit e 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 takoer treba obuhvatiti analizu transakcija (operacija) koje e se obavljati
nad bazom podataka, budui da to moe isto imati utjecaja na sadraj i konani oblik baze.
Vano 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.
Modeliranje podataka
Razliiti pogledi na podatke, otkriveni u fazi analize, sintetiziraju se u jednu cjelinu - globalnu
shemu. Precizno se utvruju tipovi podataka. Shema se dalje dotjeruje (normalizira) tako da
zadovolji neke zahtjeve kvalitete. Takoer, shema se prilagoava ogranienjima 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).
Implementacija
Na osnovu sheme i pod-shema, te uz pomo dostupnog DBMS-a, fiziki se realizira baza
podataka na raunalu. U DBMS-u obino postoje parametri kojima se moe utjecati na
fiziku organizaciju baze. Parametri se podeavaju tako da se osigura efikasan rad najvanijih
transakcija. Razvija se skup programa koji realiziraju pojedine transakcije te pokrivaju
potrebe raznih aplikacija. Baza se inicijalno puni podacima.
Testiranje
Korisnici pokusno rade s bazom i provjeravaju da li ona zadovoljava svim zahtjevima.
Nastoje se otkriti greke koje su se mogle potkrasti u svakoj od faza razvoja: dakle u analizi
potreba, modeliranju podataka, implementaciji. Greke u ranijim fazama imaju tee
posljedice. Na primjer, greka u analizi potreba uzrokuje da transakcije moda korektno rade,
no ne ono to korisnicima treba ve neto drugo. Dobro bi bilo kad bi takve propuste otkrili
prije implementacije. Zato se u novije vrijeme, prije prave implementacije, razvijaju i
priblini prototipovi baze podataka, te se oni pokazuju korisnicima. Jeftinu izradu prototipova
omoguuju jezici 4. generacije i objektno-orijentirani jezici.
Odravanje
Odvija se u vrijeme kad je baza ve ula u redovnu upotrebu. Sastoji se od sljedeeg:
popravak greaka koje nisu bile otkrivene u fazi testiranja; uvoenje promjena zbog novih
zahtjeva korisnika; podeavanje parametara u DBMS u svrhu poboljavanja performansi.
Odravanje zahtijeva da se stalno prati rad s bazom, i to tako da to praenje ne ometa
korisnike. Administratoru baze podataka trebaju stajati na raspolaganju odgovarajui alati
(utility programi).

16

3. MODELIRANJE PODATAKA
Modeliranje entiteta i veza
Bavimo se pitanjem: kako oblikovati shemu za bazu podataka, usklaenu s pravilima
relacijskog modela. U stvarnim situacijama dosta je teko direktno pogoditi relacijsku shemu.
Zato se sluimo jednom pomonom fazom koja se zove modeliranje entiteta i veza (EntityRelationship Modelling). Rije je o oblikovanju jedne manje precizne, konceptualne sheme,
koja predstavlja apstrakciju realnog svijeta.
Ta tzv. ER-shema se dalje, vie-manje automatski, pretvara u relacijsku. Modeliranje entiteta
i veza zahtijeva da se svijet promatra preko tri kategorije:

entiteti: objekti ili dogaaji koji su nam od interesa;

veze: odnosi medu entitetima koji su nam od interesa;
atributi: svojstva entiteta i veza koja su nam od interesa.
Entiteti i atributi
Entitet je neto o emu elimo spremati podatke, neto to je u stanju postojati ili ne postojati,
te se moe identificirati. Entitet moe biti objekt ili bie (na primjer kua, student, auto),
odnosno dogaaj ili pojava (na primjer nogometna utakmica, praznik, servisiranje auta).
Entitet je opisan atributima (na primjer atributi kue 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 moe istovremeno imati
vie vrijednosti (na primjer kvar koji je popravljen pri servisiranju auta).
Ime entiteta, zajedno sa pripadnim atributima, zapravo odreuje tip entiteta. Moe postojati
mnogo primjeraka (pojava) entiteta zadanog tipa (na primjer STUDENT je tip iji primjerci
su Petri Petar, Markovi Marko, . . . ).
Kandidat za klju je atribut, ili skup atributa, ije vrijednosti jednoznano odreuju primjerak
entiteta zadanog tipa. Dakle, ne mogu postojati dva razliita primjerka entiteta istog tipa s
istim vrijednostima kandidata za klju. (Na primjer za tip entiteta AUTO, kandidat za klju je
atribut REG BROJ ). Ukoliko jedan tip entiteta ima vise kandidata za klju, tada biramo
jednog od njih i proglaavamo ga primarnim kljuem. (Na primjer primarni klju za tip
entiteta STUDENT mogao bi biti atribut BROJ INDEKSA.
Veze
Veze se uspostavljaju izmeu dva ili vise tipova entiteta (na primjer veza IGRA ZA izmeu
tipova entiteta IGRA i TIM ). Zapravo je rijec o imenovanoj binarnoj ili k-arnoj relaciji
izmeu primjeraka entiteta zadanih tipova. Za sada emo se ograniiti na veze izmeu tono
dva tipa entiteta.

17

Funkcionalnost veze moe biti:

Jedan-naprama-jedan (1 : 1). Jedan primjerak prvog tipa entiteta moe biti u vezi s
najvie jednim primjerkom drugog tipa entiteta, te takoer jedan primjerak drugog tipa
moe biti u vezi s najvie jednim primjerkom prvog tipa. Na primjer veza JE
PRO_ELNIK izmeu tipova entiteta NASTAVNIK i ZAVOD (na fakultetu).
Jedan-naprama-mnogo (1 : N). Jedan primjerak prvog tipa entiteta moe biti u vezi s 0,
1 ili vie primjeraka drugog tipa entiteta, no jedan primjerak drugog tipa moe biti u vezi s
najvie jednim primjerkom prvog tipa. Na primjer veza PREDAJE izmeu tipova entiteta
NASTAVNIK i KOLEGIJ .
Mnogo-naprama-mnogo (N : N). Jedan primjerak prvog tipa entiteta moe biti u vezi s
0, 1 ili vie primjeraka drugog tipa entiteta, te takoer jedan primjerak drugog tipa moe
biti u vezi s 0, 1 ili vie primjeraka prvog tipa. Na primjer veza UPISAO izmeu tipova
entiteta STUDENT i KOLEGIJ .
Veza moe imati i svoje atribute koje ne moemo pripisati ni jednom od tipova entiteta (na
primjer veza UPISAO moe imati atribut DATUM UPISA). Ako svaki primjerak entiteta
nekog tipa mora sudjelovati u zadanoj vezi, tada kaemo da tip entiteta ima obavezno lanstvo
u toj vezi. Inae tip entiteta ima neobavezno lanstvo. (Na primjer izmeu tipova entiteta
ISPIT i KOLEGIJ zadana je veza IZ , koja ima funkcionalnost (N : 1). ISPIT ima
obavezno lanstvo u vezi IZ , jer svaki ispit mora biti iz nekog kolegija.) Odluka da li je
lanstvo obavezno ili neobavezno koji put je stvar dogovora odnosno projektantove odluke
(na primjer lanstvo za KOLEGIJ u vezi PREDAJE).

18

Prikaz ER-sheme pomou dijagrama

Obiaj je da se ER-shema nacrta kao dijagram u kojem pravokutnici predstavljaju tipove
entiteta, a rombovi veze. Veze su povezane bridovima s odgovarajuim tipovima entiteta.
Imena tipova entiteta i veza, te funkcionalnost veza, uneseni su u dijagram. Posebno se
prilae lista atributa za svaki entitet odnosno vezu. U toj listi moemo specificirati obaveznost
lanstva u vezama.
ZAVOD

1
JE_P
RO
ELNI
K

NU
DI

N
N

KOLEGI
J

PRE
DAJE

JE_
U

NASTAVNIK

N
UPIS
AO

N
STUDENT

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, . .
4. NASTAVNIK , s atributima IME NASTAVNIKA (pretpostavljamo da je
jedinstveno), BR SOBE,. . .
19

Podvueni atributi ine primarni klju. Veze su:

1. JE PRO CELNIK , bez atributa. ZAVOD ima obavezno lanstvo.
2. JE U , bez atributa. NASTAVNIK ima obavezno lanstvo.
3. NUDI , bez atributa. KOLEGIJ ima obavezno lanstvo.
4. UPISAO, s atributom DATUM UPISA.
5. PREDAJE, bez atributa. KOLEGIJ ima na primjer obavezno lanstvo.

Sloenije veze
U stvarnim situacijama pojavljuju se i sloenije veze od onih koje smo do sada
promatrali. Navest emo neke od njih. Involuirana veza povezuje jedan tip entiteta s tim istim
tipom. Dakle rije je o binarnoj relaciji izmeu raznih primjeraka entiteta istog tipa.
Funkcionalnost takve veze opet moe biti (1 : 1), (1 : N), odnosno (N : N).

Slika 2.2: Primjeri za involuirane veze

Slika 2.2 sadri primjere za involuirane veze s razliitim funkcionalnostima. Prvi dijagram na
Slici 2.2 napravljen je pod pretpostavkom da su proli brakovi osobe zaboravljeni, a
poligamija zabranjena. lanstvo u vezi U BRAKU S je neobavezno.
Drugi dijagram na Slici 2.2 ima ucrtanu strelicu koja pokazuje smjer tumaenja veze JE_EF
ZA. Moemo uzeti da je lanstvo u toj vezi neobavezno, jer postoji barem jedan suradnik koji
nema efa. Trei dijagram na Slici 2.2 odnosi se na dijelove proizvoda koji se proizvode u
nekoj tvornici. Pritom jedan sloeniji dio sadri vie jednostavnijih. Isti jednostavniji dio
pojavljuje se u vie sloenih. Pod-tipovi. Tip entiteta E 1 je podtip tipa entiteta E 2 ako je
svaki primjerak od E 1 takoer i primjerak od E 2 .

20

E 1 nasljeduje sve atribute od E 2 , no E 1 moe imati i dodatne atribute. Situaciju opisujemo

pomou specijalne (1 : 1) veze JE (engleski IS A koja se moe pojaviti vie puta unutar ERsheme.
Slika 2.3 sadri primjer ER-sheme s pod-tipovima i nad-tipovima. Rije je o tipovima entiteta
za osobe koje se pojavljuju na fakultetu. NASTAVNIK ukljuuje profesore, docente i
asistente.

Slika 2.3: Primjer ER-sheme s pod-tipovima entiteta

Slika 2.4: Primjer ternarne veze

21

Ternarne veze uspostavljaju se izmeu tri tipa entiteta. Znai rije je o ternarnoj relaciji
izmeu primjeraka triju tipova entiteta. Postoje brojne mogunosti za funkcionalnost ternarne
veze, na primjer (N : N : P ), (1 : N : N), (1 : 1 : N) ili ak (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 mnogonaprama mnogo-naprama-mnogo, dakle (N : N : 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 moe 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 moe se
zamijeniti s dvije binarne, u skladu s dijagramom na Slici 2.5.
ER model dovoljno je jednostavan da ga ljudi razliitih struka mogu razumjeti. Zato ER
shema slui za komunikaciju projektanta baze podataka i korisnika, i to u najranijoj fazi
razvoja baze. Postojei DBMS ne mogu direktno implementirati ER shemu, ve zahtijevaju
da se ona detaljnije razradi, te modificira u skladu s pravilima relacijskog, mrenog, odnosno
hijerarhijskog modela.

Slika 2.5: Rastavljanje ternarne veze na dvije binarne

Relacijski model
Relacijski model bio je teoretski zasnovan jo krajem 60-tih godina 20. stoljea, u radovima
E.F. Codd-a. Model se dugo pojavljivao samo u akademskim raspravama i knjigama. Prve
realizacije na raunalu bile su suvie spore i neefikasne. Zahvaljujui intenzivnom
istraivanju, te napretku samih raunala, efikasnost relacijskih baza postepeno se
poboljavala. Sredinom 80-tih godina 20. stoljea relacijski model je postao prevladavajui. I
danas vecina DBMS koristi taj model.

22

Relacija, atribut, n-torka, klju

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 obino sadri vrijednost jednog atributa (za entitet ili vezu) - zato stupac
poistovjeujemo 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).
4

Jedan redak relacije obino predstavlja jedan primjerak entiteta, ili biljei vezu izmeu dva ili
vie primjeraka. Redak nazivamo n-torka. U jednoj relaciji ne smiju postojati dvije jednake ntorke. 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 , MODEL, GODINA. Relacija sadri podatke o automobilima koji se
nalaze na popravku u nekoj radionici.

Tabelarni prikaz 2.1: Relacija s podacima o automobilima.

Usporedba relacijskog modela s mrenim i hijerarhijskim
Mreni i hijerarhijski model su prilino slini. Ustvari, hijerarhijski model moemo smatrati
specijalnom vrstom mrenog. S druge strane, relacijski model se po svom pristupu bitno
razlikuje od ostala dva. Osnovna razlika je u nacinu prikazivanja veza medu entitetima, te
nacinu koritenja tih veza.
U mrenom ili hijerarhijskom modelu moguce je izravno prikazati vezu. Dodue, postoje
ogranienja na funkcionalnost veze, te na konfiguraciju svih veza u shemi. Veza se
materijalizira pomou pointera, tj. u jednom zapisu pie adresa drugog (vezanog) zapisa.
Mreni odnosno hijerarhijski DML omoguuje samo jednostavne operacije s jednim zapisom
(upis, promjena, brisanje, itanje), te manevriranje kroz shemu putem veza (dohvat prvog
zapisa, koji je u zadanoj vezi sa zadanim zapisom, dohvat idueg zapisa, . . . ). Ovakav
pristup ima svoje prednosti i mane. Prednost je da je rad s bazom u tehnikom pogledu brz i
4

Varga M., Baze podataka, Zagreb 1994.; str. 47

23

efikasan. Mana je da korisnik moe upotrijebiti samo one veze koje su predviene shemom pa
su u skladu s time i materijalizirane.
U relacijskom modelu veze su samo implicitno naznaene time to se isti ili slian atribut
pojavljuje u vie relacija. Veza nije materijalizirana, ve se dinamiki uspostavlja za vrijeme
rada s podacima, usporedbom vrijednosti atributa u n-torkama raznih relacija. Relacijski
DML, osim jednostavnih operacija s jednom relacijom, mora omoguiti 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 pretraivanje podataka, a to trosi
vrijeme. Prednost je da korisnik moe uspostaviti i one veze koje nisu bile predviene u fazi
modeliranja podataka. tovie, kao kriterij za povezivanje, osim jednakosti za vrijednost
atributa, mogu posluiti i razni drugi (sloeniji) kriteriji. To jo vie poveava fleksibilnost
koritenja baze. Iz upravo reenog vidi se da je u relacijskom modelu teite baeno na
dinamiki aspekt (manje pohranjivanja a vie manipuliranja). Zato upotrebljivost relacijskog
DBMS bitno ovisi o izraajnim mogunostima njegovog jezika za rad s podacima. Poeljno
je takoer da taj jezik bude u to veoj mjeri ne proceduralan i razumljiv neposrednim
korisnicima.

24

4. LITERATURA
1.eri V., Varga, M., Informacijska tehnologija u poslovanju, Element, Zagreb 2004.
2. iin ajin M., Vukmirovi S., apko Z., EFRI, Rijeka, 2006.
3. avel, S., Access, Adami, Rijeka 2004.
4.Varga, M., Baze podataka; Konceptualno i logiko i fiziko modeliranje podataka, DRIP,
Zagreb 1994,

25