Fakultet prirodoslovno-matematičkih znanosti Sveučilišta u Splitu

Tonći Dadić

BAZE PODATAKA

Split, 2012.

2

Sadržaj:

1 UVOD ......................................................................................................................... 5

1.1 Što je baza podataka?.....................................................................................5

1.2 Vrste baza podataka .......................................................................................9

1.2.1 Datotečna baze podataka......................................................................10

1.2.2 Hijerarhijska baza podataka.................................................................10

1.2.3 Mrežna baza podataka..........................................................................11

1.2.4 Relacijska baza podataka .....................................................................11

1.2.5 Objektna baza podataka .......................................................................12

2 Relacijski model podataka ....................................................................................... 15

2.1 Mala knjižara ...............................................................................................15

2.2 Pojmovi relacijskog modela podataka .........................................................19

2.3 Relacijska algebra ........................................................................................20

2.4 Coddova pravila ...........................................................................................23

2.5 Ograničenja relacijskog modela...................................................................25

2.5.1 Ograničenja strukture...........................................................................25

2.5.2 Ograničenja ponašanja .........................................................................26

2.6 Normalizacija...............................................................................................28

2.6.1 Prva normalna forma............................................................................28

2.6.2 Druga normalna forma.........................................................................31

2.6.3 Treća normalna forma..........................................................................32

2.6.4 Boyce-Coddova normalna forma.........................................................34

2.6.5 Četvrta normalna forma .......................................................................35

2.6.6 Peta normalna forma............................................................................36

3 Životni ciklus baze podataka.................................................................................... 38

3.1 Faze životnog ciklusa baze ..........................................................................38

3.2 Vrste baza podataka .....................................................................................41

3.3 Postupak oblikovanja baze podataka ...........................................................42

3.3.1 Izrada modela.......................................................................................42

3.3.2 Različiti aspekti sustava.......................................................................43

3

3.3.3 Model entiteti – veze............................................................................44

3.3.4 Veze .....................................................................................................45

3.3.5 Rješenje veze više prema više..............................................................48

3.3.6 Rekurzivna veza...................................................................................49

3.3.7 Učestalost pojedinih vrsta veza u realnim modelima ..........................50

3.3.8 Atributi .................................................................................................51

3.3.9 Opcionalnost atributa ...........................................................................52

3.3.10 Jedinstveni identifikator.......................................................................52

3.4 Videoteka - model praktičnog primjera .......................................................54

3.5 Model entiteti – veze ( MS SQL Server 2008) ............................................61

3.6 Funkcije ( metode ) ......................................................................................61

3.7 Impementacija objekata baze podataka – primjer dviju tablica ( Microsoft

SQL Server 2008 ): ..................................................................................................62

4 Indeksi ...................................................................................................................... 64

5 SQL Upitni jezik ....................................................................................................... 70

5.1 Uvod.............................................................................................................70

5.2 Upiti u relacijskoj bazi podataka..................................................................70

5.2.1 Projekcija i restrikcija ..........................................................................70

5.2.2 Prirodno spajanje .................................................................................74

5.2.3 Vanjsko ( Outer Join ) spajanje............................................................75

5.2.4 Unutrašnje ( Inner Join ) spajanje ........................................................78

5.2.5 Funkcije u SQL Upitu..........................................................................79

5.2.6 Grupiranje podataka i sumarna izračunavanja.....................................85

5.2.7 ZbrojOcjena .........................................................................................90

5.2.8 Logički složeni uvjeti...........................................................................91

5.2.9 Pobrojane vrijednosti ...........................................................................93

5.2.10 Ugniježđeni upiti..................................................................................94

5.3 SQL komande za definiciju objekata relacijske baze podataka.................100

5.3.1 Stvaranje, promjena i uništavanje tablice ..........................................100

5.3.2 Stvaranje i uništavanje pogleda – view-a...........................................104

5.3.3 Stvaranje indeksa ...............................................................................106

5.3.4 Uništavanje indeksa ...........................................................................107

5.4 Naredbe za upisivanje, promjenu i brisanje podataka ...............................108

5.4.1 Upisivanje ( insertiranje ) retka..........................................................108

4

5.4.2 Upisivanje svih kolona.......................................................................109

5.4.3 Upisivanje iz jedne tablice u drugu....................................................110

5.4.4 Pomjena podataka ( update )..............................................................110

5.4.5 Promjena podataka tablice vrijednostima druge tablice ....................111

5.4.6 Brisanje ( delete ) retka ......................................................................112

6 Literatura: .............................................................................................................. 114

5

1 UVOD

1.1 Što je baza podataka?

Intuitivno nam je jasno da su baze podataka sastavnica informacijskog sustava. Stoga

krenimo od definicije informacijskog sustava.

Informacijski sustav prikuplja, pohranjuje, čuva, obrađuje i isporučuje informacije

važne za pojedinca, organizaciju i društvo, tako da budu dostupne i uporabljive za

svakog tko ih želi koristiti. Informacijski sustav aktivni je društveni sustav koji može,

ali ne mora, koristiti suvremenu informacijsku tehnologiju ( M. Varga, «Baze

podataka», DRIP, Zagreb 1994).

Informacija je «sirovina» i «proizvod» informacijskog sustava.

Elementarna informacija je opis jednog obilježja određenog objekta ( S. Tkalac,

1993).

Informacija je novo znanje, koje primatelju donosi nove činjenice. Ona ima karakter

novosti, otklanja neizvjesnost i služi kao podloga za odlučivanje ( Birolla i dr., 1988).

Po svojoj prirodi, informacija je nematerijalna. Da bi ostala sačuvana, treba je

materijalizirati, odnosno zapisati. Taj se zapis zove podatkom:

Podatak je skup prepoznatljivih znakova na određenom mediju.

Obrnuto gledano, informacija je protumačeni podatak, koji primatelju donosi novost,

čiju vrijednost on sam mora procijeniti ( M. Varga, «Baze podataka», DRIP, 1994).

Informacijski sustav možemo podijeliti na sastavnice:

- Sklopovsku podršku ( Hardware )

- Programsku podršku ( Software )

- Ljudske resurse ( Humanware )

- Organizacijske metode i postupke ( Orgware )

Programska podrška se, pak, dijeli na sistemsku i primjenjenu ili aplikacijsku

programsku podršku. Nije jednostavno povući strogu granicu između ove dvije vrste

programske opreme, no kažimo da sistemsku podršku sačinjavaju programi koji

6

osiguravaju rad računalnog sustava kao cjeline. Naime, računalni hardver je prvi

proizvod stvoren ljudskim umom i rukama, koji je toliko univerzalan, da sam, bez

programske podrške, praktično nije ni od kakve koristi. Potrebano ga je instruirati,

mogli bismo kazati «naučiti» da obavlja koristan posao. U tom postupku instruiranja

hardvera, uočene su i podijeljene po kategorijama različite vrste poslova. Tako,

računalni hardver mora prepoznati pritiske na tipke tipkovnice, prikazati na opremi za

ispis, kao što su monitori, znakovne i slikovne poruke itd. Isto tako, računalni hardver

se često koristi za istovremeno izvođenje različitih zadataka, te za pamćenje podataka

u radnoj memoriji i vanjskim jedinicama za masovnu pohranu podataka. Kako će

računalni hardver obaviti ovu vrtstu osnovnih poslova, instruira ga programska

podrška koju nazivamo operacijski sustav. Nadalje, račuanlni sustav koji obavlja gore

navedene poslove još uvijek nija iskoristiv u svakodnevnom poslu, jer ljudima treba

pomoć u obavljanju konkretnih, strogo definiranih poslova. Lepeza tih poslova je vrlo

široka, a svaki pojedini posao traži strogo definirane postupke, pa proizvođači

računalnih sustava, dakle hardvera i sistemske podrške nisu u stanju definirati sve

detalje aplikativnih postupaka. Njih definiraju, te instruiraju računalo kako da ih

obavi, kreatori primjenjene ili aplikativne programske podrške. S druge pak strane,

ako bi kreatori aplikacije morali voditi računa o svim detaljima rada računalnog

sustava, kao spremanjem podataka na medije za masovnu pohranu, njihovim

pretraživanjem , ispisom na ekranske forme i izvještaje, od silnog posla i

mnogobrojnih detalja koji moraju biti razrađeni do najsitnijih potankosti, nebi imali

vremena i mogućnosti usredotočiti se na sam problem koji rješavaju. Osim toga,

edukacija ljudi koji bi morali znati sve, počev od rada hardvera do detalja, do

tehnološkog posla kojeg informatiziraju, uzela bi toliko vremena, da bi vjerojatno

učili do mirovine.

Pojasnimo to primjerom: Želimo izraditi informacijski sustav koji bi automatizirao

rad studentske referade, od upisa studenta na fakultet, preko prijave i polaganja ispita,

do izdavanja diplome. Vjerojatno na svakom fakultetu u Hrvatskoj postoje razlike u

postupku prijave ispita. Štoviše, čak i na jednom fakultetu neke je ispite potrebno

prijaviti četiri dana ranije, radi rezerviranja dvorane za ispit, do organizacije putovanja

nastavnika iz drugog grada, dok se drugi ispiti, recimo iz izbornih predmeta, koje

sluša svega nekoliko studenata, ispitni termin dogovara s nastavnikom i nije potrebana

7

rezervacija dvorane. Nadalje, postupak prijave ispita u Kini i Hrvatskoj se sigurno

razlikuje uzme li se u obzir broj studenata na sveučilištima.

Očito je, da nije moguće izraditi jedinstvenu aplikaciju u prihvatljivom vremenu i po

isplatljivoj cijeni, koja bi informatizirala rad studentske referade u Kini i Hrvatskoj. S

druge pak strane, spremanje podataka na magnetski medij trebaju kreatori aplikacija u

obje zemlje. Stoga je tržište odredilo specijalizaciju poslova, pa je moguće proizvesti

identičanu programsku podršku koja će spremati i pretraživati podatke, kako za

aplikaciju u Kini, tako i u Hrvatskoj. Štoviše, ljudi specijalizirani za poslove

spremanja podataka, toliko su ušli u detalje tog problema, da ga mogu riješiti brže i

bolje nego li bi mogao univerzalni programer, koji bi morao voditi računa o svim

aspektima računalnog sustava i tehnologije koja se automatizira. Nadalje, dobar

proizvod kojeg su napravili specijalisti, prodaje se s takvom tiražom da su njegvi

autori visoko stimulirani, a kupcima je cijena prihvatljiva. Nadalje, specijalizirani opći

posao spremanja podataka na magnetski medij trebaju kreatori različitih aplikacijskih

programa, pa su tijekom vremena pronađeni presjeci poslova, koji su identični svakoj

aplikaciji tog tipa.

Prema izloženoj logici su nastali specijalizirani programi za obavljanje općih poslova

vezanih uz rad informacijskog sustava, te primjenjeni programi, koji koriste njihove

programske usluge i obavljaju poslove koje ljudi trebaju u konkretnom, strogo

određenom poslu.

Iskustveno znamo da je ljudima značajna informacija, koja mora biti prikazana na

podesan način. Na primjer, zanima nas broj permutacija šest znamenkastog broja

123456, ali često nas ne zanima kako je rezultat izračunat, samo gotovi rezultat. Ako

će netko napraviti program za izračunavanje broja permutacija – operaciju «faktorjel»,

on će to napraviti općenito, recimo za izračunavanje broja faktorjela Fakt(x), pri čemu

je x ulaz u program, koji će izračunati izlaz y i prikazati ga na monitoru računalnog

sustava:

y = Fakt(x)

Dakle, program, bio on jednostavan ili složen, na temelju ulaza izračunava izlaze.

Korisnike zanimaji izlazi, a da bi ih dobili moraju program snabdjedi traženim

ulazima. Program može imati veći broj ulaza, te izračunati veći broj izlaza. Označimo

li s X skup svih ulaza, te s Y skup svih izlaza, program f transformira ulaze u izlaze:

8

Y = f(X)

Neki ulazi mogu biti zadani ad hock, neposredno prije izračunavanja izlaza, kao u

primjeru izračunavanja faktorjela. No, mnogo je češći slučaj kada izlazni odziv nije

moguće dobiti odmah. Pretpostavimo da tražimo posao preko interneta. Jedan mogući

pristup je: prijavimo se u neki «chat-room» i unesemo poruku:

«Zovem se Toni, tražim posao programera u programskom jeziku C# itd.»

Nakon nekoliko sekundi poruka bi nestala s ekrana i trebali bismo je ponoviti svako

nekog vremena. Vrlo nepraktično i s minimalnim izgledima na uspjeh, jer je malo

vjerojatno da će se u isto vrijeme u istom «chat-roomu» naći i osoba iz tvrtke koja

traži čovjeka sa znanjem dot.net i C#, a sigurno je danas to tražena specijalnost.

Mnogo prikladniji način traženja angažmana je ako možemo pohraniti podatke o sebi

i svom znanju, te da oni budu na raspolaganju onima koji trebaju programere, tako

dugo dok naša potraga traje. U ovom slučaju, program će generirati izlaze na temelju

dvije vrste ulaza:

- ranije unijetih i pohranjenih ( podaci naše ponude )

- zadanih neposredno prije izvođenja programa ( podaci potrage )

Označimo li s X skup ulaznih podataka kod izvođenja programa, sa Z skup ranije

unijetihi pohranjenih ( perzistentnih ) ulaza, izlazni podaci Y će biti generirani

transformacijom ulaza X i Z:

Y = f( X, Z )

Bazu podataka možemo shvatiti kao elektroničko skladište za pohranu podataka, koji

će biti korišteni kao programski ulazi s odgodom. Kako je moguće predvidjeti i

generalizirati poslove spremanja te pretraživanja pohranjenih ulaznih podataka, to je

bilo moguće kreirati programski sustav za obavljanje ovih poslova. U početku je

kreator aplikacije koristio unaprijed napravljene programe koji su zapisivali i čitali

podatke na magnetski medij u obliku datoteka. Ove usluge su stavljali na raspolaganje

operacijski sustavi. Kreator aplikacije je morao voditi računa o zapisivanju i čitanju

svakog pojedinog znaka. Vremenom su stvoreni specijalizirani programi za

upravljanje «elektronskim skladištem» podataka.

Vjerojatno je svatko od nas koristio usluge garderobe na putovanjima. Osoblje

garderobe prima od nas prtljag na pultu, sprema ga na police, izdaje nam potvrdu i

9

kod podizanja prtljaga vrlo brzo ga pronađe i izruči. Uočio sam da u velikim

garderobama pitaju putnike: «Kada ćete podići?». Odgovorio sam «Za 2-3 sta». Onda

su moj prtljag stavili na policu sasvim blizu primopredajnog pulta. Ja im ništa nisam

govorio o tome kako i gdje će spremiti moje putne torbe. Jedna dama je kazala, kako

će trebati svoj prtljag tek za 7 dana, pa su njen spremili na udaljenu policu, na samom

kraju skladišta. Zaključio sam kako oni vode računa o spremanju prtljaga, a mi im

samo kažemo što trebamo.

Na sličan način rade i sustavi za upravljanje bazom - «elektronskim skladištem»

podataka. Kreator aplikacije im preda podatke na «pultu», oni ih spreme i sami vode

računa o organizaciji podataka, kako bi ih brzo pronašli, te nam ih ponovno predaju

na «pultu» kada ih trebamo. Štoviše, iste spremljene podatke mogu transformirati i

predati nam u različitim oblicima, poredane na jedan ili drugi način, baš kako ih u

datom momentu zahtijevamo.

Baza podataka je elektroničko skladište podataka zapisanih na mediju za

masovnu pohranu, pri čemu su podaci tako organizirani da se lako i brzo

pronađu i to u onom opsegu koji zadovoljava postavljeni kriterij, te prezentiraju

u pogodnom obliku. Spremanjem, pronalaženjem i sortiranjem podataka

upravlja poseban programski sustav: DBMS ( database management system).

Karakteristika baze podataka je:

1. velika količina podataka

2. znatan broj dnevnih promjena

3. različite razine izvještaja, kao:

- detaljni podaci

- sumarni podaci

- izračunati podaci

1.2 Vrste baza podataka

Prema stupnju usluge u smislu spremanja, održavanja, čitanja i pretraživanja podataka

koju kreator aplikacije dobija od ugrađene programske opreme, te načinu organizacije

podataka, baze možemo podijeliti na datotečne, hijerarhijske, mrežne, relacijske i

objektne.

10

1.2.1 Datotečna baze podataka

Najstarije baze podataka koristile su datotečni sustav i to:

- sa sekvencijalnim pristupom

- sa slučajnim pristupom

Osnovna karakteristika datotečnih baza je, da je sustav za upravljanje datotekama

kreatoru aplikacije pružao vrlo skromnu uslugu. U pravilu, kreiranje i uništavanje

datoteke, te pisanje i čitanje. Kreator aplikacije je morao voditi računa o položaju

svakog znaka na disku. Najčešće se podacima pristupalo prema apsolutnom položaju

na disku.

Naročite poteškoće kod velikih datoteka, zadavalo je pretraživanje podataka, koje je u

pravilu radilo sporo, a programeri su morali utrošiti značajno vrijeme i napr da opće

implementiraju pretraživanje. Dakle, glavni napor programera bio je usredotočen na

organizaciju podataka na disku i izradu procedura za spremanje, čitanje, te

pretraživanje zapisa – slogova podataka. Problemi bi tek dolazili s održavanjem i

potrebom naknadnih modifikacija. Dodavanje jednog polja zahtijevalo je pomicanje

slogova, te izmjenu cijelih aplikacija koje sa slogom rade, jer je položaj svakog polja

bio određen apsolutnom pozijom kao npr.: Ime studenta počinje s 35. byte-om sloga i

završava na 64 poziciji.

Kako su programeri imali potpunu slobodu u organizaciji podataka, to je praktično

svaka aplikacija, čak i unutar jedne tvrtke, bila inkompatibilna s drugima. O

povezivanju aplikacija koje rade na različitim sustavima, nije se moglo ni sanjati.

1.2.2 Hijerarhijska baza podataka

Hijerarhijski model podataka nastao je šezdesetih godina, nakon što je IBM razvio

sustav za upravljanje hijerarhijskom bazom IMS/VS, 1968. IMS je razvijen pod MVS

operacijskim sustavom za mainframe računala. Element zapisa podatka je polje

(field), pri čemu skup polja koji opisuju isti objekt čini slog ili rekord. Slogovi su u

odnosu roditelj – dijete, pri čemu niti jedan slog ne može postojati kao dijete, ako za

njega ne postoji roditeljski čvor. Podaci hijerarhiskog modela se organiziraju u stablo:

11

Hijerarhijske veze, te veze roditelj dijete realiziraju se hijerarhijskim i «Child-twin»

pokazivačima.

1.2.3 Mrežna baza podataka

Mrežni model podataka nastao je unapređenjem hijerarhiskog modela. Uočavamo da

zaposlenici Ivan i Ana Perić mogu biti supružnici, te u tom slučaju dijete Hrvoje

Perić može biti dijete kako Ivana, tako i Ane Perić:

Mrežni model implementira mogućnost pripadnosti jednog čvora u hijerarhiji većem

broju nadređenih čvorova. Jednako tako, svaki roditeljski čvor može imati više djece.

Veze isprepletene na ovaj način tvore mrežu, po čemu je mrežni model dobio ime.

1.2.4 Relacijska baza podataka

Programski sustav za upravljanje relacijskom bazom podataka RDBMS ( Relational

database management system) nastao je kao implementacija pravila relacijskog

modela podataka, koje je definirao Codd 1971. godine. Naravno, tijekom vremena,

Poduzeće

Zaposlenik: Ante Ivić 1958

Zaposlenik:Ivan Perić 1946 Zaposlenik: Ana Perić 1949

Dijete : Ivo Ivić 1980

Dijete: Hrvoje Perić 1981

Dijete: Ana Ivić 1980

«Child-twin» pokazivač

Zaposlenik:Ivan Perić 1946

Zaposlenik:Ana Perić 1946

Dijete: Hrvoje Perić 1981

12

kako je raslo iskustvo i uočavane potebe, RDBMS je evoluirao, te danas postoje na

tržištu programska rješenja koja omogućuju pridržavanje svih pravila relacijskog

modela, a da istovremeno odzivna vremena budu zadovoljavajuća, sve

«nestrpljivijim» pretražiteljima baza. Isto tako, cijena programske opreme, iskazana u

$/transakciji ( provedenoj operaciji ) za cjelokupnu instalaciju je sasvim prihvatljiva.

Relacijski model je skup pravila koji mora biti zadovoljen kod projektiranja baze

podataka. Isto tako, Codd je definirao operacije nad relacijskim modelmom, koje

kasnije implementira upitni jezik SQL ( Structured Query Language). Uspjeh

relacijskog modela leži u činjenici njegove utemeljenosti na dva dobro definirana

područja matematike: teoriji skupova i matematičke logike.

1.2.5 Objektna baza podataka

U posljednjem desetljeću je objektni pristup promatranja i analize aplikacijskih

zadataka, te oblikovanja programskih rješenja, istisnuo raniji proceduralni pristup.

Glavna razlika ova dva pristupa proizlazi iz činjenice, da su u realnom svijetu objekti

opisani svojim atributima, te znaju izvršavati određene metode. Proceduralni pristup

nas uči da usredotočimo svoju pažnju na niz koraka kojima se rješava programski

problem. Nasuprot tome, objektni pristup upućuje koncentraciju kreatora objektnog

modela na atribute i metode objekata iz realnog okruženja. Dakle, objektni pristup je

bliži mišljenju u realnom svijetu, gdje objekti surađuju jedan s drugim, pri čemu je

važno sučelje njihove interakcije, a manje su važni mehanizmi koji transformiraju

ulazne podražaje u izlazne reakcije.

Oslikajmo gornju ideju primjerom: na ulicama New York-a već dvadesetih godina

prošlog stoljeća su bili postavljeni automati za automatsku prodaju osvježavajućih

pića ( i duhanskih proizvode, koji su jako štetni po ljudsko zdravlje, no to tada njihova

prodaja na ovaj način, nije bila zabranjena ). Automat komunicira s kupcem preko

tipki za izbor pića, te «prozora» za ubacivanje i povrat novca. Automati korišteni prije

80 godina su bili potpuno mehaničke naprave, a današnji koriste mikroračunala. No

kupcu je svejedno, jer sučelje preko kojeg komunicira s automatom je praktično

nepromijenjeno svih ovih godina: uvijek je to tipka sa slikom i natpisom pića koje

naručuje.

13

Ideja objektno oblikovanog programa leži u dobro definiranom sučelju preko kojeg

pozivač snabdjeva programski objekt ulazima i od njega dobija izlaze. Procedura

obrade ostaje skrivena unutar pozvanog objekta. Upravo izrečeno, zapravo je ideja

strukturnog programiranja, jedino objektni model donosi dobro definiran odnos među

objektima, poboljšava komunikaciju među objektima preko interfejsa, te što je

najvažnije, programske prevoditelje koji implementiraju objektni programski model.

Objektni pristup unapređuje timsku izradu softvera, te povećava mogućnost ponovne

upotrebe već napisanog koda ( eng. reusebility ).

Karakteristike objektnog programskog model su:

Enkapsulacija – program pozivač ( klijent ) pristupa pozvanoj strukturi (poslužitelju)

isključivo preko svojstava ( property ) programskog sučelja, te pozivom izloženih

metoda. Drugim riječima, neke varijable i procedure poslužiteljskog objekta su

dostupne pozivaču, dok su druge skrivene. Kreator poslužiteljskog objekta u

potpunosti kontrolira prava pristupa.

Nasljeđivanje – objekti se nalaze u jednom od dva moguća odnosa:

- jedna vrsta od ( a kind of )

- jedan dio od ( a part of )

Pojasnimo primjerom: Osoba je opisana imenom, prezimenom i datumom rođenja.

Student je jedna vrsta osobe, pa prema tome ima sve značajke osobe, ali povrh toga je

njegova značajka godina studija koju pohađa. Zaposlenik je isto tako osoba, koji

dodatno ima atribute: datum zaposlenja i plaća. Umirovljenik je osoba, čiji je

specifičan atribut iznos mirovine ( drukčija poreska opterećenja u odnosu na plaću

zaposlenika ).

U objektnom programskom modelu se definira prototip – klasa – Osoba, s atributima

ime, prezime i godina rodjenja. Zatim klasa Student nasljeđuje sva svojstva osobe i

njima dodaje specifičnost studenta – godina studija. Shodno tome, Zaposlenik

nasljeđuje svojstva Osobe i dodaje datum zaposlenja i plaću, dok Umirovljenik

nasljeđuje svojstva Osobe i dodaje mirovinu. Naravno, moguće je da netko «studira

uz rad», pa bi objekt ZaposleniStudent nasljedio svojstva Zaposlenika i Studenta.

14

Dobitak ovakovog pristupa se iskazuje i tijekom razvoja klasa i tijekom održavanja.

Naprimjer, ako klasa Osoba podržava metodu Godine starosti na dan, uz ulazni

parametar Datum, onda se metoda implementira samo jednom, a koristi kod

izračunavanja godina starosti u svakoj od nasljeđenih klasa. Dodatno, naslijeđene

klase mogu neke metode polaznih klasa nadjačati, pa se istim pozivom, zapravo

odrađuje druga metoda specifična toj klasi.

Polimorfizam – sposobnost korištenja istog izraza za izvođenje različitih operacija.

Osnov ovog svojstva je poznat od najranijih programa. Zbrajamo li cijele brojeve, to

se obavlja drukčijom metodom, nego kad zbrajamo brojeve u tekućem zarezu.

Objektno programiranje je dosljedno, pa kreator klase određuje način izvršavanja

izraza. Uzmimo na primjer klasu Boje. Poznato je da miješanjem npr. žute i plave

boje dobijemo zelenu. Klasa boje može promijeniti značenje operatora plus (+) i dati

kao rezultat zelenu boju, kad god se zbrajaju žuta i plava.

Poruke – objekti komuniciraje putem poruka. Najčešće se implementira kao

pridjeljivanje vrijednosti svojstvima ( set – get property) i funkcijskim pozivima.

Postojanost (eng. Persistence) - Gore izrečena svojstva odnose se na paradigmu

objektog programiranja. Objektna baza mora implementirati gornja svojstva, ali isto

tako implementirati svojstvo postojanosti ( perzistencije) velike količine podataka.

Dakle, zapisati, čitati i pretraživati vrijednosti atributa svake instance objekta na

mediju za masovnu pohranu podataka.

Koliko je autoru ovih redaka poznato, za sada ne postoji stroga, formlno prohvaćena

definicija objektne baze. Doduše, mnogi proivođači sustava za upravljanje bazom

podataka tvrde da su njihove baze objektne, ali je teško ići u ocjenu opravdanosti

takva naziva, dok se ne prihvati formalna definicija što je objektna baza.

15

2 Relacijski model podataka

Osnovne principe i strukturu relacijskog modela podataka iznio je 1971. matematičar

E.F. Codd, u to vrijeme član «IBM San Jose Research Laboratory». Najveća prednost

relacijskog modela podataka je njegova utemeljenost na matematičkoj teoriji

relacijske algebre ( R. Vujnović: SQL i relacijski model podataka, Znak 1995.).

Prije iznošenja definicija i pravila relacijske algebre, najprije krenimo s primjerom, na

kome ćemo ilustrirati maljkavosti mogućeg rješenja, koje se otklanjaju primjenom

relacijskih pravila.

2.1 Mala knjižara

Kako je rečeno u definicijama informacijskog sustava i baze podataka, nije nužno da

informacijski sustav bude podržan informacjskom tehnologijom. Pretpostavimo

potrebu informacijskog sustava, dakle određenog ustroja, zapisivanja i korištenja

informacija male trgovine knjigama. Raspoloživih naslova je tako mali broj, da se sve

pregledno i bez napora može voditi olovkom na papiru.

Knjižara «FOKUS» prodaje mali broj naslova različitih izdavača. Svaki naslov je

tiskan od strane samo jednog izdavača, ali jedan izdavač može izdati više naslova. IS

mora raspolagati adresnim podacima izdavača, radi održavanja kontakata, poštom i

telefonom. Naslov je napisan od strane jednog ili više autora. Potrebano je raspolagati

podacima o autoru kao što su Ime i Prezime.

Luka, vlasnik i prodavač u knjižari, je na papiru napravio tablicu i pregledno unio

slijedeće podatke:

Tablica:Knjige1

Red. broj Naslov Izdava č Pošta Mjesto Ulica i kbr Telefon Autori

1 Baze podataka DRIP 10000 ZAGREB Ilica 121 01/123-456 Mladen Varga

2 SQL i relacijski model podataka ZNAK 10000 ZAGREB Vukovarska 56

01/413-8567

Ratko Vujnović

3 ORACLE 7 ZNAK 10000 ZAGREB Vukovarska 56 01/413-8567 Darko Hrenić

4 Dalmatinska kuhinja LOGOS 21000 SPLIT Narodni trg 4

021/345-678

Ankica Biluš, Marija Rode

5 Dalmatinski kolači LOGOS 21000 SPLIT Narodni trg 4 021/345-678

Ankica Biluš, Tanja Kesić

16

Luka prve probleme uočava nakon saznanja da je ZNAK preselio na novu adresu:

Maksimirska 161, te da je izmijenjeni telefonski broj: 01/656-7879. Morao bi u

svakom retku, gdje se pojavljuju ove informacije o izdavaču ZNAK, mijenjati. Čim bi

knjižara prodavala veći broj Znakovih naslova, Luka bi uočio maljkavost svog modela

podataka, jer bi morao u mnogo redaka brisati stare i upisivati nove podatke.

Luka ocjenjuje svoj model podataka i nalazi.

Nedostatak: isti podatak o izdavačima je zapisan više puta, što ga izluđuje kod

izmjena podataka. Već mu je na vrh glave brisanja i upisivanja potpuno istog podatka

u mnogo redaka. Stoga zaključuje: podijelit ću jedinstvenu tablicu Knjige1 u dvije

tablice i to Knjige2 i Izdavači2, tako da svi podaci o izdavaču budu napisani samo

jednom, pa će izmjenu adrsnih podataka izdavača, morati mijenjati na samo jednom

mjestu.

Prednost: Sve informacije o jednoj knjizi su lako dostupne, čim se pronađe knjiga,

odmah može pročitati izdavač i autore.

Tablica:Knjige2

Red. broj Naslov Izdava č Autori

1 Baze podataka DRIP Mladen Varga 2 SQL i relacijski model podataka ZNAK Ratko Vujnović 3 ORACLE 7 ZNAK Darko Hrenić

4 Dalmatinska kuhinja LOGOS Ankica Biluš, Marija Rode

5 Dalmatinski kolači LOGOS Ankica Biluš, Tanja Kesić

Tablica: Izdavači2

Izdavač Pošta Mjesto Ulica i kbr Telefon DRIP 10000 ZAGREB Ilica 121 01/123-456 ZNAK 10000 ZAGREB Vukovarska 56 01/413-8567 LOGOS 21000 SPLIT Narodni trg 4 021/345-678

Nadalje, Luka uočava da je mjesto odmah jednoznačno određeno, čim je poznat

poštanski broj, dakle 10000 je ZAGREB, a 21000 SPLIT, pa odlučuje uštedjeti papir i

napraviti novu tablicu Pošte, te iz tablice Izdavači ukloniti kolonu Mjesto.

17

Tablica:Knjige3

Red. broj Naslov Izdava č Autori

1 Baze podataka DRIP Mladen Varga 2 SQL i relacijski model podataka ZNAK Ratko Vujnović 3 ORACLE 7 ZNAK Darko Hrenić

4 Dalmatinska kuhinja LOGOS Ankica Biluš, Marija Rode

5 Dalmatinski kolači LOGOS Ankica Biluš, Tanja Kesić

Tablica: Izdavači3

Izdavač Pošta Ulica i kbr Telefon DRIP 10000 Ilica 121 01/123-456 ZNAK 10000 Vukovarska 56 01/413-8567 LOGOS 21000 Narodni trg 4 021/345-678

Tablica Pošte3:

Pošta Mjesto 10000 ZAGREB 10000 ZAGREB 21000 SPLIT

Luki se ovo rješenje činilo dobro, sve dok nije odlučio tiskati prospekt o knjigama

koje prodaje. Naime, u prospektu je trebao ispisati bibliografske podatke o svim

autorima koji su napisali knjige. Uočio je veliki problem kod knjiga što su ih napisala

dva ili više autora, te ponavljanje bibliografskih podataka autora u svakom retku. Isto

tako, jedan autor je mogao napisati više knjiga za različite izdavače, s različitim

koautorima. Nije bilo druge, nego iz tablice knjige izdvojiti kolonu autori, a da ne

izgubi vezu između autora i knjiga, napraviti posebnu tablicu u koju će upisivati samo

identifikaciju autora i knjiga. Kako su knjigu istog naslova, npr. SQL, mogli izdati

različiti izdavači, odluči knjigu identificirati naslovom i nazivom izdavača:

Tablica:Knjige4

Red. broj Naslov Izdava č

1 Baze podataka DRIP 2 SQL i relacijski model podataka ZNAK 3 ORACLE 7 ZNAK 4 Dalmatinska kuhinja LOGOS

18

5 Dalmatinski kolači LOGOS

Tablica: Izdavači4

Izdavač Pošta Ulica i kbr Telefon DRIP 10000 Ilica 121 01/123-456 ZNAK 10000 Vukovarska 56 01/413-8567 LOGOS 21000 Narodni trg 4 021/345-678

Tablica Pošte4:

Pošta Mjesto 10000 ZAGREB 10000 ZAGREB 21000 SPLIT

Tablica: Autori4

Ime Prezime Datum ro đenja Mladen Varga Ratko Vojnović Darko Hrenić Ankica Biluš Marija Rode Tanja Kesić

Tablica: Knjige_Autori4

Red. broj Naslov Izdava č Autor_ime Autor_prezime 1 Baze podataka DRIP Mladen Varga

2 SQL i relacijski model podataka ZNAK Ratko

Vujnović

3 ORACLE 7 ZNAK Darko Hrenić 4 Dalmatinska kuhinja LOGOS Ankica Biluš 4 Dalmatinska kuhinja LOGOS Marija Rode 5 Dalmatinski kolači LOGOS Ankica Biluš 5 Dalmatinski kolači LOGOS Tanja Kesić

Na kraju, Luka uočava da bi značajno štedio papir i trud oko upisivanja u tablicu

Knjige_Autori4, ako bi tablicu povezao s Knjige4 služeći se rednim brojem knjige.

19

Nažalost, prednost polazne tablice Knjige1, da svi podaci o knjizi budu pregledni i

lako dostupni više nije očuvana. Srećom, računalo može obavito ovo povezivanje brzo

i lako, te je Luka odlučio naučiti pravila relacijskog modela i upotrijebiti programski

sustav za upravljanje relacijskom bazom.

2.2 Pojmovi relacijskog modela podataka

Entitet je sve ono o čemu želimo i možemo skupljati informacije i čije se pojave

mogu međusobno razlikovati ( identificirati).

Tako na primjer, studenti jesu entitet jer razlikujemo svakog studenta imenom,

prezimenom, datumom rođenja. Kamenčići na pješčanoj plaži nisu entitet, jer ne

možemo razlikovati svakog od njih.

( Riječ entitet posuđena je iz latinskog jezike i znači: ens = biće, summ = jesam,

esse=biti, i znači bitnost, ono što jest)

Neki autori razlikuju pojmove entitet i tip entiteteta, smatrajući svaku pojavu objekta

entitetom, a prototipsku definiciju – klasu - tipom. Tako je Ivo Ivić, rođen 22.06.1981.

entitet, a prototip ime, prezime, datum rođenja tip entiteta.

Atribut – opisuje svojstva entiteta. Svaki entitet opisan je skupom atributa. Tako je

osoba opisana imenom, prezimenom, datumom rođenja. Svaki atribut može primiti

jednu vrijednost: ime=Ivo, prezime=Ivić, datum rođenja=22.06.1981.

Domena – je imenovani skup svih mogućih ( dopuštenih ) vrijednosti jednog atributa.

Očito su onda moguće pojave entiteta Kartezijev produkt svih domena.

Tako Hrvatska pošta katalogizira poštanske brojeva u Hrvatskoj, dakle definira

domenu poštanskih brojeva, a Državni sabor je donio Zakon o registraciji trgovačkih

društava, definirajući moguće djelatnosti koje ova mogu obavljati, dakle domenu

djelatnosti.

Odgovor na pitanje: koje djelatnosti mogu biti obavljane u mjestima Hrvatske (svako

mjesto za razliku od naselja ima poštanski broj) ćemo potražiti u Kartezijevom

produktu pošta i djelatnosti, jer koliko je meni poznato, svaka djelatnost zakonski

može biti obavljana u svakom mjestu. Naravno da skup postojećih pošta i djelatnosti

predstavlja podskup Kartezijevog produkta.

20

Relacija je imenovani podskup Kartezijevog produkta domena:

Neka su Di domene atributa Ai, te neka su di elementi domene Di. Tada je relacija R

podskup Di x Dj, pri čemu je i, j=1,2,3 … n & i <> j, gdje je n broj atributa entiteta.

Relacijska shem R sastoji se od naziva relacije i konačnog skupa (naziva) atributa

odnosno stupaca ( A1, A2, … An ), koji opisuju istoimenu relaciju.

Uobičajeni način pisanja relacijske sheme je R(A1,A2, … An), odnosno, R(A1:D1,

A2:D2, … An:Dn).

Ime relacije mora biti jedinstveno, jednako kao i imena atributa iste relacije.

Redoslijed atributa relacije nije bitan.

N-torka je jedan element iz skupa Kartezijevog produkta svih atributa. U relaciji ne

mogu postojati dvije identične n-torke.

Klju č relecije je minimalni skup atributa čije vrijednosti jednoznačno identificiraju

svaku n-torku relacije.

Klju č relacije R skup je atributa K iz R, tako da svake dvije n-torke r1 i r2 relacije R

imaju različite vrijednosti atributa K, tj. da je r i(K)=tj(K), samo za i=j.

Relacijska shema baze podataka je skup relacijskih shema.

Relacijska baza podataka je skup relacija definiranih relacijskom shemom baze

podataka.

U praksi je uobičajeno korištenje pojmova implementacijske razine:

tablica – je fizička implementacija relacijske sheme

kolona – implementacija atributa

redak – implementacija n-torke

2.3 Relacijska algebra

Relacijska algebra definira skup formaliziranih operacija nad relacijama. Rezultat bilo

koje operacije je relacija. Neke od operacija dobro su poznate u teoriji skupova.

Osnovne operacije su:

- unija

21

- razlika

- Kartezijev produkt

- projekcija

- restrikcija

- prirodno i theta spajanje

- presjek

- dijeljenje

Unija

Unija dviju unijski kompatibilnih relacija R(A1, A2, … An) i S(A1, A2, … An) je

nova relacija T(A1,A2, … An) koja se sastoji od svih n-torki sadržanih u R i S.

Studenti1:

Ime Prezime Ivo Ivić Ana Marić Josip Petrić

Studenti2:

Ime Prezime Luka Dadić Ana Marić

Studenti1_UNIJA_Studenti2:

Ime Prezime Ivo Ivić Ana Marić Josip Petrić Luka Dadić

Razlika

Razlika – diferencija dviju unijski kompatibilnih relacija R(A1,A2, … An) i S(A1,A2,

… An) je nova relacija T(A1,A2, … An) koja obuhvaća sve n-torke iz R, koje nisu

sadržane u S.

22

Studenti1:

Ime Prezime Ivo Ivić Ana Marić Josip Petrić

Studenti2:

Ime Prezime Luka Dadić Ana Marić

Studenti1_MINUS_Studenti2:

Ime Prezime Ivo Ivić Josip Petrić

Studenti2_MINUS_Studenti1:

Ime Prezime Luka Dadić

Kartezijev product dviju relacija R(A1,A2, … An) i S(B1,B2, … Bm) je nova

relacija T(A1,A2, … An,B1,B2, …Bm) koja se sastoji od n-torki nastalih spajanjem

svake n-torke relacije R sa svakom n-torkom relacije S. Jasno je, broj n-torki u novoj

relaciji T produkt je broja n-torki u R i S.

Projekcija relacije R nova je relacija T koja se sastoji od atributa relacije R po kojima

je obavljena operacija projekcije i u kojoj su uklonjene jednake n-torke.

R(A1,A2,A3,A4) � ( A1, A3 ) � T(A1,A3)

Restrikcija relacije R(A1,A2, … An) je nova relacija T(A1,A2, …An) koja se sastoji

od n-torki relacije R koje ispunjavaju zadani uvjet.

Spajanje - Theta-spoj je restrikcija Kartezijevog produkta relacija R i S opisana

formulom A<operator>B, gdje je A atribut relacije R, a B atribut relacije S.

23

Vanjsko spajanje - operacija vanjskog spoja relacija R i S je nova relacija T, koja je

jednaka operaciji spoja R i S, uz dodatak n-torki iz relacija R i S koje nisu sadržane u

spoju. Te n-torke su popunjene null-vrijednostima na mjestima nedostajućih atributa.

2.4 Coddova pravila

Radi izbjegavanja nesuglasja oko toga koji sustav za upravljanje bazom podataka je, a

koji nije relacijski, Codd je 1985. definirao 12 pravila od kojih barem 6 sustav mora

ispunjavati, kako bi se smatrao relacijskim. Za nas su značajna ova pravila, kako

bismo razumjeli što podržava relacijska baza i kako bismo mogli iskoristiti njene

mogućnosti, kod projektiranja relacijske baze podataka. Drugim rječima,

narušavanjem ovih pravila postupkom projektiranja aplikacijske baze, naša baza ne

može nositi atribut relacijska, iako koristimo relacijski sustav za upravljanje bazom.

Pravilo 0: Bilo koji sustav za upravljanje bazama podataka koji se smatra relacijskim,

mora upravljati bazom podataka na potpuno relacijski način i relacijskom metodom.

1. Predstavljanje informacija: Sve informacije u relacijskoj bazi podataka logički

su predtavljene isključivona jedan način: vrijednostima u tablicama, tj. relacijama

2. Obvezna logička dostupnost: Svaka najmanja vrijednost ( atom informacije, tj,

jedna vrijednost atributa u jednoj n-torci) u relacijskoj bazi mora biti logički

dostupna preko kombinacije imena relacije, vrijednosti promarnog ključa i imena

atributa.

3. Prezentacija nepostojeće informacije: Relacijska baza podataka mora

podržavati koncept Null vrijednosti, neovisno o tipu podatka. Pod pojmom Null

vrijednosti se podrazumijeva vrijednost atributa koja nije poznata u datom

vremenskom trenutku.

4. Dinamički on-line katalog: Na lokalnoj razini baza podataka opisana je na isti

način kao i obični podaci, tako da ovlašteni korisnici mogu koristiti isti upitni

jezik za pretraživanje strukture baze, opisa objekata baze, kao i za pretraživanje

podataka.

5. Sveobuhvatni jezik za manipulaciju podacima: Relacijski sustav mora

podržavati najmanje jedan jezik čiji se izrazi pomoću dobro definirane sintakse,

mogu prezentirati kao nizovi znakova i koji mora podržavati:

24

- definiranje podataka

- definiranje pogleda

- manipulaciju podacima ( interaktivno i iz aplikacije)

- ograničenja vezana uz integritet podataka

- autorizaciju orisnika

- upravljanje transakcijama

6. Ažuriranje pogleda: Svi pogledi koji se po relacijskoj teoriji mogu ažurirati,

moraju se moći ažurirati i u implementiranom modelu ( tablicama na kojima se

pogled temelji).

7. Visok nivo unosa, ažuriranja i brisanja: Svojstvo manipulacije relacijom ili

pogledom kao običnim operandom mora biti moguće ne samo kod pretraživanje,

već i pri unosu, ažuriranju i brisanju podataka.

8. Fizička neovisnost podataka: Aplikacije i aktivnosti koje korisnik poduzima

prema bazi potpuno su neovisne o metodi pristupa ili o strukturi spremanja

podataka.

9. Logička neovisnost podataka: Aplikacije i aktivnosti koje korisnik poduzima

prema bazi, ostaju nepromjenjene kad god je učinjena promjena na relacijama

koja je po teoriji dopuštena i koje ne narušava neovisnost podataka.

10. Neovisnost integriteta: Ograničenja na integritet podataka ne smiju biti dio

aplikacije već moraju biti sadržana u katalozima baze.

11. Neovisost distribucije: : Bez obzira na to, podržava li sustav distribuciju ili ne,

jezik sustava mora biti takav da podržava distribuciju bez uticaja na aplikativne

programe.

12. Pravilo o nesubverzivnosti: Ako sustav podržava jezik niskog nivoa, taj jezik ne

smije biti korišten da bi se zaobišla ili ignorirala pravila o integritetu.

25

2.5 Ograni čenja relacijskog modela

Ograničenja su definirana kako bi se podržala ispravnost i istinitost podataka. Pravila

se nazivaju i pravilima integriteta podataka.

Važno je imati na umu, da dobar informacijski sustav počiva na dobro definiranoj

bazi podataka. Baza se pak temelji na dobro definiranom modelu podataka. Ključni

činitelj dobrog modela podataka su ispravno uočena i provedena ograničenja.

Ograničenja dijelimo na:

- ograničenja strukture

- ograničenja ponašanja

2.5.1 Ograni čenja strukture

Ograničenja strukture nasljeđuju se iz definicije relacijskog model i izražavaju

specifična svojstva elemenata relacijskog modela.

Ograničenje domene – definira skup vrijednosti koje može primiti neki atribut.

Provodi se definiranjem:

- Minimalne i maksimalne vrijednosti atributa

- Uvjetom koji vrijednost mora zadovoljiti

- Nabrajanjem vrijednosti

Ograničenje Null vrijednosti – definira da li vrijednost atributa može biti

nedefinirana. Ako je dopuštena null vrijednost, ne moramo unijeti podatak, a ako nije

dopuštena, često se kaže da je podatak mandatoran – obvezan, nije moguće upisati

redak, ako se ne navede dopuštena vrijednost atributa.

Ograničenje jedinstvenosti ključa ili entitetski integritet – vrijednost primarnog

ključa ne smije biti Null – vrijednost. Isto tako nije moguće unijeti dvije n-torke s

istom vrijednosti primarnog ključa. Ista vrijednost primarnog ključa znači ili da je

unijeta pogrešna vrijednost jednog od atributa koji identificiraju objekt, ili da se radi o

istom objektu ili pak, da skup atributa koji moraju jedinstveno identificirati objekt nije

dostatan.

26

Referencijsko ograničenje ili integritet stranog klju ča – strani ključ u relaciji mora

biti jednak jednoj od vrijednosti u relaciji gdje je on promarni ključ ili pak može ostati

nedefiniran, tj. primiti Null-vrijednost.

Navedena ograničenja odnose se na strukturu podataka.

2.5.2 Ograni čenja ponašanja

Ograničenje ponašanja vodi eliminaciji redudantnosti zapisa, a time olakšanim

promjenama podatka i ušedi prostora za pohranu. Ograničenje ponašanja promatramo

kroz različite tipove ovisnosti. Najvažnije su funkcijska, višeznačna i spojna ovisnost.

2.5.2.1 Funkcijska ovisnost

Neka su A i B podskupovi atributa u relacijskoj shemi R. Funkcijska ovisnost f:A�B

vrijedi onda i samo onda, ako za bilo koje dvije n-torke t1(A) i t2(A) za koje vrijedi

t1(A)=t2(A), istovremeno vrijedi i t1(B)=t2(B). Tada kažemo da A funkcijski

određuje B.

Na primjer, u tablici Knjige1, kad god je poštanski broj 10000, mjesto je Zagreb i kad

god je poštanski broj 21000, određeno je mjesto Split. Kažemo da poštanski broj

funkcijski određuje mjesto.

Definirani su aksiomi za izvođenje funkcijskih ovisnosti:

F1) Refleksivnost: ako je A podskup od B, tada B � A. ( znak � «čitat

funkcijski određuje»)

F2) Proširenje: ako j A� B, tada AC � B.

F3) Aditivnost : ako A � B i A � C, tada A � BC

F4) Projektivnost: ako A � BC, tada A � B.

F5) Tranzitivnost : ako A � B i B � C tada A � C.

F6) Pseudotranzitivnost: ako A � B i BC � D, tada AC � D.

Aksiomi F1, F2 i F6 nazivaju se Armstrongovi aksiomi i oni čine potpuni skup

aksioma, jer se aksiomi F3, F4 i F5 daju izvesti iz njih. Navedene aksiome dobro je

znati jer su temelj za pronalaženje funkcijskih ovisnosti i modifikacije nad strukturom

podataka.

27

2.5.2.2 Višeznačna ovisnost

Neka su A i B disjunktni podskupovi atributa u relacijskoj shemi R i neka je relacijska

shema Z jednaka Z = R – AB. Kažemo da relacija r udovoljava uvjetima višeznačne

ovisnosti (VZO), odnosno A ->>, ako vrijedi: uvijek kada relacija r sadrži n-torke

t1(ABC)=a(b1)(c1) i t2(ABC)=a(b2)(c2), onda mora sadržavati i n-torke

t3(ABC)=a(b1)(c2) i t4(ABC)=a(b2)(c1). Pojasnimo višeznačnu ovisnost primjerom.

Student Sport Jezik Ivić PLIVANJE NJEMAČKI Ivić TRČANJE ENGLESKI Ivić PLIVANJE ENGLESKI Ivić TRČANJE NJEMAČKI

Dakle, student Ivić se bavi sportovima PLIVANJE i TRČANJE; te govori strane

jezike NJEMAČKI i ENGLESKI. Dakle, ukoliko postoji n-torka da se jedan student

(a=Ivić), bavi (b1=PLIVANJEM) i zna (c1=NJEMAČKI), te (b2=TRČANJEM) i

(c2=ENGLESKI), onda moraju postaojati i n-torke

(a=Ivić)(b1=PLIVANJE)(c2=ENGLESKI), kao i

(a=Ivić)(b2=TRČANJE)(c1=NJEMAČKI).

To dokazuje da atributi Sport i Jezik nemaju nikakvih međusobnih ovisnosti, dok

Student funkcijski određuje i Jezik i Sport, pa vrijede višeznačne ovisnosti:

STUDENT ->> SPORT i STUDENT ->> JEZIK

To dokazuje da se mogu pojavljivati redundantni podaci, koji mogu dovesti do

anomalija u ažuriranju baze podataka, zato što moraju postojati sve kombinacije

parova sport – jezik. Anomalija ove vrsti, odnosno ovisnost, riješit će se

«razbijanjem» početne relacije na dvije:

Student Sport Ivić PLIVANJE Ivić TRČANJE

Student Jezik Ivić NJEMAČKI Ivić ENGLESKI

28

Dekompozicija tablica je reverzibilna, to jest, da se prirodnim spajanjem tablica po

ključu student, dobija izvorna tablica kombinacija sportova i jezika.

2.6 Normalizacija

Normalizacija je postupak uklanjanja nepoželjnih funkcijskih ovisnosti, a provodi se

radi postizanja dobrih statičkih i dinamičkih svojstava baze podataka:

- učinkovitost pristupa podacima i jednostavnost njihova pretraživanja

- kontrola nad redundancijom ( višestrukim pojavljivanjem podataka u bazi)

- kontrola nad anomalijama koje se mogu pojaviti kod ažuriranja podataka

Definirano je šest normalnih formi, a u praksi je potrebno i najčešće dovoljno, dovesti

sve relacije u treću normalnu formu.

2.6.1 Prva normalna forma

Relacija se nalazi u prvoj normalnoj formi (1NF) ako je svaki njen atribut atomičan,

što znači da sadrži samo jednu vrijednost, nikako više vrijednosti odvojenih npr.

zarezom. Dvodimenzionalna tablica ima u svakoj ćeliji samo jednu elementarnu

vrijednost, koja se ne može dalje rastaviti bez gubitka smisla informacije. Ključ uvijek

ima jedinstvenu vrijednost, a za svaku njegovu vrijednost može se pojaviti samo jedna

vrijednost neključnog atributa:

Definicija: Relacija se nalazi u prvoj normalnoj formi (1NF) ako su svi neključni

atributi funkcijski zavisni o ključu relacije.

Primjer 1: Čest je slučaj da se cijene artikala vode u Eurima, a prikazuju u Kunama,

množeći iznos u Eurima tečajem Kune:

Tablica:Knjige_0

#Naslov Cijena u EURIMA

Tečaj Kune

SQL 50,00 7,42 Baze podataka 60,00 7,42 DOS 30,00 7,42

Ključ tablice Knjige_0 je Naslov ( # ispred imena označava primarni ključ). Jasno je

da cijena svake knjige ovisi o kojoj se knjizi radi, a to nam jednoznačno određuje

29

naslov knjige. Prema tome, neključni atribut cijena ovisi o ključu. Tečaj Kuna – Euro,

nipošto ne ovise o naslovu knjige, dakle, tablica Knjige_0 nije u prvoj normalnoj

formi. Tablica koja nije u prvoj normalnoj formi ne može se zvati relacijom, jer je po

definiciji relacija barem u prvoj normalnoj formi.

Rješenje: dekomponirati tablicu Knjiga_0 u dvije:

Tablica:Knjige_1

#Naslov Cijena u EURIMA

SQL 50,00 Baze podataka 60,00 DOS 30,00

Tablica:Tečajna_Lista_1

#Datum Tečaj Kune 09.12.2002 7,42

Knjige_1 je u prvoj normalnoj formi, jednako kao i Tečajna_Lista_1.

Primjer 2:

Tablica:Knjige_0

Kataloška oznaka Naslov

Broj strnica Izdavač Pošta Mjesto Autori

1 Baze podataka 162 DRIP 10000 ZAGREB Varga 2 SQL i relacijski

model podataka 419

ZNAK 10000 ZAGREB Vujnović 3 ORACLE 7 780 ZNAK 10000 ZAGREB Hrenić 4 Dalmatinska

kuhinja 420

LOGOS 21000 SPLIT Biluš Rode

5 Dalmatinski kolači

360 LOGOS 21000 SPLIT

Biluš Kesić

U tablici Knjige_0, upisana je adresa izdavača, ali isto tako prezimena svih autora

naslova. Tablica nije u prvoj normalnoj formi, jer podaci u koloni autori nisu atomični

( dakle, niti se ne može utvrđivati funkcijska ovisnost, jer jedan atom može funkcijski

ovisiti, a drugi ne).

30

Rješenje: Rascijepiti neatomične podatke u koloni Autori, dodavanjem redaka za

svakog autora, kako bi u jednoj ćeliji Autor, bude samo jedno prezime.

Tablica:Knjige_0A ( nema primarni ključ)

Kataloška oznaka Naslov

Broj stranica Izdavač Pošta Mjesto Autor

1 Baze podataka 162 DRIP 10000 ZAGREB Varga 2 SQL i relacijski model

podataka 419

ZNAK 10000 ZAGREB Vujnović 3 ORACLE 7 780 ZNAK 10000 ZAGREB Hrenić 4 Dalmatinska kuhinja 420 LOGOS 21000 SPLIT Biluš 4 Dalmatinska kuhinja 420 LOGOS 21000 SPLIT Rode 5 Dalmatinski kolači 360 LOGOS 21000 SPLIT Biluš 5 Dalmatinski kolači 360 LOGOS 21000 SPLIT Kesić

Sada imamo atomične podatke, te moramo definirati primarni ključ relacije. Postavlja

se pitanje što određuje atribut Broj stranica? Jasno je da broj stranica knjige ovisi o

Kataloškoj oznaci. Ključ mora imati jedinstvenu vrijednost, a u slučaju kada su jedan

naslov napisala dvojica ili više autora, vrijednost atributa Kataloška oznaka se

ponavlja. Stoga, definirajmo primarni ključ slaganjem atributa Kataloška oznaka +

Autor (Relacija Knjige_1B). Primjetimo, hipotetski slučaj kada bi jedan naslov mogao

napisati samo jedan autor, tada bi ključ mogao biti jednostavan, činio bi ga samo

atribut Kataloška oznaka. ( Relacija Knjige_1A).

Relacija:Knjige_1A ( jednostavan ključ)

#Kataloška

oznaka Naslov

Broj stranica

Izdavač Pošta Mjesto Autor 1 Baze podataka 162 DRIP 10000 ZAGREB Varga 2 SQL i relacijski

model podataka 419

ZNAK 10000 ZAGREB Vujnović 3 ORACLE 7 780 ZNAK 10000 ZAGREB Hrenić 4 Dalmatinska

kuhinja 420

LOGOS 21000 SPLIT Biluš 5 Dalmatinski kolači 360 LOGOS 21000 SPLIT Biluš

31

Tablica:Knjige_1B(složeni ključ)

#Kataloška oznaka Naslov

Broj stranica Izdavač Pošta Mjesto #Autor

1 Baze podataka 162 DRIP 10000 ZAGREB Varga 2 SQL i relacijski

model podataka 419

ZNAK 10000 ZAGREB Vujnović 3 ORACLE 7 780 ZNAK 10000 ZAGREB Hrenić 4 Dalmatinska

kuhinja 420

LOGOS 21000 SPLIT Biluš 4 Dalmatinska

kuhinja 420

LOGOS 21000 SPLIT Rode 5 Dalmatinski kolači 360 LOGOS 21000 SPLIT Biluš 5 Dalmatinski kolači 360 LOGOS 21000 SPLIT Kesić

Svi neključni atributi ovise o ključu, pa možemo kazati da smo doveli relaciju u prvu

normalnu formu ( u oba slučaja).

Usprkos tome što smo relaciju doveli u prvu normalnu formu, uočavamo značajne

anomalije, prije svega u redundantnosti podataka, što vodi nepotrebnom trošenju

medija za spremanje podataka i vrlo je otežano mijenjanje. Dakle, nije dovoljno

dovesti relaciju u prvu normalnu formu.

2.6.2 Druga normalna forma

Zavisnost neključnih atributa o dijelovima ključa je uzrok anomalija. Poželjna je

potpuna funkcijska zavisnost o cijelom ključu, odnosno o svim dijelovima složenog

ključa.

Relacija se nalazi u drugoj normalnoj formi (2NF) ako su svi neključni atributi

potpuno funkcijski zavisni o bilo kojem (mogućem) ključu relacije i to o svim

dijelovima ključa.

Relacija Knjige_1A ima jednostavan ključ, dakle čini ga samo jedan atribut i ona

samim tim zadovoljava pravilo druge normalne forme. Dakle, možemo reći da je

relacija odmah u drugoj normalnoj formi, ako joj je ključ jednostavan.

Relacija Knjige_1B nije u drugoj normalnoj formi, jer neključni atributi Pošta i

Mjesto, doduše ovise o dijelu ključa Kataloški broj, tranzitivno preko Izdavača, ali ne

ovise o dijelu ključa Autor. Isto tako, određeni autor funkcijski određuje Naslov, ali

ne i izdavača, jer isti autor može napisati Naslov i za drugog izdavača.

32

Rješenje: Napraviti pouzdanu dekompoziciju relacije ( reverzibilnu), tako da se

neključni atributi koji ovise samo o dijelu ključa premjeste u novu relaciju, skupa s

dijelovima ključa koji ih funkcijski određuje. U našem primjeru, o dijelu ključa Autor,

ne ovisi izdavač, pa prema tome niti atributi koji ovise o izdavaču. Kataloška oznaka

određuje autora, pa ćemo izdvojiti atribute Kataloška oznaka i Autor u posebnu

relaciju.

Relacija:Knjige_2

#Kataloška oznaka Naslov

Broj starnica Izdavač Pošta Mjesto

1 Baze podataka 162 DRIP 10000 ZAGREB 2 SQL i relacijski

model podataka 419

ZNAK 10000 ZAGREB 3 ORACLE 7 780 ZNAK 10000 ZAGREB 4 Dalmatinska

kuhinja 420

LOGOS 21000 SPLIT 5 Dalmatinski kolači 360 LOGOS 21000 SPLIT

Relacija: Knjige_Autori_2

#Kataloška

oznaka #Autor 1 Varga 2 Vujnović 3 Hrenić 4 Biluš 4 Rode 5 Biluš 5 Kesić

Nakon dekompozicije, obje su relacije u drugoj normalnoj formi.

2.6.3 Treća normalna forma

Još uvijek nalazimo na redundantnost podataka. Naime, Izdavač jednoznačno

određuje Poštu i Mjesto izdavača. Štoviše, Mjesto je funkcijski određeno poštanskim

brojem. Anomalija ovakvih podataka se ogleda u nepotrebnom trošenju medija za

spremanje, kao i potrebom za promjenama u više redaka poštanskog broja i mjesta

kad se izdavač preseli u drugo mjesto.

33

Relacija se nalazi u trećoj normalnoj formi(3NF) ako ni jedan neključni atribut nije

tranzitivno ovisan o bilo kojem ključu relacije.

Iz prethodne definicije slijedi jednostavna i popularna definicija 3NF, koja se lako

pamti:

Svaki neključni atribut mora ovisiti o ključu, cijelom ključu i ni o čemu drugom

osim o ključu.

U našem primjeru nalazimo tranzitivne zavisnosti: Izdavač je određen Kataloškim

brojem, te Izdavač funkcijski određuje Poštu. Dakle, Pošta ovisi o ključu, ali

tranzitivno preko Izdavača. Nadalje, Mjesto ovisi o Izdavaču tranzitivno preko Pošte.

Dvije tranzitivne ovisnosti uklanjamo pouzdanim dekomponiranjem relacije Knjige_2

u relacije, Knjige_3, Izdavači_3 i Pošte_3:

Relacija:Knjige_3

#Kataloška oznaka Naslov

Broj stranica Izdavač

1 Baze podataka 162 DRIP 2 SQL i relacijski

model podataka 419

ZNAK 3 ORACLE 7 780 ZNAK 4 Dalmatinska

kuhinja 420

LOGOS 5 Dalmatinski kolači 360 LOGOS

Relacija:Izdavači_3

Izdavač Pošta DRIP 10000 ZNAK 10000 LOGOS 21000

Relacija:Pošte_3

Pošta Mjesto 10000 ZAGREB 21000 SPLIT

34

2.6.4 Boyce-Coddova normalna forma

Dovođenje relacije u treću normalnu formu je zadovoljava većinu praktičnih

primjena. Iako ona rješava ponašanje neključnih atributa, ne rješava problem koji se

javlja kod složenih primarnih ključeva. Prepostavimo trgovačku kuću koja ima više

referenata prodaje. Svaki od njih održava kontakt s jednim kupcem i prodaje mu jedan

ili više artikala.

Relacija: Referent_Artikal_3

#Referent #Artikal Kupac Ivić Papir Naprijed Jurić Olovke Polet Marić Omotnice Srima Marić Bilježnice Srima Tomić Flomasteri Swing

U gornjoj relaciji vrijede funkcijske zavisnosti: (Referent,Artikal) � Kupac, te

Kupac � Referent, jer referent veže određeni artikal uz jednog kupca, a kupac je

vezan samo uz jednog referenta. Iako je relacija u trećoj normalnoj formi, uočava se

redundancija podataka, koja uzrokuje anomalije u obradi: informacija da je kupac

Srima vezan uz referenta Marić, jednom po artiklu omotnice, a drugi put po artiklu

bilježnice, prisutna je u dvije n-torke. Ova se redundancija otklanja dekompozicijom

na dvije relacije.

Relacija je u Boyce-Coddovoj normalnoj formi (BCNF) ako sve funkcijske

zavisnosti relacije proizlaze iz njezinog ključa.

Relacija je u BCNF ako ne postoji ni jedan tranzitivno zavisan atribut, uključujući i

atribute ključa. BCNF je gotovo identična 3NF, s time da uvjete o tranzitivnoj

neovisnosti proteže i na sam ključ.

Iz definicije je jasno zašto relacija Referent_Artikal_3 nije u BCNF. Funkcijska

zavisnost Kupac � Referent ne proizlazi iz ključa.

35

Relacija: Kupac_Artikal_BCNF

#Kupac #Artikal Naprijed Papir Polet Olovke Srima Omotnice Srima Bilježnice Swing Flomasteri

Funkcijska zavisnost: (Kupac, Artikal) � 0.

Relacija: Kupac_Referent_BCNF

#Kupac Referent Naprijed Ivić Polet Jurić Srima Marić Swing Tomić

Funkcijska zavisnost: Kupac � Referent.

Gore provedena dekompozicija nije reverzibilna, jer je izgubljena funkcijska

zavisnost Referent � Artikal, dakle sačuvana je informacija o tome koji se artikli

prodaju svakom kupcu, te koji referent opslužuje svakog kupca, ali je izgubljena

informacija po kojim artiklima referent poslužuje kupca.

U nekim prilikama možemo zaključiti, da je bolje sačuvati relaciju u 3NF, nego li

izgubiti dio informacija.

2.6.5 Četvrta normalna forma

Kod višeznačne ovisnosti smo već vidjeli moguću anomaliju:

Relacija: Student_Sport_Jezik_BCNF

#Student #Sport #Jezik Ivić PLIVANJE NJEMAČKI Ivić TRČANJE ENGLESKI Ivić PLIVANJE ENGLESKI Ivić TRČANJE NJEMAČKI

Kako je očito da u relaciji ne vrijedi niti jedna funkcijska zavisnost, relacija je u

BCNF. Ipak, velika redundancija rezultira u manjkavosti korištenja medija za

spremanje podataka i otežava izmjene podataka.

36

Relacija u kojoj je zadan skup funkcijskih i višeznačnih ovisnosti, u četvrtoj je

normalnoj formi (4NF), ako je svaka višeznačna ovisnost X ->> Y trivijalna ili je X

ključ relacije.

Pouzdanim dekomponiranjem se relacija prevodi u dvije nove relacije, koje spajanjem

rezultiraju polaznom relacijom, pa kažemo da je dekompozicija reverzibilna, dakle

pouzdana.

Relacija: Student_Jezik_5

#Student #Jezik Ivić ENGLESKI Ivić NJEMAČKI

Relacija: Student_Sport_5

#Student #Sport Ivić PLIVANJE Ivić TRČANJE

2.6.6 Peta normalna forma

Relacija R, u kojoj je zadan skup funkcijskih i spojnih ovisnosti, u petoj je

normalnoj formi (5NF), ako je svaka spojna zavisnost *(R1,R2, ... Rn) trivijalna ili

je svaki Ri ključ u R.

Relacija je u 5NF, ako su iz nje izbačene sve spojne zavisnosti, odnosno, ako se više

ne može pozdano (reverzibilno) dekomponirati.

Relacija: Student_Instrument_Nastavnik

Br.Indeksa Instrument Nastavnik 1 Violina Anić 1 Flauta Perić 2 Violina Perić

37

Problem se rješava dekompozicijom na 3 relacije:

Relacija: Student_Nastavnik_5

Br.Indeksa Nastavnik 1 Anić 1 Perić 2 Perić

Relacija: Student_Instrument_5

Br.Indeksa Instrument 1 Violina 1 Flauta 2 Violina

Relacija: Instrument_Nastavnik_5

Instrument Nastavnik Violina Anić Flauta Perić Violina Perić

No, većina se relacija koje predstavljaju implementaciju n – arne ( n>2) veze ne može

dekomponirati, jer ponovnim spajanjem nastaju nepostojeće n-torke:

Relacija: Student_Instrument_Nastavnik_S

Br.Indeksa Instrument Nastavnik 1 Violina Anić 1 Violina Perić 1 Flauta Perić 2 Violina Perić

nova pogrešna n-torka

38

3 Životni ciklus baze podataka

Životni ciklus baze podataka slijedi identične korake koji se primjenjuju u analizi i

oblikovanju programske podrške, koji su dobro utvrđeni sedamdesetih godina. Valja

kazati, kako postavke programskog inženjerstva vuku svoje korijene iz inženjerstva

općenito, odnosno graditeljstva. Naime, životni ciklus jedne zgrade, započinje

stvaranjem idejnog rješenja, praćenog skicama i modelima, koje izrađuju arhitekti,

surađujući s investitorom i budućim korisnicima. Metodom usmjerenog razgovora

(interview) arhitekt saznaje želje investitora i uklapa ih u estetski prihvatljiva i

tehnički izvediva rješenja. Nakon toga građevinski inženjeri izvode statičke i

dinamičke proračune, s ciljem izračunavanja nosivosti temelja, zidova, kako bi zgrada

izdržala teret vlastite konstrukcije, te dinamička naprezanja uzrokovana vjetrom ili

možebitnim zemljotresom. Dizajneri interijera oblikuju unutrašnje uređenje do

najsitnijeg detalja.

Nakon što je zgrada izgrađena, slijedi njeno korištenje, održavanje, otklanjanje

uočenih nedostataka, a ponekad i naknadne modifikacije u cilju zadovoljavanja

zahtjeva koji su definirani tijekom eksploatacije objekta. Identični životni ciklus

prolazi informacijski sustav, pa tako i baza podataka, kao njegova sastavnica.

Možemo povući usporedbu baze podataka s temeljem građevine.

Dakle, životni ciklus baze podataka možemo podijeliti na korake:

- Analiza

- Oblikovanje

- Implementacija

- Eksploatacija

- Održavanje i naknadne modifikacije

3.1 Faze životnog ciklusa baze

Analiza – vrlo je vjerojatno da je neki posao odavna obavljan primjenom postojećih

tehnoloških postupaka, prije informatizacije. Postupkom analize, primjenom metode

usmjerenog razgovora (interview), s osobljem koje pozna tehnologiju posla, se

identificiraju izlazi koje informacijski sustav mora producirati. Da bi se izlazi mogli

producirati, potrebno je programsku podršku snabdjeti određenim ulazima. Neki ulazi

39

će se definirati u tijeku izvođenja programa, no neki drugi moraju biti pohranjeni na

mediju za mosaovnu pohranu podataka, najčešće magnetskim diskovima. Projektant

baze podataka mora identificirati upravo te, tzv. perzistentne ulaze. Naprimjer, kod

prodaje automobil, sve relevantne informacije o vozilu valja pohraniti u bazi

podataka. Kupac definira kriterije koje mora zadovoljiti automobil od njegova interesa

– kriterije pretraživanja. Ovi kriteriji ne moraju biti perzistentni, već se definiraju prije

početka pretraživanja, te se zaboravljaju nakon obavljene potrage. Dakako, podržava

li informacijski sustav naknadno pretraživanje, onda će i kriterije valjati sačuvati.

Naime, u momentu pretrage kupac može ne pronaći željeni auto, a IS može osigurati

spremanje njegovih kriterija, te po njima pretraživati, npr. jednom dnevno, da li se u

međuvremenu pojavio auto koji zadovoljava kriterije i o tome kupca obavijestiti e-

mailom.

Logičko ( konceptualno) oblikovanje – faza analize završava definicijom pojmova i

opisom entiteta, njihovih atributa, te mogućih domena, najčešće prirodnim jezikom

(hrvatskim ili engleskim). Nakon toga, valja identificirati entitete, atribute i domene,

te metode - funkcije. Najčešće imenice iz opisa prirodnim jezikom vode entitetima i

njihivim atributima, a pridjevi i brojčani podaci definiraju domene. Rezultat ovog

koraka su relacije prikazane prikladnim simbolima. Vrlo je vjerojatno da će u ovoj

fazi relacije posjedovati nepoželjnu redundantnost, kao posljedicu nedopuštenih

funkcijski zavisnosti, pa se primjenjuje postupak normalizacije, iterativno, sve dok ne

dovedemo sve relacije barem i obavezno u treću normalnu formu (3NF). Nakon toga

slijedi utvrđivanje međusobnih veza među relacijama i njihov prikaz modelom

Entiteti – veze. Dakako, u prikazu se koristimo simbolima, zavisno izabranoj metodi.

Implementacija – je postupak definicije relacija u bazi podataka, pri čemu entiteti (ili

tipovi entiteta) postaju tablice, atributi kolone, a domena služi kao podloga za izbor

tipa podatka i eventualna integritetska ograničenja ( ograničenje null vrijednosti,

ograničenje područja vrijednosti uvjetom koji podaci moraju zadovoljiti ili

referencijalnim, tj. integritetom stranog ključa). Slijedi izrada objekata baze podataka,

najčešće pomoću grafičkog korisničkog sučelja na razvojnom računalu proizvođača

IS, te generiranje komandi upitnog jezika (SQL), koje se koriste za prenošenje

objekata na odredišna računala kupca.

40

Statička i dinamička analiza – uvrđivanjem tipova podataka svake kolone, te

poznavanjem načina kako korišteni RDBMS sprema podatke na mediju, a na temelju

procjene broja n-torki, odnosno redaka svake tablice, procjenjuje se fizička veličina

tablica. Isto tako, u najranijoij fazi definicije projeta, potrebno je definirati odzivna

vremena kritičnih, često izvođenih upita. Najbolje je da definicija odzivnih vremena

bude kvantificirana ( npr. 3 sekunde nakon klika na dugme «Traži» ). Da bi odzivna

vremena bila zadovoljena, važno je pravilno procijeniti važnost i ušestalost pojedinih

upita, te broj klijenata koji će istovremeno «napadati» bazu podataka. Analiza upita i

odzivnih vremena rezultira definiranjem odgovarajućih indeksa, koji značajno

ubrzavaju pretraživanje, ali nažalost usporavaju izmjene ( upisivanje – insert,

promjene – update i brisanje – delete ), jer kod svake izmjene indeksi moraju biti

reorganizirani. Stoga težimo identifikaciji minimalnog broja indeksa, koji

zadovoljavaju kritične upite nad «vrućim» tablicama. Kako indeksi «troše» prostor na

mediju za pohranu podataka, izračunava se «statika» indeksa na temelju broja redaka

tablice i poznavanja organizacije indeksa korištenog RDBMS. Ova veličina, zajedno

s veličinom prostora za pohranu tabličnih podataka, služe za procjenu veličine

potrebnog prostora medija za masovnu pohranu ( diska).

Eksploatacija i održavanje baze podataka - već prije početka eksploatacije

potrebno je planirati sigurnost podataka i to u smislu neovlaštenog pristupa podacima,

te čuvanja pričuvnih podataka – backupa. Naime, moguće elementarne nepogode ili

teroristički napadi mogu uništiti cijeli računalni sustav, skupa s podacima. Isto tako

kvar računalnog hardvera ili čak upad «hackera» mogu uzrokovati gubitak podataka. I

pored takvih katastrofa, organizacija mora nastaviti s radom i imati na raspolaganju

podatke unijete u bazu do momenta katastrofe. Vremenski period ponovne

raspoloživosti podataka može biti nekoliko sekundi ili nekoliko dana nakon gubitka,

pa zavisno definiciji ovog intervala, izrađujemo strategiju backupa, počev od «stand-

by-backup-baze» za brzi nastavka rada, do klasničnog pristupa zamjene neispravnih

dijelova računala i restauracije podataka, što može potrajati nekoliko sati ili čak dana.

Tijekom eksploatacije potrebno je pratiti odzivna vremena i korist predviđenih

indeksa, te po potrebi brisati nekorisne i kreirati nove korisne indekse.

41

U ranim fazama projekta, nije moguće predvidjeti sve funkcionalnosti informacijskog

sustava, ili još češće svjesno se ide s minimalnim funkcijama, kako bi se izišlo na

tržište prije konkurencije i ostvariovao prihod. Potom se sustav obogaćuje, a to

zahtijeva i promjene strukture baze podataka. Vrlo je važno promjenama ne ugroziti

postojeće stanje, kako u smislu funkcionalnosti, tako i u smislu odzivnih vremena.

3.2 Vrste baza podataka

Prije razrade svih koraka životnog ciklusa baze, osvrnimo se na vrste baze podataka.

Na jednom polu su sustavi koji podupiru donošenje odluka, DSS (Decision support

system), koji se samo i isključivo pretražuju. Dakle nema izmjena podataka, samo se

čitaju. Kod ovakvih sustava možemo definirati neograničeni broj indeksa ( jasno, on

je ograničen veličinom medija i maksimalnim brojem indeksa koje RDBMS

podržava).

Na drugom polu su baze koje nitko nebi pretraživao, već bi samo upisivale podatke

(insertirale) podatke, pa niti ne trebamo definirati indekse. Naravno, ovo su samo

ekstremni slučajevi, dok je najčešće istovremeno pretraživanje i promjena podataka, a

takve baze nazivamo OLTP ( on-line transaction processing), dakle, promjene se

obavljaju u živo, usporedno s pretraživanjem. Baze ove vrsti, mogu imati ograničeni

broj indeksa, jer indeksi ubrzavaju pretraživanje, ali usporavaju promjene, jer se

zajedno s promjenom podataka, mora ažurirati i stablo svih indeksa, koji sadrže

promijenjeni podataka. Ovdje je to istaknuto iz razloga denormalizacije baze. Naime,

normalizacija uklanja redundantnost i anomalije održavanja podataka, ali vodi većem

broju tablica, koje su zapisane na različitim cilindrima diska, najčešćeg medija za

pohranu baza. Upitima se tablice spajaju, a to je «skupa» operacija, pa su upiti mnogo

sporiji, nego li kad nema spajanja, tj. kad su podaci «pregledno» u istoj tablici.

Potrebno je pomiriti ove dvije suprotnosti, postupkom denormalizacije. Moramo

razlikovati pojmove ne-normalizirane i denormalizirane strukture. Naime, dopušteno

je postojanje redundantnih zapisa podataka, ali uz jasno razlikovanje «master»

podatka, koji implementira atribut iz normalizirane relacije, od «slave» podatka, koji

ubrzava pretraživanje i mora vjerno slijediti promjene vrijednosti «master» podatka.

Funkcija slijeđenja se može ostvariti definiranjem okidača ( trigera ), koje «okida»

promjena «master» podatka, te oni izvođenjem adekvatne SQL naredbe ažuriraju

«slave» podatak. Drugi način denormalizacije se može provesti upotrebom

42

materijaliziranih pogleda. Naime, pogled (view) se definira pomoću SQL naredbe

koja spaja više relacija ( tablica i drugih pogleda), radi olakšanog pisanja kasnijih

upita, te radi ograničenja pristupa objektima baze ( primjenom operacija projekcije i

restrikcije). Klasični pogled nema fizičkog zapisa podataka na mediju, već obavlja

projekciju, restrikciju i spajanje dinamički, kada se upit definiran pogledom izvodi.

Možemo sebi predočiti pogled, kao zamjenu složenog upita jednim imenom, a

pozivom pogleda, se zapravo izvodi upit koji leži iza tog imena.

Nasuprot tome, materijalizirani pogled ima fizički zapis podataka na magnetskom

mediju, kao «slave» podatke, pa se pozivom imena materijaliziranog pogleda, zapravo

čita fizički zapis kopije podataka. RDBMS osigurava da kopija podataka iz različitih

izvornih tablica vjerno slijedi promjene izvornoh, «master» podataka. Promjene

kopije se obavljaju kod izmjene «master» podataka, pa se tijekom upita nad

materijaliziranim pogledom ne obavlja dinamički spajanje većeg broja tablica.

Ovom tehnikom možemo postići bazu koja apsolutno udovoljava i najstrožim

teoretskim zahtjevima, a da isto tako kritični upiti budu pokriveni materijaliziranim

pogledima, čime se ostvaruju iznimno dobra odzivna vremena. Naravno, broj

materijaliziranih pogleda mora biti ograničen, jer bi u protivnom usporio promjene

podataka kod OLTP baza, pa treba vrlo brižljivo odabrati upite pokrivene

materijaliziranim pogledom.

3.3 Postupak oblikovanja baze podataka

3.3.1 Izrada modela

Aktivnost oblikovanja na svakom polju djelatnosti, karakterizira izrada modela. Od

male djece koja izrađuju modele realnih objekata pomoću Lego kockica, do

nuklearnih fizičara koji izrađuju modele ponašanja jezgre atoma, fizički i mentalni

modeli objekata iz realnog svijeta pomažu shvaćanju ponašanja realnih objekata i

zbivanja, istraživanju ideja i razumijevanju događaja.

Modeli se mogu koristi za:

- opis

- specifikaciju

- istraživanje

43

- komunikaciju

- analizu

- kategorizaciju

- imitaciju

ponašanja realnih objekata i zbivanja.

Važno je uočiti konflikt: model koji osigurava mnogo detalja da bi sustav opisao

potpuno, može sakriti ili otežati shvaćanje cjelovitosti. To je stvorilo ideju stvaranja,

tzv. ugniježđenih ili postupnih modela. Uzmimo na primjer izučavanje povijesti

Hrvata, koju ne možemo učiti izolirano od povijesnih zbivanja europske i svjetske

povijesti u svakom razdoblju. Učimo li istovremeno i svjetsku i hrvatsku povijest,

dolazimo do toliko detalja, da od njih ne vidimo osnovne značajke razdoblja. Zato se

učenje provodi najprije učenjem svjetske povijesti u osnovnim crtama, pa onda

hrvatske povijesti detaljnije ( u osnovnoj školi), onda se postupak ponavlja s više

detalja o svjestkoj povijesti itd. ( u srednjoj školi).

Dakle, uočavamo postupnost u razumijevanju i svladavanju problema, pa isti pristup

valja primijeniti i kod modeliranja objekata i zbivanja – odnosno tehnoloških

postupaka – predmeta informatizacije.

3.3.2 Različiti aspekti sustava

Model mora prikazivati realne objekte i zbivanja selektivno, uzimajući u obzir bitna

obilježja. U pravilu model ispušta mnogo više detalja,nego li ih uključuje. Ako bi

model uključio sve moguće detalje realnih objekata, pretpostavimo li da je to opće

moguće, bio bi identičan realnom životu, pa vjerojatno teško razumljiv i prihvatljiv.

Oslikajmo ideju primjerom. Bacimo kamenčić s visine 10 m i zanima nas brzina

kojom udari pri padu na tlo. Kao što je poznato iz fizike, brzinu računamo po modelu

opisanom formulom:

v= SQRT( 2gh)

gdje je g ubrzanje zemljine sile teže ( 9.81 m/s2) a h visina ( 10 m ) i dobijemo:

v = 14.8 m/s

44

Pri tom smo zanemarili brojne činjenice koje utiču na slobodan pad, kao trenje zraka,

tlak zraka, utjecaj mogućeg vjetra itd. Ako bi vrlo kompleksnim modelom uvažili sve

te utjecaje, odstupanje rezultata bi bilo neznatno, a račun složen.

Ako pak računamo brzinu kojom satelit može pasti na zemlju, ranije zanemareni

utjecaji se moraju uzeti u račun, jer je njihov doprinos značajan. Dakle, osnovno u

izradi modela je izbor parametara od utjecaja na konačan rezultat, a u inženjerskom

pristupu, nastojimo što jednostavnijim modelom dobiti najmanje loše rezultate.

Slijedi zaključak, da u cilju postizanja što boljeg modela valja koristiti različite

tehnike zajedno. Na primjer, kod medicinskog ispitivanja pacijenta, liječnik stvara

model njegova zdravstvenog stanja koristeći nalaze krvi, krvni tlak, rentgentske i

ultrazvučne snimke, te analizom svih nalaza zaključuje o zdravstvenom stanju.

Isto tako moramo i mi, upotrijebiti različite tehnike koje se fokusiraju na različite

aspekte sustava, ali koje se nadovezuju i isprepliću, dajući kompletnu sliku sustava.

Koristit ćemo:

- Model entiteti – veze

- Funkcijski model

- Model toka podataka

3.3.3 Model entiteti – veze

Cilj modeliranja je definirati i razumjeti činjenice značajne za poslovnu aktivnost,

koje informacije mora pamtiti, te vezu među njima.

Koristi se pristup od vrha nadolje (Top-Down), polazeći najprije od utvrđivanja

entiteta, a potom njihovih atributa.

Pojmovi od značaja u analizi entiteta

- Entitet

- Veza

- Atribut

- Jedinstveni identifikator (primarni ključ)

45

- Podtip

- Nadtip

Što može biti entitet ?

Bilo što o čemu možemo prikupljati informacije. Bilo koja imenovana stvar. Sve ono

što ima posebna svojstva, koja se mogu razlikovati, bilo u domenu realnih objekata i

zbivanja ili u sferi apstraktnog mišljenja. Entitet je obično imenica u rečenici

napisanoj tijekom usmjerenog razgovora (interview) s korisnicima postojeće

tehnologije.

Primjer entiteta:

OSOBA, POSAO, PROJEKT, TVRTKA, ODJEL, ZAPOSLENIK, K UPAC,

DOBAVLJA Č

Dobro je potražiti i sinonime: drukčija imena koja znače isto. Na primjer, što je

KUPAC, TVRTKA, DOBAVLJA Č ? Vjerojatno ORGANIZACIJA.

Zavisno od izabrane metode za prikazivanje modela, entiteti se mogu prikazati jednim

od grafičkih simola:

3.3.4 Veze

Veza predstavlja bilo koji način na koji dva objekta istog ili različitog tipa mogu biti

upućeni jedan na drugoga. Svaku je vezu dobro imenovati, naprimjer:

ZAPOSLENIK obavlja POSAO

POSAO je dodijeljen ZAPOSLENIK-u

Veze su opisane stupnjem veze i opcionalnošću:

U našem primjeru, stupanj veze odgovara na pitanje: «Koliko poslova može obavljati

jedan zaposlenik?»

OSOBA OSOBA OSOBA

46

Odgovor: Jedan zaposlenik može obavljati više poslova.

Pitanje: «Koliko zaposlenika može obavljati isti posao?»

Odgovor: Više zaposlenika može obavljati istu vrst posla.

Dakle, veza ZAPOSLENIK – POSAO je M:N, tj. više prema više.

Opcionalnost veze

Postavlja se pitanje, da li ZAPOSLENIK-u uvijek mora biti dodijeljen POSAO, ili

može i ne mora biti ?

Odgovor: ZAPOSLENIKU mora biti dodijeljen POSAO.

Sada vezu možemo čitati: Svaki ZAPOSLENIK obavlja jedan ili više POSLOVA, ili

obratno, svaki POSAO je dodijeljen jednom ili više ZAPOSLENIKA.

Prikaz veze:

Martinova notacija:

Chenova notacija:

ORACLE notacija:

ZAPOSLENIK

POSAO

obavlja

dodijeljen

ZAPOSLENIK

POSAO obavlja

M

N

ZAPOSLENIK POSAO

47

Stupanj ili kardinalni broj veze:

Naziv veze Martinova notacija Chenova notacija ORACLE notacija

Jedan prema više

1:N 1:N

Više prema više

M:N M:N

Jedan i samo jedan

1:1 1:1

Opcionalnost veze:

Naziv veze Martinova notacija Chenova notacija ORACLE notacija

Opcionalna veza

(može biti) jedan

0,1 0,1

Opcionalna veza

(može biti) više

0,N 0,N

Obvezna veza

(mora biti ) jedan

1 1

Obvezna veza

(mora biti ) barem

jedan ili više

1,N 1,N

48

Pravilo čitanja veza:

«Svaki ( entitet )

mora biti /1/

ili ( veza )

može biti /0/

jedan ili više /N/

ili (entitet)

jedan i samo jedan /1/.»

Primjer: Svaki zaposlenik obavlja barem jedan ili više poslova, te svaki posao je

dodijeljen jednom ili više zaposlenika.

Evo nekih korisnih parova imena veza:

temelji se na – osnov za

kupuje se od – isporučuje

imenovan za – povjeren

dio od – sastavljen od

odgovoran za – u nadležnosti

3.3.5 Rješenje veze više prema više

Jedan projekt može obavljati više zaposlenika, a isto tako jedan zaposlenik može

istovremeno ili u različitim vremenima, raditi na više projekata.

Vezu više prema više ( M:N) teško je implementirati i održavati, stoga se ona

dekomponira u dvije veze 1 naprema više ( 0,1:N + 0,1:M ).

ZAPOSLENIK

PROJEKT uključen

0,M

0,N

49

Dakle, veza M:N se dekomponira u dvije veze 1:N, umetanjem presječnog (eng.

intersection) entiteta, pri čemu je kardinalni broj (stupanj veze), na strani polaznih

entiteta 1 uz zadržanu opcionalnost, dakle 1 ili 0,1, a na strani presječnog entiteta 1,M.

Dakle, polazna veza «Svaki Zaposlenik može biti uključen u više projekata i Svaki

projekt može uključivati više zaposlenika» je sačuvana. Presječni entitet će imati dva

strana ključa, koji su primarni ključevi u polaznim entitetima, a oni zajedno čine

primarni ključ u presječnom entitetu.

3.3.6 Rekurzivna veza

Rekurzivna veza predstavlja vezu entiteta sa samim sobom. Koristi se za prikazivanje

hijerarhije nelimitiranog broja kompatibilnih elemenata.

Na primjer, u organizaciji koja je u pravilu hijerarhiski uređena, svaki zaposlenik ima

pretpostavljenog (šefa), pri čemu ovaj ima svog pretpostavljenog i tako dalje, sve do

vrha piramide.

ZAPOSLE

NIK

ZAP_PROJ

PROJEKT

0,1

M

N

0,1

OSOBA

šef od 0,1

ima šefa 0,N

50

Dakle, «Svaka osoba može ( glavni šef nema nad-šefa) imati jednog i samo jednog

neposrednog šefa, a neke osobe su šefovi većem broju osoba.»

Rekurzivna veza je zgodna za prikazivanje sastavnica, dio od – sastavljen od,

teritorijalne pripadnosti itd.

3.3.7 Učestalost pojedinih vrsta veza u realnim modelima

Oznaka veze Naziv veze Učestalost

1,M : 0,1 barem jedan ili više prema može biti

jedan

(5) VRLO ČESTO

0,M : 0,1 može biti više prema može biti jedan (4) ČESTO

0,M : 1 može biti više prema jedan i samo

jedan

(3) NIJE RIJETKO

1,M : 1 barem jedan ili više prema jedan i

samo jedan

(2) RIJETKO

0,M : 0,N može biti više prema može biti više (4) ČESTO U POČETNOJ

FAZI

1,M : 0,N barem jedan ili više prema može biti

jedan

(4) ČESTO U POČETNOJ

FAZI

1,M : 1,N barem jedan ili više prema barem

jedan ili više

(1) VRLO RIJETKO

1 : 0,1 jedan i samo jedan prema može biti

jedan

(2) RIJETKO

0,1 : 0,1 može biti jedan prem amože biti

jedan

(2) RIJETKO

1 : 1 jedan i samo jedan prema jedan i

samo jedan

(1) VRLO RIJETKO

Brojevi u zagradama određuju učestalost pojave, 1 = vrlo rijetko, 5=vrlo često.

51

3.3.8 Atributi

Općenito kazano atributi opisuju entitet.

Namjena atributa je da:

- Kvalificiraju

- Identificiraju

- Klasificiraju

- Kvantificiraju

- Izraze stanje

Postupkom oblikovanja utvrđujemo atribute od značaja u opisu entiteta, a

izostavljamo iz modela one koji nisu.

Tako na primjer, entitet Student može biti opisan atributima:

Atribut Kategorija Opis

Ime Identificira

Prezime Identificira

Završena srednja škola Kategorizira Npr. u statističkoj analizi

prolaznosti s obziro iz koje

škole dolazi

Studijska grupa Klasificira Prema studijskim grupama

Položeni ispiti Kvalificira Za upis na višu godinu

Težina Kvantificira Nije od značaja u IS

Status Izražava stanje Redovito upisan, ponavlja,

parcijalno upisan

Bračno stanje Izražava stanje Noženjen, neudata,

oženjen, udata

52

Jasno je da neki atributi u IS «Studentska služba» nisu značajni, kao npr. težina pa ih

ispuštamo iz određenog modela. Kod modela nekog drugog IS, npr. «Zdravstvena

ustanova» atribut težina je od značaja, jer je poznato da može biti povezana s nekim

bolestima, pa atribut mora biti uvršten u model.

3.3.9 Opcionalnost atributa

Vrijednosti nekih atributa mogu biti nepoznate i ostati nedefinirane, dok drugi atributi

moraju obavezno biti definirani. Označimo u modelu opcionalnost simbolima:

* mora biti definiran

o može ostati nedefiniran

Na primjer, entitet osoba je opisan atributima:

Osoba

* Ime

* Prezime

* Spol

o Datum rođenja

o Adresa

3.3.10 Jedinstveni identifikator

Kako je već rečeno, svaki entitet ( npr. svaki student ) mora biti identificiran na

jedinstven način, jednim atributom ili skupom atributa. Jedinstveni identifikator u fazi

implementacije postaje primarni ključ.

Atribute koji jedinstveno identificiraju pojavu entiteta simbolički označimo znakom #.

Evo nekih primjera jedinstvenog identifikatora:

Proizvod

# Bar kod

Ispit

#Predmet

53

#Datum

Osoba

#JMBG

Osoba

#Ime

#Prezime

#Datum rođenja

#Adresa

Naravno, atributi koji identificiraju svaku pojavu entiteta, moraju biti definirani. Što

ćemo izabrati za identifikator, ovisi o konkretnom informacijskom sustavu.

Motorno vozilo

#Broj šasije

Tako na primjer, broj šasije motornog vozila je odličan identifikator, jer svako

motorno vozilo na svijetu ima jedinstvenu oznaku, ali u IS «Trgovina rabljenim

motornim vozilima» cilj je oglasiti prodaju što većeg broja vozila, pa tako imati veću

zaradu, a vlasnici motornih vozila često ne znaju napamet ovaj broj, pa bi izbor

takvog identifikatora, koji mora biti definiran, odvratio mnoge klijente da isti posao

odrade kod konkurentskog internet site, koji ne traži unos kompliciranih oznaka.

Dakle, izbor atributa koji identificiraju entitet, mora biti pažljiv i razlikovat će se

prema namjeni informacijskog sustava.

U fazi implementacije baze podataka, jedinstveni identifikator će postati primarni

ključ tablice. Čest je slučaj da jedan objekt iz realnog svijeta može jedinstveno

identificirati skup većeg broja atributa. Tako osobu u mnogim IS ne može

identificirati samo Prezime, nego npr. skup atributa Ime, Prezime, Datum rođenja i

Adresa stanovanja. Veze među tablicama ostvarujemo odnosom primarni – strani

ključ. To znači, da bi u tablici – djetetu, svaka pripadnost roditelju, bila definirana

skupom od više kolona, s tekstualnim vrijednostima, koji ponekad mogu imati

nekoliko stotina znakova. Pri spajanju tablica računalni hardver mora usporediti da li

su vrijednosti u svim relevantnim kolonama identične traženim vrijednostima,

vjerojatno znak po znak, pri čemu sva mala slova moraju biti pretvorena u velika

54

(pretpostavljamo da baza radi «case insensitive», dakle ne razlikuje malo i veliko

slovo (a i A su isti znak). Da bi izbjegli narušavanje odzivnih vremena iz ovog

razloga, vrlo često, u fazi implementacije biramo primarni ključ kao apstraktan, tj.

definiramo kolonu cjelobrojnog tipa od 4 byta, čije vrijednosti baza automatski

generira, čime je osigurana jedinstvenost. Spajanje tablica onda ostvarujemo ovim

apstraktnim identifikatorom, jer računalo vrlo brzo uspoređuje 4-bytne brojeve.

Primarni ključ nazivamo apstraktnim, jer on ne identificira objekt u realno svijetu,

samo interno u našem IS. Kako bi spriječili pojavu dva retka s istom vrijednošću

atributa, koji su zapravo trebali biti primarni ključ, jer oni identificiraju objekt u

realnom svijetu, definiramo jedinstveni indeks nad skupom tih atributa. Na taj način

imamo osiguranu jedinstvenost i dobili smo na brzini spajanja tablica, te uštedjeli

prostor za pohranu.

3.4 Videoteka - model prakti čnog primjera

Nakon obavljenog usmjerenog razgovora s naručiteljem informacijskog sustava

Videoteka, napravljene su slijedeće bilješke:

Videoteka upisuje članove koji posuđuju na određeni period kasete različitih

naslova. Članovi su opisani imenom, prezimenom, kućnom adresom i brojem

telefona. Član se ne može upisati ako nisu poznati ovi atributi, radi vraćanja

zaboravljenih kaseta. Na svaku kasetu je snimljen samo jedan naslov ( film ). Naslov

je opisan nazivom djela ( filma), žanrom, trajanjem u minutama, kratkim sadržajem

te akterima, kao što su producent, režiser, glavni i ostali glumci. O svakoj kaseti se

vodi evidencija njenog stanja (istrošenosti), radi planiranja zamjena. Kasete se izdaju

za trajanje od jednog do više dana, a najam se naplaćuje na dan vraćanja, po

jedinstvenoj cijeni Kuna/dan.

Članovi često žele izabrati jedan od naslova njihovih omiljenih glumaca.

Među imenicama (tiskanim masnim podvučenim kurzivom), tražimo imena entiteta ili

(imenice tiskane masnim kurzivom) su kandidadti za atribute, a glagoli sugeriraju

metode ( SQL upit ).

Entitetski kandidati:

55

Članovi

# Identifikator člana

* Ime

* Prezime

* Poštanski broj

* Mjesto

* Ulica i Kućni broj

* Telefon

o Datum Rodjenja

o Spol

Naslovi

# Identifikator naslova

* Naslov

o Trajanje minuta

o Žanr

o Opis

Kasete

# Identifikator kasete

* Naslov

* Stanje

Akteri

# Identifikator aktera

o Ime

56

* Prezime

PosudbaKaseta

# Identifikator člana

# Identifikator kasete

# Datum izdavanja

o Planirani datum vraćanja

o Stvarni datum vraćanja

Analizom entiteta, zaključujemo na relacije:

Clanovi

Max

dužina

Prosječna

dužina

# ClanID Int4 – Autoident 4 4

* Ime varchar(30) 30 7

* Prezime varchar(30) 30 8

$ PostaID Int4 - Strani ključ – ref:

Poste

4 4

* Ulica varchar(50) 50 12

* Kbr Int2 2 2

o KbrDodatak varchar(10) 10 1

o Kat Int2 2 2

o DatumRodjenja smalldatetime 4 4

$ Spol Int1 – Strani ključ ref:

Spolovi

1 1

Total: 137 45

57

Poste

Max

dužina

Prosječna

dužina

# PostaID Int4 4 4

* Posta varchar(30) 30 9

Total: 35 13

Spolovi

Max

dužina

Prosječna

dužina

# SpolID Int1 1 1

* Spol varchar(30) 30 6

Total: 31 7

Naslovi

Max

dužina

Prosječna

dužina

# NaslovID Int4 – Autoident 4 4

* Naslov varchar(80) 80 16

o TrajanjeMin Int2 2 2

$ ZanrID Int1 1 1

o Opis varchar(1024) 1024 250

Total: 1111 273

Zanrovi

58

Max

dužina

Prosječna

dužina

# ZanrID Int1 1 1

* Zanr varchar(30) 30 6

Total: 31 7

Kasete

Max

dužina

Prosječna

dužina

# KasetaID Int4 - Autoident 4 4

$ NaslovID Int4 – ref: Naslovi 4 4

$ StanjeKaseteID Int1 1 1

Total: 9 9

StanjeKaseta

Max

dužina

Prosječna

dužina

# StanjeKaseteID Int1 1 1

* StanjeKasete varchar(30) 30 10

Total: 31 11

59

Akteri

Max

dužina

Prosječna

dužina

# AkterID Int4 – Autoident 4 4

o Ime varchar(30) 30 10

* Prezime varchar(30) 30 10

o Opis varchar(255) 255 60

Total: 219 84

AkteriUloge

Max

dužina

Prosječna

dužina

# $ AkterID Int4 ref: Akteri 4 4

# $ NaslovID Int4 ref: Naslovi 4 4

# $ UlogaID Int1 ref: Uloge 1 1

Total: 9 9

Uloge

Max

dužina

Prosječna

dužina

# UlogaID Int1 1 1

* Uloga varchar(30) 30 12

Total: 31 13

60

PosudbeKaseta

Max

dužina

Prosječna

dužina

# $ KasetaID Int4 ref: Kasete 4 4

# $ ClanID Int4 ref:Clanovi 4 4

# DatumIzdavanja smalldatetime 4 4

o PlaniraniDatumVracanja smalldatetime 4 4

o DatumVracanja smalldatetime 4 4

Total: 20 20

Pojašnjenje:

- varchar(n) je varijabilni tekst maksimalne dužine n znakova, s tim da stvarno

zauzeti prostor odgovara broju stvarno unijetih znakova (+ m byte-ove za

zapis dužine teksta).

- Int1 – 1 byte-ni cio broj, 0 ... 255 ili –128 ...0 ... 127, ovisno bazi

- Int2 – 2 byte-ni cio broj, -32786 ...0 ... 32767

- Int4 – 4 byte-ni cio broj ( -2**31 ...0 ... 2**31 –1 )

- Autoident – baza generira broj kod insertiranja zapisa

- smalldatetime – zapis datuma, način zapisa ovisi o bazi, rezolucija reda

minuta, ( kod MS SQL Server 2000, 4 byte)

- * - Obvezan unos, Null vrijednost nije dopuštena

- $ - Strani ključ

- ref – Referentna tablica

- o – unos nije obvezan, dopuštena je Null vrjednost

- # - dio primarnog ključa, unos obvezan

61

Maksimalna i očekivana dužina služe kao podloga za izračunavanje potrebnog

prostora za pohranu tablica.

3.5 Model entiteti – veze ( MS SQL Server 2008)

3.6 Funkcije ( metode )

Članovi

- Upis novog člana

- Promjena podataka člana

- Brisanje člana

- Traženje

Naslovi

- Upis novog naslova

- Promjena podatakao o naslovu

62

- Brisanje naslova

- Traženje

Kasete

- Upis nove kopije

- Promjena stanja kopije ( uključuje otpis datoteke )

- Traženje

Akteri

- Upis

- Promjena

- Brisanje

- Traženje

Izdavanje – vraćanje kaseta

- Izdavanje

- Vraćanje

3.7 Impementacija objekata baze podataka – primjer dviju

tablica ( Microsoft SQL Server 2008 ):

CREATE TABLE [dbo].[Akteri] (

[AkterID] [int] IDENTITY (1, 1) NOT NULL ,

[Ime] [varchar] (30) NULL ,

[Prezime] [varchar] (30) NOT NULL ,

[DatumRodjenja] [smalldatetime] NULL

) ON [PRIMARY]

CREATE TABLE [dbo].[Clanovi] (

[ClanID] [int] IDENTITY (1, 1) NOT NULL ,

63

[Ime] [varchar] (30) NOT NULL ,

[Prezime] [varchar] (30) NOT NULL ,

[DatumRodjenja] [smalldatetime] NULL ,

[JMBG] [bigint] NULL ,

[PostaID] [int] NOT NULL ,

[Ulica] [varchar] (50) NOT NULL ,

[Kbr] [smallint] NOT NULL ,

[KbrDodatak] [varchar] (10)NULL ,

[Kat] [smallint] NULL ,

[TelefonOperater] [smallint] NULL ,

[TelefonBroj] [int] NOT NULL ,

[email] [varchar] (100) NULL

) ON [PRIMARY]

ALTER TABLE [dbo].[Akteri] WITH NOCHECK ADD

CONSTRAINT [PK_Akteri] PRIMARY KEY CLUSTERED

(

[AkterID]

) ON [PRIMARY]

ALTER TABLE [dbo].[Clanovi] WITH NOCHECK ADD

CONSTRAINT [PK_Clanovi] PRIMARY KEY CLUSTERED

(

[ClanID]

) ON [PRIMARY]

64

4 Indeksi

Pojasnimo najprije pojam indeksa, primjerom. Želimo pronaći značenje engleske

riječi «event». U englesko – hrvatskom rječniku, u zaglavlju svake stranice su

napisane početna i završna riječ koje se nalaze na toj stranici. Brzo listamo stranice,

gledajući samo zaglavne riječi i pronalazimo onu na kojoj u zaglavlju stoji: «even ...

excess». Kako se riječ «event» u abecednom poretku nalazi između ove dvije riječi,

zadržavamo se na toj stranici i pronalazimo traženu riječ (sa značenjem događaj).

Dakle, riječ smo pronašli brzo, zato što su sve riječi u riječniku poredane po

abecednom redu engleskih riječi. Kažemo da je rječnik indeksiran po engleskim

riječima. Kada bi ovaj isti englesko-hrvatski rječnik upotrijebili za nalaženje

engleskog prijevoda hrvatske riječi «nebo», morali bismo prelistati cijeli rječnik, jer

nije poredan po hrvatskim riječima. Naravno, hrvatsko-engleski rječnik, koji sadrži

iste riječi kao i prethodni, bi pomogao, jer je indeksiran po hrvatskim riječima.

Ovakvu vrstu indeksa, kod kojeg su podaci fizički poredani po indeksiranoj koloni (ili

kolonama), sustav MS SQL Server naziva klasterirani indeks. Jasno je da se podaci

fizički mogu poredati samo na jedan način, pa je isto tako moguć samo jedan

klasterirani indeks u tablici. Ova vrsta indeks pomaže kod pretraživanja područja

(ranga) vrijednosti.

Potražimo sada u knjizi R. Vujnović «SQL i relacijski model podataka», pojašnjenje

pojma «indeksiranje». Na kraju knjige pronalazimo indeksno kazalo, te pod slovom

«I», «indeksiranje, 151». Dakle, na stranici 151 započinje pojašnjenje pojma, te brzo

pronalazimo stranicu s traženim podatkom. Ovakav indeks podržavaju i sustavi

relacijskih baza, a MS SQL Server ga naziva neklasterirani indeks. Može se definirati

veći broj indeksa ovog tipa i svaki od njih može uključiti jednu ili više kolona.

Pogledajmo primjer organizacije podataka ( MS SQL Server 2000, no slično podatke

organiziraju i ostali sustavi) na mediju za pohranu. Poznato je da se podaci čitaju i

zapisuju, dakle prenose u radnu memorije, u kvantima, stranicama.

Stoga i baze podataka organiziraju podatke po stranicama, kako bi koristile uslugu

operacijskog sustava na sukladan način. Stoga su i podaci zapisani u jednoj tablici,

zapravo razbacani po stranicama, koje mogu biti na bilo kojem cilindru diska.

65

Primjer organizacije tablice Studenti(Ime, Prezime, Spol) slijedi. Poredani su po

stranicama stohastički, kako su dodavani u tablicu, jer nije definiran indeks.

Želimo pronaći sve studente s prezimenom između Horvat i Koštić, uključivo i njih

same, zato jer svi one obavljaju vježbe kao članovi grupe B. SQL upit će biti:

SELECT * FROM Studenti

WHERE Prezime BETWEEN 'Horvat' AND 'Košti ć'

Kako tablica nije indeksirana, RDBMS će krenuti od prvog zapisa na prvoj stranici,

uspoređivati da li prezime nalazi u zadanom intervalu, te ga prikazati, nastavljajući

zapis po zapis sve do zadnjeg zapisa na zadnjoj stranici.

Stranica Zapis Ime Prezime Spol

1 Ivo Ivić M

2 Ante Perić M

3 Jure Padovan M 1

4 Anica Zubčić Z

1 Damir Kelava M

2 Kristian Brunner M 2

3 Marina Bajramović Z

1 Ivica Tomić M

2 Slavko Dešković M

3 Slavica Perović Z 3

4 Miranda Poljak Z

1 Ivan Goran Penić M

2 Ivana Marić Z

3 Nikolina Meštović Z

4 Mate Antić M

4

5 Paško Ivanković M

1 Domagoj Horvat M

2 Hrvoje Orlandini M 5

3 Danijela Klisović Z

1 Ana Belić Z

2 Ivana Zubović Z

3 Domina Aljinović Z 6

4 Kata Reić Z

1 Doris Koštić Z

2 Mario Lojpur M 7

3 Franka Dodić Z

66

Ovakvo pretraživanje zovemo potpuno pretraživanje tablice (full table scaning). Kod

tablica s velikim brojem zapisa, uzima značajno vrijeme i odziv je spor. Kreiramo li

klasterirani indeks po koloni Prezime, podaci će biti reorganizirani po stranicama i

poredni po abecedi prezimena, kako prikazuje donja slika. Pri tome, se kreira korijen

indeksa, u našem primjeru sa dva zapisa, koji senalaze na stranici 14. i koji dijele

čitavu sortiranu tablicu u dva podjednaka dijela. Ovi zapisi pokazuju na srednju razinu

indeksa, odnosno da se Prezime Aljinović nalazi na stranici 15. srednje razine

indeksa, a Lojpur na stranici 16. Srednja razina indeksa dijeli tablicu na još manje

segmente, pokazujući stranicu slijedeće razine koja sadrži isti podatak. Konačno,

zadnja razina klasteriranog indeksa sadrži same podatke.

Napomenimo da ovako klasterirani indeks kreira sustav za upravljanje relacijskom

bazom Microsoft SQL Server 2008. Neki drugi sustavi ne poznaju ovaj tip indeksa, te

štoviše pod istim nazivom – klasterirani indeks – mogu podrazumijevati potpuno

drukčiju strukturu, no smatram da je korisnije pokazati organizaciju indeksa na

konkretnom primjeru izabrane baze.

67

Klasterirani indeks: Prezime

Posljednja razina ( leaf)

Str Zap Ime Prezime Spol

1 Domina Aljinović Z

2 Mate Antić M

1 3 Marina Bajramović Z

Srednja razina ( intermediate)

Str Na str 1 Ana Belić Z

Aljinović 1 2 Kristian Brunner M

Belić 2

2

3 Slavko Dešković M

Dodić 3

15 Kelava 4 1 Franka Dodić Z

2 Domagoj Horvat M

3 Paško Ivanković M

3

4 Ivo Ivić M

Korijen (root) 1 Damir Kelava M

Str Na str 2 Danijela Klisović Z

Aljinović 15

4

3 Doris Koštić Z 14 Lojpur 16

1 Mario Lojpur M

2 Ivana Marić Z

3 Nikolina Meštović Z

5

4 Hrvoje Orlandini M

Str Na str 1 Jure Padovan M

Lojpur 5 2 Ivan Goran Penić M

Padovan 6 3 Ante Perić M

Poljak 7

6

4 Slavica Perović Z

16 Zubčić 8

1 Miranda Poljak Z

2 Kata Reić Z

7

3 Ivica Tomić M

1 Anica Zubčić Z

8

2 Ivana Zubović Z

Kako se traži prezime «Horvat» ?

Polazi se od korjena indeksa i pronalazi da je «Horvat» veće od «Aljinović» i manje

od «Lojpur», pa se slijedi zadnji pokazivač od kojeg nije manji ( tj. veće ili jednako),

dakle «Aljinović» i odlazi na stranicu 15. Tu se pronalazi da je «Horvat» veće od

«Dodić» i manje od «Kelava», pa se slijedi pokazivač od «Dodić» i odlazi na stranicu

3. Zatim se pronalazi «Horvat», prikazuje i nastavlja po zapisima u slijedu i prezime

uspoređuje s «Koštić», prikazujući ih, sve dok je prezime manje ili jednako «Koštić».

Očito je ubrzanje traženja, jer broj srednjih razina nije velik, čak ni kod velikih

tablica.

68

Pronađimo sada studenta s imenom «Ivo».

Indeks: Ime

Zadnja razina ( leaf)

Str Ime Na str Zap

Ana 2 1

Anica 8 1

Ante 6 3

Srednja razina(interm) Damir 4 1

Str Ime Na str Danijela 4 2

Ana 23 Domagoj 3 2

Doris 24

23 Domina 1 1

21 Str Na str Zap

Doris 4 3

Franka 3 1

Hrvoje 5 4

Ivan Goran 6 2

Korijen(root) Ivana 5 2

Str Ime Na str Ivana 8 2

Ana 21

24 20

Ivica 22

Str Na str Zap

Ivica 7 3

Ivo 3 4

Jure 6 1

Kata 7 2

Str Na str Kristian 2 2

Ivica 25 Marina 1 3

Mate 26

25 Mario 5 1

22 Str

Mate 1 2

Miranda 7 1

Nikolina 5 3

Paško 3 3

Slavica 6 4

Slavko 2 3

26

Indeks po koloni Prezime nam ne pomaže u pronalaženju imena. Zato kreirajmo

indeks po koloni Ime. Indeks ponovo ima korijen, srednje razine, te posljednju razinu,

koja pokazuje na stranicu i zapis na kojoj se nalaze svi podaci studenta kojem je ime

«Ivo».

Dakle, «Ivo» je veći od «Ivica», no kako je to posljedni zapis na stranici korjena,

slijedi se pokazivač od «Ivica» i odlazi na stranicu 22. srednje razine indeksa. Tu je

«Ivo» veći od «Ivica», ali manji od «Mate», pa se odlazi na stranicu 25, gdje se

69

pronalazi «Ivo», jer zadnja razina uvijek sadrži sve zapise indeksiranih kolona cijele

tablice i odlazi na stranicu 3, zapis 4, što je kompletan zapis studenta s imenom «Ivo».

Ovakva struktura indeksa se naziva «B-tree»,tj. uravnoteženo stablo (eng. balanced

tree). Karakterizira je da uvijek dijeli ciljelu tablicu na približno jednake segmente, a

to znači da se nakon svake promjene podataka u tablici, koji obuhvaćaju i indeksne

kolone, stablo mora reorganizirati. Naravno, to uzima vrijeme, pa je jasno da indeks

ubrzava traženje, ali usporava izmjene: dodavanje, ažuriranje ili brisanje zapisa. Stoga

je važno kreirati razuman broj indeksa, prema iskustvima iz prakse 5-7 i njima

zadovoljiti često izvođene upite.

Potražimo sada sve zapise koji imaju vrijednost kolone Spol = «Z». Sada nam ne

pomaže ni jdan ni drugi indeks, pa će se pretraživati cijela tablica.

Da li bi nam pomogao neklasterirani indeks po koloni Spol ? Nebi, jer je 50% zapisa s

vrijednošću «Z», pa bi pretraživanje stabla indeksa više trajalo, nego potpuno

pretraživanje tablice. Ova vrsta indeksa je korisna, ako su podaci dobro distribuirani,

dakle ako se ista vrijednost pojavljuje u 5 – 10 % slučajeva ( dakako, točan postotak

ovisi o baznom sustavu i konkretnoj tablici).

70

5 SQL Upitni jezik

5.1 Uvod

SQL jezik inovirala je tvrtka IBM, polazeći od osnovnih operacija relacijskih baza

podataka, kako ih je definirao Codd . SQL je neproceduralni jezik IV generacije. Pod

time se podrazumijeva, da nije potrebno definirati korake ( proceduru) izvođenja,

nego se definira «što želimo kao rezultat i način kako će rezulatat biti prikazan».

Naredbe jezika dijele se u dvije skupine:

DML Data

Manipulation

Language

Komande za traženje, umetanje, izmjene i brisanje

podataka.

DDL Data

Definition

Language

Komande za definiciju objekata ( tablica, indeksa, pgleda )

relacijske baze podataka.

5.2 Upiti u relacijskoj bazi podataka

5.2.1 Projekcija i restrikcija

Definirana je relacija ( tablica ) u relacijskoj bazi Studenti, s atributima ( kolonama ):

Ime

Prezime

DatumRodjenja

StudijID

PostaID

Izlistajmo sadržaj tablice i prikažimo ga na konzoli komandom:

SELECT * FROM Studenti;

Rezulta ovog upita je:

71

Ime Prezime DatumRodjenja StudijID PostaID

Ivo Ivic 22.06.1981 1 21000

Ana Matic 01.01.1980 1 22000

Tomislav Butorovic 21.01.1982 1 21000

Ana Marija Tomic 21.12.1981 1 20000

Marko Markovic 24.07.1981 2

Helena Topic 05.08.1979 20000

Hrvoje Antic 21.03.1981 1 23000

Ante Zelic 08.09.1981 1 53000

Dakle, prikazane su sve kolone i svi retci tablice, pri čemu je poredak redaka slučajan,

najčešće onim redom kako su retci upisivani u tablicu.

Često nam nisu potrebne sve kolone, pogotovu kod tablica s većim brojem kolona.

Kolone koje želimo prikazati pobrojimo poslije ključne riječi SELECT, pa komanda

kojom ćemo prikazati samo Ime i Prezime studenta izgleda:

SELECT Ime, Prezime FROM Studenti;

Rezultat izvođenja komande je:

Ime Prezime

Ivo Ivic

Ana Matic

Tomislav Butorovic

Ana Marija Tomic

Marko Markovic

Helena Topic

Hrvoje Antic

Ante Zelic

72

Često želimo prikaz samo nekih redaka tablice i to onih koji zadovoljavaju određeni

uvjet. Prikažimo Ime i Prezime studenata koji su upisani na studij «Matematike –

Informatike». Pregledom tablice Studiji:

SELECT * FROM Studiji;

StudijID Studij

1 Matematika - Informatika

2 Tehnicka kultura - Informatika

3 Matematika

4 Matematika - Fizika

5 Biologija - Kemija

nalazimo, da studij Matematike – Informatike ima oznaku StudijID=1. Tako će upit za

prikaz imena i prezimena studenata Matematieke – Informatike biti:

SELECT Ime, Prezime

FROM Studenti

WHERE StudijID=1

Ime Prezime

Ivo Ivic

Ana Matic

Tomislav Butorovic

Konačno, želimo studente Matematike – Informatike ali po abecednom redu

prezimena:

SELECT Ime, Prezime

FROM Studenti

WHERE StudijID=1

ORDER BY Prezime

73

Ime Prezime

Tomislav Butorovic

Ivo Ivic

Ana Matic

Dakle, SQL – upitna komanda nad jednom tablicom ima opći oblik:

SELECT Kolona1, Kolona2, Kolona... | *

FROM Tablica

[ WHERE uvjet ]

[ ORDER BY Kolona2 [DESC], Kolona [DESC]... ]

pri čemu je redoslijed kolona proizvoljan i u SELECT klauzuli i u ORDER BY

klauzuli. Želimo li prikazati sve kolone tablice u poretku kako je tablica definirana,

možemo upotrijebiti simbol zvjezdice ( * ) koji uključuje sve kolone. Uvjet u

WHERE klauzuli mora za svaki redak rezultirati s jednom od dvije moguće

vrijednosti: ISTINA ili LAŽ. Prikazani će biti oni retci čija je vrijednost ISTINA.

SELECT klauzula provodi relacijsku operaciju projekcije, a WHERE provodi

operaciju restrikcije. Kada restrikcija nije potrebna, tj. žele li se prikazati svi reci,

onda se WHERE klauzula ispušta ( uglate zagrade u gornjoj definiciji), jednako kao i

ORDER BY klauzula, kada poredak nije eksplicitno definiran.

Kako Sustav za upravljanje relacijskom bazom podataka ( RDBMS ) izvodi ovaj upit

(tablica nema definiranih indeksa ):

� Prevede upit u niz poziva primitivnih procedura

� Utvrdi optimalan slijed izvođenja

� Kako nema definiranih indeksa ( ili kada je tablica s malim brojem redaka) izvodi

potpuno skeniranje tablice, dakle kreće od prvog do posljednjeg retka

� Stvori privremenu radnu tablicu, s kolonama

- Ime varchar(50)

- Prezime varchar(50)

uzimajući definiciju kolona iz temeljne tablice Studenti

74

� Pročita prvi redak tablice Studenti i ako je vrijednost kolone StudijID=1, upiše

vrijednosti Ime i Prezime u radnu tablicu. U slučaju da StudijID nije 1, ide na

slijedeći redak.

� Poreda retke u radnoj tablici po abecednom redu prezimena

� Ispiše rezultat u prozoru konzole

5.2.2 Prirodno spajanje

Nedostatak gornjih upita je taj, što brojčane oznake StudijID nisu dovoljno opisne, tj.

iako vidimo oznaku studija, ne znamo o kojem se studiju radi, naravno, ne želimo li

stalno tražiti naziv studija u tablici Studiji. Na sreću, SQL upitni jezik provodi i

operaciju prirodnog spajanja dviju ili više tablica:

SELECT Ime, Prezime, Studenti.StudijID, Studiji.*

FROM Studenti, Studiji

ORDER BY Prezime

Ime Prezime StudijID StudijID Studij

1 Hrvoje Antic 2 1 Matematika - Informatika

2 Hrvoje Antic 2 2 Tehnicka kultura - Informatika

3 Hrvoje Antic 2 3 Matematika

4 Hrvoje Antic 2 4 Matematika - Fizika

5 Hrvoje Antic 2 5 Biologija - Kemija

6 Tomislav Butorovic 1 1 Matematika - Informatika

7 Tomislav Butorovic 1 2 Tehnicka kultura - Informatika

8 Tomislav Butorovic 1 3 Matematika

- - -

38 Ante Zelic 3 3 Matematika

39 Ante Zelic 3 4 Matematika - Fizika

40 Ante Zelic 3 5 Biologija - Kemija

75

Rezultat ovog upita je relacija, prikazana kao Kartezijev produkt tablica Studenti i

Studiji. Dakle, svaki redak tablice Studenti je udružen sa svakim retkom tablice

Studiji. Kako Studenti sadrži 8 redaka, a Studiji 5, to rezultantana tablica sadrži 40

redaka. Uočavamo da neki retci ne sadrže istinite podatke: student Hrvoje Antić je

upisan na studij 2 – Tehnicka kultura – Informatika ( lijeva kolona StudijID u tablici ), pa

povezivanje sa studijima 1, 3, 4 i 5 ne odgovara istini. Zato u pravilu, operaciju prirodnog

spajanja ograničavamo na retke koji sadrže istinite podatke, dakle:

SELECT Ime, Prezime, Studenti.StudijID, Studiji.*

FROM Studenti, Studiji

WHERE Studenti.StudijID=Studiji.StudijID

ORDER BY Prezime

Ime Prezime StudijID StudijID Studij

Hrvoje Antic 2 2 Tehnicka kultura - Informatika

Tomislav Butorovic 1 1 Matematika - Informatika

Ivo Ivic 1 1 Matematika - Informatika

Marko Markovic 2 2 Tehnicka kultura - Informatika

Ana Matic 1 1 Matematika - Informatika

Ana Marija Tomic 3 3 Matematika

Helena Topic 2 2 Tehnicka kultura - Informatika

Ante Zelic 3 3 Matematika

Rezultat upita je virtualna tablica, pod čime se misli da ne postoji njen fizički zapis

na mediju, npr. disku, nego se dinamički izgrađuje pri izvođenju upita.

Uobičajeni naziv za ovakav oblik spajanja tablica je «spajanje jednakosti» ( eng.

«equi – join»).

5.2.3 Vanjsko ( Outer Join ) spajanje

Izvedimo sličan upit, kojim ćemo prikazati ime, prezime, poštanski broj i naziv pošte

studenta:

76

Ime Prezime PostaID PostaID Posta

Hrvoje Antic 23000 23000 Zadar

Tomislav Butorovic 21000 21000 Split

Ivo Ivic 21000 21000 Split

Ana Matic 22000 22000 Sibenik

Helena Topic 20000 20000 Dubrovnik

Ante Zelic 53000 53000 Gospic

Nažalost, umjesto očekivanih 8 redaka, tablica ne sadrži retke:

Ana Marija Tomic

Marko Markovic

Razlog leži u nedefiniranim poštanskim brojevima ( prigodom prijave, studenti nisu

prijavili adresu, jer su bili u fazi preseljenja ). No, mi želimo prikazati sve studente,

čak i ako nije definiran poštanski broj. Naravno, ako pošta nije poznata, neće biti

ispisana.

SELECT Ime, Prezime, Studenti.PostaID, Poste.*

FROM Studenti

LEFT OUTER JOIN Poste ON Studenti.PostaID=Poste.PostaID

ORDER BY Prezime

Ime Prezime PostaID PostaID Posta

Hrvoje Antic 23000 23000 Zadar

Tomislav Butorovic 21000 21000 Split

Ivo Ivic 21000 21000 Split

Marko Markovic NULL NULL NULL

Ana Matic 22000 22000 Sibenik

Ana Marija Tomic NULL NULL NULL

Helena Topic 20000 20000 Dubrovnik

Ante Zelic 53000 53000 Gospic

77

Engleski termin ovog oblik spajanja je LEFT OUTER JOIN, što možemo prevesti kao

«spajanje slijeva», a prikazuje sve retke u tablici s lijeve strane ključne riječi

(Studenti). Svaki redak tablice Studenti će pokušati spojiti s tablicom Poste preko

identičnih vrijednosti kolona PostaID i prikazati naziv pošte, kad god je spajanje

uspješno, odnosno NULL vrijednost kad spajanje nije moguće.

Vrijednost NULL tumačimo kao nedefinirana ili nepoznata vrijednost.

Kako Sustav za upravljanje relacijskom bazom podataka ( RDBMS ) izvodi ovaj upit

(tablice nemaju definirane indekse ):

� Prevede upit u niz poziva primitivnih procedura

� Utvrdi optimalan slijed izvođenja

� Kako nema definiranih indeksa ( ili kada je tablica s malim brojem redaka) izvodi

potpuno skeniranje tablice, dakle kreće od prvog do posljednjeg retka tablice

Studenti

� Stvori privremenu radnu tablicu, s kolonama

- Ime varchar(50)

- Prezime varchar(50)

- PostaID int ( iz tablice Studenti)

- PostaID int ( iz tablice Poste)

- Posta varchar(50)

uzimajući definiciju kolona iz temeljnih tablica Studenti i Poste

� Pročita prvi redak tablice Studenti i upiše vrijednosti u radnu tablicu:

Ivo Ivic 21000

� Pretraži tablicu Poste, počev od prvog retka za vrijednost

Poste.PostaID=Studenti.PostaID, odnosno dok ne pronađe PostaID=21000

� Upiše u redak radne tablice PostaID ( 21000 ) i Posta ( Split )

� Ponovlja postupak čitanja svih redaka

� Poreda retke u radnoj tablici po abecednom redu prezimena

� Ispiše rezultat u prozoru konzole

78

Isto tako, moguće je spojiti tablicu s desna:

SELECT Studiji.*, Ime, Prezime

FROM Studenti

RIGHT OUTER JOIN Studiji ON Studenti.StudijID=Studi ji.StudijID

ORDER BY Studiji.StudijID

StudijID Studij Ime Prezime

1 Matematika - Informatika Ivo Ivic

1 Matematika - Informatika Ana Matic

1 Matematika - Informatika Tomislav Butorovic

2 Tehnicka kultura - Informatika Marko Markovic

2 Tehnicka kultura - Informatika Helena Topic

2 Tehnicka kultura - Informatika Hrvoje Antic

3 Matematika Ana Marija Tomic

3 Matematika Ante Zelic

4 Matematika - Fizika NULL NULL

5 Biologija - Kemija NULL NULL

Ovim upitom prikazuju se sve moguće studijske grupe, te studenti onih studijskih

grupa koje imaju upisane studente. Studiske grupe bez studenata, isto tako su

navedene, ali naravno bez pridruženih studenata.

5.2.4 Unutrašnje ( Inner Join ) spajanje

U nekim prilikama, ipak želimo prikaz samo onih redaka koji se mogu spojiti s

odgovarajućim recima druge tablice. Recimo, kada trebamo uputiti pisma na adrese

studenata, studenti bez adrese trebaju biti ispušteni iz prikaza:

SELECT Ime, Prezime, Studenti.PostaID, Posta

FROM Studenti

INNER JOIN Poste ON Studenti.PostaID=Poste.PostaID

79

ORDER BY Prezime

Ime Prezime PostaID Posta

Hrvoje Antic 23000 Zadar

Tomislav Butorovic 21000 Split

Ivo Ivic 21000 Split

Ana Matic 22000 Sibenik

Helena Topic 20000 Dubrovnik

Ante Zelic 53000 Gospic

Isti rezulata se dobije i primjenom «Equi-join» spajanjem, no ipak «INNER JOIN»

zapis potpunog spajanja ima prednost, jer u komandi jasno razlikuje klauzulu

restrikcije WHERE od spajanja INNER JOIN.

Dakle, sintaksa potpune upitne komande koja izvršava projekciju, potpuno i

nepotpuno spajanje, restrikciju i određivanje poretka je:

SELECT Kolona1, Kolona2, ...

FROM Tablica1

[ INNER JOIN Tablica2 ON Kolona3=Kolona4 AND Kolona5=Kolona6 ]

[ LEFT OUTER JOIN Tablica3 ON Kolona7=Kolona8 AND ... ]

[ WHERE uvjet ]

[ ORDER BY Kolona1 [ ASC | DESC ], Kolona2 [ ASC | DESC ], ... ]

5.2.5 Funkcije u SQL Upitu

Često trebamo neke izračunate podatke, čija se vrijednost temelji na baznim

podacima, upisanim u tablici. Prikažimo ime i prezime studenata u jednoj koloni,

spajanjem kolona ime i prezime, te ukupni broj slova imena i prezimena ( razmak nije

uključen). Retke je potrebno poredati po dužini teksta, tako da student s najdužim

imenom i prezimenom bude na vrhu poretka:

80

SELECT Prezime + ' ' + Ime, LEN(Prezime + Ime)

FROM Studenti

ORDER BY LEN(Prezime + Ime) DESC

Ime Prezime Dužina Ime i Prezime

Butorovic Tomislav 17

Tomic Ana Marija 15

Markovic Marko 13

Topic Helena 11

Antic Hrvoje 11

Zelic Ante 9

Matic Ana 8

Ivic Ivo 7

Ključna riječ DESC ( DESCEDING ) označava inverzni poredak prikazane tablice.

Predefiniran je poredak od manje vrijednosti prema većoj ASC ( ASCEDING ) i nije

ga potrebno navoditi.

Neke često korištene funkcije su:

Sintaksa Opis

LEFT( Tekstualni izraz, n ) Izdvaja n pozicija s lijeva iz tekstualnog izraza (

obično tekstualna kolona tablice)

RIGHT( Tekstualni izraz,

n)

Izdvaja n pozicija s desna iz tekstualnog izraza (

obično tekstualna kolona tablice)

SUBSTRING( Tekstualni

izraz, S, D)

Izdvaja D znakova iz tekstualnog izraza, počev od

pozicije S izraza

LEN( Tekstualni izraz ) Daje dužinu ( broj slova ) tekstualnog izraza

81

Primjeri:

a) Prikazati početno slovo imena ( inicijal ) i prezime u jednoj koloni.

SELECT LEFT(Ime, 1) + '. ' + Prezime

FROM Studenti

Inicijal Prezime

I. Ivic

A. Matic

T. Butorovic

A. Tomic

M. Markovic

H. Topic

H. Antic

A. Zelic

b) Prikazati dva posljednja slova prezimena studenta

SELECT RIGHT(Prezime, 2), Prezime

FROM Studenti

2 zadnja slova

prezimena Prezime

ic Ivic

ic Matic

ic Butorovic

ic Tomic

ic Markovic

ic Topic

ic Antic

ic Zelic

82

c) Prikazati 3 slova imena studenta, počev od 3. slova

SELECT SUBSTRING(Ime, 3, 3 ), Ime

FROM Studenti

3 slova po čev od

3. Pozicije Ime

o Ivo

a Ana

mis Tomislav

a M Ana Marija

rko Marko

len Helena

voj Hrvoje

te Ante

d) Prikazati sve studente čije je ime=Ivo'

SELECT *

FROM Studenti

WHERE Ime='Ivo'

Ime Prezime DatumRodjenja StudijID PostaID

Ivo Ivic 22.06.1981 1 21000

e) Prikazati sve studente čije ime sadrži slovo i na bilo kojoj poziciji.

83

SELECT *

FROM Studenti

WHERE Ime LIKE '%i%'

Ime Prezime DatumRodjenja StudijID PostaID

Ivo Ivic 22.06.1981 1 21000

Tomislav Butorovic 21.01.1982 1 21000

Ana Marija Tomic 21.12.1981 3 NULL

f) Prikazati sve studente kojima naziv pošte sadrži slovi i na bilo kojoj poziciji.

SELECT Ime, Prezime, Studenti.PostaID, Posta

FROM Studenti

LEFT OUTER JOIN Poste ON Studenti.PostaID=Poste.PostaID

WHERE Posta LIKE '%i%'

Ime Prezime PostaID Posta

Ivo Ivic 21000 Split

Ana Matic 22000 Sibenik

Tomislav Butorovic 21000 Split

Helena Topic 20000 Dubrovnik

Ante Zelic 53000 Gospic

g) Prikazati sve studente kojima naziv pošte sadrži slovi i na bilo kojoj poziciji.

SELECT Ime, Prezime, Studenti.PostaID, Posta

FROM Studenti

LEFT OUTER JOIN Poste ON Studenti.PostaID=Poste.PostaID

WHERE Posta NOT LIKE '%i%'

84

Ime Prezime PostaID Posta

Hrvoje Antic 23000 Zadar

h) Prikazati ime, prezime i dužinu imena svim studentima, čije je ime duže od 5 slova.

Poredati po dužini imena.

SELECT Ime, Prezime, LEN(Ime)

FROM Studenti

WHERE LEN(Ime) > 5

ORDER BY LEN(Ime)

Ime Prezime

Duzina

Imena

Helena Topic 6

Hrvoje Antic 6

Tomislav Butorovic 8

Ana Marija Tomic 10

g) Prikazati ime i prezime studenta u jednoj koloni, te svaku pojavu malog slova a,

zamijeniti velikim slovom A.

SELECT REPLACE(Ime + ' ' + Prezime, 'a', 'A')

FROM Studenti

Ime Prezime

Ivo Ivic

AnA MAtic

TomislAv Butorovic

85

AnA MArijA Tomic

MArko MArkovic

HelenA Topic

Hrvoje Antic

Ante Zelic

5.2.6 Grupiranje podataka i sumarna izra čunavanja

a) Zanima li nas koliko imamo ukupno studenata u tablici Studenti, izvest ćemo upit:

SELECT count(*)

FROM Studenti

(No column name)

8

Dakle, count(*), pri čemu * da nas zanima broj redaka, bez obzira na definiranu

vrijednost kolona, će izbrojati ukupni broj redaka tablice.

Umetnemo li redak koji sadrži isključivo nedefinirane vrijednosti ( što je u suprotnosti

s pravilima relacijskih baza ), broj redaka bit će 9.

b) Ispišimo sada ukupni broj studenta, te broj studenata koji imaju definiranu adresu

(PostaID):

SELECT count(*) As BrojStudenata, count(PostaID) As ImaDefiniranuAdresu

FROM Studenti

BrojStudenata ImaDefiniranuPostu

8 6

86

c) Ispišimo broj studenata na svakoj studijskoj grupi. Grupe na kojima nema upisanih

studenata nije potrebno prikazati, te poredati prema broju studenata na grupi, počev

od najbrojnije grupe:

SELECT StudijID, count(*)

FROM Studenti

GROUP BY StudijID

ORDER BY count(*) DESC

StudijID count(*)

1 3

2 3

3 2

Kako programski sustav za upravljanje relacijskom bazom podataka( RDBMS) izvodi

ovaj upit ( Pretpostavka je da tablica nije indeksirana):

� RDBMS prevede definiranu komandu SQL upita u niz poziva primitivnih

procedure

� Izračuna optimalan redoslijed izvođenja primitiva

� U bazi za privremene – radne tablice stvori tablicu čije su kolone:

StudijID smallint ( Uzima definiciju kolone iz polazne tablice )

Count1 int

� Krene od prvog retka tablice Studenti i upiše vrijednost StudijID ( 1 ) u radnu

tablicu, te brojačkoj koloni Count dodijeli vrijednost 1.

� Prelazi na slijedeći redak i ponovno pronalazi StudijID=1. Kako oznaka studija

postoji u radnoj tablici, uveča brojač pojava Count za 1, te on sada iznosi 2.

87

� Prelazi na slijedeći redak i pronalazi StudijID=2, te stvori novi redak s brojačem

na inicijalnoj vrijednosti 1.

� Ove korake ponavlja sve do posljednjeg redka tablice, te svaki put kada naiđe na

veijednost StudijID, koja ne postoji u tablici, stvori redak. Ako oznaka studija

postoji u radnoj tablici, uvečava joj brojač za 1.

� Sortira retke radne tablice od najveće do najmanje vrijednosti brojačke kolone.

d) Gore dobiveni rezultat je ispravan, ali nije razumljiv, jer oznake studija nisu

deskriptivne. Zato bismo radije čitali rezultat uz puni naziv studijske grupe, pa zato

moramo spojiti tablicu Studiji, gdje se opisi nalaze:

SELECT Studij, count(*) As BrojStudenata

FROM Studenti S

INNER JOIN Studiji ST ON S.StudijID=ST.StudijID

GROUP BY Studij

ORDER BY count(*) DESC

Studij BrojStudenata

Matematika - Informatika 3

Tehnicka kultura - Informatika 3

Matematika 2

e) Zahtijeva li se prikaz samo onih studijskih grupa, na kojima je opisano više od 2

studenta, upit će biti:

SELECT Studij, count(*) As BrojStudenata

FROM Studenti S

INNER JOIN Studiji ST ON S.StudijID=ST.StudijID

GROUP BY Studij

HAVING count(*) > 2

ORDER BY count(*) DESC

88

Studij BrojStudenata

Matematika - Informatika 3

Tehnicka kultura - Informatika 3

Dakle, uvjet koji se odnosi na sumarne podatke definira se u klauzuli HAVING.

f) Želimo li pak, ispisati sve studijske grupe, te ukupan broj studenata upisan na svaku

studijsku grupu, uključujući i grupe na kojima nema upisanih studenata, upit će biti:

SELECT Studij, count(Ime)

FROM Studiji ST

LEFT OUTER JOIN Studenti S ON S.StudijID=ST.StudijI D

GROUP BY Studij

ORDER BY Studij DESC

Studij BrojStudenata

Biologija - Kemija 0

Matematika 2

Matematika - Fizika 0

Matematika - Informatika 3

Tehnicka kultura - Informatika 3

Uočimo, da count(Ime) osigurava da BrojStudenata bude 0, kada na Studiju nema

upisanih studenata, dok bi count(*) dao ispravan broj u slučaju da je barem jedan

student upisan na Studijsku grupu, ali bi isto tako dao vrijednost jedan i kad na grupu

nije upisan niti jedan student. U pravilu ćemo uvijek kada se tablice spajaju s OUTER

JOIN, upotrijebiti count( Kolona ).

89

g) Ispis studenata i njihovih prosječnih ocjena, dobit ćemo upitom:

SELECT Ime, Prezime, AVG(Ocjena*1.0)

FROM Studenti S

LEFT OUTER JOIN StudentiOcjene SO ON S.StudentID=SO.StudentID

GROUP BY Ime, Prezime

ORDER BY Prezime

Ime Prezime (no column name)

Hrvoje Antic 2.7500

Tomislav Butorovic 4.0000

Ivo Ivic 4.0000

Marko Markovic 2.7500

Ana Matic 3.0000

Ana Marija Tomic 3.0000

Helena Topic 4.0000

Ante Zelic 3.7500

h) Isto tako, možemo ispisati sve studente, čija je prosječna ocjena veća ili jednaka

3.5:

SELECT Ime, Prezime, AVG(Ocjena*1.0) As Prosje čnaOcjena

FROM Studenti S

LEFT OUTER JOIN StudentiOcjene SO ON S.StudentID=SO.StudentID

GROUP BY Ime, Prezime

HAVING AVG(Ocjena*1.0) >= 3.5

ORDER BY Prezime

Ime Prezime Prosje čnaOcjena

90

Tomislav Butorovic 4.0000

Ivo Ivic 4.0000

Helena Topic 4.0000

Ante Zelic 3.7500

i) Konačno, ispišimo sve studente s adresom 21000 ( Split ) koji imaju prosječnu

ocjenu 3.5 ili veću, te ukupan zbroj ocjena i prosječnu ocjenu svakog studenta, a

rezltate poredajmo po abecednom redu prezimena:

SELECT Ime, Prezime, PostaID, SUM(Ocjena) As ZbrojOcjena,

AVG(Ocjena*1.0) As ProsječnaOcjena

FROM Studenti S

LEFT OUTER JOIN StudentiOcjene SO ON S.StudentID=SO.StudentID

WHERE PostaID=21000

GROUP BY Ime, Prezime, PostaID

HAVING AVG(Ocjena*1.0) >= 3.5

ORDER BY Prezime

Ime Prezime PostaID 5.2.7 ZbrojOcjena Prosje čnaOcjena

Tomislav Butorovic 21000 16 4.0000

Ivo Ivic 21000 16 4.0000

Uočimo da kod upita grupiranja, projekcija( klauzula SELECT ) sadrži kolone iz

temeljnih tablica, kao Ime, Prezime i PostaID, te funkcije grupiranja,count(), SUM,

AVG. Operacija grupiranja ( klauzula GROUP BY ) mora sadržavati sve kolone po

kojima se grupiranje obavlja, dakle, Ime, Prezime i PostaID. Isto tako, rezultat

91

grupiranja može se sortirati samo po kolonama koje su navedene SELECT klauzuli,

jer one jedino i postoje u radnoj tablici, koja se naknadno sortira.

5.2.8 Logi čki složeni uvjeti

a) Ispišimo sve studente Studijske čije ime ili prezime započinje slovom a :

SELECT Ime, Prezime

FROM Studenti

WHERE Ime LIKE 'a%' OR Prezime LIKE 'a%'

Ime Prezime

Ana Matic

Ana Marija Tomic

Hrvoje Antic

Ante Zelic

Uvjet će biti zadovoljen ako Ime ili prezime započinje slovom A, pa su ova dva uvjeta

povezana logičkim operatorom OR.

b) Ispišimo sve studente kojima Ime započinje slovom A a prezime slovom Z:

SELECT Ime, Prezime

FROM Studenti

WHERE Ime LIKE 'a%' AND Prezime LIKE 'z%'

Ime Prezime

Ante Zelic

92

Uvjet je zadovoljen samo u slučaju kada ime započinje slovom A, a prezime slovom Z,

pa su ova dva uvjeta vezana logičkim operatorom AND.

c) Prikažimo studente, čije ime NE započinje slovomA i prezime započinje

slovom A:

SELECT Ime, Prezime

FROM Studenti

WHERE Ime NOT LIKE 'A%' AND Prezime LIKE 'A%'

Ime Prezime

Hrvoje Antic

Bilo koji od logičkih izraza može biti negiran, odnosno, rezultirat će istinom kada ne-

negirani uvjet daje laž.

d) Potrebno je izlistati sve studente, kojima ima ili prezime započinje slovom A,

a da im je PostaID=22000:

SELECT Ime, Prezime, PostaID

FROM Studenti

WHERE Ime LIKE 'A%' OR Prezime LIKE 'A%' AND PostaI D=22000

Ime Prezime PostaID

Ana Matic 22000

Ana Marija Tomic NULL

Ante Zelic 53000

Gornji upit nije dao očekivani rezultat, jer vidimo da samo jedan od tri studenta

prebiva na PostaID=22000. Problem je uzrokovan logičkim povezivanjem

elementarnih uvjeta. Naime, kao što kod računskih operacija množenje ima veći

prioritet od zbrajanja, tako logički operator AND ima veći prioritet od OR operatora.

93

Zato gornji uvjet zadovoljava svaki redak, čim ime započinje slovo A.

Redoslijed razvijanja pojedinih elementarnih uvjeta možemo odrediti upotrebo

zagrada, pa je ispraljeni upit :

SELECT Ime, Prezime, PostaID

FROM Studenti

WHERE ( Ime LIKE 'A%' OR Prezime LIKE 'A%' ) AND Po staID=22000

Ime Prezime PostaID

Ana Matic 22000

Uočavamo da se najprije izračunava vrijednost logičkog izraza u zagradama.

5.2.9 Pobrojane vrijednosti

Ispišimo sve studente upisane na StudijID 1, 3 ili 5 :

SELECT Ime, Prezime, StudijID, PostaID

FROM Studenti

WHERE StudijID IN ( 1, 3, 5 )

Ime Prezime StudijID PostaID

Ivo Ivic 1 21000

Ana Matic 1 22000

Tomislav Butorovic 1 21000

Ana Marija Tomic 3 NULL

Ante Zelic 3 53000

Isti upit moguće je napisati ina ovaj način:

SELECT Ime, Prezime, StudijID, PostaID

FROM Studenti

94

WHERE StudijID=1 OR StudijID=3 OR StudijID=5

Da se izbjegne ponavljanje imena kolone StudijID, prvi oblik upita, kod kojeg se

nabroji lista traženih vrijednosti, je mnogo prikladniji i razumljiviji, te se redovito

koristi. RDBMS izvodi oba upita na isti način.

5.2.10 Ugnijež đeni upiti

a) Prikažimo sve studente koji studiraju na istoj studijskog grupi kao student čije je

prezime Ivić.

Ovaj zadatak bismo mogli odraditi pomoću dva uipta:

Upit 1:

SELECT StudijID

FROM Studenti

WHERE Prezime='Ivic'

Zatim očitamo vrijednost StudijID i izvedemo

Upit 2:

SELECT Ime, Prezime, StudijID

FROM Studenti

WHERE StudijID=1

Oba upita moguće je definirati kao jedinstveni, ugniježđeni upit:

SELECT Ime, Prezime, StudijID

FROM Studenti

WHERE StudijID IN (SELECT StudijID

FROM Studenti

WHERE Prezime='Ivic')

Ime Prezime StudijID

Ivo Ivic 1

95

Ana Matic 1

Tomislav Butorovic 1

Dakle, umjesto da pobrojimo konstantne vrijednosti, možemo definirati upit koji

vraća listu pobrojanih vrijednosti. Najprije se izvodi upit u zagradama, dakle

ugniježđeni, a zatim vanjski. Može se ugnijezditi veći broj upita.

b ) Komplementarno gornjem upitu, možemo ispisati sve studente koji nisu upisani na

isti studij kao student Ivić:

SELECT Ime, Prezime, StudijID

FROM Studenti

WHERE StudijID NOT IN (SELECT StudijID

FROM Studenti

WHERE Prezime='Ivic')

Ime Prezime StudijID

Ana Marija Tomic 3

Marko Markovic 2

Helena Topic 2

Hrvoje Antic 2

Ante Zelic 3

Uočimo, upotrebu ključne riječi NOT, kojom se označava da uvjet zadovoljavaju svi

studenti, čija je vrijednost StudijID različita od 1, tj. nemaju StudijID isti kao student

Ivić.

Često se ugnježđuju upiti grupiranja, kao u primjeru:

c) Ispišimo sve studente, koji studiraju na studijskim grupama, na kojima je upisano

više od 2 studenta.

96

SELECT Ime, Prezime, StudijID

FROM Studenti

WHERE StudijID IN (SELECT StudijID

FROM Studenti

GROUP BY StudijID

HAVING count(*) > 2)

Ime Prezime StudijID

Ivo Ivic 1

Ana Matic 1

Tomislav Butorovic 1

Marko Markovic 2

Helena Topic 2

Hrvoje Antic 2

2.9 Jedinstvene vrijednosti redaka

a) Želimo znati početna slova ( inicijale ) imena studenata:

SELECT LEFT(Ime, 1)

FROM Studenti

ORDER BY 1

Inicijal

A

A

A

H

H

97

I

M

T

U slučaju velikog broja redaka u tablici, ovakav prikaz bi bio potpuno nepregledan, pa

želimo vidjeti samo jedinstvene pojave svakog slova, jer nas saznanje da imamo

jednog ili više studenata čije ime započinje s A zadovoljava:

SELECT DISTINCT LEFT(Ime, 1)

FROM Studenti

ORDER BY 1

Inicijal

A

H

I

M

T

Ključna riječ DISTINCT označava da se retci s istom vrijednošću svih kolona,

prokažu samo jednom.

Kako RDBMS izvodi ovaj upit:

� Stvori privremenu radnu tablicu s kolonama kako je navedeno u SELECT klauzuli,

dakle u našem primjeru, s jednom kolonom.

� Izvodi upit pretražujući tablicu, provjeravajući zadovoljenje uvjeta ako postoji,

poziva funkciju LEFT, koja vraća prvo slovo imena.

� Upisuje vrijednosti projeciranih kolona onih redaka koji zadovoljavaju uvjet u

radnu tablicu

98

� Sortira retke u radnoj tablici po svim kolonama

� Pretraži radnu tablicu ispisujući svaki put samo prvu pojavu retka, preskačući

retke koji imaju iste vrijednosti u svim kolonama, kao već ispisani redak.

2.10 Null vrijednost

Pri upisu retka u tablicu, vrijednosti nekih kolona mogu biti nepoznate, te ih moramo

ostaviti nedefiniranim. Naravno, neke kolone moraju imati obavezno unijete

vrijednosti, pa se pri kreiranju tablice zahtijeva obavezan unos vrijednosti. U našem

primjeru tablice Studenti, ime, prezime i studijska grupa moraju biti unijete, a

PostaID, te datum rođenja mogu ostati nedefinirane. Nedefinirana vrijednost naziva se

Null vrijednost.

a) Ispišimo sve studente koji imaju PostaID = Null :

SELECT Ime, Prezime, StudijID, PostaID

FROM Studenti

WHERE PostaID IS Null

Ime Prezime StudijID PostaID

Ana Marija Tomic 3 NULL

Marko Markovic 2 NULL

Uočimo da se Null vrijednost testira ključnom rječju IS Null i da test = Null, gdje je

znak jednakosti zamijenio ključnu riječ IS, ne mora dati očekivani rezultat. Naime, o

postavkama baze podataka ovisi rezultat test = Null, no to prelazi okvire ovih skripta.

b) Prikažimo sve studente koji imaju definiranu vrijednost PostaID, dakle

PostaID IS NOT Null :

SELECT Ime, Prezime, StudijID, PostaID

FROM Studenti

WHERE PostaID IS NOT Null

99

Ime Prezime StudijID PostaID

Ivo Ivic 1 21000

Ana Matic 1 22000

Tomislav Butorovic 1 21000

Helena Topic 2 20000

Hrvoje Antic 2 23000

Ante Zelic 3 53000

100

5.3 SQL komande za definiciju objekata relacijske b aze

podataka

U prethodnom poglavlju smo izvodili upite nad već definiranim tablicama u koje su

prethodno unijeti podaci. U ovom poglavlju ćemo definirati i izvoditi komande

kojima se stvaraju, mijenjaju i uništavaju objekti relacijske baze. Različiti sustavi za

upravljanje relacijskim bazama ( RDBMS ) pružaju mogućnost definiranja nekih

specifičnih objekata, no svi sigurno podržavaju mogućnost kreiranja, mijenjanja i

uništavanja tablica, pogleda ( views) i indeksa.

Isto tako, valja napomenuti da je mnogo prokladniji način stvaranja objekata

korištenjem grafičkog korisničkog sučelja. Lakše je klikom miša odabrati željenu

akciju ili tip podatka, nego pamtiti sintaksu komandi, te ćemo najvjerojatnije objekte

baze kreirati koristeći grafički interfejs i pokazivačku jedinicu ( miš ) na razvojnom

računalu. U fazi implementacije baze na ciljnom računalu ili većem broju ciljnih

računala, bilo bi veoma neprikladno ponavljati niz već odrađenih «klikova». Srećom,

danas korišteni sustavi relacijskih baza mogu generirati komande za stvaranje bazbih

objekata. Mi moramo komande razumjeti i biti u stanju zadati ih ručno.

U ovo poglavlju ćemo se upoznati samo s komandama u tekstualnom obliku.

5.3.1 Stvaranje, promjena i uništavanje tablice

Tablica sadrži kolone i retke. Kolone se moraju definirati prigodom stvaranja tablice,

a retci se stvaraju unosom vrijednosti u tablicu. Tablica predstavlja fizičku

implementaciju entiteta, a kolone atributa. Tablica je određena korisničkim imenom

kreatora i imenom tablice. Isti korisnik mora svakoj tablici odabrati jedinstveno ime.

Različiti korisnici mogu koristiti ista imena za svoje tablice. Kako jedan sustav za

upravljanje relacijskim bazama može u isto vrijeme upravljati s više baza na istom

stroju, kažimo da je tablica određena preko tri komponente:

Baza.Korisnik.Tablica

Jasno je, da u slučajevima kada se radna baza i korisnik podrazumijevaju, nije

potrebnonavoditi bazu i korisnika.

101

5.3.1.1 Stvaranje tablice Studenti

Entitet Studenti opisan je atributima:

Atributi Opis

Ime Slobodno unijeti tekst, maksimalne dužine 30 znakova,

obavezan unos

Prezime Slobodno unijeti tekst, maksimalne dužine 30 znakova,

obavezan unos

DatumRodjenja Datum, unos nije obavezan

StudijID Cio broj, s vrijednostima od 1 do 255, obavezan unos. Opis

brojčane oznake pogledati u tablici Studiji

PostaID Cio broj, s vrijednostima od 10000 ( Zagreb) do 99999, unos

nije obavezan. Opis brojčanih vrijednosti pogledati u tablici

Poste

Kod kreiranja tablice je veoma važno odabrati odgovarajući tip podatka svake kolone.

Na taj način onemogućavamo unos nesuvislih ili nemogućih podataka, barem u onoj

mjeri koliko je to moguće. Pojasnimo primjerom: ako bi kolona DatumRodjenja bila

tekstualnog tipa, onda bi bo moguć unos datuma 30.02.2002, no znamo da veljača ne

može imati 30 dana. Zato je važno da kolona DatumRodjenja bude datumskog tipa,

pri čemu baza neće dopustiti unos nemogućeg datuma. Dakle, pravilnim izborom tipa

podatka kolone sprečavamo nemoguće unose, no neispravni unosi još su uvijek

moguću: npr. osobi rođenoj 2. siječnja 1980, još je uvijk moguće nepažnjom unijeti

datum rođenja 1. veljače 1980.

Dakle, tablica Studenti imat će kolone:

Kolona Tip podatka Null vrijednost Opis tipa podatka

Ime varchar(30) NOT Null tekstualni,

maksimalna dužina

30 znakova. Unosi

«troše» onoliko

102

byte-ova koliko je

znakova unijeto, uz

dodatk 2 byte za

dužinu unijetog

podatka

Prezime varchar(30) NOT Null tekstualni,

maksimalna dužina

30 znakova

DatumRodjenja datetime Null Datumski podatak,

8 byte-ova ( ovisno

RDBMS)

StudijID tinyint NOT Null brojčani podataka

između 0 i 255, 1

byte

PostaID int Null brojčani podatak, 4

byte

Opisanu tablicu kreirajmo komandom:

CREATE TABLE Studenti (

Ime varchar(30) NOT Null,

Prezime varchar(30) NOT Null,

DatumRodjenja datetimeNull,

StudijID tinyint NOT Null

)

Tablicu Studenti, stvorenu gornjom komandom mogli smo kreirati i preko grafičkog

korisničkog sučelja.

103

Kreiranje tablice preko GUI

5.3.1.2 Uništavanje tablice

Tablicu koju više ne trebamo možemo uništiti, komandom:

DROP TABLE Studenti

Želimo li ponovno stvoriti tablicu s istim imenom, postojeću moramo najprije uništiti,

jer nisu moguće dvije tablice s istim imenom.

5.3.1.3 Izmjena strukture tablice

Pri kreiranju tablice Studenti, propustili smo kreirati kolonu PostaID. Vrlo je čest

slučaj da se tijekom eksploatacije baze podataka moraju dodati neke kolone, kao

posljedica naknadog proširenja zahtjeva. Uništavanje, radi ponovnog kreiranja tablice

nije moguće jer su podaci već upisani, a to bi značilo njihov gubitak. Dapače, tablicu

će koristiti postojeća aplikacija, pa ona ne smije biti nedostupna. Zato su nam na

raspolaganju komande za dodavanje novih kolona, te za promjenu postojećih. Iz

praktičnih razloga, nastojimo nikada ne uništiti postojeće kolone, jer neki segment

aplikacije koji se poziva na stara imena kolona, neće raditi. Kolone možemo dodavati

bez bojazni po greške postojećih aplikacija, naravno ako se pridržavamo i nekih

drugih «praktičnih pravila» o kojima će biti riječi u slijedećem poglavlju.

Dodajmo kolonu PostaID int Null :

ALTER TABLE Studenti ADD PostaID int Null

104

Kolonu nije moguće dodadi uz zabranu Null vrijednosti ( NOT NULL ), ako nije

definirana predefinirana ( default) vrijednost.

Navedimo i komandu za uništavanje kolone, iako je dobro izbjegavati takvu praksu, iz

ranije opisanih razloga:

ALTER TABLE Studenti DROP COLUMN PostaID

Promijenimo tip podatka kolone StudijID iz tinyint u smallint ( 2 byte ).

ALTER TABLE Studenti2 ALTER COLUMN StudijID smallin t

Pri izmjenama tipa podataka iz tipa većeg opseg vrijednosti u manji opseg, moramo

osigurati da već upisane vrijednosti ne prelaze novi, manji opseg.

Mijenjamo li maksimalno dopušteni broj znakova u kolonama varijabilne širine, može

doći do gubitka dijela unosa koji ne stane u novu, manju dimenziju. Neke RDBMS će

prijaviti grešku:

Server: Msg 8152, Level 16, State 9, Line 1

String or binary data would be truncated.

The statement has been terminated.

5.3.2 Stvaranje i uništavanje pogleda – view-a

U praksi ćemo vrlo često trebati ispise iz tablice Studenti povezane s tablicama Studiji

i Poste, jer nas u pravilu zanima naziv studija i pošte. Da bi olakšali pretraživanje i

izbjegli složenost često korištenih upita, stvorit ćemo pogled ( view) Vstudenti, koji

će povezivati potrebne tablice. Isto tako, javlja se potreba da neke kolone ne budu

dostupne stanovitoj grupi korisnika, dok ih neka druga skupina može čitati. U našem

primjeru, zadržat ćemo kolonu DatumRodjenja skrivenom u pogledu Vstudenti.

CREATE VIEW VStudenti

AS

(

SELECT Ime, Prezime, Studij, S.PostaID, Posta

FROM Studenti S

INNER JOIN Studiji ST ON S.StudijID=ST.StudijID

105

LEFT OUTER JOIN Poste P ON S.PostaID=P.PostaID

)

Sada je ispis imena, prezimena, naziva studija, poštanskog broja i naziva pošte,

krajnje jednostavan:

SELECT *

FROM Vstudenti

Ime Prezime Studij PostaID Posta

Ivo Ivic Matematika - Informatika 21000 Split

Ana Matic Matematika - Informatika 22000 Sibenik

Tomislav Butorovic Matematika - Informatika 21000 Split

Ana Marija Tomic Matematika NULL NULL

Marko Markovic Tehnicka kultura - Informatika NULL NULL

Helena Topic Tehnicka kultura - Informatika 20000 Dubrovnik

Hrvoje Antic Tehnicka kultura - Informatika 23000 Zadar

Ante Zelic Matematika 53000 Gospic

RDBMS pogled tretira kao virtualnu tablicu, dakle ne čita je s medija ( diska ) nego

dinamički izgrađuje za vrijeme izvođenja upita, baš kao da smo zadali upit:

SELECT Ime, Prezime, Studij, S.PostaID, Posta

FROM Studenti S

INNER JOIN Studiji ST ON S.StudijID=ST.StudijID

LEFT OUTER JOIN Poste P ON S.PostaID=P.PostaID

To znači da možemo primijeniti restrikciju i sortiranje:

SELECT *

FROM VStudenti

WHERE Studij LIKE '%Informatika%'

106

ORDER BY Studij, Prezime

Ime Prezime Studij PostaID Posta

Tomislav Butorovic Matematika - Informatika 21000 Split

Ivo Ivic Matematika - Informatika 21000 Split

Ana Matic Matematika - Informatika 22000 Sibenik

Hrvoje Antic Tehnicka kultura - Informatika 23000 Zadar

Marko Markovic Tehnicka kultura - Informatika NULL NULL

Helena Topic Tehnicka kultura - Informatika 20000 Dubrovnik

Zgodno je ovdje napomenuti, da suvremni sustavi za upravljanje relacijskim bazama

omogućavaju stvaranje materijaliziranih pogleda. Naime, relacijska baza mora biti

najmanje u 3. normalnoj formi, a to znači da svaka relacija ( tablica ) mora biti

najmanje u toj ili višoj normalnoj formi. Kod ispisa podataka često moramo spajati

veći broj tablica, što značajno ugrožava odzivna vremena, jer je operacija spajanja u

pravilu vremenski zahtjevna, naročito pri spajanju relacija s velikim brojem unosa

(redaka). Stoga se u praksi, nakon normaliziranja baze, često pristupa denormalizaciji.

U tom postupku materijalizirani pogledi igraju značajnu ulogu, jer oni predstavljaju

fizičku kopiju spojenih tablica, pri čemu RDBMS sam održava redudantne podatke.

Korisnici baze vide relacije ( tablice) normalizirane, bez odstupanja od teoretskih

postavki, a materijalizirani pogledi osiguravaju iznimno brze upite.

5.3.2.1 Uništavanje pogleda

Pogled koji više ne trebamo, ili ga želimo ponovno kreirati, možemo uništiti

komandom:

DROP VIEW Vstudenti

Jasno je da uništavanje pogleda nema nikakvog utjecaja na bazne tablice i podatke.

5.3.3 Stvaranje indeksa

Cilj ovog poglavlja su naredbe SQL jezika za stvaranje objekata relacijske baze, pa

tako i indeksa. Analizom upita, planiranjem indeksa, te ostalih potankosti vezanih uz

indekse se bavimo u posebnom poglavlju, a ovdje samo kratko pojasnimo pojam i

značaj indeksa.

107

Pretpostavimo da želimo pronaći u telefonskom imeniku splitskog područja sve osobe

čije je prezime Ivić. Zadatak ćemo brzo obaviti, jer je imenik poredan po abecednom

redu prezimena pretplatnika. No, ako bi zadatak bio pronaći sve osobe koje žive u

Teslinoj ulici, potrošili bi mnogo više vremena. Jednostavno, morali bi krenuti od

prvog pretplatnika, na prvoj stranici imenika, te svakom pretplatniku pregledati ulicu.

Postupak provjere ulice bi provodili jednom po jednom, svim pretplatnicima, sve do

posljednjeg na zadnjoj stranici imenika. Razlog za potpuno čitanje imenika leži u

činjenici da je imenik sortiran po abecedi prezimena, ali ne i po ulicama. Dakle,

imenik je indeksiran po prezimenu. Kada bi željeli isti imenik sortiran i po ulicama, to

bi radi uštede papira mogli napraviti na ovaj način: dodati stranice s abecednim

popisom ulica, te kod svake ulice nabrojati sve stranice i retke u kojima ćemo pronaći

pretplatnike s adresom u Teslinoj ulici. To bi vjerojatno značilo, da bi brzo pronašli

Teslinu ulicu i onda bismo za svakog pretplatnika morali pronaći stranicu, te ponovno

za slijedećeg pretplatnika skoknuti na stranicu indeksa ulica, pročitati na kojoj se

stranici nalazi slijedeći pretplatnik i tako redom. Dakle, indeksiranjem se značajno

ubrzava pretraživanje.

Shvatimo naredbu za kreiranje indeksa kao sortiranje podataka u određenom poretku

(slučaj abecednog poretka po prezimenima), odnosno, kao dodavanje stranica s

abecednim poretkom ulica i pokazivačima stranica i redaka na kojima su pretplatnici

date ulice.

Naravno, mi želimo indeksirati tablicu studenti, po prezimenu, kako bismo u tablici s

mnogo redaka brzo pronašli traženo prezime ( naredbom je stvoren indeks koji

odgovara indeksiranju ulica u gornjem tekstu).

CREATE INDEX Prezime_X ON Studenti(Prezime)

Postupak stvaranja indeksa u velikim tablicama, s nekoliko stotina tisuća i miliona

redaka, može potrajati nekoliko minuta.

5.3.4 Uništavanje indeksa

Shvatimo komandu kao «trganje» iz telefonskog imenika dodanih stranica sa

sortiranim ulicama. Srećom, stranice medija za pohranu podataka se proglašavaju

slobodnima i bit će ponovno upotrebljene, dok recikliranje starog papira ipak ne ide

tako glatko.

108

DROP INDEX Studenti.Prezime_X

Uočimo, da se indeks određuje imenom tablice i imenom indeksa, no to se može

razlikovati od jednog do drugog sustava relacijskih baza.

Podrobnije o indeksima govori se u drugim poglavljima ovih skripta.

Opće pravilo stvaranja i uništavanja objekata baze podataka

- stvaranje

CREATE TipObjekta NazivObjekta (

Definicija objekta

)

- uništavanje

DROP TipObjekta NazivObjekta

5.4 Naredbe za upisivanje, promjenu i brisanje poda taka

Cjeloviti informacijski sustav izgrađuje niz ekranskih formi – prozora preko kojih

upisujemno, mijenjamo ili brišemo podatke u tablicama relacijske baze, služeći se

programskim objektima za spajanje na bazu i rad sa skupovima podataka. No, pored

toga, u svim fazama života baze podataka, postavlaju se nepredviđeni upiti, a isto tako

se obavljaju ad hock izmjene podataka, pa stoga treba obratiti potrebnu pažnju i steći

potrebnu sigurnost i samopouzdanje u korištenju naredbi za manipulaciju podacima.

5.4.1 Upisivanje ( insertiranje ) retka

Upišimo novog studenta u tablicu Studenti, čije je ime Marko, prezime Marić, rođen

je 07.08.1980. i upisan je na studijsku grupu 1. Poštanski broj njegove adrese za sada

nije poznat.

INSERT INTO Studenti( Prezime, Ime, StudijID, DatumRodjenja)

VALUES( 'Marti ć', 'Marko', 1, '1980/08/07' )

109

Primjetimo da nakon ključne riječi INSERT INTO slijedi ime tablice, te lista kolona u

koje će biti upisani podaci, dok ključnu riječ VALUES slijedi lista vrijednosti. Lista

kolona i lista vrijednosti moraju se podudarati po broju i tipu podataka. Sustav će

javiti grešku ako:

broj kolona nije jednak broju datih vrijednosti

(There are more columns in the INSERT statement than values specified in

the VALUES clause. )

upisujemo vrijednost čiji tip ne odgovara ili se ne može pretvoriti u tip kolone,

npr. ako bismo u cjelobrojnu kolonu StudijID pokušali upisati tekst 'Marko'.

(Syntax error converting the varchar value 'Marko' to a column of data type

smallint.)

tekstualne konstante nisu zatvorene u jednostrukim navodnicima

(The name 'Marko' is not permitted in this context. Only constants,

expressions, or variables allowed here. Column names are not permitted.)

datum nije ispravan.

(The conversion of a char data type to a datetime data type resulted in an

out-of-range datetime value.)

nije navedena vrijednost za kolonu s obaveznim unosom ( NOT Null ), a da

istovremeno nije zadana ( kod kreiranja tablice ) pretpostavljena (default)

vrijednost.

(Cannot insert the value NULL into column 'Prezime', table

'DT.dbo.Studenti'; column does not allow nulls. INSERT fails.The statement

has been terminated.)

5.4.2 Upisivanje svih kolona

Kada naredba za upisivanje retka obuhvaća listu svih kolona definiranih u tablici, nije

neophodno navoditi listu kolona, već samo listu vrijednosti, pri čemu poredak

vrijednosti mora odgovarati fizičkom poretku kolona u tablici:

INSERT INTO Studenti

VALUES( 'Slavko', 'Peri ć', '1980/08/07', 1, 21000 )

110

Ovakvu naredbu možemo koristiti ad hock, dakle upotrijebimo i izbrišemo, ali nipošto

u programima ili skriptama koje se koriste trajno. Naime, tijekom vremena prpizići će

potreba za dodavanjem jedne ili više kolona u tablicu, što je uobičajena praksa kako

primjena baze napreduje, a onda broj kolona tablice i navedenih vrijednosti se neće

podudariti. Stoga je praktičana neophodnost da se uvijek navodi lista kolona u koje se

upisuju vrijednosti. Naknadno dodane kolone moraju dopuštati Null vrijednost ili

imati definiranu pretpostavljenu ( default ) vrijednost.

5.4.3 Upisivanje iz jedne tablice u drugu

Stvorimo li tablicu Studenti2, s kolonama Ime, Prezime i StudijID, tada u nju možemo

upisati dio ili sve retke iz tablice Studenti, naredbom:

INSERT INTO Studenti2( Ime, Prezime, StudijID)

SELECT Ime, Prezime, StudijID

FROM Studenti

WHERE StudijID=1

Dobijena poruka je (5 row(s) affected), te možemo provjeriti sadržaj tablice Studenti2.

5.4.4 Pomjena podataka ( update )

Potrebno je promijeniti DatumRodjenja studentu Ivo Ivić. Ispravan datum je

21.06.1980.

UPDATE Studenti

SET DatumRodjenja='1980/06/21'

WHERE Ime='Ivo' AND Prezime='Ivi ć'

Prije izvođenja ovakve naredbe, moramo biti sigurni da će se promjena provesti samo

željenom studentu, pa je kod ovakvih promjena najbolje koristiti primarni ključ u

WHERE klauzuli. Česte su greške koje se dese zbog brzopletosti, npr. izvođenjem

komande:

UPDATE Studenti

SET DatumRodjenja='1980/06/21'

111

Učinak je katastrofalan: svim studentima postavljen je isti datum rođenja. Naravno i

za ovakve pogreške moramo predvidjeti lijek, no u svakom slučaju dobro je izbjeći

ovako neugodne situacije, pažljivim zadavanjem naredbe UPDATE.

5.4.5 Promjena podataka tablice vrijednostima druge tablice

Svim studentima koji nemaju definiran poštanski broj, ( PostaID IS NULL), potrebno

je upisati broj čija druga znamenka slijeva odgovara broju StudijID, a prva znamenka

je 2.

Kako se radi o zahtjevnoj naredbi, najprije ćemo provjeriti naše razmišljanje

izvođenjem SELECT upita, jer jasno je, pogrešno promijenjene podatke nije lako

popraviti:

SELECT StudijID, S.PostaID, P.PostaID

FROM Studenti S, Poste P

WHERE CONVERT(varchar,

StudijID)=SUBSTRING(CONVERT(varchar, P.PostaID), 2,1) AND

P.PostaID BETWEEN 20000 AND 29999 AND S.PostaID IS NULL

StudijID S.PostaID P.PostaID

3 NULL 23000

2 NULL 22000

1 NULL 21000

Kako smo zaista dobropostavili uvjet, to vidimo da su obuhvaćeni samo studenti

kojima nije definirana PostaID ( NULL ), te da je prva znamenka slijeva poštanskog

broja 2 i konačno StudijID i driga znamenka poštanskog broja se uvijek podudaraju.

Stoga, provedimo promjene podataka:

UPDATE Studenti

SET PostaiD=P.PostaID

FROM Studenti S, Poste P

112

WHERE CONVERT(varchar, StudijID)=SUBSTRING(CONVERT( varchar,

P.PostaID), 2,1) AND

P.PostaID BETWEEN 20000 AND 29999 AND S.PostaID IS NULL

Jasno je, da će nakon izvedene naredbe PostaID dobiti ranijom komandom izlistane

vrijednosti.

5.4.6 Brisanje ( delete ) retka

Možemo brisati pojedinačne retke, grupu redaka koji zadovoljavaju određeni kriterij,

ili pak sve retke u tablici.

5.4.6.1 brisanje jednog retka

Općenito, sigurno ćemo izbrisati samo jedan redak, ako se u WHERE klauzuli testira

vrijednost primarnog ključa, jer on na jedinstven način identificira svaki redak.

Primarni ključ tablice Studenti je StudentID, čije vrijednosti automatski generira

sustav relacijske baze ( Autonumber ).

Brišemo, dakle trajno uklanjamo iz tablice, studenta Hrvoja Antića, čijije StudentID (

u mojoj tablici ) 7 naredbom:

DELETE FROM Studenti

WHERE StudentID=7

Kako smo upotrijebili primarni ključ kao uvjet, to smo sigurni da je izbrisan najviše

jedan redak.

5.4.6.2 brisanje više redaka koji zadovoljavaju uvjet

Pretpostavimo da su se svi studenti iz Zadarske i Šibenske županije ispisali sa studija,

te ih moramo ukloniti iz tablice. Iskoritit ćemo pogodnost da sve pošte u Zadarskoj

županiji započinju s 23, a u šibenskoj s 22, pa su u opsegu brojeva 22000 do 23999

zaparavo sva mjest ove dvije županije:

DELETE FROM Studenti

WHERE PostaID BETWEEN 22000 AND 23999

Rezulta je: (3 row(s) affected).

113

brisanje svih redaka tablice

Vrlo jednostavno, kako se i da pretpostaviti, ispuštanjem uvjeta bit će izbrisani svi

retci tablice.

DELETE FROM Studenti

Skrenimo pažnju, da je nakon izvedene komande, tablica potpuno prazna. Prije

izvođenja ovakvih komandi, moramo biti sigurni što želimo.

114

6 Literatura:

1. Mladen Varga: «Baze podataka – Konceptualno, logičko i fizičko modeliranje

podataka», Društvo za razvoj informacijske pismenosti (DRIP), Zagreb, 1994.

2. Darko Hrenić: «ORACLE», Znak, Zagreb, 1995.

3. Ratko Vujnović: «SQL i relacijski model podataka», Znak, Zagreb, 1995.

4. Malcolm Dodwell: «System Modelling Techniques» ( Course Notes ), Oracle

Corporation UK Ltd, 1993.

5. David Solomon: «MS SQL Server 6.5», SAMS Publishing, 1996.

6. Kalen Delany: «Inside SQL Server 2000», 2000.

7. Ken Henderson: «The Gurus's Guide to Transact-SQL», Addison-Wesley,

2000.