Baza podataka za sveu ili²nu dru²tvenu mreºu

Transcription

1 Sveu ili²te J.J. Strossmayera u Osijeku Odjel za matematiku Snjeºana Mijo²evi Baza podataka za sveu ili²nu dru²tvenu mreºu Diplomski rad Osijek, 2014.

2 Sveu ili²te J.J. Strossmayera u Osijeku Odjel za matematiku Snjeºana Mijo²evi Baza podataka za sveu ili²nu dru²tvenu mreºu Diplomski rad Mentor: izv. prof. dr. sc. Domagoj Matijevi Komentor: Slobodan Jeli Osijek, 2014.

3 SADRšAJ 1 Sadrºaj 1 Uvod 2 2 Logi ki dizajn baze podataka Kriteriji za model baze Normalizacija baze podataka Implementacija baze podataka Ograni enja i okida i Ograni enja Okida i Prikazi i indeksi Virtualni prikazi Izmjena prikaza i izmjenjivi prikazi CHECK opcija vezana uz prikaze Indeksi u SQL-u Kako MySQL koristi indekse Pohranjene procedure i funkcije Kreiranje pohranjenih procedura i pohranjenih funkcija Grananje A Relacijska shema baze 51 B Prilozi 54 B.1 Gra ki prikaz relacijske sheme baze aktivna B.2 Kod i obja²njenje koda aktivne baze B.2.1 Tablice B.2.2 Indeksi B.2.3 Okida i B.2.4 Prikazi B.2.5 Procedure B.2.6 Funkcija

4 1 UVOD 2 1 Uvod U dana²njem svijetu tematika dru²tvenih mreºa je jako aktualna tematika mežu mladima, budu i da su upravo mlade osobe oni koji najvi²e vremena provode na njima. Osvrnimo se najprije na povijesni aspekt dru²tvenih mreºa, potom spomenimo injenicu kako je Facebook u po etku sluºio kao dru²tvena mreºa na sveu ili²tu, da bismo naposljetku objasnili kao izbor teme ovog diplomskog rada upravo bazu podataka za sveu ili²nu dru²tvenu mreºu. Povijest dru²tvenih mreºa vezana je uz tzv. Usenet - prete u dana²njih foruma - 90-ih godina 20. stolje a. Zapravo, forumi se smatraju prvim dru²tvenim mreºama u svijetu. Iako su nudili opciju komentiranja razli itih tema, debate ili virtualnog druºenja, nedostajala im je najvaºnija opcija ve ine dana²njih dru²tvenih mreºa - mogu nost postati s nekim virtualni prijatelj. Osim toga, u forumima se u po etku registriralo pseudonimom. Prva prava dru²tvena mreºa sa svim funkcijama koje imaju dana²nje dru²tvene mreºe je bila dru²tvena mreºa SixDegrees. Svatko se mogao registrirati na stranicu (obvezno imenom i prezimenom) i pozvati om prijatelje, te pretraºivati korisnike po njihovim zanimanjima ili interesima. SixDegrees je sluºbeno propao godine. S vremenom su nastajale dru²tvene mreºe specijalizirane za razna podru ja i interese, mežu kojima je bio poznat Friendster (nastao u velja i godine) - dru²tvena mreºa za komunikaciju s prijateljima, a potom se pojavio LinkedIn (poslovna dru²tvena mreºa) i MySpace (osnovan u kolovozu godine - dopu²tao sve ²to korisnik ºeli: laºno ime, blog, igre, otvaranje prola bez pozivnice postoje eg lana). Prva dru²tvena mreºa koja je bila specijalizirana za studente sveu ili²ta je Facebook, kojeg je pokrenuo Mark Zuckerberg, student s Hardvarda zajedno sa svojim cimerima, kako bi fotoalbume studenata postavio online, gdje bi ih svi mogli vidjeti. Ispo etka je sluºio samo fakultetima, a potom je godine otvoren za sve ljude godine je Zuckerberg omogu io svakom programeru da osmisli i postavi aplikaciju na stranicu. U dana²nje vrijeme raste popularnost nove dru²tvene mreºe Google+, koja omogu uje grupiranje korisnika s kojima dijelimo informacije u krugove (npr. obitelj, prijatelji, poznanici,...), te dijeljenje odreženih informacija samo s izabranim krugovima ljudi, a kako je za logiranje potreban samo ra un na Google-u, ta bi mreºa mogla predstavljati konkurenciju Facebook-u. U ovom je radu izražena baza podataka za sveu ili²nu dru²tvenu mreºu. Zapravo, radi se o dvije baze podataka koje imaju jednaku relacijsku shemu. Jedna je aktivna (u njoj se sve odvija), a druga povijesna (iz nje se ni²ta ne bri²e). Za razliku od Facebook-a, tj. od onog ²to je Facebook s vremenom postao, na²a dru²tvena mreºa ima korisnike koji su isklju ivo

5 1 UVOD 3 vezani uz sveu ili²te: profesore, studente i gostuju e studente, te sadrºi informacije o ustanovama obrazovanja, profesorima na pojedinim fakultetima, kabinetima,... pa baza osim podataka vezanih uz korisnike, njihove osobne informacije, poruke, slike i sl. sadrºi i podatke o obrazovanju, generacijama obrazovanja u pojedinoj ustanovi, kolegijima koji su upisani na odreženom smjeru i sl., odnosno podatke vezane uz sveu ili²te i akademsko obrazovanje. U radu je najprije naveden logi ki dizajn baze podataka (kriteriji za bazu i normalizacija), a potom implementacija baze podataka, s naglaskom na gradivo vezano uz ograni enja, okida e, prikaze, indekse, pohranjene procedure i funkcije. U Dodacima se nalazi relacijska shema baze podataka, te obja²njenje priloga koji su na CD-u priloºenom uz rad.

6 2 LOGIƒKI DIZAJN BAZE PODATAKA 4 2 Logi ki dizajn baze podataka U ovom emo dijelu rada konkretnije progovoriti o relacijskom modelu podataka, o relacijama, te o funkcijskim ovisnostima. Spomenimo prvo najbitnije pojmove. Relacijski model podataka prikazuje podatke pomo u dvodimenzionalnih tablica ili relacija. Instancom relacije nazivamo tablicu kojom je predstavljen skup entiteta u relacijskom modelu podataka, a relacijskom shemom nazivamo ime relacije R iza kojeg slijedi popis njezinih atributa u zagradi, dok je relacijska shema baze podataka skup relacijskih shema svih relacija u nekoj bazi podataka. Navedimo sada najprije tvrdnje vezane uz na²u bazu podataka za sveu ili²nu dru²tvenu mreºu, a potom emo navesti relacijsku shemu. 2.1 Kriteriji za model baze Kao kriteriji za model baze, posluºit e nam sljede e tvrdnje, a relacijska shema baze podataka nalazi se u Dodatku A. Svaki korisnik u bazi podataka ima naveden svoj korisni ki broj (userid), korisni ko ime (username), ²ifru (password), ime, prezime, spol, datum roženja (datum rodjenja), i mjesto roženja (mjesto rodjenja). Pri tome su korisni ki broj i korisni ko ime jedinstveni, a ²ifra i korisni ko ime mogu imati najvi²e 10 znakova. U bazi postoji popis gradova i drºava. Za svaki grad je naveden gradid, po²tanski broj 1 (postanski broj), naziv grada (naziv grada) i drºava u kojoj se nalazi. Mežu korisnike se ubrajaju profesori (pod tim se misli ne samo na one koji imaju titulu profesora, nego i na docente, asistente,...), studenti 2 (s promatranog sveu ili²ta) i gostuju i studenti (s drugih sveu ili²ta i ustanova koje nisu na promatranom sveu ili²tu). Odnosno, userid moºe biti profesorid, sid, gid ili neka kombinacija navedenih atributa. Svakom studentu navedena je adresa (pri tome u bazi postoji popis ulica, svakoj je pridruºen grad, a preko grada i drºava u kojoj se nalazi), broj telefona (telefon), broj mobitela (mobitel) i adresa ( ). 1 Pri tome za neke gradove iz drugih drºava, za koje emo imati gostuju e studente u bazi i koji imaju vi²e po²tanskih brojeva, uzimamo onaj po²tanski broj koji odgovara podru ju grada na kojem se ustanova ili student nalazi. No, takvih primjera ne emo imati puno, pa tu injenicu moºemo smatrati zanemarivom u bazi. 2 Pod tim pojmom u bazi emo misliti isklju ivo na one studente koji su s promatranog sveu ili²ta, tako da to ubudu e ne e biti posebno nagla²avano. Bude li trebalo govoriti o studentima s drugih sveu ili²ta, koristit emo pojam gostuju eg studenta.

7 2 LOGIƒKI DIZAJN BAZE PODATAKA 5 Svakom profesoru je navedena titula (nastavna i znanstvena), a moºe biti navedena adresa, telefon, mobitel i adresa ( ) - sve privatno, ali ne mora. Svaki gostuju i student ima navedenu ustanovu obrazovanja s koje dolazi, jezike koje govori (u bazi imamo popis jezika), potom znanstveno-istraºiva ka podru ja koja ga zanimaju (u bazi imamo popis znanstveno-istraºiva kih podru ja) i koje kolegije slu²a na kojem smjeru (s popisa izvoženja kolegija u bazi na na²em sveu ili²tu). Svaki korisnik moºe (ali i ne mora) popuniti osobne podatke - ime se bavi (aktivnost), ²to ga zanima (interes), koju glazbu slu²a (glazba), koje TV emisije i serije voli (TV emisije i serije), koje lmove voli (filmovi), koje su mu knjige najdraºe (knjige), i ²to bi sam izrekao o sebi (o sebi). Omogu eno je slanje poruka mežu korisnicima, svakoj je zabiljeºen ID po²iljatelja (posiljateljid), ID primatelja (primateljid), vrijeme slanja (vrijeme slanja) i tekst. Omogu en je spomenar. Svaki korisnik moºe svakome napisati ne²to za uspomenu, a zabiljeºeni su korisni ki broj osobe koja pi²e (tko pise), korisni ki broj osobe iji je spomenar u pitanju (kome pise), poruka i vrijeme objave 3. Pri tome vrijedi, ako se osoba koja je nekome zapisala poruku u spomenar obri²e iz mreºe, poruka ostaje, ali se atribut tko pise postavlja na NULL. U bazi postoji popis ustanova obrazovanja. Za svaku je naveden broj ustanove (ustanovaid), naziv ustanove (naziv ustanove), adresa, broj telefona (telefon) i fax. Pri tome, ako se neka ustanova nalazi na vi²e lokacija, za svaku je navedena adresa, telefon i fax. U bazi postoji popis vrsta obrazovanja u pojedinoj ustanovi, i o generacijama svake vrste obrazovanja (godina po etka i godina zavr²etka). Svaki korisnik moºe imati navedene podatke o svom obrazovanju. Svakom korisniku je dopu²teno u itavanje slika, te zapis informacija o pojedinoj slici. Svaki fakultet ima navedenu svoju web-stranicu i dekana (koji je ujedno i profesor). 3 Za ime atributa stoji rije datum tipa TIMESTAMP jer smatramo kako bi slu ajevi zapisa iste osobe istoj osobi dva ili vi²e puta dnevno bili iznimno rijetki, ali su dopu²teni na ovaj na in (ne mora zna iti da e svatko unijeti sat u kojem je pisao, a osigurana je jedinstvenost zapisa za osobu koja pi²e, osobu iji je spomenar, tekst poruke i vrijeme).

8 2 LOGIƒKI DIZAJN BAZE PODATAKA 6 Za svaki fakultet je navedeno koji smjerovi na njemu postoje, a za svaki smjer je naveden tip studija i trajanje u semestrima. Svaki profesor na svakom fakultetu na kojem radi moºe imati navedenu adresu, a mora imati naveden postotni dio radnog vremena. U bazi je naveden popis kabineta na pojedinim fakultetima, za svaki kabinet je navedena oznaka, telefon i fax. U bazi emo pretpostaviti da svaki kabinet ima samo jedan broj telefona i samo jedan broj faxa. Svaki profesor na svakom fakultetu na kojem radi moºe imati svoj kabinet. Pri tome, nije dozvoljeno da profesor ima kabinet na fakultetu na kojem ne radi. Dozvoljeno je da svaki profesor na svakom fakultetu na kojem radi ima svoju web-stranicu. Profesor moºe drºati konzultacije na onima fakultetima na kojima radi. U bazi postoji popis znanstveno-istraºiva kih podru ja. Svaki profesor se moºe baviti s vi²e znanstveno-istraºiva kih podru ja, i svako znanstveno-istraºiva ko podru je moºe imati vi²e profesora koji se njim bave. Svako znanstveno-istraºiva ko podru je moºe imati grupu profesora koja se njime bavi. Svakoj grupi profesora naveden je naziv i opis. Pri tome, u grupi profesora ne moºe biti nijedan profesor koji se ne bavi znanstveno-istraºiva kim podru jem za koje je grupa namijenjena. U svakoj grupi profesora, lanovi mogu stavljati objave 4 i komentare. Pri tome se biljeºi vrijeme objave. Ostale osobe na mreºi, koje nisu lanovi grupe, ne mogu ni vidjeti 5 objave i komentare u njoj. Za pojedinog studenta je navedeno na kojim smjerovima studira (jedan student moºe studirati na vi²e smjerova), a za svaki smjer na kojem studira naveden je semestar, broj indeksa i status (npr. je li redoviti student, izvanredni ili s pla anjem). 4 engl. post 5 U bazi je s tehni ke strane (preko okida a) osigurano eliminiranje komentara na objave grupe sa strane korisnika koji grupi ne pripadaju. Ina e se takve stvari rije²avaju na razini aplikacije, a ne na razini baze, tako da su okida i koji bri²u krive unose u bazi postavljeni vi²e zbog primjera kori²tenja okida a, nego zbog rje²avanja problema na najekasniji na in. Budu i je ovaj rad usmjeren isklju ivo na razvoj baze podataka za sveu ili²nu dru²tvenu mreºu ne bave i se pri tome aplikacijskom razinom, okida e koristimo za rje²avanje pojedinih problema na razini baze podataka.

9 2 LOGIƒKI DIZAJN BAZE PODATAKA 7 U bazi postoji popis kolegija. Svaki kolegij moºe imati potrebna predznanja (takožer kolegije) na svakom smjeru na kojem se izvodi. Pri tome, neki smjerovi mogu biti u planiranju, tj. ne mora se svaki kolegij za koji su navedena predznanja na nekom smjeru izvoditi. Svaki kolegij na svakom smjeru na kojem se izvodi moºe imati navedenu web-stranicu, a mora imati naveden semestar na kojem se izvodi i ECTS bodove. Pojedini kolegij na pojedinom smjeru moºe imati vi²e profesora koji rade na njemu. U bazi postoji popis kolegija koje student trenutno slu²a na pojedinom smjeru. Studenti pojedinog smjera i godine, ili samo pojedinog smjera, mogu se upisati u grupu za to predviženu, te sli no kao i profesori u grupama profesora mogu stavljati objave i komentare. Pri tome, studenti koji nisu s tog smjera i te godine, ili samo tog smjera (ovisno o specikaciji grupe), ne mogu biti lanovi grupe i ne mogu objavljivati 6 postove i komentare. Pri objavi postova i komentara u grupama studenata, biljeºi se tekst i vrijeme objave. Svaki korisnik moºe izabrati s kojim korisnicima e podijeliti svoje osobne podatke i spomenar. Ako obri²emo profesora iz grupe profesora ili studenta iz grupe studenata, obrisat e se i sve njihove objave i svi njihovi komentari (ubrzo nakon toga). 2.2 Normalizacija baze podataka U svrhu normalizacije baze podataka, uvodimo pojam funkcijske ovisnosti. Denicija 2.1 (Funkcijska ovisnost) Za relaciju R(A, B), skup atributa B je funkcijski ovisan o skupu atributa A i pi²emo A B ako za svaku vrijednost od A postoji samo jedna vrijednost B, odnosno ako vrijedi da za dvije n-torke s jednakom vrijedno² u A koje u isto vrijeme postoje u relaciji, ta injenica ujedno zna i da te dvije n-torke imaju jednaku vrijednost B. Denicija 2.2 (Potpuna funkcijska ovisnost) Za relaciju R(A, B), skup atributa B je potpuno funkcijski ovisan o skupu atributa A, ako vrijedi da je B funkcijski ovisan o A (A B), ali B nije funkcijski ovisan ni o jednom pravom podskupu od A. 6 Na analogan na in kao i u prethodnoj fusnoti, problem koji bi se najekasnije rije²io na razini aplikacije, u bazi je rije²en preko okida a. (Primjerice, netko u tablicu za upis korisnika u grupu ºeli unijeti onog korisnika koji toj grupi ne bi trebao pripadati, pa je osigurano brisanje takvih redaka i sli nih slu ajeva.)

10 2 LOGIƒKI DIZAJN BAZE PODATAKA 8 Denicija 2.3 (Klju relacije) Za relaciju R(A, B), u kojoj su A i B dva disjunktna skupa atributa, skup atributa A je klju relacije ako je skup atributa B potpuno funkcijski ovisan o njemu. Propozicija 2.1 (Pravilo kombiniranja) Ako imamo skup atributa {A 1, A 2,..., A n } i ako on funkcijski povla i svaki pojedini element iz skupa atributa {B 1, B 2,..., B m }, tada skup atributa {A 1, A 2,..., A n } funkcijski povla i skup {B 1, B 2,..., B m }. Odnosno, A 1 A 2... A n B 1 A 1 A 2... A n B 2... A 1 A 2... A n B m je ekvivalentno sljede oj funkcijskoj ovisnosti: A 1 A 2... A n B 1 B 2... B m. Pogledajmo sada primjere funkcijskih ovisnosti atributa u relacijama korisnik i poruke. Primjer 2.1 (Funkcijske ovisnosti i klju evi relacije korisnik) Svrha ovog primjera je pokazati neke funkcijske ovisnosti relacije korisnik, iz kojih slijedi da su atributi userid i username klju evi. Navedimo sada ponovno relacijsku shemu relacije korisnik: korisnik(userid, username, password, ime, prezime, spol, datum rodjenja, mjesto rodjenja) Kako u relaciji korisnik imamo atribut userid koji jednozna no odrežuje svaki drugi atribut, vrijede sljede e funkcijske ovisnosti: userid username userid password userid ime userid prezime userid spol userid datum rodjenja userid mjesto rodjenja Kako vrijedi pravilo kombiniranja, tada nam vrijedi i sljede a funkcijska ovisnost: userid username password ime prezime spol datum rodjenja mjesto rodjenja U relaciji korisnik takožer postoji jo² jedan atribut koji je jedinstven - atribut username. Stoga vrijede sljede e funkcijske ovisnosti:

11 2 LOGIƒKI DIZAJN BAZE PODATAKA 9 username userid username password username ime username prezime username spol username datum rodjenja username mjesto rodjenja Ovdje bismo mogli dodati sljede u funkcijsku ovisnost koje dobijemo zbog pravila kombiniranja: username userid password ime prezime spol datum rodjenja mjesto rodjenja Sada iz Denicije 2.3 vidimo da su atributi userid i username klju evi relacije korisnik. Primjer 2.2 (Funkcijske ovisnosti atributa relacije poruke) Promotrimo relaciju poruke, s relacijskom shemom: poruke(posiljateljid, primateljid, vrijeme slanja, tekstid) Jedan po²iljatelj moºe poslati poruku vi²e primatelja u isto vrijeme. Jedan primatelj moºe dobiti poruku od vi²e po²iljatelja u isto vrijeme (teoretski mogu e, ali rijetko u praksi). Jedan po²iljatelj moºe jednom primatelju poslati vi²e poruka (svaku u drugo vrijeme), stoga e u toj relaciji vrijediti sljede a funkcijska ovisnost: posiljateljid primateljid vrijeme slanja tekstid. Proces kojim se iz baze, odnosno iz relacijskih shema tablica u bazi uklanjaju parcijalne, tranzitivne i vi²ezna ne ovisnosti, naziva se normalizacija. Denicija 2.4 (Prva normalna forma) Kaºemo da je relacija u prvoj normalnoj formi (1NF), ako je vrijednost svakog atributa nedjeljiva (jednostruka) - tj. kad je vrijednost svakog atributa samo jedna vrijednost iz domene tog atributa, te kad neklju ni atributi relacije funkcijski ovise o klju u relacije.

12 2 LOGIƒKI DIZAJN BAZE PODATAKA 10 Slika 2.1 Relacijske sheme relacija profesor, student i gostujuci student Promotrit emo sada samo one relacije koje nam mogu biti sporne po pitanju 1NF. Najprije pogledajmo relaciju student i relaciju profesor. U njima se traºi samo jedan broj mobitela, jedan broj telefona i jedna adresa, a tako se i pretpostavlja da e kao korisnici unijeti. Ukoliko netko ima vi²e brojeva mobitela, telefona, ili vi²e adresa, upisuje samo onu primarnu. Tipovi podatka su tako osmi²ljeni da ne dozvoljavaju unos dvije vrijednosti za atribut (telefon VARCHAR(15), mobitel VARCHAR(15), VARCHAR(35)), a na aplikacijskoj razini, kad bi se ba² i²lo napraviti web su elje za bazu, moglo bi se preko regularnih izraza sprije iti ak i poku²aj unosa dvostruke vrijednosti tako da se onemogu i razmak. Promotrimo sada relaciju gostujuci student. Iako student moºe studirati na vi²e fakulteta, ako se radi o gostuju em studentu, on dolazi u ime samo jedne ustanove na kojoj studira, pa je relacija u 1NF. Kako su i sve ostale relacije (osim nabrojanih) u 1NF, baza je u 1NF. Denicija 2.5 (Druga normalna forma) Relacija je u drugoj normalnoj formi (2NF), ako je u 1NF i ako je svaki neklju ni atribut potpuno funkcijski ovisan o bilo kojem klju u relacije.

13 2 LOGIƒKI DIZAJN BAZE PODATAKA 11 U bazi je u svakoj relaciji svaki neklju ni atribut potpuno funkcijski ovisan o bilo kojem klju u relacije, tj. sve relacije su u 2NF, pa je i baza u 2NF. Da bismo govorili o tre oj normalnoj formi, najprije moramo denirati pojam tranzitivne ovisnosti. Denicija 2.6 (Tranzitivna ovisnost) Zadana je relacijska shema R(X, Y, Z) i skupovi atributa X R, Y R, Z R. Skup atributa Z je tranzitivno ovisan o skupu atributa X ako vrijedi X Y, Y ne povla i funkcijski X i Y Z. Sada moºemo denirati i tre u normalnu formu. Denicija 2.7 (Tre a normalna forma) Relacijska shema je u tre oj normalnoj formi (3NF) ako je u 1NF i ako nijedan atribut iz zavisnog dijela (tj. atribut s desne strane strelice u funkcijskoj ovisnosti) nije tranzitivno funkcijski ovisan o bilo kojem klju u relacije. Slika 2.2 Relacijske sheme relacija nastavne titule i znanstvene titule Promotrimo sada relacije koje nam na prvi pogled mogu djelovati sporne po pitanju tranzitivne ovisnosti. Radi se o relacijama nastavne titule i znanstvene titule. Budu i da imaju prili no sli ne relacijske sheme, dovoljno je na jednoj objasniti slu aj. Uzmimo za primjer relaciju nastavne titule i njezine atribute. Promotrimo funkcijske ovisnosti koje u njoj vrijede: ntitulaid naziv ntitule naziv ntitule kratica ntitule

14 2 LOGIƒKI DIZAJN BAZE PODATAKA 12 naziv ntitule ntitulaid. Uo imo, zbog zadnje funkcijske ovisnosti se ipak ne radi o tranzitivnoj ovisnosti atributa ntitulaid i atributa kratica ntitule, pa je relacija u 3NF. Na isti na in se pokaºe za relaciju znanstvene titule i njezine atribute. Prema [4, str. 39], navedimo najprije deniciju natklju a relacije, a potom moºemo denirati Boyce-Coddovu normalnu formu. Denicija 2.8 (Natklju relacije) Za k- lani skup atributa {A i1... A ik } {A 1... A n } kaºemo da je natklju relacije R (koja ima atribute A 1... A n ), 1 k n, ako on funkcijski odrežuje sve atribute iz pripadne relacijske sheme. Denicija 2.9 (Boyce-Coddova normalna forma) Kaºemo da je relacija R u Boyce- Coddovoj normalnoj formi (BCNF) ako u svakoj netrivijalnoj 7 funkcijskoj ovisnosti oblika A 1... A n B 1... B m, skup atributa {A 1,... A n } predstavlja natklju relacije R, odnosno ako je u 1NF i ako niti jedan atribut nije tranzitivno ovisan o bilo kojem klju u relacije. Promotrimo ponovno funkcijske ovisnosti iz Primjera 2.1. Uo imo kako atribut userid funkcijski odrežuje sve atribute iz pripadne relacijske sheme, pa je on natklju relacije (korisnik). Takožer, atribut username funkcijski odrežuje sve atribute pripadne relacijske sheme, pa je i on natklju iste relacije. Svaka tablica u bazi je u BCNF, pa je i cijela baza u BCNF. U praksi se naj e² e baza dovodi do 3NF i rijetki su slu ajevi (iako postoje) da baza podataka zadovoljava 3NF, a istovremeno ne zadovoljava BCNF. Zato emo kod toga stati s normalizacijom. Postoje jo² 4NF, 5NF i 6NF (vidi [5]). 7 Netrivijalna funkcijska ovisnost je ona funkcijska ovisnost u kojoj skup atributa s lijeve strane strelice ili uop e ne povla i sam sebe ili neki od svojih podskupova, ili uz to povla i bar jo² jedan atribut koji nije s lijeve strane strelice.

15 3 IMPLEMENTACIJA BAZE PODATAKA 13 3 Implementacija baze podataka Baza podataka za sveu ili²nu dru²tvenu mreºu implementirana je u MySQL-u, najprije u verziji , a potom u verziji m13. Gra ki prikaz baze podataka izražen je preko alata MySQL Workbench. Detaljnije o gra kom prikazu i o implementaciji nalazi se u Dodatku B. U ovom poglavlju govorit emo o ograni enjima, okida ima, prikazima, indeksima, te o pohranjenim procedurama i funkcijama. 3.1 Ograni enja i okida i Kreiraju i bazu podataka, suo avamo se i s mogu no² u da promjena, brisanje ili unos novih podataka u bazu mogu biti pogre²ni na nekoliko na ina. Jedan od primjera mogu biti pogre²ke u prijepisu pri ru nom unosu podataka. Zbog toga e nam biti potrebna ograni enja 8 i okida i 9, tzv. aktivni elementi SQL-a. Radi se o izrazima ili tvrdnjama koje jednom spremimo u bazu, o ekuju i da e se izvr²iti u pravi trenutak (npr. prije ili poslije unosa novog retka, brisanja starog ili modikacije postoje eg). Pri tome, ograni enja koristimo kako bismo dohvatili pogre²ke pri unosu podataka, dok su okida i dinami niji koncept. Pojasnimo to na ovaj na in: dok ograni enja govore o stanju baze, okida i govore o tome na koji se na in baza razvija dalje. Okida i su poznati po tome ²to reagiraju na neki dogažaj (npr. unos novog retka, brisanje starog ili modikacija postoje eg), te provjeravaju uvjete na bazi, i u slu aju da su uvjeti ispunjeni, izvr²avaju akciju (ili akcije). Uvjet moºe biti prekr²aj ograni enja ili ne²to op enitije. Dakle, ograni enja i okida i sluºe kako bismo nadgledali stanje u bazi Ograni enja Navedimo sada vrste ograni enja kojima emo se detaljnije baviti u MySQL standardu: ograni enja ne NULL vrijednosti 10, 8 engl. constraints 9 engl. triggers 10 engl. not-null constraints

16 3 IMPLEMENTACIJA BAZE PODATAKA 14 ograni enja na klju 11 i strani klju 12 (referencijalni integritet 13 ). Ograni enja ne NULL vrijednosti Prilikom susreta s bazama podataka i tablicama, nerijetko se dogaža slu aj kada ºelimo obavezan unos nekog atributa u n-torci, tj. ne ºelimo dopustiti mogu nost da takav atribut poprimi NULL vrijednost. To ograni enje se postiºe stavljanjem rije i NOT NULL nakon tipa podatka pojedinog atributa pri deniranju tablice. Slika 3.1 Relacijska shema relacije drzava Primjer 3.1 (Primjer NOT NULL vrijednosti atributa) Promotrimo tablicu drzava (njezina relacijska shema se nalazi na Slici 3.1). Ne bi bilo prakti no kada bismo dopustili da bilo koji od atributa drzavaid i ime drzave ima vrijednost NULL. Zbog toga u kodu stvaranja tablice stavljamo pored tipa podatka svakog od ta dva atributa klju ne rije i NOT NULL: CREATE TABLE IF NOT EXISTS drzava ( drzavaid TINYINT UNSIGNED NOT NULL AUTO_INCREMENT, ime_drzave VARCHAR(30) NOT NULL, PRIMARY KEY (drzavaid)) ENGINE = InnoDB; Ograni enja na klju i strani klju (referencijalni integritet) 11 engl. key constraints 12 engl. foreign key constraints 13 engl. referential integrity constraints

17 3 IMPLEMENTACIJA BAZE PODATAKA 15 Prema Deniciji 2.3, vidjeli smo da je klju relacije atribut ili skup atributa koji jednozna no odrežuje svaku n-torku u relaciji (tablici). Izmežu svih mogu ih izbora za klju pojedine relacije, dizajner baze bira tzv. primarni klju, pomo u kojeg se n-torka moºe prona i u bazi tako da navedemo vrijednosti atributa koji ine primarni klju. Za pronalaºenje n- torki moºemo koristiti bilo koji klju relacije, no SUBP o ekuje navoženje primarnog klju a. Neki od SUBP kreiraju indekse 14 na primarnom klju u, kako bi pretraºivanje bilo ekasnije. Klju ne rije i pomo u kojih neke atribute progla²avamo klju em su PRIMARY KEY (za primarni klju ) i UNIQUE (za jedinstvenu vrijednost). No, treba naglasiti da svaka relacija moºe imati jedan primarni klju, te vi²e jedinstvenih vrijednosti ili jedinstvenih kombinacija pojedinih atributa. U Primjeru 3.1 vidimo atribut drzavaid kao primarni klju relacije drzava. Osim klju a koji osigurava jedinstvenost n-torki, potrebno je objasniti i pojam klju a koji se poziva na ve postoje i primarni klju neke relacije, odnosno klju a koji se poziva na ve postoje e n-torke. Takav se klju zove strani klju, a moºe se denirati na dva na ina: 1. Navoženjem rije i REFERENCES nakon imena i tipa atributa kod deniranja tablice, a potom ime tablice i naziv atributa (koji mora biti primarni klju ili jedinstvena vrijednost u tablici koja ga sadrºi) na koji prethodno navedeni atribut referencira. 2. Pomo u klju nih rije i FOREIGN KEY (<atributi>) REFERENCES <tablica>(<atributi>). Moºe se koristiti i za vi²e atributa koji bi zajedno inili strani klju. Ovdje jo² dobro dože napomenuti kako pojava NULL vrijednosti u atributu stranog klju a ne kr²i ograni enje stranog klju a. Mežutim, pojava NULL vrijednosti za atribut primarnog klju a nije dozvoljena (jer primarni klju odrežuje n-torku na jedinstven na in). Primjer drugog na ina deniranja stranog klju a pojavljuje se u radu u tablici naziv grada, kada se atribut drzavaid iz tablice naziv grada poziva na atribut drzavaid iz tablice drzava. Primjer 3.2 (Deniranje stranog klju a) Promotrimo relaciju naziv grada (njezina je relacijska shema prikazana na Slici 3.2.). šelimo dopustiti uno²enje samo onih vrijednosti za atribut drzavaid koje ve postoje za istoimeni atribut u tablici drzava. Kako bismo zadovoljili uvjet referencijalnog integriteta, u kreiranju tablice stavljamo klju ne rije i FOREIGN KEY (drzavaid) REFERENCES drzava (drzavaid). Pogledajmo sada deniciju tablice: 14 O indeksima e vi²e rije i biti kasnije, u potpoglavlju

18 3 IMPLEMENTACIJA BAZE PODATAKA 16 Slika 3.2 Povezanost tablica naziv grada i drzava CREATE TABLE IF NOT EXISTS naziv_grada ( gradid INT UNSIGNED NOT NULL, postanski_broj INT UNSIGNED NOT NULL, naziv_grada VARCHAR(45) NOT NULL, drzavaid TINYINT UNSIGNED NOT NULL, PRIMARY KEY (gradid), CONSTRAINT drzavaid02 FOREIGN KEY (drzavaid) REFERENCES drzava (drzavaid) ON DELETE RESTRICT ON UPDATE CASCADE) ENGINE = InnoDB; Ostalo nam je objasniti jo² nekoliko naredbi vezanih uz kod. Naredba CONSTRAINT daje ime pojedinom ograni enju. U na²em se slu aju ograni enje prethodno spomenutog stranog klju a zove drzavaid02. Klju ne rije i ON DELETE nam govore ²to e se dogoditi s atributom drzavaid u tablici naziv grada nakon brisanja retka iz tablice drzava, a klju na rije on RESTRICT zabranjuje brisanje. Drugim rije ima, nije dozvoljeno brisanje drºave u kojoj imamo naveden grad u bazi. Klju ne rije i ON UPDATE nam govore ²to e se dogoditi s atributom drzavaid u tablici naziv grada nakon aºuriranja atributa drzavaid u tablici drzava, a klju na rije CASCADE zna i kaskadiranje. Drugim rije ima, kad bismo svim drºava u bazi pove ali atribut drzavaid za 500, automatski bi se aºurirali istoimeni atributi u tablici naziv grada (kaskadirano bi im se atribut drzavaid pove ao za 500). Promotrimo sada jo² jednom dvije tablice koje smo prethodno naveli. naru²iti referencijalni integritet? Svaka od sljede e etiri akcije: to bi moglo Unos retka tablice (n-torke) naziv grada kojem atribut drzavaid nema NULL vrijednost, ali ne pripada nijednom atributu drzavaid iz tablice drzava.

19 3 IMPLEMENTACIJA BAZE PODATAKA 17 Promjena retka tablice (n-torke) naziv grada nakon koje atribut drzavaid nema NULL vrijednost, ali ne pripada nijednom atributu drzavaid iz tablice drzava. Brisanje n-torke iz tablice drzava za koju postoji atribut drzavaid u tablici naziv grada koji se referencira na njen drzavaid. Aºuriranje n-torke u tablici drzava koje mijenja atribut drzavaid, na koji se referencira atribut drzavaid iz tablice naziv grada. Dok prve dvije akcije zaista naru²avaju referencijalni integritet, te ih kao takve sustav odbacuje, za zadnje dvije akcije imamo izbor (prema MySQL standardu): RESTRICT (zabrani) - odbija se bilo koja promjena koja kr²i referencijalni integritet; ne dopu²ta brisanje ili aºuriranje atributa drzavaid iz tablice drzava za koji postoji grad u tablici naziv grada koji na njega referencira. CASCADE (kaskadiraj) - brisanjem drºave iz relacije drzava bi se automatski obrisali svi redci u relaciji naziv grada kojima je atribut drzavaid jednak obrisanom atributu drzavaid, a promjenom (aºuriranjem) istog atributa, automatski bi se atributi drzavaid iz tablice naziv grada aºurirali s njim. SET NULL - obri²emo li redak ili aºuriramo atribut drzavaid iz tablice drzava za koji postoji grad u tablici naziv grada koji na njega referencira, automatski e se postaviti vrijednost atributa drzavaid iz tablice naziv grada na NULL. Vrijedi napomenuti da se svaka od te tri opcije u MySQL standardu moºe izabrati za brisanje (nakon rije i ON DELETE ide sintagma klju nih rije i pojedine akcije) i aºuriranje (sintagma ide nakon rije i ON UPDATE), kao ²to smo imali slu aj u Primjeru 3.2. Izmjena ograni enja Ograni enja moºemo dodavati, mijenjati i brisati. Da bismo mijenjali ili obrisali pojedino ograni enje, nuºno je dodijeliti mu ime. To se postiºe pomo u klju nih rije i CONSTRAINT <ime ograni enja>. Imenovanje ograni enja pokazuje se dobrom praksom, jer omogu uje naknadne izmjene. Osim toga, u slu aju gre²ke (prouzrokovane kr²enjem ograni enja), dobit emo obavijest o kojem se ograni enju radi. U Primjeru 3.2 imamo ograni enje nazvano drzavaid02 koje ozna ava strani klju. Podsjetimo se tog primjera:

20 3 IMPLEMENTACIJA BAZE PODATAKA 18 CONSTRAINT drzavaid02 FOREIGN KEY (drzavaid) REFERENCES drzava (drzavaid) ON DELETE RESTRICT ON UPDATE CASCADE Brisanje ograni enja se moºe posti i pomo u klju nih rije i ALTER TABLE <ime tablice> DROP CONSTRAINT <naziv ograni enja>. Za na² prethodno naveden primjer, sintaksa je sljede a: ALTER TABLE naziv_grada DROP CONSTRAINT drzavaid02; šelimo li ponovno uvesti prethodno obrisana ograni enja, ili dodati nova, koristimo sljede e klju ne rije i: ALTER TABLE <ime tablice> ADD CONSTRAINT <naziv ograni enja> <ograni enje>. Vrijedi napomenuti kako ograni enje mora biti udruºeno s n-torkama, npr. ograni enje koje provjerava klju ili ograni enje stranog klju a, te da ne moºemo dodati ograni enje na tablicu ako ono ne vrijedi za svaku ve postoje u n-torku u toj tablici. šelimo li ponovno uvesti prethodno obrisano ograni enje, to postiºemo na sljede i na in: ALTER TABLE naziv_grada ADD CONSTRAINT drzavaid02 FOREIGN KEY (drzavaid) REFERENCES drzava (drzavaid) ON DELETE RESTRICT ON UPDATE CASCADE; Okida i Ve smo u uvodu govora o ograni enjima i okida ima spomenuli kako su okida i poznati po tome ²to reagiraju na neki dogažaj. Zapravo, cijela pri a o okida ima vezana je uz sintagmu dogažaj-uvjet-akcija 15. Kad se dogažaj pojavi, provjeri uvjet; ako je istinit, poduzmi akciju. Za²to ih koristimo? Kako bismo premjestili logiku kontroliranja baze sa same aplikacije na SUBP 16, te kako bismo primijenili ograni enja (izvan onoga ²to sustav ograni enja podrºava). MySQL standard vezan uz okida e 15 engl. event-condition-action (ECA) 16 SUPB=sustav za upravljanje bazom podataka (engl. database management system)

21 3 IMPLEMENTACIJA BAZE PODATAKA 19 U ovom radu emo govoriti o MySQL standardu 17 vezanom uz okida e. Najprije nekoliko rije i o kratici dogažaj-uvjet-akcija: 1. Dogažaj - to je ono ²to poziva ili pokre e pojedini okida (naj e² e je u pitanju unos, brisanje ili aºuriranje redaka pojedine relacije). 2. Uvjet - boolean izraz koji okida provjerava nakon ²to se pojavio dogažaj. Ukoliko uvjet nije ispunjen, ni²ta se dalje ne dogaža iz okida a, a ako je ispunjen, izvr²ava se akcija. 3. Akcija - SQL iskaz(i). Akciju moºe initi bilo koji niz operacija nad bazom, jedino u MySQL-u nije dopu²tena akcija na tablici na kojoj se pojavio dogažaj koji pokre e okida. Sintaksa okida a u MySQL-u je sljede a: [delimiter <oznaka>] CREATE TRIGGER ime_okidaca BEFORE AFTER dogadjaj FOR EACH ROW [BEGIN] akcije [END <oznaka>] [delimiter ;] Objasnimo sada svaki dio posebno: CREATE TRIGGER ime okidaca - kreira okida koji se naziva ime okidaca BEFORE AFTER dogadjaj - pokazuje dogažaj koji pokre e okida i govori o tome na koji na in okida koristi stanje baze (tj. koristi li stanje u bazi prije nego ²to se dogažaj koji je pokrenuo okida izvr²io, ili stanje u bazi nakon samog dogažaja) dogadjaj - moºe biti unos retka ili redaka u neku relaciju, brisanje retka ili redaka iz neke relacije, ili njihovo aºuriranje. Ograni en je samo na cijelu n-torku, tj. dogadjaj = INSERT UPDATE DELETE ON imetablice. 17 MySQL standard je implementacija SQL standarda vezanog uz okida e za MySQL SUBP. Vi²e o samom SQL standardu moºe se na i na [3, str ]

22 3 IMPLEMENTACIJA BAZE PODATAKA 20 atribut starog 18 retka se ozna ava sa OLD.imeatributa, a atribut novog 19 retka sa NEW.imeatributa, pri emu OLD.imeatributa vrijedi samo za DELETE i UPDATE okida e, a NEW.imeatributa samo za INSERT i UPDATE okida e FOR EACH ROW - okida na razini retka 20. Na primjer, ako aºuriramo cijelu tablicu pomo u iskaza UPDATE, onda e se okida na razini retka izvr²iti jednom za svaki redak koji je aºuriran. BEGIN...END - u svakom okida u moºe biti jedna ili vi²e akcija. U slu aju vi²e akcija, razdvojene su pomo u znaka ';', te okruºene klju nim rije ima BEGIN...END i u tom je slu aju potrebno postaviti neku drugu oznaku kao grani nik 21 (umjesto ';') - to postiºemo naredbom delimiter <oznaka>, npr. delimiter // i nakon rije i END stavimo tu oznaku, a nakon okida a vratimo grani nik ';' (delimiter ;). akcije - zapravo je rije o jednom ili vi²e SQL iskaza U radu smo koristili okida e naj e² e za unos i aºuriranje podataka aktivne baze s povijesnom bazom. Okida za unos bi imao naziv imetablice pov ins, a okida za aºuriranje bi se zvao imetablice pov upd. Promotrimo takve primjere na relaciji drzava. Primjer 3.3 (Okida drzava pov ins u MySQL-u) Navedimo najprije relacijsku shemu relacije drzava za potrebe ovog i sljede eg primjera. drzava(drzavaid, ime drzave) šelimo svaku drºavu koja se unosi u aktivnu bazu ujedno upisati u povijesnu bazu. postiºemo sljede im okida em: To CREATE TRIGGER drzava_pov_ins BEFORE INSERT ON aktivna.drzava FOR EACH ROW INSERT INTO povijesna.drzava VALUES(NEW.drzavaID, NEW.ime_drzave); Objasnimo sada pojedine dijelove koda. Okida drzava pov ins se aktivira prije unosa u tablicu drzava u aktivnoj bazi (BEFORE INSERT ON aktivna.drzava), te za svaki une²eni 18 Stari redak nam, kad se radi o operaciji brisanja, ozna ava onaj redak koji dogažajem koji pokre e okida bri²emo. No, kada se radi o operaciji aºuriranja, stari redak ozna ava ono stanje retka koje je bilo prije aºuriranja koje je pokrenulo okida. Stari redak se koristi samo kod operacija brisanja i aºuriranja, nema ga kad se radi o unosu. 19 Novi redak nam, kad se radi o operaciji unosa, ozna ava onaj redak koji se unosi operacijom koja pokre e okida. No, kada se radi o operaciji aºuriranja, novi redak ozna ava stanje retka nakon aºuriranja koje je pokrenulo okida 20 engl. row-level trigger 21 engl. delimiter

23 3 IMPLEMENTACIJA BAZE PODATAKA 21 redak (FOR EACH ROW) unosi vrijednosti retka u tablicu drzava u povijesnoj bazi. Klju na rije NEW uz ime atributa ozna ava vrijednost koju e taj atribut imati nakon operacije unosa u aktivnoj bazi. Drugim rije ima, u tablicu drzava u povijesnoj bazi unosimo prije unosa u istoimenu tablicu aktivne baze one vrijednosti atributa svakog une²enog retka koje bi ti atributi imali nakon unosa u tablicu drzava u aktivnoj bazi (i u tom primjeru vidimo kako se okida izvr²ava prije izvr²avanja radnje dogažaja zbog kojeg se pokrenuo). Primjer 3.4 (Okida drzava pov upd u MySQL-u) šelimo osigurati usklaženost aktivne i povijesne baze po pitanju aºuriranja tablica. Sljede i okida osigurava usklaženost tablice drzava u aktivnoj i u povijesnoj bazi: CREATE TRIGGER drzava_pov_upd BEFORE UPDATE ON aktivna.drzava FOR EACH ROW UPDATE povijesna.drzava SET drzavaid=new.drzavaid, ime_drzave=new.ime_drzave WHERE drzavaid=old.drzavaid; Objasnimo sada pojedine dijelove koda. Okida drzava pov upd se aktivira prije aºuriranja redaka u tablici drzava u aktivnoj bazi (BEFORE UPDATE ON aktivna.drzava), te za svaki aºurirani redak (FOR EACH ROW) mijenja vrijednosti istog retka u tablici drzava u povijesnoj bazi. Klju na rije NEW uz ime atributa ozna ava vrijednost koju e taj atribut imati nakon operacije aºuriranja u aktivnoj bazi, dok klju na rije OLD uz ime atributa ozna ava vrijednost koju taj atribut ima prije iste operacije aºuriranja. Drugim rije ima, akcija okida a je aºuriranje retka tablice drzava u povijesnoj bazi onim vrijednostima atributa koje bi trebao poprimiti za atribute koji se aºuriraju u aktivnoj bazi istoimene tablice (a okida se izvr²ava prije tog dogažaja). Okida prepozna redak koji treba aºurirati po klju u (WHERE drzavaid=old.drzavaid;). Primjer 3.5 (Okida i koji bri²u dijeljenje informacija sa samim sobom) Budu i da MySQL ne podrºava brisanje podataka iz tablice na kojoj je dogažaj pokrenuo okida, morali smo napraviti dva okida a, jedan na unos retka u tablicu aktivne baze koja sadrºi zapise o dijeljenju informacija (AFTER INSERT ON aktivna.dijeli informacije) bri²e retke iz povijesne baze u kojima korisnici dijele informacije sami sa sobom (DELETE FROM povijesna.dijeli informacije WHERE userid=userid2;). A nakon brisanja iz tablice povijesne baze koja sadrºi podatke o dijeljenju informacija (AFTER DELETE ON povijesna.dijeli informacije), aktivira se okida koji iz aktivne baze bri²e podatke o osobama koje su same sa sobom podijelile informacije (DELETE FROM

24 3 IMPLEMENTACIJA BAZE PODATAKA 22 Slika 3.3 Relacijske sheme relacija korisnik i dijeli informacije, te veze izmežu te dvije relacije aktivna.dijeli informacije WHERE userid=userid2;). Ovdje ujedno vidimo i primjer ulan anih okida a. USE aktivna; CREATE TRIGGER obrisi_dijeljenje_sa_samim_sobom AFTER INSERT ON aktivna.dijeli_informacije FOR EACH ROW DELETE FROM povijesna.dijeli_informacije WHERE userid=userid2; USE povijesna; CREATE TRIGGER obrisi_dijeljenje_sa_samim_sobom AFTER DELETE ON povijesna.dijeli_informacije FOR EACH ROW DELETE FROM aktivna.dijeli_informacije WHERE userid=userid2; USE aktivna; Svaki okida se moºe obrisati naredbom DROP TRIGGER [imebaze.]<ime okida a>. U

25 3 IMPLEMENTACIJA BAZE PODATAKA 23 na²im primjerima, to bi bilo ovako: DROP TRIGGER drzava_pov_ins; DROP TRIGGER drzava_pov_upd; DROP TRIGGER obrisi_dijeljenje_sa_samim_sobom; DROP TRIGGER povijesna.obrisi_dijeljenje_sa_samim_sobom; Korisne napomene o okida ima u MySQL-u Okida i u MySQL-u imaju nekoliko ograni enja. Ovdje emo navesti samo ona vezana uz rad, a vi²e o ograni enjima u MySQL-u se moºe prona i na [11] i [12]: U MySQL-u je dopu²ten 22 samo jedan okida vezan uz pojedino vrijeme i pojedinu akciju za odreženu tablicu. Npr. ne moºemo imati dva okida a koja e se aktivirati nakon unosa retka u neku tablicu. MySQL ne podrºava izvr²avanje akcija okida a na tablici na kojoj je dogažaj pokrenuo okida. Gre²ka tijekom BEFORE ili AFTER okida a rezultira neuspjehom cijelog dogažaja koji je pokrenuo okida e. Potrebno je napomenuti koliko je vaºno biti oprezan s kori²tenjem okida a, jer ulan ane aktivnosti okida a i nepredvidljivi redoslijed u kojem SUBP izvr²ava aktivne okida e, moºe oteºati razumijevanje efekta kori²tenja vi²e okida a. 3.2 Prikazi i indeksi Do sada smo govorili samo o tablicama - temeljnim relacijama 23. No vrijedi spomenuti kako osim tog pojma, pod pojmom relacija moºemo misliti i na druga dva pojma: na virtualne relacije (prikaze) 24 i na privremene relacije 25 (privremene tablice). U ovom poglavlju, upoznat emo se s prikazima. Prikazi su relacije kojima su shema i sadrºaj opisani kao SQL upit nad temeljnim relacijama ili nad ve postoje im prikazima. Nisu pohranjeni u bazi, ali se 22 Ovo ograni enje je vrijedilo do verzije U njoj se moºe dogoditi da se na isti dogažaj u istoj tablici aktivira vi²e okida a, ali se mora nazna iti redoslijed. To se postiºe tako da se u okida u nakon klju nih rije i FOR EACH ROW napi²e [PRECEDES FOLLOWS] imedrugogokidaca, ime se odrežuje ho e li se ovaj okida dogoditi prije ili poslije okida a koji se zove imedrugogokidaca. 23 engl. base relation - trajno pohranjena relacija (tablica) 24 engl. virtual relations (views) 25 engl. temporary relation (temporary table) - relacija koja nije prikaz, a nije ni trajno spremljena, nego moºe biti konstrurana za neki podupit i sl.

26 3 IMPLEMENTACIJA BAZE PODATAKA 24 mogu izvr²iti upiti nad njima, kao da postoje, jer e procesor upita 26 zamijeniti prikaz njegovom denicijom tako da izvr²i upit iz prikaza. Sadrºaj virtualnog prikaza se dinami ki 27 odrežuje u samom trenutku kad se nad virtualnom relacijom izvr²i neka operacija (jer ovisi o trenutnom stanju temeljnih tablica). Moºemo promatrati 3 sloja baze podataka - zi ki, konceptualni i logi ki. Podaci pohranjeni na disk ine zi ki sloj, organizacija podataka na disku u relacije ini konceptualni sloj, a prikazi ine logi ki sloj. Za²to koristimo prikaze? Navedimo dva naj e² a razloga. Jedan je mogu nost sakrivanja pojedinih podataka od pojedinih korisnika. Drugi razlog je u initi neke upite jednostavnijima i prirodnijima. Pored prikaza, u ovom emo poglavlju govoriti i o indeksima - strukturi podataka koja sluºi kako bi se pristup odreženim redcima ubrzao. Bit e rije i i o tome koje sve injenice treba uzeti u obzir vezano uz izbor indeksa za pojedinu tablicu Virtualni prikazi Sintaksa za prikaz u MySQL-u je: CREATE [OR REPLACE] VIEW ime_prikaza [(lista_atributa)] AS definicija_prikaza [WITH [CASCADED LOCAL] CHECK OPTION]; Objasnimo sada pojedine dijelove (ovaj je dio uglavnom preuzet iz [12]): CREATE VIEW - stvara novi prikaz CREATE OR REPLACE VIEW - stvara novi prikaz, ako prikaz ne postoji (djeluje kao CREATE VIEW), ili mijenja postoje i (djeluje kao ALTER VIEW) ime prikaza - prikaz ne smije imati isto ime kao bilo koja tablica ili prikaz u bazi definicija prikaza - po inje sa SELECT klauzulom i moraju vrijediti sljede a ograni enja: - SELECT iskaz ne smije sadrºavati upit u FROM klauzuli, a ne smije se odnositi na korisni ke varijable. 26 engl. query processor 27 tj. SUBP dinami ki odrežuje sadrºaj virtualnih relacija pri izvr²avanju svakog upita koji koristi tu virtualnu relaciju

27 3 IMPLEMENTACIJA BAZE PODATAKA 25 - Prikaz je "zamrznut" pri stvaranju, pa promjene na tablici koja je u pozadini ne utje u na deniciju prikaza (npr. prikaz koji u deniciji ima SELECT * za tablicu ne e prikazivati stupce koji su naknadno dodani u tu tablicu). - Svaka tablica ili prikaz koji su u deniciji prikaza moraju postojati u trenutku kad se prikaz kreira; mežutim, nakon stvaranja prikaza mogu e je obrisati tablicu ili prikaz na koje denicija upu uje. U tom slu aju, kori²tenje prikaza dovodi do gre²ke. Kako bismo provjerili ima li denicija prikaza problem takve vrste, moºemo koristiti SQL iskaz CHECK TABLE <ime tablice ili prikaza>, koji e javiti postoji li odrežena tablica ili prikaz na koje se pozivamo u deniciji prikaza, ili ne postoji. - Denicija prikaza se ne moºe pozivati na privremenu tablicu (TEMPORARY TABLE) i ne moºe stvoriti privremeni prikaz (TEMPORARY VIEW). - Prikaz moºe biti napravljen pomo u vi²e SELECT klauzula. Moºe upu ivati na temeljne tablice ili ostale prikaze, moºe koristiti spajanje, uniju ili podupite. SELECT se ak ne mora pozivati ni na jednu tablicu (npr. moºe ra unati neki izraz i tako nazvati stupac), a moºe se raditi i o izrazima koji koriste funkcije, konstantne vrijednosti, operatore i sl. - Alias za ime stupca u SELECT iskazu se provjerava na maksimalnu duljinu stupca (64 znaka), a ne na maksimalnu duljinu aliasa (256 znakova). ORDER BY je dopu²teno u deniciji prikaza, ali se ignorira ako selekcija u prikazu ima vlastiti ORDER BY WITH CHECK OPTION se koristi za izmjenjive 28 prikaze, kako se ne bi dopustio unos ili aºuriranje redaka, osim onih za koje je WHERE klauzula u deniciji prikaza istinita. Pri tome imamo izbor: - LOCAL - ograni ava CHECK OPTION samo na onaj prikaz koji se denira, - CASCADED - provjerava evaluaciju i ishodi²nih prikaza, a ne samo onog koji trenutno stvaramo; podrazumijeva se kao zadana opcija ako smo stavili klju ne rije i WITH CHECK OPTION, a nismo naveli nijednu od rije i LOCAL ili CASCADED. U samom radu, prikaze smo koristili najvi²e u slu ajevima kada je trebalo povezati tablice, kako bismo mogli prikazati informacije. Ukoliko prikaz postoji za tablicu imetablice, on se u radu naziva imetablice prikaz. Ovdje emo kao primjer navesti prikaz naziv grada prikaz, koji umjesto atributa drzavaid iz relacije naziv grada ima atribut 28 O izmjenjivim prikazima u MySQL-u e biti vi²e rije i u potpoglavlju 3.2.2, a primjer spomenute opcije nalazi se u potpoglavlju

28 3 IMPLEMENTACIJA BAZE PODATAKA 26 ime drzave iz relacije drzava. No, prije samog primjera, moramo navesti deniciju prirodnog spoja kako bismo mogli objasniti primjer. Denicija 3.1 (Prirodni spoj dvaju tablica s istoimenim atributima) Neka je R(A,B) relacija u kojoj je skup atributa A mežusobno disjunktan skupu atributa B, te S(B,C) relacija u kojoj je skup atributa B mežusobno disjunktan skupu atributa C, pri emu su skupovi atributa A i C mežusobno disjunktni. Prirodni spoj RS relacija R i S e imati relacijsku shemu RS(A,B,C) i sadrºavat e sve retke nastale spajanjem redaka relacije R i redaka relacije S koji se podudaraju u vrijednostima zajedni kog skupa atributa B. Primjer 3.6 (Prikaz drºave uz svaki navedeni grad - naziv grada prikaz) šelimo uz svaki grad upisan u bazu imati navedeno ime drºave umjesto atributa drzavaid. Za potrebe ovog primjera, ponovimo relacijske sheme temeljnih tablica koje se nalaze u deniciji prikaza: drzava(drzavaid, ime drzave) naziv grada(gradid, postanski broj, naziv grada, drzavaid) To emo posti i tako da napravimo prirodni spoj tablice drzava i tablice naziv grada, a potom izaberemo sve atribute, osim atributa drzavaid: CREATE VIEW naziv_grada_prikaz AS SELECT gradid, postanski_broj, naziv_grada, ime_drzave FROM drzava NATURAL JOIN naziv_grada; Upiti se mogu izvr²iti nad prikazima, kao i nad pohranjenim tablicama. Ime prikaza spomenemo u FROM klauzuli, oslanjaju i se na SUBP, koji e do i do odreženih n-torki operacijama nad relacijama iz denicije virtualnog prikaza. Primjer 3.7 (Prikaz korisnik prikaz koji navodi mjesto roženja korisnika) šelimo uz svakog korisnika imati naveden po²tanski broj i naziv grada u kojem je rožen, te ime drºave. Za potrebe ovog prikaza ponovimo relacijsku shemu relacije korisnik sa Slike 3.3: korisnik(userid, username, password, ime, prezime, spol, datum rodjenja, mjesto rodjenja) te uz to navedemo relacijsku shemu prethodno stvorenog prikaza naziv grada prikaz: naziv grada prikaz(gradid, postanski broj, naziv grada, ime drzave). Prikaz koji ovdje navodimo spaja retke tablice korisnik i prikaza naziv grada prikaz na na in da izjedna ava atribute mjesto rodjenja iz relacije korisnik i gradid iz relacije naziv grada prikaz (korisnik JOIN naziv grada prikaz ON

29 3 IMPLEMENTACIJA BAZE PODATAKA 27 korisnik.mjesto rodjenja=naziv grada prikaz.gradid), te iz njih navodi atribute koje traºimo. Klju na rije AS sluºi za preimenovanje atributa, npr. atribut postanski broj e se u prikazu zvati postanski broj rodnog grada. Donosimo sada kod prikaza. CREATE VIEW korisnik_prikaz AS SELECT userid, username, ime, prezime, spol, datum_rodjenja, postanski_broj AS 'postanski_broj_rodnog_grada', naziv_grada AS 'grad_rodjenja', ime_drzave AS 'drzava_rodjenja' FROM korisnik JOIN naziv_grada_prikaz ON korisnik.mjesto_rodjenja=naziv_grada_prikaz.gradid; Prikaz korisnik prikaz ima relacijsku shemu korisnik prikaz(userid, username, ime, prezime, spol, datum rodjenja, postanski broj rodnog grada, grad rodjenja, drzava rodjenja). Pokaºimo sljede im primjerom na koji se na in upit koji uklju uje virtualni prikaz interpretira. Primjer 3.8 (Interpretacija kori²tenja virtualnog prikaza u upitu drugog prikaza) U ovom primjeru pokazujemo na koji na in SUBP interpretira na² prethodno navedeni prikaz, koji u svojoj deniciji sadrºi prikaz. SUBP napravi Kartezijev produkt svih temeljnih tablica (spoj koji sadrºi sve atribute svake od relacija koje sudjeluju u spoju na na in da svaki redak jedne relacije uparuje sa svakim retkom druge i da spoj sadrºi sve mogu e kombinacije redaka relacija koje u njemu sudjeluju) koje se koriste za deniciju prikaza (u na²em slu aju relacija korisnik, drzava i naziv grada) i potom traºi samo one retke u kojima se atribut drzavaid iz tablice drzava podudara s istoimenim atributom iz tablice naziv grada i u kojima se uz to atribut mjesto rodjenja iz tablice korisnik podudara s atributom gradid iz tablice naziv grada. SUBP interpretira prethodno navedeni prikaz kao da smo izvr²ili sljede i kod. CREATE VIEW korisnik_prikaz AS SELECT userid, username, ime, prezime, spol, datum_rodjenja, postanski_broj AS 'postanski_broj_rodnog_grada', naziv_grada AS 'grad_rodjenja', ime_drzave AS 'drzava_rodjenja' FROM korisnik, drzava, naziv_grada WHERE drzava.drzavaid=naziv_grada.drzavaid AND korisnik.mjesto_rodjenja=naziv_grada.gradid;

30 3 IMPLEMENTACIJA BAZE PODATAKA 28 U praksi, korisnik ne mora brinuti o tome na koji se na in prikazi interpretiraju u SUBP. šelimo li ponekad dati druga ija imena atributima prikaza, moºemo to u initi i na na in 29 da ih navedemo u zagradi nakon imena prikaza u CREATE VIEW iskazu. Brisanje 30 slu aju: prikaza ostvaruje se naredbom DROP VIEW <ime prikaza>, odnosno u na²em DROP VIEW naziv_grada_prikaz; DROP VIEW korisnik_prikaz; Izmjena prikaza i izmjenjivi prikazi Moºemo li mijenjati prikaze? U nekim slu ajevima mogu e je izvesti operacije unosa, brisanja ili aºuriranja na prikaz. Prvo logi no pitanje koje se name e uz tu tvrdnju je kako je to uop e mogu e kad prikazi ne postoje u bazi pohranjeni kao ²to su to temeljne tablice. to bi zapravo zna ilo unijeti novu n-torku u prikaz? Gdje bi ta n-torka zavr²ila, i kako bi se SUBP dosjetio da ta n-torka treba biti u prikazu? Iako u dosta slu ajeva nemogu e, postoje i tzv. izmjenjivi prikazi 31, u kojima je mogu e izmjenu nad njima zapravo usmjeriti na izmjenu nad temeljnim tablicama (navedenima u prikazu). Prije govora o izmjenjivim prikazima, napomenimo ponovno kako SUBP ne moºe promijeniti sadrºaj prikaza, tj. retke tablice koja se formira kao rezultat SQL upita koji je u prikazu. Umjesto toga, SUBP mora promijeniti sadrºaj temeljnih tablica koje se navode u prikazu. Ako je virtualni prikaz deniran tako da SUBP moºe jednozna no odrediti koje operacije mora obaviti na temeljnim tablicama (umjesto na prikazima), tada kaºemo da je prikaz izmjenjiv. Izmjenjivi prikazi u MySQL-u 29 CREATE VIEW imeprikaza(naziv1, naziv2,..., nazivn) AS <definicija prikaza> 30 Vaºno je napomenuti kako taj SQL iskaz bri²e deniciju prikaza (tako da ne moºemo vi²e raditi upite nad prikazom, ili ga izmjenjivati), dok na relacijama koje je prikaz koristio nema promjena. S druge strane, ako obri²emo temeljne tablice (naredbom DROP TABLE <ime tablice>), prikazi koji se pozivaju na te tablice se ne e automatski obrisati, ali e postati neupotrebljivi (budu i da se pozivaju na nepostoje e relacije). 31 engl. updatable views

31 3 IMPLEMENTACIJA BAZE PODATAKA 29 Slijedi nekoliko informacija o izmjenjivim prikazima u MySQL-u, preuzeto iz [11] i [12]. Izmjenjivi prikazi su oni koje moºemo koristiti u izrazima kao ²to su DELETE, UPDATE, INSERT kako bi se preko njih aºurirala temeljna tablica. Kako bi prikaz bio izmjenjiv, mora postojati veza 1-1 izmežu redaka prikaza i redaka ishodi²ne temeljne tablice. Postoje slu ajevi kada prikaz nije izmjenjiv. To nije, prikaz nije izmjenjiv ako sadrºi bilo ²to od sljede eg: agregacijske funkcije (SUM(), MIN(), MAX(), COUNT(), AVG() i sl.), DISTINCT, GROUP BY, HAVING, UNION, UNION ALL, podupite u SELECT listi, odrežene spojeve, neizmjenjiv prikaz u FROM klauzuli, podupit u WHERE klauzuli koji se poziva na tablicu iz FROM klauzule, samo doslovne vrijednosti 32 (tada ne postoji ishodi²na tablica za aºuriranje). Uz navedeno, dodatni uvjeti da se u izmjenjiv prikaz mogu unijeti informacije ( INSERT) su: ne smije postojati dvostruko ime za stupac prikaza, prikaz mora sadrºavati sve stupce iz temeljne tablice koji nemaju zadanu vrijednost DEFAULT, stupci prikaza ne smiju biti izvedeni 33 iz stupaca temeljnih tablica. U prikaz koji ima stupce iz temeljnih tablica i one izvedene se ne mogu unositi redci, ali se mogu aºurirati ako mijenjamo samo one stupce koji nisu izvedeni. 32 eng. literal values, npr. atribut stupac2 u prikazu CREATE VIEW prikaz AS SELECT stupac, 1 AS stupac2 FROM tablica; 33 pojam izvedenog stupca ozna ava stupce koji su rezultat nekog izraza, npr. zbroj, razlika, umnoºak, i sl.

32 3 IMPLEMENTACIJA BAZE PODATAKA 30 Primjer 3.9 (Unos u prikaz ne mora zavr²iti u prikazu) Za potrebe ovog prikaza, navedimo relacijsku shemu 34 relacije koja se nalazi u deniciji prikaza grupa(idgrupe, zipid, naziv, opis) Navedimo sada primjer prikaza zipidje1 koji se ti e naziva i opisa grupa kojima je znanstvenoistraºiva ko podru je jednako 1, te primjer unosa u njega. CREATE VIEW zipidje1 AS SELECT naziv, opis FROM grupa WHERE zipid=1; INSERT INTO zipidje1 VALUES ('nova grupa','moj zipid=1'); to e se dogoditi? Prije izno²enja te injenice, ºelimo napomenuti kako ovaj primjer nemamo u samom radu, nego ga koristimo samo zbog teoretskih razloga. Naime, kako relacija grupa ima atribute IDgrupe i zipid postavljene na NOT NULL, unos ne e biti dozvoljen, jer bi, umjesto u prikaz, podaci trebali biti une²eni u tablicu grupa i to na ovaj na in: (NULL, NULL, 'nova grupa','moj zipid=1'). No, maknemo li rije i NOT NULL kod denicije atributa IDgrupe i zipid u tablici grupa, tada e unos pro i, jer prikaz zipidje1 zadovoljava uvjete (budu i da sadrºi komponente samo jedne temeljne tablice). Unos u prikaz zipidje1 je izvr²en kao da je sljede i unos naveden u tablicu grupa: INSERT INTO grupa(naziv, opis) VALUES ('nova grupa','moj zipid=1'); Redak une²en u tablicu grupa ima vrijednost 'nova grupa' za atribut naziv, te vrijednost 'moj zipid=1' za atribut opis. Atribut IDgrupe e poprimiti kao vrijednost automatski odabran broj koji slijedi nakon prethodno une²enog retka (AUTO INCREMENT), a atribut zipid e poprimiti vrijednost NULL. Uo imo ²to se sada dogaža. Une²eni redak, budu i da ima NULL vrijednost za atribut zipid, ne e prije i u prikaz (koji traºi da zipid ima vrijednost 1), pa sam unos ne utje e na prikaz. Kako bismo to popravili, moºemo dodati atribut zipid u SELECT klauzuli prikaza. Primjer 3.10 (Popravak prikaza zipidje1) Pou eni prethodno navedenim primjerom kako unos retka u prikaz ne mora zavr²iti u prikazu, preradimo prikaz zipidje1 tako da u njega (osim atributa navedenih u prethodnom primjeru) bude dodan i atribut zipid. Sada e unos retka u prikaz zahtijevati i unos atributa zipid, koji mora biti 1, pa e zavr²iti u prikazu. Donosimo kod prikaza i primjer unosa. 34 Relacijska shema e se nalaziti i na Slici 3.5.

33 3 IMPLEMENTACIJA BAZE PODATAKA 31 CREATE OR REPLACE VIEW zipidje1 AS SELECT zipid, naziv, opis FROM grupa WHERE zipid=1; INSERT INTO zipidje1 VALUES (1, 'nova grupa','moj zipid=1'); Unos ima isti efekt na tablicu grupa, kao da smo izvr²ili sljede i redak: INSERT INTO grupa(zipid, naziv, opis) VALUES (1, 'nova grupa','moj zipid=1'); Izmjenjivi prikazi omogu uju i brisanje. Odnosno brisanje se proslježuje do temeljne tablice R. Kako bismo bili sigurni da e se obrisati jedino n-torke u prikazu, dodajemo uvjet u WHERE klauzuli prikaza uvjetu u WHERE klauzuli za brisanje. Pokaºimo to na primjeru. Primjer 3.11 (Brisanje redaka iz prikaza) šelimo obrisati iz izmjenjivog prikaza zipidje1 sve grupe koje u opisu imaju rije 'nova'. To emo u initi na sljede i na in: DELETE FROM zipidje1 WHERE naziv LIKE '%nova%'; Brisanje je prosliježeno do ekvivalentog brisanja u temeljnoj tablici grupa; jedina razlika je ta da je uvjet koji denira prikaz zipidje1 dodan uvjetu klauzule WHERE, pa je zapravo izvr²ena sljede a naredba: DELETE FROM grupa WHERE naziv LIKE '%nova%' AND zipid=1; Na sli an na in se i aºuriranje izmjenjivog prikaza proslježuje do temeljne tablice. Tako aºuriranje prikaza ima efekt aºuriranja svih n-torki iz temeljne relacije koje su se pojavile u prikazu. Primjer 3.12 (Aºuriranje redaka iz prikaza) Aºuriranje prikaza zipidje1 koje svim grupama iz prikaza daje opis zipid=1 u ovoj grupi, prikazano sljede om sintaksom UPDATE zipidje1 SET opis='zipid=1 u ovoj grupi'; je ekvivalentno sljede em aºuriranju temeljne tablice grupa UPDATE grupa SET opis='zipid=1 u ovoj grupi' WHERE zipid=1; Prema [12], MySQL u trenutku stvaranja prikaza postavlja zastavicu, nazvanu zastavica izmjenjivosti prikaza 35. Zastavica je postavljena potvrdno (YES) ili nije no (NO), ovisno o 35 engl. view updatability ag

34 3 IMPLEMENTACIJA BAZE PODATAKA 32 tome jesu li dozvoljene operacije aºuriranja, brisanja i sl. Stupac IS UPDATABLE u tablici INFORMATION SCHEMA.VIEWS pokazuje status zastavice. To zna i da posluºitelj uvijek zna je li prikaz izmjenjiv. Ako prikaz nije izmjenjiv, operacije unosa, aºuriranja i brisanja e biti odbijene. Podsjetimo se: prikaz moºe biti izmjenjiv, a da u njemu nije dopu²tena operacija unosa. Za izmjenjiv prikaz koji se sastoji od vi²e tablica, INSERT operacija se moºe provesti ako upisuje redak samo u jednu tablicu, a DELETE operacija nije podrºana. šelimo li vidjeti sve informacije o prikazima iz pojedine baze, rabimo sljede i SQL upit: SELECT * FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA='imebaze'; Primjer 3.13 (Traºimo sve prikaze u bazi aktivna) šele i na i sve prikaze u bazi aktivna, traºimo uz svaki navedeno ime baze (TABLE SCHEMA), ime prikaza (TABLE NAME), deniciju prikaza (VIEW DEFINITION), ima li CHECK opciju (CHECK OPTION) i je li izmjenjiv (IS UPDATABLE). To postiºemo sljede im upitom. SELECT TABLE_SCHEMA AS ime_baze, TABLE_NAME AS ime_prikaza, VIEW_DEFINITION AS definicija_prikaza, CHECK_OPTION AS ima_li_check_opciju, IS_UPDATABLE AS je_li_izmjenjiv FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA='aktivna'; Deniciju prikaza koji postoji u trenutnoj bazi u MySQL-u moºemo saznati i preko naredbe SHOW CREATE VIEW <ime prikaza> CHECK opcija vezana uz prikaze U Primjeru 3.9 smo vidjeli kako unos vrijednosti u prikaz moºe rezultirati unosom retka u temeljnu tablicu, koji se ne e pojaviti u prikazu. Kako bi to sprije io, MySQL dopu²ta provjeru ho e li unos podataka u izmjenjivi prikaz ili njihova promjena i dalje ostati u prikazu. Spomenuta provjera se postiºe pomo u klju nih rije i WITH CHECK OPTION nakon upita u prikazu. Promotrimo primjer na kojem emo objasniti o emu se radi. Primjer 3.14 (Osiguran unos samo onih redaka koji e zavr²iti u prikazu) Promotrimo prikaz zipidje1 koji ima jednaku deniciju prikaza kao istoimeni prikaz u Primjeru 3.9. Jedino se od njega razlikuje u klju nim rije ima WITH CHECK OPTION.

35 3 IMPLEMENTACIJA BAZE PODATAKA 33 CREATE OR REPLACE VIEW zipidje1 AS SELECT naziv, opis FROM grupa WHERE zipid=1 WITH CHECK OPTION; Poku²ajmo sada u njega unijeti novi redak INSERT INTO zipidje1 VALUES ('nova grupa3','moj zipid=1'); Nakon poku²aja unosa javit e se gre²ka: CHECK OPTION failed, jer navedeni redak ne bi zavr²io u prikazu, budu i da ima vrijednost NULL za atribut zipid, tako da unos retka u prikaz na ovaj na in ne e pro i, za razliku od unosa u Primjeru Indeksi u SQL-u Sljede a dva odlomka su prevedena iz [3, str. 350]: "Indeks na atributu A relacije je struktura podataka koja ini uspje²nim pronalaºenje onih n-torki koje imaju ksnu vrijednost atributa A. Indeks moºemo promatrati kao pretraºivanje binarnog stabla s parovima (klju, vrijednost), u kojima je klju a (jedna od vrijednosti koju atribut A mora imati) povezan s "vrijedno² u" koja je skup lokacija n-torki koje imaju a u komponenti atributa A. Takav indeks moºe pomo i s upitima u kojima se atribut A usporežuje s konstantom, npr. A = 3, ili ak A 3. Uo imo kako klju za indeks moºe biti bilo koji atribut ili skup atributa, tj. ne mora nuºno biti klju relacije na kojoj se indeks postavlja. Kada moramo razlikovati ta dva pojma, atribute indeksa moºemo zvati klju indeksa. Tehnologija implementiranja indeksa na velikim relacijama je od temeljne vaºnosti u implementaciji SUBP. Najvaºnija struktura podataka koju SUBP koristi po tom pitanju je B-stablo, koje je generalizacija balansiranog 36 binarnog stabla." U ovom dijelu rada ne emo se baviti detaljnije tematikom B-stabla (vi²e o njima ima u [3, str. 633]). Za²to govorimo o indeksima? U slu ajevima kada imamo velike relacije, moºe nam biti skupo pro i svaku n-torku u relaciji kako bismo na²li one (moºda vrlo malo njih) koje zadovoljavaju dani uvjet. Primjer 3.15 (Pronalaºenje n-torke u relaciji) Za potrebe ovog primjera, podsjetimo se najprije relacijske sheme relacije korisnik sa Slike 3.3: korisnik(userid, username, password, ime, prezime, spol, datum rodjenja, 36 Stablo je balansirano ako je duljina puta od korijena do lista jednaka za svaki list u stablu.

36 3 IMPLEMENTACIJA BAZE PODATAKA 34 mjesto rodjenja) Pretpostavimo da u dru²tvenoj mreºi ºelimo na i one korisnike kojima ime po inje na slovo S, i koji su roženi godine: SELECT * FROM korisnik WHERE ime LIKE 'S%' AND datum_rodjenja LIKE '1989%'; Moºemo imati na tisu e korisnika od kojih bi moºda stotinjak bilo roženo godine. Naivan na in implementacije ovog upita je uzeti sve n-torke korisnika (sve tisu e koje imamo) i testirati uvjet iz WHERE klauzule na svakoj. No, bilo bi ekasnije ako bismo na neki na in mogli dohvatiti njih stotinjak koji su roženi godine i testirati svaki od njih kako bismo vidjeli kojima ime po inje slovom S. Postoji i jo² ekasniji na in od toga, na koji bismo mogli izravno dohvatiti onih 10-ak n-torki koje zadovoljavaju oba uvjeta (tj. kojima ime po inje na slovo S i koji su roženi godine). Indeksi takožer mogu biti korisni kad koriste spajanje tablica. Sljede i primjer pokazuje takav slu aj: Primjer 3.16 (Primjer spajanja tablica u kojima bi indeks bio od koristi) Relacijsku shemu relacije korisnik imali smo u prethodnom primjeru. Podsjetimo se uz to, za potrebe ovog primjera, relacijske sheme relacije naziv grada: naziv grada(gradid, postanski broj, naziv grada, drzavaid) Pogledajmo sada primjer upita za koji bi indeks bio od koristi. SELECT userid, username, ime, prezime, spol, datum_rodjenja, postanski_broj AS 'postanski_broj_rodnog_grada', naziv_grada AS 'grad_rodjenja', FROM korisnik JOIN naziv_grada ON korisnik.mjesto_rodjenja=naziv_grada.gradid WHERE naziv_grada=osijek; Kada bi postojao indeks na atributu naziv grada relacije naziv grada, mogli bismo koristiti taj indeks kako bismo dohvatili n-torku za Osijek. Od te n-torke moºemo izdvojiti gradid. Sada, pretpostavimo kako takožer postoji indeks na mjesto rodjenja relacije korisnik. Tada moºemo koristiti gradid s indeksom kako bismo na²li n-torku iz relacije korisnik koja odgovara korisnicima roženim u Osijeku. Iz te n-torke izdvojimo informacije koje nas zanimaju. Uo imo kako s ta dva indeksa gledamo samo one dvije vrste redaka (po jednu iz svake relacije) koji odgovaraju na upit. Bez indeksa, morali bismo gledati svaki redak svake relacije.

37 3 IMPLEMENTACIJA BAZE PODATAKA 35 Stvaranjem indeksa na atributu imeatributa relacije imerelacije e procesor upita izvr²avati upite u kojima je atribut imeatributa naveden na na in da e gledati samo one n-torke iz relacije imerelacije s navedenom vrijedno² u atributa imeatributa. Kao posljedica toga, vrijeme potrebno za odgovor na upit se smanjuje. Sintaksa za stvaranje indeksa u MySQL-u Sintaksa za stvaranje indeksa na InnoDB tablicama 37 u MySQL-u je sljede a: CREATE [UNIQUE FULLTEXT] INDEX imeindeksa ON imetablice(lista_atributa); Objasnimo sada pojedine dijelove (prema [12]): CREATE INDEX omogu uje dodavanje indeksa na postoje e tablice. Lista atributa (atr1, atr2) stvara indeks na vi²e atributa. Klju indeksa se formira konkatenacijom vrijednosti danih atributa. Indeks se moºe stvoriti tako da koristi samo po etni dio vrijednosti stupca pomo u sintakse imestupca(duljina) koja odrežuje duljinu preksa indeksa: - Preks se moºe odrediti za CHAR, VARCHAR, BINARY i VARBINARY stupce. - BLOB i TEXT stupce takožer moºemo indeksirati, ali mora biti zadana duljina preksa. - Duljina preksa se daje u znakovima za nebinarne znakovne tipove, a u bajtovima za binarne znakovne tipove. Tj. unosi za indeks se sastoje od prvih duljina znakova za stupce s tipom CHAR, VARCHAR i TEXT, te za prvih duljina bajta za svaki stupac tipa BINARY, VARBINARY, i BLOB. Ako se imena stupaca obi no razlikuju u prvih 10 znakova, indeks ne bi trebao biti puno sporiji od indeksa stvorenog na cijelom stupcu. Uz to, kori²tenje preksa za indekse nad stupcima moºe smanjiti indeks datoteku 38, ²to bi u²tedjelo prostor na disku i takožer ubrzalo INSERT operacije. UNIQUE indeks stvara ograni enje takvo da sve vrijednosti indeksa moraju biti razli ite. Gre²ka se javlja ukoliko poku²amo dodati novi redak s vrijednosti klju a koja ve postoji ili ako poku²amo stvoriti indeks nad relacijom u kojoj ime atributa nema 37 InnoDB tablice osiguravaju zadovoljenje referencijalnog integriteta, a od MySQL 5.5 verzije su zadani stroj za pohranu (engl. storage engine). Vi²e o njima u [12, str. 1574] 38 engl. index le

38 3 IMPLEMENTACIJA BAZE PODATAKA 36 jedinstvenu vrijednost. UNIQUE indeks dozvoljava vi²estruke NULL vrijednosti za stupce koji mogu sadrºavati NULL vrijednosti. Ako odredimo vrijednost preksa za stupac s UNIQUE indeksom, vrijednosti stupca moraju biti jedinstvene u tom preksu. FULLTEXT indeksi su podrºani za InnoDB tablice i mogu sadrºavati samo CHAR, VARCHAR i TEXT stupce. Indeksira se uvijek cijeli stupac, indeksiranje preksa stupca nije podrºano (duljina preksa se ignorira ako je navedena). Dobro dože za pretraºivanje cijelog teksta pomo u nekoliko funkcija u MySQL-u. Vi²e detalja moºe se prona i u [12, str. 1606]. Za sada se vrijednosti indeksa u MySQL-u se uvijek pohranjuju u rastu em redoslijedu. šelimo li obrisati indeks u MySQL-u, koristimo sljede u sintaksu: DROP INDEX imeindeksa ON imetablice; ili ALTER TABLE imetablice DROP INDEX imeindeksa; Primjer 3.17 (Stvaranje jedinstvenog indeksa) U relaciji drzava s relacijskom shemom drzava(drzavaid, ime drzave) ºelimo osigurati jedinstvenu vrijednost za ime drzave i to postiºemo na sljede i na in: CREATE UNIQUE INDEX ime_drzave_unique01 ON drzava(ime_drzave); Primjer 3.18 (Stvaranje indeksa za pretraºivanje teksta poruke) U relaciji tekst poruke s relacijskom shemom tekst poruke(tekstid, tekst poruke) ºelimo stvoriti indeks koji bi omogu io pretraºivanje cijelog teksta poruke. To inimo na sljede i na in: CREATE FULLTEXT INDEX tekstporuke16 ON tekst_poruke(tekst_poruke); Kada ne bismo imali FULLTEXT indeks, ne bismo mogli indeksirati cijeli tekst poruke, nego bismo morali navesti duljinu - prvih nekoliko znakova teksta poruke.

39 3 IMPLEMENTACIJA BAZE PODATAKA 37 Slika 3.4 Relacijska shema relacije spomenar Primjer 3.19 (Indeksiranje s odreženom duljinom znakova) Promotrimo relacijsku shemu relacije spomenar sa Slike 3.4. šelimo osigurati jedinstvenost zapisa u spomenaru na na in da e se zapis jedne osobe drugoj odreženog datuma razlikovati u prvih 200 znakova poruke. To postiºemo na sljede i na in: CREATE UNIQUE INDEX jedinstveni_zapis18 ON spomenar(tko_pise, kome_pise, poruka(200), datum); Primjer 3.20 (Stvaranje jednog indeksa na vi²e atributa) Budu i da su fakultetid i profesorid klju relacije web stranice prof, moºemo o ekivati da e se odrediti vrijednosti oba atributa, ili nijednog. Slijedi sintaksa kojom bismo deklarirali indeks na ova dva atributa u slu aju kad oni ne bi inili klju, jer ovako je indeks ve automatski stvoren u MySQL-u, ali ovdje nam je bitno zbog primjera imati ujedno i naziv indeksa: CREATE INDEX fakultetprofesor_fk31 ON web_stranice_prof(fakultetid, profesorid); Kako je (fakultetid, profesorid) klju, slijedi da za dane vrijednosti fakulteta i profesora indeks nalazi samo jedan redak - traºeni redak. Usporedimo to sa slu ajem kada upit odrežuje fakultetid i profesorid, ali imamo indeks samo na atributu fakultetid. Tada SUBP uzima u obzir sve profesore na navedenom fakultetu i provjerava tko je od njih onaj kome atribut profesorid odgovara vrijednosti navedenoj u upitu. Indeks fakultetprofesor fk31 se koristi za upite koji su oblika: SELECT * FROM web_stranice_prof WHERE fakultetid=broj1 AND profesorid=broj2; i tome ekvivalentnog oblika: SELECT * FROM web_stranice_prof WHERE profesorid=broj2 AND fakultetid=broj1; te za upite oblika: SELECT * FROM web_stranice_prof WHERE fakultetid=broj1;

40 3 IMPLEMENTACIJA BAZE PODATAKA 38 za ksno odrežene cjelobrojne vrijednosti broj1 i broj2, ali se ne moºe koristiti za: SELECT * FROM web_stranice_prof WHERE profesorid=broj2; Indeks fakultetprofesor fk31 se ekasno koristi za sortiranja oblika: SELECT * FROM web_stranice_prof ORDER BY fakultetid, profesorid; SELECT * FROM web_stranice_prof ORDER BY fakultetid DESC, profesorid DESC; ali ne i za: SELECT * FROM web_stranice_prof ORDER BY fakultetid DESC, profesorid; Osim toga, budu i da imamo indeks na kombinaciji atributa fakultetid i profesorid, nije nam potrebno stvoriti poseban indeks samo na atributu fakultetid. Ako je (²to je est slu aj u praksi) klju indeksa koji sadrºi vi²e atributa zapravo konkatenacija atributa u odreženom redoslijedu, onda ak moºemo koristiti taj indeks kako bismo na²li sve retke s danom vrijedno² u za prvi atribut. Tako je dio dizajniranja indeksa koji se sastoji od vi²e atributa izbor redoslijeda u kojem e se navesti atributi. Npr. ako ºelimo u upitu o web-stranicama profesora na fakultetima e² e odreživati fakultet, redoslijed atributa u indeksu e biti kao gore, a ako ºelimo e² e odreživati profesora iju web-stranicu traºimo, redoslijed atributa u indeksu e biti (profesorid, fakultetid). Izbor indeksa Iako moºemo dobiti dojam kako ²to vi²e indeksa stvorimo, ve a je vjerojatnost da e za bilo koji upit postojati indeks koji nam je koristan, takav zaklju ak je kriv. Kako bismo to objasnili, spomenimo najprije injenicu da su n-torke relacije pravilno pohranjene mežu stranicama 39 diska, a pregledavanje ak i jednog retka zahtjeva da cijela stranica bude u radnoj 40 memoriji. S druge strane, pregledavanje svih redaka na stranici malo vi²e vremena ko²ta od pregledavanja samo jednog retka. Cijena upita ili modikacije je esto broj stranica 39 engl. pages of disk 40 engl. main memory

41 3 IMPLEMENTACIJA BAZE PODATAKA 39 koje trebamo dovesti u radnu memoriju, pa nam indeksi na odreženom atributu mogu uvelike ubrzati izvoženje onih upita u kojima je vrijednost ili skup vrijednosti odrežen za taj atribut, te takožer mogu ubrzati spajanje tablica koje uklju uje taj atribut. S druge strane, svaki indeks stvoren za jedan ili vi²e atributa neke relacije ini kompleksnijim i vremenski sloºenijim operacije unosa, brisanja i aºuriranja na toj relaciji, zbog injenice da i sami indeksi trebaju biti pohranjeni na disku. Zbog toga pristup indeksima i modikacija indekasa ko²ta. Zapravo, modikacija je otprilike dvostruko skuplja od pristupa indeksu ili podacima u upitu, jer zahtjeva jedno itanje stranice diska i osim toga jedno zapisivanje promijenjene stranice. U praksi te injenice odrežuju osigurava li dizajn baze zadovoljavaju e performanse. Sljede i primjer pokazuje mo indeksa za klju, ak i u upitu koji uklju uje spajanje. Primjer 3.21 (Vaºnost indeksa kod uparivanja redaka) Promotrimo sljede i upit na relacije drzava(drzavaid, ime drzave) i naziv grada(gradid, postanski broj, naziv grada, drzavaid) SELECT * FROM drzava, naziv_grada WHERE drzava.drzavaid=naziv_grada.drzavaid AND gradid=10; U gore navedenom upitu dogaža se uparivanje redaka iz relacija drzava i naziv grada. Implementacija spoja na takav na in zahtjeva od nas itanje svake od stranica koja sadrºi n-torke relacije drzava i svake od stranica koja sadrºi n-torke relacije naziv grada barem jednom. U stvari, budu i da te stranice mogu biti previ²e brojne da bi stale u radnu memoriju u isto vrijeme, moºda emo vi²e puta morati itati svaku stranicu s diska. No, imamo li odgovaraju e indekse, cijeli upit moºe biti gotov itanjem 2 stranice. Indeks na klju u gradid relacije naziv grada e nam pomo i na i onaj redak kojem je gradid jednak 10. Samo ta stranica - stranica koja sadrºi taj redak e biti pro itana s diska. Potom, nakon pronalaºenja tog retka, dohva amo broj za njegov atribut drzavaid. Indeks na atributu drzavaid relacije drzava e nam pomo i brzo prona i onaj redak koji odgovara drºavi u kojoj se nalazi pronaženi grad iz relacije naziv grada. Ponovno, samo jedna stranica s retcima relacije drzava e biti pro itana s diska, iako moºemo trebati pro itati mali broj drugih stranica za kori²tenje indeksa na atributu drzavaid relacije drzava. Jo² neke napomene vezane uz indekse

42 3 IMPLEMENTACIJA BAZE PODATAKA 40 U ovom potpoglavlju, navest emo jo² neke korisne informacije o indeksima, na koje se nismo prije mogli toliko fokusirati. Rekli smo kako indeks ima strukturu B-stabla. To se B-stablo formira kao struktura nad podacima relacije izvr²avanjem naredbe za stvaranje indeksa nad tom relacijom. Imaju li vrijednosti atributa relativno mali broj razli itih vrijednosti, indeks se ne bi trebao kreirati (npr. atribut spol u relaciji korisnik). Trebamo li u relaciji izvr²iti mnogo operacija unosa, aºuriranja ili brisanja n-torki, preporu a se brisanje postoje ih indeksa i njihovo ponovno kreiranje nakon tih operacija. Sadrºi li relacija relativno malo redaka, nije potrebno stvarati indeks, jer B-stablo ne pridonosi ekasnosti pretrage. Imamo li u nekoj relaciji atribut u kojem relativno malo redaka ima odreženu vrijednost tog atributa, indeks bi mogao biti ekasan jer za pronalaºenje tog atributa ne bismo trebali dopremiti sve stranice diska u radnu memoriju (nego samo one koje sadrºe redak s tom vrijedno² u atributa). Ukoliko su retci relacije sa zajedni kom vrijedno² u nekog atributa grupirani na minimalno stranica diska koliko je mogu e, indeks na tom atributu bi i u tom slu aju bio od koristi Kako MySQL koristi indekse Za potrebe ovog cijelog potpoglavlja, koristili smo [12]. Ve ina MySQL indeksa su pohranjeni kao B-stabla (npr. PRIMARY KEY, UNIQUE, FULLTEXT, INDEX). MySQL koristi indekse za sljede e operacije: za brzi pronalazak redaka koji zadovoljavaju uvjet u WHERE klauzuli, za eliminiranje redaka iz izbora (ako imamo izbor izmežu vi²estrukih indeksa, MySQL redovito koristi indeks koji pronalazi najmanji broj redaka), za vra anje 41 redaka iz drugih tablica kada izvodi spojeve 42, za pronalazak najmanje (MIN()) i najve e (MAX()) vrijednosti odreženog indeksiranog stupca, 41 engl. retrieve 42 MySQL moºe ekasnije koristiti indekse na stupcima ako su deklarirani kao isti tip i ista veli ina - npr. CHAR i VARCHAR se u tom kontekstu smatraju jednakima ako su deklarirane kao jednake veli ine ( VARCHAR(20) i CHAR(20)).

43 3 IMPLEMENTACIJA BAZE PODATAKA 41 za sortiranje ili grupiranje tablice, ako je sortiranje ili grupiranje izvedeno po atributima klju a, od lijevo navedenog (npr. ORDER BY atr1, atr2). Ukoliko nakon svih atributa klju a slijedi DESC, klju se ita u obrnutom redoslijedu. Indeksi su manje vaºni za upite na malim tablicama, ili na velikim tablicama gdje upit prolazi ve inu redaka ili sve. Kada upit mora pristupiti ve ini redaka, skeniranje svih redaka je brºe nego rad s indeksom - minimizira pretraºivanje diska. Primarni klju ima automatski generiran indeks koji je s njim povezan. Ne moramo posebno dodati indeks na njega u MySQL-u. Primarni indeks tablice trebao bi biti ²to je mogu e kra i (kako bi se svaki redak mogao jednostavno i jasno identicirati). 3.3 Pohranjene procedure i funkcije U ovom poglavlju rada bavit emo se tematikom pohranjenih procedura i pohranjenih funkcija. Oboje su potprogrami koji se izvr²avaju u kontekstu SUBP, ali spomenimo razliku izmežu ta dva pojma. Procedura u pozivaju i program ne vra a rezultat, dok funkcija u pozivaju i program vra a rezultat. U MySQL-u mogu e je izvoditi naredbe za kontrolu toka programa (IF, FOR, WHILE,...), te koristiti varijable. Njima se moºe omogu iti za²tita podataka na razini retka 43 (radi se o mogu nosti da neki korisnik vidi samo neke od redaka u pojedinoj relaciji, a ne sve), a kod potreban za neki postupak, iskaz i sl. je napisan na jednom mjestu. U ovom radu opisat emo MySQL standard Kreiranje pohranjenih procedura i pohranjenih funkcija Sintaksa procedure u MySQL-u je CREATE PROCEDURE ime ([parametri_procedure[,...]]) tijelo_procedure; a sintaksa funkcije CREATE FUNCTION ime ([parametri_funkcije[,...]]) RETURNS tip tijelo_funkcije; 43 engl. row-level security

44 3 IMPLEMENTACIJA BAZE PODATAKA 42 Parametri procedure se navode na sljede i na in [IN OUT INOUT] <ime parametra> <tip>, a parametri funkcije <ime parametra> <tip>. Popis parametara se nalazi unutar zagrada. Ukoliko nemamo parametara, mora biti prisutna prazna zagrada (). Imena parametara nisu osjetljiva na malo/veliko 44 slovo. Objasnimo sada ²to svaka od vrsta 45 parametara zna i: IN (samo unos 46 ) parametar proslježuje vrijednost proceduri, a u slu aju promijene vrijednosti parametra (unutar procedure), ne moºe ju vidjeti pozivatelj procedure. OUT (samo izlaz 47 ) parametar proslježuje vrijednost iz procedure natrag pozivatelju, a po etna vrijednost mu je NULL. Parametar INOUT (i ulaz i izlaz) je inicijaliziran od pozivatelja, moºe biti izmijenjen u proceduri, vidljiv je pozivatelju kad procedura zavr²i. Zadana vrsta parametra procedure je IN i moºe se izostaviti. S druge strane, parametri funkcije mogu biti jedino IN, a jedini na in na koji dobivamo informaciju iz funkcije je preko njezine vra ene vrijednosti. Ne smijemo odreživati IN vrstu za parametre funkcije, iako to inimo u denicijama procedura. Procedura se u MySQL-u bri²e naredbom DROP PROCEDURE <imeprocedure>; a funkcija naredbom DROP FUNCTION <imefunkcije>; Navedimo sada primjer procedure, kako bismo mogli govoriti o na inu pozivanja procedure s obzirom na vrstu parametara koji su u njoj zadani. Primjer 3.22 (Kori²tenje procedure za pretraºivanje prikaza) Promotrimo proceduru koja daje podatke o korisnicima iz prikaza korisnik prikaz(userid, username, ime, prezime, spol, datum rodjenja, postanski broj rodnog grada, grad rodjenja, drzava rodjenja) 44 engl. case sensitive 45 engl. mode 46 engl. input-only 47 engl. output-only

45 3 IMPLEMENTACIJA BAZE PODATAKA 43 za u itano ime i prezime korisnika. CREATE PROCEDURE pretrazivanje_po_imenu_i_prezimenu( IN imekorisnika VARCHAR(20), IN prezimekorisnika VARCHAR(30)) SELECT * FROM korisnik_prikaz WHERE ime=imekorisnika AND prezime=prezimekorisnika; Uo imo kako su oba parametra imekorisnika i prezimekorisnika vrste IN i tipa VARCHAR (VARCHAR(20) za imekorisnika, jer je i atribut ime relacije korisnik prikaz takožer tipa VARCHAR(20), i VARCHAR(30) za prezimekorisnika jer je atribut prezime relacije korisnik prikaz tipa VARCHAR(30)). Uo imo kako se imena parametara u tijelu procedure mogu koristiti kao da su konstante. Uz to, na ovakav na in korisnik ne e vidjeti sve retke iz prikaza korisnik prikaz, nego samo one kojima je ime jednako u itanom imenu, a prezime jednako u itanom prezimenu, pa moºemo re i da je osigurana za²tita podataka na razini retka. Procedura se poziva sljede im klju nim rije ima: CALL <ime procedure>(<popis argumenata>); Procedura iz Primjera 3.22 bi se pozvala na na in: CALL pretrazivanje po imenu i prezimenu('snjeºana','mijo²evi '); Napomenimo kako nije dozvoljeno pozivanje funkcije naredbom CALL. Funkcija se poziva pomo u SELECT <ime funkcije>(<popis argumenata>); Za svaki OUT ili INOUT parametar, korisnik proslježuje varijablu u CALL iskaz koji poziva proceduru pa zavr²etkom procedure moºemo dobiti njenu vrijednost. Promotrimo takav slu aj na sljede em primjeru. Primjer 3.23 (Primjer pozivanja procedure s OUT parametrom) Sada na primjeru procedure koja nalazi broj ljudi koji sa zadanim korisnikom dijeli informacije i ispisuje iz prikaza korisnika koji su to ljudi pokaºimo kako pozvati proceduru s OUT parametrom. Podsjetimo se najprije relacijskih shema prikaza korisnik prikaz i relacije dijeli informacije korisnik prikaz(userid, username, ime, prezime, spol, datum rodjenja, postanski broj rodnog grada, grad rodjenja, drzava rodjenja) dijeli informacije(userid, userid2)

46 3 IMPLEMENTACIJA BAZE PODATAKA 44 Tijelo procedure ima 2 SQL iskaza pa su potrebne klju ne rije i BEGIN i END, te promjena grani nika prije i nakon procedure (delimiter //... delimiter ;). IN parametar mojid ozna ava userid korisnika za kojeg traºimo koliko ljudi s njim dijeli informacije i koji su to ljudi, a u OUT parametar broj (za kojeg e u pozivanju procedure biti proslježena varijabla) e se pomo u klauzule INTO broj upisati broj korisnika koji je s na²im korisnikom podijelio informacije. Ispis koji korisnici su s na²im korisnikom podijelili informacije e biti poredan po korisni kom broju (ORDER BY userid). Promotrimo sada kod na²e procedure. delimiter // CREATE PROCEDURE koliko_ljudi_sa_mnom_dijeli_informacije ( IN mojid INT UNSIGNED, OUT broj TINYINT UNSIGNED) BEGIN SELECT COUNT(userID) INTO broj FROM dijeli_informacije WHERE userid2=mojid; SELECT * FROM korisnik_prikaz WHERE userid IN (SELECT userid FROM dijeli_informacije WHERE userid2=mojid) ORDER BY userid; END// delimiter ; Broj korisnika koji s na²im korisnikom dijeli informacije e biti u varijabli koju proslijedimo u CALL iskazu kod pozivanja procedure. Na primjer, naredba CALL koliko ljudi sa mnom dijeli e u varijabli broj pohraniti broj ljudi iz aktivne baze koji s korisnikom iji je userid=1 dijeli informacije. Naredba e ispisati taj broj. Klauzula RETURNS se moºe odrediti samo za funkciju i obvezna je. Odrežuje tip podatka koji funkcija vra a, a tijelo funkcije mora imati iskaz RETURN <vrijednost>. Ako RETURN iskaz vra a vrijednost druga ijeg tipa, vrijednost se pretvara u pravi tip. Navedimo ovdje injenice vezane uz tijelo procedure i tijelo funkcije (jednim imenom tijelo rutine) koje su vezane uz procedure i funkciju iz rada i koda, a vi²e injenica moºemo na i u [12]. Ukoliko je potrebno unutar rutine izvr²iti vi²e od jednog iskaza, osim klju nih rije i BEGIN i END, moramo postaviti drugu oznaku kao grani nik. (O tome smo ve govorili u potpoglavlju 3.1.2).

47 3 IMPLEMENTACIJA BAZE PODATAKA 45 Forma pridruºivanja je: SET <varijabla> = <izraz>; Vrijednost izraza s desne strane znaka jednakosti se izra una ili naže i potom pridruºi vrijednosti varijable s lijeve strane znaka jednakosti. NULL je dozvoljen izraz. Izraz moºe biti ak i upit, toliko dugo dok vra a jednu vrijednost. Iskazi koji vra aju skup rezultata se mogu koristiti unutar pohranjene procedure, ali ne unutar pohranjene funkcije. Ta zabrana uklju uje SELECT iskaze koji nemaju INTO <popis varijabli> klauzulu i druge iskaze kao npr. SHOW i CHECK TABLE. Posluºitelj se nosi s tipom podatka parametra rutine, lokalne 48 varijable rutine stvorene naredbom DECLARE <ime varijable> <tip varijable> ili s vrijedno² u koju funkcija vra a na sljede i na in: Zadaci se provjeravaju na nepodudaranje tipa podatka i preljev 49. Problemi s pretvaranjem i preljevanjem podataka rezultiraju upozorenjem, ili gre²kom. Samo se skalarna vrijednost moºe pridruºiti atributu. Dobrom praksom pokazalo se izbjegavati davanje imena (procedurama ili funkcijama) za koje ve postoji SQL funkcija Grananje Promotrimo IF iskaz kad su u pitanju pohranjene procedure i funkcije. Op enita forma IF iskaza u MySQL-u je sljede a: delimiter <oznaka> IF <uvjet> THEN <popis iskaza>; ELSEIF <uvjet> THEN <popis iskaza>; ELSEIF...; [ELSE <popis iskaza>;] END IF; <oznaka> delimiter ; 48 Radi se o varijablama iju vrijednost SUBP ne uva nakon izvoženja funkcije ili procedure. Deklaracije moraju prethoditi iskazima koji se izvr²avaju u tijelu funkcije ili procedure. 49 engl. overow

48 3 IMPLEMENTACIJA BAZE PODATAKA 46 Uvjet moºe biti bilo koja boolean vrijednost koja se moºe pojaviti u WHERE klauzuli SQL iskaza. Svaki popis iskaza se sastoji od iskaza koji zavr²avaju znakom ';', ali ne treba biti okruºen sa BEGIN...END. Zadnji ELSE i njegovi iskazi su opcionalni. Slika 3.5 Relacijske sheme relacija grupa i grupa studenata Primjer 3.24 (Funkcija s grananjem) Funkcija kojagrupa prima broj (parametar broj) i string (parametar koja), te vra a konkatenaciju stringova za broj i speci nost grupe ako grupa postoji, u suprotnom javlja da nema takve grupe. Zbog IF-THEN-ELSE naredbe je potrebna promjena grani nika prije i nakon funkcije (delimiter //... delimiter ;), a naredba CONCAT(string1, string2,...,stringn) vra a konkatenaciju stringova - u na²em slu aju 'Grupa', broj (pretvoren u string) i ovisno o tome radi li se o grupi profesora ili studenata string 'profesora' ili 'studenata'. Donosimo sada kod funkcije. delimiter // CREATE FUNCTION kojagrupa (broj INT UNSIGNED, koja VARCHAR(20)) RETURNS VARCHAR(35) IF koja='profesori' AND broj IN (SELECT IDgrupe FROM grupa) THEN RETURN CONCAT ('Grupa ', broj, ' profesora.'); ELSEIF koja='studenti' AND broj IN (SELECT IDgrupe_studenata FROM grupa_studenata) THEN RETURN CONCAT ('Grupa ', broj, ' studenata.'); ELSE RETURN 'Nema takve grupe.'; END IF;//