SVEUČILIŠTE U ZAGREBU

FAKULTET ORGANIZACIJE I INFORMATIKE

VARAŽ D I N

Petar Perić

MODELI PODATAKA

ZAVRŠNI RAD

Varaždin, 2008.

SVEUČILIŠTE U ZAGREBU
FAKULTET ORGANIZACIJE I INFORMATIKE
VARAŽ D I N

Petar Perić
Redoviti student
Broj indeksa: 9324/2005.
Smjer: Informacijski sustavi
Preddiplomski studij

MODELI PODATAKA

ZAVRŠNI RAD

Mentor:
Dr. sc. Mato Matijević, redoviti profesor

Varaždin, lipanj 2008.

Tablica sadržaja
1. Uvod.................................................................................................................................................3
2. Općenito o modelima podataka........................................................................................................3
2.1. Opća definicija i svrha..............................................................................................................3
2.2. Različite instance modela podataka..........................................................................................4
2.3. Tipovi modela podataka............................................................................................................4
3. Model baze podataka – relacijski model..........................................................................................6
3.1. Uvod u relacijski model............................................................................................................6
3.2. Primjerci ili n-torke relacija......................................................................................................8
4. Ograničenja.......................................................................................................................................9
4.1 Opća ograničenja.......................................................................................................................9
4.2. Specifična ograničenja..............................................................................................................9
5. Uvod u relacijsku algrebru.............................................................................................................10
6. Zaključak........................................................................................................................................12

I
1. Uvod

Modeli podataka predstavljaju organizaciju baza podataka, tj njezin temelj. Baza podataka
se gradi na određenom modelu podataka, večina baza se „izrađuje“ oko jednog modela podataka, no
sve više na popularnosti je da proizvodi nude podršku za više modela podataka.
Za lakše shvaćanje cjelokupnog sadržaja ovog seminarskog rada, moramo prvo spomenuti
što je to zapravo model. S ovim pojmom se često susrećemo u životu, a posebice na fakultetu.
Mogli bi reći da je model „sredstvo“, tj. neki način na koji čovjek pojednostavljuje određeni
problem. No, najčešće promatranje toga problema se bazira samo s gledišta koja su bitna za ciljeve
kako bi postavili željenu analizu problema.
Možemo uzeti za primjer knjižnicu, znači knjiga kao stvar ima mnoga obilježja koja ju
određuju, no kada ju knjižničar promatra kao model, njemu je u tom trenutku bitan samo naslov (ili
autor) te inventarni broj. No, ta knjiga ima brojna druga obilježja, kao što su: format, broj stranica,
boja knjige i dr., ali u tom trenutku knjižničaru to nije bitno.

Također trebamo reći i što je to baza

podataka. Najjednostavnije rečeno, baza podataka je
strukturirana zbirka podataka. Baza podataka
tako može biti i neelektronska, no mi ćemo
se ipak više usmjeriti na elektronske baze podataka
te ćemo tako reći da je baza podataka strukturirana
zbirka zapisa ili podataka pohranjenih u računalnom
Slika 1. Koala
sustavu.
Sada kad smo rekli što je model, što je baza podataka, možemo i točnije definirati što je
zapravo model podataka u ovom seminarskom radu. Model podataka je struktura ili oblik baze
podataka, opisan u formalnom jeziku te podržan od strane DBMS-a (Database Management
System). DBMS ili prevedeno sustav za upravljanje bazama podataka, omogućuje da baza podataka
bude dostupna svim korisnicima. Svakako treba istaknuti i to da model podataka nije samo način na
koji se strukturiraju neki podaci, nego se njime i određuju operacije koje mogu biti izvedene nad
tim podacima.

1
2. Općenito o modelima podataka

2.1. Opća definicija i svrha

Ako ćemo promatrati modele podatka iz perspektive softverskog inžinjerstva možemo reći kako je
to model koji opisuje način na koji su podaci predstavljeni te na koji način se njima pristupa. Dakle,
pomoću modela podataka ćemo formalno definirati elemente podataka i veze između tih elemenata
za neko područje interesa. Osim same definicije strukture, pristupa i predođbe modeli podataka nam
sami po sebi određuju značenje nekog podatka. Takve podatke, koji imaju određeno značenje
nazivamo strukturiranim podacima. Kako bismo pojam struktuiranih podataka stavili u perspektivu
možemo pogledati njihove pandane: nestruktuirane podatke, čije predstavnike vidimo u podacima
poput slika, ili tekstualnim datotekama koje sadrže govorni jezik. Za takve podatke kažemo da su
nestruktuirani jer sami po sebi ne nose informaciju, osim ako ih prije ne protumačimo.
Modali podataka imaju brojne primjene u bazama podataka,
programskim jezicima (gdje ih nazivamo strukturama
podataka), zatim izradi informacijskih sustava te
poslovanju, gdje ih najčešće prate i funkcijski modeli koji
određuju gdje i za koju funkciju su potrebni podaci i
slično. No, model podataka primjenjujemo na mnogo više
od navedenoga. Sama uloga modela podataka je pružanje
nekog sustava standardizacije i Slika 2. Pustinja formatiranja podataka. Ako je
ovaj model poštovan kroz cijeli sustav ( bio to poslovni IS, baza podataka ili pak obična knjižnica )
podaci će sačuvati jedinstveni oblik, biti će im lako pristupiti a eventualno će i različite aplikacije
moći dijeliti te podaktke.

2.2. Različite instance modela podataka

Sudeći po Američkom nacionalnom institutu za standardizaciju modeli podataka se mogu

manifestirati u tri oblika (ANSI 1975):
Poanta ovakvog pristupa, sudeći po ANSU-u je relativna neovisnost svake instance. To jest, same tri
šeme nemaju neku međuovisnost, već će logička shema moći zadržati svoj izgled ako mijenjamo
fizički sloj te će konceptualna ostati ista ako odlučimo promijeniti logički i fizički.

2
2.3. Tipovi modela podataka

Između različitih vrsta modela podataka razlikujemo

1. Model baze podataka – teorijski opis ili specifikacija strukture te načina uporabe baze
podataka. Tijekom kasnijeg proučavanja ćemo se i fokusirati na ovaj tip modela podataka.
Za sada je dovoljno načiniti osnovnu distinkciju različitih modela baza podataka. Od
navedenih poznajemo:
a. Tablični model – Strogo gledano se ne kvalificira kao model baza podataka jer se tabele
sastoje od pojedinih, dvodimenzionalnih polja za koje je samo izvršena pretpostavka da
se u poljima jednog sloga nalaze podaci koji pripadaju istom entitetu a u stupcima
podaci istog tipa podataka
b. hijerarhijski model – predstavlja model podataka u obliku stabla gdje svaki podataka
slijedi iz nekog nadređenog. Na primjer, podaci o djeci bi bili podređeni podacima o
njihovim roditeljima i slično. Primjetite kako podatak roditelj može imati više djece ali
podatak dijete samo jednog roditelja

c. Mrežni model – ima sličnu strukturu kao

hijerarhijski model s tim da razlika
počiva na tome da pravilo o samo jednom
roditelju ne vrijedi; podaci mogu biti
višestruko isprepleteni
d. Relacijski model – ćemo opisati kasnije u

Slika 3. Cvijet velike detalje

e. Objektno relacijski model – je direktan naslijednik relacijskog modela ali podržava
objektno orijentirane modele baze podataka kao što su to objekti, klase i nasljedstva
f. Zvjezdani model – se sastoji od jedne tablice činjenica s koje se poziva bilo koji broj
dimenzijskih tablica koje se poziva bilo koji broj dimenzijskih tablics koje se poziva bilo
koji broj dimenzijskih tablica.
2. ER dijagram (Entity - relationship diagram) – je apstraktna konceptualna reprezentacija
struktuiranih podatak. Najčešće se koristi za izradu konceptualne šeme ili semantičkig
modela podataka sustava, često i baze podataka. Proces koji se odvija prilikom izrade je
usmjeren sa vrha na dolje. ER dijagram utilizira prilično jednostavan sustav obilježavanja.
Neki objekt definiran je na dijagramu jednostavno kao kvadrat. Objektom ćemo pak smatrati
sve ono što može imati neke atribute ili svojstva. Upravo tako, o objektima možemo

3
 razmišljati kao o imenicama: Kuća, student, automobil; mogu biti primjeri objekta, ali
jednako tako i prodaja, narudžba i slično. Ukoliko slijedimo analogiju uočavamo da veze
između objekata možemo definirati kao glagole ili predikate. Dakle: Student kupuje kuću;
Student kupuje automobil... Prikazati ćemo taj odnos na jednostavnom grafu:
Nadalje, ako ćemo razmisliti o konceptu atributa, shvatit ćemo da se analogija na kolokvijalni govor
i dalje primjenjuje. Dakle, atribut nekog entiteta ili objekta bio bi neki pridjev, odnosno opis same
imenice; tako će studenta opisivati njegov JMBAG, Adresa, Ime,Prezime i slično. Za svaki entitet
trebamo definirati odvojene atribute, jer se oni naravno razlikuju od entiteta do entiteta. Diagram na
koji su dodani atributi prikazujemo:
Konačno, diagramu ćemo dodati neke atribure koji će predstavljati jedinstvene identifirkatore.
Naime, potreba za njima rađa se jer neki entiteti mogu sadržavati jednake atribute. Tada je potrebno
razlikovati ta dva entiteta nekim jedinstvenim obilježjem. Dakle, vidimo da je sama struktura
jednostavna, te se prilično lako može iščitati sve o nekom sustavu. Naravno, ništa nije savršeno. Od
očitih problema će mo istaknuti nedostatak složenijih elemenata kojima bi definirali kompliciranije
odnose i veze te eventualnu zakrčenost cijele slike ukoliko je broj atributa pojedinih entiteta velik.

3. Dijagram strukture podataka (Data structure diagram ili DSD) je model podataka koji večim
dijelom funkcionira na jednakoj razini kao i ER diagram. Osnovni elementi DSD-a su
entiteti i strelice (koje predstavljaju veze). Za razliku od ER diagrama, atributi su kod DSD
– a specificirani unutar kvadrata entiteta, tako poboljšavajući vizualnu komponentu. Osim
toga, umjesto da se kao ER zasniva večim dijelom na odnosima između entiteta, DSD se
bavi i odnosima unutar entiteta. Stoga ga na neki način smatramo proširenom verzijom ER
dijagrama.

4. Generički modeli podataka su generalizacija konvencionalnih modela podatka. Njihova

primarna zadaća je definirati standardizirane tipove odnosa među različitim načinima
prikazivanja podatka. Dakle, kolokvijalno rečeno, možemo reći da se generički modeli
podataka pokušavaju približiti prirodnom jeziku, koji svi koristimo. Poanta takvog modela
podataka je da bi se izbjegla potreba za najrazličitijim sredstvima za promatranje podataka.
Naime, takav model podatka bi predstavljao neko univerzalno rješenje.

5. Semantički modeli podataka u programskom inžinjersvu predstavljaju tehniku definiranja

značenja podataka s obzorom na kontekst međuveza sa drugim podacima. Dakle, semantički
model podataka je apstrakcija koja definira kako se pohranjeni simboli odnose na realnu

4
 stvarnost. Gledano iz perspektive baza podataka, možemo ovaj model nazvati i
konceptualnim. Ako pogledamo ilustraciju...
...Možda nam postane jasnije o čemu se zapravo radi. Dakle, stvarni svijet ima svoje entitete,
atribute, ideje... Pitanje je kako ih pohraniti na neki fizički medij i zadržati vezu između iskrivljenog
simbola i stvarnog, postojećeg pojma. Sada kada smo upoznati sa osnovnim modelima podataka
možemo se vratiti na model baze podataka.

3. Model baze podataka – relacijski model

3.1. Uvod u relacijski model

Relacijski model, iako se koristi dobrim dijelom danas, svoje početke ime još u šezdesetim
godinama prošlog stoljeća. Začetnik same ideje relacijskog modela je Edgar Frank Codd, Britanski
znanstvenik koji se bavio istraživanjima u računalnoj znanosti. Tijekom šezdesetih godina
teoretizirao je o različitim načinima slaganja, sortiranja i povezivanja podataka. 1970te izdaje
znanstveni rad pod imenom: „A relational model of data for large shared data banks“. Nažalost,
njegova ideja ne uspijeva odmah pod okriljem IBM-a, za koji je radio u tom periodu.
Tijekom narednih godina, razvija relacijski model. Eventualno, tijekom ranih osamdesetih
godina prošlog stoljeća, relacijski model dolazi u modu. Codd je imao značajnih problema sa
proizvođačima baza koji su koristili naziv relacijski, iako njihov proizvod to odista nije bio. Stoga
objavljuje dvanaest pravila u kojima se točno definira što definira relacijsku bazu podataka. Možda
je zanimljiva činjenica da je set od 12 pravila zapravo set od trinaest pravila. Numeriranih od nula
do dvanaest. Neka od njih ćemo ovdje i navesti:
1. Sustav se mora kvalificirati kao relacijski, kao sustav upravljanja i kao baza podataka. Kako
bi se kvalificirao, sustav mora koristiti relacijske mogućnosti (i samo relacijske da upravlja
bazom).
2. Pravilo informacije – Sve informacije u bazi moraju biti predstavljene na jedan i samo jedan
način, u pravilu kao vrijednosti poslagane u stupce sa redovima koji definiraju jedan slog.
3. Pravilo garantiranog pristupa – svim podacima se mora moći pristupiti bez dvojbe je li
informacija prava. Dakle, svaki podatak mora imati jedinstvenu adresu sastavljenu od imena
tablice, imena određenog stupca i primarnog ključa pojedinog reda.
4. Postojanje polja bez vrijednosti – svaki DBMS mora moći predstaviti polje koje je prazno.

5
 Dakle, to polje ne smije biti predstavljeno kao nula ili neki broj. Već nekim jedinstvenim
znakom koji označava nepostojanje podatka.
5. Pravilo postojanja kataloga baziranog na relacijskom modelu.
6. Pravilo sveobuhvatnosti podjezika
7. Pravilo osvježavanja pogleda
8. Umetanje, ažuriranje i brisanje visoke razine
9. Fizička nezavisnost podataka – garanitra da promjene u fizičkoj strukturi pohrane podataka
(odnosno načinu na koji su podaci pohranjeni) neće za sobom povlačiti promjene na
programskoj strukturi.
10. Logička nezavisnost podatka – promjene na logičkoj razini ne smiju za sobom povlačiti
promjene an programskoj strukturi. Budući da logička struktura podrazumijeva izgled
tabela, stupaca, redaka i slično, takvu neovisnos je očito nešto teže postići.
11. Neovisnost na razini integriteta – ograničenja integriteta moraju biti navedena i specificirana
odvojeno od programskog sloga i pohranjena u katalog. Mora biti moguće promijeniti
takvea ograničenja bez nužnog utjecaja na sam program.
12. Distribucijska neovisnost – promjene lokacije baze podataka ne smiju utjecati na rad baze
13. Pravilo nesubverzivnosti
Dakle, po relacijskom modelu baza podataka sastojati će se od skupa pravokutnih tabela ili
relacija. Svaku relaciju ćemo od ostalih morati razlikovati jedinstvenim imenom. U svakoj relaciji
moramo definirati stupce koji sadrže po jedan atribut određenog entiteta koji prikazuje relacija.
Jednako kao što relacija mora imati jedinstveni identifikator, atributi moraju imati svoje, a svi
atributi dijele istu vrstu ili tip podataka. Sve vrijednosti koje može zauzeti jedan atribut ćemo zvati
domenom atributa. Dobra ilustracija domene atributa bi bila godine neke osobe. Ta domena će
obuhvaćati racionalne brojeve u rasponu od nule do nekih maksimalnih 150 godina života (želimo
uzeti u obzir sve mogućnosti). Osim svoje domene, atributi su određeni jednostrukošću i
jednostavnošću, dakle, atribut ne smije biti rastavljen na sitnije dijelove. Jedan atribut je obilježje
koje nije kompozicija drugih obilježja. Sve to ćemo zaokružiti definicijom stupnja relacije, koju čini
broj atributa u relaciji.

3.2. Primjerci ili n-torke relacija

Definirajući tako osnovna obilježja relacijske baze kroz koncepte relacije i atributa treba se
zapitati i što se nalazi u retku neke relacije. Prije nego krenemo u te vode, treba pojasniti da neka

6
relacija ne mora nužno prikazivati neki entitet, već može biti i kompozitna, odnosno produkt nekog
upita, pa tako prikazivati polja (stupce) iz više tablica. Dakle, jedan redak relacije će predstavljati
primjerak entiteta ili pak veze između više enitteta. Takav primjerak ćemo nazvati n-torka. Pravila
n-torke su prilično jednostavna. Ona je uređena svojim atributima, pripada nekoj relaciji ili je dio
više relacija, ali povezana nekim jedinstvenim mjerilom. Osim toga, u jednoj relaciji ne mogu biti
dvije jednake n-torke. Znači neki primjerak entiteta se smije ponavljati samo jednom, odosno
relacija ne smije imati ponavljajuće podatke. Broj takvih n-torki predstavlja kardinalnost (ili
veličinu) relacije. Također, prateći navedena pravila, primjećujemo kako ne postoji neki kriterij oko
redoslijeda kojima se prikazuju atributi ili primjerci entiteta. Ukoliko sortiramo primjerke na ovaj ili
onaj način, mijenjamo samo zapis, ali relacija sama po sebi ostaje ista. Dakle, poanta relacije je
povezanost podataka, umjesto njihovog redoslijeda.
Također, radi lakše razumljivosti i snalaženja možda ne bi bilo loše prikazati različite termine
istih pojmova kroz razne platforme:
Nadalje, spomenuli smo da je svaki primjerak ili n-torka relacije nužno označena na neki
jedinstveni način. Taj atribut nazivamo ključem, a njegova vrijednost će jednoznačno odrediti n-
torku u relaciji. Budući da je ključ kriterij jednoznačnosti, da bi zadovoljili pravilo relacije on
uvijek mora postojati. Postavivši pitanje što sve može biti ključ dolazimo do svega nekolicine
odgovora. Bilo koji broj, na primjer, pod uvjetom da isti ne postoji u svojstvu ključa. Najčešće se
rabi slučajan broj ili inkrementalni skup. Zatim neki niz brojeva koji je po definiciji jedinstven,
poput JMBG-a ili OIB-a, potom neki određeni niz znakova, i slično.
Ukoliko neka relacija sadrži nekolicinu takvih atributa (koji zadovoljavaju preduvjete da bi bili
ključ), odabiremo onu koja nam predstavlja najzgodniju za uporabu. Kod neke evidencije
građanstva ćemo prije odabrati njihov JMBG nego broj osobne iskaznice, iako su oba jedinstveni
brojevi. Jednom kada odaberemo takav ključ, proglašavamo ga primarnim ključem. Primarni ključ,
naravno, ne poštuje pravilo da podaci mogu poprimiti praznu (takozvanu NULL vrijednost) jer bi to
narušilo integritet baze.

4. Ograničenja

4.1 Opća ograničenja

7
 Možda je potrebito još i spomenuti neka generalna ograničenja koja se pojavljuju prilikom
izrade baze podataka. Postoje dva opća ogranilenja: entitetni integritet i referencijalni integritet.
Premda sudeći samo po nazivima ta dva ograničenja jesu komplicirana, njihova primjena je sasvim
prisutna u realnom svijetu. Prvo ograničenje zasniva se na mogućnosti raspoznavanja entiteta, a
drugo na samom postojanju.
Načelo entitetnog integriteta iskazati ćemo kao pravilo da atributi koji tvore primarni ključ
ne smiju sadržavi null oznaku. Premda smo ovo već na određeni način i implicirali kroz prijašnji
rad, ne vidim zašto se to ne bi dalje formalizirlo. Dakle, načelo entitetnog integriteta nalaže da
oznaka relacije (atribut) koja je jednoznačna i predstavlja njen primarni ključ nikako ne smije biti
nepostojeća. Budući da smo s takvim pravilom upoznati iz generalnog razglabanja o relacijama kao
i kroz Coddovih 12 pravila, možemo reći da je ovo pravilo prije korolar nego načelo. Ono slijedi iz
definicije relacije.
S druge strane, referancijalni integritet nam inferira da svaka vrijednost vanjskog ključa koja
postoji mora biti uparena sa odgovarajučim primarnim ključem u njegovoj matičnoj relaciji. Za
primjer uzmimo račun koji je izdan studentu čiji JMBAG ne postoji: Student nije u bazi, račun nije
valjan, nisu ispoštovana pravila relacija.

4.2. Specifična ograničenja

Iako su opća ograničenja imala prizvuk ograničenja na cijeli sustav, specifična ne nose
nikakve preciznije definije kao što bi mogli pomisliti iz naziva. Specifična ograničenja će
jednostavno govoriti o nekom setu pravila koji potječe iz vanjskog svijeta ili je jednostavno
predodređen. Stoga ćemo reći da su specifična ograničenja uvjeti na pojedine podatke koji na neki
način definiraju njihov raspon. Ukoliko pokušamo primjeniti to pravilo na neki realni sustav vidjeti
ćemo da je primjena mnoštvo. Za početak možemo uzeti veliku večinu skalarnih vrijednosti iz
prirode: Masu, tlak, brzinu...
Dakle, ukoliko neka operacija nad bazom podataka dovede do kršenja tih specifičnih ograničenja
baza se smatra proturječnom i postoji problem. Proturječnost doduše implicra samo formalnu
ispravnost sadržaja, to jest, bazu ćemo smatrati točnom sve dok ne postoje dva kontradiktorna
podatka.
Jednom kada su ova ograničenja postavljena, baza je spremna za uporabu.

8
5. Uvod u relacijsku algrebru

Dio relacijskog modela koji se bavi manipulacijom podataka značajno je evoluirao od

orginalanog nacrta Codd-ovog relacijskog modela, no još uvijek je slučaj da je osnovna
komponenta ovog manipulativnog dijela relacijskog modela relacijska algebra. Relacijska algebra je
u osnovi samo set operatora koji imaju relacije za operande, a njihov konačan rezultat je nova
relacija. U ovom poglavlju pozabavit ćemo se uglavnom setom operacija koje je definirao sam
Codd. Naime,Codd je razvio sustav od 8 različitih operacija koji je trebao biti u mogućnosti stvoriti,
dohvatiti ili izabrati podatke iz bilo koje relacije. Danas pak, ovih 8 operacija nikako nisu kraj priče.
Zapravo broj operacija koji može biti definiran je gotovo pa beskonačan jer jedini uvjet za
zadovoljavanje jednostavnih pravila operacija s bazama je da relacija uđe i relacija izađe.
Za početak, nabrojati ćemo i ukratko opisati 8 operatora koji se po sličnosti mogu podijeliti
u dvije grupe:
Tradicionalni set operatora koji obuhvaća uniju, presjek, razliku i kartezijev produkt.
Specijalni relacijski operatori: restrict, project, join i divide.
Razmotrit ćemo pojednostavljene definicije svih 8 operatora. S tim da ćemo tradicionalni set
operatora razmotriti u nešto više detalja.
Unija vraća relaciju koja sadrži sve primjerke koji se pojavljuju u jednoj ili obje
relacije. U matematici, unija dva seta je set svih elemenata koji pripadaju bilo jednom ili drugom
originalnom setu. Budući da je relacija u nekoj nategnutijoj definiciji zapravo set, konkretnije set
primjeraka, očito je moguće stvoriti uniju dva takva seta. Rezultat će biti jedinstvena relacija koja se
sastoji od primjeraka nađenih u jednoj ili obje orginalne relacije. Naprimjer, unija seta podataka o
studentima i seta podataka o računima je svakako set koji opisuje račune koji pripadaju pojedinom
studentu. No,iako rezultat je set, nije relacija; relacija ne može sadržavao mješovite primjerke, ona
mora biti primjerno homogena. Naravno, ako razmatramo pravila relacijskog modela, to može
predstavljati problem. Stoga unija u relacijskom modelu je posebna vrsta unije, dakle nije
uobičajena matematička unije već ona u kojoj zahtijevamo da su ulazne relacije istog tipa. Slijedno
tome u uniju možemo staviti samo dva primjerka studenta ili dva primjerka računa ali ne i
mješavinu navedenoga. Tako su očuvana pravila relacijskog modela.
Presjek vraća relaciju u kojoj se pojavljuju primjerci koji su sadržani u obje relacije. Kao i
kod unije, te zbog gotovo identičnoga razloga relacijski operator presjeka zahtjeva relacije da budu
istog tipa. Pretpostavljajući da su relacija A i relacija B istog tipa, presjek te dvije relacije, A presjek

9
B, biti će relacija istog tipa s tijelom u kojem se nalaze svi primjerci P tako da je P element A i B.
Razlika vraća relaciju koja sadrži sve primjerke koji su različiti među tablicama. Slijedno
pravilima unije i presjeka, operator razlike također traži da operandi budu istog tipa. Ukoliko
imamo relaciju A i relaciju B koje su istog tipa razlika te dvije relacije, A razlika B (isključivo tim
redom), je relacija istog tipa sa tijelom koje se sastoji od svih primjeraka P koji se pojavljuju u A, ali
ne i u B.
Kartezijev produkt vraća relaciju koja sadrži sve kombinacije primjeraka dvije relacije. U
matematici kartezijev produkt dva seta je set svih parova tako da je u svakom paru prvi element iz
prvog seta i drugi element iz drugog seta. Dakle, kartezijev produkt bio bi set uređenih parova
primjeraka, što bi opet narušilo relacijski integritet. Drugim riječima, želimo da rezultat sadrži
primjerke, a ne uređene parove primjeraka,dakle relacijska verzija kartezijevog produkta je
proširena forma operacije u kojoj je svaki uređeni par primjeraka zamijenjen jednostrukim
primjerkom koji je unija dva primjerka u pitanju.
Restrict vraća sve primjerke iz određene relacije koji zadovoljavaju neki određeni uvjet
Project vraća relaciju koja sadrži sve primjerke koji ostaju u specifičnoj relaciji nakon što su
određeni atributi uklonjeni.
Join (ili pridruži) vraća združene vrijednosti dvije ili više tablica.
Divide (podijeli) uzima dvije unarne operacije te jednu binarnu i vraća relaciju koja sadrži
sve primjerke iz unarne relacije koji se pojavljuju u binarnoj relaciji zajedno s primjercima u
drugoj unarnoj relaciji.
Iako smo možda tijekom ove rasprave o operatorima dobili dojam da primarna funkcija
relacijske algebre isključivo dohvaćanje podataka, moramo ovdje istaknuti da to niti u jednom
slučaju nije isključivo tako. Fundamentalni cilj relacijske algebre je dopustiti pisanje relacijskih
izraza. Izrazi tako imaju najrazličitije spektar mogućih svrha. Naravno da je jedan od njih
pribavljanje podataka ali nikako se ne ograničavamo isključivo na njih. Sljedeća lista koje je
predviđena isključivo kratkom upoznavanju daje nam neke indikacije o mogućim primjenama ovih
izraza:
Definiranje parametara pribavljanja podataka.
Definiranje parametara ažuriranja relacije
Definiranje integritetnih ograničenja
Definiranje zahtjeva stabilnosti
Definiranje sigurnosnih ograničenja
Generalno gledajući takvi izrazi služe kao simbolička reprezentacija korisnikove namjere

10
visoke razine.

6. Zaključak

Općenito gledano, modeli podataka su neizbježni u današnjem svijetu. Naime, sve mora imati
neku svrhu i standard kako bi se moglo dijeliti i služiti nama bez da imamo problema sa
interpretiranjem. No, postavlja se pitanje: Dokle tako?
Očito je kako se ulaže silan trud da se nešto dobije u formalizirani model. Osim toga, svi
proizvođači softver-a imaju tendenciju koristiti svoje, tako stvarajući enormnu zbrku po nas. No,
čini se da postoji neko svjetlo na kraju tunela. Sve više se radi na generičkim modelima, koji bi
jedan dan mogli postati standard i tako nas zauvijek riješiti muka sa formatima podataka i sličnim.
Što se tiče samih baza podataka, relacijski model koji je danas dominantan vjerojatno je u toj
poziciji s razlogom. No, premda ima ogromne koristi i radi svoj posao sasvim dobro. Svatko tko je
jednom radio po njemu se nije mogao n zapitati zašto je to tako kruto. Moguće poboljšanje vidimo
u nekim od modernijih modela baza podataka koji će nam olakšati život i na tom polju.
Nadalje, mnogo podataka kojima baratamo danas je organizirano hijerarhijski. Prvo nam na
pamet padaju datotečni sustav, knjižničke klasifikacijske sheme, pa čak i kategorije žutih stranica.
Naravno, tu su i podaci nastali kao rezultat poslovanja. Samim time se pitamo, je li hijerarhijski
model podataka u bazama pravedno zamijenjen onim relacijskim. Zbog nedavnog povećanja
interesa za hijerarhijski model ( moguća direktna posljedica rasta važnosti x.500/LDAP direktorija,
koji su hijerarhijski, nekih novih funkcija XML aplikacija te povećanje interesa za razmjenu
podataka među bazama podataka različitih tipova ) postoji obnovljeni interes za tim modelom.
Možda je potrebno izraditi nove radne okvire utemeljene na ovom modelu koji bi unaprijedili rad
na mnogim poljima. Možda je moguće argumentirati da će unaprijeđena verzija ovog modela doista
nadići mogućnosti relacijskog.
Ono što zaista želimo reći je da ništa nije definirano. Nema sigurnog znaka kamo nas
budućnost tehnologije vodi, pogotovo kada se radi o području važnom poput ovoga. Kako god bilo,
možda je nakon tridesetak godina malih promjena vrijeme za neke velike skokove?

11
Popis slika
Slika 1. Koala.......................................................................................................................................3
Slika 2. Pustinja....................................................................................................................................4
Slika 3. Cvijet.......................................................................................................................................5

Kazalo pojmova
Atributa............................................................4
Baza podataka..................................................1
Dijagram strukture podataka...........................4
Elemente..........................................................2
ER dijagram.....................................................3
Generički modeli podataka..............................4
Hijerarhijski model..........................................3
Instance............................................................2
Modali podataka..............................................2
Modeli podataka..............................................1
Mrežni model...................................................3
Objektno relacijski model................................3
Relacijski model..............................................3
Semantički modeli podataka............................4
Tablični model ................................................3
Zvjezdani model..............................................3

12