Marin Kalua

SUSTAVI BAZA PODATAKA

Nakladnik: Veleuilite u Rijeci

Za nakladnika: doc. dr. sc. Duan Rudi, prof. v. .

Lektor: Sanja Grakali Plenkovi, prof.

Recenzenti: dr. sc. Ninoslav Novak, izv. prof.

dr. sc. Mile Pavli, izv. prof.

Tisak: Veleuilite u Rijeci, Rijeka

Naklada: 40 kom
Nijedan dio ove skripte ne smije se umnoavati, fotokopirati ni
na bilo koji drugi nain reproducirati ili koristiti, ukljuujui web distribuciju
i sustave za pretraivanje, te skladitenje podataka bez pismenog
doputenja nakladnika.
CIP - Katalogizacija u publikaciji
SVEUILINA KNJINICA
RIJEKA
UDK 004.65(075.8)
KALUA, Marin
Sustavi baza podataka / Marin Kalua. Rijeka :
Veleuilite, 2008. - (Udbenici Veleuilita u Rijeci =
Manualia Collegium Politechnic Fluminensis)

Veleuilite u Rijeci uvrstilo je ovaj udbenik u veleuiline udbenike (Klasa: 00309/08-01/01, Ur. broj: 2170-57-01-08-13).

PREDGOVOR
Ova skripta napisana je prema sadraju kolegija Sustavi baza podataka koji se izvodi
na Strunom studiju informatike pri Veleuilitu u Rijeci. Svi sadraji koji su skriptom
obraeni usklaeni su s planom i programom kolegija.
Skripta obuhvaa osnovna razmatranja potreba za drutvenu korisnost baza
podataka sa stanovita organizacije, skladitenja i koritenja podatkovnog sadraja.
Objanjava koncepte fizike organizacije podataka i fizikog skladitenja, dohvata i
dostupnosti podatkovnog sadraja. Prikazano je i logiko gledanje na podatke,
logika organiziranost podataka, te komunikacijski jezik s raunalom za dohvat
podataka i razumijevanje istih. Objanjena su i semantika ogranienja na podacima
i njihova izvedivost na bazi podataka. Pravila koja uvaju konzistentnost u
podatkovnom

sadraju

definirana

su

odreenim

matematiki

dokazanim

zakonitostima. Kako bi se mogla ouvati konzistentnost podataka i skladitenje i

auriranje jedne informacije u samo jednom trenutku, pokazani su postupci
normaliziranja

podataka,

odnosno

svoenje

anomalija

prilikom

auriranja

podatkovnog sadraja na minimum. Semantika pravila koja djeluju na razini statike

(stanja) sustava nisu uvijek dostatna, tj. ogranienja nisu dovoljna kako bi sustavna
statika ouvala konzistentnost podataka, pa su stoga objanjene akcijske mjere
uvanja istog. Na posljetku su prikazane metode komunikacije korisnika s
podatkovnim sadrajem zbog potrebe za to brom i tonijom vezom prema
podatkovnom sadraju.
Autor

Rijeka, svibanj 2008.

SADRAJ
1.

UVOD U BAZE PODATAKA.......................................................................................................... 1

1.1.

POTREBE U OKRUENJU.................................................................................................... 1

1.2.

PROMJENE U DRUTVU...................................................................................................... 1

1.3.

RAD U SUVREMENO DOBA BEZ KORITENJA BAZA PODATAKA ................................... 2

1.4.

ODNOS ORGANIZACIJSKOG I INFORMACIJSKOG SUSTAVA.......................................... 3

2.

FIZIKA ORGANIZACIJA BAZE PODATAKA............................................................................. 4

3.

ORGANIZACIJA PODATAKA ....................................................................................................... 6

3.1.

DATOTENA ORGANIZIRANOST........................................................................................ 6

3.2.

METODE PRISTUPA PODACIMA......................................................................................... 7

4.

POGLED NA PODATKE.............................................................................................................. 10

5.

TRADICIONALNA DATOTENA ORGANIZIRANOST .............................................................. 11

6.

BAZA PODATAKA....................................................................................................................... 16
6.1.

6.1.1.

DD (Data Dictionary rjenik podataka) ..................................................................... 18

6.1.2.

DDL (Data Definition Language jezik za stvaranje tipova podataka)....................... 19

6.1.3.

DML (Data Manipulation Language jezik za manipuliranje podacima) .................... 20

6.1.4.

DQL (Data Query Language podatkovni upitni jezik)............................................... 21

6.2.
7.

DBMS ................................................................................................................................... 16

SQL ...................................................................................................................................... 23

VEZE I MODEL PODATAKA ....................................................................................................... 24

7.1.

TIPOVI VEZA ....................................................................................................................... 24

7.1.1.

TIP VEZE 1 PREMA 1.............................................................................................. 24

7.1.2.

TIP VEZE 1 PREMA VIE ....................................................................................... 25

7.1.3.

TIP VEZE VIE PREMA VIE ................................................................................. 25

7.2.

MODELI PODATAKA ........................................................................................................... 26

7.2.1.

HIJERARHIJSKI MODEL ............................................................................................ 26

7.2.2.

MRENI MODEL ......................................................................................................... 27

7.2.3.

RELACIJSKI MODEL .................................................................................................. 28

7.2.4.

OBJEKTNI MODEL ..................................................................................................... 29

8.

XML .............................................................................................................................................. 30

9.

FAZE RAZVOJA BAZE PODATAKA .......................................................................................... 33

10.

CODDOVA PRAVILA .............................................................................................................. 35

11.

RELACIJSKA TEORIJA .......................................................................................................... 39

11.1.

SHEMA RELACIJE, SLOG, RELACIJA ............................................................................... 39

11.2.

RELACIJSKA ALGEBRA ..................................................................................................... 40

11.2.1.

NASLIJEENI RELACIJSKI OPERATORI ................................................................. 41

11.2.2.

OSNOVNI RELACIJSKI OPERATORI ........................................................................ 44

11.2.3.

IZVEDENI RELACIJSKI OPERATORI ........................................................................ 48

11.2.4.

VANJSKO SPAJANJE................................................................................................. 50

11.3.

FUNKCIJSKA ZAVISNOST.................................................................................................. 51

11.4.

KLJU .................................................................................................................................. 52

12.

NOMALIZACIJA BAZE PODATAKA ...................................................................................... 54

12.1.

REDUNDANCIJA ................................................................................................................. 54

12.2.

ANOMALIJE ......................................................................................................................... 55

12.3.

NORMALIZACIJA ................................................................................................................ 57

12.4.

DEKOMPOZICIJA BEZ GUBITKA INFORMACIJA I FUNKCIJSKIH ZAVISNOSTI ............. 58

12.5.

NORMALNE FORME ........................................................................................................... 59

12.5.1.

1. NORMALNA FORMA .............................................................................................. 59

12.5.2.

2. NORMALNA FORMA .............................................................................................. 62

12.5.3.

3. NORMALNA FORMA .............................................................................................. 63

12.5.4.

BCNF BOYCE-CODDOVA NORMALNA FORMA ................................................... 64

13.

DINAMIKA U BAZI PODATAKA ............................................................................................. 66

13.1.

UVANJE KONZISTENTNOSTI.......................................................................................... 67

13.2.

PROMJENE U PODACIMA ZA POTREBE SUSTAVA......................................................... 69

13.2.1.

TRANSAKCIJSKI PRISTUP........................................................................................ 70

13.2.2.

PROVOENJE POSLOVNIH PRAVILA ..................................................................... 72

13.3.
14.

BRZINA ODZIVA REZULTAT UPITA ................................................................................ 74

LITERATURA........................................................................................................................... 76

1. UVOD U BAZE PODATAKA

1.1. POTREBE U OKRUENJU
Teimo ivotu u digitalnom drutvu. To nije metafora u oekivanju Godota.
elimo ivjeti u digitalnom drutvu jer pomou raunala kao sofisticiranog alata
moemo brzo i tono doi do informacije kako bismo potvrdili je li odreena akcija
korektna i ne kosi li se s pravilima postavljenim na razini ovjeanstva. Kako bismo
mogli doi do takve razine u razvoju, potrebno je da budemo na razini koja se zove
informacijsko drutvo. Informacijsko drutvo je razina u razvoju u kojoj postoji potreba
za brzim i tonim dolaskom do informacije. Kako bi se postigla razina u razvoju
nazvana digitalno drutvo, potrebno je razini informacijskog drutva dodati aktivnosti
koje se zovu e-poslovanje.
Shematski:

1.2. PROMJENE U DRUTVU

Ako promatramo razvoj drutva, moemo zakljuiti da vrijeme nosi promjene
koje se s vremenom poveavaju.
U doba poljoprivredne ere nije se deavalo previe promjena, ako pogledamo
koliinu promjena u dananje vrijeme. Metaforiki gledano, ovjek je u srednjem
vijeku nauio koristiti plug za oranje zemlje i tako je orao. Njegov sin i njegov unuk su
takoer orali zemlju. Generacijama se nisu deavale promjene ili su one bile
minimalne.

Za vrijeme industrijskog doba deavalo se malo promjena. To je neto vie od

poljoprivrednog doba, a opet manje od dananjeg modernog doba. Promjene su
zahtijevale usvajanje znanja o tehnolokim promjena u radnim procesima, odnosima
meu ljudima, te novanim odnosima.
Intenziviranjem brzine usvajanja znanja i koliine meuljudskih potreba nai
emo se u dananjem, modernom dobu. Iz ovoga se vidi da se brzina promjena
neprestano poveava, tovie, eksponencijalno se poveava.
Kako bismo mogli biti ukorak s promjenama (up to date), kako bismo mogli
dobiti tonu informaciju u pravo vrijeme i na pravom mjestu, potrebno je koristiti
odgovarajue alate raunala. Raunala mogu uz pomo programa pokazati
podatke iz kojih e se interpretirati potrebna informacija. Podaci se u raunalima
nalaze spremljeni u odreena spremita koja su logiki povezana. Sada nastaje
potreba za bazom podataka.

1.3. RAD

SUVREMENO

DOBA

BEZ

KORITENJA

BAZA

PODATAKA
Svjetski trendovi pokazuju potrebu za sve veom povezanou meu ljudima
u poslovnom i neposlovnom ivotu. U komunikaciji meu ljudima potrebni su podaci
koji e predstavljati temelj uspjeno izvedene komunikacije. Kada u komunikaciji ne
bismo koristili podatke kao dokaze, vrlo bismo brzo bili izbaeni iz igre. To znai da
u suvremeno, digitalno doba, u vrijeme globalizacije, ne moemo biti uspjean
poslovni subjekt ako ne posjedujemo podatke iz kojih moemo jednostavno, brzo, i
tono doi do informacije koja moe pomoi u poslovnom odnosu.

Komunikacija bez koritenja podataka dobivenih iz baze moe biti Sizifov posao.

1.4. ODNOS ORGANIZACIJSKOG I INFORMACIJSKOG SUSTAVA

Temelj organizacijskog sustava ine: resursi, ljudi i komunikacija. Tei se da
ljudi uz pomo odabranih resursa izvre komunikaciju to je mogue bolje. U takvom
sustavu djeluje nekoliko elemenata: organizacija, poslovanje, posao, pravila i odnosi.
Svaki od navedenih elemenata utjee na proces komunikacije. To znai da svi
navedeni elementi mogu biti zapisani u podatkovnoj osnovi. Iz podataka se
reverzibilno moe dobiti spremljena informacija ili se pak moe generirati nova uz
potivanje odreenih uvjeta.
Sustav koji prikuplja, sprema (pohranjuje), obrauje i distribuira podatke zove
se informacijski sustav. Informacijski sustav moe postojati jedino kada posjeduje
svaki od sljedeih elemenata:
-

hardware raunalne komponente

software programi (korisnike aplikacije)

lifeware korisnike programa, ljude

orgware organizaciju i organizacijska pravila za komunikaciju

netware omreenje poslovnih partnera (internih - unutar poduzea, i

eksternih - iz drugog poduzea)

Slika pokazuje povezanost svih elemenata informacijskog sustava i poloaj baze

podataka. Baza podataka ima direktan utjecaj na svaki pojedini element
informacijskog sustava.

2. FIZIKA ORGANIZACIJA BAZE PODATAKA

BIT
Najmanja logika jedinica koja postoji na fizikoj razini. Bit moe primiti dva
mogua stanja: 1 (true, upaljeno), 0 (false, ugaeno). Bit predstavlja vrstu prekidaa
koji se moe paliti i gasiti. Kada je upaljen tada je u logikom stanju 1 (ima struje).
Kada je ugaen tada je u logikom stanju 0 (nema struje).
BAJT
Bajt predstavlja nakupinu od 8 bitova. esto se bajt usporeuje s pojmom
znak. Razumijevanje bajta proitanog iz raunala nosi informacije (postavke) o
jednom znaku. Kako u jednom bajtu ima 8 bitova, tako se moe dobiti maksimalno 28
(256) razliitih kombinacija bitova unutar jednog bajta. To znai da raunalo moe
pokazati maksimalno 256 razliitih znakova. Bajt je najmanja logika jedinica koja
moe biti fiziki zapisana, a nosi semantiku vrijednost. Bajt nosi minimum znaenja
ono to ovjek razumije.
POLJE
Skup vie bajtova koji ine jednu cjelinu. Polje nije fizika tvorevina. Polje je
sainjeno od niih logikih komponenti. Ono nosi semantiku vrijednost koja izraava
odreenu pojavnost. Polje predstavlja skup specijalno odabranih znakova koji daju
svojstvo (atribuciju) nekoj pojavi.
esto se poistovjeuju nazivi polje i atribut. Navedena dva naziva imaju
jednako, ali i razliito znaenje. Polje predstavlja fiziko mjesto gdje e biti zapisan
odreeni segment opisa promatrane pojave, dok atribut predstavlja tip opisa svih
pojava, a vrijednost atributa na odreenom slogu zapisana je u polju. Polje je fiziki
pojam, a atribut je semantiki pojam,
SLOG
Skup vie razliitih polja koja zajedniki opisuju jednu pojavu. Slog predstavlja
jednu pojavu, ija su odabrana svojstva opisana u poljima (atributima). Slog sudjeluje
u procesu obrade podataka. On predstavlja najmanju sliku objektivne stvarnosti
zapisane u raunalu. Raunalo je sliku objektivne stvarnosti zapisalo pomou opisnih
elemenata (polja atributa), a time je stvarna objektivna pojava preslikana u slog.

DATOTEKA
Skup istovrsnih slogova koji zajedno ine i definiraju tip pojave. Kako svaki
slog predstavlja jednu jedinku iz objektivne stvarnosti opisanu pomou vrijednosti
atributa zapisanu u poljima, tako datoteka predstavlja stog takvih pojava meusobno
razliitih, ali samo onih koje pripadaju istom tipu pojave i koje se mogu jednoznano
opisati atributima (poljima) u datoteci.
Tako npr. postoji datoteka koja sadri podatke o studentima. Ona je sainjena
od slogova, a slogovi su pojedinani studenti iz objektivne stvarnosti. Razliitost
svakog pojedinog studenta od drugog definirana je vrijednostima u poljima
(atributima).
Isto tako, primjerice, postoji datoteka o studijima iji slogovi predstavljaju
pojedinane studije koji su opisani i zapisani u poljima.
U datoteci se nalaze samo slogovi iste vrste. U datoteci nema slogova
razliitih vrsta. Moderniji programi posjeduju mogunost spremanja slogova u
datoteku, a koji nisu jednake vrste. Takve datoteke imaju fiziki odvojene lokacije za
spremanje slogova razliitih vrsta. Slogovi jedne vrste spremaju se u jedan dio
datoteke, dok se slogovi druge vrste spremaju u drugi dio datoteke.
BAZA PODATAKA
Organizirana, povezana, elektronika biblioteka datoteka. Baza podataka
sastoji se od vie razliitih datoteka koje su na logikoj razini na neki nain povezane.
Povezane nisu datoteke, ve podaci koji se nalaze zapisani u poljima slogova
datoteke. Baza podataka je organizirana jer postoje pravila povezivanja i odnosa
meu podacima iz datoteka. Logike poveznice meu datotekama regulirane su
programskim rjeenjem. Programsko rjeenje koje brine o vezama meu podacima u
datotekama moe biti:
-

dio korisnikog programskog proizvoda (zastarjela tehnologija)

specijalizirani program napisan samo za taj posao.

3. ORGANIZACIJA PODATAKA
Pojam datoteke ve smo pojasnili. U datoteke se spremaju podaci o pojavama
i odnosima u objektivnoj stvarnosti. Podatke je potrebno sigurno zapisati kako bi se
uvijek moglo do njih doi brzo i tono.

3.1. DATOTENA ORGANIZIRANOST

Ovisno o tipu medija i nainu pohrane podataka na njega, postoje dva
temeljna tipa datotene organiziranosti:
-

slijedna slogovi su zapisani jedan iz drugoga, time se slijedi fizika struktura

medija

direktna zapisi su smjeteni na medij, a dohvat slogova ne ovisi o smjetaju

datoteke i redoslijedu nizanja slogova.

SLIJEDNA

DIREKTNA

3.2. METODE PRISTUPA PODACIMA

Bitan aspekt dobrog stvaranja baze podataka je organizacija podataka u bazi.
Kako bi se postigao cilj, dobro organizirana baza podataka, potrebno je razmiljati o
metodama i tehnikama kvalitetnog i brzog spremanja podataka, te njihovog brzog i
jednostavnog dohvaanja.
Organiziranje podataka podrazumijeva sljedee aktivnosti:

osiguranje memorijskog prostora za fiziki smjetaj podataka

stvaranje sheme strukture podataka

dodavanje novih podataka u definiranu strukturu

pronalaenje (rudarenje) podataka

izmjena postojeih podataka

brisanje postojeih podataka.

Prikazani zahtjevi za organizaciju podataka na fizikoj razini provode se sljedeim

metodama:

sekvencijalna metoda SAM (Sequential Access Method)

indeks-sekvencijalna metoda ISAM (Indeks Sequential Access Method)

direktna metoda DAM (Direct Access Method).

SAM
U slijednim ili sekvencijalnim datotekama podaci se zapisuju redom jedan iza
drugoga onim redoslijedom kojim se unose. Ova metoda organizacije podataka moe
se ostvariti na svim nosiocima podataka.
Slika pokazuje shematski prikaz sekvencijalno spremljenih podataka.

Kada slogovi nisu memorirani na uzastopnim adresama, tada se oni meusobno

povezuju pokazivaima. Pokaziva je podatak koji se memorira u slogu, a vrijednost
mu je adresa sljedeeg sloga.
Kada se postavi zahtjev za itanjem odreenog sloga, tada je potrebno proitati sve
slogove do traenog. Taj postupak traje izvjesno vrijeme. Brzina pristupa podacima
ovom metodom je vrlo loa. Pogodno bi bilo slogove memorirati jedan iz drugoga i to
po rastuoj vrijednosti kljua.
Prednosti sekvencijalne metode:

najbolje iskoriten prostor na nosiocu podataka

nema ogranienja u veliini datoteke

programiranje obrade je vrlo jednostavno

obrada je brza i ekonomina kad se izvrava na vie slogova.

Nedostaci sekvencijalne metode:

pretraivanje svih slogova koji se nalaze ispred sloga koji se trai

ogranienost obrade samo na serijski nain.

ISAM
Indeks-sekvencijalna organizacija podataka nastala je na bazi sekvencijalne
organizacije s ciljem da pobolja njezina svojstva. Postojea sekvencijalna struktura
nadograena je indeksnom strukturom. Podatku je mogue pristupiti direktno.
Postoje dva preduvjeta: razliitost definicije sloga i neposredan pristup
memoriji. Slogovima se mora moi pristupiti direktno. To je mogue ako je nositelj
podataka direktno organiziran. ISAM metodom ne mogu biti organizirane datoteke
spremljene na magnetnim trakama. Svaki slog treba se razlikovati od drugoga prema
nekim obiljejima. Takva obiljeja obino se stvaraju na temelju vrijednosti primarnog
kljua ili se sama vrijednost primarnog kljua koristi u tu svrhu.
Zapisivanje podataka provodi se jednako kao i kod SAM metode, samo to se
istovremeno uz zapisivanje podataka izvodi i zapisivanje tablice indeksa. Tablica
indeksa sastoji se od dva stupca: stupac s kljuevima i stupac s adresama slogova.
Za pristup odreenom slogu potrebno je znati vrijednost kljua i time se direktno
pristupa eljenom slogu.

Velika prednost ISAM metode je u tome to je mogue vrlo brzo pristupiti

podacima zahvaljujui kljuu, a indeksna tablica moe sluiti i za sortiranje slogova
po rastuem ili padajuem redoslijedu vrijednosti kljua.
DAM
Direktna organizacija podataka omoguuje direktan pristup podacima. Jednaki
preduvjeti postoje kao i kod ISAM metode. Jedina razlika je to se adresa
memoriranja pojedinog sloga odreuje matematikim algoritmom na temelju
vrijednosti kljua. Postoji vrlo visoka povezanost kljua sloga i adrese pohrane.
Adresa pohrane je rezultat funkcije nad kljuem sloga. Adresa sloga je logika
adresa sloga koja se obino kree od 1 do n. Matematikim algoritmom adresa sloga
pretvara se u stvarnu fiziku adresu na nositelju podataka. O tome brine sustav za
upravljanje fizikim prostorom (File Manager).
Algoritam koji pretvara, transformira vrijednost kljua u adresu sloga, moe za dva
razliita sloga dobiti jednake adrese. Takvi slogovi zovu se sinonimi.
Prednosti DAM metode:

izravan, vrlo brz pristup, ali samo do jednog sloga

slogovi prilikom pristupanja ne trebaju biti sortirani.

Nedostaci:
slaba iskoritenost prostora nosioca podataka
teka sekvencijalna i grupna obrada podataka
tekoe u pronalaenju najboljeg postupka za transformaciju kljua
datoteka mora uvijek biti cijela prisutna u sustavu.

4. POGLED NA PODATKE
Podaci nose odreenu vrstu i razinu stanja realnog svijeta. Podatke treba
uvati kako bi se zakonitosti u realnom svijetu mogle trajno rabiti kao izvori
informacija u buduim aktivnostima. Stoga, kada se promatraju, postoje dva naina
razmiljanja o podacima:
-

fiziki

logiki.

Prvi nain vodi brigu o podacima i njihovom sigurnom spremanju. Drugi se nain
brine o tehnici dohvaanja samo odreenih podataka sa svrhom stvaranja nove
informacije.
FIZIKI POGLED NA PODATKE
Pokazuje lokaciju gdje su podaci smjeteni i u kakvom obliku. Govori o lokaciji
u prostoru, na kojem mediju, u kojoj tablici, u kojem redu i na kojem stupcu se nalazi
odreeni podatak koji se trai. Fiziki pogled pokazuje (objanjava) fiziku lokaciju
podataka. Objanjava metodu (zakonitost) koja definira pravila kako e podaci biti
spremljeni i kako e biti organizirani bitovi (prekidai).
LOGIKI POGLED NA PODATKE
Definira koji su to i kakvi su dobiveni podaci koje potrebuje odreena aplikacija
(programsko rjeenje). Logiki pogled na podatke daje pravila kako pristupiti
podacima iz bilo kakve aplikacije. Podrazumijeva naziv podataka i njegovu tipizaciju.
Tip kojem pripada odreeni podatak kako bi se definirala vrsta dobivene informacije.
Ovaj pogled objanjava pristup kojim korisnik ili programer na konceptualnoj
razini razumije podatke.

10

5. TRADICIONALNA DATOTENA ORGANIZIRANOST

Takva organiziranost podatkovne osnove je zastarjela, te je zato nazvana
tradicionalna. Tradicionalna datotena organiziranost ne stvara razliku u gledanju na
podatke, ne postoje razliita gledita na podatke. Raunalni program dovoljno je
pametan da moe pametno i sigurno spremiti podatke i kasnije ih po potrebi itati.
Takvi programi obino su jednoslojni. Jednoslojan je onaj program koji u sebi ima
integrirane podatke, programsku logiku i nain prikazivanja podataka.
Tradicionalnu programsku organiziranost valja objasniti jer danas jo uvijek
postoje programski proizvodi koji koriste tako organizirane podatke.
Neke znaajke tradicionalne datotene organiziranosti:
1. Istovrsni slogovi nalaze se u jednoj datoteci.
2. U svakoj datoteci nalaze se samo slogovi iste vrste.
3. Ima onoliko datoteka koliko ima vrsta slogova.
4. Program direktno pristupa datoteci podacima.
5. Nain prikazivanja podataka definiran je programom.
Ako je fizika organizacija baze podataka nastala na temelju ER modela podataka,
tada se moe rei da se entiteti (pojave) svakog tipa entiteta (pojavnosti) nalaze u
jednoj datoteci koja fiziki postoji na nositelju podataka (npr. vrstom disku - HDD).
Entiteti drugog tipa entiteta nalaze se u drugoj datoteci, i tako redom dalje.
Svi tipovi entiteta u modelu podataka imaju vlastite datoteke na disku. Vrlo rijetko
postoje sluajevi u kojima se entiteti dvaju ili vie tipova entiteta nalaze unutar jedne
datoteke.
U tradicionalnoj datotenoj organizaciji podataka postoje neki nedostaci:
-

Nekonzistentnost
o Ako se jedan podatak nalazi u dvije razliite datoteke, tada se on moe
na razliite naine itati i/ili pisati. Dvije razliite datoteke mogu biti
razliito fiziki organizirane te mogu posjedovati razliite metode
pristupa. Ne znai da e se jednom podatku u jednoj datoteci pristupati
jednako, odnosno istom metodom i algoritmom, kao i tom istom ili
drugom podatku u nekoj drugoj datoteci.

11

o Korisniki program mora biti dovoljno pametan kako bi mogao ouvati

ovisnosti koje ine poveznice meu podacima. Naini povezivanja
definirani su odnosima u drutvu.
-

Sustavna nepovezanost datoteka

o Datoteke postoje na fizikoj razini i vidljive su kroz operacijski sustav.
Jedino operacijski sustav poznaje gdje su i koje to datoteke postoje na
disku. Kako programi samostalno pristupaju datoteci tada oni stvaraju
svoju logiku povezanost meu datotekama. Ne postoji takav program
koji bi na jednoznaan i ostalim programima razumljiv nain vrio
logiku povezanost meu datotekama.
o Pretpostavimo da postoje dva korisnika programa A i B. Program A
koristi neke podatke u svom poslu. Program B koristi neke iste, a i neke
drugaije podatke programa A. Moe se dogoditi situacija da program A
izvri promjenu nekih podataka, a to se reflektira na gubljenje odnosa
meu podacima koje koristi program B.

Zalihost podataka
o Jednaki podaci u razliitim datotekama nisu povezani na logikoj razini.
Program ne mora poznavati i imati uvida u sve datoteke u kojima se
nalaze podaci. Kako ne postoji sustavna povezanost meu podacima,
esto se deava multipliciranje istog podatka u vie razliitih datoteka.
Time se omoguuje drugim programima dolazak do podataka.
Redundancija je logino narasla.
o Pretpostavimo da postoje dva korisnika programa A i B. Program A
koristi odreene datoteke i u njih sprema neke podatke, a program B
koristi neke druge datoteke i neke datoteke programa A. Program A i
program B ne poznaju koje sve izvore podataka koristi onaj drugi.
Podaci se esto ponavljaju, jer programi A i B esto koriste jednake
podatke, s razliitih lokacija. Jedan podatak je zapisan na razliitim
lokacijama i time se stvara zalihost redundancija.

Ovisnost podataka i programa

o Program poznaje nain organiziranosti i metodu za pristup datoteci.
Program je dovoljno pametan da moe proitati odreenu skupinu
bitova, odnosno, bajtova, i istu pretvoriti u odreenu skupinu znakova

12

koji predstavljaju neku semantiku vrijednost. Program esto definira

internu organiziranost podatkovne datoteke.
o Program posjeduje skup procedura i funkcija koje poznaju nain
fizikog zapisivanja i upravljanja zapisanim podacima na fizikoj razini.
Program s druge strane posjeduje itav niz procedura i funkcija koje
koristi da bi krajnji korisnik mogao upravljati podacima. S obzirom na to
da krajnji korisnik upravlja podacima na semantikoj razini jer mu je
poznato znaenje podatka, a program podacima na fizikoj razini jer
poznaje kako, vidi se vrlo visoka povezanost podataka i korisnikog
programa.
-

Onemoguavanje

fleksibilnosti

obrade

viih

razina

upravljanja

podacima
o esto postoje zahtjevi za dobivanjem novih informacija iz podatkovne
osnove, ali ne iz samo jedne datoteke. Dolazak do odreenih podataka
iz vie razliitih datoteka i njihovo prezentiranje krajnjem korisniku kroz
program obino se rjeava pomou vrlo sloenih algoritama, koji su
ukljueni u sam program.
o Linearne promjene nad podacima prema odreenim formulama vrlo su
teko izvedive. Istovremeno dohvaanje podataka iz razliitih datoteka
na temelju definiranih spojnih toaka izvodi se esto sekvencijalno s
definiranim formulama ispada (izbaaja) i neobuhvaanja.
-

Nedovoljna sigurnost i zatita

o Podaci su spremljeni u datoteci kojoj program direktno pristupa.
Operacijski sustav vodi brigu o dostupnosti datoteke odreenim
korisnicima i/ili udaljenim raunalima. Potrebno je mnogo truda kako bi
se natjeralo operacijski sustav da inteligentno osigurava pristup datoteci
samo autoriziranim korisnicima.
o Program s udaljenog raunala direktno pristupa i upravlja podacima na
tzv. posluiteljskom raunalu. U komunikacijskom kanalu mogue su
pogreke ime se moe dogoditi oteenje datoteke u kojoj se nalaze
podaci. Time datoteka postaje neitka za program.

Slabe mogunosti dijeljenja podataka i njihove dostupnosti

o Programi iz razliitih udaljenih raunala pristupaju datoteci na tzv.
posluiteljskom raunalu. Kako oba programa direktno koriste bit i bajt
13

strukturu datoteke za itanje i pisanje, tako isti programi moraju biti

dovoljno pametni da prepoznaju i itaju promjene koje je izradio onaj
drugi. to ako jednoj datoteci pristupa vie od dva razliita programa na
razliitim udaljenim raunalima?
o Prilikom auriranja podataka u datoteci program obino ostavlja
odreene oznake na za to namijenjenom mjestu. Drugi program
razumije postavljene oznake o promjenama i time dobiva informaciju da
se neto dogodilo u podatkovnom sadraju. Kako do takve informacije
dolazi itanjem oznaka, tako datoteka treba biti neprestano otvorena za
itanje i pisanje.
-

Relativno spor odziv

o Datoteke koje sadre mnogo podataka (mnogo slogova) su velike sa
stanovita zauzetih bajta na disku. Program direktno pristupa datoteci i
iz nje ita i u nju direktno pie. Kako bi program uvijek imao zadnje
stanje podataka u datoteci, tada ih program mora moi brzo proitati.
Vea koliina bajta tee e proi kroz komunikacijski kanal (lokalna
mrea, internet).
o ak i u stanju mirovanja, kada korisniki program ne aurira datoteku, a
niti ne ita iz nje, komunikacija programa s podacima djeluje.
Transportiraju se podaci u svom bajt obliku, sve zbog mogunosti da
drugi korisniki programi promijene podatke.

14

Na slici je shematski prikazana organizacija podataka i koritenje od strane

programa.

15

6. BAZA PODATAKA
Baza podataka je organizirani elektroniki skup podataka, pripremljen tako da
se moe jednostavno koristiti. To znai da se podaci u bazi podataka mogu
jednostavno koristiti, pregledavati, pretraivati, sortirati, usporeivati, te takoer,
mijenjati, dodavati i brisati. Podaci su u bazi podataka pohranjeni i sustavno
upravljani. Zalihost (redundancija) je u bazi podataka svedena na minimum.

6.1. DBMS
Bazom podataka upravlja Sustav za Upravljanje Bazama Podataka (SUBP)
eng. Database Management System (DBMS). DBMS je program koji kreira podatke i
kontrolira pristup podacima u bazi podataka. DBMS omoguava poslovnim
aplikacijama raznovrstan dohvat podataka. DBMS je neovisan o platformi na kojoj se
koristi, te neovisan o raunalnom programu (poslovnoj aplikaciji) koji ga koristi.
DBMS omoguuje korisniku ili programeru poznavanje logike strukture
podataka i logiki pogled na podatke. On interno vodi brigu o fizikoj lokaciji
podataka na disku i tehnologiji njihove pohrane i dohvaanja, odnosno razumijeva
fiziki pogled na podatke. Korisnik (krajnji ili programer) ne moe dobiti informaciju o
fizikoj organizaciji podataka, no to mu nije niti potrebno.
U nastavku emo pokazati neke koristi DBMS-a:

Centraliziran nain kreiranja i definiranja baze podataka na temelju

stvorenog modela podataka izgrauje se fizika baza podataka koritenjem
DBMS-a i u njemu definiranim korisnikim jezikom (DDL). Baza podataka
moe se kreirati iskljuivo koritenjem DDL-a. Ne postoje drugi naini
kreiranja baze podataka koja bi bila itljiva iz DBMS-a. Ne postoje tzv. back
door naini definiranja baze podataka.

Smanjivanje zalihosti i nekonzistentnosti podataka prilikom stvaranja

baze podataka stvaraju se i posebne vrste ogranienja nad podacima (tip
podataka, skup vrijednosti, reference). Podaci su meusobno povezani
referencama, a sve sukladno definiranom modelu podataka. Redundancija
je svedena na minimum. Korektnost podataka i korektnost informacije

16

dobivene

povezivanjem

podataka

osigurava

se

referencijalnim

integritetom.

Smanjivanje ovisnosti programa o podacima bazom podataka

upravlja DBMS. Razliiti programi mogu pristupiti DBMS-u i na semantikoj
razini upravljati podacima. Programima je doputena manja koliina
pameti jer ne trebaju poznavati gdje i kako su podaci smjeteni i kako ih
dohvatiti. Program treba znati to dohvatiti, i to je sve.

Smanjivanje kompleksnosti zbog prethodnog program ne treba imati

takve procedure i funkcije koje poznaju gdje su smjeteni i kako su fiziki
spremljeni podaci. Time su programi manje sloeni. Jezik za dohvaanje
podataka DQL podrava DBMS i moe izvravati i neke sloenije vrste
upitivanja kojima se mogu prezentirati podaci u razliitim oblicima i time
stvarati informacije. Time je jedan dio programske podrke prebaen na
DBMS.

Smanjenje trokova razvitka i odravanja baze podataka zbog manje

kompleksnosti potrebno je napisati manje kodnih linija programa, a time se
umanjuju trokovi. Promjene nad podacima izvedive su upitnim jezikom
nad DBMS-om. DDL i DML su dvije vrste DBMS pristupnog jezika koje se
koriste u te svrhe. DBMS na svojoj unutranjoj razini vodi brigu o
podacima, pa je potrebno uloiti manje truda za odravanje baze podataka.

Poveanje dohvata i raspoloivosti podataka Kada program dohvaa

podatke, tada on samo dobiva sliku podataka prikazanu u obliku tablice i to
najee u tekstualnom obliku. Korisniki program ne moe biti uzrok
nedostupnosti podataka. Korisniki program ne moe otetiti itljivost
podataka.

Samo

DBMS

operacijski

sustav

mogu

biti

uzrokom

nedostupnosti podataka.

Poveanje fleksibilnosti sustava zbog svega navedenog jednostavno

je zakljuiti da su programi koji se slue DBMS-om za auriranje i itanje
podataka znatno fleksibilniji od tradicionalno organiziranih korisnikih
programa.

17

Na slici je shematski prikazan pristup podacima koritenjem DBMS-a.

DBMS treba posjedovati standardizirani pristupni jezik od strane programa (poslovnih

aplikacija) kako bi im se omoguilo itanje i pisanje podataka u bazi. Pristupni jezik
treba sadravati naredbe koje se mogu podijeliti u sljedee kategorije:
-

DD (Data Dictionary)

DDL (Data Definition Language)

DML (Data Manipulation Language)

DQL (Data Query Language)

6.1.1. DD (Data Dictionary rjenik podataka)

Sadri informacije o strukturi baze i svim podacima u njoj. Takoer sadri
informacije o tipovima podataka, vezama meu njima i ogranienjima nad podacima.
Obino se DD naredbe na DBMS-u koriste na poetku izrade baze kako bi se utvrdilo
postojee stanje baze podataka. Mogui rezultati koje mogu dati naredbe poslane
DBMS-u od strane korisnikog programa su izvjea koja je DBMS pripremio i
dostavio korisnikom programu. Vrste takvih DBMS izvjetaja su:
-

izlistavanje programa u kojima se koriste pojedini podaci

prikaz spremljenih procedura koje koriste odreene podatke

popis svih sinonima podataka u pojedinim tablicama

18

organizaciju podataka u tablicama

ogranienja nad podacima

veze meu podacima

6.1.2. DDL (Data Definition Language jezik za stvaranje tipova

podataka)
DDL naredbe DBMS-u slue za stvaranje kostura, okvira baze podataka. To
ukljuuje stvaranje tablica s atributima i vezama u koje e se zapisivati podaci.
Atributi u tablicama su tipovi podataka. Tipovi podataka predstavljaju ormare u koje
e se spremati podaci - koulje. DDL treba sadravati naredbe za:
-

izradu rjenika podataka

dizajniranje i kreiranje baze podataka

opis logikih struktura podataka veze meu podacima

specificiranje ogranienja nad tipovima podataka

specificiranje sigurnosnih mehanizama.

U nastavku je prikazan pseudokod DDL naredbe prema DBMS-u:

CREATE TABLE STUDENT (
IME:

CHARACTER(8) NOT NULL UNIQUE

PREZIME:

CHARACTER(16) UNIQUE

JMBG:

NUMBER(5) AUTONUM PRIMARY

SPOL:

CHARACTER(1) VALUES(M,)

DAT_UPI:

DATE NO DUPLICATE

GRAD:

CHARACTER(24) FOREIGN(GRADOVI.GRAD)

PLACENO: DECIMAL(7,2)
)
ili
ALTER TABLE STUDENT ADD ATTRIBUTE BODOVA NUMBER(2)
ili
ALTER TABLE STUDENT DROP ATTRIBUTE SPOL

19

Iz prikazanih naredbi vidi se da DDL jezik treba sadravati elemente kojima e se

definirati:
-

atributi u koje e se spremati podaci

tip podataka za svaki atribut metodu zapisivanja i itanja podatka

karakteristike vrste podataka

oznaka obaveznosti

oznaka automatske inkrementacije (uveanja za 1)

doputeni skup vrijednosti

repozitorij vrijednosti za vrijednosti u atributu

primarni jedinstveni identifikator

dodatni jedinstveni identifikatori.

Za sve navedene definirane elemente treba omoguiti da se naknadno dodaju,

modificiraju i briu.

6.1.3. DML (Data Manipulation Language jezik za manipuliranje

podacima)
DML se koristi za auriranje podataka. DML treba sadravati naredbe koje e
izvravati sljedee obaveze:
-

promjene nad podacima kao dijelovima baze podataka

unos novih podataka u bazu

brisanje podataka iz baze.

Prikaz pseudokod DML naredbe za unos podataka:

INSERT INTO STUDENT
(JMBAG, IME, PREZIME)
VALUES
(1712347810234, IVO, IVI),
(7819267265431, ANA, ANI)

20

DML Insert naredba treba sadravati sljedee mogunosti:

-

upis novog reda u tablicu

upis vie redova u jednoj akciji

upisivanje vrijednosti samo za odreene atribute u tablici.

Prikaz pseudokod DML naredbe za izmjenu podataka:

UPDATE STUDENT
SET

ULICA = 'Nova ulica 11'

GRAD = 'Dubrovnik'
REDBR = REDBR+1

WHERE JMBAG = '2424000345'

DML Update naredba treba sadravati sljedee mogunosti:
-

izmjenu podataka u redu tablice

prilikom izmjene vrijednosti atributa moe koristiti vrijednosti drugih atributa

izmjenjivanog reda

izmjenu vrijednosti na samo odreenim atributima reda

izmjenu podataka nad vie redova u jednoj akciji.

Prikaz pseudokod DML naredbe za brisanje podataka:

DELETE FROM STUDENT
WHERE JMBAG = '2424000345'
DML Delete naredba treba sadravati sljedee mogunosti:
-

brisanje reda iz tablice

brisanje vie razliitih redova u jednoj akciji.

6.1.4. DQL (Data Query Language podatkovni upitni jezik)

DQL se koristi za itanje i obradu podataka iz baze. DQL ita, sortira,
pretrauje i prezentira sadraj dohvaen iz baze podataka, a na temelju korisnikovih
upita. DQL upitnim jezikom podaci se mogu samo itati iz baze. Prilikom itanja
podaci se prezentiraju uvijek u obliku dvodimenzionalne tablice. Dobivena tablica
21

prezentira podatke iz baze sortirane po eljenom redoslijedu. Takoer pokazuje

samo odabrane podatke. Moe pokazivati podatke iz razliitih tablica istovremeno.
Upit prema bazi za dohvaanje odreenih podataka ima cilj stvoriti novu
informaciju na temelju dobivenih rezultata upita. Novu informaciju e osoba koja je
poslala upit shvatiti kao ishodite za odreeno djelovanje.
Pseudokod DQL naredbe:
SELECT IME, PREZIME, OCJENA, SUM(IZNOS)
FROM STUDENT
JOIN STUD_PLACANJA ON STUDENT.ID = STUD_PLACANJA.ID
WHERE GOD_UPISA < 2007/08
GROUP BY IME, PREZIME
ORDER BY SPOL DESCENDING
DQL naredba treba sadravati sljedee mogunosti:
-

prikaz podataka

odabir samo odreenih

sortiranje prema zahtjevu

prikaz podataka iz razliitih izvora (tablica)

grupiranje podataka

obraivanje podataka za prikaz.

22

6.2. SQL
Cilj standardiziranog pristupnog jezika je stvoriti pravila kojih se treba
pridravati kod stvaranja pitanja raunalu za dobivanjem odreenih podataka koji
mogu dati odreenu informaciju, a koja ima za posljedicu provoenje odreene
aktivnosti.
Takav upitni jezik zove se: SQL Structured Query Language, standardizirani
upitni jezik za manipulaciju podacima koji se nalaze pohranjeni u bazi podataka. U
SQL-u su integrirani i dostupni svi elementi koji su u teoriji zahtjevni pristupnim
jezikom u bazi podataka.
SQL je zaet u IBM-u 70-ih godina pod nazivom SEQUEL. SEQUEL je bio
dizajniran za upravljanje podacima i njihovim pronalaenjem. SQL do 80-ih godina
nije komercijalno razvijan zbog slabih karakteristika tadanjih raunala. Do kraja 80ih godina razvilo se nekoliko desetaka razliitih komercijalnih SQL sustava. Sa
stanovita korisnika velika razliitost meu njima dovela je do potrebe standardizacije
upitnog jezika. ANSI (American National Standards Institute) i ISO (International
Standards Organizations) objavile su 1989. prvu inaicu standarda pod nazivom
SQL-89. Ve 1992. objavljen je SQL-2 standard, te 1999. SQL-3 standard.
Danas se SQL jo uvijek razvija iako je ve na vrlo zavidnom stupnju razvoja.
Svi vodei proizvoai DBMS sustava implementirali su standard u svoja DBMS
rjeenja.

23

7. VEZE I MODEL PODATAKA

7.1. TIPOVI VEZA
U procesu modeliranja podataka vano je poznavati mogue tipove
povezanosti meu podacima. Tipovi veza se prema kardinalnosti mogu podijeliti na:
1. Tip veze 1 prema 1
2. Tip veze 1 prema vie
3. Tip veze vie prema vie.

7.1.1. TIP VEZE 1 PREMA 1

Tip veze 1 prema 1 (1:1) prikazuje takvu vrstu povezivanja podataka kojom se
za odreeni podatak moe definirati samo jedna vrijednost u drugom podatku. Time
se onaj prvi podatak dodatno opisuje, objanjava, obogauje novim svojstvima.
Objekt na lijevoj strani veze moe predstavljati i vie atributa koji su svi u vezi 1:1. U
tom sluaju takav je objekt tip entiteta. Veza 1:1 oznaava da e se za jednu pojavu
vrijednosti na lijevoj strani veze dogoditi jedna pojava vrijednosti na desnoj strani
veze i obrnuto. Obino se tipom veze 1:1 prikazuju veze izmeu tipa entiteta i
njegovih pripadnih atributa i specijalne veze izmeu dva razliita tipa entiteta.

24

7.1.2. TIP VEZE 1 PREMA VIE

Tip veze 1 prema vie (1:M) prikazuje takvu vrstu povezivanja podataka kojom
se za odreeni podatak moe definirati vie vrijednosti u drugom podatku. Prvi
podatak se dodatno opisuje pripadnim vrijednostima u drugom podatku. Veza 1:M se
prepoznaje tako to su vrijednosti u drugom podatku jednakog tipa i objanjavaju
jednaku osobinu (svojstvo). Ako postoji takva veza meu podacima tada se takvi
podaci grupiraju u cjelinu i ine tip entiteta koji je s prvim podatkom (obino tipom
entiteta) povezan vezom M:1.

7.1.3. TIP VEZE VIE PREMA VIE

Tip veze vie prema vie (M:M) prikazuje mogunost povezivanja vie
vrijednosti prvog tipa podataka s vie vrijednosti drugog tipa podataka. Ako postoje
takve ovisnosti meu podacima, tada se sve vrijednosti prvog podatka grupiraju i ine
entitete u tipu entiteta. Isto tako se vrijednosti drugog podatka grupiraju i ine entitete
u drugom tipu entiteta. Tada su tipovi entiteta povezani specijalnim tipom veze M:M.
25

Takav tip veze ne moe egzistirati u objektivnoj stvarnosti. Ne znai da svaki

entitet prvog tipa entiteta treba povezati (dodatno opisati) s vrijednostima po svim
entitetima drugog tipa entiteta. Ako u odnosu meu podacima postoji takav tip M:M
veze, tada se za njega stvara dodatni tip entiteta meu dva povezana tipa i on ini
agregirani tip entiteta koji je vezama M:1 povezan s izvorinim tipovima entiteta. Time
e se postii samo specifino povezivanje vrijednosti prvog entiteta sa specifinim
vrijednostima drugog entiteta.

7.2. MODELI PODATAKA

Apstraktni prikaz sadraja baze podataka. Model podataka ne pokazuje
podatke ve njihovu organizaciju i strukturu. On takoer prikazuje odnose meu
tipovima podataka. Modelom podataka stvara se logika struktura podataka i pravila
povezivanja meu podacima, a isto tako i pretpostavka za logino itanje podataka.
Neki tipovi modela podataka:

hijerarhijski

mreni

relacijski

objektni

7.2.1. HIJERARHIJSKI MODEL

26

Hijerarhijski model prikazuje dekomponiranje podataka po granama. Razine

dekompozicije prikazane su na lijevoj strani slike (djed, otac, sin, unuk). Postupak
dekomponiranja naziva se specijalizacija. Ako se model promatra obrnutim
redoslijedom tada je s udaljene grane mogue doi do korijena. Takav postupak
naziva se generalizacija.
U modelu se najee koriste 1:1 i 1:M tipovi veza.
Ponekad postoje i logike veze meu podacima u razliitim granama (npr.
moda postoji logika veza izmeu Fakultativne i Ispiti). Takvu vezu ovim
modelom nije mogue pokazati. Hijerarhijski model je relativno krut sa stanovita
moguih povezivanja podataka. Iako postoje logike veze meu podacima na
razliitim granama, njih nije mogue dodatno povezati. Podaci su jedino povezani
preko korijena.

7.2.2. MRENI MODEL

Mrenim modelom mogue je povezati bilo koji tip podataka s bilo kojim
drugim, no ne znai da uistinu postoji prava logika veza meu povezanim
elementima. Moda nije korektno da su svi elementi u prikazanom modelu na takav
nain povezani.

27

Mreni model podataka je pomalo preotvoren. Ne postoje pravila povezivanja.

Ne postoje definirani mogui odnosi meu podacima. Pravila uvanja konzistentnosti
podataka nisu mogua. Izgradnja sustava koji bi pohranjivao podatke povezane na
temelju mrenog modela trebao bi imati sloene algoritme kojima bi se uvala
konzistentnost podataka. Takav model ne moe ivjeti u realnom svijetu.
U mrenom modelu mogua su sva tri tipa povezivanja: 1:1, 1:M i M:M.

7.2.3. RELACIJSKI MODEL

Eng. Relational Data Model.

Svi podaci koji e se spremati u bazu podataka mogu se prikazati u obliku
tablica, i to ne bilo kakvih, nego u obliku potpunih dvodimenzionalnih tablica.
Relacijski model za ouvanje konzistentnosti meu podacima koristi se
relacijskom algebrom. U relacijskoj algebri djeluju relacijski operatori kojima se
osigurava dohvat i konzistentno skladitenje podataka, obrada podataka te dobivanje
novih informacija.

28

Svaka tablica tehniki se naziva relacija. Tablica se sastoji od:

1. Naziva naziv sheme relacije
2. Stupaca atributi
3. Reda slog
4. Redova relacija
5. Referenci veze meu atributima razliitih tablica.
Relacijski model podataka ne sadri takvu relaciju koja nije u vezi niti s jednom
drugom. Drugim rijeima, relacijski model podataka sadri relacije (tablice) koje su
meusobno povezane referencama. Svaka relacija je u vezi s barem jednom drugom
relacijom.

7.2.4. OBJEKTNI MODEL

Objektni model podataka logino se naslanja na relacijski model podataka s
dodacima preuzetim iz objektno orijentiranih pristupa. Tako se relacijski model moe
nadograditi novim sljedeim elementima:
-

tipovi podataka

metode

klase.

Tipovi podataka karakteristini za objektne modele podataka ukljuuju razliite

binarne tipove koji mogu interpretirati slike, videozapise, originalne tekstualne ili na
neki nain formatirane datoteke. Veina dananjih DBMS sustava omoguuje takvu
pohranu podataka u svojevrsne BLOB (Binary Large Object) tipove podataka. Postoji
problem interpretacije takvih binarnih sadraja koji se jo uvijek interpretiraju na razini
klijentskog programa koji pristupa bazi i ita podatke. Problem je isto tako u veliini
takvih BLOB tipova podataka jer DBMS svojim definiranim postavkama omoguuje
odreenu veliinu upita (query buffer) koji ovim BLOB podacima moe biti znatno
premaen.
Metode predstavljaju procedure rada i izvoenja odreenih postupaka nad objektima
u modelu. Metode se pohranjuju na strani DBMS sustava i DBMS vodi brigu o
njihovom korektnom izvoenju. Metode izvode promjene nad podacima, a definirane
su poslovnim pravilima i odnosima meu podacima.
29

Klase prikazuju odreenu vrstu grupiranja objekata modela nad kojima djeluju
jednake metode koje pospjeuju dinamiku. Razliiti objekti mogu pripadati klasama.
Klase posjeduju metode i svojstva kojima se upravlja promjenama nad podacima i
osigurava integritet i konzistentnost podataka. Objekti tada nasljeuju (inheritance)
metode i svojstva i obogauju ih svojim specifinim metodama i svojstvima
(podacima).

8. XML
XML (Extensible Markup Language) je jezik za oznaavanje podataka. XML
predstavlja nain spremanja podataka koji bi bio jednostavan za itanje i ljudima i
raunalu. Sintaksa XML-a vrlo je slina HTML sintaksi. Podaci se u XML datoteku
zapisuju hijerarhijskom strukturom i vezama. Svi podaci u XML datoteci vidljivi su bilo
kakvim programom koji moe itati tekstualne datoteke. Meutim strukturu XML
datoteke i koliinu sadraja zapisanih u XML datoteci mogue je itati pomou za to
namijenjenih programa.
Ciljevi koji su se htjeli postii uvoenjem XML-a su:
1. mora biti izravno primjenjiv preko interneta
2. mora podravati irok spektar primjena
3. mora biti kompatibilan sa SGML-om
4. treba osigurati lakou pisanja programa koji procesuiraju XML
dokumente
5. broj opcionalnih svojstava u XML dokumentu mora biti minimalan ili
jednak nuli
6. dokumenti trebaju biti itljivi ljudima, te u razumnoj mjeri jednostavni
7. dizajn mora biti brz i jednostavan
8. dizajn mora biti formalan i precizan
9. kreiranje dokumenta mora biti jednostavno
10. oznake u dokumentu se ne smiju izostavljati
Primjer:
<?xml version="1.0" encoding="UTF-8"?>
<poruka>
<za>Ivo</za>

30

<od>Jure</od>
<naslov>Podsjetnik</naslov>
<tijelo>Napii zadau</tijelo>
</poruka>

U zaglavlju dokumenta stoji oznaka da se radi o XML dokumentu te tip kodne

stranice podataka zapisanih u dokumentu. Nakon zaglavlja nanizani su XML
elementi koji su obgrljeni zagradama (< i >). Svaki element mora imati i svoj
zavretak koji je takoer obgrljen zagradama i jednakog naziva kao i poetak s
dodatkom znaka / prije pisanja naziva elementa. Unutar svakog elementa temeljem
hijerarhijske strukture mogue je zapisati druge elemente koji su takoer obgrljeni
zagradama i tako rekurzivno dalje.
Svaki XML element moe imati i svoje atribute, svojstva koja dodatno opisuju taj
element.
Primjer:
<?xml version="1.0" encoding="UTF-8"?>
<poruka>
<za spol=muki vrsta=student>Ivo</za>
<od funkcija=direktor>Jure</od>
<naslov>Podsjetnik</naslov>
<tijelo>Napii zadau</tijelo>
</poruka>

Atributi dodatno opisuju pojedini element, daju elementu dodatna svojstva koja nisu
definirana njegovom vrijednou. Postoje dva temeljna pristupa, odnosno odnosa
prema XML atributima:
1. Pozitivan stav o XML atributima smatra se da se XML atributima moe
dodatno opisati XML element, a time i sprijeiti takav dodatni opis elementa
njegovim podelementima, ime se znatno moe smanjiti nepotrebno
poveavanje hijerarhijske strukture XML dokumenta.
2. Negativan stav o XML atributima smatra se da XML dokument treba biti
ist i ne treba sadravati nikakve XML atribute, ve se svi opisi mogu i
moraju definirati podelementima XML elementa.

31

Neke osobine XML dokumenta:

-

pogodan za migraciju podataka meu razliitim bazama, odnosno razliitim

sustavima

pogodan za sistematinu deskripciju pojava u objektivnoj stvarnosti

jednostavan za itanje

redundantan odreeni podaci u strukturi ponekad se viestruko ponavljaju

zbog njihove iskoritenosti u razliitim elementima

relativno spor pristup i dolazak do odreenog elementa

u potpunosti transparentan

itljiv na svim platformama i na svim programskim jezicima

XML kao standard komunikacije danas ima sve veu primjenu i zasigurno e tako
i ostati. Veina dananjih DBMS sustava posjeduje podrku za stvaranje i itanje
XML dokumenata. Oekuje se jo vea integracija XML-a u DBMS sustave
omoguavanjem klasinih SQL naredbi na XML dokumentima, to danas posjeduju
neki DBMS sustavi.

32

9. FAZE RAZVOJA BAZE PODATAKA

U procesu razvoja baze podataka potrebno je proi kroz est razvojnih faza.
To ukljuuje poetna razmiljanja kao poetak, te zavrnu eksploataciju kao
zavretak.

Slika prikazuje faze ivotnog ciklusa baze podataka. Iz prikazane slike vidi se
da razvoj i rast baze podataka nikada ne staje. Razvoj se vrti u zaaranom krugu.
Kada su svi elementi baze podataka gotovi i uspjeno se koriste, posao nije gotov.
Neto e novo biti potrebno dograditi na postojei sustav. Razvoj nikada nije zavren.
I kad sve izgleda tako da je posao zavren, pojavit e se zahtjev koji e traiti
dodatnu funkcionalnost koja nije podrana postojeom bazom.
U nastavku e biti pojedinano objanjena svaka faza razvoja baze podataka.
1. Planiranje
U procesu planiranja definiraju se potrebe i mogunosti za sustavom
baze podataka (SBP). Pristupa se objektivnoj analizi tehnoloke i
ekonomske izvedivosti. Definiraju se ciljevi koji se trebaju postii
izgradnjom SBP-a.

33

2. Analiza potreba
Identifikacija potreba krajnjeg korisnika. Definiranje podruja vanosti
novog SBP-a. Definiranje osnovnih potreba za strojnom i programskom
osnovicom. Odabir odgovarajueg DBMS sustava koji e podrati
potrebe.
3. Dizajniranje
Definiranje strukture i koncepata izrade baze podataka. Provodi se kroz
konceptualni dizajn i fiziki dizajn.
Konceptualni dizajn apstrakcija podataka u modelu podataka,
grupiranje podataka i stvaranje objekata, povezivanje elemenata u
modelu podataka.
Fiziki dizajn detaljno modeliranje baze podataka, stvaranje
relacijskog modela podataka, provoenje normalizacije, detaljno
specificiranje strojne i programske opreme za uspjeno funkcioniranje
baze podataka.
4. Izgradnja
Prevoenje sheme baze podataka (relacijskog modela) u stvarnu
strukturu u odabranom DBMS-u, izgradnja tablica baze podataka na
temelju relacijskog modela, podeavanje ogranienja: primarni klju (PK
primary key), eventualni sekundarni kljuevi (UI unique indeks),
vanjski kljuevi (FK foreign key), ogranienja atributa na listu
vrijednosti.
5. Implementacija
Testiranje rada novog SBP-a, upisivanje ili generiranje testnih
podataka, eventualna migracija postojeih podataka iz stare baze
podataka ili iz datoteka, izobrazba i obuka korisnika za rad i koritenje
novog SBP-a.
6. Koritenje i odravanje
Nadzor rada novog SBP-a, fina regulacija baze podataka, dodatna
customizacija baze podataka, izrada sustavno voenih sigurnosnih
kopija (backup).
Sustav nikada nije gotov, uvijek e postojati neke nove potrebe i
funkcionalnosti. Razmiljanje o novim zahtjevima za nadogradnju SBPa prelazak ponovo u fazu 1.
34

10. CODDOVA PRAVILA

Jo davne 1985. Codd je svojim radom predstavio 12 pravila koje baza
podataka treba podravati kako bi se smatrala pravom relacijskom bazom podataka.
Kako je relacijska baza podataka teoretski postavljena, implementacija njezinih
zakonitosti i pravila oituje se kroz stvaranje i koritenje DBMS sustava.
DBMS je sustav koji se bavi praktinom primjenom i koritenjem teoretskih
postavki relacijskog modela, relacijske algebre i relacijskih operatora.
Vrlo esto se vre usporedbe i dokazivanja zadovoljava li DBMS Coddova
pravila, te mogu li se baze podataka kojima on upravlja nazivati relacijskim bazama
podataka. Neka istraivanja pokazivala su da DBMS treba podrati samo est pravila
da bi se mogao nazvati sustavom koji upravlja relacijskom bazom podataka. Kasnije
se limiti podravanja pravila penju na osam. Danas se moe raspravljati o tome ne
podrava li neki DBMS samo neko od Coddovih pravila. Veina pravila danas je ve
ukljuena u DBMS sustave.
Coddova pravila su:
1. Predstavljanje informacije
2. Obavezna dostupnost
3. Sustavno tretirana null vrijednost
4. Dinamiki online katalog
5. Sveobuhvatni jezik za manipulaciju podacima
6. Auriranje pogleda
7. Visoka razina unosa, izmjene i brisanja
8. Fizika neovisnost podataka
9. Logika neovisnost podataka
10. Neovisnost integriteta
11. Neovisnost distribucije
12. Nesubverzivnost.
U nastavku e biti objanjeno svako navedeno pravilo.

35

1. Predstavljanje informacije
eng. the information rule
Sve informacije u bazi podataka logiki

su

predstavljene

iskljuivo

vrijednostima u relacijama (tablicama). Ne postoji takva informacija koja se moe

proitati iz baze podataka, a da se ne nalazi u nekoj relaciji.
2. Obavezna dostupnost
eng. guaranteed access rule
Svaka vrijednost atributa u relacijskoj bazi podataka mora biti dostupna
pomou imena relacije, vrijednosti primarnog kljua i imena atributa.
Podatak u bazi podataka predstavlja odreenu vrstu opisa neke pojave iz
objektivne stvarnosti. On mora biti dostupan. Dohvatit ga se moe putem imena
relacije kako bi se definiralo tip pojave koji se ita, pomou vrijednosti primarnog
kljua koji definira pojavu odnosno red u tablici i pomou naziva atributa koji govori o
tipu svojstva koje se trai.
3. Sustavno tretirana null vrijednost
eng. systematic treatment of null values
Relacijska baza podataka mora podravati koncept null vrijednosti neovisno o
tipu podataka.
Svaki tip podataka moe primiti null vrijednost. Null vrijednost nije definirana
vrijednost. To je nepoznata vrijednost. Relacijska baza podataka treba sadravati
operatore koji na neki nain mogu tretirati null vrijednost:
-

usporeivanje podataka koji imaju odreenu vrijednost i podataka koji imaju

null vrijednost

sortiranje podataka u to ulaze podaci koji imaju odreenu vrijednost i podaci

koji imaju null vrijednost.

4. Dinamiki online katalog

eng. dynamic online catalog based on the relational model
Struktura baze podataka opisana je u bazi podataka na isti nain kao i obini
podaci. Time autorizirani korisnici jednak DQL jezik mogu primjenjivati na kataloge
kao i na obine podatke.
36

5. Sveobuhvatni jezik za manipulaciju podacima

eng. comprehensive dana sublanguage rule
Relacijska baza podataka mora sadravati jezik koji e podravati:

DD, DDL, DML, DQL

Ogranienja integriteta

Autorizaciju

Transakcijske zahtjeve (begin, commit, rollback).

6. Auriranje pogleda
eng. view updating rule
Svi pogledi koji se teoretski mogu aurirati, moraju se moi aurirati na
sustavnoj razini. Ako relacijska baza podataka dozvoljava stvaranje i koritenje
pogleda na podatke, tada se rezultati koje pokazuje pogled moraju automatizmom na
sustavnoj razini obnavljati ovisno o promjenama koje su se dogodile na bazinim
podacima. Obnavljanje rezultata pogleda ne smije provoditi manualno korisnik ili
administrator.
7. Visoka razina unosa, izmjene i brisanja
eng. high-level insert, update and delete
Manipulacija relacijom kao operandom mora biti mogua ne samo prilikom
pretraivanja podataka, nego i prilikom unosa izmjene ili brisanja.
8. Fizika neovisnost podataka
eng. physical data independence
Aplikacije ili aktivnosti kojima se korisnik koristi za pristup podacima u
potpunosti su neovisni o metodi pristupa podacima i o strukturi i nainu spremanja
podataka na medije.
9. Logika neovisnost podataka
eng. logical data independence
Promjene na relacijama koje su po teoriji doputene ne smiju utjecati na nain
pristupa podacima od strane aplikacija i korisnika.

37

10. Neovisnost integriteta

eng. integrity independence
Ogranienja na integritet ne smiju biti dio aplikacije, nego moraju biti sadrana
u katalozima baze podataka.
11. Neovisnost distribucije
eng. distribution independence
Bez obzira podrava li sustav distribuciju baze podataka ili ne, jezik sustava
mora biti takav da podrava distribuciju bez utjecaja na aplikativne programe. Kod
promjene i nadogradnje DBMS jezgre (DBMS programa) aplikativni programi i dalje
moraju biti funkcionalni downlevel kompatibilnost DBMS-a.
12. Nesubverzivnost
eng. nonsubversion rule
Ako sustav podrava nii jezik za upravljanje podacima, ne smiju se zaobii
pravila integriteta postavljena relacijskim jezikom. U DBMS-u ne smije postojati takav
jezik koji e dozvoliti back-door pristup podacima, te dozvoliti auriranje podataka i
ne voditi rauna o definiranim pravilima integriteta meu podacima.

38

11. RELACIJSKA TEORIJA

11.1. SHEMA RELACIJE, SLOG, RELACIJA
Slika prikazuje primjer sheme relacije, sloga i relacije.

SHEMA RELACIJE
Shema relacije je konaan neprazan skup atributa. Sastoji se od imena i
popisa atributa. Shema relacije (pojavnost) definira tipove podataka smjetene tako
da tvore logiku cjelinu koja e moi jednoznano opisivati odreenu pojavu. Shema
relacije treba biti dovoljno dobra da moe razlikovati stvarne pojave opisane pomou
atributa sheme.
Matematiki prikaz: R={A1, , Ak,} gdje je:
R naziv sheme relacije
A1, A2, A3, , Ak svaki pojedini atribut sheme
Primjer: Partner (Matini broj, Naziv, Adresa, Grad, Telefon)

39

SLOG
Slog predstavlja maksimalno jednu definiranu vrijednost po svakom atributu
sheme. Slog je pojava iz objektivne stvarnosti zapisana u bazi pomou vrijednosti
svakog pojedinog atributa koji nosi odreeni semantiki tip vrijednosti.
Primjer: (123, Veleuilite, Vukovarska 1, Rijeka, 051/123-456)
RELACIJA
Skup slogova koji pripadaju istoj shemi relacije. Skup zapisanih pojava koje
sve zajedno pripadaju jednoj pojavnosti. Relacija je uvijek definirana nad nekom
shemom relacije. Relacija se moe prikazati tabelarno tada se moe rei da je
relacija = tablica.
Relacija sadri uvijek konaan broj slogova. U teoriji relacija moe primiti
beskonano () slogova. Praksa je limitirana kapacitetima na mediju/ima. U svakom
trenutku poznato je koliko slogova se nalazi u relaciji.
Prazna relacija je ona relacija koja nema niti jedan slog. Nije prazna relacija
ona koja nema niti jedan atribut, jer time ne bi bilo zadovoljeno pravilo da je relacija
definirana nad nekom shemom relacije.

11.2. RELACIJSKA ALGEBRA

Relacijska algebra sadri poznate relacijske operatore. Ona je nadogradnja na
tradicionalnu algebru koja djeluje nad skupovima. Doraeni su i operatori. Relacijska
algebra djeluje u dvodimenzionalnom prostoru pa time i relacijski operatori trebaju biti
dvodimenzionalno definirani.
Relacijski operatori djeluju nad jednom ili dvije relacije. Mogu biti: unarni i
binarni. Unarni operatori su oni koji djeluju nad jednom relacijom i njezinom
pripadnom shemom. Binarni operatori su oni koji djeluju nad dvije razliite relacije s
jednakim ili razliitim shemama.
VANO koritenjem relacijskih operatora stvara se nova relacija sa svojom
pripadnom shemom. Dobivena relacija nastala je obradom bazinih relacija. Nova
relacija sadri samo odreene podatke (atribute) iz traenih izvora (relacija). Time se
stvara nova semantika vrijednost, a time i informacija.

40

Operatori se prema mjestu nastanka mogu podijeliti na:

1. naslijeene relacijske operatore
2. osnovne relacijske operatore
3. izvedene relacijske operatore.

11.2.1.

NASLIJEENI RELACIJSKI OPERATORI

Svi naslijeeni relacijski operatori su binarni i djeluju nad dvije razliite relacije
jednakih shema. Naslijeeni operatori su preuzeti iz algebre nad skupovima i
obogaeni relacijskim definicijama. Tako su preuzeta pravila operiranja nad jednom
dimenzijom i to slogovima (redovima) koji ine relaciju. Shema relacije nad kojom
djeluje naslijeeni relacijski operator jednaka je za obije relacije. Naslijeeni relacijski
operator ne moe se izvoditi nad razliitim relacijama razliitih shema.

Unija ()
Postoje dvije relacije jednakih shema r(R) i s(R).
Rezultat provoenja:
-

stupci - svi atributi preuzeti iz bilo koje relacije jer su im sheme jednake

redovi - skup svih slogova koji su u relaciji r ili u relaciji s

Kupci

Dobavljai

M. br.

Naziv

Adresa

Grad

Telefon

M. br.

Naziv

Adresa

Grad

Telefon

12345

Veleuilite

Vukovarsk
a1

Rijeka

051/111-222

77564

Hrvatske
ume

umska
15

Zagreb

01/11-22-334

33215

3. maj

Rijeka 17

Rijeka

33-22-11

99115

Filozofski
fakultet

Uenika
15/IV

Dubrov
nik

+385 21 337891

77564

Hrvatske
ume

umska
15

Zagreb

01/11-22-334

38912

P.E.R.O.
d.o.o.

Neka ulica
11

Pula

052/11-44-78

Kupci Dobavljai
Partneri
MB

Naziv

Adresa

Grad

Telefon

12345

Veleuilite

Vukovarska 1

Rijeka

051/111-222

33215

3. maj

Rijeka 17

Rijeka

33-22-11

77564

Hrvatske ume

umska 15

Zagreb

01/11-22-334

99115

Filozofski fakultet

Uenika 15/IV

Dubrovnik

+385 21 337-891

38912

P.E.R.O. d.o.o.

Neka ulica 11

Pula

052/11-44-78

41

Presjek ()
Postoje dvije relacije jednakih shema r(R) i s(R).
Rezultat provoenja:
-

stupci - svi atributi preuzeti iz bilo koje relacije jer su im sheme jednake

redovi - skup svih slogova koji su u relaciji r i u relaciji s

Kupci

Dobavljai

MB

Naziv

Adresa

Grad

Telefon

MB

Naziv

Adresa

Grad

Telefon

123456

Veleuilite

Vukovarsk
a1

Rijeka

051/111-222

775642

Hrvatske
ume

umska
15

Zagreb

01/11-22-334

332156

3. maj

Rijeka 17

Rijeka

33-22-11

991155

Filozofski
fakultet

Uenika
15/IV

Dubrov
nik

+385 21 337891

775642

Hrvatske
ume

umska
15

Zagreb

01/11-22-334

389125

P.E.R.O.
d.o.o.

Neka ulica
11

Pula

052/11-44-78

Kupci Dobavljai
Partneri samo oni koji su i kupci i dobavljai
MB

Naziv

Adresa

Grad

Telefon

775642

Hrvatske ume

umska 15

Zagreb

01/11-22-334

Razlika (-)
Postoje dvije relacije jednakih shema r(R) i s(R).
Rezultat provoenja:
-

stupci - svi atributi preuzeti iz bilo koje relacije jer su im sheme jednake

redovi - skup svih slogova koji su u relaciji r i nisu u relaciji s

r-s s-r

42

Kupci

Dobavljai

MB

Naziv

Adresa

Grad

Telefon

MB

Naziv

Adresa

Grad

Telefon

123456

Veleuilite

Vukovarsk
a1

Rijeka

051/111-222

775642

Hrvatske
ume

umska
15

Zagreb

01/11-22-334

332156

3. maj

Rijeka 17

Rijeka

33-22-11

991155

Filozofski
fakultet

Uenika
15/IV

Dubrov
nik

+385 21 337891

775642

Hrvatske
ume

umska
15

Zagreb

01/11-22-334

389125

P.E.R.O.
d.o.o.

Neka ulica
11

Pula

052/11-44-78

Kupci - Dobavljai
Kupci samo oni koji nisu dobavljai
MB

Naziv

Adresa

Grad

Telefon

123456

Veleuilite

Vukovarska 1

Rijeka

051/111-222

332156

3. maj

Rijeka 17

Rijeka

33-22-11

43

11.2.2.

OSNOVNI RELACIJSKI OPERATORI

Osnovni relacijski operatori definirani su unutar relacijske algebre. Stvorena su

nova pravila operiranja nad relacijskim skupovima. Postoje unarni i binarni osnovni
relacijski operatori.
Projekcija ()
Izvodi se nad jednom relacijom i njenom pripadnom shemom.
Rezultat provoenja:
-

stupci odabrani atributi iz sheme osnovne relacije, atributi mogu biti samo iz
osnovne relacije

redovi svi slogovi iz osnovne relacije

Partneri
MB

Naziv

Adresa

Grad

Telefon

123456

Veleuilite

Vukovarska 1

Rijeka

051/111-222

332156

3. maj

Rijeka 17

Rijeka

33-22-11

775642

Hrvatske ume

umska 15

Zagreb

01/11-22-334

991155

Filozofski

Uenika

Dubrovnik

+385 21 337-891

389125

P.E.R.O. d.o.o.

Neka ulica 11

Pula

052/11-44-78

Iz relacije partneri prikazati samo naziv i grad

Naziv, Grad(Partneri) - Sjedita partnera
Naziv

Grad

Veleuilite

Rijeka

3. maj

Rijeka

Hrvatske ume

Zagreb

Filozofski fakultet

Dubrovnik

P.E.R.O. d.o.o.

Pula

44

Selekcija ()
Izvodi se nad jednom relacijom i njenom pripadnom shemom. Prikazuje
slogove iz osnovne relacije, s time da postoji formula F koja treba biti zadovoljena
kako bi slog bio pokazan.
Rezultat provoenja:
-

stupci svi atributi iz osnovne sheme relacije

redovi slogovi osnovne relacije kojima je formula istina. Oni slogovi koji su
zadovoljili uvjet zadan u formuli.

Partneri
MB

Naziv

Adresa

Grad

Telefon

123456

Veleuilite

Vukovarska 1

Rijeka

051/111-222

332156

3. maj

Rijeka 17

Rijeka

33-22-11

775642

Hrvatske ume

umska 15

Zagreb

01/11-22-334

991155

Filozofski

Uenika 15/IV

Dubrovnik

+385 21 337-891

389125

P.E.R.O. d.o.o.

Neka ulica 11

Pula

052/11-44-78

Iz relacije Partneri prikazati samo one koji su iz Grada Rijeka

Grad=Rijeka(Partneri) partneri samo iz Rijeke
MB

Naziv

Adresa

Grad

Telefon

123456

Veleuilite

Vukovarska 1

Rijeka

051/111-222

332156

3. maj

Rijeka 17

Rijeka

33-22-11

45

Prirodni spoj ()
Prirodni spoj je binarni operator i djeluje nad dvije relacije s dvije razliite
sheme. Moe se rei da je to pridruivanje s izjednaavanjem. Svi zajedniki atributi,
dakle oni atributi koji ine presjek shema, izjednaavaju se po vrijednostima u
slogovima. Svaki slog u prvoj relaciji pokuava se izjednaiti preko zajednikih
atributa sa svakim slogom iz druge relacije. Ako je to mogue, tada slogovi stvaraju
slog nove relacije.
Rezultat provoenja:
-

stupci svi atributi koji su u jednoj i u drugoj shemi, dakle R S

redovi svi slogovi koji su iz prve i druge relacije izjednaeni na zajednikim

atributima.

Ako se spojenoj relaciji promatra projekcija na skup atributa prve relacije, tada svi
dobiveni slogovi jesu iz prve relacije. Isto vrijedi i za drugu relaciju.

Artikli centrale
ifra

Artikli maloprodaje

Naziv

Jedinica

artikla

Dob. ifra

mjere

Plan.

ifra

cijena

artikla

Naziv

Barcode

Plan.

Stanje

cijena

001

Coca Cola

KOM

CC1L-005

15,00

002

Prut

38635687

190,15

150,01

005

Rakija

LIT

007

33,50

001

Coca Cola

38566833
4112

15,00

200

002

Prut

KG

Pr-Slav-15

190,15

005

Rakija

876432

33,50

8,5

Artikli centrale Artikli maloprodaje

Spojeni artikli
ifra artikla

Naziv

Jedinica

Dobavljaeva ifra

mjere

Planska

Barcode

cijena

001

Coca Cola

KOM

CC1L-005

005

Rakija

LIT

007

002

Prut

KG

Pr-Slav-15

stanje

15,00

385668334112

33,50

876432

190,15

Trenutno

38635687

200
8,5
150,01

46

Preimenovanje ()
Koristi se za preimenovanje atributa. Operator preimenovanja je unaran, izvodi
se nad jednom relacijom i njenom pripadnom shemom. Stvara se nova relacija s
novom shemom koja sadri preimenovane atribute.
Rezultat provoenja:
-

stupci odabrani atributi osnovne tablice preimenuju se redom u nove atribute

redovi slogovi iz osnovne relacije, tako da su vrijednosti po atributima koji se

preimenuju iz osnovne relacije dodijeljene novim preimenovanim atributima.

Partneri
Matini broj

Naziv

Adresa

Grad

Telefon

123456

Veleuilite

Vukovarska 1

Rijeka

051/111-222

332156

3. maj

Rijeka 17

Rijeka

33-22-11

775642

Hrvatske ume

umska 15

Zagreb

01/11-22-334

991155

Filozofski fakultet

Uenika 15/IV

Dubrovnik

+385 21 337-891

389125

P.E.R.O. d.o.o.

Neka ulica 11

Pula

052/11-44-78

Preimenovati atribute Matini broj, Grad i Telefon u redom Porezni broj, Sjedite, Kontakt
Partneri novi
Porezni Broj

Naziv

Adresa

Sjedite

Kontakt

123456

Veleuilite

Vukovarska 1

Rijeka

051/111-222

332156

3. maj

Rijeka 17

Rijeka

33-22-11

775642

Hrvatske ume

umska 15

Zagreb

01/11-22-334

991155

Filozofski fakultet

Uenika 15/IV

Dubrovnik

+385 21 337-891

389125

P.E.R.O. d.o.o.

Neka ulica 11

Pula

052/11-44-78

47

11.2.3.

IZVEDENI RELACIJSKI OPERATORI

Izvedeni relacijski operatori djeluju unutar relacijske algebre i njihova primjena

moe se izvesti meusobnim koritenjem naslijeenih i osnovnih relacijskih
operatora.
Produkt ()
Operator produkt je binaran, izvodi se nad dvije relacije i s razliitim shemama.
Predstavlja spoj dviju relacija tako da se svaki slog iz prve spoji sa svakim slogom iz
druge relacije. Novodobivena relacija produktom predstavlja umnoak dviju osnovnih
relacija.
Nain provoenja:
-

ako prva i druga shema relacije nisu u potpunosti disjunktne (imaju barem
jedan zajedniki atribut), tada u jednoj treba izvriti preimenovanje atributa
kako bi se postigla disjunktnost R S =

kad je prethodni zahtjev zadovoljen, dvije relacije spajaju se prirodnim spojem

r s.

Rezultat provoenja
-

stupci svi atributi iz prve i druge sheme R S

redovi svaki slog prve relacije spojen je sa svakim slogom druge relacije,
ukupno ima: broj slogova r * broj slogova s.

Aktivni komplement (AC)

Operator aktivni komplement je unarni operator, djeluje nad jednom relacijom i
njenom pripadnom shemom. Prikazuje mogue veze meu atributima generirajui
nove slogove koji ne predstavljaju niti jedan od moguih slogova u osnovnoj relaciji.
Nain provoenja:
-

projekcija po svakom atributu iz osnovne relacije

prirodni spoj dobivenih projekcija

oduzimanje osnovne relacije od dobivene prirodno spojene relacije.

48

Definicija: AC(r) = [A1(r) An(r)] r

Rezultat provoenja:
-

stupci svi atributi koji ine osnovnu relaciju

redovi permutacije vrijednosti atributa po slogovima osnovne relacije, ali bez

slogova koji ine osnovnu relaciju.

Kvocijent ()
Operator kvocijent je binaran, djeluje nad dvije relacije i s razliitim shemama.
Prikazuje prvu relaciju podijeljenu s drugom, odnosno prikazuje sve slogove iz prve
relacije koji su povezani preko zajednikog atributa sa svim (ne samo nekim)
slogovima iz druge.
Definicija:
-

r s (T), gdje je T = R - S

r s = T(r) - T[(T(r) s) r].

Rezultat provoenja:
-

stupci atributi koji su iz prve sheme, a nisu u drugoj

redovi svi oni slogovi iz prve relacije koji su se mogli spojiti strogo sa svakim
slogom iz druge relacije na zajednikim atributima koji nisu pokazani u novoj
relaciji.

49

11.2.4.

VANJSKO SPAJANJE

Vanjsko spajanje izvodi se pomou operatora prirodnog spajanja. Vanjsko

spajanje je binarno jer djeluje nad dvije relacije s razliitim shemama.
Kada dvije relacije imaju barem jedan zajedniki atribut tada prirodnim
spajanjem nastaje nova relacija koja ima sve slogove iz prve i iz druge relacije koji
imaju na zajednikim atributima jednake vrijednosti. Oni slogovi iz prve relacije koji
nisu mogli na zajednikom atributu biti spojeni niti s jednim slogom iz druge jer takav
ne postoji, nee biti prikazani. Isto vrijedi i za slogove druge relacije u odnosu na
prvu. Takav nain spajanja je unutarnji.
esto postoji zahtjev za vanjskim spajanjem kojim e se prirodno spojiti dvije
relacije, a iz jedne (ili obje) e biti pokazani i svi ostali slogovi koji nisu mogli biti
prirodno spojeni s onom drugom relacijom. Na takvim nespojivim slogovima
vrijednosti atributa, na atributima koji pripadaju drugoj relaciji, bit e null vrijednosti.
Postoje tri naina vanjskog spajanja:
1. lijevo vanjsko spajanje
2. desno vanjsko spajanje
3. potpuno vanjsko spajanje.
Vrsta lijevo, desno ili potpuno (lijevo i desno) oznaava stranu veze iz koje e biti
pokazani svi slogovi, dakle pokazuje iz koje relacije, s koje strane e spajanje biti, a
uz prirodno spojene slogove, pokazani su i ostali slogovi koji nisu spojivi s onom
drugom stranom.

50

11.3. FUNKCIJSKA ZAVISNOST

Funkcijska zavisnost predstavlja odnos meu skupovima. Smatra se da neki
skup X funkcijski ili jednoznano odreuje Y, odnosno da Y zavisi od X, kada vrijedi
da niti jedan element skupa X ne moe biti preslikan u vie od jednog elementa
skupa Y. Ako se skupovi X i Y promatraju kao atributi, tada se moe rei da
vrijednost atributa A funkcijski odreuje atribut B samo tada kada za odreenu
vrijednost atributa A postoji samo jedna vrijednost atributa B u svim slogovima
relacije. Vrijednosti preslikavanja A u B mogu se ponavljati. Dakle, u relaciji se moe
vie puta, u razliitim slogovima, ponoviti jednaka vrijednost atributa A, ali isto tako
vrijednost atributa B uvijek mora biti jednaka u svim slogovima za promatranu
vrijednost atributa A.
Za atribut A kae se da funkcijski odreuje atribut B, odnosno da je atribut B
funkcijski odreen atributom A, kada za svaku pojavu vrijednosti atributa A postoji
maksimalno jedna vrijednost atributa B.
U relaciji je mogue jednostavno provjeriti koje funkcijske zavisnosti postoje.
Potrebno je tablicu sortirati po jednom atributu npr. atributu A, i ako za svaku
vrijednost atributa A postoji maksimalno jedna vrijednost atributa B, tada se moe
rei da funkcijska zavisnost vrijedi u shemi relacije, a ne vie kao pojedinana
funkcijska zavisnost.
Kada funkcijska zavisnost vrijedi u shemi relacije, tada znai da za svaki slog u
relaciji vrijedi pojedinana funkcijska zavisnost.
Definicija funkcijske zavisnosti u shemi relacije:
X Y i to vrijedi u r(R) ako
t1, t2 r (t1[X] = t2[X] t1[Y] = t2[Y]).

51

Primjer:
Rauni
Br. ra

Kupac

Adresa

Sjedite

Pota

Iznos rauna

15

Veleuilite

Vukovarska 1

Rijeka

51000

5.000,00

25

3. maj

Rijeka 17

Rijeka

51000

158,32

17

Veleuilite

Vukovarska 1

Rijeka

51000

356,15

18

Filozofski fakultet

Uenika 15/IV

Dubrovnik

21000

1.298,22

50

P.E.R.O. d.o.o.

Neka ulica 11

Pula

52000

15.862,34

Iz gornje slike vidi se:

-

atribut Pota funkcijski odreuje Sjedite

atribut Sjedite funkcijski odreuje Pota

atribut Kupac funkcijski odreuje Adresa, Sjedite, Pota

atribut Br. ra. funkcijski odreuje sve ostale atribute.

11.4. KLJU
Svaka funkcijska zavisnost ima dva elementa: atribut koji odreuje i atribut koji
je odreen. Podatak zapisan u atributu koji odreuje predstavlja i nain dohvaanja
podatka spremljenog u atributu koji je odreen. To znai da atribut koji odreuje
predstavlja klju za atribut koji je odreen.
U shemi relacije vrijede neke funkcijske zavisnosti. Treba popisati sve
funkcijske zavisnosti i takav popis sortirati tako da se lako moe uoiti koji atribut
odreuje najvie ostalih. Onaj atribut koji odreuje najvie ostalih postaje kandidat za
primarni klju. Na temelju kandidata za primarni klju stvara se i naziv sheme relacije.
Primarni klju u relaciji je jedan atribut ili skup atributa. Prema broju atributa
koji ga ine moe biti jednostavan (jedan atribut) ili sloen (vie atributa).

52

Primarni klju treba zadovoljavati sljedea pravila:

1. funkcijski odreuje sve ostale nekljune atribute sheme relacije
2. jedinstven je ne postoje dva razliita sloga u relaciji koji imaju
jednake vrijednosti kljunih atributa
3. minimalan je ne postoji niti jedan pravi podskup kljua, a s kojim bi
vrijedilo pravilo 1 ili 2 ovo pravilo se ispituje samo u shemama sa
sloenim kljuevima.

53

12. NOMALIZACIJA BAZE PODATAKA

Prema Coddu je osnovni cilj relacijskog modela zatita korisnika baze
podataka i omoguavanje lakeg i jednostavnijeg pristupa podacima u bazi. U
relacijskom modelu to se postie na sljedee naine:

sprjeavanje anomalija odravanja podataka u bazi

na minimum svedena potreba za reorganizacijom, izazvana unoenjem novih

tipova podataka u bazu

omoguavanje boljeg koritenja informacija pohranjenih u bazu.

12.1. REDUNDANCIJA
Redundancija je nepotrebno ponavljanje podataka u bazi. Ostvaruje se
memoriranjem vie kopija iste informacije u bazi podataka. Redundancija poveava
brzinu obrade jer se kopije informacija nalaze u slogovima koji e se obraivati. Do
informacija koje su kopirane u slogove koji e se obraivati moe se doi
jednostavno i brzo. Nije potrebno izvravati povezivanja relacija za izvlaenje
informacije.
Ako se, primjerice, u logikom slogu radnika memoriraju sve informacije
relevantne za obraun osobnog dohotka tog radnika (informacije o radnim zadacima
na kojima je radnik radio u proteklom periodu, informacije o satima bolovanja, mjestu
boravita, osnovici osobnog dohotka, itd.), tada e za obraun osobnog dohotka
radnika biti dovoljno da se uita jedan slog iz baze podataka. Kako su ulazno-izlazne
operacije najsporije operacije u raunalnoj obradi podataka, takvim nainom
spremanja informacije znatno se ubrzava proces obrade.
Meutim ovakav nain memoriranja informacije nosi itav niz problema. Jedan
je redundancija. Nepotrebno multipliciranje podataka o informaciji ima za posljedicu
probleme u odravanju konzistentnosti podataka.
Svako ponavljanje podataka nije redundantno. Ako ponavljanje podataka
slijedi iz prethodnih podataka u relaciji, tada je ponavljanje redundantno.

54

12.2. ANOMALIJE
Redundancija se prepoznaje prisutnim anomalijama u odravanju podataka:

anomalija unosa

anomalija izmjene

anomalija brisanja.

Kupci
Naziv kupca

Sjedite

Broj pote

Veleuilite

Rijeka

51000

3. maj

Rijeka

51000

Filozofski fakultet

Zagreb

10000

P.E.R.O. d.o.o.

Pula

52000

Telekom

Zagreb

10001

Najprije valja pokazati koje funkcijske zavisnosti djeluju nad shemom prikazane
relacije:

Broj pote Sjedite

Ne vrijedi Sjedite Broj pote

Naziv kupca Sjedite

Naziv kupca Broj pote

Relacija se sastoji od 3 atributa i sva 3 atributa mogu zasebno primiti po jednu

vrijednost za svaki slog relacije.

55

Primjer anomalija:
Anomalija unosa u relaciju treba upisati informaciju da grad Split ima potanski
broj 21000. U tablicu nije mogue zapisati takvu pojedinanu informaciju jer je
zahtijevani atribut i Kupac. Drugim rijeima, informaciju da je grad Split na
potanskom broju 21000 nije mogue zapisati, osim ako se u danom trenutku ne
stvori kupac koji e biti u navedenom gradu.
Anomalija izmjene dobivena je nova informacija da na potanskom broju 51000
vie nije grad Rijeka nego grad Fiume. Svi slogovi u kojima se na atributu Grad
nalazi vrijednost Rijeka trebaju promijeniti vrijednost u Fiume. Time se informacija ne
mijenja na jednom mjestu nego na onoliko mjesta (slogova) na koliko ih se ona
nalazi.
Anomalija brisanja brisanjem slogova u relaciji postoji mogunost za kaskadnim
gubitkom informacije. Ako se iz relacije obriu dva sloga Veleuilite i 3. maj, tada
nestaje informacija da se Rijeka nalazi na potanskom broju 51000. Ili ako se obrie
slog (P.E.R.O. d.o.o., Pula, 52000) gubi se informacija 52000 Pula (potanskom
broju 52000 pripada grad Pula).
Jednu informaciju treba biti mogue zapisati u bazu podataka samo jednom, na
jednom mjestu. Ako to nije sluaj, tada nastupaju navedene anomalije. Iz pokazanog
primjera vidi se da je jedan atribut (Sjedite) odreen duplo. Dva ga razliita atributa
(Naziv kupca i Broj pote) definiraju odreuju. Informacija je zapisana odnosom
izmeu dva atributa. Ako se neki atribut moe definirati na temelju vie drugih
atributa, tada je i informacija viestruko zapisana, dakle, stvorena je kopija
informacije.

56

12.3. NORMALIZACIJA
Normalizacija je postupak kojim se proizvoljna nenormalizirana shema relacije
transformira uvoenjem novih ogranienja. U procesu normalizacije ne smije doi do
nepovratnog gubitka informacija sadranih u relacijama zadanih na shemama koje se
transformiraju. U svakom momentu normalizacije mora biti mogue reverzibilno
rekonstruirati polazno stanje.
Postoje dvije osnovne tehnike normalizacije:

vertikalna normalizacija

horizontalna normalizacija.

Vertikalna normalizacija izvodi se dekompozicijom relacijske sheme. Pritom se

nenormalizirana shema postepeno zamjenjuje s vie manjih shema relacije, ime
dolazi do cijepanja svakog pojedinog sloga u relaciji. Za transformaciju relacije
koriste se operatori:
- projekcija - za dobivanje dekomponirane sheme
- prirodni spoj - za dokaz reverzibilnosti.
Horizontalna normalizacija ne mijenja skup atributa zadan na relacijskoj shemi.
Ona stvara dodatna ogranienja na domenama atributa zadanih shemom relacije. Za
transformaciju relacije koriste se operatori selekcije i unije. Tehnika horizontalne
normalizacije nije potpuno razvijena. Mogla bi imati velik znaaj u suvremenim
distribuiranim bazama.
Danas se kao osnovna tehnika normalizacije koristi vertikalna normalizacija.
Razlikuju se dvije varijante ove tehnike:

normalizacija dekompozicijom

normalizacija sintezom.

Normalizacija dekompozicijom je starija i kree se od proizvoljne nenormalizirane

sheme. Provodi se u koracima. Svakim korakom normalizacije shema se prevodi u
viu normalnu formu. Nadalje, svaki korak normalizacije mora biti reverzibilan.

57

Normalizacija sintezom ne kree od sheme relacije nego od skupa atributa i skupa

zavisnosti zadanih na tom skupu atributa. Ovaj postupak se za razliku od
normalizacije dekompozicijom ne provodi u koracima. Direktno se u traenoj
normalnoj formi moe konstruirati skup shema relacija na temelju skupa atributa i
skupa zavisnosti koje djeluju na njemu.

12.4. DEKOMPOZICIJA

BEZ

GUBITKA

INFORMACIJA

FUNKCIJSKIH ZAVISNOSTI
Tijekom normalizacije ne smije doi do gubitka informacije. Smatra se da je
dekompozicija sheme relacije izvedena bez gubitka informacije ako vrijedi: bilo koja
relacija stvorena nad shemom R rezultat je prirodnog spajanja svih njezinih projekcija
koje su nastale dekompozicijom.
Reverzibilnost sheme relacije dokazuje se reverzibilnou dekompozicije
relacija zadanih na toj shemi. Operatori projekcija i prirodni spoj osnova su vertikalne
normalizacije. Projekcija relacije odgovara dekompoziciji sheme relacije, a unija
dekomponiranih

shema

odgovara

prirodnom

pridruivanju

dekomponiranjem

dobivenih relacija.
Dekompozicija sheme relacije je reverzibilna ako:

dekomponirane sheme imaju barem jedan zajedniki atribut

zajedniki atributi ine klju u barem jednoj od dekomponiranih shema.

Normalizacijom bez gubitka informacije moe se dogoditi gubitak funkcijskih

zavisnosti. Dekomponirane sheme respektiraju odreene funkcijske zavisnosti iz
osnovne sheme relacije. Dekompozicija bez gubitka funkcijskih zavisnosti dogodit e
se ako unija projekcija funkcijskih zavisnosti na dekomponiranim shemama
predstavlja osnovni skup funkcijskih zavisnosti definiran na poetnoj shemi relacije.
Rissanenovo pravilo:

Svaka funkcijska zavisnost zadana nad poetnom shemom R sadrana je ili

moe biti izvedena iz unije funkcijskih zavisnosti zadanih na projekcijama.

Zajedniki atributi u dvije projekcije sadre klju u barem jednoj od njih.

58

12.5. NORMALNE FORME

12.5.1.

1. NORMALNA FORMA

Definicija 1: Shema relacije je u 1NF ako su svi nekljuni atributi funkcijski zavisni od
kljua sheme relacije.
Primjer:
Partner
Naziv partnera

Telefon

Osoba za
kontakt

GSM osobe

Veleuilite

111-222

Pero

091-223-4321

3. maj

224-567

Jure

098-213-6781

Filozofski fakultet

111-222

Pero

098-225-111

INA

224-567

Ante

098-145-666

Veleuilite

111-222

Ivica

091-134-6547

Partner

Kontakt osobe partnera

Naziv partnera

Telefon

Veleuilite

111-222

3. maj
Filozofski fakultet

Naziv partnera

Osoba za
kontakt

GSM osobe

224-567

INA

Ante

098-145-666

111-222

3. maj

Jure

098-213-6781

Filozofski fakultet

Pero

098-225-111

Veleuilite

Ivica

091-134-6547

Veleuilite

Pero

091-223-4321

Poetna shema relacije nije u prvoj normalnoj formi. Prije nego to se vri
transformacija sheme u prvu normalnu formu, valja potraiti mogue kandidate za
klju.
Kandidati za klju definiraju se na temelju skupa funkcijskih zavisnosti. Onaj atribut
koji funkcijski odreuje najvie ostalih je najpogodniji za klju.

59

Na prikazanom primjeru djeluje sljedei skup funkcijskih zavisnosti:

Naziv partnera Telefon
Kontakt osoba GSM osobe
Naziv partnera Osoba za kontakt
Prema prikazanom popisu funkcijskih zavisnosti vidi se da atribut Naziv partnera
odreuje najvie ostalih atributa. Dakle, atribut Naziv partnera predstavlja kandidata
za klju. Klju treba zadovoljavati pravila jednoznanosti i minimalnosti. Atribut Naziv
partnera ne moe biti klju jer ne zadovoljava pravilo jednoznanosti.
Kako atribut koji odreuje najvie ostalih ne moe biti klju, uzima se onaj koji je
brojem odreivanja prvi manji od prethodnog. Kako u prikazanom popisu funkcijskih
zavisnosti nema drugih zavisnosti osim Osoba za kontakt

GSM osobe, tako Osoba

za kontakt postaje kandidat za klju. U prikazanoj relaciji nije sluaj, ali se moe
dogoditi da u relaciji za odreenog partnera nema osobe za kontakt. Partner je
zapisan jer postoji informacija o njegovom broju telefona, ali jo uvijek ne postoji
informacija o osobi za kontakt. Prema tome, atribut Osoba za kontakt mogao bi
primiti null vrijednost. Klju ne smije primiti null vrijednost, pa tako niti atribut Osoba
za kontakt ne moe biti klju prikazane sheme.
U prvom sluaju, kada je Naziv partnera bio predloen za klju, prikazana tablica
mogla se pokazati bez multipliciranih vrijednosti za atribute Naziv partnera i Telefon,
konkretno u posljednjem slogu relacije. Kada bi se navedene kopije atributa u dijelu
posljednjeg sloga uklonile, relacija ne bi bila prikazana u obliku potpune
dvodimenzionalne tabele, a kopirajue grupe atributa inile bi tzv. grupe koje se
ponavljaju.
Drugi sluaj kada je atribut Osoba za kontakt bio predloen za klju, ne moe se
ostvariti zbog toga to atribut Osoba za kontakt ne postoji nuno za odreenog
partnera.
Prema svemu navedenom moe se pokazati i druga definicija 1. normalne forme.
Definicija 2: Shema relacije je u 1NF ako svaka relacija (skup slogova) koji je zadan
nad shemom moe biti prikazan u obliku dvodimenzionalne tabele.
Kada se razmatrala mogunost postavljanja atributa Naziv partnera za klju sheme
relacije, tada se moglo rei da je atribut Naziv partnera dobar kandidat jer odreuje

60

najvie ostalih atributa. Neka atribut Naziv partnera bude klju sheme relacije.
Postoje oni partneri koji imaju vie osoba za kontakt. Prema definiciji 2 shema e biti
u 1NF ako se relacija moe prikazati u obliku dvodimenzionalne tabele. Ovdje
nastaje zahtjev za treom dimenzijom jer se jedino pomou tree dimenzije moe
jednom partneru dodijeliti vie osoba za kontakt, ako se potuje pravilo tabele. Ali
time se ne potuje pravilo dvodimenzionalnosti.
Prema navedenom moe se pokazati i trea definicija 1. normalne forme.
Definicija 3: Shema relacije je u 1NF ako za svaki atribut u shemi vrijedi da su
vrijednosti domene na kojoj je atribut zadan pojedinani podaci.

61

12.5.2.

2. NORMALNA FORMA

Definicija: Shema relacije je u 2NF ako je u 1NF i ako su svi nekljuni atributi
potpuno funkcijski zavisni od kljua, tj. ako ne postoji parcijalna zavisnost nekljunog
atributa o kljuu preko dijela kljua.
Primjer:
Prodana roba
Broj rauna

Artikal

15

Mahune

15,5

kg

17

Jabuke

3,75

kg

16

Mahune

14,23

kg

17

Jamnica

15

15

Jabuke

74

kg

Prodana roba

Koliina

Jedinica
mjere

Artikli

Broj rauna

Artikal

Koliina

15

Jabuke

15

Mahune

15,5

16

Mahune

14,23

17

Jabuke

3,75

17

Jamnica

74

Artikal

Jedinica
mjere

Mahune

kg

Jamnica

Jabuke

kg

15

Normalizacija prema zahtjevima 2NF provodi se samo na shemama sa sloenim

kljuevima. Ne treba promatrati one sheme koje imaju jednostavni klju. Provjerava
se tako da se ustvrdi zavisi li funkcijski neki nekljuni atribut od dijela kljua. Ako
takav postoji, tada shema nije u 2NF.
U prikazanom primjeru Jedinica mjere je redundantan atribut jer je duplo funkcijski
odreen. Odreen je kljuem (Broj rauna, Artikl) i atributom Artikl koji ini dio kljua.
Postupak se provodi tako da se redundantni atribut izbacuje iz sheme ime u shemi
ostaju atributi Broj rauna, Artikl i Koliina. Od izbaenog atributa Jedinica mjere
stvara se druga shema. Kako Jedinica mjere ne moe samostalno egzistirati, a i zbog

62

pravila o uvanju informacija i funkcijskih zavisnosti, zajedno s Jedinicom mjere u

novostvorenu shemu kopira se i atribut koji je ovog prethodnog odreivao, dakle
Artikl se kopira u drugu shemu. Artikl koji se sada nalazi u obje dekomponirane
sheme nije redundantan jer on nosi funkcijsku zavisnost.

12.5.3.

3. NORMALNA FORMA

Definicija: Shema relacije je u 3NF ako je u 1NF i ako niti jedan nekljuni atribut nije
tranzitivno zavisan od kljua sheme relacije.
Primjer:
Rauni
Br. ra.

Kupac

Datum

Adresa kupca

15

Veleuilite

15.06.2005

Vukovarska 1

16

P.E.R.O. d.o.o.

16.06.2005

Rijeka 17

17

Veleuilite

16.06.2005

Vukovarska 1

18

Filozofski fakultet

17.06.2005

Uenika 15/IV

19

P.E.R.O. d.o.o.

17.06.2005

Rijeka 17

Rauni

Iznos
15.000,00
1.450,80
18.200,20
350,35
3.682,40

Kupci

Br. ra.

Kupac

Datum

15

Veleuilite

15.06.2005

15.000,00

16

P.E.R.O. d.o.o.

16.06.2005

1.450,80

17

Veleuilite

16.06.2005

18.200,20

18

Filozofski fakultet

17.06.2005

350,35

19

P.E.R.O. d.o.o.

17.06.2005

3.682,40

Iznos

Kupac

Adresa kupca

Veleuilite

Vukovarska 1

Filozofski fakultet

Uenika 15/IV

P.E.R.O. d.o.o.

Rijeka 17

Normalizacija za 3NF provodi se tako da se ustvrdi postojanje nekljunog atributa koji

je funkcijski odreen drugim nekljunim atributom, odnosno treba ustvrditi postoji li
neka druga funkcijska zavisnost, a koja nije funkcijska zavisnost o kljuu.
U prikazanom primjeru Adresa kupca je redundantan atribut jer je dvostruko
funkcijski odreen. Atribut Adresa kupca je funkcijski odreen nekljunim atributom
Kupac, a temeljem 1NF funkcijski je odreen kljuem. Time se vidi tranzitivna

63

funkcijska zavisnost atributa Adresa kupca preko drugog nekljunog atributa Kupac o
kljuu sheme relacije.
Postupak se provodi tako da se redundantni atribut izbacuje iz sheme, ime u shemi
ostaju atributi Br. ra., Kupac, Datum i Iznos. Od izbaenog atributa Adresa kupca
stvara se nova shema relacije. Kako Adresa kupca ne moe samostalno egzistirati, a
i zbog pravila o uvanju informacija i funkcijskih zavisnosti, zajedno s Adresom kupca
u novostvorenu shemu kopira se i atribut koji je odreivao prethodnog, dakle Kupac
se kopira u drugu shemu. Kupac koji se sada nalazi u obje dekomponirane sheme
nije redundantan jer on nosi funkcijsku zavisnost.

12.5.4.

BCNF BOYCE-CODDOVA NORMALNA FORMA

BCNF je najvia normalna forma koja se moe definirati pomou funkcijskih

zavisnosti.
Definicija: Shema relacije R je u BCNF ako je u 1NF, i ako postoji takav skup
atributa X iz sheme R, te atribut A koji nije u skupu X, i ako vrijedi X A, tada vrijedi
X R.
Definicija se moe rei i drugim rijeima. Ako u shemi relacije R postoji takav skup
atributa X za koji vrijedi da X A, a atribut A nije u skupu X, odnosno navedena
funkcijska zavisnost nije trivijalna, tada skup atributa X mora biti klju od R.
BCNF odstranjuje sve tranzitivne funkcijske zavisnosti o kljuu. Neke tranzitivne
zavisnosti odstranjene su 2NF i 3NF.
Kako bi se moglo objasniti koje se tranzitivne funkcijske zavisnosti rjeavaju pomou
BCNF, najprije treba definirati mogue vrste tranzitivnih funkcijskih zavisnosti. Prema
tome slijede vrste tranzitivnosti:
1. Tranzitivna zavisnost nekljunog atributa preko podskupa nekljunih
atributa
Shema relacije ima dva nekljuna atributa (A i B), i vrijedi A B, kako su
atributi A i B funkcijski zavisni od kljua jer su u 1NF, time je i atribut B
dvostruko odreen. Atribut B je zavisan od atributa A, a time je atribut B preko
atributa A zavisan od kljua. Ovakva vrsta tranzitivnosti rijeena je 3NF-om.
2. Tranzitivna zavisnost nekljunog atributa preko dijela kljua
64

Shema relacije ima sloeni klju sastavljen od atributa K1 i K2. Takoer vrijedi
da je nekljuni atribut A funkcijski odreen atributom npr. K1. Kako vrijedi
pravilo trivijalnosti koje kae da sloeni skup atributa funkcijski odreuje svaku
pojedinu njegovu komponentu, moe se zakljuiti da je atribut A dvostruko
funkcijski odreen. Atribut A zavisi od kljua i preko dijela kljua (atribut K1)
ponovo od kljua. Takav tip zavisnosti zove se parcijalna funkcijska zavisnost.
Ovakva vrsta tranzitivnosti rijeena je 2NF-om.
3. Tranzitivna zavisnost kljunog atributa preko podskupa nekljunih
atributa
Shema relacije ima sloeni klju K sastavljen od atributa K1 i K2. Takoer
vrijedi da nekljuni atribut A funkcijski odreuje dio kljua npr. K1. Trivijalna
zavisnost KK1 kojom K pojedinano funkcijski odreuje svaku svoju
komponentu je tranzitivna jer se moe izvesti aksiomom tranzitivnosti na
zavisnosti K A i A K1.
4. Tranzitivna zavisnost kljunog atributa preko podskupa kljunih atributa
Shema relacije ima dva sloena kljua K(K1K2) i X(C1C2). Ako postoji
funkcijska zavisnost C1 K1, tada je trivijalna funkcijska zavisnost KK1
tranzitivna jer se moe izvesti aksiomom tranzitivnosti K C1 i C1 K1.
Zadnje dvije vrste tranzitivnosti rjeavaju se pomou BCNF. Na temelju posljednjih
dviju vrsta tranzitivnosti u kojima sheme relacije trebaju imati barem jedan sloeni
klju, moe se zakljuiti da sve sheme relacija koje su u 3NF i imaju jednostavan
klju sigurno jesu u BCNF. Samo sheme koje su u 2NF i 3NF i imaju sloeni klju ne
moraju biti u BCNF. Takve sheme se ispituju BCNF-om.

65

13. DINAMIKA U BAZI PODATAKA

Baza podataka nije samo statian sustav koji, kad je jednom dobio svoju
koliinu podataka, takav ostaje zauvijek. Podaci se u bazi permanentno mijenjaju,
dopunjavaju i uklanjaju. Dinamika u bazi se oituje kroz sljedee:

Definirana

statina

ogranienja

podacima

(domena

atributa,

specifine vrijednosti, reference na vrijednosti) ponekad nisu dovoljna

za uvanje konzistentnosti meu podacima. esto relacije u bazi
podataka nisu dovoljno normalizirane pa su anomalije prisutne, ime
uvanje konzistentnosti nije uvijek mogue definiranim ogranienjima.

Podaci su stanje objektivne stvarnosti. Kako se objektivna stvarnost

mijenja tako se i podaci trebaju mijenjati, dodavati, brisati. Vrlo esto
odreena promjena u objektivnoj stvarnosti proizvodi veu koliinu
promjena u stanju podataka. Tada se moe dogoditi auriranje
podataka u vie razliitih relacija. Zbog mnogih razloga (hardver, softver
itd.) moe se dogoditi nekorektnost u zahtijevanim promjenama nad
podacima. Neki podaci su time doivjeli korekcije, a neki nisu. Novo
stanje baze podataka vie nije korektno i ne oslikava stanje objektivne
stvarnosti. Logino bi bilo provesti jednak redoslijed modifikacija na
podacima kako bi se dolo do odreenog stanja koje je realno i
korektno ili bi logino bilo vratiti se na stanje podataka koje je bilo prije
izvravanja korekcija na podacima.

Procesi itanja i spremanja podataka relativno su spori bez obzira na

dananje mogunosti raunala, njihove brzine i kapacitete. Korisnik
dohvaa podatke, daje zahtjeve za nove dohvate ili vri korekcije (unos,
izmjenu ili brisanje) na stanju podataka u bazi. O rezultatima pisanja u
bazu korisnik mora biti obavijeten. Kada korisnik dobije odreene
rezultate pretraivanja odluuje se za neku drugu aktivnost. esto je
takva

sljedea

aktivnost

poznata

rijeena

automatizmima

implementiranim u korisnikim programima. Navedeni procesi traju

izvjesno vrijeme.

66

Iz svega navedenog postoje zahtjevi za sustavnim definiranjem pravila koja utjeu na

promjene stanja podataka.

13.1. UVANJE KONZISTENTNOSTI

Sheme relacija u bazi podataka trebaju biti normalizirane to je mogue vie.
Minimumom normalizacije smatra se rjeavanje anomalija koje se javljaju kod sve
etiri vrste tranzitivnosti. Drugim rijeima, smatra se potrebnim da sheme budu
normalizirane barem do 3NF, odnosno do BCNF, ime e biti rijeene sve anomalije
koje se javljaju redundantnim funkcijskim zavisnostima.
Meutim esto sheme relacija imaju takve atribute ija vrijednost moe biti
izvedena nekim matematikim algoritmima. Npr. Iznos = Koliina * Cijena ili
UkupanIznos = Iznosa stavaka. Vrijednosti takvih atributa u relacijama ne mogu biti
rijeene svim dosad predstavljenim ogranienjima. Na takve vrijednosti utjeu
pojedinane vrijednosti nekih drugih atributa pomou odreenih matematikih
algoritama.
Na vrijednosti izvedenih atributa utjeu i korekcije u atributima koji ine
elemente algoritma za dobivanje vrijednosti izvedenog atributa. Pod korekcijama se
smatra auriranje podataka (unos, izmjena ili brisanje) ime e se dogoditi promjene
u atributima ije vrijednosti po slogovima djeluju u algoritmu za izvoenje vrijednosti
izvedenog atributa. Takve algoritme je potrebno programski rijeiti. Algoritmi sadre
podatke kao izvorite koji su zapisani u odreenim atributima. Time bilo kakva
promjena podataka na atributima izvorita treba rezultirati korekcijom vrijednosti
izvedenog atributa kao rezultata algoritma.
Postoje dva mogua pristupa kojima je mogue realizirati algoritme izvoenja
vrijednosti:
1. algoritmi na strani korisnikog programa
2. algoritmi na strani baze.
Algoritmi na strani korisnikog programa algoritmi koji su implementirani u
korisniki program i izvode se obino nakon uspjeno izvrene akcije auriranja
(unosa, izmjene ili brisanja) podataka koji su spremljeni u atributima koji utjeu na
vrijednost izvedenog atributa. Takve algoritme obino je lake programski izgraditi jer

67

se implementiraju unutar ostalih programskih komponenti. Takav pristup ima neke

nedostatke:
1. Brzina izvoenja algoritma algoritmi sadre naredbe za auriranje
podataka i naredbe za dohvaanje podataka. Takvi procesi su spori jer
moraju komunicirati s bazom podataka.
2. Garancija da e se algoritam izvesti korisnik moe nekim drugim
programom pristupiti podacima i izvriti korekciju koja e utjecati na
obaveznu korekciju izvedenog atributa koja se tada nee dogoditi.
Algoritmi na strani baze su algoritmi koji su implementirani uz postavke shema
relacije unutar DBMS-a. O njihovom izvoenju brine DBMS. Ovakvim pristupom
rjeavaju se oba nedostatka prethodnog pristupa. Algoritme pokree DBMS
samostalno i time se ne dogaa komunikacija s korisnikom s ciljem dohvaanja
podataka. Algoritam e sigurno biti izvren. Izmeu DBMS-a i podataka nema vie
nikoga. Nitko ne moe utjecati na neizvravanje algoritma koje DBMS pokree.
Drugim pristupom rjeava se jedan dio problema uvanja konzistentnosti meu
podacima poslovna logika i algoritmi manipuliranja podacima trebaju biti spremljeni
na jednom mjestu i obavezno se moraju potovati.
Algoritmi na strani baze implementiraju se pomou okidaa (eng. trigger).
Okidae podrava DBMS sustav, a mogu se izvoditi na svim DML akcijama (unos,
izmjena, brisanje). Na svakoj akciji mogue je definirati vrijeme izvoenja okidaa
koje moe biti prije (before) ili poslije (after) izvedene akcije.
Primjer psuedokod naredbe za kreiranje okidaa:
CREATE TRIGGER Izracunaj_Iznos BEFORE INSERT, UPDATE
ON StavkaRacuna
FOR EACH RECORD
BEGIN
DECLARE UkIznos DECIMAL(11,2);
SELECT SUM(Kolicina*Cijena) INTO Iznos
WHERE BrojRac = NEW.BrojRac;
UPDATE Racuni SET Iznos = UkIznos
WHERE BrRac = NEW.BrojRac;
END
68

Naredba za stvaranje okidaa sastoji se od sljedeih elemenata:

-

table name - naziv tablice nad kojom se kreira okida

trigger action DML akcija nad slogom u tablici na koju e biti pridodan okida
- insert, update, delete

trigger time vrijeme izvoenja okidaa u odnosu na izvoenje DML akcije

before, after

trigger statement naredbe, dogaaj koji e okida izvriti kada se bude

pokrenuo. Naredbe ukljuuju auriranje iste ili drugih tablica u bazi.

Okidai pospjeuju dinamiku nad podacima s ciljem uvanja konzistentnosti nad

njima. Kod stvaranja okidaa valja voditi brigu o postavci vremena izvoenja.
Obino se okidai s vremenom izvoenja prije akcije auriranja stvaraju za atribute
koji mogu biti izvedeni iz nekih drugih atributa, a koji se nalaze u istoj relaciji (tablici)
kao i atribut koji je izveden.
Okidai koji se izvode vremenski nakon uspjene aktivnosti auriranja obino se
odnose na korekcije vrijednosti atributa u drugim tablicama koje mogu direktno ovisiti
o prvoj, tako da predstavljaju odreeni slijed dogaaja ili neku kumulativnu vrijednost
auriranih atributa na kojima je okida.

13.2. PROMJENE U PODACIMA ZA POTREBE SUSTAVA

Baza podataka ne egzistira sama za sebe. Ona postoji zbog potreba
organizacijskog sustava za koji je izgraena. Baza podataka podatkovno predstavlja
sliku objektivne stvarnosti u odreenom trenutku. U realnom svijetu dogaaju se
promjene. Promjene je potrebno evidentirati u podatkovnoj osnovi, dakle u bazi
podataka. Prilikom auriranja promjena u podacima potrebno je voditi brigu o:

poslovnim pravilima odreuju pravila auriranja podataka i semantike

poveznice meu njima

cjelovitosti provedenih auriranja poslovna pravila odreuju koliinu i

redoslijed auriranja podataka, a sva auriranja trebaju u potpunosti biti
provedena, kako bi se osigurala to tonija slika objektivne stvarnosti
zapisane u podatkovnoj osnovi.

69

Za osiguranje cjelovitosti provedenih auriranja koriste se transakcijske mogunosti

DBMS-a.
Poslovna pravila definirana su programskom osnovom i akcijskim tijekom
programskog rjeenja.

13.2.1.

TRANSAKCIJSKI PRISTUP

Jedna poslovna aktivnost moe imati za posljedicu auriranje vie razliitih

podataka u bazi. Vrlo esto se nakon auriranja jednih podataka, na temelju
novodobivenih vrijednosti u auriranim podacima, slijedno auriraju drugi podaci, pa
trei itd. Za zavretak cijele poslovne aktivnosti potrebno je uspjeno izvriti veu
koliinu promjena nad podacima u bazi. Nije dobro da proces auriranja bude
prekinut u nekom dijelu. U tom sluaju upitna je semantika korektnost izvravanja
narednih auriranja. Obino auriranja koja slijede za nekima prije trebaju prethodne
podatkovne sadraje za izvravanje vlastitih auriranja. Proces koji se sastoji od vie
slijednih i meusobno semantiki zavisnih auriranja zove se transakcija. Neki
primjeri transakcija:
- knjienje rauna u glavnu knjigu
- proces obrauna plae
- auriranje kartice prometa artikala novom otpremnicom
- izrada procjene radnog mjesta s poveanim opasnostima
- obraun amortizacije osnovnih sredstava
- stvaranje radnih naloga iz sastavnice artikala
- izrada rasporeda sati itd.
Svaka transakcija sastoji se od podatkovne osnove i poslovnih pravila koja utjeu na
promjene nad podatkovnim sadrajem. Transakcija posjeduje toku iz koje kree sa
svojim radom. Takva pozicija zove se poetak transakcije. DBMS koji podrava
transakcijski pristup (podravaju ga gotovo svi DBMS-ovi) ima naredbu koja
oznaava poetak transakcije START TRANSACTION. Kada se transakcija pokrene,
ona obuhvaa sva auriranja na bazi do toke zavretka. Valja napomenuti da su sva
auriranja koja se izvode unutar transakcije vidljiva samo onom korisniku koji je
pokrenuo transakciju. Drugi korisnik je pod istim imenom mogao pristupiti bazi. Niti
on ne vidi promjene koje je pokrenuo onaj prvi, isti korisnik. Kada dva korisnika s dva
70

jednaka ili razliita mjesta pristupaju bazi, stvaraju se dvije razliite sesije pristupa.
Transakcija je vezana za sesiju, te je zato vidljiva samo onom korisniku koji ju je i
pokrenuo. Sva auriranja koja se dogaaju na relacijama baze podataka spremaju se
u tzv. privremene tablice jer ne smiju biti vidljiva drugim korisnicima. Nakon zavrenih
svih potrebitih auriranja potrebno je zavriti transakciju. Postoje dva mogua
zavretka transakcije i za njih postoje odgovarajue naredbe na DBMS-u:
- COMMIT potrebno je pokrenuti ovu naredbu kada su sva auriranja
uspjeno zavrena i korisnik je postigao cilj zavrio je poslovnu aktivnost. Nakon
pokretanja naredbe commit sva auriranja koja su se dogodila na relacijama baze bit
e prihvaena i spremljena u bazinim relacijama i time vidljiva ostalim korisnicima.
- ROLLBACK naredba koja se pokree prije zavretka svih auriranja koja
predstavljaju transakciju. Pokree se onda kada odreeno auriranje nije uspjelo,
odnosno kada se dogodila odreena pogreka u procesu auriranja. Tada je upitna
korektnost drugih auriranja koja semantiki slijede ono neuspjelo auriranje. U tom
sluaju obino se pokree naredba rollback koja e stanje baze vratiti u ono stanje
koje je bilo u trenutku pokretanja transakcije.
Gore navedenim nisu rijeeni svi transakcijski problemi. Moe se dogoditi sluaj da je
jedan korisnik pokrenuo jednu transakciju, a drugi korisnik je prije zavretka one prve
transakcije pokrenuo istu ve pokrenutu transakciju. Ako transakcija posjeduje
naredbe kojima e se vriti upisivanje slogova u relaciju, s time da se klju treba
automatski uveavati za jedan, tada druga transakcija moe za vrijednost kljua u
procesu upisivanja dati jednaku vrijednost inkrementiranog kljunog atributa, kao i
prva transakcija, i to zato to je druga transakcija bila pokrenuta prije zavretka prve.
Ili, ako se transakcija sastoji od poslova, najprije prebrojavanje koliko prodanih
artikala ima, i dodavanje novog artikla s rednim brojem koji je uvean za broj
prebrojanih. Ako prvi korisnik pokrene takvu transakciju, i ako drugi ili isti korisnik
pokrene drugu takvu transakciju prije zavretka one prve, tada e prva transakcija
koja bude zavrena biti korektno izvrena. Ona transakcija koja naknadno zavrava
nee uspjeno zavriti svoju aktivnost, jer je prvozavrena transakcija uzrokovala
stanje podataka koje nee dozvoliti uspjean zavretak nove transakcije. U takvim
sluajevima pristupa se tzv. privremenom zakljuavanju relacija. Zakljuavanje
relacija odnosi se na auriranje. Korisnik, odnosno sesija koja izvri zakljuavanje
relacije, ne dozvoljava ostalim korisnicima (sesijama) bilo kakvo auriranje na
71

zakljuanoj tablici. Zakljuanost traje toliko dugo dok onaj korisnik (sesija) koji je
zakljuao relaciju ne izvri njezino otkljuavanje. Onaj korisnik koji je izvrio
zakljuavanje relacije smije vriti auriranja na zakljuanoj relaciji. Navedeni
postupak provodi se naredbama LOCK TABLE i UNLOCK TABLE.

13.2.2.

PROVOENJE POSLOVNIH PRAVILA

Poslovna pravila definiraju dinamiku sustava, odnosno promjene na

podatkovnoj osnovi. Svaki novi dogaaj u organizacijskom sustavu rezultira nekim
auriranjima podatkovnog sadraja kako bi podatkovni sadraj predstavljao to
vjerniju sliku stanja organizacijskog sustava, odnosno sliku objektivne stvarnosti.
Poslovna pravila, odnosno auriranja podataka provode se definiranim
pravilima i definiranim jezikom za auriranje podataka. Krajnji korisnik ne treba
poznavati sintaksu jezika za auriranje podataka. Program koji korisnik koristi
poznaje sintaksu jezika za auriranje podataka i program komunicira s bazom
podataka te aurira podatke na zahtjev korisnika. Korisnik pokree odreenu
aktivnost u programu koji koristi, a u pozadini se dogaaju naredbe koje izvravaju
auriranja podataka. Korisnik poznaje znaenje podataka i to sa podacima treba
uiniti, a ne kako s njima izvriti odreenu aktivnost auriranja.
Programi se sastoje od procedura koje izvravaju neke segmente upravljanja
podatkovnim sadrajem. Prema mjestu izvoena procedure mogu biti:
- procedure koje pristupaju bazi
- procedure koje su spremljene na bazi.
Procedure koje pristupaju bazi takve procedure koje se izvravaju na klijentskom
raunalu ili aplikacijskom posluitelju tako da im je za izvravanje potrebna
komunikacija s bazom podataka koja moe biti na drugom tzv. database posluitelju.
Procedure koje su spremljene na bazi takve procedure (tzv. uskladitene
procedure, eng. stored procedure) koje su pisane u programskom jeziku kojeg DBMS
razumije i moe izvravati. Pokreu se direktno na posluitelju s bazom, odnosno
unutar samog DBMS-a.

72

Razlika u funkcionalnosti meu navedena dva tipa procedura ne postoji. Meutim

postoji velika razlika u brzini izvoenja postupaka od kojih se procedura sastoji.
Procedure koje pristupaju bazi za itanje podataka trebaju poslati odreene upite
DBMS-u i ekati odgovor DBMS-a. Odgovor ne mora biti malen, moe biti i velik.
Brzina izvoenja procedure koja pristupa bazi znatno ovisi o brzini komunikacijskog
kanala izmeu raunala na kojem je pohranjena procedura i na kojem se ista izvodi i
raunala na kojem se nalazi baza. Procedure koje pristupaju bazi mogu se izvoditi i
na istom raunalu na kojem se nalazi DBMS. Takve procedure e logino biti
izvrene bre nego iste na nekom udaljenom raunalu.
Uskladitene procedure na DBMS-u izvravaju se na DBMS-u tako da ih korisnik u
odreenom trenutku pozove. S obzirom na to da su one spremljene i izvode se u
sustavu koji istovremeno upravlja podacima, logino je oekivati da e brzina
izvoenja takvih procedura biti znatno vea od onih koje se pokreu i izvode izvan
DBMS sustava, na istom ili udaljenom raunalu.
Krajnji korisnik obino ne poznaje koje procedure postoje uskladitenje na DBMS-u i
kako one funkcioniraju. Korisnik poznaje svoju poslovnu logiku koju provodi
koritenjem programskog rjeenja. Programsko rjeenje moe imati svoje procedure
koje pristupaju bazi i izvode odreene aktivnosti nad podacima, ili moe pozivati
uskladitene procedure na DBMS-u koje rade jednak posao.
Uskladitene procedure mogu se pisati i izvoditi na DBMS-u koji to dozvoljava.
Danas veina DBMS sustava dozvoljava pisanje, spremanje i izvoenje uskladitenih
procedura. DBMS u svojoj osnovi posjeduje samo SQL upitni jezik. SQL nije dovoljno
moan da moe primiti naredbe koje se koriste u uskladitenim procedurama. SQL je
zato nadograen svojim programibilnim strukturama, pa se u tu svrhu razvio PL-SQL
(Programing Language Structured Query Language). PL-SQL uz klasine SQL
upitne naredbe posjeduje i naredbe klasinog programskog jezika. Dakle posjeduje
naredbe kontrole toka. Tako posjeduje i naredbe kojima se osigurava grananje
programa (IF) i ponavljanje odreenih naredbi (LOOP).

73

13.3. BRZINA ODZIVA REZULTAT UPITA

Upiti prema DBMS-u esto se izvode s odreenom namjerom i predstavljaju
odreeno stanje baze u nekom trenutku. Upiti prema DQL specifikaciji mogu
sadravati i sloenije zahtjeve rudarenja podataka. Takvo traganje i itanje podataka
nekad moe biti i dugotrajno. U sluajevima kada je upit prema bazi postavljen i treba
dohvatiti veu koliinu podataka, tada je vrijeme odziva, odnosno dobivanja rezultata
due. Upiti zahtijevaju sekvencijalno itanje slogova u tablicama. Tada se podaci
itaju jedan za drugim i na temelju zahtijevanog uvjeta ulaze u obzir ili se odbacuju iz
rezultata. Vrijeme dobivanja rezultata moe biti i podue zbog velike koliine slogova
koji se trebaju obraditi (provjeriti zadovoljavanje uvjeta). U takvim sluajevima koriste
se indeksi (eng. index).
Indeksi se stvaraju na bazi odmah uz osnovnu bazinu tablicu i posjeduju uvijek
aurno stanje atributa iz bazine tablice, ali samo onih koji su zahtijevani u indeksu.
Indeksi uz kopije vrijednosti sadranih atributa posjeduju i tzv. pointere prema
originalnim podacima u bazinoj tablici. Prilikom pisanja upita prema bazi mogue je
forsirati koritenje indeksa ime e se pregledavati popis vrijednosti u tablici
indeksa i za zadovoljene vrijednosti, pomou pointera proitati odgovarajui slog
bazine tablice. Time e se znatno ubrzati proces traganja za podacima i njihovo
itanje. Brzina se nee poveati nekoliko desetaka postotnih jedinica, nego ak i
nekoliko desetaka puta. Koritenje indeksa time ima vrlo znaajnu ulogu u dovoljno
brzom dohvatu podataka.
Valja imati na umu da ne treba pretjerivati s koliinom razliitih indeksa. Prilikom
auriranja slogova u bazinoj tablici istovremeno se auriraju i vrijednosti u tablici
indeksa. Takvo dodatno auriranje tablice indeksa traje izvjesno vrijeme. to je vie
indeksa na tablici time se i proces auriranja sloga u tablici vremenski produuje. U
tablicama koje imaju veu koliinu promjena, koritenjem indeksa moe se znatno
smanjiti brzina auriranja podataka, zbog popratnih auriranja svih tablica indeksa.
Stoga valja paziti prilikom stvaranja indeksa, odnosno, valja paziti prilikom donoenja
odluke za stvaranjem indeksa. Indeks treba biti koriten. Ako se indeks ne koristi niti
jednim upitom prema bazi, tada ne treba niti postojati.

74

Uz navedene zahtjeve ubrzavanja odziva baze rezultatima upita indeksi se mogu

podijeliti u dvije skupine s obzirom na dodatne zahtjeve:
-

Nejedinstveni indeksi dodatno koritenje takvih indeksa je kod stvaranja

ogranienja vanjskog kljua. Veina DBMS sustava nee dozvoliti stvaranje
ogranienja atributa na vanjsku vrijednost (foreign key reference), ako tablica
nema indeks koji se sastoji od atributa koji ine vanjski klju.

Jedinstveni indeksi takvi indeksi mogu se dodatno koristiti za ogranienja

jedinstvenosti u atributima koji ine indeks. Drugim rijeima, mogue je da
tablica (entitet) uz primarni klju posjeduje i sekundarne kljueve. Takvi
sekundarni kljuevi takoer zahtijevaju jedinstvenost slogova na atributima koji
ine indeks. Npr. Kupci(NazivKupca, Adresa, MatiniBroj, Telefon). Neka je
NazivKupca primarni klju, tada MatiniBroj moe biti sekundarni klju u tablici
Kupci.

75

14. LITERATURA
[1] Tkalac, S., Relacijski model podataka, Drutvo za razvoj informacijske
pismenosti, Zagreb, 1993.
[2] Radovan, M., Baze podataka: relacijski pristup i SQL, Informator, Zagreb, 1993.
[3] Alagi, S., Relacione baze podataka, Svjetlost, Sarajevo, 1985.
[4] Malekovi, M., Skripta - Baze podataka I, Poslijediplomski znanstveni studij
Informacijske znanosti, Varadin, 1999.
[5] Tkalac, S., Skripta - Oblikovanje baze podataka, Poslijediplomski znanstveni
studij Informacijske znanosti, Varadin, 1999.
[6] Novak, N., Prezentacija za predavanja iz kolegija Baze podataka, Veleuilite u
Rijeci, Rijeka, 2005.
[7] Kalua, M., Prezentacija za predavanja iz kolegija Sustavi baza podataka,
Veleuilite u Rijeci, Rijeka, 2005.
[8] Pavli, M., Razvoj informacijskih sustava, Znak, Zagreb, 1996.

76