uvod u relacijske baze podataka

Uvod u relacijske baze podataka

Tonci Caric i Mario Buntic

Zagreb, 2015

Autori:Tonci Caric i Mario Buntic

Naslov:Uvod u relacijske baze podataka

Strucni recezenti:prof. dr. sc. Hrvoje Golddoc. de. sc. Edouard Ivanjko

Za tisak pripremio:Mario Buntic

Mjesto i godina izdavanja:Zagreb, 2015

© Tonci Caric i Mario BunticZasticeno licencijom Creative Commons Imenovanje–Nekomercijalno–Bez prerada3.0 Hrvatska. http://creativecommons.org/licenses/by-nc-nd/3.0/hr/

http://creativecommons.org/licenses/by-nc-nd/3.0/hr/

http://creativecommons.org/licenses/by-nc-nd/3.0/hr/

Sadrzaj

Predgovor i

I Baze podataka i podatkovni modeli 1

1 Osnovni pojmovi 21.1 Sto je baza podataka? . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Sustav za upravljanje bazom podataka . . . . . . . . . . . . . . . . . 31.3 Podatkovni modeli . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1 Hijerarhijski podatkovni model . . . . . . . . . . . . . . . . . 51.3.2 Mrezni podatkovni model . . . . . . . . . . . . . . . . . . . . 61.3.3 Objektno orijentiran podatkovni model . . . . . . . . . . . . . 61.3.4 Relacijski podatkovni model . . . . . . . . . . . . . . . . . . . 8

2 Zivotni ciklus baze podataka 12

II Logicko dizajniranje baze podataka 14

3 ER modeliranje 153.1 Modeliranje podataka . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 Jednostavne veze . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.2 Slozene veze . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 ER modeliranje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.1 Dijagram entiteta . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2 ER dijagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.3 Primjer ER modeliranja: ITS laboratorij . . . . . . . . . . . . 22

4 Relacijski model 254.1 Osnove relacijske algebre . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1 Teorija skupova . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.2 Prirodne relacijske operacije . . . . . . . . . . . . . . . . . . . 274.1.3 Logicke operacije . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Ocuvanje integriteta podataka . . . . . . . . . . . . . . . . . . . . . . 314.2.1 Domena podataka . . . . . . . . . . . . . . . . . . . . . . . . 314.2.2 Referencijalni integritet . . . . . . . . . . . . . . . . . . . . . . 32

5 Normalizacija 345.1 Prva normalna forma . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1.1 Primarni kljuc . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1.2 Ovisnost relacije o poretku . . . . . . . . . . . . . . . . . . . . 365.1.3 Null atributi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.1.4 Ponavljajuce grupe . . . . . . . . . . . . . . . . . . . . . . . . 365.1.5 Ponavljanje grupa stupaca . . . . . . . . . . . . . . . . . . . . 37

1

5.2 Druga normalna forma . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.1 Tablica izvan 2NF . . . . . . . . . . . . . . . . . . . . . . . . 395.2.2 Normalizacija do 2NF . . . . . . . . . . . . . . . . . . . . . . 405.2.3 Anomalije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.4 Kandidatski kljucevi . . . . . . . . . . . . . . . . . . . . . . . 41

5.3 Treca normalna forma . . . . . . . . . . . . . . . . . . . . . . . . . . 425.3.1 Normalizacija do 3NF . . . . . . . . . . . . . . . . . . . . . . 43

5.4 Daljnja normalizacija . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

III Strukturirani jezik upita 44

6 Uvod u SQL 456.1 SQL standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.1.1 SQL89 (SQL1) . . . . . . . . . . . . . . . . . . . . . . . . . . 456.1.2 SQL92 (SQL2) . . . . . . . . . . . . . . . . . . . . . . . . . . 466.1.3 SQL99 (SQL3) . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2 Tipovi podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.2.1 Predefinirani tipovi podataka . . . . . . . . . . . . . . . . . . 466.2.2 Korisnicki definirani tipovi podataka . . . . . . . . . . . . . . 50

7 Kreiranje strukture baze podataka 527.1 Kreiranje baze podataka . . . . . . . . . . . . . . . . . . . . . . . . . 527.2 Ogranicenja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.3 Kreiranje i brisanje tablica . . . . . . . . . . . . . . . . . . . . . . . . 547.4 Mijenjanje strukture tablica . . . . . . . . . . . . . . . . . . . . . . . 54

8 Modifikacija podataka 568.1 Dodavanje podataka u tablicu . . . . . . . . . . . . . . . . . . . . . . 568.2 Brisanje podataka iz tablice . . . . . . . . . . . . . . . . . . . . . . . 578.3 Azuriranje podataka iz tablice . . . . . . . . . . . . . . . . . . . . . . 57

9 Dohvacanje podataka iz tablica 599.1 DISTINCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609.2 TOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609.3 Sortiranje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619.4 Filtriranje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629.5 Specijalni operatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659.6 Agregatne funkcije . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659.7 Grupiranje podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . 669.8 Podupiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

10 Spajanje tablica 6910.1 Unutarnje spajanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7010.2 Lijevo vanjsko spajanje . . . . . . . . . . . . . . . . . . . . . . . . . . 7110.3 Desno vanjsko spajanje . . . . . . . . . . . . . . . . . . . . . . . . . . 7210.4 Potpuno vanjsko spajanje . . . . . . . . . . . . . . . . . . . . . . . . 72

10.5 Unakrsno spajanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7310.6 Spajanje tablica podupitima . . . . . . . . . . . . . . . . . . . . . . . 7410.7 Spajanje tablice sa samom sobom . . . . . . . . . . . . . . . . . . . . 74

11 Operacije sa skupovima 7511.1 UNION i UNION ALL . . . . . . . . . . . . . . . . . . . . . . . . . . 7511.2 INTERSECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7611.3 EXCEPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

12 Sistemske funkcije 7812.1 Funkcije za rad sa datumom i vremenom . . . . . . . . . . . . . . . . 7812.2 Matematicke funkcije . . . . . . . . . . . . . . . . . . . . . . . . . . . 7912.3 Funkcije za rad sa znakovima . . . . . . . . . . . . . . . . . . . . . . 81

IV Napredne mogucnosti SQL-a 83

13 Rad sa skriptama i upravljanje greskama 8413.1 Skripte, varijable i grupiranje naredbi . . . . . . . . . . . . . . . . . . 8413.2 Uvjetno izvrsavanje naredbi . . . . . . . . . . . . . . . . . . . . . . . 85

13.2.1 IF i IF...ELSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 8513.2.2 WHILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8613.2.3 CASE naredba . . . . . . . . . . . . . . . . . . . . . . . . . . 86

13.3 Upravljanje greskama . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

14 Pogledi 8914.1 Kreiranje jednostavnog pogleda . . . . . . . . . . . . . . . . . . . . . 8914.2 Azuriranje i brisanje pogleda . . . . . . . . . . . . . . . . . . . . . . . 9014.3 Ovisnost pogleda o shemi baze podataka . . . . . . . . . . . . . . . . 9014.4 Zastita sadrzaja pogleda . . . . . . . . . . . . . . . . . . . . . . . . . 9114.5 Manipulacija podacima kroz poglede . . . . . . . . . . . . . . . . . . 91

15 Pohranjene procedure 9315.1 Osnove rada za pohranjenim procedurama . . . . . . . . . . . . . . . 9315.2 Vracanje vrijednosti iz procedure . . . . . . . . . . . . . . . . . . . . 9415.3 Odgodena provjera referenci . . . . . . . . . . . . . . . . . . . . . . . 9415.4 Tipicno koristenje procedura - CRUD operacije . . . . . . . . . . . . 95

16 Korisnicki definirane funkcije 9616.1 Skalarne koje vracaju skalarnu vrijednost . . . . . . . . . . . . . . . . 9616.2 Jednostavne funkcije koje vracaju tablicu . . . . . . . . . . . . . . . . 9716.3 Slozene funkcije koje vracaju tablicu . . . . . . . . . . . . . . . . . . 9716.4 Brisanje funkcija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

17 Okidaci 9917.1 T-SQL naredbe za rad sa okidacima . . . . . . . . . . . . . . . . . . . 9917.2 Specijalne tablice i ispitivanje vrste dogadaja . . . . . . . . . . . . . . 9917.3 Detekcija promjenjenog stupca . . . . . . . . . . . . . . . . . . . . . . 100

17.4 Ukljucivanje i iskljucivanje okidaca . . . . . . . . . . . . . . . . . . . 10117.5 Redoslijed postavljanja okidaca . . . . . . . . . . . . . . . . . . . . . 101

18 Kursori 10218.1 Dohvacanje zapisa preko kursora . . . . . . . . . . . . . . . . . . . . . 10318.2 Status kursora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10418.3 Azuriranje podataka kursorima . . . . . . . . . . . . . . . . . . . . . 106

19 Transakcije 10719.1 Svojstva transakcija . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

19.1.1 Atomarnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10719.1.2 Konzistentnost . . . . . . . . . . . . . . . . . . . . . . . . . . 10719.1.3 Izolacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10719.1.4 Trajnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

19.2 Koristenje transakcija . . . . . . . . . . . . . . . . . . . . . . . . . . . 10819.2.1 Ugnjezdivanje transakcija . . . . . . . . . . . . . . . . . . . . 10919.2.2 Upravljanje transakcijama . . . . . . . . . . . . . . . . . . . . 109

19.3 Vrste transakcija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10919.3.1 Automatske . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11019.3.2 Eksplicitne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11019.3.3 Batch-scoped transakcije . . . . . . . . . . . . . . . . . . . . . 11019.3.4 Implicitne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11019.3.5 Distribuirane transakcije . . . . . . . . . . . . . . . . . . . . . 111

19.4 Izolacijski nivoi i zakljucavanja . . . . . . . . . . . . . . . . . . . . . 11219.4.1 Zakljucavanje resursa i eskalacija zakljucavanja . . . . . . . . 11219.4.2 Vrste lokota . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11419.4.3 Kompatibilnost lokota . . . . . . . . . . . . . . . . . . . . . . 11619.4.4 Vrste i svojstva izolacijskih nivoa . . . . . . . . . . . . . . . . 11719.4.5 Problemi konkurentnosti . . . . . . . . . . . . . . . . . . . . . 11919.4.6 Problemi konkurentnosti koje rjesavaju izolacijski nivoi . . . . 12219.4.7 Problem potpunog zastoja . . . . . . . . . . . . . . . . . . . . 123

V Fizicko dizajniranje baze podataka i optimizacija upita 128

20 Indeksi 12920.1 DBMS manipulacija podacima . . . . . . . . . . . . . . . . . . . . . . 129

VI Literatura i dodaci 131

Literatura 132

Dodatak A - Shema baze podataka 133

Dodatak B - Kreiranje baze podataka 134

Predgovor

Ova skripta namijenjena je studentima Fakulteta prometnih znanosti, Sveucilista uZagrebu kao pomoc pri svladavanju gradiva iz kolegija: Baze podataka i Naprednebaze podataka.

i

Dio I

Baze podataka i podatkovni modeli

1

1 Osnovni pojmovi

U poglavlju su definirani osnovni koncepti i pojmovi vezani uz baze podataka, opi-sane su najvaznije zadace sustava za upravljanje bazom podataka, apstrakcijskerazine modela podataka, podatkovni modeli te zivotni ciklus baze podataka.

1.1 Sto je baza podataka?Bazu podataka promatramo kao zbirku podatkovnih zapisa pohranjenih na racunalukoja je lako dostupna korisnicima i aplikacijama. Sastoji se od skupa medusobno po-vezanih podataka, pohranjenih zajedno, bez stetne ili nepotrebne zalihosti. Podacisu u bazi pohranjeni u obliku neovisnom o aplikacijama koje ih koriste, a rukovanjepodacima izvodi se iskljucivo kroz zajednicko i nadzirano sucelje.

Sustav za upravljanje bazom podataka (SUBP, engl. DBMS – Database Manage-ment System) je programska podrska koja izvodi sve operacije nad bazom podataka.Primjeri operacija nad bazom podataka su kreiranje strukture, brisanje, mijenjanjei dohvacanje podataka, administracija i dr. Sustav za upravljanje bazom podatakabrine se o fizickom smjestaju podataka, administraciji sustava i obnovi podatakanakon rusenja baze podataka.

Zbirka podatkovnih zapisa pohranjenih na racunalu predstavlja bazu podatakajedino ako ima odredena svojstva, primjerice, ako se podacima upravlja uz osigu-ranje referencijalnog i domenskog integriteta, ako je omogucen zasticeni zajednickipristup podacima odredenoj grupi korisnika, ako postoji jasna podatkovna shema,ako je podrzan standardni upitni jezik itd. Ipak, dogovorena definicija ovih svoj-stava ne postoji vec su mogucnosti koje baze podataka pruzaju, predmet trzisneutakmice u softverskoj industriji i upravo to osigurava stalan tehnoloski napredakbaza podataka.

Sustavi za upravljanja bazom podataka obicno se kategoriziraju prema modelupodataka koji podrzavaju: relacijski, objektno orijentirani, mrezni i dr. Veliki dioSUBP-a, odnosno podupiruce programske podrske, neovisan je o modelu podataka,te je razvoj usmjeren na poboljsanje performansi kao sto su brzina izvodenja ope-racija nad podacima, zastita integriteta ili obnova nakon rusenja baze podataka. Upostignutim performansama postoje velike razlike medu SUBP-ovima.

Strukturni opis objekata sadrzanih u bazi podataka naziva se shema. Shemaopisuje objekte i odnose medu njima prikazane u bazi podataka. Modeli baza poda-taka predstavljaju nacin organiziranja sheme, odnosno modeliranja strukture bazepodataka. Postoji vise razvijenih modela no najcesce se koristi relacijski model po-dataka, koji prikazuje informacije kroz vise tablica od kojih se svaka sastoji od viseredaka i stupaca. Relacijski model prikazuje odnose uporabom vrijednosti koje suzajednicke za vise tablica. Ostali modeli poput hijerarhijskog i mreznog modelakoriste prikaze i odnose koji su eksplicitniji.

2

POGLAVLJE 1. OSNOVNI POJMOVI

1.2 Sustav za upravljanje bazom podatakaSustav za upravljanje bazama podataka (SUBP) je programski sustav koji omogucavaupravljanje podacima u bazi podataka. SUBP se temelji na odabranom modelu po-dataka. Osnovne zadace koje se mora obavljati svaki SUBP su:

• zastita objekata baza podataka od neovlastenog koristenja,

• ocuvanje integriteta podataka u bazi podataka,

• omogucavanje obnove podataka razlicitim nacinima u slucaju gubitka poda-taka,

• omogucavanje konkurentnosti, tj. omogucavanje visekorisnickog pristupa istimpodacima u bazi podataka istovremeno,

• omogucavanje opisa podataka metapodacima,

• identificiranje optimalne strukture za najprikladnije upravljanje podacima,

• opis i rukovanje podacima.

Baze podataka su visekorisnicki sustavi u kojima je nuzno osigurati dodjeljiva-nje i postivanje ovlasti pristupu, mijenjaju i brisanju podataka. Administriranjekorisnickih ovlasti i njihovo provodenje jedna je od bitnih zadaca SUBP-a. PojediniSUBP-ovi razlikuju se u nacinu provodenja i upravljanja ovlastima koristenja poda-taka, a najcesce se implementacija svodi na koristenje unaprijed odredenih uloga iprava pojedinih korisnika. Moderniji pristup u odnosu na hijerarhijski model ovlastije mogucnost da vlasnik podataka dodijeli ovlasti nad podacima drugom korisnikubez direktnog upletanja administratora baze podataka.

Arhitektura SUBP-a moze se podjeliti na tri razine prikazane na Slici 1.1.

Vanjska razina je najbliza korisniku (front-end) i predstavlja korisnicku aplikacijuza pristup i rad s podacima. Sastoji se od razlicitih vanjskih pogleda ili pod-shema koje sadrze razlicite podatke i veze pojmovne razine. Ova razina odnosise na logicku predodzbu o bazi podataka ili njezinom dijelu kojeg koristi po-jedina aplikacija.

Pojmovna razina (logicki opis) podrazumijeva koncept realizacije baze podatakana temelju saznanja o projektiranju baze podataka. Na ovoj razini se defi-nira logicka struktura baze, tj. tipovi podataka, struktura tablica, veze medunjima (primarni i strani kljucevi) te ogranicenja koja cuvaju integritet poda-taka.

Unutarnja razina (fizicki opis) vodi racuna o nacinima fizickog spremanja poda-taka i njihovom upravljanju na fizickom disku. Opisuje kako se elementi logickerazine preslikavaju na cilindre i staze fizickih diskova. Najmanja logicka je-dinica s kojom SUBP upravlja je stranica. Osim navedenog unutarnja razinaobuhvaca upravljanje radnom memorijom.

Uvod u relacijske baze podataka Stranica 3 od 134


Slika 1.1: Razine arhitekture SUBP-a

Slika 1.2: Primjer lika

Organizacijom SUBP-a u tri razine postize se odvojena fizicka i logicka repre-zentacija podataka. Podatak opisan na logickoj razini kao tablica na disk se nesprema kao tablica. Aplikacijama, razvojnim inzenjerima, korisnicima i dr. je do-voljno da poznaju logicki opis podataka, relacije i ogranicenja medu njima kako bimogli njima upravljati sve dok im nije potrebno znanje o fizickoj reprezentaciji tihistih podataka.

1.3 Podatkovni modeliPodatkovni model je formalni sustav sastavljen od skupa objekata, operacija i pra-vila cjelovitosti. Njime je definirana logicka struktura baze podataka. Postoji visepodatkovnih modela od kojih ce se u nastavku detaljnije obraditi: hijerarhijski,mrezni, objektni i relacijski.

Navedeni podatkovni modeli bit ce obradeni na primjeru lika na Slici 1.2.



Slika 1.3: Hijerarhijski model podataka

1.3.1 Hijerarhijski podatkovni modelHijerarhijski model baza podataka i pripadajuci SUBP pojavili su se 60-tih godinaproslog stoljeca. Trenutna zastupljenost ovih baza nije velika, ali imaju svoje pred-nosti kao sto je brzo spremanje i dohvacanje podataka. Ove prednosti proizlazeiz cinjenice da su podaci hijerarhijski slozeni u stabla te je unaprijed poznat putdohvata pojedinog podatka. Zanimljivo je da se prva implementacija hijerarhijskogmodela nije pojavila nakon definiranja modela vec se model definirao na osnovuIBM-ovog IMS (Information Managment System) sustava. Struktura hijerarhijskogmodela bazirana je na zapisima koji se sastoje od polja. Uredeni skup zapisa na-ziva se stablo, a baza podataka je sastavljena od skupa stabala. Stablo zapocinjesa korijenom koji se sastoji od vise zapisa (djece). Dijete moze imati samo jednogroditelja. Ovaj odnos naziva se odnos roditelj - dijete. Mana ovog modela je sto nijemogao ostvariti relaciju vise na prema vise vec samo jedan na prema vise tj. jedanroditelj je mogao imati vise djece, a svako dijete moze imati samo jednog roditelja.Sljedeci nedostatak je bila redundantnost podataka, a najtezi problem je bilo kom-pleksno brisanje i azuriranje podataka koje je zahtijevalo poznavanje fizickih vezaizmedu zapisa. Jezik za upravljanje podacima u hijerarhijskoj bazi sastoji se odskupa operatora pomocu kojih se obraduju podaci u stablima. Operatori se sastojeod operacija lociranja korijena stabla, pomicanja na sljedece stablo, te pomicanjana sljedeci zapis.

Na Slici 1.3 prikazan je primjer hijerarhijskog modela podataka koji pohranjujepodatke o liku prikazanom na Slici 1.2. Vidljivo je kako se relacije ostvaruju tako-zvanim odnosom roditelj-dijete (npr. Lik je roditelj poligonima A i B). Takoder jevidljiva pojava redundantnih podataka tj. podataka koji se zapisuju na vise mjesta.Poligon A i B su omedeni duzinom i koja je zapisana na dva mjesta. Iz ovog razlogaproizlazi problem azuriranja i brisanja podataka jer se isti podatak nalazi na dvarazlicita mjesta, pa prema tome ako se zeli obrisati vrh 5 potrebno je pronaci svapojavljivanja vrha 5 kako bi ga se uspjesno obrisalo.

Najpoznatije implementacije sustava za upravljanje hijerarhijskim bazama su:

• IMS s programskim jezikom DL/1 (Data Language/1),

• Windows Registry od Microsoft-a.



Slika 1.4: Mrezni model podataka

1.3.2 Mrezni podatkovni modelMrezni model se pojavio krajem 60-tih godina. Prvi standard na podrucju bazapodataka nastao je na osnovu mreznog model 1971. godine. Mrezni model je slicanhijerarhijskom modelu, samo sto za razliku od hijerarhijskog svako dijete moze imativise roditelja. U ovom modelu se mogu prikazivati samo relacije jedan na premavise ili vise na prema vise. Prednost ovog modela u odnosu na hijerarhijski jeuspostavljanje veze izmedu razlicitih hijerarhija zapisa. Temeljni element mreznestrukture su zapisi, pri cemu jedan zapis moze imati vise roditelja, dok svaki rodi-telj moze imati vise podredenih zapisa (djece). Ovakva struktura kada se prikazegraficki najslicnija je mrezi otkuda dolazi i ime mreznog podatkovnog modela. Pred-nosti mreznog modela su brzi pristup podacima, dobro upravljanje integritetom ipodatkovna neovisnost. Nedostaci su velika kompleksnost sustava i zahtjevna im-plementacija modela.

Na Slici 1.4 prikazan je primjer mreznog modela podataka koji pohranjuje po-datke o liku prikazanom na Slici 1.2. Veze se takoder kao i u prethodnom modeluostvaruju odnosom roditelj-dijete, ali se mogu ostvariti i relacije vise na prema visecime se redundatni podaci eliminiraju. Time je postignuto poboljsanje u odnosu nahijerarhijski model podataka.

Najpoznatije implementacije sustava za upravljanje mreznim bazama su:

• IDMS (Integrated Database Management System), proizvod Computer Asso-ciates,

• DBMS-10, DBMS-20, VAX DBMS proizvodi tvrtke Digital Equipment Cor-poration.

1.3.3 Objektno orijentiran podatkovni modelObjektno orjentiran podatkovni model (engl. Object Oriented Data Model) je modelkoji prihvaca semantiku objekata podrzanu u objektno orijentiranim programskimjezicima. Ideja se pojavila priblizno u isto vrijeme kada i relacijski model. Prviprototipovi sustava za upravljanje objektnim bazama pojavili su se 80-tih godina,



dok su se prvi komercijalni alati pojavili pocetkom 90-ih. Tek zadnjih godina modelpostaje sve popularniji. Za aplikacije koje zahtjevaju spremanje kompleksnijih po-dataka sa mnogo relacija kao sto su prostorni podaci objektno orijetiran podatkovnimodel pokazao se mnogo brzi u odnosu na relacijski model. Osnovna svojstva bezkojih se model ne moze proglasiti objektno orijentiranim su:

Apstrakcija - predstavlja pojednostavljivanje slozenih objekata iz realnog svijeta nanacin da se izdvoje bitne karakteristike svakog objekta i njegovo ponasanje.

Enkapsulacija - predstavlja implementaciju koja ce dovesti do zeljenog ponasanjaobjekta. Potrebno je odvojiti sucelje objekta od same implementacije njegovogponasanja. Enkapsulacijom je moguce promjeniti implementaciju ponasanjaobjekta bez da se mijenja sucelje. Bitno je da drugi objekti mogu koristitisamo sucelje bez poznavanja implementacije ponasanja objekta.

Modularnost - sastoji se od formiranja modularnih cijelina koje se mogu ponasatineovisno i mogu komunicirati s drugim modulima. Npr. vise se objekata kojiimaju zajednicka svojstva “zapakira” u modul koji ima zajednicko sucelje zakomunikaciju sa ostalim objektima i modulima.

Nasljedivanje - je svojstvo definiranja objekta na temelju objekata koji su vec defi-nirani. Novi objekt “nasljeduje” sve metode i atribute vec definiranog objektate moze i ne mora dodati neke nove atribute ili izmjeniti ponasanje nasljedenihmetoda. Npr. objekt Ucenik bi mogo naslijediti objekt Osoba te njegove atri-bute ime, prezime i datum rodenja. Bitno je zapamtiti da objekt koji nasljedujemoze izmjeniti ponasanje objekta kojeg nasljeduje, ali ne i njegovu strukturu.

Polimorfizam - je svojstvo promjenjivosti oblika. Ovo se smatra najvaznijim svoj-stvom objektno orijentiranog koncepta gdje objekt moze predstavljati vise odjednog tipa podatka. Polimorfizam je objasnjen na iducem primjeru. Akoobjekt GeometrijskiLik ima metodu IzracunajPovrsinu(), a njega nasljedujuobjekti Trokut i Kvadrat sto znaci da i oni imaju tu metodu, no implementa-cija metode IzracunajPovrsinu() je razlicita za kvadrat i trokut. Novi objektce se stvoriti na sljedeci nacin

GeometrijskiLik gl1 = new Trokut();GeometrijskiLik gl2 = new Kvadrat();

nad objektom GeometrijskiLik moze se pozvati metoda IzracunajPovrsinu().Takvim pozivima nad objektima gl1 i gl2 izracunat ce se povrsina na dvarazlicita nacina. Polimorfizam znaci da ce ista metoda na razlicitim tipovimapodataka biti izracunata na razlicite nacine.

gl1.IzracunajPovrsinu();gl2.IzracunajPovrsinu();

Ne poziva se metoda IzracunajPovrsinu() nad likom GeometrijskiLik vec nadobjektima Trokut i Kvadrat koji nasljeduju metodu IzracunajPovrsinu().



Slika 1.5: Objektni model podataka

Na Slici 1.5 prikazan je primjer objektno orijentiranog modela podataka kojipohranjuje podatke o liku prikazanom na Slici 1.2. Svaki objekt u objektnoj bazidobije indentifikator (GUID, engl. Globally Unique Identifier) na temelju kojegSUBP gradi relacije i na osnovu kojeg se moze jedinstveno indentificirati svaki objektu bazi podataka.

Najveci nedostatak ovog modela je nemogucnost integracije sa relacijskim mo-delom koji je daleko najzastupljeniji. Osim integracije problem je i standardizacijaupitnog jezika.

1.3.4 Relacijski podatkovni modelRelacijski podatkovni model razvio je engleski matematicar Edgar Frank Codd-a.Prezentiran je 1970 u njegovom clanku “A Relational Model of Data for Large Sha-red Data Banks”. Edgar Frank Codd-a u to vrijeme radio je u IBM-u. Njegovaocekivanja su bila da ce oni prvi implementirati relacijski model spremanja poda-taka, sto se nije dogodilo zbog ustrajnosti IBM-a na koristenju vec provjerenog, alizastarjelog hijerarhijskog modela u sustavu IMS. Prva tvrtka koji je implementiralarelacijski model podataka bila je Oracle koja je i danas sinonim za baze podataka.Codd-ov relacijski upitni jezik Alpha nije prihvacen vec je prihvacen nerelacijski je-zik SEQUEL. Zanimljivo je da je prvotno ime SEQUEL preimenovano u SQL jer jejedna od zrakoplovnih kompanija u to vrijeme imala zasticen naziv SEQUEL (viseo samom jeziku SQL u poglavlju 6).



Codd se dugi niz godina borio sa raznim proizvodacima SUBP-ova jer su krivo ilidjelomicno implementirali relacijski podatkovni model, a nazivali su ga relacijskim.Rezultat njegove borbe je objava dvanaest pravila koja SUBP mora postivati kakobi bio relacijski:

1. Predstavljanje informacija (engl. The information rule) - podaci se reprezen-tiraju na jedinstven nacin kao vrijednosti u relacijama, tj. tablicama, jednos-tavno i dosljedno.

2. Pravilo pristupa (engl. The guaranteed access rule) - svaki podatak u tablicimora biti logicki dostupan preko kombinacije imena tablica, vrijednosti pri-marnog kljuca i imena atributa.

3. Tretiranje nepoznatih vrijednosti (engl. Systematic treatment of null values) -vrijednost NULL se tretira kao nepoznata vrijednost neovisno o tipu podatka.Nepoznata vrijednost nije isto sto i prazan znak ili broj 0 (nula) ili varijabla.

4. Dinamicki online katalog (engl. Active online catalog based on the relationalmodel) - Rjecnik baze podataka u kojem se nalaze informacije o samoj relacij-skoj shemi tablica mora biti pohranjen kao i svi ostali podaci u bazi. Nad timpodacima autorizirani korisnici mogu postavljati upite koristeci (SQL) upitnijezik.

5. Pravilo sveobuhvatnog jezika (engl. The comprehensive data sublanguage rule)- mora postojati jezik za komunikaciju sa bazom podataka koji podrzava rela-cijske operatore koji se odnose na modifikaciju podataka, definiciju podatakai administraciju.

6. Pravilo pogleda (engl. The view updating rule) - ovo pravilo definira takozvaneTablice pogleda (engl. View table) koje se sastoje od jedne SELECT naredbekoja dohvaca podatke iz jedne ili vise tablica. Sve poglede sustav mora mociazurirati.

7. Pravila azuriranja skupova (engl. High-level insert, update, and delete) - ovopravilo kaze da podaci iz relacijske baze podataka mogu biti preuzeti u sku-povima podataka iz jedne ili vise tablica. Ovo pravilo takoder zahtjeva daoperacije umetanja, azuriranja i brisanja moraju biti podrzane za skupovepodataka, a ne samo za jedan redak jedne tablice.

8. Nezavisnost fizickih podataka (engl. Physical data independence) - aplikacijekoje pristupaju podacima u relacijskoj bazi podataka ne smiju biti ovisne opromjenama u fizickom nacinju spremanja podataka.

9. Nezavisnost logickih podataka (engl. Logical data independence) - logickanezavisnost znaci da se odnosi izmedu tablica mogu mijenjati, a da se isto-vremeno ne utjece na funkcije aplikacija koje se spajaju na tablice. Daklepromjena strukture baze podataka ne smije uzrokovati ponovnu izradu bazepodataka ili aplikacije.



10. Nezavisnost integriteta podataka (engl. Integrity independence) - sustav zaupravljanje bazama podataka mora se brinuti o integritetu baze podataka, ane aplikacije izvana.

11. Distribuirana nezavisnost (engl. Distribution independence) - aplikacija moranastaviti operativno raditi kada se uvede distribuirana verzija SUBP-a ili kadase distribuirana verzija centralizira.

12. Pravilo o nenarusavanju (engl. The nonsubversion rule) - integritet podatakane smije biti narusen zaobilazenjem pravila integriteta i ogranicenja.

13. Nulto pravilo (engl. Rule 0 ) - da bi sustav za upravljanje bazama podatakabio relacijski mora koristiti iskljucivo relacijske mogucnosti baze podataka kodupravljanja.

Danas se SUBP smatra relacijskim ako postuje sest pravila od navedenih trinaest.Na Slici 1.6 je prikazan primjer relacijskog modela podataka koji pohranjuje

podatke o liku prikazanom na Slici 1.2. Podaci se spremaju u tablice, a relacijeizmedu tablica se ostvaruju stvarnim fizickim zapisom koji se naziva strani kljuc,a stvara ga korisnik. Prema tome stvaraju se tablice Lik, Poligon i Linije u kojese unose podaci: identifikator (IdLik, IdPoligon, IdLinija) i oznaka. Osim toga utablicu Poligon dodaje se strani kljuc LikId koji oznacava kojem liku pojedini poligonpripada. Tablica PoligonOmedjuje predstavlja relaciju izmedu tablica Poligona iLinije u koju se upisuje koje linije omeduju koji poligon.

Relacijski model je najsporiji, ali i najfleksibilniji sto ga cini najzastupljenijim udanasnje vrijeme.

Najpoznatije implementacije sustava za upravljanje relacijskim bazama su:

• SQL Server,

• Oracle,

• Microsoft Access,

• PostgreSQL,

• MySQL i dr.

U ovom poglavlju prikazan je kratki povijesni pregled relacijskog modela i primjerspremanja podataka relacijskim modelom, a detaljnija obrada slijedi u nastavkuskripte cija tematika i pociva na ovom modelu.



Slika 1.6: Relacijski model podataka


2 Zivotni ciklus baze podataka

Zivotni ciklus baze podataka ukljucuje osnovni korak dizajniranja globalne logickesheme baze podataka, raspodjele podataka diljem racunalne mreze i definicije shemelokalnog SUBP-a. Kada se dizajn zavrsi, zivotni ciklus baze podataka, nastavlja seimplementacijom te odrzavanjem. Ovo poglavlje sadrzi pregled koraka zivotnogciklusa baze podataka sa njihovim rezultatima koji su prikazani na Slici 2.1. Obu-hvaceni su svi koraci izrade baze podataka od ideje do realizacije stvarne baze po-dataka.

Slika 2.1: Zivotni ciklus baze podataka

Analiza korisnickih zahtjeva Zahtjevi baze podataka odreduju se razgovorom dava-telja i korisnika podataka. Zahtjevi baze podataka koji se moraju utvrditi prije

12

POGLAVLJE 2. ZIVOTNI CIKLUS BAZE PODATAKA

same implementacije i izrade modela ukljucuju potrebne podatke za procesi-ranje, relacije izmedu podataka i platformu za implementaciju baze podataka.

Utvrdivanje korisnickih zahtjeva Globalna shema, tj. konceptualni model poda-taka koji prikazuje sve podatke i njihove odnose, razvija se koristenjem entitet-relacija dijagrama. Konacni model podataka mora biti u svim normalnimformama. Metodologija razvoja modela je jednaka za distribuiranu i centrali-ziranu bazu podataka.

Implementacija, nadgledanje, odrzavanje i promjene baze podataka Jednom kadaje zavrsen dizajn, baza podataka moze biti stvorena kroz formalnu shemu im-plementacije koristeci jezik za definiranje objekata baze podataka (DDL engl.Data definition language). Zatim se koristi jezik za manipulaciju nad poda-cima (DML engl. Data manipulation language) kako bi se postavili odovarajuciupiti nad bazom podataka, azurirali podaci, provelo indeksiranje, postavilaogranicenja te referencijalni integritet baze podataka. SQL jezik sastoji se odkonstruktora oba jezika. Primjerice naredba za kreiranje tablice predstavljaDDL, a naredba za dohvacanje podataka predstavlja DML.U trenutku kada baza podataka pocinje sa radom nadgledanjem se moze uocitigdje su performanse baze podataka zadovoljavajuce ili suprotno gdje perfor-manse nisu zadovoljavajuce. Ako performase nisu zadovoljavajuce potrebnoje modificirati bazu podataka. Takoder moze postojati potreba za promje-nama baze podataka ako se zahtjevi nad bazom podataka promijene ili ako sepovecaju ocekivanja krajnjih korisnika za boljim perforamasama. Slijedom na-vedenog vidljivo je da se zivotni ciklus baze podataka nastavlja nadgledanjem,odrzavanjem i promjenama.


Dio II

Logicko dizajniranje baze podataka

14

3 ER modeliranje

3.1 Modeliranje podatakaKao sto je prikazano u zivotnom ciklusu baze, da bi modelirali stvarni svijet te iznjega napravili bazu podataka potrebno je modelirati entitete i veza izmedu enti-teta (engl. Entity Relationship Modelling). Razvijeni konceptualni model dalje sepretvara u relacijski ili neki drugi model (Slika 3.1). Objekti i njihovih medusobniodnosi modeliraju se entitetima, atributima i vezama izmedu entiteta.

Slika 3.1: Modeliranje podataka

Entitet (engl. Entity) je skup objekata iz stvarnog svijeta koji imaju naglasenazajednicka svojstva. Svaki entitet ima svojstva koja ga opisuju i nazivaju se atri-butima. Entitet je definiran kao skup E = {e1, e2, e3, e4, . . . , en}, gdje su e1, . . . , en

elementi entiteta (Slika 3.2).

Slika 3.2: Prikaz entiteta kao skupa

Primjerice u bazi podataka WebShop (koristenoj na laboratorijskim vjezbama,

15

POGLAVLJE 3. ER MODELIRANJE

[2]) za opis osobe koja kupuje proizvod koristi se entitet Kupac, tj. skup svih kupacakoji imaju neka zajednicka svojstva, tj. atribute:ime, prezime, email, telefon i gradiz kojeg dolaze. Pojedini kupac predstavlja jedan element skupa svih kupaca, tj.element entiteta Kupac.

Prije prikaza entiteta kao skupa objekata potrebno je utvrditi sljedece:

Selekciju atributa - utvrduje se koji atributi opisuju entitet iz naseg kuta gledanja.Primjerice opis entiteta Automobil nece biti jednak ako entitet promatra dizaj-ner automobila i automehanicar. Automehanicaru ce biti zanimljivi atributipoput obujma i snage motora za opis entiteta, dok bi dizajneru automobilabili zanimljivi atributi poput boje i oblika limarije i stakla.

Integritet atributa - predstavlja postavljena ogranicenja i pravila vezana za poje-dini atribut. Integritetom atributa osigurava se suvislost vrijednosti atributa.Primjerice atribut DatumRodenja neke osobe ne moze biti nakon danasnjegdatuma, tj. niti jedna osoba ne moze imati vrijednost atributa datum rodenja01.01.2020. ako je danasnji datum 01.01.2016.

Kardinalitet atributa - je podatak o zastupljenosti atributa. Kardinalitetom seodreduje obveznost unosa vrijednosti atributa. Pri utvrdivanju kardinalitetaodreduje se donja (minimalni kardinalitet) i gornja granica (maksimalni kar-dinalitet):

card(A,E) = (mincard(A,E),max card(A,E)) (3.1)pri cemu je A atribut, E entitet, mincard(A,E) minimalni kardinalitet atri-buta A u entitetu E, a max card(A,E) maksimalni kardinalitet atributa A uentitetu E. Ako je unos vrijednosti atributa obvezan, donja granica kardinali-teta poprima vrijednost mincard(A,E) = 1, a ako nije obvezan donja granicakardinaliteta je mincard(A,E) = 0. Primjerice atribut Ime u entitetu Kupacje obvezan za unos mincard(Ime,Kupac) = 1 jer svaki kupac zasigurno imaime tj. ne postoji osoba koja nema ime. Istovremeno svaki kupac ima samojedno ime pa je max card(Ime,Kupac) = 1. Prema tome kardinalitet atributaIme je card(Ime,Kupac) = (1,1). S druge strane atribut Telefon je opciona-lan za unos te je mincard(Telefon,Kupac) = 0, odnosno postoje kupci kojinemaju telefon, te ga nije potrebno unijeti.

Svaki entitet je u vezi sa entitetima iz svog okruzenja, pa kazemo da je veza nestosto povezuje dva ili vise entiteta. Veze se mogu podjeliti na jednostavne i slozene.Najcesce vrste veza opisane su u sljedecim poglavljima.

3.1.1 Jednostavne vezeJednostavne veze su binarne veze tj. veze izmedu dva entiteta. Razlikuju se tri vrstebinarnih veza: 1 : 1, 1 : N i M : N .



Veza 1:1

Svaki element skupa R moze biti povezan samo sa jednim ili nijednim elementomskupa S, Slika 3.3. Isto vrijedi za elemente skupa S.

Slika 3.3: Prikaz veze jedan prema jedan (1:1)

Veza 1:N

Svaki element skupa R moze biti povezan sa jednim ili vise elemenata skupa S, doksvaki element skupa S moze biti povezan sa samo jednim elementom skupa R, Slika3.4.

Slika 3.4: Prikaz veze jedan prema vise (1:N)

Veza M:N

Svaki element skupa R moze biti povezan sa jednim ili vise elemenata skupa S. Istovrijedi za elemente skupa S, Slika 3.5.



Slika 3.5: Prikaz veze vise prema vise (M : N)

3.1.2 Slozene vezeKod opisivanja stvarnih sustava pojavljuju se slozenije veze od prethodno navedenih.U nastavku slijedi opis nekih od njih.

Involvuirana veza

Involvuirana veza povezuje neki entitet sa samim sobom. Dakle, rijec je o binarnojvezi (1:1, 1:N i M:N) izmedu entiteta istog tipa, Slika 3.6.

Slika 3.6: Prikaz involuiranih veza

Podtip veze

Tip entiteta E1 je podtip tipa entiteta E2 ako je svaki primjerak od E1 takoder iprimjerak od E2. Dakle E1 nasljeduje sve atribute od E2 te moze imati dodatneatribute. Ovakva situacija opisuje se vezom 1:1. Na Slici 3.7 prikazana je podtipveza izmedu Studenta, Profesora i Knjiznjicara. Entitet Osoba sadrzi sve zajednickeatribute spomenutih entiteta, a svaki pojedinacni entitet sadrzi i neke svoje dodatne.Primjerice entitet Profesor ima dodatni atribut Titula, dok entitet Student imadodatni atribut JMBG.



Slika 3.7: Podtip veza

Ternarna veza

Ternarna veza je ona veza koja u sebi sadrzi tri razlicita tipa entiteta. Uvodi sekada vezu nije moguce rastaviti na binarne veze. Ternarna veza moze biti N:M:P,1:N:M, 1:1:M ili 1:1:1. Primjer ternarne veze prikazan je na Slici 3.8. Za vezu naSlici moze se reci da je M:N:P, jer primjerice za zadani par (Student, Predmet)postoji vise studenata koji upisuju isti predmet, a isto tako jedan student upisujevise predmeta.

Slika 3.8: Ternarna veza



3.2 ER modeliranjeProces oblikovanja baze podataka iz korisnickih zahtjeva nije formalno definiran tezahtjeva kretivnost i individualno se razlikuje od osobe do osobe. Za oblikovanjebaze podataka izraduje se model entiteta i veza (Entity-Relationship Modelling - ERmodeliranje). U bazama podataka koristi se kada proces iz stvarnog svijeta trebapretvoriti u konceptualni model koji se dalje transformira; u ovom slucaju relacijskimodel. Konceptualno oblikovanje baze podataka ER modeliranjem za rezultat ima:

• Dijagram entiteta - prikazuje samo entitete sa atributima,

• ER dijagram - prikazuje odnose entiteta bez atributa.

Na Slici 3.9 su prikazani simboli koji se koriste kod ER modeliranja. Simboli ERdiagrama predstavljaju sljedece likovi:

• Pravokutnik - predstavlja entitet;

• Romb - predstavlja vezu izmedu entiteta;

• Elipsa - predstavlja atribut koji opisuje entitet;

• Dvostruki pravokutnik - predstavlja slabi entitet koji ovisi o postojanju drugogentiteta;

• Dvostruki romb - predstavlja involuiranu vezu tj. vezu entiteta sa samimsobom. Ova veza moze se oznaciti i obicnom elipsom;

• Dvostruka elipsa - oznacava visevrijednosni atribut. Obicno se ER dijagramizraduje na nacin da se visevrijednosni atribut pretvori u novi entitet te je uodnosu na entitet od kojeg je nastao u relaciji 1:N ili N:M.

Slika 3.9: Simboli u ER dijagramu

Visevrijednosni atributi su atributi koja mogu poprimiti vise vrijednosti za po-jedini atribut entiteta, odnosno gornja granica kardinaliteta porpima vrijednostmax card(A,E) = N . Modeliraju se na dva nacina prikazana na Slici 3.10. A nacinprikazuje modeliranje entiteta Student s vise vrijednosnim atributom Sport, od-nosno jedan student moze se baviti s vise ili nijednim sportom te mu je kardinalitet



card(Sport,Studnet) = (0,N) te se oznacava dvostrukom elipsom u dijagramu enti-teta. B nacin prikazuje modeliranje dva entiteta Student i Sport koji su medusobnopovezani M:N vezom, buduci da se jedan student moze baviti s vise sportova, a is-tovremeno se jednim sportom moze baviti vise studenata. Zbog jednostavnosti kodkasnije transformacije u relacijski model, u nastavku ce se koristiti B nacin.

Slika 3.10: Modeliranje visevrijednosnih atributa

Primjer slabog entiteta je relacija izmedu entiteta Racuna i entiteta Stavka prika-zana Slikom 3.11. Entitet Stavka je slab entitet jer stavka racuna ne postoji ukolikone postoji racun u kojem se stavka nalazi, buduci da se svaki racun sastoji od nizastavaka npr. mlijeko, kruh, pecivo itd.

Slika 3.11: Primjer slabog entiteta

3.2.1 Dijagram entitetaDijagram entiteta prikazuje entitete i njihove atribute. Kod izrade dijagrama enti-teta uvodi se identifikacijski atribut te kardinalitet atributa. Kardinalitet atributaje broj koji opisuje koliko vrijednosti pojedini atribut moze poprimiti za opis jednogelementa entiteta. Identifikacijski atribut (identifikator) je atribut koji jedinstvenoodreduje svaki element entiteta. U dijagramu entiteta prikazuje se s elipsom kojojje naziv podcrtan, primjerice Id.

Slika 3.12: Dijagram entiteta



Na Slici 3.12 dijagramom entiteta prikazan je entitet Student koji sadrzi atribute:Id, Ime, Prezime, JMBAG, Email i DatumRodenja. Atribut Id je identifikacijskiatribut. Naziv identifikacijskog atributa se podcrtava te se tako naglasi da je atri-but identifikacijski. Na liniji koja povezuje entitet i atribute upisuje se kardinalitetatributa, tj. donja i gornja granica kardinaliteta primjerice. Kardinalitet atributaIme u entitetu Student kazuje koliko imena moze imati svaki student. Dakle kardi-nalitet kod atributa Ime (1,1) znaci da svaki student ima najmanje jedno ime cimese utvrduje donja granica, te najvise jedno ime cime se odreduje gornja granica.

3.2.2 ER dijagramER dijagram prikazuje samo veze medu entitetima koji su odredeni u koraku izradedijagrama entiteta. Veze se oznacavaju rombovima izmedu entiteta koji sudjeluju uvezi. Na poveznicu izmedu entiteta i veza upisuje se tip veze (1:1, 1:N, N:M). Osimveza nekad je potrebno prikazati i atribute koji opisuju neku vezu, a obicno je toveza N:M.

Na Slici 3.13 prikazan je primjer ER dijagrama koji opisuje veze izmedu osobe,grada u kojoj osoba zivi te drzave kojoj grad pripada. Iz ER dijagrama se jednos-tavno ocita da se u jednoj drzavi nalazi vise gradova, dok jedan grad pripada tocnojednoj drzavi. Zatim da svaka osoba zivi u tocno jednom gradu, dok u jednomgradu moze zivjeti vise osoba. Iako nema direktne veze izmedu entiteta osoba idrzava operacijama teorije skupova preko entiteta grad lako se dobiva informacija ukojoj drzavi zivi koja osoba, te da jedna osoba zivi u tocno jednoj drzavi.

Slika 3.13: Primjer ER dijagrama

3.2.3 Primjer ER modeliranja: ITS laboratorijPojednostavljeni korisnicki zahtjev za bazu ITSLaboratorij su sljedeci: ITS labo-ratorij zeli unaprijediti vodenje evidencije o korisnicima (Ime, Prezime, Email iBrojTelefona) i posudbama laboratorijske opreme. Do sada su se posudbe pisale nakarticama gdje su se s prednje strane upisivali podaci o korisniku, a na poledini kar-tice informacije o posudbama kao sto je datum posudbe i vracanja te sifra posudeneopreme. ITS laboratorij bi htio sastaviti popis opreme koji bi se sastojao od nazivaopreme, sifre, opisa cemu sluzi oprema i uputa kako se koristi. Oprema je podije-ljena na kategorije primjerice softver i hardver. Od evidencije prati se tko je kadazaduzio koji dio opreme, kada je vracen i da li je vracen u ispravnom stanju.



Prvi korak je prepoznati logicke cijeline (entitete) koje imaju zajednicke karak-teristike (Slika 3.14). Dakle entiteti i atributi izdvojeni iz prethodno navedenihkorisnickih zahtjeva su:

• Korisnik: Id, Ime, Prezime, Email, BrojTelefon

• Oprema: Id, Naziv, Sifra, Opis, Upute

• Kategorija: Id, Naziv

Slika 3.14: Dijagram entiteta ITS laboratorija

Kardinalitet svih atributa prikazanih na Slici 3.14 je (1,1), sto znaci da su sviatributi obavezni za unos, te poprimaju maksimalno jednu vrijednost. Id je atributkoji je indentifikator u svakom entitetu te je on “umjetan” odnosno SUBP se kasnijebrine oko njegove jedinstvenosti.

Veze izmedu entiteta su:

• Korisnik je Posudio Opremu

• Oprema Pripada Kategoriji

ER dijagram prikazan je Slikom 3.15. Veza Posudba izmedu entiteta Korisnik iOprema je M:N jer jedan korisnik moze posuditi vise opreme, dok istu opremu mozekoristiti vise razlicitih korisnika. Entiteti Kategorija i Oprema su u vezi nazvanojJe tipa 1:N jer jednoj kategoriji moze pripadati vise opreme, dok oprema pripada usamo jednu kategoriju. U ER dijagramu istice se veza Posudba jer ima dodatne atri-bute. To je cest slucaj kada se radi o vezi M:N te se tada atributi prikazuju u ER di-jagramu. Kardinalitet atributa DatumPosudbe je card(DatumPosudbe,Posudba) =(1,1) jer uvijek kada se unese nova posudba tocno se zna kojeg je datuma onda bila,te ne postoji jos neki drugi datum te posudbe. Atributi DatumVracanja i JeIspravansu kardinaliteta (0,1) sto znaci da ih u trenutku posudbe nije potrebno unijeti, aliu trenutku kada ce se unositi mogu poprimiti samo jednu vrijednost. Nazivi vezaizmedu entiteta su proizvoljni, ali najcesce se nazivaju prema radnji koja se vrsiizmedu entiteta.



Slika 3.15: ER Dijagram ITS laboratorija

U trenutku zavrsetka formaliziranja dijela stvarnog svijeta dijagramom entitetai ER dijagramom potrebno je stvoreni konceptualni model pretvoriti u relacijskimodel. Kod pretvaranja ER dijagrama u relacijski model koriste se transformacijskapravila.


4 Relacijski model

Kod opisivanja relacijskog modela mogu se koristiti razliciti termini. U Tablici4.1 prikazani su matematicki nazivi elemenata relacijskog modela te odgovarajucitradicionalni nazivi relacijskog modela koji se nadalje koriste u tekstu.

Tablica 4.1: Terminologija relacijskog modela baza podataka

Matematici naziv Tradicionalni nazivRelacija TablicaN-torka Redak ili redAtribut Stupac ili kolonaVrijednost atributa Pojedinacni podatakVeza Veza ili relacija

4.1 Osnove relacijske algebreOsnove relacijske algebre u bazama podataka uveo je E. F. Codd u istrazivanjimaprovedenim 70-ih godina. Relacijska algebra podrazumijeva definirane operacijenad entitetima (tablicama) i podacima koji im pripadaju. Za pocetak je potrebnodefinirati sto su to kompatibilne tablice. One sadrze atribute jednakog naziva i istibroj atributa (imaju jednak broj stupaca i svi stupci su istog naziva), te su atributiistog naziva definirani su nad jednakim domenama.

4.1.1 Teorija skupovaOperacije iz teorije skupova koje se najcesce primjenjuju nad tablicama su: unija(T:= R ⋃ S), presjek (T:=R ⋂ S), razlika (T:=R − S) i produkt (T:=R × S).

Unija (T:= R ⋃ S)

U bazama podataka operacija unije moze se provoditi samo nad kompatibilnimtablicama. Po matematickoj teoriji unija dvaju skupova R i S je skup T koji sesastoji od svih elemenata koji pripadaju i skupu R i skupu S. Primijenjeno na tablice,tablica T je unija tablica R i S, koja ima isto zaglavlje (stupce) kao i tablice R i S,a sadrzi sve retke koji se nalaze u obje tablice. Unija ima sljedece osobine:

• zakon komutacije: R ⋃ S = S ⋃ R,

• asocijativnost: R ⋃ (S ⋃ C) = (R ⋃ S) ⋃ C,

• neutralni element: R ⋃ ∅ = R ,

• idempotentnost: R ⋃ R = R.

Slika 4.1 prikazuje primjer unije tablica T:= R ⋃ S. Tablice R i S dijele istenazive atributa, odnosno kompatibilne su, te imaju dva zajednicka retka: b i c.

25

POGLAVLJE 4. RELACIJSKI MODEL

Rezultat unije T:= R ⋃ S je tablica T koja ima retke obaju tablica R i S, s time dase zajednicki redci pojavljuju samo jedanput.

Slika 4.1: Primjer unije tablica T:= R ⋃ S

R S T============= ============= =============| A | B | C | | A | B | C | | A | B | C |============= ============= =============| a | 1 | 1 | | b | 2 | 2 | | a | 1 | 1 || b | 2 | 2 | | c | 3 | 3 | | b | 2 | 2 || c | 3 | 3 | | d | 4 | 4 | | c | 3 | 3 |

| d | 4 | 4 |

Presjek (T:=R ⋂ S)

Operacija presjeka takoder se moze provoditi samo nad kompatibilnim tablicama.Po matematickoj teoriji presjek dvaju skupova R i S je skup T koji se sastoji od svihelemenata koji pripadaju i skupu R i skupu S. Primijenjeno na tablice, tablica T jepresjek tablica R i S, koja imaju isto zaglavlje (stupce) kao i tablice R i S, a sadrzisve retke koji su zajednicki tablicama R i S. Presjek ima sljedece osobine:

• zakon komutacije: R ⋂ S = S ⋂ R,

• asocijativnost: R ⋂ (S ⋂ C) = (R ⋂ S) ⋂ C,

• neutralni element: R ⋂∅ = R te

• idempotentnost: R ⋂ R = R.

Slika 4.2 prikazuje primjer presjeka tablica T:=R ⋂ S. Tablice R i S dijele istenazive atributa, odnosno kompatibilne su, te imaju dva zajednicka retka: b i c.Upravo ta dva retka su rezultat presjeka T:=R ⋂ S.

Slika 4.2: Primjer presjeka tablica T:=R ⋂ S

R S T============= ============= =============| A | B | C | | A | B | C | | A | B | C |============= ============= =============| a | 1 | 1 | | b | 2 | 2 | | b | 2 | 2 || b | 2 | 2 | | c | 3 | 3 | | c | 3 | 3 || c | 3 | 3 | | d | 4 | 4 |

Razlika (T:=R - S)

Operacija razlike moze se provoditi samo nad kompatibilnim tablicama. Po ma-tematickoj teoriji razlika dvaju skupova R i S je skup T koji se sastoji od svihelemenata koji pripadaju skupu R i ne pripadaju skupu S. Primijenjeno na tablice,tablica T je razlika tablica R i S, koja ima isto zaglavlje (stupce) kao i tablice R i



S, a sadrzi sve retke koji se nalaze u R, a ne nalaze se u S.

Slika 4.3 prikazuje primjer razlike tablica T:=R - S. Tablice su kompatibilne jerdijele iste nazive stupaca. Potrebno je odrediti koji su redci zajednicki tablicama Ri S, te je rezultat razlike tablica T:=R - S koja sadrzi sve retke tablice R koji nisuzajednicki tablici S, odnosno samo redak a.

Slika 4.3: Primjer razlike tablica T:=R - S

R S T============= ============= =============| A | B | C | | A | B | C | | A | B | C |============= ============= =============| a | 1 | 1 | | b | 2 | 2 | | a | 1 | 1 || b | 2 | 2 | | c | 3 | 3 || c | 3 | 3 | | d | 4 | 4 |

Produkt (T:=R × S)

Operacija produkta nad entitetima (tablicama), temelji se na skupovnoj opera-ciji Kartezijevog produkta te ne zahtjeva da tablice budu kompatibilne. Po ma-tematickoj teoriji Kartezijev produkt dvaju skupova R i S je skup T koji se sastojiod uredenih parova, pri cemu je prvi element uredenog para iz skupa R, a drugi izskupa S. Primijenjeno na tablice, tablica T je produkt tablica R i S, cije je zaglavljedefinirano: zaglavlje(R × S) = zaglavlje(R) ⋃ zaglavlje(S), a redci te tablice nas-taju spajanjem redaka iz tablica R i S. Svaki o redaka iz tablice R spoji se sa svimredcima tablice S.

Slika 4.4 prikazuje Primjer produkta tablica T:=R × S. Svaki od redaka tabliceR spoji se sa svim recima tablice S. Tako se redak a spaja sa svim redcima d, e i ftablice S itd.

Slika 4.4: Primjer produkta tablica T:=R × S

R S T============= ============= =========================| A | B | C | | D | E | F | | A | B | C | D | E | F |============= ============= =========================| a | 1 | 1 | | d | 4 | 4 | | a | 1 | 1 | d | 4 | 4 || b | 2 | 2 | | e | 5 | 5 | | a | 1 | 1 | e | 5 | 5 || c | 3 | 3 | | f | 6 | 6 | | a | 1 | 1 | f | 6 | 6 |

| b | 2 | 2 | d | 4 | 4 || b | 2 | 2 | e | 5 | 5 || b | 2 | 2 | f | 6 | 6 || c | 3 | 3 | d | 4 | 4 || c | 3 | 3 | e | 5 | 5 || c | 3 | 3 | f | 6 | 6 |

4.1.2 Prirodne relacijske operacijePrirodnim relacijskim operacijama pripadaju: projekcija (T:= R [a]), selekcija (T:=Rgdje je a=12), spajanja (ima ih nekoliko vrsta) i dijeljenje (T:=R ÷ S)



Projekcija (T:= R [a])

Operacijom projekcije tablice nad atributima izdvajaju se atributi tablice na kojimase vrsi projekcija. Projekcija tablice R nad atributima A, B, C jest tablica T sazaglavljem(T) = A, B, C koja sadrzi sve redove koji su sadrzani u tablici R. Rezultatprojekcije je nova tablica koja predstavlja vertikalni podskup zadane tablice.

Slika 4.5: T:= R [a]

| x | | | x | | |=========================| x | | | x | | |=========================| x | | | x | | |=========================

R T:=R[A]============= ======| A | B | C | | A |============= ======| a | 1 | 1 | | d || b | 2 | 2 | | e || c | 3 | 3 | | f |

Dakle operacijom projekcije nastaje nova tablica koja sadrzi isti broj redova kaoi tablica R, ali samo one atribute (stupce) po kojima se vrsi projekcija.

Selekcija (T:=R gdje je a=12)

Operacijom selekcije nad zadanom tablicom R izdvaja se skup redova koji zadovo-ljavaju uvjet po kojem se selekcija vrsi. Rezultat operacije selekcije je tablica kojasadrzi sve atribute izvorne tablice, ali samo one redove koji zadovoljavaju trazeniuvjet. Dobivena tablica predstavlja horizontalni podskup izvorne tablice.

Slika 4.6: T:=R gdje je a=12

| x | x | x | x | x | x |=========================| | | | | | |=========================| x | x | x | x | x | x |=========================

R T:= where A=c============= =============| A | B | C | | A | B | C |============= =============| a | 1 | 1 | | c | 3 | 3 || b | 2 | 2 || c | 3 | 3 |

Spajanja

Kod operacije spajanja (join) razlikuje se nekoliko podvrsta. Podvrste operacijespajanja navedene su u nastavku.



Unutrasnje spajanje - Inner join (T:=RBCS)

Inner join operacijom povezuju se tablice na nacin da se spajaju redovi tablica poistim vrijednostima zajednickog atributa, tj. spajaju se redovi koji u stupcima istognaziva u obje tablice imaju istu vrijednost.

Slika 4.7: T:=RBCS

R S T============= ============= =====================| A | B | D | | D | E | F | | A | B | D | E | F |============= ============= =====================| a | 1 | 1 | | 2 | 2 | 2 | | b | 2 | 2 | 2 | 2 || b | 2 | 2 | | 3 | 3 | 3 | | c | 3 | 3 | 3 | 3 || c | 3 | 3 | | 4 | 4 | 4 |

U navedenom primjeru tablice R i S imaju zajednicki atribut D, te se spajanjeodvija po tom atributu. Prvi red tablice R ima vrijednost atributa D = 1, te nesudjeluje u vezi, jer u tablici S ne postoji red sa D = 1. Drugi i treci red tablice Rimaju vrijednost D = 2 i D = 3, te se spajaju sa prvim i drugim redom u tablici S.

Lijeva vanjska veza - Left outer join (T:=RBCLOS)

Lijeva vanjska veza je prosirenje unutrasnje veze. Osnova za realizaciju lijeve vanjskeveze je unutrasnja veza, kojoj se dodaju elementi tablice koji ne sudjeluju u vezi.Tablica ciji se elementi dodaju je ona koja je u relacijskom izrazu sa lijeve strane.

Slika 4.8: T:=RBCLOS

R S T============= ============= =======================| A | B | D | | D | E | F | | A | B | D | E | F |============= ============= =======================| a | 1 | 1 | | 2 | 2 | 2 | | a | 1 | 1 | n u l l | n u l l || b | 2 | 2 | | 3 | 3 | 3 | | b | 2 | 2 | 2 | 2 || c | 3 | 3 | | 4 | 4 | 4 | | c | 3 | 3 | 3 | 3 |

U prethodnom primjeru objasnjeno je nastajanje tablice RBCS. U stvaranjuRBCLOS najprije se realizira RBCS (time se dobiju drugi i treci redak). Potomse dodaju svi redci tablice R, koji ne sudjeluju u unutrasnjoj vezi. U ovom slucajujedini redak u tablici R koji nije obuhvacen unutrasnjom vezom je prvi redak. Buducida on ne sudjeluje u unutrasnjoj vezi atributi E i F su null vrijednosti.

Desna vanjska veza - Right outer join (T:=RBCROS)

Desna vanjska veza je prosirenje unutrasnje veze. Osnova za realizaciju desne vanj-ske veze je unutrasnja veza, kojoj se dodaju oni elementi tablice koji ne sudjeluju uunutrasnjoj vezi. Tablica ciji se elementi dodaju je ona koja je u relacijskom izrazu



sa desne strane.

Na primjeru sa slike 4.9 objasnjeno je nastajanje tablice RBCS. U stvaranjuRBCROS najprije se realizira RBCS (time se dobiju prva dva reda tablice T). Potomse dodaju svi redovi tablice S, koji ne sudjeluju u unutrasnjoj vezi. U ovom slucajujedini red u tablici S koji nije obuhvacen unutrasnjom vezom je treci red (D = 4).Buduci da on ne sudjeluje u unutrasnjoj vezi atributi A i B su null vrijednosti.

Slika 4.9: T:=RBCROS

R S T============= ============= =======================| A | B | D | | D | E | F | | A | B | D | E | F |============= ============= =======================| a | 1 | 1 | | 2 | 2 | 2 | | b | 2 | 2 | 2 | 2 || b | 2 | 2 | | 3 | 3 | 3 | | c | 3 | 3 | 3 | 3 || c | 3 | 3 | | 4 | 4 | 4 | | n u l l | n u l l | 4 | 4 | 4 |

Vanjska veza - Outer join (T:=RBCOS)

Vanjska veza je prosirenje unutrasnje veze. Osnova za realizaciju lijeve vanjskeveze je unutrasnja veza, kojoj se dodaju elementi obje tablice koji ne sudjeluju uunutrasnjoj vezi. Na ovaj nacin vrijedi da je T:=RBCOS = RBCLOS ⋃ RBCROS.Primjer vanjske veze prikazan je na Slici 4.10.

Slika 4.10: T:=RBCOS

R S T============= ============= ==========================| A | B | D | | D | E | F | | A | B | D | E | F |============= ============= ==========================| a | 1 | 1 | | 2 | 2 | 2 | | a | 1 | 1 | n u l l | n u l l || b | 2 | 2 | | 3 | 3 | 3 | | b | 2 | 2 | 2 | 2 || c | 3 | 3 | | 4 | 4 | 4 | | c | 3 | 3 | 3 | 3 |

| n u l l | n u l l | 4 | 4 | 4 |

Dijeljenje (T:=R ÷ S)

Tablica T koja se dobije dijeljenjem R i S je najveca tablica za koju vrijedi da se sviredovi produkta T x S nalaze u tablici R. Primjer dijeljenja skupova prikazan je naSlici 4.11.

Slika 4.11: T:=R ÷ S

R S T:=R % S============= ========= =====| A | B | D | | A | B | | D |============= ========= =====| s | 1 | 4 | | s | 1 | | 4 || s | 1 | 5 | | 5 || c | 2 | 5 |



Prioritet operatora je redom: (1) projekcija, (2) selekcija, (3) produkt, (4) spa-janje,dijeljenje, (5) razlika, (6) unije, presjek

4.1.3 Logicke operacijeLogicke operacije cesto se primijenjuju u relacijskoj algebri, posebno kod primjeneoperacije selekcije tj. postavljanja slozenih uvjeta za selekciju pojedinih redova iztablice. Logicki operatori su AND, OR i NOT. Operatori AND i OR su funkcijekoje se primijenjuju nad dva argumenta, a funkcija NOT nad jednim argumentom.

Slika 4.12: Logicke operacije

============== ============== ==========| AND | | OR | | NOT |============== ============== ==========| T | T | | T | | T | T | | T | | F | | T || F | T | | F | | T | T | | F | | T | | F || F | F | | T | | T | F | | T || F | F | | T | | F | F | | F |

4.2 Ocuvanje integriteta podatakaIntegritetom podataka osigurava se njihova suvislost i dosljednost uporabe poda-taka. Na ovaj nacin podaci odgovaraju tocno zadanim pravilima i formatima bazepodataka. Kako bi bilo moguce da baza podataka zaista preslikava sliku realnog svi-jeta potrebno je postaviti ogranicenja na moguce pojavljivanje vrijednosti atributa(raspon) kao i na njihovo medusobno povezivanje.

4.2.1 Domena podatakaDomena podataka predstavlja skup vrijednosti koje odredeni atribut moze poprimiti.Pojedinacna vrijednost atributa se smatra najmanjom nedjeljivom semantickom je-dinicom podataka. Za svaki atribut definira se domena i predstavlja podatke kojipripadaju istom tipu podataka. Mijesanje vise tipova podataka unutar jedne do-mene nije dopusteno.

Osim toga za atribute su obicno definirana dodatna ogranicenja primjerice en-titet (tablica) Racun i njegov atribut DatumIzdavanja daju nam informaciju kadaje racun izdan. Pretpostavka je da atribut treba biti tipa datetime no pitanje jeosigurava li se time realnost podataka, tj. ako je trenutno datum 2016−01−01, a uatribut je unesena vrijednost 2017−11−11 zaljucuje se da je unesena vrijednost po-gresna. Dakle nije dovoljno definirati format podataka vec treba definirati dodatnaogranicenja koja opisuju specificnost atributa. U ovom slucaju uneseni datum nesmije biti veci od trenutnog.



4.2.2 Referencijalni integritetReferencijalni integritet osigurava logicnu vezu i pravila odnosa medu podacimau tablicama koje su relacijski povezane. U tablici ne moze postojati vrijednoststranog kljuca za koju ne postoji ista vrijednost primarnog kljuca u osnovnoj tablici.Referencijalni integritet definira pravila unosa, brisanja i mijenjanja (azuriranja)podataka sa ciljem osiguravanja konzistentnost podataka u bazi. Dizajner bazepodataka definira ponasanje baze prilikom promjena podataka u tablicama. Bazapodataka moze imati dvije vrste ponasanja prilikom promjene podataka:

• Trazena akcija se odbija i u bazi se na dogadaju nikakve promjene.

• Akcija se dopusta, ali se uz nju pokrecu dodatne akcije koje imaju svrhu us-postaviti konzistentnost baze podataka

Na Slici 4.13 je prikazan primjer ocuvanja referencijalnog integriteta u tablicamaGrad i Drzava. Tablice Drzava i Grad su u relaciji 1:N koja je ostvarena stranimkljucem u tablici Grad (DrzavaID).

Slika 4.13: Primjer ocuvanja referecijalnog integriteta

Grad========================================| IDGrad (PK) | Naziv | DrzavaID (FK) |========================================| 1 | Zagreb | 1 || 2 | O s i j e k | 1 || . . . | . . . | . . . || 13 | D e r v e n t a | 3 |

Drzava======================================| IDDrzava (PK) | Naziv |======================================| 1 | H r v a t s k a || 2 | Njemacka || 3 | Bosna i Hercegov ina |

Unos podataka

Zabranjen je unos podatka u tablicu, sa nekom vrijednost stranog kljuca, ako u os-novnoj tablici ne postoji ista vrijednost primarnog kljuca (Restricted). Na primjerusa slike 4.13 to bi znacilo da nije dopusten unos novog grada u tablicu Grad kojembi vrijednost DrzavaIDbila neka koja ne postoji u tablici Drzava.

Brisanje podataka

Kako bi se ocuvao referencijalni integritet kod brisanja podataka postoje tri nacinakoja se odreduju tijekom dizajniranja baze podataka. Svi nacini biti ce objasnjenipomocu primjera sa slike 4.13.

• Ograniceno (engl. Restricted) - brisanje redka dozvoljeno je samo ako se nje-gova vrijednost primarnog kljuca ne pojavljuje u povezanoj tablici kao strani



kljuc. Primjerice u tablici Drzava nije dopusteno brisanje drzava Hrvatska, jeru tablici Grad postoji strani kljuc drzave koji je pridruzen gradovima Zagrebi Osijek.

• Kaskadno (engl. Cascade) brisanje - brisanje podatka u tablici uzrokuje bri-sanje svih podataka u povezanoj tablici gdje vrijednost obrisanog primarnogkljuca pojavljuje kao strani kljuc. Ako obrisemo drzavu Hrvatska iz tabliceDrzava svi gradovi kojima je DrzavaID = 1 ce se obrisati (Zagreb, Osijek itd.).

• Nuliranje (engl. Nullifies) – brisanje podatka iz primarne tablice uzrokujepostavljanje vrijednosti stranog kljuca u povezanim tablicama na NULL vri-jednost, zatim se iz primarne tablice brise podatak sa odredenom vrijednostiprimarnog kljuca. Na primjeru drzave Hrvatska u tablici Drzava bi znaciloda brisanjem Hrvatske, strani kljuc gradova Zagreb i Osijek poprimio bi vri-jednost NULL, a nakon toga bi Hrvatska bila izbrisana iz tablice Drzava. Uovom primjeru lose je izgubiti podatak o pripadnosti grada nekoj drzavi, alipostoji niz situacija kada je ovaj nacin brisanja potreban.

Azuriranje podataka

Kod azuriranja podataka postoje tri nacina ocuvanja referencijalnog integriteta.

• Ograniceno (engl. Restricted) - azuriranje vrijednosti primarnog kljuca do-zvoljeno je samo ako se ta vrijednost ne pojavljuje u drugoj tablici kao stranikljuc.

• Kaskadno (engl. Cascade) - azuriranje vrijednosti primarnog kljuca izazivaazuriranje svih podataka u drugoj tablici gdje se ta vrijednost primarnog kljucapojavljuje kao strani kljuc.

• Nuliranje (engl. Nullifies) – azuriranjem odredene vrijednosti primarnog kljuca,najprije se sve iste vrijednosti stranog kljuca postavljaju na NULL vrijednost,zatim se u osnovnoj tablici mijenja vrijednost primarnog kljuca.

Gotovo nikada ne dolazi situacije da se azurira primarni kljuc.


5 Normalizacija

Normalizacija podataka unutar baze podataka mogla bi se definirati kao teznja kaefikasnoj organizaciji podataka. Glavni su ciljevi smanjenje redundancije podatakai njihova bolja relacijska organizacija. Smanjenje redundancije kolicine podatakapodrazumijeva izbjegavanje ponavljanja podataka (primjer je ponavljanje istih po-dataka unutar iste tablice). Drugi cilj podrazumijeva organiziranje podataka u ta-blice na nacin koji slijedi logiku meduovisnosti podataka. Postizanjem tih ciljeva ukonacnici dolazi do redukcije zauzeca prostora u spremistu za podatke i bolje logickeorganizacije podataka unutar baze.

U domeni relacijskih baza podataka normalizacija se moze opisati i kao sis-tematski pristup dizajniranju baze za koju je tada jednostavno kreirati generickeupite (engl. queries). Na taj se nacin uklanjanju neke od nezeljenih pojava kao stosu razne anomalije dodavanja, brisanja i azuriranja podataka.

Koncept normalizacije podataka uveo je Edgar F. Codd koji je ujedno i autor sa-mog relacijskog modela podataka. Codd uvodi pojam ”Prve normalne forme” (1NF)1970., a 1971. konceptu normalizacije dodaje drugu normalnu formu (2NF) i trecunormalnu formu (3NF). Zajedno s Raymondom F. Boyceom uvodi pojam Boyce-Coddove normalne forme (BCNF). Drugi teoreticari kasnije su uveli vise normalneforme, a posljednja definirana forma jest sesta normalna forma (6NF).

5.1 Prva normalna formaPrva normalna forma (1NF) naziva se i minimalnom formom. Da bi neka relacijskabaza podataka zadovoljila prvu normalnu formu, mora zadovoljiti minimalni setkriterija koji to omogucuju. Rijec je konkretno o sljedecim uvjetima: tablica moravjerno reprezentirati relacije te ne smije sadrzavati ponavljajuce grupe podataka.Problem nastaje zbog razlicitog tumacenja ponavljajucih grupa, zbog cega ne postojijedinstveni konsenzus o karakteristikama tablice zbog kojih ona eventualno ne mozepripadati kategoriji prve normalne forme. 1NF se u literaturi cesto definira upravokroz ova dva cilja:

• Relacije (tablice) ne smiju imati ponavljajuci grupe podataka

• Svaki redak mora imati jedinstveni identifikator (primarni kljuc) koji ga je-dinstveno odreduje

Opisu gore navedenih ciljeva pridodat cemo i uvjete iz Dateove definicije. PremaDateovoj definiciji normalne forme, tablica pripada prvoj normalnoj formi samo akozadovoljava sljedece uvjete:

1. nepostojanje uvjetovanja poretka redaka po osi od vrha prema dnu za uspos-tavu relacije

2. nepostojanje uvjetovanja poretka kolona po osi lijevo-desno za uspostavu re-lacija

34

POGLAVLJE 5. NORMALIZACIJA

3. nema dupliciranih redaka (svaka n-torka mora biti jedinstvena); to upucujena postojanje primarnoga kljuca koji se sastoji od jednog (ili vise atributa)

4. svaki redak u presjeku osi retka i kolone sadrzi tocno jednu vrijednost iz pri-mjenjive domene i nijednu vise , tj. sadrzaj polja ne smije biti NULL, a poljene moze imati vise od jedne vrijednosti

5. svi su stupci regularni – sto znaci da nemaju skrivene atribute kao sto suidentifikator retka, objekta ili vremenska oznaka retka.

Ako tablica ne zadovoljava bilo koji od ovih uvjeta, iskljucena je iz prve normalneforme. U nastavku slijede neki primjeri koji ne zadovoljavaju prvu normalnu formu.

5.1.1 Primarni kljucNa Slici 5.1 prikazana je tablica bez primarnog kljuca koja omogucuje pojavu du-pliciranih podataka u redcima. Time se izravno krsi 3. uvjet. U tablici Zaposlenicinalaze se stupci Ime, Prezime i RadnoMjesto bez primarnog kljuca. Dakle, sasvimje moguce da se pojave dvije osobe s istim imenom, prezimenom te radnim mjestom.Primjerice dva se puta pojavljuje Pero Peric koji radi na radnom mjestu razvojnoginzenjera, ali u zbilji se radi o dvije razlicite osobe. Moze se zakljuciti da tablicaZaposlenici ne zadovoljava 1NF jer dopusta ponavljanje podataka.

Slika 5.1: Primjer tablice bez primarnog kljuca

Z a p o s l e n i c i=========================================| Ime | Prez ime | RadnoMjesto |=========================================| Pero | P e r i c | R a z v o j n i i n z e n j e r || E u f r a t a | T i g r i s | K o n z u l t a n t || Pero | P e r i c | R a z v o j n i i n z e n j e r || I v a | P i v i c | PR Manager |=========================================

Kako bi tablica Zaposlenici bila u 1NF u tablicu se dodaje novi atribut MBG kojije definiran kao primarni kljuc tablice (Slika 5.2). Time se osigurava jedinstvenostsvakog retka, tj. svake n-torke.

Slika 5.2: Primjer tablice sa primarnim kljucem

Z a p o s l e n i c i=========================================================| MBG | Ime | Prez ime | RadnoMjesto |=========================================================| 0101008 xxxxxx | Pero | P e r i c | R a z v o j n i i n z e n j e r || 0101008 xxxxxx | E u f r a t a | T i g r i s | K o n z u l t a n t || 0101008 xxxxxx | Pero | P e r i c | R a z v o j n i i n z e n j e r || 0101008 xxxxxx | I v a | P i v i c | PR Manager |=========================================================



5.1.2 Ovisnost relacije o poretkuAko pregled podataka zahtijeva njihov prikaz na nacin da se podaci vracaju premanekom odredenom redu radi intrinzicnosti i smislenosti takvog pregleda – 1NF jenarusena. To konkretno znaci da je narusen 1. uvjet: N-torke podataka u pravimrelacijama ne smiju nikako biti uvjetovane poretkom jednih podataka u odnosu nadruge. Kao primjer mogu posluziti dvije tablice podataka, pri cemu tablica Zapos-lenici sadrzi popis zaposlenika, a tablica AdreseZaposlenika sadrzi podatke o adre-sama zaposlenika. Relacija je pritom uspostavljena iskljucivo poretkom podatakapo redoslijedu unosa odnosno poretkom po polju VrijemeUnosa. Ako se poredakuspostavlja po nekom drugom kriteriju, gubi se relacijska poveznica izmedu redakau jednoj i drugoj tablici.

5.1.3 Null atributiPrimjer tablice koja nije u 1NF jest tablica s barem jednim atributom koji mozebiti NULL. Postojanje atributa koji smije imati null kao vrijednost narusava pra-vilo broj 4 koje zahtijeva da tablica u nekom polju ima tocno jednu vrijednost izdefinirane domene. To se pravilo kosi s kasnijom definicijom Coddovog relacijskogmodela koji dozvoljava postojanje atributa koji mogu imati vrijednost NULL.

5.1.4 Ponavljajuce grupeTreci je uvjet zabrana postojanja grupa podataka, a to je ujedno i jedan od minimal-nih pretpostavljenih uvjeta za zadovoljavanje kriterija 1NF. Na Slici 5.3 prikazan jeprimjer krsenja 3. uvjeta normalne forme: tablicu kontakata za zaposlenike.

Slika 5.3: Primjer tablice sa grupama podataka

K o n t a k t i Z a p o s l e n i k a=========================================| Id | Ime | Prez ime | T e l e f o n B r o j |=========================================| 101 | F r a n j o | Tahi | +3850123001 || 120 | M a t i j a | Gubec | +3850123002 || 211 | Zdravko | P e r i c | +3850123003 |=========================================

Ako se ukaze potreba za dodavanjem vise brojeva telefona po kontaktu, pojavitce se problem s postojecim modelom. Jedno od mogucih rjesenja je dodavanje visetelefonskih brojeva u polje za telefon (Slika 5.4). Pretpostavimo li da je domena zapolje TelefonBroj definirana tako da podrazumijeva tekst ogranicen na duzinu od 15znakova, to rjesenje ne zadovoljava 1NF jer se zabranjuje postojanje vise telefonskihbrojeva u istom polju, odnosno postojanje dvije vrijednosti u jednom polju.



Slika 5.4: Primjer tablice sa visevrijednosnim atributom

K o n t a k t i Z a p o s l e n i k a====================================================| Id | Ime | Prez ime | T e l e f o n B r o j |====================================================| 101 | F r a n j o | Tahi | +3850123001 || 120 | M a t i j a | Gubec | +3850123002 || 211 | Zdravko | P e r i c | +3850123003 +385124002 |====================================================

5.1.5 Ponavljanje grupa stupacaJedno od mogucih rjesenja bilo bi dodavanje vise stupaca za telefonske brojeve. NaSlici 5.5 prikazan je takav model tablice. Prvi je problem u ovom modelu postojanjestupaca s dozvoljenom vrijednoscu NULL, sto nije u skladu s Dateovom definicijomprve normalne forme koja to nacelno zabranjuje. Slijedimo li kasnije Coddovu vizijui dozvolimo postojanje polja NULL vrijednoscu, dolazimo do druge zapreke, a to jeda polja za telefonske brojeve TelefonBroj1, TelefonBroj2, TelefonBroj3 dijele istudomenu i znacenje. Navedeni pristup stvara dodatne poteskoce prilikom stvaranjaupita za dohvat podataka na tako dizajniranim tablicama. Javljaju se problemi veckod stvaranja osnovnih upita. Primjerice za dohvat iz tablice KontaktiZaposlenikaprema telefonskom broju ili uspostavi jedinstvene relacije Kontakt→ TelefonskiBroj.Takoder postoji i ogranicenje ukupnog broja telefonskih brojeva po kontaktu na tri.Postavlja se pitanje sto ako ih je potrebno vise i koje ce sve to probleme donijeti(prosirenje sheme, promjena upita itd.).

Slika 5.5: Primjer tablice sa ponavljajucom grupom stupaca

K o n t a k t i Z a p o s l e n i k a========================================================================| Id | Ime | Prez ime | T e l e f o n B r o j 1 | T e l e f o n B r o j 2 | T e l e f o n B r o j 3 |========================================================================| 101 | F r a n j o | Tahi | +3850123001 | NULL | NULL || 120 | M a t i j a | Gubec | +3850123002 | NULL | NULL || 211 | Zdravko | P e r i c | +3850123003 | +385124002 | +385124003 |========================================================================

Ponavljanje grupa unutar stupca

Moguce je, iako za realne potrebe neprakticno, stvoriti tablicu uz izmjenu stupcaTelefonskiBroj tako da se u njega moze pohraniti vise telefonskih brojeva.

Rjesenje prikazano na Slici 5.6 slicno je prethodno navedenom. Iako je formalnozadovoljen kriterij 1NF, to definitivno nije prakticno rjesenje i trebalo bi ga izbjega-vati. Jedno od pitanja koja se namecu je ono o semantickom znacenju samog atributaTelefonBroj, buduci da on moze sadrzavati jednu instancu telefonskog broja, kolek-ciju telefonskih brojeva ili nesto trece. Ako su podaci strukturirani na ovaj nacin,stvaranje upita je komplicirano jer se pojavljuje problem postavljanja ogranicenja(constraints) nad podacima u takvoj tablici na stvarnim RDBM sustavima.



Slika 5.6: Primjer tablice sa ponavljajucom grupom unutar stupaca

K o n t a k t i Z a p o s l e n i k a=====================================================| Id | Ime | Prez ime | T e l e f o n B r o j |=====================================================| 101 | F r a n j o | Tahi | +3850123001 || 120 | M a t i j a | Gubec | +3850123002 || 211 | Zdravko | P e r i c | +3850123003 , +385124002 |=====================================================

Princip nedjeljivosti (atomicnosti) podataka

U nekim se definicijama 1NF, npr. u Coddovoj, spominje koncept atomicnosti (ne-djeljivosti) podataka. Rijec je o tome da vrijednosti unutar neke domene nad kojimasu definirane relacije moraju biti atomicne s obzirom na RDBM sustav u kojem senalaze. Dakle, svaki bi podatak koji se nalazi u nekom polju (sjeciste osi retka ikolone) trebao biti nedjeljiv, tj. njegova daljnja dekompozicija ne bi trebala bitimoguca.

Koncept nedjeljivosti nije jednoznacan buduci da je tesko ostvariv, pogotovo ukontekstu modernog RDBM sustava. No svi danasnji RDBM sustavi daju mogucnostdekompozicije podataka kroz razne funkcionalnosti te na taj nacin omogucuju de-kompoziciju svakog podatka na manje elemente. Tipican je primjer tekstualna vri-jednost (engl. string) koja se sastoji od niza manjih elemenata, znakova. RDBMSobicno nudi funkcionalnosti za manipulaciju s nizovima znakova (engl. string functi-ons) sto omogucuje dekompoziciju i narusavanje koncepta nedjeljivosti. Isto vrijediza funkcionalnosti za rad s datumima koje omogucavaju dohvacanje pojedinih ele-menata datuma.

Buduci da je jednoznacni koncept nedjeljivosti tesko ostvariv, govori se vise oatomicnosti podataka ovisno o kontekstu i samim podacima. Stoga ovaj uvjet trebapromatrati uvjetno ovisno o kontekstu i samim podacima.

Dizajn u skladu s 1NF

Tablica KontaktiZaposlenika iz prethodnih primjera prikazana je na Slici 5.7 u 1NF.Kako bi tablica bila u 1NF potrebno je kreirati dvije tablice.

Slika 5.7: Primjer tablice u 1NF

K o n t a k t i Z a p o s l e n i k a T e l e f o n s k i B r o j e v i Z a p o s l e n i k a=========================== ======================================| Id | Ime | Prez ime | | K o n t a k t Z a p o s l e n i k a I d | T e l e f o n B r o j |=========================== ======================================| 101 | F r a n j o | Tahi | | 101 | +385123001 || 120 | M a t i j a | Gubec | | 120 | +385124002 || 211 | Zdravko | P e r i c | | 211 | +385125003 |=========================== | 211 | +385124002 |

======================================

Prva tablica sadrzi popis kontakata zaposlenika sa atributima Id koji je primarnikljuc, Ime i Prezime. Druga tablica pod nazivom TelefonskiBrojevi sadrzi atribute



KontaktZaposlenikaId i TelefonBroj. KontaktZaposlenikaId pokazuje na Id u ta-blici KontaktiZaposlenika i uspostavlja relaciju izmedu entiteta. Svaki zaposlenikna ovaj nacin moze imati vise telefonskih brojeva. Nakon promjene dizajna tablicazadovoljava 1NF.

5.2 Druga normalna formaDrugu normalnu formu (u daljnjem tekstu 2NF) 1971. definirao je E.F.Codd. Da bitablica bila u 2NF mora najprije zadovoljiti 1NF.

Neka tablica je u 2 NF ako i samo ako svi atributi ovise o cijelom primarnomkljucu, a ne samo o nekom njegovom dijelu. Dakle, tablica koja zadovoljava 1NFmoze se smatrati da je i u 2NF samo ako ne sadrzi niti jedan neprimarni atributkoji nije funkcijski ovisan o primarnom kljucu. Pod pojmom neprimarnih atributapodrazumijevaju se oni atributi koji nisu dio primarnog kljuca. 1NF nema slozeneprimarne kljuceve, a kako se slozeni primarni kljuc sastoji od dva ili vise atributa,tada se takva tablica automatski kvalificira kao 2NF.

Posljedica toga jest razdvajanje podataka koji se odnose na vise stupaca u za-sebne tablice. Uz to se uvode relacije izmedu novih tablica i vec postojecih stoimplicira uvodenje stranog kljuca.

5.2.1 Tablica izvan 2NFU Tablici na Slici 5.8 nijedan atribut nije dobar kandidat za primarni kljuc. Prvi jeproblem ponavljanje atributa Djelatnik ukoliko jedan djelatnik ima vise certifikataili ponavljanje atributa Certifikat ukoliko vise djelatnika ima isti certifikat. Stoga seu ovom slucaju kao kandidat namece slozeni kljuc Djelatnik, Certifikat. Buduci daatribut RadnoMjesto ovisi samo o dijelu kompozitnog kljuca, o atributu Djelatnik,tablica nije u 2NF. Osim toga, potencijalno se mogu stvoriti redundantni podaci ustupcu RadnoMjesto. Primjerice radno mjesto Matije Gubeca u tablici je dvaputnavedeno. Takav pristup moze uzrokovati probleme zbog nekonzistentnog azuriranjapodataka, tj. ako djelatnik Matija Gubec prijede na drugo radno mjesto, mozda senece azurirati svi njegovi dotadasnji zapisi te se mogu pojaviti dvojica Matije Gupca(dva radnika s istim imenom i prezimenom koji rade na razlicitim radnim mjestima).

Slika 5.8: Primjer tablice izvan 2NF

D j e l a t n i k a I C e r t i f i k a t i========================================================| D j e l a t n i k | C e r t i f i k a t | RadnoMjesto |========================================================| F r a n j o Tahi | CCNA | S i s t e m s k i i n z i n j e r || M a t i j a Gubec | SCJD | V i s i r a z v o j n i i n z i n j e r || M a t i j a Gubec | MCSD | V i s i r a z v o j n i i n z i n j e r || Zdravko Loza | MCPD | R a z v o j n i i n z i n j e r || Mila P i l a n o v i c | CCNA | S i s t e m s k i i n z i n j e r || Mila P i l a n o v i c | CEH | S i s t e m s k i i n z i n j e r |========================================================



5.2.2 Normalizacija do 2NFJedna od ispravnih varijanti 2NF bila bi da se tablica podijeli na dvije tablice: Dje-latnici i DjelatnikoviCertfikati sa kandidatima za primarne kljuceve redom {Djelatnik}za Djelatnici i {Djelatnik, Certifikati} za tablicu DjelatnikoviCertifikati. Nakon ovepodjele se nece pojavljivati nekonzistencija nakon azuriranja podataka.


D j e l a t n i c i===========================================| D j e l a t n i k | RadnoMjesto |===========================================| F r a n j o Tahi | S i s t e m s k i i n z i n j e r || M a t i j a Gubec | V i s i r a z v o j n i i n z i n j e r || Zdravko Loza | R a z v o j n i i n z i n j e r || Mila P i l a n o v i c | S i s t e m s k i i n z i n j e r |===========================================

D j e l a t n i k o v i C e r t i f i k a t i===============================| D j e l a t n i k | C e r t i f i k a t |===============================| F r a n j o Tahi | CCNA || M a t i j a Gubec | SCJD || M a t i j a Gubec | MCSD || Zdravko Loza | MCPD || Mila P i l a n o v i c | CCNA || Mila P i l a n o v i c | CEH |===============================

5.2.3 AnomalijeIako je tablica u 2NF, to ne znaci da je ona imuna na anomalije nastale zbogazuriranja, brisanja i dodavanja podataka (redaka unutar tablica). U primjeru naSlici 5.10 prikazana je tablica koja sadrzi popis godisnjih revizija tvrtki zajedno spodacima o revizorima.

Slika 5.10: Primjer tablice podlozne anomalijama azuriranja, brisanja i dodavanjapodataka

G o d i s n j e R e v i z i j e==========================================================| T r v t k a | Godina | R e v i z o r i | RevizorMBG |==========================================================| Firma d . o . o . | 2010 | Ostap P e r i c | 0710960 xxxxxx || Kompanija d . d . | 2010 | Zdravko Dren | 1709975 xxxxxx || Firma d . o . o . | 2011 | Ostap P e r i c | 0710960 xxxxxx || Firma d . o . o . | 2011 | M a t i j a Gubec | 2709965 xxxxxx || Obr t d . o . o . | 2011 | Zdravko Dren | 1709975 xxxxxx |==========================================================



U prikazanoj se tablici nalazi popis revizora (Revizor, RevizorMBG) i godisnjihrevizija (polje Godina) za tvrtke (polje Tvrtka). Kandidat za kljuc je {Tvrtka, Go-dina}. Iako su polja Revizori i RevizorMBG odredena navedenim kljucem, ona nisudio kljuca. Takoder se ponavljaju podaci o revizoru u obliku Revizor – Revizor-MBG sto je potencijalni uzrok anomalija azuriranja podataka. Primjerice, za istogrevizora mogu se pojaviti dva ili vise MBG-a kao posljedica pogresno provedenogazuriranja. Navedeno je posljedica tranzitivne ovisnosti polja RevizorMBG o poljuRevizor koje pak ovisi o kljucu {Tvrtka, Godina}. No 2NF je ovime zadovoljena, aproblem tranzitivne ovisnosti rjesava se 3NF.

5.2.4 Kandidatski kljuceviTablice kod kojih nema djelomicnih ovisnosti o primarnom kljucu obicno su, no neuvijek, u 2NF. Osim primarnog kljuca, neka tablica moze lako sadrzavati vise kan-didatskih kljuceva. Stoga se provjerava ovisi li ijedan neprimarni atribut djelomicnoo bilo kojem kandidatskom kljucu. U tablici, Slika 5.11, s dva kandidatska kljuca,{MBG} i {PunoIme, Grad}, MBG odabran je kao primarni. Tablica nije u 2NF jerDrzava ovisi o atributu Grad (dijelu kandidatskog kljuca).

Slika 5.11: Kandidatski kljucevi

Z a p o s l e n i c i=========================================================================| PunoIme | MBG | Drzava | Grad |=========================================================================| Ostap P e r i c | 0710960 xxxxxx | H r v a t s k a | Dubrovnik || Zdravko Dren | 1709975 xxxxxx | S l o v e n i j a | C e l j e || Simo Tamovic | 0710960 xxxxxx | Makedoni ja | Vardar || M a t i j a Gubec | 2709965 xxxxxx | H r v a t s k a | Donja s t u b i c a || Magnar Z u l u f i c | 1002973 xxxxxx | Bosna i Hercegov ina | J a j c e || Mila P i l a n o v i c | 1711950 xxxxxx | S l o v e n i j a | Maribor |=========================================================================

Da bi zadovoljili 2NF, tablicu dijelimo u dvije tablice: Zaposlenici i DrzaveGradova,Slika 5.12.

Slika 5.12: Kandidatski kljucevi nakon 2NF

DrzaveGradova========================================| Drzava | Grad |========================================| H r v a t s k a | Dubrovnik || S l o v e n i j a | C e l j e || Makedoni ja | Vardar || H r v a t s k a | Donja s t u b i c a || Bosna i Hercegov ina | J a j c e || S l o v e n i j a | Maribor |========================================



Z a p o s l e n i c i==================================================| PunoIme | MBG ( pk ) | Grad |==================================================| Ostap P e r i c | 0710960 xxxxxx | Dubrovnik || Zdravko Dren | 1709975 xxxxxx | C e l j e || Simo Tamovic | 0710960 xxxxxx | Vardar || M a t i j a Gubec | 2709965 xxxxxx | Donja s t u b i c a || Magnar Z u l u f i c | 1002973 xxxxxx | J a j c e || Mila P i l a n o v i c | 1711950 xxxxxx | Maribor |==================================================

5.3 Treca normalna formaTreca normalna forma (u daljnjem tekstu 3NF) sljedeci je korak normalizacije ta-blica. 3NF takoder je definirao E.F.Codd 1971. Da bi neka tablica bila u 3NF, moraispuniti sljedece uvjete:

1. Tablica mora biti u 2NF (kumulativna ovisnost o prethodnoj)

2. Svaki neprimarni atribut relacije R izravno je ovisan (odnosno nije tranzitivnoovisan) o svim dijelovima primarnog kljuca na relaciji R (neprimarni atributisu medusobno nezavisni). Neprimarni atribut relacije R onaj je atribut kojine pripada ni jednom kandidatu za kljuc.

Tranzitivna ovisnost je funkcionalna ovisnost: X → Z (X indirektno odredujeZ), sa svojstvom ovisnosti X → Z tako da je X → Y i Y → Z (vrijedi i obrnutoX → Y ).

Definicija Carlu Zaniola (1982.) ekvivalentna je Coddovoj, no drukcije izrazena.U njoj se navodi da je relacija u 3NF ako i samo ako svaka funkcionalna ovisnostX → A zadovoljava kriterije:

• X sadrzi A (X → A je trivijalna funkcijska ovisnost) ili

• X je superkljuc ili

• A je primarni atribut (tj. A je sadrzan u kandidatu za kljuc)

Na primjeru Zaniolove definicije lako je uociti razliku izmedu 3NF i Boyce-Coddove normalne forme (BNCF). U slucaju BNCF-e eliminira se zadnja mogucnostda je A primarni atribut sto BCNF cini strozom naspram 3NF. Definicija 3NF vodiracuna o tome da su neprimarni atributi relacije (tablice) ovisni o kljucevima. Pri-marni atributi, koji su dijelovi kljuceva ili su sami kljucevi, ne smiju biti funkcijskiovisni. Svaki predstavlja cinjenicu o kljucu ili dijelu kljuca.

Tablica na Slici 5.10 spomenuta je vec kao primjer tablice koja je u 2NF uzanomalije azuriranja no nije u 3NF. Moguci je kljuc {Tvrtka, Grad} koji jamcijedinstvenost retka u tablici, tj. jedna godisnja revizija po jednoj tvrtci u jednojgodini. Za svaku reviziju, tj. redak, postoji podatak o revizoru koji je proveoreviziju. Dakle u opisanoj tablici je neprimarni atribut MBG tranzitivno ovisano primarnom kljucu Tvrtka, Grad preko neprimarnog atributa Revizor te je timenarusena 3NF.



5.3.1 Normalizacija do 3NFKako bi tablica sa Slike 5.10 bila u 3NF potrebno je ukloniti tranzitivnu ovis-nost atributa RevizorMBG o neprimarnom atributu Revizor. Pri rjesavanju pro-blema ne smije se zanemariti trenutni primarni kljuc {Tvrtka, Godina} te ovisnosti:Revizor→{Tvrtka, Godina} i RevizorMBG→{Tvrtka, Godina}.

Tablica je u 3NF ako se postojeca tablica podijeli na dvije tablice od kojih cesvaka tablica sadrzavati direktno ovisne atribute o primarnom kljucu, Slika 5.13. Iztablice GodisnjeRevizije uklonjen je atribut RevizorMBG koji je tranzitivno ovisioo primarnom kljucu. Kreirana je nova tablica MBGoviRevizora koja je relacijskipovezana sa tablicom GodisnjeRevizije. Time je sprijeceno narusavanje integritetapodataka kao posljedice anomalije azuriranja.


G o d i s n j e R e v i z i j e==========================================| T v r t k a | Godina | R e v i z o r |==========================================| Firma d . o . o . | 2010 | Ostap P e r i c || Kompanija d . d . | 2010 | Zdravko Dren || Firma d . o . o . | 2011 | Ostap P e r i c || Firma d . o . o . | 2011 | M a t i j a Gubec || Obr t d . o . o . | 2011 | Zdravko Dren |==========================================

5.4 Daljnja normalizacijaU vecem broju slucajeva dovodenjem baze podataka do 3NF rjesava se problemaanomalija azuriranja, umetanja i brisanja. Stovise, nerijetko je slucaj da su tabliceblizu zadovoljenja kriterija za BCNF-u, 4NF ili cak 5NF nakon dovodenja u 3NF.

Normalizacija podataka do razine 3NF prilikom dizajniranja baza podataka sma-tra se obaveznom. Sam koncept 3NF i sistematicna primjena normalizacije prilikomdizajna dobra su pretpostavka uspjesnog dizajna baze.

1NF logicki organizira podatke, uklanja ponavljanje redaka i svakom retku dajejedinstvenost uvodeci koncept primarnoga kljuca. 2NF uklanja skupine podataka,koje se odnose na vise redaka u nekoj tablici, u posebne tablice. Pri tome se stvarajurelacije izmedu novih tablica i primarne tablice. 3NF zavrsava proces uklanjajuci sveneprimarne atribute koji su tranzitivno ovisni o nekom kandidatu za kljuc. Na tajnacin stvaraju se nove tablice i vecim djelom uklanjaju se anomalije azuriranja, ume-tanja i brisanja podataka. Sve navedeno je osnova za organiziranu bazu podatakate ukoliko je potrebno daljnju normalizaciju.

Ponekad se u realnim slucajevima javlja potreba za suprotnim postupkom tzv.denormalizacijom. Denormalizacija se primjenjuje u specificnim slucajevima kadase baza podataka podesava za vece brzine dohvata podataka ili kada se podacipripremaju za OLAP sustave. Zbog prednosti koje nastaju kao posljedica norma-lizacija ne smije se normalizaciju smatrati iskljucivo akademskom disciplinom veckao esencijalni dio svakog dizajna.


Dio III

Strukturirani jezik upita

44

6 Uvod u SQL

Pojavom novog koncepta za spremanje podataka u relacijama javila se potreba i zajezikom koji ce podatke analizirati. Godine 1974. IBM Research Laboratory objavioje clanak pod nazivom SEQUEL (od engl. Struciured English Query Language)dvojice autora Donald D. Chamberlin i Raymond F. Boyce. Cilj objave clanka je bilopriblizavanje relacijskih baza podataka korisnicima. Iz tog razloga jezik SEQUEL jeprirodan i jednostavan za koristenje. Kratica SEQUEL je bila zastitni znak HawkerSiddeley zrakoplovne tvrtke iz Ujedinjenog Kraljevstva koja je zahtijevala da se toime ne koristi. Tako je kratica promijenjena u SQL (od engl. Structured QueryLanguage) za jezik kojim se definira logicka struktura i manipulira s podacima urelacijskim bazama podataka i danas. SQL se moze kategorizirati kao jezik za:

Manipulaciju podacima - DML ( od engl. Data Manipulation Language) naredbevrse manipulaciju podacima. Primjeri DML naredbi su: SELECT, UPDATE,INSERT.

Definiciju strukture - DDL (od engl. Data Definition Language) je tip naredbi kojedefiniraju strukturu objekata u bazi podataka u koju ce se kasnije sprematipodaci. Primjeri DDL naredbi su: CREATE, ALTER, DROP.

Dodjelu prava - DCL (od engl. Data Control Language) naredbe se koriste za kre-iranje uloga i dodjelu prava na objekte ili na naredbe kao sto su procedure ubazi podataka. Primjeri DCL naredbi su: GRANT, REVOKE.

Upravljanje transakcijama TCL (eng. Transactional Control Language) naredbese koriste za upravljanje transakcijama. Primjeri TCL naredbi su: BEGINTRANSACTION, ROLLBACK TRANSACTION, COMMIT TRANSACTION,SAVE TRANSACTION.

6.1 SQL standardCilj standardizacije jezika baza podataka je da omoguci prenosivost definicija bazapodataka i aplikativnih programa medu implementacijama (MS SQL, MySQL, Pos-tgres, Oracle, itd.) koje su suglasne sa standardom. U stvarnosti su implementacijepoprilicno slicne.

6.1.1 SQL89 (SQL1)Od 1986. godine, kada je prvi put standardiziran prema americkom standardu ANSI-ju (od engl. American National Standard Institute) i medunarodnom standarduISO (od engl. International Standard Organization), jezik baza podataka SQL je uneprestanom razvoju od strane veceg broja organizacija za standardizaciju. Sljedecapuna verzija standarda objavljena je 1992. godine. Puni naziv ovog standarda je”International Standard Database Language SQL”, poznat i pod nazivima SQL2,SQL-92.

45

POGLAVLJE 6. UVOD U SQL

6.1.2 SQL92 (SQL2)SQL2 u odnosu na prethodni standard ukljucuje jezik za manipulaciju shemom,tablicu za informacije o shemi, bolje kreiranje dinamickih upita, nove tipove po-dataka i domenu. Osim ovog uvodi se kaskadno azuriranje i brisanje podataka,algebra skupova nad tablicama, razlicite nivoe konzistentnosti, kursore, temporalnetablice, bolju dijagnostiku i izvjestavanje o pogreskama. SQL2 je mnogo dinamicnijii fleksibilniji, u odnosu na prethodni standard, zbog smanjenja ogranicenja.

6.1.3 SQL99 (SQL3)SQL3 predstavlja sljedeci korak u razvoju SQL standarda. Definiranje ovog stan-darda pocelo je gotovo istovremeno sa objavom SQL2. Novi standard je razvijenpod vodstvom ANSI i ISO organizacija.

6.2 Tipovi podatakaTip podatka odreduje koju vrstu podatka odredeni atribut moze sadrzavati. MSServer je ISO kompatibilan po tipovima podataka. Osim predefiniranih tipova po-dataka mogu se koristiti i korisnicki definirani tipovi podataka. O predefiniranim ikorisnickim definiranim tipovima podataka vise u iduca dva poglavlja.

6.2.1 Predefinirani tipovi podatakaPredefinirane tipove podataka moze se podijeliti u nekoliko kategorija: egzaktni iaproksimirani brojevi, vremenski i datumski, znakovni, binarni i dr. U tablicama6.1, 6.2,6.3,6.4,6.5 i 6.6 je dan pregled svih predefiniranih tipova podataka po kate-gorijama, njihove raspon vrijednosti i zauzece memorije.

Tablica 6.1: Egzaktni brojevi

Podatkovni tip Raspon vrijednosti Zauzece memorijebigint od -9 223 372 036 854 775 808

do 9 223 372 036 854 775 8078 bajta

int od -2 147 483 648do 2 147 483 647

4 bajta

smallint od -32 768 do 32 767 2 bajtatinyint od 0 do 255 1 bajtadecimal[(p[,s])],numeric[(p[,s])]

od 1038 + 1 do 1038 - 1 5 bajta =¿ p = 1-99 bajta =¿ p = 10-1913 bajta =¿ p = 20-2817 bajta =¿ p = 29-38

money od -922 337 203 685 477.5808do 922 337 203 685 477.5807

8 bajta

smallmoney od -214 748.3648do 214 748.3647

4 bajta



Egzaktni brojevi su oni koji se mogu zapisati u racunalu tocno onakvi kakvijesu. U tablici 6.1 p vrijednost predstavlja maksimalan broj spremljenih znamenki.U obzir se uzimaju znamenke s lijeve i desne strane decimalnog zareza. Vrijednostp mora biti u rasponu od 1 do 38, a predefinirana vrijednost je 18. Vrijednost s iztablice 6.1 predstavlja maksimalan broj znamenki sa desne strane decimalnog zarezate moze biti u intervalu [0− p]. Predefinirana vrijednost je 0.

Tablica 6.2: Aproksimirani brojevi

Podatovni tip Raspon vrijednosti Zauzece memorijefloat od -1,79*10308 do 1,79*10308 4 bajta =¿ n = 1-24

8 bajta =¿ n = 25-53real od -3,40*10308 do 3,40*10308 4 bajta

Aproksimirani brojevi (tablica 6.2) su brojevi kojima spremamo priblizno prika-zive vrijednosti. Kod float tipa podataka n je broj bitova potrebnih da se spremitextcolorredmantisa te o njemu ovisi duzina memorije koja ce se potrositi za spre-manje ovog tipa podatka. Ako je n specificiran njegova vrijednost mora biti izmedu1 i 53. Predefinirana vrijednost je 53 sto znaci da se za pohranjivanje trosi 8 bajtamemorije.

Tablica 6.3: Datum i vrijeme

Podatovni tip Raspon vrijednosti Zauzece memorijedate od 1. Sijecnja, 1

do 31. Prosinca, 99993 bajta

datetime od 1. Sijecnja, 1753,do 31. Prosinca, 9999

8 bajta

datetime2 od 1. Sijecnja, 1,do 31. Prosinca, 9999

8 bajta

time od 00:00:00.0000000do 23:59:59.9999999

5 bajta

smalldatetime od 1. Sijecnja, 1900do 6. lipnja, 2079

4 bajta

Tablica 6.4: Znakovi

Podatovni tip Napomena Zauzece memorijechar[(n)] n oznacava duljinu fiksne

velicine ne-Unicode znakova imoze biti u rasponu od 1 do 8000

n bajta

varchar[(n—max)] n oznacava duljinu varijabilnevelicine ne-Unicode znakova imoze biti u rasponu od 1 do 8000, a max omogucava sprema-nje do 2GB podataka

n + 2 bajta



Tablica 6.4: Znakovi

Podatovni tip Napomena Zauzece memorijetext varijabilna duzina ne-Unicode

znakova i moze biti maksi-malno do 2 147 483 647 zna-kova

n bajta

nchar[(n)] n oznacava duljinu fiksnevelicine Unicode znakova imoze biti u rasponu od 1 do 8000

n * 2 bajta

nvarchar[(n—max)] n oznacava duljinu varijabilnevelicine Unicode znakova imoze biti u rasponu od 1 do8 000, a max omogucava spre-manje do 2GB podataka

n * 2 + 2 bajta

ntext varijabilna duzina Unicodeznakova i moze biti mak-simalno do 1 073 741 823znakova

n * 2 bajta

Znakovni tipovi podataka prikazani u Tablici 6.4 mogu se podijeliti prema nacinukodiranja koji koriste. Svi tipovi koji pocinju sa slovom n predstavljaju Unicode ko-diranje. Unicode kodiranje za zapis jednog znaka koristi 2 bajta i podrzava hrvatskaslova. Ostali tipovi koriste ASCII kodiranje. ASCII ima mogucnost spremanja samo128 razlicitih znakova te za spremanje pojedinog znaka koristi samo 1 bajt. Osimnavedene razlike znakovni tipovi se dijele na one varijabilne i fiksne velicine. Podat-kovni tipovi varchar, nvarchar su varijabilni dok su ostali fiksne velicine. Fiksnimtipovima unaprijed se odreduje duzina i oni uvijek zauzimaju jednaku kolicinu me-morijskog prostora. Primjerice za tip podatka nvarchar ukoliko se definira duzinaod 10 znakova, nvarchar[10], postavljeno je ogranicenje te se u varijablu sa opisa-nim tipom podatka ne moze spremiti podatak koji sadrzi vise od 10 znakova. Uslucaju spremanja znakovnih zapisa manjih od 10 primjerice ’Pero’, ’Ana’ popunitice se samo prva tri znaka, a ostalih sedam ce se popuniti prazninama ’ ’. Prednostvarijabilnih tipova je sto se trosi samo onoliko memorije kolika je velicina sprem-ljenog podatka. Nedostatak varijabilnih tipova je sporija obrada upita kod velikihbaza podataka. Maksimalan broj znakova koji se moze spremiti u znakovni tip po-datka ovisi o kodiranju. Primjerice kod ASCII koda maksimalan broj znakova je8000, a Unicode 4000. Kod spremanja znakovnih nizova vecih od maksimalnog brojaznakova DBMS ih automatski sprema u BLOB-ove.

Tablica 6.5: Binarni

Podatovni tip Napomena Zauzece memo-rije



Tablica 6.5: Binarni


binary[(n)] Fiksna duzina binarnih poda-taka, gdje je n duzina bajta zaspremiti i moze biti u rasponu od1 do 8 000.

n bajta

varbinary[(n—max)] Varijabilna duzina binarnih po-dataka, gdje je n duzina bajtaza spremiti i moze biti u rasponuod 1 do 8 000, a max omogucavaspremanje do 2GB podataka.

n + 2 bajta

image Varijabilna duzina binarnih po-dataka do 2 147 483 647 bajta.

Binarni podatkovni tipovi sluze za spremanje slika, filmova, dokumenata itd.Ostalim tipovima podataka prikazanim tablicom 6.6.

Tablica 6.6: Ostali tipovi


cursor Koristi se za varijable ili za izlazneparametre uskladistenih procedurakoji sadrze referencu na kursor.

timestamp Tip podatka koji automatski gene-rira jedinstvene binarne brojeve unu-tar baze podataka.

8 bajta

hierarchyid Ovaj tip podatka se koristi kako bise pokazala pozicija podatka u hije-rarhijskoj strukturi.

uniqueidentifier Globalni jedinstveni indetifikatorkoji se jos naziva GUID.

2 Bytes

sql variant Tip podatka u koji se mogu po-hraniti rezliciti tipovi podataka kojeSQL server podrzava.

xml Tip podatka u koji se spremajuXML podaci.

table Ovaj tip podatka koristi se zaprivremeno spremanje rezulti-rajuceg skupa za kasnije koristenje.Najcesce se u njega sprema rezultattablicnih funkcija.

Osim navedenih tipova podataka u bazama podataka koristi se vrijednost NULLcije prisustvo signalizira da pridruzenom atributu nije poznata vrijednost. Za prikazatributa bez dodijeljene vrijednosti ne koristi se broj 0 iz vise razloga. Primjerice bi



se u tom slucaju raspoznalo da prava vrijednost atributa nije 0? U to slucaju to nebi bilo moguce iz tog razloga problem je rijesen zamjenom praznih polja NULL vri-jednoscu. Dakle NULL vrijednost se moze postaviti umjesto bilo kojeg tipa podatkai koristi se kada ne znamo neki podatak ili se podatak naknadno unosi.

6.2.2 Korisnicki definirani tipovi podatakaOsim predefiniranih tipova podataka MS Server omogucava kreiranje vlastitih tipovapodataka. Korisnicki definirane tipove podataka se moze podjeliti u tri kategorije:

• korisnicki definirani podatkovni tipovi (engl. User Defined Data Types)

• korisnicki definirani tablicni tipovi (engl. User Defined Table Types)

• korisnicki definirani tipovi (engl. User Defined Types)

Svaki korisnicki definiran tip podatka za neku bazu moze se pronaci pod Naziv baze− > Programmabolity − > Types − > User Defined Data Types — User DefinedTable Types — User Defined Types. Za detaljne informacije o svakom tipu podatakakoristi se sistemska procedura ”sp help”. Osim za ispis detaljnih informacija o sva-kom tipu podataka navedena procedura se moze koristiti za generiranje informacijao objektima vezanim za bazu podataka.

Slika 6.1: Informacije o korisnicki definiranom tipu podatka

1 EXEC sp_help ’dbo.Jmbag’2 ========== ============== ======= ======= ==========3 Type_name Storage_type Length Prec Scale4 ========== ============== ======= ======= ==========5 Jmbag char 11 11 NULL6

7 ========== ============== =========== ==============8 Nullable Default_name Rule_name Collation9 ========== ============== =========== ==============

10 no none none Croatian_CI_AS

Korisnicki definirani podatkovni tipovi

U ANSI standardnoj terminologiji ovi tipovi podataka definiraju se kao domena.Primjer: za spremanje JMBAG-a studenta u tablicu za koje je poznato da se sastojiod 11 brojeva. Takoder poznato je da nije moguca pojava hrvatskih znakova (c, c...)u vrijednosti JMBAG-a. U takvim slucajevima je idealno za konzistentnost bazepodataka definirati tip podatka naziva JMBAG u kojeg se sprema tocno 11 brojeva.Na Slici 6.2 prikazana je sintaksa za kreiranje korisnicki definiranih podatkovnihtipova, a na Slici 6.3 kreiranja tipa podatka JMBAG i brisanje tipa podatka JMBAG,Slika 6.4.

Zanimljivo je spomenuti da ne postoji mogucnost mijenjanja ovog tipa podatakavec ga se mora obrisati te nakon brisanja ponovno kreirati.



Slika 6.2: Sintaksa za kreiranje korisnicki definiranih podatkovnih tipova

1 CREATE TYPE [ naziv_sheme. ] naziv_tipa2 FROM bazni_tip [ NULL | NOT NULL ];

Slika 6.3: Sintaksa za kreiranje tipa podatka JMBAG

1 CREATE TYPE Jmbag2 FROM char(11) NOT NULL;

Slika 6.4: Sintaksa za brisanje tipa podatka JMBAG

1 DROP TYPE Jmbag;

Korisnicki definirani tablicni tipovi

Drugi naziv za tablicne tipove podataka je privremene tablice. Nakon definiranjaprivremene tablice koristenje je slicno koristenju tablica. U Slici 6.5 prikazana jeosnovna sintaksa za kreiranje korisnicki definiranog tablicnog tipa podataka.

Slika 6.5: Osnovna sintaksa kreiranje tablicnih tipova

1 CREATE TYPE [naziv_sheme.] naziv_tablicnog_tipa2 AS TABLE3 (4 naziv-stupca podatkovni_tip,5 ...6 naziv-stupca_n podatkovni_tip_n7 )


7 Kreiranje strukture baze podataka

Prvi korak kod pohranjivanja podataka je kreiranje baze podataka. U ovom poglav-lju obradene su teme kreiranja sheme relacijske baze podatka sto ukljucuje kreiranjebaze podataka. pripadajucih tablica te postavljanje ogranicenja na definirane stupceunutar tablice.

7.1 Kreiranje baze podatakaKreiranje nove baze podataka u DBMS SQL jezikom izvrsava se naredbom cre-ate database. Na primjeru 7.1 moze se vidjeti primjer kreiranja baze MojaPr-vaBazaPodataka bez dodatnih postavki. Izvrsavanjem naredbe kreirana je bazapodataka naziva MojaPrvaBazaPodataka sa predefiniranim postavkama. Osim na-vedenog nacina, bazu podataka se moze kreirati i preko grafickog sucelja u vecinidbms-ova.

Kod 7.1: Kreiranje baze podataka1 CREATE DATABASE ’MojaPrvaBazaPodataka’

Brisanje baze podataka izvrsava se naredbom drop database. drop naredbase takoder koristi za brisanje bilo kojeg strukturnog objekta u bazi podataka, doknaredba delete brise podatke. Na primjeru 7.2 prikazano je brisanje baze poda-taka. Treba znati da dbms automatski nepovratno brise bazu podataka sa svimpodacima i shemom nakon izvrsavanja naredbe za brisanje baze podataka.

Kod 7.2: Brisanje baze podataka1 DROP DATABASE ’MojaPrvaBazaPodataka’

Za kreiranje baze podataka sa prilagodenim postavkama koristi se prosirenaopcija naredbe za kreiranje baze podataka. Na takav nacin moguce je definiratiprimjerice ponasanje baze podataka tijekom pohranjivanja podataka, fizicka lokacijadatoteka baze podataka itd. Na primjeru 7.3 prikazano je kreiranje baze podatakasa dodanim opcijama.

Kod 7.3: Kreiranje baze podataka sa dodatnim opcijama1 CREATE DATABASE MojaPrvaBazaPodataka2 ON (3 NAME = ’MPBP’,4 FILENAME = ’C:\MPBP.mdf’,5 SIZE = 10,6 MAXSIZE = 50,7 FILEGROWTH = 58 )9 LOG (

10 NAME = ’MPBP-LOG’,11 FILENAME = ’C:\MPBP.ldf’,12 SIZE = 1MB,

52

POGLAVLJE 7. KREIRANJE STRUKTURE BAZE PODATAKA

13 MAXSIZE = 25MB,14 FILEGROWTH = 5MB15 )

7.2 OgranicenjaOgranicenja su nacin na koji RDBMS namece korisniku ocuvanje integriteta bazepodataka. Ogranicenja definiraju pravila koja dopustaju unos samo valjanih vri-jednosti u stupce. Osim za ocuvanje integriteta baze podataka ona imaju vaznuulogu u kreiranju planova izvrsavanja upita, sto pridonosi boljim performansamabaze podataka. Neka od najcesce koristenih ogranicenja su:

NULL ili NOT NULL - sprjecava se unos NULL vrijednosti u stupac koji je defi-niran kao NOT NULL. Primjerice kako bi se sprijecio potencijalni problemunosa zapisa bez primarnog kljuca koji jedinstveno odreduje svaki zapis u bazipodataka, na primarni kljuc se postavi ogranicenje NOT NULL.

CHECK - ovim ogranicenjem definira se interval vrijednosti koje stupac moze po-primiti. Primjerice za unos atributa ocjena u bazu podataka postavlja seogranicenje vrijednosti koju atribut moze poprimiti na interval [1− 5].

UNIQUE - ovim ogranicenjem sprjecava se unos duplih vrijednosti u jednom stupcu,tj. ogranicenje se koristi kada je potrebno da svi redci jednog stupca imajurazlicitu vrijednost. Primjerice u tablici studenata postavljanje ovog ogranicenjana stupac ime znacilo bi da svaki student u tablici ima razlicito ime. U ovomslucaju NULL vrijednost se gleda kao jedna od vrijednosti te ju je mogucetakoder dodati u samo jedan redak.

DEFAULT - omogucava da stupac sa ovim ogranicenjem tijekom unosa vrijednostipoprimi definiranu pocetnu vrijednost ukoliko se ne unese neka druga vrijed-nost. Primjerice tijekom unosa ocjena studenata za atribut vrijeme unosamoze se postaviti DEFAULT(GETDATE()) sto ce omoguciti da stupac vri-jeme unosa poprimi vrijednost trenutnog vremena.

PRIMARY KEY je jedan atribut ili kombinacija atributa koji jedinstveno indenti-ficira svaki redak u tablici.

FOREIGN KEY je jedan atribut ili kombinacija atributa koji se koriste za uspos-tavljanje veza izmedu tablica.

Postavljanje veceg broja ogranicenja tijekom kreiranja strukture baze podatakaomogucava kasnije jednostavnije odrzavanje baze podataka. U sljedecem poglavljusu navedeni primjeri za kreiranje tablica sa ogranicenjima opisanim iznad.



7.3 Kreiranje i brisanje tablicaKreiranje tablice se radi naredbom CREATE TABLE ImeTablice. Ovom naredbomkreiramo samo strukturu modela u koji cemo kasnije pohranjivati podatke postujucidefinirana ogranicenja. Primjer kreiranja tablice Narudzba prikazan je na primjeru7.4

Kod 7.4: Kreiranje tablice arudzba1 CREATE TABLE Narudzba(2 Id int PRIMARY KEY IDENTITY(1,1) NOT NULL,3 VrijemeNarudzbe datetime NOT NULL DEFAULT (getdate()),4 Broj nvarchar(25) NOT NULL UNIQUE,5 KupacId int NOT NULL REFERENCES Kupac(Id),6 KreditnaKarticaId int NOT NULL REFERENCES

KreditnaKartica(Id),7 Komentar nvarchar(1024) NULL8 )

Atribut naziva Id predstavlja primarni kljuc, sto je definirano naredbom PRI-MARY KEY. Primarni kljuc mora biti jedinstven, pa se koristi naredba: IDENTITY[(p, i)] u kojoj p predstavlja pocetak niza i obicno je to 1, a drugi parametar i pred-stavlja inkrement, tj. velicinu koraka svakog sljedeceg generiranog ID-a. p i i morajubiti cijeli brojevi. Svi zapisi u stupacu broj narudzbe moraju biti razliciti, pa je de-finiran uz ogranicenje UNIQUE. U stupac VrijemeNarudzbe pohranjuje se podatako vremenu kreiranja narudzbe na nacin DEFAULT (getdate()). Ako korisnik unesedrugu vrijednost datuma, stupac ce poprimiti upisanu vrijednost, a ako vrijednostnije unesena generirati ce se datum i vrijeme koje se nalazi na uredaju na kojem jeDBMS instaliran. Atribut Komentar je tipa nvarchar(1024) sto znaci da se u njegamogu spremiti hrvatska slova, a maksimalna duzina atributa je 1024 znaka. Takoderatribut Komentar je definiran kao NULL stupac, pa unos komentara nije obvezan.Stupci KupacId i KreditnaKarticaId su definirani kao strani kljucevi. Svi stupci saogranicenjem NOT NULL su obvezni za unos vrijednosti osim ako DBMS sam negenerira vrijednost kao u slucaju stupaca Id i VrijemeNarudzbe.

Brisanje tablice kao i svakog objekta u bazi podataka radi se naredbom DROP.Na primjeru7.5 brise se tablica Narudzba. Brisanje je moguce ako se ne narusavareferencijalni integritet u protivnom tablica se nece obrisati i DBMS ce javiti po-gresku.

Kod 7.5: Brisanje tablice Narudzba1 DROP TABLE Narudzba

7.4 Mijenjanje strukture tablicaZa mijenjanje strukture tablice odnosno operacije dodavanje, brisanja ili modifikacijestupca na postojecoj tablici koristi se naredba ALTER TABLE.

Na primjeru 7.6 prikazano je dodavanje stupca Test u tablicu Narudzba koji jetipa nvarchar(50) i koji je opcionalan za unos (dopusten unos NULL vrijednosti).



Ako vec postoje podaci u tablici, a dodaje se novi stupac postavljanje NULL nanovo dodani stupac je obavezno.

Kod 7.6: Dodavanje novog stupca u postojecu tablicu1 ALTER TABLE Narudzba2 ADD Test nvarchar(50) NULL

Ako se zeli promijeniti tip podatka stupca koji je vec u tablici to se radi kao uprimjeru 7.7. Bitno je paziti u koji tip se pretvara jer moze doci do gubitka svihpodataka ili njihovog dijela.

Kod 7.7: Azuriranje stupca u postojecoj tablici1 ALTER TABLE Narudzba2 ALTER COLUMN Test nvarchar(150)

Na primjeru 7.8 prikazano je brisanje stupca Test i podataka unutar stupca.

Kod 7.8: Brisanje stupca iz tablice1 ALTER TABLE Narudzba2 DROP COLUMN Test


8 Modifikacija podataka

Postoji cetiri primarna nacina za modifikaciju podataka unutar vec kreiranih tablica.To su: INSERT, DELETE, UPDATE i MERGE. U ovoj skripti baviti cemo se saprve tri. Svaka od naredbi usmjerena je nekoj aktivnosti za modifikaciju podataka.U nastavku slijedi opis spomenutih naredbi te primjeri njihove upotrebe.

8.1 Dodavanje podataka u tablicuZa dodavanje podataka u vec postojecu tablicu koristi se kljucna rijec INSERT. Unastavku slijedi pojednostavljena sintaksa za dodavanje podataka u tablicu.

Kod 8.1: Osnovna sintaksa INSERT naredbe1 INSERT2 [ INTO ]3 { <objekt> }4 [ (lista_stupaca) ]5 { VALUES ({ DEFAULT | NULL | izraz } [ ,...n ]) [ ,...n ] }6 | izvedena_ztablica | izvrsena_naredba | DEFAULT VALUES

Kod dodavanja podataka u tablicu posebnu pozornost treba obratiti kakva ogranicenja(poglavlje 7.2) su zadana na tablici u koju se podaci dodaju. Takoder nuzna jeprovjera narusava li se referencijalni integritet zbog stranog kljuca. U slucaju nepostivanja bilo kojeg ogranicenja podaci se nece trajno pohraniti u tablicu. Stupcikoji na sebi imaju definirano jedno od ogranicenja: IDENTITY, DEFAULT ili NULLne zahtijevaju dodavanje vrijednosti.

Kod 8.2: Dodavanje nove vrijednosti u tablicu Drzava1 INSERT INTO Drzava (Naziv) VALUES (’Madagaskar’)

Na 8.2 prikazan je primjer dodavanja nove drzave u tablicu Drzava. Na primjerunije dodana vrijednost u stupac Id. Razlog je opcija IDENTITY koja omogucujeDBMS-u automatsko generiranje nove vrijednosti Id-a.

Osim dodavanja redak po redak nerijetko se stvori potreba za istovremenimdodavanjem vece kolicine podataka. Primjer takvog dodavanja podataka prikazanje na primjeru 8.3.

Kod 8.3: Osnovna sintaksa INSERT naredbe za dodavanje vise zapisa1 INSERT INTO tablica (stupac_1, ..., stupac_n)2 SELECT vrijednost_1, ..., vrijednost_n FROM tablica

Bitno je paziti da tipovi podataka tijekom dodavanja podataka odgovaraju tipo-vima podataka u tablici. Postojanje IDENTITY ogranicenja u tablici definira dvijemogucnosti:

• Ne upisati nista i prepustiti bazi da generira vrijednost tog stupca (primjer8.2)

56

POGLAVLJE 8. MODIFIKACIJA PODATAKA

• Eksplicitno upisati vrijednost u stupac na nacin da se opcija IDENTITY INSERTukljuci (primjer 8.4).

Kod 8.4: Primjer iskljucivanja/ukljucivanja IDENTITY INSERT-a1 SET IDENTITY_INSERT tablica ON2 INSERT INTO ...3 SET IDENTITY_INSERT tablica OFF

Bitno je napomenuti da samo jedna tablica u bazi moze imati ukljucen IDEN-TITY INSERT istovremeno. IDENTITY INSERT se najcesce koristi kod dodavanjavece kolicine inicijalnih podataka koristenjem SQL skripte.

8.2 Brisanje podataka iz tabliceZa brisanje zapisa iz tablice koristi se DELETE naredba. Bitno je ne izostavitiWHERE dio jer ce se u protivnom svi podaci iz tablice izbrisati. Najcesce se briseredak po redak, a podaci se filtriraju po primarnom kljucu tablice. Sintaksa zabrisanje zapisa iz tablice prikazana je na 8.5, a na 8.6 prikazan je primjer brisanjakupca iz tablice Kupac sa Id-em 100.

Kod 8.5: Osnovna sintaksa DELETE naredebe1 DELETE Tablica WHERE Uvjet

Kod 8.6: Primjer brisanja kupca1 DELETE Kupac WHERE Kupac.IDKupac = 100

Za brisanje svih podataka iz tablice moze se koristiti takoder naredba TRUN-CATE TABLE koja brise sve podatke iz tablice bez zapisivanja obrisanih redaka ulog datoteku. Vise o log datotekama biti ce objasnjeno kasnije u skripti. Na primjeru8.7 moze se vidjeti brisanje svih podataka iz tablice naredbom TRUNCATE. Akopostoji IDENTITY stupac u tablici on se takoder postavlja na pocetnu vrijednost.

Kod 8.7: Primjer brisanja jednog kupca1 TRUNCATE TABLE Narudzbe

8.3 Azuriranje podataka iz tabliceZa mijenjanje podataka u tablici koristi se naredba UPDATE. Bitno je ne izostavitiWHERE dio jer ce se u protivnom na sve podatke u tablici postaviti nove vrijednosti.UPDATE se odnosi samo na one retke koji zadovoljavaju kriterije u WHERE dijelu.U slucaju azuriranja jednog retka preporuca se filtriranje podataka po primarnomkljucu. Tijekom azuriranja podataka bitno je obratiti paznju na tipove podataka.Osnovna sintaksa za azuriranje prikazana je na 8.8 te azuriranje kupca iz tabliceKupac sa Id-em 100 na 8.9.


POGLAVLJE 8. MODIFIKACIJA PODATAKA

Kod 8.8: Osnovna sintaksa UPDATE naredebe1 UPDATE tablica SET2 stupac-1 = vrijednost-1,3 ...4 stupac-n = vrijednost-n5 WHERE uvjet

Primjer mijenjanja jednog zapisa iz tablice Kupac prikazana je iducim primje-rom:

Kod 8.9: Primjer mijenjanja podataka o kupcu1 UPDATE Kupac SET2 Email = ’[email protected]’,3 Telefon = ’0981837166’4 WHERE Kupac.IDKupac = 100


9 Dohvacanje podataka iz tablica

Dohvacanje podataka obuhvaca sortiranje i filtriranje podataka, koristenje agregat-nih funkcija nad grupama podataka te izvrsavanje podupita nad podacima. Nakonsto je baza podataka dizajnirana i popunjena podacima dolazi do potrebe dohvacanjapodataka. Dohvacanje podataka iz tablica izvrsava se naredbeom SELECT. Redos-lijed izvodenja naredbe SELECT prikazan je na slici 9.1.

Korak 4

[ DISTINCT ] [ TOP broj ]

{ stupac, … | * }

FROM izvorPodataka

WHERE uvjet

SELECTSELECT

ORDER BY { stupac [ ASC | DESC ], ... }

Korak 5

Korak 3

Korak 2

Korak 6

Korak 1

GROUP BY stupci

HAVING uvjet

Korak 7

Korak 8

Slika 9.1: Redosljed izvodenja SELECT naredbe

Svaki SELECT upit mora sadrzavati FROM dio upita i popis dohvacanih atri-buta. Ako se dohvacaju svi atributi koristi se znak * (zvjezdica), u svakom drugomslucaju atributi se navode redoslijedom dohvacanja. Primjer SELECT upita koji do-hvaca sve atribute iz tablice proizvod prikazan je na primjeru 9.1. U FROM dijeluse navode izvori podataka, tj. tablice, a izmedu SELECT i FROM dijela se navodipopis atributa ili *.

Kod 9.1: Najjednostavniji oblik SELECT upita1 SELECT * FROM Proizvod

=========================================================| Id | Naziv | S i f r a | Boja | C i j e n a |=========================================================| 1 | Headse t B a l l B e a r i n g s | BE−2908 | NULL | 10 .00 || 2 | Blade | BL−2036 | NULL | 10 .00 || 3 | LL Crankarm | CA−5965 | Crna | 10 .00 || . . . | . . . | . . . | . . . | . . . |

Primjer selekcije stupaca Naziv, Sifra i Boja iz tablice Proizvod prikazan je naprimjeru 9.2.

Kod 9.2: Dohvacanje samo odredenih stupaca SELECT naredbom

59

POGLAVLJE 9. DOHVACANJE PODATAKA IZ TABLICA

1 SELECT Naziv, Sifra, Boja FROM Proizvod

==========================================| Naziv | S i f r a | Boja |==========================================| Headse t B a l l B e a r i n g s | BE−2908 | NULL || Blade | BL−2036 | NULL || LL Crankarm | CA−5965 | Crna || . . . | . . . | . . . |

9.1 DISTINCTZa dohvacanje razlicitih vrijednosti pojedinog stupca koristi se naredba DISTINCTodmah poslije SELECT dijela te se nakon nje navode stupci cije se vrijednostidohvacaju. Vrijednost NULL se smatra jednom od vrijednosti. Na primjeru 9.3prikazano je dohvacanje razlicitih imena svih kupaca.

Kod 9.3: Primjer rada naredbe DISTINCT1 SELECT DISTINCT Ime2 FROM Kupac

===========| Ime |===========| Henry || J e f f r e y || A l b e r t || Helen || . . . |

Osim dohvacanja razlicitih vrijednosti iz jednog stupca mogu se dohvacati razlicitevrijednosti iz vise stupaca. U takvim slucajevima jedinstvenom vrijednoscu se sma-tra redak koji ima razlicite vrijednosti u svim stupcima.

9.2 TOPZa dohvacenje odredenog broja ili postotka redaka koristi se naredba TOP. Naprimjeru 9.4 prikazano je dohvacanje prva dva retka iz tablice Kupac.

Kod 9.4: Primjer koristenja naredbe TOP1 SELECT TOP 2 Ime, Prezime2 FROM Kupac

=======================| Ime | Prez ime |=======================| J o n a t h a n | Anderson || L o r i | Watson |

Na primjeru 9.5 prikazano je dohvacanje prvih 2% zapisa iz tablice Kupac. Uupitu se koristi izraz TOP n PERCENT, gdje je n postotak redaka koji se zelidohvatiti.



Kod 9.5: Primjer koristenja naredbe PERCENT1 SELECT TOP 2 PERCENT Ime, Prezime2 FROM Kupac

=======================| Ime | Prez ime |=======================| J o n a t h a n | Anderson || L o r i | Watson || . . . | . . . |

(401 row ( s ) a f f e c t e d )

9.3 SortiranjeKljucna rijec za sortiranje podataka je ORDER BY. Mogu se odabrati dvije vrstesortiranja: (1) silazno (ASC) i (2) uzlazno (DESC). NULL vrijednost se smatranajmanjom vrijednoscu. Predefinirano sortiranje je silazno te se ASC ne mora defi-nirati. Na primjeru 9.6 prikazano je dohvacanje imena i prezimena kupaca sortiranihprema atributu Ime silazno.

Kod 9.6: Osnovna sintaksa sortiranja1 SELECT Ime, Prezime2 FROM Kupac3 ORDER BY Ime

===================| Ime | Prez ime |===================| Aaron | Burns || Aaron | Hawkins || Aaron | Olson || . . . | R o b e r t s |

U primjeru 9.7 prikazano je uzlazno sortiranje prema pseudonimu. Atributu kojije rezultat spajanja dva stupca dan je naziv ’Ime i prezime’ te se rezultat sortirauzlazno prema navedenom nazivu.

Kod 9.7: Sortiranje preko alijasa1 SELECT Ime + ’ ’ + Prezime AS ’Ime i prezime’2 FROM Kupac3 ORDER BY ’Ime i prezime’ DESC

=================| Ime i p rez ime |=================| W i l l i e Wright || W i l l i e Wilson || W i l l i e Wilson || . . . |

Na primjeru 9.8 prikazano je dohvacanje imena i prezimena kupca sortiranihuzlazno prema imenu, a nakon toga silazno prema prezimenu.



Kod 9.8: Sortiranje prema dva stupca1 SELECT Ime, Prezime2 FROM Kupac3 ORDER BY Ime DESC, Prezime ASC

======================| Ime | Prez ime |======================| W i l l i e | Adams || W i l l i e | Alexande r || W i l l i e | A u s t i n || . . . | . . . |

9.4 FiltriranjeFiltriranje se koristi za dohvacanje podskupa podataka koristeci kljucnu rijec WHEREnakon koje se definira uvjet filtriranja. Na primjeru 9.9 prikazano je dohvacanje ku-paca cija je vrijednost atributa Ime ’Kim’.

Kod 9.9: Primjer filtriranja podataka po imenu1 SELECT * FROM Kupac WHERE Ime = ’Kim’

Za slozenija filtriranja podataka koriste se operatori. Operatora su podijeljeni unekoliko grupa. Jedna od grupa operatora su aritmeticki operatori:

+ - operator zbrajanja;

- - operator oduzimanja;

* - operator mnozenja;

/ - operator dijeljenja;

% - operator modulo.

Isti operatori se ponasaju razlicito primjenom na razlicite tipove podataka. Pri-mjerice primjenom operatora zbrajanja na dva cijela broja ili na dva znakovna tiparezultat ce razlicitim rjesenjem. Rezultat zbrajanja cijelih brojeva 2 + 2 ce biti 4,dok ce rezultat zbrajanja znakovnih tipova podataka ’2’ + ’2’ biti ’22’.

Sljedeca skupina operatora su logicki operatori:

AND - operator i;

OR - operator ili;

NOT -operator negacije.

Kako je cesto potrebno dohvatiti podskup podataka koji zadovoljava vise kriterijakoriste se logicki operatori u kombinaciji sa jos nekom skupinom operatora. Uprimjeru 9.10 dohvacaju se kupci cije je ime ’Jonathan’ ili ’Nicholas’. Izmedu jekoristen operator OR.



Kod 9.10: Primjer koristenja logickog operatora1 SELECT Ime, Prezime, Email FROM Kupac2 WHERE Ime = ’Jonathan’ OR Ime = ’Nicholas’

Treca skupina operatora su operatori usporedbe:

= - jednako;

> - strogo vece;

< - strogo manje;

>= - vece ili jednako;

<= - manje ili jednako;

<> - razlicito;

! = - razlicito;

! > - ne vece;

! < - ne manje.

Na primjeru 9.11 je prikazano koristenje operatora usporedbe strogo vece kakobi se dohvatili kupci cije je ime ’Jonathan’ ili ’Nicholas’ i Id im je veci od 1000.

Kod 9.11: Primjer koristenja kombinacije operatora1 SELECT Id, Ime, Prezime, Email FROM Kupac2 WHERE (Ime = ’Jonathan’ OR Ime = ’Nicholas’) AND Id > 1000

==========================================================| Id | Ime | Prez ime | Email |==========================================================| 1038 | J o n a t h a n | S t e v e n s | j o n a t h a n . s tevens@bug . h r || 1147 | J o n a t h a n | Gomez | j o n a t h a n . gomez@twi t t e r . com || 1373 | J o n a t h a n | F i s h e r | j o n a t h a n . f i s h e r @ y m a i l . com || . . . | . . . | . . . | . . . |

Za dohvacanje svih podataka koji pripadaju nekom skupu podataka koristi seoperator IN. U prethodnom primjeru smo trebali dohvaceni su svi kupce cije je ime’Jonathan’ ili ’Nicholas’, no ukoliko se dohvacaju i kupci cija su imena ’Aron’, ’Cla-rence’ itd. moze se koristiti operator IN. Na primjeru 9.12 prikazano je dohvacanjesvih kupaca iz skupa imena ’Jonathan’, ’Nicholas’, ’Aron’ i ’Clarence’ koristenjemIN operatora. Jednak rezultat se moze postici koristenjem vise operatora OR.

Kod 9.12: Koristenje operatora IN1 SELECT Id, Ime, Prezime, Email FROM Kupac2 WHERE Ime IN (’Jonathan’, ’Nicholas’, ’Aron’, ’Clarence’)



==========================================================| Id | Ime | Prez ime | Email |==========================================================| 1 | J o n a t h a n | Anderson | j o n a t h a n . a n d e r s o n @ l i v e . com || 4 | N i c h o l a s | Edwards | n i c h o l a s . edwards@live . com || 6 | J o n a t h a n | Lopez | j o n a t h a n . lopez@mail . com || . . . | . . . | . . . | . . . |

Tijekom filtriranja podataka cesto dolazi do potrebe da se dohvate podaci unekom rasponu. Raspon vrijednosti koje se dohvacaju moze se definirati koristenjemoperatora BETWEEN, primjer 9.13. Rezultat upita prikazan na 9.13 ukljucuje Id1000 i 1003, pa se moze zakljuciti da su donja i gornja granica kod ovog operatoraukljucujuce.

Kod 9.13: Koristenje operatora BETWEEN1 SELECT Id, Ime, Prezime, Email FROM Kupac2 WHERE Id BETWEEN 1000 AND 1003

===================================================| Id | Ime | Prez ime | Email |===================================================1000 | Mario | Lewis | mario . l e w i s @ t w i t t e r . com |1001 | Andrew | T o r r e s | andrew . t o r r e s @ a d o p t o . eu |1002 | C a r l o s | Hunte r | c a r l o s . hunte r@mai l . com |1003 | Howard | Cruz | howard . cruz@mail . com |

Za pretrazivanje znakovnih nizova koristi se operator LIKE. Na taj nacin prona-lazi se odredeni uzorak unutar zadanog niza znakova. Kako bi uzorak pozicioniralina pocetak, kraj ili sredinu niza kojeg trazimo koriste se simboli prikazani ispod:% - oznacava bilo koji string koji se sastoji od niti jednog ili vise znakova, primjerice

izraz LIKE ’%a%’ bi vratio sva imena koja unutar sebe na bilo kojoj pozicijiimaju znak ’a’;

- zamjenjuje bilo koji znak, ali samo jedan, primjerice izraz LIKE ’ p%’ bi vratiosve retke kojima na kojima znakovni niz od interesa ima drugo slovo ’p’, aostatak moze biti bilo sto;

[ ] - bilo koji znak iz npr. raspona ([a-c]) ili skupa [abcdefgh], primjerice izraz LIKE’[a-c]%’ bi vratio sva retke ciji stupac od initeresa pocinje sa slovima iz rasponaod ’a’ do ’c’;

ˆ - bilo koji znak koji nije iz npr. raspona (’[ˆa-c]%’);Na primjeru 9.14 prikazano je dohvacanje svih kupaca cije ime zapocinje sa

slovima ’a’, ’b’ ili ’g’.

Kod 9.14: Upotreba operatora LIKE1 SELECT Id, Ime, Prezime, Email FROM Kupac2 WHERE Ime LIKE ’[abg]%’

Za filtriranje podataka koristi se IS koji provjerava ima li neka vrijednost vrijed-nost NULL, navodi se u WHERE dijelu naredbe ali ne pripada skupini operatora.Na primjeru 9.15 prikazano je dohvacanje svih kupaca ciji broj telefona nije unesen.Povratni tip IN-a je Boolean sto znaci da vraca vrijednost TRUE ili FALSE.



Kod 9.15: Upotreba IS-a1 SELECT Id, Ime, Prezime, Email FROM Kupac2 WHERE Telefon IS NULL

Za dohvacanje suprotnih vrijednosti, tj. kupaca ciji je telefon unesen, koristi selogicki operator NOT poslije IS-a (WHERE Telefon IS NOT NULL).

9.5 Specijalni operatoriISNULL() je sistemsku funkcija koja NULL vrijednost mijenja sa vrijednoscu kojukorisnik odredi. Ne treba mijesati sa operatorom IS NULL koji vraca true ili false.Na primjeru 9.16 moze se vidjeti upotreba funkcije ISNULL. Ako je vrijednost stupcaradno mjesto, email i telefona NULL zamijeniti ce se sa vrijednoscu ’Nezaposlen’ ili’-’.

Kod 9.16: Upotreba ISNULL funkcije1 SELECT2 Ime, Prezime,3 ISNULL(RadnoMjesto, ’Nezaposlen’) ’RadnoMjesto’,4 ISNULL(Email, ’-’) ’Email’,5 ISNULL(Telefon, ’-’) ’Telefon’6 FROM Kupac

EXISTS je sistemska funkcija koja sluzi za ispitivanje postojanja redaka unutarsebe. Vraca istinu ili laz i koristi se u WHERE dijelu SELECT naredbe.

9.6 Agregatne funkcijeAgregatne funkcije izracunavaju jednu vrijednost iz skupa vrijednosti i najcesce seprimjenjuju za grupe podataka. U nastavku su navedene agregatne funkcije:

AVG(ALL | DISTINCT) - vraca prosjek vrijednosti u grupi, dok se NULL vrijed-nosti ignoriraju;

MIN(ALL | DISTINCT) - vraca minimalnu vrijednost iz grupe;

MAX(ALL | DISTINCT) - vraca maksimalnu vrijednost iz grupe;

SUM(ALL | DISTINCT) - vraca sumu svih vrijednosti iz grupe (ili samo razlicitih:DISTINCT), dok se NULL vrijednosti ignoriraju;

CUNT(ALL | DISTINCT | *) - vraca broj elemenata u grupi. Pozvana s parame-trom * broji NULL vrijednosti i duple vrijednosti.

Koristenje agregatnih funkcija prikazano je primjerom 9.17 gdje se izracunavaprosjecna, najmanja, najveca i suma svih cijena proizvoda.



Kod 9.17: Primjer koristenja agregatnih funkcija1 SELECT2 AVG(Cijena) AS ’Prosjek’,3 MIN(Cijena) AS ’Najmanja’,4 MAX(Cijena) AS ’Najveca’,5 SUM(Cijena) AS ’Suma’6 FROM Proizvod

=================================================| P r o s j e k | Najmanja | Najveca | Suma |=================================================| 537 .4337 | 2 .7709 | 4329 .7067 | 268179.4506 |

Na primjeru 9.18 je prikazano prebrojavanja boja iz tablice Proizvod. Kada sepromotri rezultat upita vidljivo je da su dohvacene razlicite vrijednost prebroja-vanjem redaka po stupcu i svih redaka. Razlog je sto COUNT(NekiStupac) vracabroj redaka koji nemaju NULL vrijednost upisanu u NekiStupac, a COUNT(*) vracaukupni broj redaka bez obzira na NULL vrijednost. Ostale agregatne funkcije osimCOUNT funkcije ignoriraju NULL vrijednosti.

Kod 9.18: Koristenje COUNT funkcije1 SELECT2 COUNT(Boja) AS ’COUNT(Boja)’,3 COUNT(*) AS ’COUNT(*)’4 FROM Proizvod

==========================| COUNT( Boja ) | COUNT( * ) |==========================| 254 | 499 |

9.7 Grupiranje podatakaGrupiranje podataka sluzi da bi se odredeni set podataka podijelio u grupe. Podacise grupiraju unutar SELECT upita naredbom GROUP BY. Potreba za grupiranjempodataka najcesce nastaje koristenjem agregatnih funkcija nad grupom objekata.Grupiranje podataka prema nekom stupcu ogranicava selekcijsku listu, tj. samostupac po kojemu su podaci grupirani se moze nalaziti u SELECT dijelu upita.

Kod 9.19: Grupiranje podataka1 SELECT2 Boja,3 AVG(Cijena) ’Prosjecna cijena’,4 COUNT(*) ’Broj proizvoda’5 FROM Proizvod6 GROUP BY Boja

==============================================| Boja | P r o s j e c na c i j e n a | Bro j p r o i z v o d a |==============================================



| NULL | 28 .2473 | 245 || B i j e l a | 11 .1864 | 4 || Crna | 882 .7593 | 91 || . . . | . . . | . . . |

Na primjeru 9.19 prikazano je grupiranje proizvoda prema boji te postupak do-hvacanja prosjecne cijene proizvoda pojedine boje i broja proizvoda svake boje.

9.8 PodupitiPodupit (engl. subquerry) je SELECT naredba ugnjezdena unutar naredbi SELECT,SELECT...INTO, INSERT...INTO, UPDATE, DELETE. Na 9.20 prikazane su trisintakse za koristenje podupita. Podupiti se mogu koristiti u razne svrhe,a dijelimoih:

• Podjela prema nacinu rada

– Konstantni podupiti(ne ovise o retku vanjskog upita)– Korelirani podupiti(ovise o retku vanjskog upita)

• Podjela prema mjestu pojavljivanja

– Podupiti u SELECT dijelu– Podupiti u WHERE/HAVING dijelu

• Podjela prema povratnoj vrijednosti

– Skalarni podupiti (vracaju jednu vrijednost)– Tabularni podupiti (vracaju tablicu)

Kod 9.20: Podupit - prvi oblik sintakse1 usporedba [ ANY | ALL | SOME ] (podupit)

Kod 9.21: Podupit - drugi oblik sintakse1 izraz [ NOT ] IN (podupit)

Kod 9.22: Podupit - treci oblik sintakse1 [ NOT EXISTS] (podupit)

Podupit se sastoji od (1) usporedbe koja je izraz i operator koji usporedujeizraz s rezultatima upita, (2) izraza za koji se skup rezultata podupita pretrazuje te(3) SQLnaredbe, tj. naredbe SELECT upita koja slijedi isto oblikovanje i pravilakao i bilo koja druga SELECT naredba.

U nastavlku slijedi primjer koristenja podupita. Zadatak je dohvatiti sve kupcekoji stanuju u gradu Zagrebu.



Kod 9.23: Primjer koristenja podupita u usporedbi1 SELECT2 Ime,3 Prezime4 FROM Kupac5 WHERE Kupac.GradID = (SELECT GradID FROM Grad6 WHERE Grad.Naziv = ’Zagreb’)

Ime Prez ime−−−−−−−−−−−−−−−−−−−−−−−−− −−−−−−−−−−−−Ana LeeC a t h e r i n e AbelKim AbercrombieHumberto AcevedoP i l a r Ackerman. . . . . .C r y s t a l He

(19975 row ( s ) a f f e c t e d )


10 Spajanje tablica

Kod dohvacanja podataka iz razlicitih tablica povezanih stranim kljucem potrebnoje koristiti operaciju spajanja. Postoji nekoliko vrsta spajanja koja se dijele na unu-trasnje, vanjsko i samospajanje. Svi primjeri spajanja tablica izvode se na tablicama:TablicaA i TablicaB koje su prikazane na 10.Tab l i caA T a b l i c a B================== ==================| Id | Naziv | | Id | Naziv |================== ==================| 1 | Zagreb | | 3 | S p l i t || 2 | K a r l o v a c | | 4 | R i j e k a || 3 | S p l i t | | 5 | O s i j e k || 4 | R i j e k a | | 6 | Dubrovnik |

Na slici 10.1 vizualno su prikazana spajanja podataka i odgovarajuce SQL na-redbe. A i B predstavljaju skupove podataka koji se spajaju odnosno tablice kojesu izvori podataka.

Slika 10.1: Vizualni prikaz operacija spajanja

69

POGLAVLJE 10. SPAJANJE TABLICA

10.1 Unutarnje spajanjeUnutarnje spajanje (INNER JOIN) je dio SELECT izraza koji dohvaca zapise iz dvijeili vise tablica. Unutarnje spajanje je najcesce koristeno spajanje. Kod unutarnjegspajanja nije bitan redoslijed navodenja tablica. Logicki opis procesa spajanja dvijetablice prikazan je sljedecim koracima:

1. potrebno je zadati uvjet spajanja. Najcesce je to operator ’=’ (equi join) kojispaja primarni kljuc jedne tablice sa stranim kljucem u drugoj tablici;

2. za svaki redak u prvoj tablici DBMS pronalazi redak u drugoj tablici premauvjetu spajanja koji mora biti zadovoljen;

3. rezultat je tablica koja sadrzi redke iz obje tablice koje smo spajali i sluzi kaoizvor podataka.

Unutrasnje spajanje vraca samo one podatke koji se nalaze i u tabliciA i u ta-bliciB kao je prikazano na 10.1.

Kod 10.1: Primjer spajanje dvije tablice unutrasnjim spajanjem1 SELECT * FROM TablicaA2 INNER JOIN TablicaB3 ON TablicaA.Naziv = TablicaB.Naziv

===========================Id | Naziv | Id | Naziv |===========================3 | S p l i t | 3 | S p l i t |4 | R i j e k a | 4 | R i j e k a |

Unutrasnje spajanje moze se povezati vise od dvije tablice. Na 10.2 je prikazanprimjer spajanje tri tablice unutrasnjim spajanjem. Rezultat upita su filtrirani kupcicije ime pocinje sa R (LIKE ’R%’). Takoder nisu svi atributi ispisani vec samo oninavedeni u SELECT dijelu upita.

Tijekom spajanja vise tablica cesto atributi iz razlicitih tablica imaju isti naziv,pa se tada koristi operator AS za preimenovanje jednog od atributa. Primjericetablice Regija i Drzava imaju jednak atribut Naziv, pa su imena tih atributa pro-mijenjena koristenjem operatora AS.

Kod 10.2: Primjer spajanje tri tablice unutrasnjim spajanjem1 SELECT2 Kupac.Ime,3 Kupac.Prezime,4 Regija.Naziv AS ’Regija’,5 Drzava.Naziv AS ’Drzava’6 FROM Drzava7 INNER JOIN Regija ON Regija.DrzavaId = Drzava.Id8 INNER JOIN Kupac ON Kupac.RegijaId = Regija.Id9 WHERE Kupac.Ime LIKE ’R%’



1 | Zagreb | NULL | NULL |2 | K a r l o v a c | NULL | NULL |3 | S p l i t | 3 | S p l i t |4 | R i j e k a | 4 | R i j e k a |NULL | NULL | 5 | O s i j e k |NULL | NULL | 6 | Dubrovnik |

10.5 Unakrsno spajanjeUnakrsno spajanje (CROSS JOIN) je spajanje svih mogucih kombinacija podatakaiz tablica bez WHERE dijela. Ovo nije nista drugo vec Kartezijev produkt. Brojredaka u rezultatu upita jednak je umnosku broja redaka svih tablica koje sudjelujuu unakrsnom spajanju. Na primjeru tablica A i B koje sadrze 4 retka rezultat sadrzi16 redaka. Na 10.8 prikazana su dva nacina koristenja unakrsnog spajanja. Za obaupita rezultat ce biti jednak.

Kod 10.8: Primjer unakrsnog spajanja (prvi nacin)1 SELECT2 A.Id AS ’A-Id’,3 A.Naziv AS ’A-Naziv’,4 B.Id AS ’B-Id’,5 B.Naziv AS ’B-Naziv’6 FROM TablicaA A7 CROSS JOIN TablicaB B

1 SELECT2 A.Id AS ’A-Id’,3 A.Naziv AS ’A-Naziv’,4 B.Id AS ’B-Id’,5 B.Naziv AS ’B-Naziv’6 FROM TablicaA A, TablicaB B

====================================A−Id | A−Naziv | B−Id | B−Naziv |====================================1 | Zagreb | 3 | S p l i t |2 | K a r l o v a c | 3 | S p l i t |3 | S p l i t | 3 | S p l i t |4 | R i j e k a | 3 | S p l i t |1 | Zagreb | 4 | R i j e k a |2 | K a r l o v a c | 4 | R i j e k a |3 | S p l i t | 4 | R i j e k a |4 | R i j e k a | 4 | R i j e k a |1 | Zagreb | 5 | O s i j e k |2 | K a r l o v a c | 5 | O s i j e k |3 | S p l i t | 5 | O s i j e k |4 | R i j e k a | 5 | O s i j e k |1 | Zagreb | 6 | Dubrovnik |2 | K a r l o v a c | 6 | Dubrovnik |3 | S p l i t | 6 | Dubrovnik |4 | R i j e k a | 6 | Dubrovnik |



10.6 Spajanje tablica podupitimaPodupiti se za spajanje tablica mogu koristiti umjesto bilo kojeg navedenog spajanja.Na primjeru 10.9 prikazan je primjer unutrasnjeg spajanja podupitom. Rezultat jeekvivalentan rezultatu unutarnjeg spajanja.

Kod 10.9: Primjer unutrasnjeg spajanja podupitom1 SELECT2 r.Id,3 r.Naziv,4 (SELECT Naziv FROM Drzava d5 WHERE d.Id = r.DrzavaId) ’Drzava’6 FROM Regija r

============================Id | Naziv | Drzava |============================1 | C a n i l l o | Andorra |2 | Encamp | Andorra |3 | La Massana | Andorra |. . . | . . . | . . . |

10.7 Spajanje tablice sa samom sobomSpajanje tablice sa samim sobom naziva se samospajanje (self-join). Samospajanjese koristi kada postoji hijerarija u tablici. Za primjer prikaza samospajanja koris-titi ce se tablica Zaposlenik iz baze FpzLogistika. Kako bi ispisali sve zaposlenikei njihove nadredene potrebno je koristiti samosapajanje. Postoje dva nacina sa-mospajanja: (1) unutrasnjim spjanjem i (2) podupitom. U nastavku slijedi primjersamospajanja sa podupitom, 10.10.

Kod 10.10: Primjer samospajanja podupitom1 SELECT2 z1.Ime,3 z1.Prezime,4 (SELECT Ime + ’ ’ + Prezime FROM Zaposlenik z25 WHERE z1.NadredjeniId = z2.Id) ’Nadredjeni’6 FROM Zaposlenik AS z1

===============================Ime | Prez ime | N a d r e d j e n i |===============================J o s i p | Markovi c | I g o r I g i c |Mario | Mari c | I g o r I g i c |I van | I v i c | I g o r I g i c |Ante | Ant i c | I g o r I g i c |I g o r | I g i c | NULL |


11 Operacije sa skupovima

Operatori skupova rade na dva rezultata upita, usporedujuci njihove kompletneretke te ovisno o rezultatu i zadanom operatoru odreduje hoce li pojedini redak bitiu rezultatu ili ne. T-SQL podrzava tri operatora skupova: UNION, INTERSECT iEXCEPT. Takoder je podrzana jedna operacija na multi skupovima: UNION ALL.Opci oblik naredbi za rad sa skupovima podatak slijedi.

1 <upit 1>2 <operator skupa>3 <upit 2>

Na istom primjeru kao i kod spajanja tablica (TablicaA i TablicaB) biti ce objasnjenisvi operatori skupova u sljedecim poglavljima.

11.1 UNION i UNION ALLOperator UNION se koristi za kombiniranje dvije ili vise rezultirajucih skupova.Skupovi moraju sadrzavati istovjetne retke, sto znaci da vrijednosti stupaca morajubiti istog tipa podatka ili kompatibilne. UNION operator vraca sve retke koji surezultat unije skupova. Jedan element skupa je jedan redak u tablici. Na slici 11.1ilustriran je UNION operator koristenjem Vennova diagrama.

Slika 11.1: Operator UNION prikazan Vennovim dijagramom

Primjer upotrebe UNION operatora sa rezultatima operacije nad tablicama A iB dan je na 11.1.

Kod 11.1: Upotreba UNION operatora1 SELECT Id, Naziv FROM TablicaA2 UNION3 SELECT Id, Naziv FROM TablicaB

==================| Id | Naziv |==================| 1 | Zagreb || 2 | K a r l o v a c || 3 | S p l i t || 4 | R i j e k a || 5 | O s i j e k || 6 | Dubrovnik |

75

POGLAVLJE 11. OPERACIJE SA SKUPOVIMA

Ako se zele zadrzati dupli redci kao operator potrebno je koristiti UNION ALL.Koristenje navedenog operatora rezultira unijom dva skupa bez uklanjanja dvos-trukih redaka kao UNION operator. Ilustracija operatora UNION ALL Vennovimdijagramom prikazana je slikom 11.2.

Slika 11.2: Operator UNION ALL prikazan Vennovim dijagramom

Kod 11.2: Upotreba UNION ALL operatora1 SELECT Id, Naziv FROM TablicaA2 UNION ALL3 SELECT Id, Naziv FROM TablicaB

==================| Id | Naziv |==================| 1 | Zagreb || 2 | K a r l o v a c || 3 | S p l i t || 4 | R i j e k a || 3 | S p l i t || 4 | R i j e k a || 5 | O s i j e k || 6 | Dubrovnik |

11.2 INTERSECTINTERSECT operator vraca sve razlicite retke koji su zajednicki svim skupovimakoji sudjeluju u operaciji. Da bi se redak pojavio u rezultatu mora se identicanredak nalaziti i u ostalim skupovima. Slika 11.3 prikazuje INTERSECT operatorVennovim dijagramom.

Na primjeru 11.3 moze se vidjeti kako su rezultat INTERSECT operacije redcikoji se pojavljuju u svim skupovima.

Kod 11.3: Upotreba INTERSECT operatora1 SELECT Id, Naziv FROM TablicaA2 INTERSECT3 SELECT Id, Naziv FROM TablicaB

==================| Id | Naziv |==================


POGLAVLJE 11. OPERACIJE SA SKUPOVIMA

Slika 11.3: Operator INTERSECT prikazan Vennovim dijagramom

| 3 | S p l t || 4 | R i j e k a |

11.3 EXCEPTEXCEPT operator rezultira razlikom skupova, odnosno vraca razlicite retke iz pr-vog upita koji se ne pojavljuju u ostalim upitima. Drugim rijecima, redak koji sepojavljuje u prvom upiti najmanje jedanput, a ne pojavljuje se u drugim upitimanalaziti ce se u rezultatu. Na slici 11.4 ilustriran je EXCEPT operator sa Vennovimdiagramom.

Slika 11.4: Operator EXCEPT prikazan Vennovim dijagramom

Kao primjer upotrebe EXCEPT operatora koriste se TablicaA i TablicaB, arezultat operacija je prikazan na 11.4.

Kod 11.4: Upotreba EXCEPT operatora1 SELECT Id, Naziv FROM TablicaA2 EXCEPT3 SELECT Id, Naziv FROM TablicaB

==================| Id | Naziv |==================| 1 | Zagreb || 2 | K a r l o v a c |


12 Sistemske funkcije

Sistemske funkcije ovdje obuhvacene mogu se podijeliti na agregatne (poglavlje 9.6) iskalarne. Skalarne funkcije su one ciji je argument skalarna vrijednost odnosno jednavrijednost iz jedne domene. Agregatne funkcije preslikavaju skup vrijednosti jednogstupca (obicno iz tablice) u skalarnu vrijednost. Skalarne funkcije obuhvacene ovimpoglavljem su: funkcije za rad s datumom i vremenom, matematicke funkcije ifunkcije za rad sa znakovima.

12.1 Funkcije za rad sa datumom i vremenomPostoji mnogo funkcija za rad sa datumskim i vremenskim tipom podatka. U nas-tavku je odabrano nekoliko njih koje se najcesce koriste.

DATEPART(dio datuma, datum) - Dio datuma moze biti: year, quarter, month,day, week, hour, minute, second, millisecond, microsecond, nanosecond i slicno.Kao rezultat vraca cijeli broj trazenog dijela datuma.

DAY(datum) - Kao rezultat vraca dan u mjesecu od datuma predanog kao para-metar.

MONTH(datum) - Kao rezultat vraca mjesec od datuma predanog kao parametar.

YEAR(datum) - Kao rezultat vraca godinu od datuma predanog kao parametar.

DATEDIFF(dio datuma, pocetni datum, krajnji datum) - dio datuma moze bitiraznovrstan kao i u funkciji DATEPART. Razlika je sto je vraceni rezultatcijeli broj izmedu dva datuma koja se predaju kao parametri. Primjerice akoje dio datuma DAY, rezultat je broj dana izmedu dva predana dana.

DATEADD(dio datuma, broj, datum) - u dijelu dio datuma opisuje se koji diodatumskog tipa podatka se povecava od predanog datuma za broj predanihjedinica.

GETDATE() - Funkcija vraca trenutno vrijeme racunala na kojem je DBMS insta-liran.

U nastavku na 12.1,12.2 navedena su dva primjera koristenja funkcija za rad sadatumom i vremenom.

Kod 12.1: Primjer koristenja datumskih funkcija1 SELECT2 GETDATE() AS ’GETDATE()’,3 DATEPART(YEAR, GETDATE()) AS ’DATEPART(YEAR, GETDATE())’,4 YEAR(GETDATE()) AS ’YEAR(GETDATE())’

78

POGLAVLJE 12. SISTEMSKE FUNKCIJE

=========================================================================| GETDATE ( ) | DATEPART(YEAR, GETDATE ( ) ) | YEAR(GETDATE ( ) ) |=========================================================================| 2015−05−26 1 5 : 3 2 : 3 7 . 2 1 7 | 2015 | 2015 |

Kod 12.2: Primjer koristenja DATEDIFF funkcije1 SELECT2 DATEDIFF(DAY, ’2011-11-11’, ’2012-11-11’) AS ’Dana’,3 DATEDIFF(HOUR, ’2011-11-11’, ’2012-11-11’) AS ’Sati’,4 DATEDIFF(SECOND, ’2011-11-11’, ’2012-11-11’) AS ’Sekundi’

==========================| Dana | S a t i | Sekundi |==========================| 366 | 8784 | 31622400 |

12.2 Matematicke funkcije

Sve matematicke funkcije osim RAND su deterministicke. Sto znaci da ce za istiskup parametara vratiti istu vrijednost. U tablici je dan pregled matematickihfunkcija sa opisom cemu sluze.

ABS(brojcani izraz) - Izracunava absolutnu vrijednost predanog broja.

ACOS(float izraz) - Izracunava kut u radijanima ciji je kosinus odreden float iz-razom. Float izraz mora biti u rasponu od -1 do 1 inace se vraca domenskagreska.

ASIN(float izraz) - Izracunava kut u radijanima ciji je sinus odreden float izrazom.Float izraz mora biti u rasponu od -1 do 1 inace se vraca domenska greska.

ATAN(float izraz) - Izracunava kut u radijanima ciji je tangens odreden float izra-zom. Zove se

ATN2(float izraz, float izraz) - Izracunava kut u radijanima, izmedu pozitivne x-osi i tocke (y, x), gdje su X i Y vrijednosti dviju navedenih float izraza.

CEILING(brojcani izraz) -Matematicka funkcija koja vraca gornji cijeli broj brojcanogizraza.

COS(float izraz) - Izracunava kosinus od float izraza koji predstavlja kut u radija-nima.

COT(float izraz) - Izracunava kotangens kuta u radijanima koji je odreden floatizrazom.

DEGREES(brojcani izraz) - Pretvara radijane koji su odredeni brojcanim izrazomu stupnjeve.

EXP(float izraz) - Izracunava eksponencijalnu vrijednost float izraza.



FLOOR(brojcani izraz) - Izracunava donji cijeli broj brojcanog izraza.

LOG(float izraz[,baza )] - Izracunava prirodni logaritam float izraza.

LOG10(float izraz) - Izracunava logaritam sa bazom 10.

PI() - Vraca konstantnu vrijednost broja PI.

POWER(float izraz, y) - Izracunava kvadrat float izraza. Y predstavlja potenciju.

RADIANS(brojcani izraz) - Pretvara stupnjeve koji se unose kao brojcani izraz uradijane.

RAND([b )] - Vraca slucajno generiranu float vrijednost od 0 do 1. Opcionalno semoze postaviti cijelobrojna vrijednost b. Za isti b ce se uvijek vratiti ista floatvrijednost.

ROUND(brojcani izraz, duzina [,funkcija )] - Zaokruzuje vrijednost brojcanog iz-raza na zadani broj decimalnih mjesta.

SIGN(brojcani izraz) - Za brojcani izraz vraca -1 ako se radi o negativnom broju,0 ako se radi o nuli, a za pozitivne brojeve vraca 1.

SIN(float izraz) - Izracunava sinus od float izraza koji predstavlja kut u radijanima.

SQRT(float izraz) - Izracunava korijen od predane float vrijednosti.

SQUARE(float izraz) - Vraca kvadrat predanog float izraza.

TAN(float izraz) - Izracunava tangens float izraza.

Na primjerima 12.3, 12.3 prikazano je koristenja matematickih funkcija za izracunavanjeapsolutne vrijednosti te korijen i kvadrat broja.

Kod 12.3: Koristenje funkcije za izracun absolutnih brojeva1 SELECT2 ABS(-1.0) AS ’ABS(-1.0)’,3 ABS(0.0) AS ’ABS(0.0)’,4 ABS(1.0) AS ’ABS(1.0)’

===================================| ABS( −1.0) | ABS ( 0 . 0 ) | ABS ( 1 . 0 ) |===================================| 1 . 0 | 0 . 0 | 1 . 0 |

Kod 12.4: Koristenje funkcija za korjenovanje i kvadriranje1 SELECT2 SQRT(16) AS ’SQRT(16)’,3 SQUARE(4) AS ’SQUARE(4)’

========================| SQRT( 1 6 ) | SQUARE( 4 ) |========================| 4 | 16 |



12.3 Funkcije za rad sa znakovimaPopis najznacajnijih funkcija za rad sa znakovima je prikazan ispod. Sve funkcijesu deterministicke i vracaju uvijek znak(ove) ili cijeli broj.

ASCII(znak) - Vraca poziciju predanog znaka u ASCII tablici.

CHAR(brojcani izraz) - Pretvara brojcani izraz prema ASCII tablici u znak.

CHARINDEX(znakovni niz1, znakovni niz2 [,start )] - Znakovni niz 1 je onaj ukojemu nesto pokusavamo pronaci i limitiran je na 8000 znakova. Znakovniniz 2 je ono sto se trazi. Opcionalno se moze navesti startna pozicija od kudapocinje trazenje.

CONCAT(znakovni niz1,znakovni niz2, [znakovni nizN )] - Rezultat ove funkcijeje spajanje svih znakova koji se navedu kao parametri. Moze se spajati dva ilivise znakovnih nizova.

DIFFERENCE(znakovni niz1,znakovni niz2) - Vraca cijelobrojnu vrijednost brojarazlicitih znakova u dva znakovna niza koji se primaju kao parametri.

LEFT(znakovni niz, brojcani izraz) - Kao rezultat vraca lijevi dio znakovnog nizai to onoliko znakova koliko je specificirano brojcanim izrazom.

LEN(znakovni niz) - Kao rezultat vraca cijeli broj koji predstavlja broj znakova uznakovnom izrazu.

LOWER(znakovni niz) - Sva velika slova iz znakovnog niza pretvara u mala i vracaih kao rezultat.

LTRIM(znakovni niz) - Kao rezultat vraca znakovni niz nakon sto ukloni praznamjesta (space) sa lijeve strane.

NCHAR(brojcani izraz) - Pretvara brojcani izraz prema Unicode tablici u znak.

REPLACE(znakovni niz1, znakovni niz2, znakovni niz3) - Znakovni niz 1 je uzo-rak na kojemu ce se vrsiti zamjena. Niz 2 oznacava uzorak koji ce se zamje-njivati. Niz 3 predstavlja novi uzorak koji ce popuniti niz 2 nakon zamjene.

REPLICATE(znakovni niz, brojcani izraz) - Replicira znakovni niz onoliko putakoliko je odredeno brojcanom vrijednosti.

REVERSE(znakovni niz) - Kao rezultat vraca obrnut znakovni niz od onog kojimu je predan kao parametar.

RIGHT(znakovni niz, brojcani izraz) - Kao rezultat vraca desni dio znakovnogniza i to onoliko znakova koliko je specificirano brojcanim izrazom.

RTRIM(znakovni niz) - Kao rezultat vraca znakovni niz nakon sto ukloni praznamjesta (space) sa desne strane.



SUBSTRING(znakovni niz, start, duljina uzorka) - Kao rezultat vraca dio zna-kovnog niza na nacin da mu se putem parametra start zadaje pocetna pozicijauzimanja uzorka, a parametrom duljina zadaje se duljina uzorka. Prvo slovou znakovnom nizu nalazi se na indeksu 1, a ne na 0 sto je uobicajeno.

UNICODE(znak) - Vraca poziciju predanog znaka u Unicode tablici.

UPPER(znakovni niz) - Sva mala slova iz znakovnog niza pretvara u velika i vracaih kao rezultat.

Na primjru 12.5 prikazano je koristenja nekih od funkcija za rad sa znakovima.

Kod 12.5: Primjer koristenja nekih funkcija za rad sa znakovima1 SELECT2 LEFT(’Pero ide u sumu’, 5) AS ’LEFT’,3 REVERSE(’Pero ide u sumu’) AS ’REVERSE’,4 UPPER(’Pero ide u sumu’) AS ’UPPER’,5 LOWER(’Pero ide u sumu’) AS ’LOWER’

===============================================================| LEFT | REVERSE | UPPER | LOWER |===============================================================| Pero | umus u e d i oreP | PERO IDE U SUMU | pe ro i d e u sumu |


Dio IV

Napredne mogucnosti SQL-a

83

13 Rad sa skriptama i upravljanje greskama

SQL skripta je skup naredbi spremljen u datoteku kao SQL skripta. Svaka SQLnaredba moze se smatrati SQL skriptom. U ovom poglavlju upoznat cemo se sa na-prednijim mogucnostima upotrebe SQL skripta. Skripte su cest odabir kod inicijal-nog kreiranja sheme baze podataka i punjenja baze podataka inicijalnim podacima.

13.1 Skripte, varijable i grupiranje naredbiSQL skripte su tekstualne datoteke koje imaju ekstenziju .sql. Primjer SQL skripte jeskripta za kreiranje testne baze FpzLogistika na kojoj je prikazan velik broj primjeraiz ove skripte. Ako se promotri primjer 13.1; prvi korak je provjera postoji li bazaFpzLogistika. Ako postoji baza podataka sa istim imenom ona se brise i kreira senova baza podataka istog imena. U svrhu provjere koristi se naredba EXISTS isistemska tablica sys.databases koja unutar sebe sadrzi popis svih kreiranih bazapodataka u navedenoj instanci DBMS-a. Naredbom USE FpzLogistika mijenja setrenutna baza podataka nad kojom se naredbe izvrsavaju.

Kod 13.1: Pocetak skripte za kreiranje baze FpzLogistika1 IF EXISTS(SELECT * FROM sys.databases WHERE name =

’FpzLogistika’)2 BEGIN3 DROP DATABASE FpzLogistika4 CREATE DATABASE FpzLogistika5 END6 USE FpzLogistika7 --Kreiranje sheme i punjenje podataka

Takoder, osim pisanja vlastite skripte, DBMS nudi mogucnost automatskog gene-riranja skripte putem grafickog sucelja, komandne linije ili HTML sucelja. Postupakautomatskog generiranja skripte zapocinje odabirom baze iz skupine Databases zakoju se zeli generirati skripta. Zatim se iz izbornika odabrane baze podataka odabireTasks → Generate Scripts. Automatski generirana skripta moze sadrzavati jedanod mogucih skupova podataka:(1) shema, (2) shema i podaci (3) podaci.

Osim uobicajenih SQL upita skripta moze sadrzavati deklarirane varijable. Va-rijabla je imenovana naredba unaprijed odredenog tipa u koju se moze spremati vri-jednost ili citati vrijednost iz nje. Naredba za deklariranje varijable je DECLARE,dok je naziv varijable proizvoljan uz uvjet da prvi znak mora biti @, primjerice@nazivVarijable. Primjer deklariranja varijable @ocjena prikazan je na 13.2.

Kod 13.2: Primjer deklariranje i incijaliziranja varijable1 DECLARE @ocjena int -- Deklariranje2 SET @ocjena = 5 -- Postavljanje vrijednosti3 PRINT @ocjena -- Dohvacanje sadrzaja varijable

Na primjeru 13.3 prikazano je spremanje rezultata upita u varijablu.

84

POGLAVLJE 13. RAD SA SKRIPTAMA I UPRAVLJANJE GRESKAMA

Kod 13.3: Spremanje rezultata upita u varijablu1 DECLARE @prosjek money2 SELECT @prosjek = AVG(Cijena) FROM Proizvod3 PRINT @prosjek

Niz SQL naredbi grupiranih u jednu logicku cjelinu naziva se blok naredbi (engl.batch). Unutar jedne skripte moze se nalaziti vise blokova naredbi koje se tadaodvajaju naredbom GO. Iznimka koja vrijedi za naredbu GO je da ona mora bitiu vlastitoj liniji koda. Specificnost ovakvog odvajanja skupina naredbi je da vari-jable deklarirane unutar jedne logicke cjeline nece biti vidljive niti jednoj drugojlogickoj cjelini. Primjerice, kod 13.3, ako prije ispisa vrijednosti varijable @prosjekpostavimo naredbu GO rezultat ce biti greska. Razlog je sto varijabla @prosjeknije vidljiva u drugoj logickoj cjelini. Postoji niz razloga zasto se podjela skripte ublokove naredbi koristi, a neki od njih su uzrokovani time sto se neke naredbe nemogu serijski izvrsavati. Primjerice ne moze se u istom bloku naredbi kreirati bazapodataka i koristiti ta ista baza.

Kod 13.4: Podjela skripte u logicke cijeline1 DECLARE @prosjek money2 SELECT @prosjek = AVG(Cijena) FROM Proizvod3 GO4 PRINT @prosjek

13.2 Uvjetno izvrsavanje naredbiProgramski jezik T-SQL podrzava uvjetno izvrsavanja dijela naredbi. Uvjetnoizvrsavanje je bitno jer omogucava kontrolu toka izvrsavanja SQL koda. Naredbe zauvjetno izvrsavanje koje ce biti obradene dalje u poglavlju su IF. . . ELSE, WHILEi CASE.

13.2.1 IF i IF...ELSEGrananje IF se koristi za uvjetno izvrsenje SQL naredbi. SQL naredba koja se nalaziunutar IF kljucne rijeci izvrsiti ce se samo ako je uvjet zadovoljen, tj. logicki izrazvraca vrijednost TRUE. Opcija ELSE se izvrsava kada IF uvjet nije ispunjen: logickiizraz vraca vrijednost FALSE. Tijekom koristenja grananja niz SQL naredbi se mozeformirati u grupu pomocu naredbe BEGIN . . . END(koristenje nije obvezno).

1 IF logicki_izraz2 BEGIN3 { SQL_izraz | blok_izraza }4 END5 [ ELSE6 BEGIN7 { SQL_izraz | blok_izraza }8 ELSE ]



Izraz IF...ELSE moze se ugnjezdivati te se kao takav cesto koristi. Na primjeru ??prikazan je ugnjezdeni IF...ELSE izraz unutar ELSE bloka. Ako varijabla @Numberpoprimi vrijednost redom 5, 50 i 500, rezultat izvrsavanja bloka ce biti redom: ”Brojje mali”, ”Broj je srednji” i ”Broj je veliki”.

Kod 13.5: Ugnjezdeni IF-ELSE blok1 DECLARE @Number int2 SET @Number = 503 IF @Number > 1004 BEGIN5 PRINT ’Broj je veliki.’6 END7 ELSE8 BEGIN9 BEGIN

10 IF @Number < 1011 PRINT ’Broj je mali.’12 ELSE13 PRINT ’Broj je srednji.’14 END15 END

13.2.2 WHILEWHILE petlja sadrzi logicki uvjet ponavljanja SQL izraza ili bloka. Izraz unu-tar WHILE-a ponavlja se sve dok je logicki uvjet istina. Izvrsavanje izraza unu-tar WHILE petlje moze se kontrolirati unutar petlje kljucnim rijecima BREAK iCONTINUE. Naredba BREAK uzrokuje izlazak iz petlje, a naredba CONTINUEpreskakanje uvjetovane iteracije.

Kod 13.6: Ispis prvih 100 cijelih brojeva1 DECLARE @Number int = 12 WHILE @Number < 1013 BEGIN4 PRINT @Number5 SET @Number = @Number + 16 END

Na primjeru 13.6 prikazano je koristenje WHILE petlje za ispisivanje prvih 100cijelih brojeva. While @Number ¡ 101 predstavlja logicki izraz, ako logicki izrazpoprimi vrijednost istina blok naredbi se izvrsava.

13.2.3 CASE naredbaCASE naredba unutar SQL-a je specificna jer ne sluzi za uvjetno izvrsavanje kodavec za uvjetno dohvacanje koda. Postoje dvije varijante CASE naredbe. Jednaod njih ukljucuje izraz kojim se provjerava vrijednost, dok druga nema izraza vec



svaka provjera ima svoj logicki izraz. Drugi oblik se cesce koristi u kombinaciji saSELECT-om.

Na primjeru 13.7 je prikazano kako za svaku kreditnu karticu za mjesec istekakoji je tipa int treba vratiti naziv mjeseca kada istice kartica.

Kod 13.7: Primjer upotrebe CASE naredbe1 SELECT2 Tip, Broj,3 CASE IstekMjesec4 WHEN 1 THEN ’Sijecanj’5 WHEN 2 THEN ’Veljaca’6 WHEN 3 THEN ’Ozujak’7 WHEN 4 THEN ’Travanj’8 WHEN 5 THEN ’Svibanj’9 WHEN 6 THEN ’Lipanj’

10 WHEN 7 THEN ’Srpanj’11 WHEN 8 THEN ’Kolovoz’12 WHEN 9 THEN ’Rujan’13 WHEN 10 THEN ’Listopad’14 WHEN 11 THEN ’Studeni’15 WHEN 12 THEN ’Prosinac’16 END ’Mjesec isteka’17 FROM KreditnaKartica

13.3 Upravljanje greskamaZa upravljanje greskama bitno je nekoliko sistemskih funkcija kojima DBMS pruzainformacije o nastaloj gresci:

ERROR NUMBER() - broj greske na osnovu kojega se lako pronade uzrok,

ERROR PROCEDURE() - naziv procedure ili okidaca u kojemu je doslo do greske,

ERROR LINE() - broj retka u kojemu je doslo do greske,

ERROR MESSAGE() - potpun opis greske,

ERROR STATE() - neke greske se mogu dogoditi vise puta u istom kodu, a prekoove funkcije ih se jedinstveno indentificira,

ERROR SEVERITY() - ukazuje na razinu ozbiljnosti greske.

Ozbiljnost greske koja se dohvaca sistemskom funkcijom ERROR SEVERITY()moze poprimiti jednu od 25 vrijednosti razina:

1-10 - predstavljaju informacije,

11-16 - predstavljaju korisnicke greske. Primjerice krivo napisana sintaksa upita ilipokusaj brisanja objekta koji ne postoji,



17-19 - predstavljaju softverske greske koje zahtijevaju intervenciju administratora.Primjerice nedostatak prostora na disku,

20-25 - predstavljaju fatalne greske i mogu rezultirati zatvaranjem konekcije premaaplikacijama (kvar diska).

Greske se dohvacaju blok naredbama TRY-CATCH. U TRY blok se postavljakod koji potencijalno moze izazvati gresku. Ako do greske dode izvrsava se CATCHblok u kojemu se moze saznati vise informacija o razlozima nastajanja greske. Akodo greske ne dode CATCH dio se nece izvrsiti.

Kod 13.8: Primjer TRY-CATCH bloka1 BEGIN TRY2 SELECT 5/0 --izazivanje pogreske dijeljenja sa nulom3 END TRY4 BEGIN CATCH5 SELECT6 ERROR_NUMBER(),7 ERROR_PROCEDURE(),8 ERROR_LINE(),9 ERROR_MESSAGE(),

10 ERROR_STATE(),11 ERROR_SEVERITY()12 END CATCH


14 Pogledi

Pogled (View) je pohranjen upit koji se cuva na DBMS-u kao objekt VIEW. Re-zultati upita (osim indeksiranih) nisu pohranjeni u bazi podataka vec je pohranjensamo upit koji se pozivom pogleda izvrsava. Koristenje pogleda kao izvora podatakaje jednako koristenju obicne tablice. Rezultati pogleda mogu se spajati sa drugimtablicama ili pogledima. Koristenje pogleda ima dvije glavne prednosti ispred obicneSELECT naredbe:

• Smanjuje se kompleksnost dijelova baze podataka prema korisnicima baze

• Sprjecava se dohvacanje podataka nad kojima korisniku nisu dodijeljena prava

14.1 Kreiranje jednostavnog pogledaPogled u svom najjednostavnijem obliku je jedna SELECT naredba koja ima svojnaziv. Da bi se pogled mogao kreirati treba zadovoljiti dva uvjeta: (1) svi stupciunutar SELECT upita moraju imati jedinstveni naziv, (2) SELECT upit ne smijesadrzavati ORDER BY kljucnu rijec, osim ako ne sadrzi TOP n dio. Pogled se koristikao izvor podataka kao i svaka druga tablica. Na primjerima14.1 i 14.2 prikazanoje kreiranje i dohvacanje pogleda vwKupci.

Kod 14.1: Kreiranje jednostavnog pogleda vwKupci1 CREATE VIEW vwKupci2 AS3 SELECT Ime, Prezime, RegijaId4 FROM Kupac WHERE Id < 100

Kod 14.2: Pogled kao izvor podataka1 SELECT * FROM vwKupci

Prednost koristenja pogleda ocituje se u mogucnosti spremanja slozenijih upita.Nakon kreiranja pogleda dovoljno je pogled dohvatiti kako bi se cijeli upiti izvrsio.Na primjeru 14.3 prikazano je kreiranje pogleda vwKupci koji unutar sebe sadrzislozeniji upit. Pogled vwKupci koristi tri tablice kao izvor podataka: Kupac, Regijai Drzava. Za svakoga kupca osim njegova imena i prezimena zeli se dohvatiti nazivregije i drzave iz koje kupac dolazi. SELECT naredba sastoji se od dvostrukogunutrasnjeg spajanja.

Kod 14.3: Smanjenje kompleksnosti pogledima1 CREATE VIEW vwKupci22 AS3 SELECT Ime, Prezime, r.Naziv ’Regija’, d.Naziv ’Drzava’4 FROM Kupac k5 INNER JOIN Regija r ON r.Id = k.RegijaId6 INNER JOIN Drzava d ON d.Id = r.DrzavaId7

89

POGLAVLJE 14. POGLEDI

8 SELECT * FROM vwKupci2 --Koristenje

Sigurnost informacija, tj. vidljivost informacija samo odredenoj grupi korisnikaje takoder jedna od prednosti koristenja pogleda. Primjerice place u bazi FPZLogis-tika zapisane su u tablici Zaposlenik. Ukoliko se zeli sprijeciti da itko od zaposlenikaima uvid u iznos place ostalih zaposlenika moze se kreirati pogled bez stupca placei dozvoliti zaposlenicima dohvacanje podataka samo kroz pogled, 14.4.

Kod 14.4: Skrivanje podataka pogledom1 CREATE VIEW vwZaposlenici2 AS3 SELECT Id, Ime, Prezime, Pozicija, DatumRodjenja, NadredjeniId4 FROM Zaposlenik5

6 SELECT * FROM vwZaposlenici --Koristenje

14.2 Azuriranje i brisanje pogledaPogledi se mogu azurirati koristeci naredbu ALTER. Primjer azuriranja pogledaprikazan je na 14.5.

Kod 14.5: Azuriranje pogleda vwKupci1 CREATE VIEW vwKupci2 AS3 SELECT Ime, Prezime4 FROM Kupac

Za brisanje pogleda koristi se naredba DROP. Primjer brisanja pogleda prikazanje na 14.6.

Kod 14.6: Brisanje pogleda vwKupci1 DROP VIEW vvKupci

Kod koristenja naredbe ALTER zadrzavaju se sva prava korisnicima na koristenjepogleda, a kod koristenja DROP naredbe, za brisanje pogleda, brisu se i dodije-ljena prava na obrisani pogled. Dakle ukoliko se zele sprijeciti prava korisnicima naazurirani pogled, pogled se moze obrisati, pa ponovno kreirati.

14.3 Ovisnost pogleda o shemi baze podatakaKako su pogledi dodatna apstrakcija izmedu tablica i korisnika podataka potenci-jalni problem moze nastati pri promjeni sheme nekog dijela baze podataka. Pri-mjerice pogled vvKupci povezan je sa tablicama Kupac, Regija i Drzava. U slucajupromjene dijela sheme neke od ovih tablica koje pogled referencira doci ce do po-greske. Problem je sto se pogreska javlja tek u trenutku prvog koristenja pogledanakon promjene sto znaci da pogresku uocava tek krajni korisnik. Navedeni problemse rjesava koristenjem dodatne opcije WITH SCHEMABINDING tijekom kreiranja



ili azuriranja pogleda. Kreiranjem pogleda sa navedenom opcijom uspostavljaju secvrste veze na tablice koje pogled koristi. Dakle tijekom mijenjanja tablica na kojese pogled referencira DBMS javlja gresku koja ukazuje na navedeni problem.

Na primjeru 14.7 prikazano je kreiranje pogleda sa ukljucenom dodatnom opci-jom WITH SCHEMABINDING. Tijekom koristenja navedene opcije SELECT na-redba ima sljedeca ogranicenja: (1) ne moze se koristiti * za dohvacanje svih stupacai (2) uz tablice se obavezno navodi shema (predefinirana je dbo.).

Kod 14.7: Koristenje opcije WITH SCHEMABINDING1 ALTER VIEW vwKupci2 WITH SCHEMABINDING3 AS4 SELECT Ime, Prezime, r.Naziv ’Regija’, d.Naziv ’Drzava’5 FROM dbo.Kupac k6 INNER JOIN dbo.Regija r ON r.Id = k.RegijaId7 INNER JOIN dbo.Drzava d ON d.Id = r.DrzavaId

14.4 Zastita sadrzaja pogledaSvaki kreirani pogled moze se pronaci u bazi na koju se pogled referencira. Sadrzajpogleda odnosno SELECT naredba se moze dohvatiti iz datoteke baze podatakana koju je pogled kreiran. Ukoliko se pogled zeli zastiti od navedenog pristupakod kreiranja pogleda postavlja se dodatna opcija WITH ENCRYPTION. Primjerkoristenja dodatne opcije WITH ENCRYPTION14.8.

Kod 14.8: Koristenje opcije WITH ENCRYPTION1 ALTER VIEW vwKupci22 WITH ENCRYPTION3 AS4 SELECT Ime, Prezime, r.Naziv ’Regija’, d.Naziv ’Drzava’5 FROM dbo.Kupac k6 INNER JOIN dbo.Regija r ON r.Id = k.RegijaId7 INNER JOIN dbo.Drzava d ON d.Id = r.DrzavaId

U slucaju koristenja zastite potrebno cuvati originalnu definiciju pogleda (naj-bolje u SQL skripti). Bitno je znati da se ne radi o pravoj enkripciji jer se kao kljuckoristi GUID(engl. Globally Unique Identifier) baze i ID objekta.

14.5 Manipulacija podacima kroz pogledePodatke je moguce mijenjati kroz pogled koristenjem standardnih SQL naredbi:UPDATE, DELETE i INSERT. Da bi se podaci mogli mijenjati kroz pogled morajuse postivati sljedeca pravila:

• Sve promjene INSERT, UPDATE ili DELETE naredbe moraju referenciratistupce iz samo jedne tablice,



• Referencirani stupci ne smiju nastati rezultatom podupita, agregatnih funkcijaili kombinacijom stupaca,

• Stupci koji se mijenjaju ne smiju biti dio GROUP BY, HAVING ili DISTINCTkljucnih rijeci.

Na primjeru 14.9 prikazano je dodavanje novog retka kroz pogled.

Kod 14.9: Umetanje podataka kroz pogled vwKupci1 INSERT INTO vwKupci (RegijaId, Ime, Prezime)2 VALUES(1, ’Pero’, ’Peric’)

Na primjeru 14.9 umetnut je novi redak u tablicu Kupac. Kako pogled vwKupci usebi sadrzi WHERE dio upita, primjer 14.1, novi redak iako je umetnut kroz poglednece se vidjeti kroz pogled. Kako bi se izbjegle ove situacije na pogled se postavljadodatna opcija WITH CHECK OPTION. Time se kod ubacivanja provjerava hoceli se umetnuti redak vidjeti kroz pogled, ako se redak nece vidjeti umetanje takvogretka ce biti zabranjeno.

Kod 14.10: Koristenje opcija WITH CHECK OPTION1 ALTER VIEW vwKupci2 AS3 SELECT Ime, Prezime, RegijaId4 FROM Kupac WHERE Id < 1005 WITH CHECK OPTION


15 Pohranjene procedure

Pohranjena procedura je imenovana kolekcija SQL naredbi spremljena na serveru.Naredbe spremljene unutar pohranjene procedure izvrsavaju se u jednoj jedinici rada(batch of work). Prednost pohranjenih procedura je da nije potrebno slati SQL na-redbe putem mreze vec se salje samo naziv procedure sa pripadajucim parametrima.Procedure su jedan od najbrzih nacina pristupa relacijskim bazama jer sadrze una-prijed prevedene SQL naredbe sto omogucava DBMS-u cuvanje plana izvrsavanja.Procedure se smatraju sigurnim nacinom pristupa podacima jer izvodenje proce-dure od strane korisnika podrazumijeva samo dohvat rezultata procedure. Daklepohranjena procedura se koristi po principu ”black box”. Neke od cestih upotrebaprocedura navedene su dalje u tekstu. Osim pohranjenih procedura koje kreirajukorisnici baze podataka, u SQL serveru se nalaze sistemske procedure koje imajuprefiks sp .

15.1 Osnove rada za pohranjenim proceduramaU ovom poglavlju obradena je sintaksa za kreiranje, azuriranje, brisanje i pokreta-nje procedura. Kreiranje procedure zahtjeva da naziv procedure bude jedinstvenodnosno niti jedan drugi objekt u DBMS-u ne smije imati jednak naziv. SQL sin-taksa za kreiranje procedura bez parametara je sljedeca.

1 CREATE PROC[EDURE] <naziv>2 AS3 <sql_naredbe>

Za azuriranje procedura koristi se naredba ALTER. Tijelo procedure je isto kaoi kod kreiranja procedure sa dodanim modifikacijama.

1 ALTER PROC[EDURE] <naziv>2 AS3 <sql_naredbe>

Za brisanje procedure iz DBMS-a koristi se naredba DROP i naziv procedurekoja se zeli obrisati.

1 DROP PROC[EDURE] <naziv>

Pohranjene procedure se ne mogu koristiti kao izvor podataka. Procedura seizvrsava naredbom EXEC[UTE] na jedan od dva moguca nacina: (1) prosljedivanjeparametara po redoslijedu, (2) prosljedivanje parametara po nazivu, 15.1.

Kod 15.1: Proslijedivanje parametara proceduri1 --Prosljedivanje parametara po redoslijedu (redoslijed je bitan)2 EXEC[UTE] <Naziv procedure> <vrijednost 1>, <vrijednost n>3

4 --Prosljedivanje parametara po nazivu (redoslijed nije bitan)5 EXEC [UTE] <Naziv procedure>6 @<Naziv parametra 1> = <vrijednost 1>,

93

POGLAVLJE 15. POHRANJENE PROCEDURE

7 @<Naziv parametra n> = <vrijednost n>

15.2 Vracanje vrijednosti iz procedurePomocu RETURN naredbe pohranjena procedura vraca cjelobrojnu vrijednost. Nemamogucnosti vracanja drugih tipova podataka. Najcesce se RETURN koristi kao po-vratna informacija o uspjesnom ili neuspjesnom izvrsavanju procedure. Obicno 0predstavlja uspjeh procedure (npr. INSERT ili UPDATE u proceduri), a bilo kojidrugi cijeli broj neuspjeh procedure. Nakon izvrsavanja RETURN dijela procedurazavrsava.

Kod izvrsavanja procedure moze se deklarirati lokalna varijabla koja poprimavrijednost koju procedura vraca. Na 15.2 prikazan je primjer upotrebe lokalnevarijable kod izvrsavanja procedure. Funkcija SCOPE IDENTITY() koristena uprimjeru sluzi za dohvacanje generirane vrijednosti stupca na kojemu je postavljenaIDENTITY vrijednosti.

Kod 15.2: Vracanje vrijednosti procedure u lokalnu varijablu1 --Kreiranje procedure2 CREATE PROC DodajDrzavu3 @Naziv nvarchar(50)4 AS5 INSERT INTO Drzava (Naziv) VALUES (@Naziv)6 DECLARE @Id INT = SCOPE_IDENTITY();7 RETURN @Id8

9 --Pokretanje procedure10 DECLARE @GeneriraniId INT11 EXEC @GeneriraniId = DodajDrzavu ’Spanjolska’12 PRINT @GeneriraniId

15.3 Odgodena provjera referenciKreiranjem ili azuriranjem pohranjene procedure dolazi do provjere referenci natablice prema sljedecim pravilima:

• Ako tablica postoji vrsi se provjera postojanja stupaca iz tablice koje procedurakoristi:

– Ako nema nepravilnosti prelazi se na provjeru sljedece tablice– Ako stupac ne postoji ili nema odgovarajucu definiciju, RDBMS nece

dopustiti kreiranje procedure

• Ako tablica ne postoji u bazi podataka, RDBMS prelazi u provjeru sljedecetablice:

– Provjera definicije tablice, tj. stupaca, se dogada tek prvim pozivom pro-cedure - odgodena provjera referenci.


POGLAVLJE 15. POHRANJENE PROCEDURE

15.4 Tipicno koristenje procedura - CRUD operacijeProcedure se tipicno koriste za CRUD operacije. CRUD operacije su: C - Create, R- Retrieve (SELECT), U - Update i D - Delete. Uobicajeno se kreira pet proceduraza svaku operaciju, za operaciju kreiranja, azuriranja i brisanja jedna procedurai za operaciju dohvacanja dvije procedure. U prvoj proceduri za dohvacanje sedohvacaju svi podaci, a u drugoj jedan specifican redak koji se identificira premanekom atributu. Primjer koristenja procedura na opisani nacin prikazan je na 15.3.

Kod 15.3: Koristenje procedura za CRUD operacije1 -- Dodavanje nove drzave2 CREATE PROC CreateDrzava3 @Naziv nvarchar(max)4 AS5 INSERT INTO Drzava(NazivDrzave) VALUES (@Naziv)6 GO7

8 -- Dohvacanje drzava9 CREATE PROC GetDrzava

10 AS11 SELECT * FROM Drzava12 GO13

14 -- Dohvacanje drzave15 CREATE PROC GetDrzavaById16 @Id int17 AS18 SELECT * FROM Drzava WHERE Id = @Id19 GO20

21 -- Azuriranje drzave22 CREATE PROC UpdateDrzava23 @Id int,24 @Naziv nvarchar(max)25 AS26 UPDATE Drzava SET27 NazivDrzave = @Naziv28 WHERE IDDrzava = @Id29 GO30

31 -- Brisanje drzave32 CREATE PROC DeleteDrzava33 @Id int34 AS35 DELETE Drzava WHERE Id = @Id36 GO


16 Korisnicki definirane funkcije

Korisnicki definirane funkcije (engl. User-defined functions) su objekti u bazi koji sekoriste za izvrsavanje operacija nad definiranim skupom u bazi podataka, a njihovrezultat kao izvor podataka. Tablice koje funkcije vracaju nisu stvarne tablice u bazipodataka vec privremene (engl. temporary). Takoder, mogu se koristiti dodatneopcije uspostavljanja ovisnosti sa koristenim objektima te opcija zastite funkcija.Prednosti koristenja funkcija su sljedece:

• Modularno programiranje - Promoviraju visestruko koristenje T-SQL logike uaplikaciji. Mogu se referencirati na mnogo vise lokacija u odnosu na procedure.

• Reduciranje mreznog prometa - Izvrsavanje neke logike se moze izvrsiti u samojfunkciji, a mrezom se salje samo rezultat.

• Kreiranje plana izvrsavanja - Plan izvrsavanja sprema se u memoriju kao i kodprocedura. Sto znaci da optimizator upita ne mora svaki puta kreirati planizvrsavanja vec samo prvi put.

Korisnicki definirane funkcije podijeljene su na tri vrste koje su detaljno opisanedalje u poglavlju.

16.1 Skalarne koje vracaju skalarnu vrijednostSkalarne funkcije vracaju jednu vrijednost, a primaju nula ili vise parametara. Sin-taksa za kreiranje i azuriranje funkcija je sljedeca:

1 CREATE/ALTER FUNCTION <shema>.<naziv_funkcije>2 (3 @<naziv_parametra_1> <tip_parametra_1>,4 @<naziv_parametra_n> <tip_parametra_n>5 )6 RETURNS <tip_podataka>7 AS8 BEGIN9 <niz_naredbi>

10 RETURN <vrijednost>11 END

Kod koristenja skalarnih funkcija obavezno je navesti shemu (primjerice dbo.MojaFunkcija).Skalarne funkcije mogu se koristiti na dva nacina:

1. Samostalno1 DECLARE @<varijabla> <tip_varijable>2 SET @<varijabla> = <shema>.<naziv_funkcije>(<parametri>)

2. Unutar SELECT naredbe1 SELECT <shema>.<naziv_funkcije>(<parametri>)2 FROM <tablica>

96

POGLAVLJE 16. KORISNICKI DEFINIRANE FUNKCIJE

Kod koristenja funkcija unutar SELECT naredbe potrebno je uzeti u obzirnarusavanje performansi jer se funkcija poziva za svaki redak posebno.

16.2 Jednostavne funkcije koje vracaju tablicuJednostavne funkcije su podskup korisnicki definiranih funkcija koje vracaju tablicukao podatkovni tip. Koriste se kao izvori podataka. Sintaksa za kreiranje i azuriranjeje sljedeca:

1 CREATE/ALTER FUNCTION <shema>.<naziv_funkcije>2 (3 @<naziv_parametra_1> <tip_parametra_1>,4 @<naziv_parametra_n> <tip_parametra_n>5 )6 RETURNS TABLE7 AS8 RETURN <select_upit>

Jednostavne funkcije se koriste kao izvori podataka (koristi se u FROM dijeluSELECT upita). Kod poziva funkcije nije obavezno navesti shemu.

1 SELECT * FROM <shema>.<naziv_funkcije>(<parametri>)

16.3 Slozene funkcije koje vracaju tablicuSlozene funkcije za razliku od jednostavnih funkcija mogu sadrzavati proizvoljanbroj SQL naredbi. Sintaksa za kreiranje i azuriranje slozenih funkcija je sljedeca:

1 CREATE/ALTER FUNCTION <shema>.<naziv_funkcije>2 (3 @<naziv_parametra_1> <tip_parametra_1>,4 @<naziv_parametra_n> <tip_parametra_n>5 )6 RETURNS @<naziv_tablice> TABLE7 (8 <naziv_stupca_1> <tip_stupca_1>,9 <naziv_stupca_n> <tip_stupca_n>

10 )11 AS12 BEGIN13 <niz_naredbi>14 RETURN15 END

Slozene funkcije koriste se kao izvori podataka:1 SELECT *2 FROM <shema>.<naziv_funkcije>(<parametri>) AS ’F’3 INNER JOIN ...


POGLAVLJE 16. KORISNICKI DEFINIRANE FUNKCIJE

Slozene funkcije mogu se koristiti kao tablice u svim segmentima, primjericespajanje, izdvajanje atributa i dr. Ovo je veoma mocna alternativa snimljenimprocedurama. Mogu imati istu poslovnu logiku u svom tijelu s tim da se mogukoristiti kao izvori podataka.

16.4 Brisanje funkcijaSintaksa za brisanje svih vrsta funkcija je jednaka:

1 DROP FUNCTION <shema>.<naziv_funkcije>


17 Okidaci

Okidaci(engl. triggers) su posebna vrsta procedura te s procedurama dijele jednakekarakteristike. Svaki okidac je vezan uz jednu tablicu ili pogled. Ne poziva ihkorisnik vec RDBMS kao reakciju definirane dogadaje. Dogadaj (akcija) uzrokujepozivanje okidaca (reakcija). Postoje dvije vrste okidaca:

• DDL okidaci (engl. Dana Definition Language triggers) – Reakcija na izmjenustrukture baze - rjede se koriste i necemo ih proucavati

• DML okidaci (engl. Dana Modification Language triggers) – Reakcija na pro-mjenu podataka– cesce se koriste

Ova skripta razmatra samo DML okidace koji se dijele na dvije podvrste:

• INSTEAD OF – izvrsavaju se umjesto pokretacke naredbe

• AFTER - izvrsavaju se nakon pokretacke naredbe

Okidaci koji se obraduju u ovom poglavlju mogu se definirati kao posebna vrstapohranjenih procedura koje se izvrsavaju automatski kada se nad tablicom izvrsiUPDATE, INSERT ili DELETE naredba.

17.1 T-SQL naredbe za rad sa okidacimaSintaksa za kreiranja i azuriranje okidaca je sljedeca:

1 CREATE/ALTER TRIGGER <shema tablice>.<naziv_okidaca>2 ON <tablica>3 AFTER {[INSERT][,][UPDATE][,][DELETE]}4 AS5 <niz_naredbi>

Moze se koristiti bilo koja kombinacija INSERT, UPDATE i DELETE dogadaja.Shema okidaca uvijek mora odgovarati shemi tablice na koju se okidac postavlja.Umjesto AFTER moze se koristiti FOR (sinonimi).

Naredba za brisanje okidaca je:1 DROP TRIGGER <naziv_okidaca>

17.2 Specijalne tablice i ispitivanje vrste dogadajaUnutar okidaca postoje dvije specijalne vrste tablica: (1) tablica INSERTED kojasadrzi kopije redaka koji su umetnuti i (2) tablica DELETED – koja sadrzi kopijeredaka koji su obrisani. Postojanje navedenih tablica omogucava ispitivanje koji sedogadaj dogodio. Naredbama EXISTS i NOT EXISTS moze se ispitati postojanjeretka u jednoj od ili obje tablice. Tri su jednostavna pravila kojima je definiranokoji se dogadaj dogodio:

99

POGLAVLJE 17. OKIDACI

• INSERT dogadaj - ako postoje redci u tablici INSERTED, a ne postoje utablici DELETED

• DELETE dogadaj - ako ne postoje redci u tablici INSERTED, a postoje utablici DELETED

• UPDATE dogadaj – ako postoje redci u tablici INSERTED i u tablici DELE-TED

Na 17.1 je prikazan primjer ispitivanja koji se dogadaj dogodio te ovisno o vrstidogadaja zapisivanje odgovarajuce poruke u tablicu Zapisnik.

Kod 17.1: Koristenje okidaca1 CREATE TRIGGER OkiDoki ON Drzava2 AFTER INSERT, UPDATE, DELETE3 AS4

5 IF EXISTS(SELECT * FROM inserted) AND6 NOT EXISTS(SELECT * FROM deleted)7 BEGIN8 INSERT INTO Zapisnik (Zapis)9 VALUES (’Dogodio se INSERT.’)

10 END11

12 ELSE IF NOT EXISTS(SELECT * FROM inserted) AND13 EXISTS(SELECT * FROM deleted)14 BEGIN15 INSERT INTO Zapisnik (Zapis)16 VALUES (’Dogodio se DELETE.’)17 END18

19 ELSE IF EXISTS(SELECT * FROM inserted) AND20 EXISTS(SELECT * FROM deleted)21 BEGIN22 INSERT INTO Zapisnik (Zapis)23 VALUES (’Dogodio se UPDATE.’)24 END25 GO

17.3 Detekcija promjenjenog stupcaOsim detekcije koji dogadaj se dogodio ponekad je potrebno detektirati koji atributje izmijenjen. Kod aktivirajucih dogadaja umetanja i brisanja mijenjaju se svi redci,pa nije potrebno ispitivati koji je stupac promijenjen. Kod aktivirajuceg dogadajaazuriranja moze se promijeniti jedan ili vise stupaca. DBMS sadrzi sistemsku funk-ciju UPDATE() koja kao parametar prima naziv stupca te vraca TRUE – ako jestupac promijenjen ili FALSE – ako stupac nije promijenjen. Primjer detekcije kojistupac je promijenjen prikazan je na 17.2:


POGLAVLJE 17. OKIDACI

Kod 17.2: Ispitivanje promijene stupca1 CREATE TRIGGER OkiDoki ON Drzava AFTER UPDATE2 AS3 IF UPDATE(IDDrzava)4 BEGIN5 PRINT ’Promijenjen je stupac IDDrzava.’6 END7 IF UPDATE(Naziv)8 BEGIN9 PRINT ’Promijenjen je stupac Naziv.’

10 END11 GO

17.4 Ukljucivanje i iskljucivanje okidacaUkljuceni okidaci se pozivaju od strane RDBMS kao reakcija na dogadaje. Iskljuceniokidaci se ne pozivaju, tj. dobije se efekt kao da nisu niti kreirani. Iskljucivanjeokidaca se obicno radi pri umetanju vecih kolicina podataka u tablicu. Naredbe zaiskljucivanje/ukljucivanje okidaca su:

1 DISABLE TRIGGER <naziv_okidaca> ON <tablica>2 ENABLE TRIGGER <naziv okidaca> ON <tablica>

17.5 Redoslijed postavljanja okidacaNa tablici moze postajati vise okidaca koji su pretplaceni na isti pokretacki dogadaj.Kada se dogadaj pojavi DBMS ce pozvati sve okidace jednakim redoslijedom kojimsu kreirani. Na redoslijed izvrsavanja okidaca se moze utjecati na nacin da se postavikoji ce se okidac izvrsiti prvi, a koji posljednji. Na redoslijed izvrsavanja ostalihokidaca se ne moze utjecati.

1 EXEC sp_settriggerorder2 @triggername = ’<Naziv okidaca>’,3 @order = ’FIRST | LAST | NONE’,4 @stmttype = ’INSERT | UPDATE | DELETE’


18 Kursori

Kursori su objekti u bazi podataka koji omogucuju manipulaciju podacima u tabliciili rezultatom upita redak po redak. Prije uporabe kursor se mora deklarirati iotvoriti, a nakon sto se zavrse operacije nad kursorom potrebno ga je zatvoritii osloboditi resurse. Kursori su najsporiji nacin pristupa podacima unutar SQLServera, pa se koriste kada je zbilja potreban iterativan pristup redcima iz skupapodataka. Kada je god moguce treba izbjeci koristenje kursora i koristiti operacijenad skupovima podataka jer je za takav pristup baza podataka optimizirana. Kursorse deklarira naredbom DECLARE. Sintaksa je sljedeca:

1 DECLARE ime_kursora [ INSENSITIVE ] [ SCROLL ] CURSOR2 FOR select_naredba3 [ FOR { READ ONLY | UPDATE [ OF ime_stupca [ ,...n ] ] } ]

Kod kreiranja kursora mogu se koristiti sljedece opcije:

• INSENSITIVE - kursor kreira privremenu kopiju rezultata upita tako da pro-mjene nastale tijekom koristenja kursora nece biti vidljive, a osim toga kursorse ne moze azurirati

• SCROLL - moguce su sve opcije dohvata redaka (FIRST, LAST, PRIOR,NEXT, RELATIVE, ABSOLUTE). U slucaju da opcija nije navedena moguceje samo dohvatiti svaki slijedeci redak (NEXT)

• FOR READ ONLY - kursor ne moze biti azuriran

• FOR UPDATE OF ime stupca [,...n] - moguce je azurirati samo navedeneatribute. Ako je UPDATE naveden bez liste atributa moguce je azurirati sveatribute.

Cesto koristen oblik kreiranja kursora je:1 DECLARE <ime_kursora> CURSOR FOR <select upit>

Kursor se otvara pomocu naredbe OPEN, a zatvara naredbom CLOSE. Nakonzatvaranja kursora naredbom DEALLOCATE se oslobadaju resursi te se omogucavada kursor bude ponovo deklariran. Primjer kreiranja kursora, otvaranja, zatvaranjeveze prema njemu te otpustanje resursa prikazan je na 18.1.

Kod 18.1: Osnovno koristenje kursora1 DECLARE cur CURSOR2 FOR SELECT Ime FROM Kupac3 OPEN cur -- Otvaranje veze4 CLOSE cur -- Zatvaranje veze5 DEALLOCATE cur -- Otpustanje resursa

102

POGLAVLJE 18. KURSORI

18.1 Dohvacanje zapisa preko kursoraZapise iz kursora dohvaca se pomocu naredbe FETCH koja ima sljedecu sintaksu:

1 FETCH2 [ [ NEXT | PRIOR | FIRST | LAST|3 ABSOLUTE { n | @nvar } | RELATIVE { n | @nvar }]4 FROM ] {cursor_name }5 [ INTO @variable_name [ ,...n ]]

Cesto koristeni oblik naredbe je:1 FETCH NEXT FROM <naziv_kursora> INTO <varijable>

Popis varijabli mora odgovarati atributima upita nad kojim je kursor deklariran.Naredba FETCH se ne moze koristiti nakon zatvaranja kursora. Primjer dohvacanjaprvog retka iz kursora deklariranog na primjeru 18.1 prikazan je na 18.2.

Kod 18.2: Koristenje naredbe FETCH1 DECLARE @id int2 FETCH NEXT FROM cur INTO @id

Na primjeru 18.3 prikazan je postupak kreiranja kursora koji dohvaca sve kupcekojima se ne zna broj telefona. Nakon kreiranja kursora dohvacaju se i ispisujuimena prva dva retka pomocu kursora.

Kod 18.3: Deklariranje i koristenje kursora za dohvacanje zapisa1 DECLARE cur CURSOR FOR2 SELECT IDKupac, Ime FROM Kupac WHERE Telefon IS NULL3 OPEN cur4 DECLARE @IDKupac INT, @Ime NVARCHAR(50)5 FETCH NEXT FROM cur INTO @IDKupac, @Ime6 PRINT @Ime7 FETCH NEXT FROM cur INTO @IDKupac, @Ime8 PRINT @Ime9 CLOSE cur

10 DEALLOCATE cur

Na primjeru 18.4 je prikazano kreiranje kursora za upit iz proslog zadatka ko-risteci opciju SCROLL, te ispis definiranog atributa za zadnji i predzadnji redak.

Kod 18.4: Koristenje opcije SCROLL1 DECLARE cur SCROLL CURSOR FOR2 SELECT IDKupac, Ime FROM Kupac WHERE Telefon IS NULL3 OPEN cur4 DECLARE @IDKupac INT, @Ime NVARCHAR(50)5 FETCH LAST FROM cur INTO @IDKupac, @Ime6 PRINT @Ime7 FETCH PRIOR FROM cur INTO @IDKupac, @Ime8 PRINT @Ime9 CLOSE cur



10 DEALLOCATE cur

Koristeci kursore moguce je takoder dohvacati n-ti redak iz dohvacenog skupapodataka. Na primjeru 18.5 je prikazano kreiranja kursora za proizvode kojima jecijena veca od 100. Dohvacaju se samo atributi ID, naziv i boja, te se redci sortirajupo nazivu. Iz dohvacenog skupa podataka ispisuje se treci redak te redci koji senalaze prije i nakon treceg retka.

Kod 18.5: Koristenje opcije ABSOLUTE i RELATIVE1 DECLARE cur SCROLL CURSOR FOR2 SELECT IDProizvod, Naziv, Boja FROM Proizvod3 WHERE CijenaBezPDV > 1004 ORDER BY Naziv5 OPEN cur6 DECLARE @IDProizvod int, @Naziv nvarchar(50), @Boja nvarchar(15)7

8 FETCH ABSOLUTE 3 FROM cur INTO @IDProizvod, @Naziv, @Boja9 PRINT CAST(@IDProizvod AS varchar) + ’ ’ + @Naziv + ’ ’ +

CAST(@Boja AS varchar)10

11 FETCH RELATIVE -1 FROM cur INTO @IDProizvod, @Naziv, @Boja12 PRINT CAST(@IDProizvod AS varchar) + ’ ’ + @Naziv + ’ ’ +


14 FETCH RELATIVE 2 FROM cur INTO @IDProizvod, @Naziv, @Boja15 PRINT CAST(@IDProizvod AS varchar) + ’ ’ + @Naziv + ’ ’ +


17 CLOSE cur18 DEALLOCATE cur

18.2 Status kursoraStatus kursora ukljucuje informaciju o trenutnom broju zapisa u kursoru i us-pjesnosti prethodne operacije unutar kursora. Koristeci sistemske funkcije moguceje provjeriti statusa kursora. Funkcije ugradene u T-SQL jezik mogu se pronaci kli-kom na mapu Programmibility → Functions → System Functions. Unutar popisafunkcija nalaze se i sistemske varijable koje zapocinju sa @@.

• Za provjeru broja redaka u kursoru koristi se sistemska varijabla @@CUR-SOR ROWS koja vraca broj zapisa u zadnjem otvorenom kursoru ako je kursordeklariran sa opcijom INSENSITIVE ili SCROLL.

• Za provjeru rezultata zadnje FETCH operacije koristi se sistemska varija-bla @@FETCH STATUS. Vrijednosti koje moze imati su (0 – operacija us-pjesna, -1 – operacija neuspjesna, -2 – redak koji se dohvatio nedostaje). Dabi resetirali varijablu nakon otvaranja kursora potrebno je pozvati naredbu



FETCH NEXT koja ce dohvatiti prvi zapis i postaviti vrijednost varijable@@FETCH STATUS na 0.

Navedene varijable se obicno koriste u uvjetu petlje za prolazak kroz sve zapise.Na primjerima 18.6 i 18.7 prikazano je koristenje sistemskih varijabli u petlji kojomse ispisuju dohvaceni podaci kroz kursor. Kursor dohvaca sve kupce (IdKupac, Ime,Prezime) cije ime pocinje sa nekim iz slova u rasponu od a-c.

Kod 18.6: Koristenje sistemske varijable @@CURSORROWS

1 DECLARE cur INSENSITIVE CURSOR FOR2 SELECT IDKupac, Ime, Prezime FROM Kupac WHERE Ime LIKE

’[a-c]%’3 OPEN cur4 DECLARE @brojac INT, @IDKupac INT, @Ime NVARCHAR(50), @Prezime

NVARCHAR(50)5 SET @brojac = 16

7 WHILE @brojac <= @@CURSOR_ROWS8 BEGIN9 FETCH NEXT FROM cur INTO @IDKupac, @Ime,

@Prezime10 PRINT CAST(@IDKupac AS varchar) + ’, ’ + @Ime +

’, ’ + @Prezime11 SET @brojac = @brojac + 112 END13 CLOSE cur14 DEALLOCATE cur

Kod 18.7: Koristenje sistemske varijable @@FETCHSTATUS

1 DECLARE cur INSENSITIVE CURSOR FOR2 SELECT IDKupac, Ime, Prezime FROM Kupac WHERE Ime LIKE

’[a-c]%’3 OPEN cur4 DECLARE @brojac INT, @IDKupac INT, @Ime NVARCHAR(50), @Prezime

NVARCHAR(50)5 SET @brojac = 16

7 FETCH NEXT FROM cur INTO @IDKupac, @Ime, @Prezime8 WHILE @@FETCH_STATUS = 09 BEGIN

10 PRINT CAST(@IDKupac AS varchar) + ’, ’ + @Ime +’, ’ + @Prezime

11 FETCH NEXT FROM cur INTO @IDKupac, @Ime,@Prezime

12 END


POGLAVLJE 18. TRANSAKCIJE

18.3 Azuriranje podataka kursorimaUkoliko se prilikom deklaracije kursora upotrijebi opcija UPDATE moguce je azuriratitablicu pomocu naredbe SQL UPDATE koristeci uvjet CURRENT OF ¡ime kursora¿u WHERE dijelu. Primjer kursora koji ce u tablici Kupci postaviti vrijednost atri-buta Telefon na ”-” svim kupcima koji jos nemaju unesen telefon prikazan je na18.8.

Kod 18.8: Azuriranje podataka kursorom1 DECLARE cur CURSOR FOR2 SELECT IDKupac, Telefon FROM Kupac3 WHERE Telefon IS NULL4 FOR UPDATE OF Telefon5 OPEN cur6 DECLARE @IDKupac int, @Telefon nvarchar(25)7 FETCH NEXT FROM cur INTO @IDKupac, @Telefon8 WHILE @@FETCH_STATUS = 09 BEGIN

10 IF @Telefon IS NULL11 BEGIN12 UPDATE Kupac SET Telefon = ’-’13 WHERE CURRENT OF cur14 END15 FETCH NEXT FROM cur INTO @IDKupac, @Telefon16 END17

18 CLOSE cur19 DEALLOCATE cur


19 Transakcije

Transakcija predstavlja nedjeljivu logicku cjelinu operacija na podacima. Zadataktransakcija je bazu podataka ostaviti u konzistentnom stanju. Dok se transak-cija izvrsava baza podataka je najcesce privremeno u nekonzistentnom stanju, alizavrsetkom transakcije bilo da se radi o odustajanju ili potvrdi naredbi baza poda-taka mora ostati u konzistentnom stanju. Kako bi bilo moguce izvoditi transakcijepotrebno je podatke nad kojima se izvode njezine naredbe odvojiti od drugih ko-risnika. Odvajanje se vrsi zakljucavanjem, pa vrijedi pravilo sto se manja skupinapodataka zakljuca mogucnost paralelizma je veca, ali je i izvedba slozenija.

19.1 Svojstva transakcijaTransakcije u svim RDBMS posjeduju cetiri svojstva: atomarnost, konzistenciju,izolaciju, trajnost. Ako uzmemo prva slova ovih svojstava na engleskom jezikudobiva se kratica ACID. ACID svojstva transakciji osiguravaju integritet podatakanakon izvrsenja transakcije.

19.1.1 AtomarnostAtomarnost (eng. Atomicity) je svojstvo da promjene u bazi podataka postujupravilo ”sve ili nista”. Ovo svojstvo transakciji omogucuje da ona funkcionira kaopojedinacna neraskidiva jedinica. Cesto dolazi do potrebe da se manipulira sa skupo-vima podataka koji se medusobno ovisni, te se ne smije samo dio podataka spremitiili obrisati iz baze. Kada je transakcija atomarna, ne postoji mogucnost djelomicnoodradene transakcije, tj. djelomicnog spremanja ili brisanja skupa podataka.

19.1.2 KonzistentnostKonzistentnost (eng. Consistency) je svojstvo koje jamci da su kod baze podatakau konzistentnom stanju primijenjena sva pravila i ogranicenja, primjerice primarni istrani kljucevi. Transakcija mora bazu podataka nakon svog zavrsavanja bez obziraradi li se o odustajanju ili potvrdivanju transakcije ostaviti u konzistentnom stanju.Nakon pokretanja transakcije baza podataka moze biti privremeno u nekonzistent-nom stanju, ali njezinim zavrsetkom mora se vratiti u konzistentno stanje.

19.1.3 IzolacijaIzolacija (eng. Isolation) zahtijeva da transakcije paralelno pokrenute ne utjecujedna na drugu tijekom izvrsavanja. Izolacija omogucava da transakcija nakon stoje pokrenuta ne dopusta citanje medustanja podataka, koja ona mijenja, dok se onane potvrdi ili odustane od izmjena. Ovo je jako bitna karakteristika transakcija, daje nema bilo bi moguce da neka transakcija mijenja podatke,odustane od izmjena,a u meduvremenu je neka druga transakcija ocitala privremene podatke. Ovim

107


svojstvom transakcija se osigurava da je stanje baze podataka jednako stanju kojebi nastalo da se transakcije izvrsavaju jedna iza druge.

19.1.4 TrajnostTrajnost (eng. Durability) je svojstvo koje osigurava da promijene koje transak-cija uzrokuje ostanu trajno zapisane u bazi podataka nakon potvrde transakcije.U slucaju pada sustava, nestanka elektricne energije i sl. podatak ce ostati ne-promijenjen u bazi jer je transakcija vec potvrdena. U slucaju da se dogodi ispadelektricne mreze za vrijeme trajanja transakcije, kod oporavka sustava ponistiti cese dotadasnji rad transakcije i baza ce ostati u konzistentnom stanju.

19.2 Koristenje transakcijaSvaka transakcija bez obzira na vrstu se obavezno sastoji od sljedeca dva elementa:

• pocetka transakcije

• zavrsetaka transakcije koji moze oznacavati

– potvrdu transakcije - sve naredbe koje transakcija sadrzi uspjesno izvrsene,– odustajanje od transakcije - doslo je do najmanje jedne greske u izvrsavanju

transakcije, pa bazu podataka moramo vratiti u onakvo stanje kakvo jebilo prije zapocinjanja transakcije.

Primjer naredbi pocetka(BEGIN), potvrde(COMMIT) i odustajanja(ROLLBACK)od transakcije:

1 BEGIN TRAN[SACTION] [<NazivTransakcije>]2 COMMIT TRAN[SACTION] [<NazivTransakcije>]3 ROLLBACK TRAN[SACTION] [<NazivTransakcije>]

Kod transakcija postoji mogucnost postavljanja kontrolne tocke (eng. savepoint)koja je opcionalna. Postavljanje se izvrsava pomocu sljedecih naredbi:

1 SAVE TRAN[SACTION] <NazivKontrolneTocke>2 ROLLBACK TRAN[SACTION] <NazivKontrolneTocke>

Transakcija prikazana na Slici 19.1) ima postavljene kontrolne tocke. Nakonizvrsavanja transakcije u bazi ce biti spremljene promjene koje su napravile naredbe1 i 3. Promijene koje su napravljene izvrsavanjem naredbe 2 su ponistene. Te pro-mjene su ponistene zbog odustajanja od transakcije (ROLLBACK TRAN t1) nakonizvrsavanja naredbe 2. Zbog postavljene kontrolne tocke nije doslo do ponistavanjaizmjena naredbe 1 jer se odustajanjem vratilo stanje baze koje je bilo u posljednjojkontrolnoj tocki (SAVE TRAN t1).



Slika 19.1: Primjer kreiranja kontrolne tocke

19.2.1 Ugnjezdivanje transakcijaEksplicitne transakcije se mogu ugnijezditi. Kada dode do situacije kada u jednojtransakciji pozovemo drugu transakciju dolazi do ugnjezdivanja. Prva pozvana tran-sakcija se naziva vanjska, ostale pozvane transakcije unutar prve su unutrasnje. Zaupravljanje transakcijama tokom ugnjezdivanja bitna je sistemska funkcija @@TRAN-COUNT. Vrijednost funkcije se povecava za 1 nakon svake pokrenute transakcije(BEGIN TRAN). Svaka potvrda transakcije smanjuje vrijednost funkciji (COM-MIT TRAN).

19.2.2 Upravljanje transakcijamaUpravljati transakcijama se moze unutar SQL koda ili iz aplikacije. Kod upravljanjatransakcijama iz SQL koda moze doci do problema kada se mnogo transakcija ugni-jezdi. Do toga dolazi jer se u vecim sustavima koriste procedure koje pozivaju drugeprocedure zbog prosirenog misljenja kako je ponovnog koristenja koda (eng. reusecode) uvijek dobro. Upravljanje transakcijama unutar SQL moguce je na nekolikonacina:

• Unutar procedure - upravljanje transakcijama unutar procedure znaci da onasama pokrece transakciju te potvrduje ili odustaje od transakcije.

• Izvan procedure - procedura nema veze sa transakcijama ona je samo ug-nijezdena unutar transakcije koja je pokrenuta izvan nje.

• Unutar i izvan procedure -osim sto procedura unutar sebe pokrece transakcijui izvan nje je pokrenuta transakcija koja je omotava.

Mogucnosti upravljanja transakcijama iz aplikacije su iste kao iz SQL koda. Nasljedecem primjeru je prikazano upravljanje transakcijama iz aplikacije (slika 19.2).Izveden je na primjeru ubacivanja jednog retka u tablicu Kupac (definirana u 19.4.5.poglavlju).

19.3 Vrste transakcijaPostoji nekoliko vrsta transakcija iako se pri spomenu rijeci transakcija u vecinislucajeva misli na eksplicitne. Vrste transakcija su detaljno opisane dalje u poglavlju



Slika 19.2: Upravljanje transakcijama iz aplikacije

19.3.1 AutomatskeAutomatske (eng. Autocommit) - svaka naredba (INSERT, UPDATE, DELETEitd.) je zapravo transakcija sto se vidi u dnevniku transakcija. NJihov naziv jeautomatske transakcije jer se same potvrduju.

19.3.2 EksplicitneEksplicitne (eng. Explicit) transakcije - svaka transakcija pocinje nakon naredbeBEGIN TRANSACTION i traje do eksplicitne definicije zavrsetka (COMMIT iliROLLBACK).

19.3.3 Batch-scoped transakcijeBatch-scoped transakcije - primjenjive su kod visestruko aktivnih rezultirajucih sku-pova - MARS (engl. Multiple Active Result Sets). Kako bi se sacuvao integritetpodataka tijekom konekcije dozvoljeno je koristenje samo jednog kursora. MARSomogucava koristenje vise kursora u jednoj konekciji. Ako neka implicitna ili eks-plicitna transakcija pocinje u MARS sesiji naziva se Batch-scoped transakcija.

19.3.4 ImplicitneImplicitne (eng. Implicit) transakcije - implicitne transakcije ne zapocinju nared-bom BEGIN vec one zapocinju prvom naredbom u konekciji u kojoj su ukljucene



implicitne transakcije. SQL Server ima mogucnost ukljucivanja i iskljucivanja im-plicitnih transakcija dok neki RDBMS-ovi ne podrzavaju ovaj tip transakcija. Upocetnim postavkama one su iskljucene, a ukljucuje ih se naredbom:

1 SET IMPLICIT_TRANSACTIONS ON

Na slici 19.3 prikazana je upotreba implicitne transakcije. Kod zatvaranja konek-cije SQL Server trazi potvrdu zeli li se potvrditi transakcija. Potvrdnim odgovorompotvrduju se sve naredbe koje su se izvrsile u implicitnoj transakciji, negativnimodgovorom odustaje se od svih naredbi.

Slika 19.3: Implicitne transakcije

Implicitne transakcije se mogu iskoristiti kod osjetljivih promjena na bazi, tese njihov ucinak u slucaju nepredvidene greske moze ponistiti. Koristenjem visepokrenutih implicitnih transakcija istovremeno degradiraju se performanse, te setime unistava konkurentnost baze podataka.

19.3.5 Distribuirane transakcijeDistribuirane transakcije se koriste na distribuiranim sustavima. Distribuirani sus-tav ima vise dijelova baze podataka na razlicitim serverima koji su razmjesteni nalokacijski udaljenim mjestima i povezana su mrezom. Zapravo distribuirana tran-sakcija ima ACID svojstva te nalikuje na ugnijezdenu transakciju. Za sinkroniza-ciju se koristi two-phase commit algoritam koji se sastoji od dvije faze, pripreme iizvrsavanja. Svaki lokalni server ima svog transakcijskog menadzera - DTC (engl.Distibuted Transaction Coordinator), onaj koji inicira transakciju naziva se globalnikoordinator. Globalni koordinator kod inicijalizacije salje serverima inicijalnu po-ruku, zatim provjerava njihovu raspolozivost, a na kraju prve faze svakoj lokalnojinstanci dodijeljuje poslove koje ona mora izvrsiti. Nakon sto globalni koordina-tor prikupi sve poruke o mogucnosti izvrsavanja transakcija na lokalnim serverimaprelazi se u drugu fazu. U drugoj fazi krece izvrsavanje transakcija. Globalni koor-dinator ceka poruke od lokalnih servera o izvrsavanju transakcija koje im pripadaju.Ukoliko samo jedna lokalna instanca ne izvrsi transakciju odustaje se od svih tran-sakcija. Ukoliko svi lokalni serveri potvrde svoje transakcije, globalni koordinator



salje COMMIT naredbu za istovremenu potvrdu svih transakcija. Na slici 19.4 pri-kazan je distribuirani sustav koji koristi dvije lokalne instance. Osnovni nedostatak

Slika 19.4: Distribuirane transakcije

distribuiranih transakcija je sinkronizacija lokalnih instanci. Naime, ako samo jednainstanca otkaze razmjena podataka ce biti nemoguca zbog nemogucnosti potvrdesvih transakcija.

19.4 Izolacijski nivoi i zakljucavanjaPostavljanje izolacijskih nivoa i zakljucavanje resursa jedna su od tehnike kontrolekonkurentnosti i medusobno su ovisni. O vrsti postavljenog nivoa ovisi koji ce selokoti postaviti na odredeni resurs, te kolika ce biti izoliranost medu transakcijama.

19.4.1 Zakljucavanje resursa i eskalacija zakljucavanjaZakljucavanje resursa jedna je od najbitnijih stvari koja omogucuje visekorisnickuupotrebu baze. Bitno je znati da se SQL Server automatski brine o zakljucavanjima.Za to je zaduzen Lock manager koji generira dogadaje zakljucavanja i upravlja pos-tavljanjima zakljucavanja. Postoje nivoi zakljucavanja resursa koji su prikazani utablici 19.1.

Lock manager se vodi filozofijom bolje zakljucati jedan redak nego cijelu tablicu.Prvo postavlja najmanju granulaciju, jer je to najbolje po performanse i omogucujeda vise korisnika pristupa bazi podataka. Smanjenje granulacije se dogada po po-trebi te kada dode do maksimalno potrebnog resursa podaci se otpustaju. Ovajnacin rada je poznat pod nazivom eskalacija zakljucavanja. Prvi zakljucani poda-tak biti ce zadnji otpusten. Tako je u svim slucajevima osim u slucaju nastajanjapotpunog zastoja. Na slici 19.5 je prikazana arhitektura Lock managera. Iako jeLock menager optimiziran kako bi se postigle najbolje performanse i sigurnost, pos-toji mogucnost preopterecenja (engl. Override) sheme zakljucavanja. Na primjerNOLOCK naredbu (koja nesmetano cita podatke bez obzira na zakljucavanje) bibilo dobro koristiti kod upita na podatke koji su staticni, a nikako kod aplikacijakoje koriste podatke kako bi ih mijenjali. SQL Server ima dvije kategorije naredbi zakontrolu zakljucavanja i samo jedna iz pojedine grupe moze biti koristena u jednomupitu:



Tablica 19.1: Nivoi zakljucavanja resursa

RESURS OPISBaza podataka Zakljucavanje cijele baze podataka

Alocirana jedinica Zakljucavanje kolekcije stranica koje sadrzeodredeni tip podataka

Metadata Zakljucavanje podataka u sistemskom kataloguDatoteka Zakljucavanje citave datoteke baze podataka. Od-

nosi se na podatkovnu datoteku ili dnevnik tran-sakcija

Objekt Zakljucavanje cijele tablice, procedure ukljucujucisve indekse i podatke. Osim gore navedenih objektmoze biti bilo sto, sto se nalazi u sys.all objects.

B-stablo ili Hrpa Zakljucavanje indeksnih stranica (B-stablo) za ta-blice s klasteriranim indeksom ili podatkovnihstranica (hrpa) za tablice s neklasteriranim indek-som. Ovaj resurs se u SQL Serveru oznacava kra-ticom HOBT.

Grozd Zakljucavanje osam susjednih stranicaStranica Zakljucavanje jedne stranice koja sadrzi 8 KB

Kljuc Zakljucavanje kljuca ili raspona kljuceva na in-deksu

Redak Zakljucavanje jednoga reda unutar tablice.Oznacava se kraticom RID

• Granulacijski:

– PAGLOCK - zahtjeva da se postave lokoti na stranice tamo gdje bi seinace postavljali na nivou tablice

– NOLOCK - zahtjeva da niti jedan lokot ne bude zahtjevan ni definiran– ROWLOCK - zahtjeva da lokoti budu postavljeni na nivo retka i nikako

drugacije– TABLOCK - zahtjeva postavljane lokota na cijelu stranicu umjesto pos-

tavljanja lokota na stranicu ili redak

• Izolacijski:

– HOLDLOCK i SERIALIZABLE - zahtjeva da zakljucavanje bude tokomcijele transakcije,

– READCOMMITTED,– READ UNCOMMITTED,– READ REPEATABLEREAD



Slika 19.5: Arhitektuta Lock managera

19.4.2 Vrste lokotaLokoti su nesto sto nema fizicku opipljivost, znaci da se ne spremaju na disk nikadavec koriste dio radne memorije predvidene za rad SQL Servera. Jedan lokot pred-stavlja dio memorije od 64 ili 128 bitova ovisno o sustavu na kojem je SQL Serverpokrenut. U bloku memorije koji se naziva lock block mora biti zapisano koji resursse zakljucava (tablica, redak, stranica...) i koji je tip lokota postavljen. Osim ovogbloka postoji i lock owner block koji je iste velicine i govori nam tko drzi lokot.Vlasnik lokota je jedna konekcija, a to je najcesce transakcija. Moguca je situacijada jedan vlasnik drzi vise lokota, kao i da jedan lokot ima vise vlasnika. S-lokot jeprimjer lokota koji u vecini slucajeva ima vise vlasnika.

S-lokot

Dijeljeni lokot ili S-lokot (eng. Shared locks) se postavlja samo u pesimisticnoj kon-troli konkurentnosti. Ako neka konekcija pristupa objektu sa postavljenim izolacij-skim nivoom READ UNCOMMITTED ovaj tip lokota se uopce nece postaviti.Kodizolacijskh nivoa READ COMMITTED, REPEATABLE READ ili SERIALIZABLES-lokot se postavlja tijekom citanja podataka koji se dohvacaju SELECT naredbomi zadovoljavaju WHERE dio naredbe. Kad se S-lokot postavi sve konekcije mogucitati taj podatak bez obzira na postavljeni nivo izolacija, ali ga ne mogu mijenjatiili brisati. S-lokoti se obicno postavljaju na nivou PAGE ili TABLOCK.



U-lokot

Lokoti za azuriranje ili U-lokot (eng. Update locks) sprjecava najcesci uzrok pot-punog zastoja u visekorisnickom radu. Tipicna situacija kod mijenjanja podatakau bazama podataka je citanje podataka gdje se postavlja S-lokot na resurse na ko-jima se radi izmjena, pa se postavlja X-lokot na resurs koji je do sada bio zakljucanS-lokotom. Tada dolazi do potencijalno opasne situacija za nastajanje potpunogzastoja. Ako vise transakcija cita podatke i postavlja S-lokot, pa onda zatrazi X-lokot na isti resurs lako moze doci do blokade. Da bi se izbjegla ova potencijalnoopasna situacija kod azuriranja koriste se U-lokoti. Samo jedna transakcija mozezakljucati U-lokotom odredeni resurs, ako transakcija krene mijenjati resurs U-lokotse prebacuje u X-lokot inace se pretvara u S-lokot.

X-lokot

X-lokot (eng. Exclusive locks) je najjaca restrikcija koja se moze postaviti. Onasprjecava da dvije transakcije pisu istovremeno u isti resurs. Kada se jedanput X-lokot postavi na neki resurs niti jedna druga transakcija ne moze postaviti nikakavlokot na taj resurs sve dok lokot ne bude otpusten. Podatci zakljucani X-lokotommogu se dohvatiti samo koristeci NOLOCK ili ako se postavi najnizi nivo izolacijeREAD UNCOMMITTED. Ova vrsta lokota se tipicno koristi kod DML (eng. DataManipulation Language) operacija kao sto su INSERT, UPDATE ili DELETE. Uslucaju zakljucavanja prevelikog broja resursa ovim kljucem moze se znatno narusitikonkurentnost baze podataka, pa je preporuka da granulacija zakljucavanja budesto veca, te da transakcije koje manipuliraju podacima traju sto je moguce krace.

I-lokot

I-lokoti (eng. Intent locks) se koriste za uspostavu hijerarhije zakljucavanja. Tehnickigledano I-lokoti zapravo i nisu lokoti vec su samo neka vrsta zastavice koja ukazujeda na nizoj razini zakljucavanja postoji postavljen lokot. Oni sluze za obavjestavanjedrugih transakcija o namjeri koje resurse postojeca transakcija misli zakljucati. Ovajlokot ima dva glavna zadatka, a to su:

• Sprjecavanje drugih transakcija da mijenjaju resurse na visoj razini na nacinkoji ce ponistiti zakljucavanje na nizoj razini.

• Poboljsana ucinkovitost RDBMS-a u otkrivanju konflikta zakljucavanja navecoj razini granulacije.

I-lokota ima nekoliko vrsta kao sto su:

• IS-lokote (eng. Intent shared)

• IX-lokote (eng. Intent exclusive)

• SIX-lokote (eng. Shared with intent exclusive)

• IU-lokote (eng. Intent update)



• SIU-lokote (eng. Shared intent update)

• UIX-lokote (eng. Update intent exclusive)

Sch-lokoti

Sch-lokoti (eng. Schema locks) se koriste kada operacija ovisi o shemi tablice kojase izvrsava. Dijele se na dva podtipa:

• Sch-S-lokoti (eng. Schema stability lock) koriste se tijekom generiranja planovaizvrsenja (eng. execution plans). Ovi lokoti ne blokiraju pristup podatkovnimobjektima.

• Sch-M-lokoti (eng. Schema modification lock) se koriste tijekom izvrsavanjaDDL operacije kao sto su CREATE, DROP ili ALTER. Oni blokiraju pristupobjektu dok se njegova definicija mijenja.

BU - lokoti

BU - lokoti (eng. Bulk Update locks) se koriste kada se treba unijeti vise podataka.Oni nam omogucavaju brzo ubacivanje gomile podataka u tablicu bez smetnji drugihtransakcija. Tek kada se transakcija zavrsi resurs u ovom slucaju objekt ce bitiotpusten. Granulacija kod ovog zakljucavanja je uvijek TABLOCK.

KR - lokoti

KR - lokoti (eng. Key-Range) se koriste kada se podaci citaju s postavljenim SERI-ALIZABLE izolacijskim nivoom. Njihova svrha je sprjecavanje nastajanja fantoma.Onemogucuju transakcijama modifikaciju podataka na podacima u rasponu djelo-vanja kljuca. Postoje dva tipa KR - lokota:

• RangeX-X - postavljanje X-lokota izmedu kljuceva u zadanom rasponu i pos-tavljanje X-lokota na zadnji kljuc u rasponu

• RangeS-U - postavljanje S-lokota izmedu kljuceva u zadanom rasponu i pos-tavljanje U-lokota na zadnji kljuc u rasponu

19.4.3 Kompatibilnost lokotaU tablici 19.2 prikazana je kompatibilnost postavljana lokota na resurse po vrstamaod najslabijeg prema najjacemu. Postojece zakljucavanje prikazano je u stupcimatablice, a zatrazeno u redovima tablice. Osim prikazanih lokota u tablici trebareci da su Sch-S-lokoti kompatibilni sa svim tipovima zakljucavanja osim sa Sch-M-lokotima, a Sch-M-lokoti nisi kompatibilni ni sa jednim tipom lokota. BU-lokoti sukompatibilni samo sa ostalim BU-lokotima i sa Sch-S-lokotima.



Tablica 19.2: Kompatibilnost lokota

IS S U IX SIX XIntent Shared (IS) DA DA DA DA DA NE

Shared (S) DA DA DA NE NE NEUpdate (U) DA DA NE NE NE NE

Intent Exclusive (IX) DA NE NE DA NE NEShared with Intent Exclusive (SIX) DA NE NE NE NE NE

Exclusive (X) NE NE NE NE NE NE

19.4.4 Vrste i svojstva izolacijskih nivoaJedno od cetiri svojstva transakcija je izolacija. Izolacijom medu transakcijama semoze upravljati postavljanjem odredenog izolacijskog nivoa za pojedinu transakciju.Svaki izolacijski nivo ima svoje specificnosti koje su opisane u sljedecim poglavljima.U SQL Serveru postoji pet izolacijskih nivoa. Jedan nivo je predefinirano iskljucen.Da bi ga koristili moramo ga ukljuciti pomocu sljedece naredbe:

1 ALTER DATABASE ImeBazePodataka2 SET ALLOW_SNAPSHOT_ISOLATION ON

Izolacijski nivoi se postavljaju na sljedeci nacin:1 SET TRANSACTION ISOLATION LEVEL2 < READ UNCOMMITTED3 | READ COMMITTED4 | REPEATABLE READ5 | SNAPSHOT6 | SERIALIZABLE7 >

Kod opisa izolacijskih nivoa navedena stanja su generalizirana jer Lock menagersam odlucuje dali ce biti zakljucan redak, objekt ili stranica (RID, OBJECT iliPAGE) nekog resursa osim ako mu mi implicitno ne kazemo drugacije, ali principrada je isti. Ovisno o postavljenom nivo razlicito ce se zakljucavati podaci, ali kodoperacija promjene, brisanja i umetanja podataka (UPDATE, INSERT, DELETE)transakcije se ponasaju na sljedeci nacin u svim izolacijskim nivoima:

• ako nema unaprijed postavljenih lokota, na objekt ce postaviti svoj X-lokot idrzati ga do kraja transakcije,

• u slucaju da bilo kakav tudi lokot postoji na objektu transakcija ce biti bloki-rana.

Izolacijski nivo citanje bez zakljucavanja

Citanje bez zakljucavanja (eng. Read uncommitted) nivo jamci najmanju izolacijui najmanju tocnost podataka pri manipuliranju s podacima. Izolacijski nivo READUNCOMMITTED se kod citanja podataka (SELECT) ponasa na sljedeci nacin:



• transakcija cita podatak i ne postavlja svoje lokote,

• ako su tudih lokoti postavljeni na resurs podaci ce biti procitani bez postivanjatudih lokota

Kod koristenja ovog izolacijskog nivoa treba biti oprezan jer postoji mogucnost dase dogodi prljavo citanje, neponovljivo citanje ili da se pojave fantomski redci. Ovajnivo je koristan za citanje podataka cija tocnost nije bitna vec trenutno stanje.

Izolacijski nivo citanje potvrdenih

Izolacijski nivo citanje potvrdenih (eng. Read committed) je predefinirani izolacijskinivo u SQL Serveru. Kod citanja podataka (SELECT) ponasa na sljedeci nacin:

• ako na nekom objektu iz kojega se citaju podaci ne postoje nikakvi lokoti ilipostoji S-lokot, na objekt postavlja svoj S-lokot i drzi ga dok se ne procitajupodaci i odmah nakon citanja ga otpusta, ne ceka kraj transakcije,

• ako je na objekt netko postavio X ili IX-lokot transakcija ce biti blokirana.Kod koristenja ovog izolacijskog nivoa treba biti oprezan jer postoji mogucnost dase dogodi neponovljivo citanje ili da se pojave fantomski redci. Preporuka je da seovaj izolacijski nivo najvise koristi, ali treba biti svjestan mogucnosti pogreske.

Izolacijski nivo ponovljivo citanje

Izolacijski nivo ponovljivo citanje (eng. Repeatable read) se koristi kada je potrebnaveca izolacija izmedu transakcija, a manja konkurentnost. Kod citanja podataka(SELECT) ponasa na sljedeci nacin:

• ako na nekom objektu iz kojega se citaju podaci ne postoje nikakvi lokoti ilipostoji S-lokot, na objekt postavlja svoj S-lokot i drzi ga dok se transakcija nepotvrdi ili ponisti,

• ako je na objekt netko postavio X ili IX-lokot transakcija ce biti blokirana.Iako ovaj izolacijski nivo jamci vecu sigurnost od prethodna dva, no ipak postojimogucnost pojavljivanja fantomskih redaka.

Izolacijski nivo serijalizacija

Izolacijski nivo serijalizacija (eng. Serializable) garantira najveci stupanj izoliranostimedu transakcijama. Kod citanja podataka (SELECT) ponasa se na sljedeci nacin:

• ako na nekom objektu iz kojega se citaju podaci ne postoje nikakvi lokoti ilipostoji S-lokot, na objekt postavlja svoj S-lokot i drzi ga dok se transakcija nepotvrdi ili ponisti,

• dodatno definira raspon redaka prema WHERE uvjetu i na njega stavlja S-lokote kako bi bilo sprijeceno umetanje novih redaka.

Iako ovaj izolacijski nivo sprjecava mogucnost pojavljivanja fantoma, prljavog i nepo-novljivog citanja, ozbiljno narusava konkurentnost baze podataka, pa ga nije dobrokoristiti ukoliko nije neophodno.



Izolacijski nivo snimak

Izolacijski nivo snimak (eng. Snapshot) je najspecificniji od svih. Predefiniranoje iskljucen. Prvi put se pojavio u SQL Serveru 2005, i malo mu je ljudi sklono.SNAPSHOT radi na principu verzioniranja retka. Tradicionalan pristup je kodizmjena podatka da se podatak zakljuca i ostane nedostupan za druge transakcijedo potvrde ili odustajanja od izmjene. U praksi SNAPSHOT izolacijski nivo provodiMVCC (engl. Multiversion concurrency control). MVCC omogucava da se vidi tockaili snimak u vremenu svih do tada potvrdenih podataka. Kod citanja podataka(SELECT) ponasa se na sljedeci nacin:

• uzima snimak stanja zadnje potvrdenih resursa kada je transakcija pokrenutate takvo stanje drzi do kraja transakcije, ne zanima ga ako se u meduvremenudogodila neka izmjena ili nesto slicno.

Nedostatak ovog izolacijskog nivoa je dodatna obrada podataka i potrosnje memo-rije.

19.4.5 Problemi konkurentnostiZa prikaz problema konkurentnosti koristiti ce se tablica strukture prikazane na slici19.6. Preko sistemske naredbe sys.dm tran locks moze se doci do resursa koje Lockmenager trenutacno drzi zakljucanim, a za koje ima zahtjev za zakljucavanjem.

Slika 19.6: Struktura tablice Kupac

Prljavo citanje

Prljava citanja (engl. dirty reads) nastaju nakon sto prva transakcija promjeni redaku tablici (UPDATE), druga transakcija ga procita u trenutku izmjene. Ukoliko prvatransakcija odustane od izmjene dogodi se problem prljavog citanja (Tablica 19.3).

Rjesenje ovog problema je postavljanje transakcije 2 na najmanje READ COM-MITTED izolacijski nivo zasto je to tako treba pogledati kako su postavljeni lokotina koji resurs. Transakcija 1 postavlja izolacijski nivo na READ COMMITTED ipokrece transakciju. Prije i za vrijeme izvrsavanja naredbe UPDATE transakcija 1postavlja lokote na resurse (slika 15.). Transakcija 2 ima postavljen izolacijski nivona READ UNCOMMITTED sto znaci da ne postavlja svoje lokote na resurse, alii da ne postuje tude lokote, pa moze procitati podatak (korak 6. - prljavo citanje)prije nego transakcija 1 odluci odustati od izmjene, napraviti ROLLBACK.



Tablica 19.3: Prikaz problema prljavog citanja

TRANSAKCIJA 1 TRANSAKCIJA 2

1 SET TRANSACTION ISOLATIONLEVEL READ COMMITTED

2 SET TRANSACTION ISOLATIONLEVEL READ UNCOMMITTED

3 BEGIN TRAN

4 BEGIN TRAN

5UPDATE Kupac SETEmail = ’[email protected]’,Telefon = ’777-555-1111’WHERE IDKupac = 1

6 SELECT * FROM KupacWHERE Kupac.IDKupc = 1

7 ROLLBACK TRAN

8 ROLLBACK TRAN

Neponovljiva citanja

Neponovljiva citanja (engl. Non repeatable reads) nastaje nakon sto prva transak-cija dohvati neku vrijednosti. U meduvremenu druga transakcija promijeni vrijed-nost dohvacenog retka. Nakon izmjene prva transakcija ponovno izvrsava jednakunaredbu, a dohvati razlicite vrijednosti. U tablici 19.4 prikazan je problem neponov-ljiva citanja. Transakcija 1 i 2 imaju postavljen predefiniran izolacijski nivo READCOMMITTED. Nakon sto je pokrenuta transakcija 1 SELECT naredbom dohvacajuse podatci o kupcu koji ima vrijednost IDKupac-a 80. Nakon toga istom naredbomdohvaca istog kupca, ali rezultat dohvacanja je razlicita vrijednost (korak 5. i korak8.) Razlog tome je sto je transakcija 2 u meduvremenu promijenila vrijednosti kupcas primarnim kljucem 80. Kako bi se izbjegao navedeni problem izolacijski nivo sepodize na razinu REPEATABLE READ ili SERIALIZABLE.

Fantomi

Fantomi (engl. phantoms) su redci u tablici koji ne bi smjeli postojati, tj. dvos-truko dohvacanje istih podataka rezultira razlicitim brojem redaka. U tablici 19.5je prikazan primjer nastajanja problema fantoma. Obje transakcije su na predefi-niranom nivou READ COMMITTED. Prva transakcija dohvaca podatke iz tabliceKupac kojima telefonski broj zapocinje s tri znamenke 5. Rezultat izvrsavanja na-redbe ce biti 12 kupaca sa njihovim podacima. Nakon toga ista transakcija dohvacapodatke istom naredbom (korak 8.), a rezultat izvrsavanja je 13 kupaca. Taj redakse naziva fantomski redak. Razlog njegovog nastajanja je transakcija 2 koja ubacujejednog novog kupca i potvrduje svoje naredbe izmedu dva dohvacanja transakcije1. Problem se rjesava podizanjem izolacijskog nivoa na SERIALIZABLE. Navedeniizolacijski nivo postavlja S-lokote kod pokretanja SELECT upita i drzi ga do kraja



Tablica 19.4: Prikaz problema neponovljivog citanja




3 BEGIN TRAN

4 BEGIN TRAN

5 SELECT * FROM KupacWHERE Kupac.IDKupac = 80

6UPDATE Kupac SET

Telefon = ’333-222-1111’WHERE Kupac.IDKupac = 80

7 COMMIT TRAN


9 ROLLBACK TRAN

Tablica 19.5: Prikaz problema fantoma




3 BEGIN TRAN

4 BEGIN TRAN

5SELECT * FROM KupacWHERE Telefon LIKE ’555%’-- vraca 12 redaka

6INSERT INTO KupacVALUES (’Mario’, ’Buntic’,[email protected]’, ’555-123-1234’)

7 COMMIT TRAN

8SELECT * FROM KupacWHERE Telefon LIKE ’555%’-- vraca 13 redaka

9 ROLLBACK TRAN

transakcija.



Problem izgubljenih izmjena

Problem izgubljenih izmjena (eng. Lost Updates) nastaje nakon sto dvije ili visetransakcija promjene vrijednosti nekog retka i potvrde svoje naredbe. Samo pro-mjene zadnje transakcije ostati ce zapisane u bazi podataka. U tablici 19.6 prikazanje primjer nastajanja izgubljenih izmjena.

Tablica 19.6: Prikaz problema izgubljenih izmjena




3 BEGIN TRAN

4 BEGIN TRAN



7UPDATE Kupac SET

Ime = ’Fernando’WHERE Kupac.IDKupac = 100

8 COMMIT TRAN

9UPDATE Kupac SET

Ime = ’Miroslav’WHERE Kupac.IDKupac = 100

10 COMMIT TRAN

Problem izgubljenih izmjena je teze rijesiti jer ga nije moguce sprijeciti postav-ljanjem izolacijskih nivoa. Na primjer ako dva korisnika ucitaju iste podatke iz bazeza financijski izvjestaj i obojica ih odluce mijenjati preko forme za mijenjanje na svo-jim racunalim te na kraju spreme promijene. Tada je rad jednog korisnika uzaludanjer je izvjestaj prebrisan, tj. dogodio bi se problem izgubljenih izmjena. Najboljinacin rjesavanja ovog problema je provjera kod spremanja podataka odgovaraju lipodaci koji se ucitavaju trenutnima u bazi. Ako je odgovor potvrdan podaci se spre-maju, no ako podaci ne odgovaraju korisnika se obavjestava da je doslo do izmjenau podacima te se nudi odabir spremanja podataka ili ucitavanja novih podataka.

19.4.6 Problemi konkurentnosti koje rjesavaju izolacijski nivoiIzolacijskim nivoima se moze rijesiti vecina problema koji nastaju u visekorisnickomradu baze podataka, ali se postavljanjem prevelikog izolacijskog nivoa moze ozbiljnonarusiti konkurentnost baze podataka. Ne postoje pravila kada se koji izolacijskinivo koristi vec se izolacijski nivoi postavljaju ovisno o ocekivanom broju korisnickih



zahtjeva. U tablici 19.7 su prikazani neki od mogucih problema koji se rjesavajuizolacijskim nivoima. Sa DA su oznaceni problemi koje izolacijski nivoi mogu rijesiti,a sa NE oni koje ne mogu.

Tablica 19.7: Problemi koji se rjesavaju izolacijskim nivoima

IZOLACIJSKINIVO

PRLJAVOCITANJE

NEPONOVLJIVOCITANJE

FANTOMI IZGUBLJENEIZMJENE

READ UN-COMMITTED

NE NE NE ?

READ COM-MITTED

DA NE NE ?

REPEATABLEREAD

DA DA NE ?

SERIALIZABLE DA DA DA ?SNAPSHOT DA DA DA ?

19.4.7 Problem potpunog zastojaPotpuni zastoj (eng. Deadlocks) nastaje zbog nemogucnosti potvrde niti jedne tran-sakcije jer ne moze pristupiti resursu kojega drzi ova druga 19.7. SQL Server auto-

Slika 19.7: Situacija potpunog zastoja

matski detektira potpuni zastoj. Nakon detekcije potpunog zastoja SQL Serverjednoj transakciji dopusta da se potvrdi, a drugu opozove i generira gresku. Tran-sakcija koja se nije potvrdila u ovoj situaciji naziva se zrtva potpunog zastoja (eng.Deadlock victim). Resursi koji mogu biti u situaciji potpunog zastoja su:

• Lokoti - prva transakcija cita redak i postavlja svoj S-lokot na njega, drugatransakcija cita drugi redak i postavlja svoj S-lokot na njega, nakon citanja objetransakcije zele promijeniti redak na kojem druga transakcija ima postavljen S-lokot, ali ne mogu postaviti svoj X-lokot na redak koji ima na sebi postavljenS-lokot od druge transakcije, pa dolazi do potpunog zastoja. U sljedecempoglavlju je prikazan primjer ovakvog zastoja.

• Radna dretva (eng. Worker threads) - kada sesija pokrene transakciju kojacita redak iz tablice i postavlja S-lokote na njega, te ode u stanje mirovanja



(eng. sleep), druga transakcija pokusava mijenjati redak, tj. postaviti svojX-lokot, ali nije u mogucnosti zbog postavljenog S-lokota sesije koja miruje.

• Memorija - u slucaju dvije korisnicki definirane funkcije objema je potrebno30MB prostora za izvrsavanje, a na raspolaganju je samo 40MB. Tada oba kon-kurentna upita zauzmu samo 20MB, pa dolazi do problema potpunog zastojajer oba upita cekaju otpustanje resursa, tj. memorije.

Primjer situacije potpunog zastoja

U tablici 19.8 su prikazane dvije transakcije pod izolacijskim nivoom REPEATABLEREAD u situaciji potpunog zastoja. Do potpunog zastoja dolazi iz sljedecih razloga:

• transakcija 1 cita redak iz tablice tbl1 i postavlja svoje S-lokot na taj redak,

• transakcija 2 cita redak iz tablice tbl2 i postavlja svoje S-lokot na taj redak,

• transakcija 1 nakon citanja retka iz tablice tbl1 zeli mijenjati redak u tablicitbl2, ali ne moze jer je na njemu postavljen S-lokot transakcije 2,

• transakcija 2 zeli promijeniti redak u tbl1, ali je na njemu postavljen S-lokottransakcije 1, pa mora cekati otpustanje lokota i tada dolazi do situacije pot-punog zastoja.

Nakon sto je SQL Server detektirao potpuni zastoj, jedna transakcija je ponistena,a druga se potvrduje, Slika 19.8.

Slika 19.8: Poruke nakon ponistenja jedne transakcije

Detektiranje potpunog zastoja i oporavak

Detektiranje potpunog zastoja se radi automatski. SQL Server to radi svakih 5sekundi na nacin da provjerava za sve trenutne transakcije koje lokote cekaju izasto nisu potvrdene. Ako postoje transakcije sa zahtjevom za nekim resursima tenakon druge provjere jos nisu potvrdene onda rekurzivno provjerava sve otvorenetransakcije. Provjeru vrsi na nacin da pretrazuje ovisnost izmedu transakcija kojeimaju kruzni lanac zahtjeva za zakljucavanjem. Nakon detekcije potpunog zastoja,SQL Server mora donjeti odluku koju transakciju odbaciti. Kriterij odabira je manjibroj akcija za povratak u prethodno stanje baze. Kriterij odabira se moze mijenjati.



Tablica 19.8: Primjer situacije potpunog zastoja


1SET TRANSACTION ISOLATIONLEVEL REPEATABLE READBEGIN TRAN

2SET TRANSACTION ISOLATIONLEVEL REPEATABLE READBEGIN TRAN

3SELECT * FROM tbl1WHERE ID = 1WAITFOR DELAY ’00:00:05’

4 SELECT * FROM tbl2WHERE ID = 1

5UPDATE tbl2SET Stupac1

= ’Test-Deadlocks’WHERE ID = 1

6UPDATE tbl1SET Stupac1

= ’Test-Deadlocks’WHERE ID = 1

7 COMMIT TRAN

8 COMMIT TRAN

Implicitno odredivanje prioriteta kod odabira zrtva potpunog zastoja se radi nasljedeci nacin:

1 SET DEADLOCK_PRIORITY LOW | HIGH | NORMAL | -10 do 10

Znaci prioritet se moze odrediti numericki i odabirom LOW, HIGH ili NORMAL.Bitno je znati da je LOW vrijednost manja od numerickih -5, NORMAL vrijednostje u rasponu od -5 do 0, a HIGH u rasponu od 0 do 5.

Tehnike pisanja koda koje sprjecavaju nastajanje potpunog zastoja

Izbjegavanje potpunog zastoja u velikim i kompleksnim sustavima je nemoguce,moguce ga je samo smanjiti na sto manji broj. Da bi se smanjio broj pojavljivanjapotpunih zastoja treba slijediti nekoliko pravila kao sto su:

• Sve transakcije moraju pristupati objektima istim redoslijedom 19.9. Ako pos-toji situaciju kada dvije transakcije zele mijenjati podatke u dvije tablice. Pri-mjerice ako jedna transakcija pristupa prvoj tablici i mijenja podatke u prvojtablici, a nakon toga pristupa drugoj tablici. Druga transakcija pristupa istimtablicama, ali obrnutim redoslijedom. Takva situacija je potencijalno opasnaje ceu jednom trenutku jedna transakcija cekati na drugu zbog postavljenihlokota. Kako bi se izbjegla ovakva situacija potrebno je transakcije kreirati na



Slika 19.9: Pristup objektu obrnutim i istim redoslijedom

nacin da mijenjaju podatke istim redoslijedom (slika 18). Znaci prva transak-cija postavlja X-lokot na prvoj tablici i mijenja podatke. Druga transakcijaisto zeli mijenjati podatke u prvoj tablici, ali mora cekati dok prva ne otpustiX-lokote. Kada prva transakcija zavrsi prebacuje se na drugu tablicu i otpustasvoje X-lokote, a druga transakcija krene mijenjati podatke na prvoj, pa zatimna drugoj tablici. Na ovaj nacin izbjegava se potencijalno najopasnija situacijaza nastajanje potpunog zastoja.

• Treba koristiti sto je moguce nizi izolacijski nivo. Za citanje podataka dobroje koristiti nivo READ COMMITTED jer on ne drzi zakljucanim podatkedo kraja transakcije vec samo dok se citanja izvrsava. Odmah nakon citanjaresursi se otpustaju bez obzira sto transakcija jos traje. Navedeno povecavakonkurentnost baze i smanjuje mogucnost potpunog zastoja.

• Transakcije moraju biti sto je moguce krace u jednoj skupini naredbi (engl.batch). Sve sto nije potrebno biti u transakcije mora se izbaciti iz nje. Bitnoje da transakcije traju sto krace jer povecavanjem vremena izvrsavanja tran-sakcije raste i vjerojatnost da ce nekome trebati resurs koji je transakcijazakljucala. Zadrzavanjem transakcije u jednoj skupini naredbi smanjuju sepotencijalno moguce odgode i cekanja na izvrsavanje ostalih transakcija zbogsporijeg otpustanja resursa. Kod koristenja transakcija moze se koristiti na-redba za vremensko ogranicavanje drzanja resursa:

1 SET LOCK_TIMEOUT 1500

• Koristiti izolacijski nivo baziran na verzioniranju redaka. Ovakvo se nestomoze koristiti samo kada je izolacijski nivo SNAPSHOT ukljucen. Imple-mentacijom ovog izolacijskog nivoa minimizirana je vjerojatnost nastajanjapotpunog zastoja izmedu operacija citanja i pisanja.

• Izbjegavati interakciju s korisnikom u transakciji. Interakcija s korisnikom



moze trajati dugo, a cijelo vrijeme ce biti zakljucani neki resursi. Ovo jepogubno po performanse baze podataka, a i povecava mogucnost nastajanjapotpunog zastoja.


Dio V

Fizicko dizajniranje baze podataka ioptimizacija upita

128

20 Indeksi

U ovom poglavlju je dan pregled procesiranja upita sa naglaskom na interakcijunajnizeg fizickog dijela (stvarni zapis na disku) i memorije kod manipulacije poda-cima.

20.1 DBMS manipulacija podacimaProcesiranje upita je odvojeno od upravljanja memorijom i diskom. Na slici 20.1 jeprikazan slijed procesa tijekom izvrsavanja SQL upita.

Proces zapocinje kada korisnicka stanica uputi SQL upit i proslijedi ga do SQLServera. Upit se analizira, optimizira i prevode u plan izvrsavanja koji koristiokruzenje za upravljanje podacima. Plan izvrsavanja ce detektirati stranice s poda-cima i indeksne stranice koje treba dohvatiti. Detaljniji opis funkcioniranja planaizvrsavanja, podatkovnih i indeksnih stranica biti ce opisan u poglavlju. Nakon stopodsustav za upravljanje podacima dobije plan izvrsavanja moze proslijediti trazenjestranice klijentu. Stranice ne idu odmah prema klijentu kao sto je vidljivo na slici20.1 vec idu prvo u radnu memoriju zatim klijentu. Vecina operacija manipulacijepodataka se ne obavlja na disku vec u radnoj memoriji jer bi bilo ”preskupo” poresurse svaku manipulaciju podacima raditi na disku. Inace operacije citanja i pi-sanja po disku su najsporije. Dakle nakon procesiranja korisnikova upita prvo sepretrazuje radna memorija i provjera se postoje li tamo trazeni podaci, tek ako nisuide se na disk ucitava ih se u memoriju i vraca korisniku. Svaki memorijski dio od8KB moze biti u tri razlicita stanja:

• Slobodan - slobodni ili prazni dijelovi memorije su oni koji ne sadrze podatke.Oni predstavljaju slobodan prostor za stranice koje se ucitavaju sa diska umemoriju. Veliki broj slobodnih dijelova memorije znaci da memorijski prostor

Slika 20.1: Podsustav za manipulaciju podacima

129

POGLAVLJE 20. INDEKSI

nije dobro iskoristen.

• Raspoloziv - trenutno u sebi sadrze podatke sa diska koji nisu modificirni odtrenutka kada su ucitani u memoriju. DBMS ove dijelove memorije tretiranepotrebne, te ih prepisuje novim podacima bez posljedica i to prvo prepisujeone koji nisu u posljednje vrijeme koristeni.

• Modificiran - su oni koji u sebi sadrze podatke koje je klijent modificirao, tene odgovaraju stanju na disku. DBMS se mora pobrinuti da te podatke neprepise drugima jer bi Korisnicke modifikacije bile izgubljene. DBMS koristirazne tehnike kako bi upravljao modificiranim dijelovima memorije. Potrebnoje znati da DBMS u odredenom vremenskom intervalu sve modificirane dijelovememorije zapise na disk, te ih dalje smatra raspolozivima.


Dio VI

Literatura i dodaci

131

Literatura

[1] Dambic, G. Oblikovanje baza podataka - Prirucnik. Algebra, 2009.

[2] Buntic, M. Osnovna select naredba. Laboratorijske vjezbe iz kolegija Bazepodataka, 2015.

[3] Darwen, H. An Introduction to relational database theory, fourth ed. Book-boon, 2010.

[4] Date, C. J. The Relational Database Dictionary, 1 ed. O’Reilly Media, 2006.

[5] Date, C. J. Database Design and Relational Theory - Normal Forms and AllThat Jazz. O’Reilly, 2012.

[6] Dewson, R. Beginning SQL Server 2012 for Developers, third ed. Apress,2012.

[7] Elmasri, R., and Navathe, S. B. Fundamentals of Database Systems (5thEdition). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA,2006.

[8] Garcia-Molina, H., Ullman, J. D., and Widom, J. Database Systems:The Complete Book, 2 ed. Prentice Hall Press, Upper Saddle River, NJ, USA,2008.

[9] Kastelan, T. Uvod u baze podataka - Prirucnik. Algebra, 2010.

[10] Liu, L., and Ozsu, M. T., Eds. Encyclopedia of Database Systems. SpringerUS, 2009.

132

Dodatak A - Shema baze podataka

Shema testne baze ”FpzLogistika” nalazi se na slici 20.2.

Slika 20.2: Modeliranje podataka

133

Dodatak B - Kreiranje baze podataka

Skripta za kreiranje sheme baze podataka ”FpzLogistika” i inicijalnim punjenjempodataka te svim primjerima iz skripte moze se preuzeti na stranici Transport Op-timization Group na sljedecoj poveznici http://www.fpz.unizg.hr/tog.

Za generiranje svih testnih podataka baze podataka ”FpzLogistika” koristen je bes-platan servis ”Mockaroo” (http://mockaroo.com/)

134

http://www.fpz.unizg.hr/tog

http://mockaroo.com/

uvod u relacijske baze podataka

Documents