Fakultet prirodoslovnih znanosti i odgojnih područjaSveučilišta u Splitu

Tonći Dadić

BAZE PODATAKA

Split, 2002.

Sadržaj:

1 UVOD.....................................................................................................................4

1.1 Što je baza podataka?.....................................................................................41.2 Vrste baza podataka.......................................................................................7

1.2.1 Datotečna baze podataka........................................................................71.2.2 Hijerarhijska baza podataka...................................................................81.2.3 Mrežna baza podataka............................................................................91.2.4 Relacijska baza podataka.......................................................................91.2.5 Objektna baza podataka.........................................................................9

2 Relacijski model podataka...................................................................................12

2.1 IS male knjižare............................................................................................122.2 Pojmovi relacijskog modela podataka..........................................................152.3 Relacijska algebra........................................................................................162.4 Coddova pravila...........................................................................................192.5 Ograničenja relacijskog modela...................................................................20

2.5.1 Ograničenja strukture...........................................................................202.5.2 Ograničenja ponašanja.........................................................................21

2.6 Normalizacija...............................................................................................222.6.1 Prva normalna forma............................................................................232.6.2 Druga normalna forma.........................................................................252.6.3 Treća normalna forma..........................................................................262.6.4 Boyce-Coddova normalna forma.........................................................272.6.5 Četvrta normalna forma.......................................................................282.6.6 Peta normalna forma............................................................................29

3 Životni ciklus baze podataka...............................................................................31

3.1 Faze životnog ciklusa baze...........................................................................313.2 Vrste baza podataka.....................................................................................333.3 Postupak oblikovanja baze podataka............................................................34

3.3.1 Izrada modela.......................................................................................343.3.2 Različiti aspekti sustava.......................................................................353.3.3 Model entiteti – veze............................................................................353.3.4 Veze......................................................................................................363.3.5 Rješenje veze više prema više..............................................................393.3.6 Rekurzivna veza...................................................................................393.3.7 Učestalost pojedinih vrsta veza u realnim modelima...........................403.3.8 Atributi.................................................................................................403.3.9 Opcionalnost atributa...........................................................................413.3.10 Jedinstveni identifikator.......................................................................42

2

3.4 Videoteka - model praktičnog primjera.......................................................433.5 Model entiteti – veze ( MS SQL Server 2000).............................................473.6 Funkcije ( metode )......................................................................................473.7 Impementacija objekata baze podataka – primjer dviju tablica ( Microsoft SQL Server 2000 ):..................................................................................................48

4 Indeksi..................................................................................................................49

5 SQL Upitni jezik..................................................................................................54

5.1 Uvod.............................................................................................................545.2 Upiti u relacijskoj bazi podataka..................................................................54

5.2.1 Projekcija i restrikcija...........................................................................545.2.2 Prirodno spajanje..................................................................................575.2.3 Vanjsko ( Outer Join ) spajanje............................................................585.2.4 Unutrašnje ( Inner Join ) spajanje........................................................605.2.5 Funkcije u SQL Upitu..........................................................................605.2.6 Grupiranje podataka i sumarna izračunavanja.....................................645.2.7 ZbrojOcjena..........................................................................................675.2.8 Logički složeni uvjeti...........................................................................675.2.9 Pobrojane vrijednosti...........................................................................695.2.10 Ugniježđeni upiti..................................................................................69

5.3 SQL comande za definiciju objekata relacijske baze podataka...................745.3.1 Stvaranje, promjena i uništavanje tablice.............................................745.3.2 Stvaranje i uništavanje pogleda – view-a.............................................775.3.3 Stvaranje indeksa..................................................................................785.3.4 Uništavanje indeksa..............................................................................79

5.4 Naredbe za upisivanje, promjenu i brisanje podataka..................................805.4.1 Upisivanje ( insertiranje ) retka............................................................805.4.2 Upisivanje svih kolona.........................................................................815.4.3 Upisivanje iz jedne tablice u drugu......................................................815.4.4 Pomjena podataka ( update )................................................................815.4.5 Promjena podataka tablice vrijednostima druge tablice.......................825.4.6 Brisanje ( delete ) retka........................................................................83

6 Literatura:.............................................................................................................84

3

1 UVOD

1.1 Što je baza podataka?

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

Informacijski sustav prikuplja, pohranjuje, čuva, obrađuje i isporučuje informacije važne za pojedinca, organizaciju i društvo, tako da budu dostupne i uporabljive za svakog tko ih želi koristiti. Informacijski sustav aktivni je društveni sustav koji može, ali ne mora, koristiti suvremenu informacijsku tehnologiju ( M. Varga, «Baze podataka», DRIP, Zagreb 1994).

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

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

Informacija je novo znanje, koje primatelju donosi nove činjenice. Ona ima karakter novosti, otklanja neizvjesnost i služi kao podloga za odlučivanje ( Birolla i dr., 1988). Po svojoj prirodi, informacija je nematerijalna. Da bi ostala sačuvana, treba je materijalizirati, odnosno zapisati. Taj se zapis zove podatkom:

Podatak je skup prepoznatljivih znakova na određenom mediju.Obrnuto gledano, informacija je protumačeni podatak, koji primatelju donosi novost, čiju vrijednost on sam mora procijeniti ( M. Varga, «Baze podataka», DRIP, 1994).

Informacijski sustav možemo podijeliti na sastavnice:

- Sklopovsku podršku ( Hardware )- Programsku podršku ( Software )- Ljudske resurse ( Humanware )- Organizacijske metode i postupke ( Orgware )

Programska podrška se, pak, dijeli na sistemsku i primjenjenu ili aplikacijsku programsku podršku. Nije jednostavno povući strogu granicu između ove dvije vrste programske opreme, no kažimo da sistemsku podršku sačinjavaju programi koji osiguravaju rad računalnog sustava kao cjeline. Naime, računalni hardver je prvi proizvod stvoren ljudskim umom i rukama, koji je toliko univerzalan, da sam, bez programske podrške, praktično nije ni od kakve koristi. Potrebano ga je instruirati, mogli bismo kazati «naučiti» da obavlja koristan posao. U tom postupku instruiranja hardvera, uočene su i podijeljene po kategorijama različite vrste poslova. Tako, računalni hardver mora prepoznati pritiske na tipke tipkovnice, prikazati na opremi za ispis, kao što su monitori, znakovne i slikovne poruke itd. Isto tako, računalni hardver se često koristi za istovremeno izvođenje različitih zadataka, te za pamćenje podataka

4

u radnoj memoriji i vanjskim jedinicama za masovnu pohranu podataka. Kako će računalni hardver obaviti ovu vrtstu osnovnih poslova, instruira ga programska podrška koju nazivamo operacijski sustav. Nadalje, račuanlni sustav koji obavlja gore navedene poslove još uvijek nija iskoristiv u svakodnevnom poslu, jer ljudima treba pomoć u obavljanju konkretnih, strogo definiranih poslova. Lepeza tih poslova je vrlo široka, a svaki pojedini posao traži strogo definirane postupke, pa proizvođači računalnih sustava, dakle hardvera i sistemske podrške nisu u stanju definirati sve detalje aplikativnih postupaka. Njih definiraju, te instruiraju računalo kako da ih obavi, kreatori primjenjene ili aplikativne programske podrške. S druge pak strane, ako bi kreatori aplikacije morali voditi računa o svim detaljima rada računalnog sustava, kao spremanjem podataka na medije za masovnu pohranu, njihovim pretraživanjem , ispisom na ekranske forme i izvještaje, od silnog posla i mnogobrojnih detalja koji moraju biti razrađeni do najsitnijih potankosti, nebi imali vremena i mogućnosti usredotočiti se na sam problem koji rješavaju. Osim toga, edukacija ljudi koji bi morali znati sve, počev od rada hardvera do detalja, do tehnološkog posla kojeg informatiziraju, uzela bi toliko vremena, da bi vjerojatno učili do mirovine.

Pojasnimo to primjerom: Želimo izraditi informacijski sustav koji bi automatizirao rad studentske referade, od upisa studenta na fakultet, preko prijave i polaganja ispita, do izdavanja diplome. Vjerojatno na svakom fakultetu u Hrvatskoj postoje razlike u postupku prijave ispita. Štoviše, čak i na jednom fakultetu neke je ispite potrebno prijaviti četiri dana ranije, radi rezerviranja dvorane za ispit, do organizacije putovanja nastavnika iz drugog grada, dok se drugi ispiti, recimo iz izbornih predmeta, koje sluša svega nekoliko studenata, ispitni termin dogovara s nastavnikom i nije potrebana rezervacija dvorane. Nadalje, postupak prijave ispita u Kini i Hrvatskoj se sigurno razlikuje uzme li se u obzir broj studenata na sveučilištima.Očito je, da nije moguće izraditi jedinstvenu aplikaciju u prihvatljivom vremenu i po isplatljivoj cijeni, koja bi informatizirala rad studentske referade u Kini i Hrvatskoj. S druge pak strane, spremanje podataka na magnetski medij trebaju kreatori aplikacija u obje zemlje. Stoga je tržište odredilo specijalizaciju poslova, pa je moguće proizvesti identičanu programsku podršku koja će spremati i pretraživati podatke, kako za aplikaciju u Kini, tako i u Hrvatskoj. Štoviše, ljudi specijalizirani za poslove spremanja podataka, toliko su ušli u detalje tog problema, da ga mogu riješiti brže i bolje nego li bi mogao univerzalni programer, koji bi morao voditi računa o svim aspektima računalnog sustava i tehnologije koja se automatizira. Nadalje, dobar proizvod kojeg su napravili specijalisti, prodaje se s takvom tiražom da su njegvi autori visoko stimulirani, a kupcima je cijena prihvatljiva. Nadalje, specijalizirani opći posao spremanja podataka na magnetski medij trebaju kreatori različitih aplikacijskih programa, pa su tijekom vremena pronađeni presjeci poslova, koji su identični svakoj aplikaciji tog tipa.

Prema izloženoj logici su nastali specijalizirani programi za obavljanje općih poslova vezanih uz rad informacijskog sustava, te primjenjeni programi, koji koriste njihove programske usluge i obavljaju poslove koje ljudi trebaju u konkretnom, strogo određenom poslu.

Iskustveno znamo da je ljudima značajna informacija, koja mora biti prikazana na podesan način. Na primjer, zanima nas broj permutacija šest znamenkastog broja 123456, ali često nas ne zanima kako je rezultat izračunat, samo gotovi rezultat. Ako

5

će netko napraviti program za izračunavanje broja permutacija – operaciju «faktorjel», on će to napraviti općenito, recimo za izračunavanje broja faktorjela Fakt(x), pri čemu je x ulaz u program, koji će izračunati izlaz y i prikazati ga na monitoru računalnog sustava:

y = Fakt(x)

Dakle, program, bio on jednostavan ili složen, na temelju ulaza izračunava izlaze. Korisnike zanimaji izlazi, a da bi ih dobili moraju program snabdjedi traženim ulazima. Program može imati veći broj ulaza, te izračunati veći broj izlaza. Označimo li s X skup svih ulaza, te s Y skup svih izlaza, program f transformira ulaze u izlaze:

Y = f(X)

Neki ulazi mogu biti zadani ad hock, neposredno prije izračunavanja izlaza, kao u primjeru izračunavanja faktorjela. No, mnogo je češći slučaj kada izlazni odziv nije moguće dobiti odmah. Pretpostavimo da tražimo posao preko interneta. Jedan mogući pristup je: prijavimo se u neki «chat-room» i unesemo poruku:

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

Nakon nekoliko sekundi poruka bi nestala s ekrana i trebali bismo je ponoviti svako nekog vremena. Vrlo nepraktično i s minimalnim izgledima na uspjeh, jer je malo vjerojatno da će se u isto vrijeme u istom «chat-roomu» naći i osoba iz tvrtke koja traži čovjeka sa znanjem dot.net i C#, a sigurno je danas to tražena specijalnost.

Mnogo prikladniji način traženja angažmana je ako možemo pohraniti podatke o sebi i svom znanju, te da oni budu na raspolaganju onima koji trebaju programere, tako dugo dok naša potraga traje. U ovom slučaju, program će generirati izlaze na temelju dvije vrste ulaza:

- ranije unijetih i pohranjenih ( podaci naše ponude )- zadanih neposredno prije izvođenja programa ( podaci potrage )

Označimo li s X skup ulaznih podataka kod izvođenja programa, sa Z skup ranije unijetihi pohranjenih ( perzistentnih ) ulaza, izlazni podaci Y će biti generirani transformacijom ulaza X i Z:

Y = f( X, Z )

Bazu podataka možemo shvatiti kao elektronsko skladište za pohranu podataka, koji će biti korišteni kao programski ulazi s odgodom. Kako je moguće predvidjeti i generalizirati poslove spremanja te pretraživanja pohranjenih ulaznih podataka, to je bilo moguće kreirati programski sustav za obavljanje ovih poslova. U početku je kreator aplikacije koristio unaprijed napravljene programe koji su zapisivali i čitali podatke na magnetski medij u obliku datoteka. Ove usluge su stavljali na raspolaganje operacijski sustavi. Kreator aplikacije je morao voditi računa o zapisivanju i čitanju svakog pojedinog znaka. Vremenom su stvoreni specijalizirani programi za upravljanje «elektronskim skladištem» podataka.

6

Vjerojatno je svatko od nas koristio usluge garderobe na putovanjima. Osoblje garderobe prima od nas prtljag na pultu, sprema ga na police, izdaje nam potvrdu i kod podizanja prtljaga vrlo brzo ga pronađe i izruči. Uočio sam da u velikim garderobama pitaju putnike: «Kada ćete podići?». Odgovorio sam «Za 2-3 sta». Onda su moj prtljag stavili na policu sasvim blizu primopredajnog pulta. Ja im ništa nisam govorio o tome kako i gdje će spremiti moje putne torbe. Jedna dama je kazala, kako će trebati svoj prtljag tek za 7 dana, pa su njen spremili na udaljenu policu, na samom kraju skladišta. Zaključio sam kako oni vode računa o spremanju prtljaga, a mi im samo kažemo što trebamo.

Na sličan način rade i sustavi za upravljanje bazom - «elektronskim skladištem» podataka. Kreator aplikacije im preda podatke na «pultu», oni ih spreme i sami vode računa o organizaciji podataka, kako bi ih brzo pronašli, te nam ih ponovno predaju na «pultu» kada ih trebamo. Štoviše, iste spremljene podatke mogu transformirati i predati nam u različitim oblicima, poredane na jedan ili drugi način, baš kako ih u datom momentu zahtijevamo.

Baza podataka je elektronsko skladište podataka zapisanih na mediju za masovnu pohranu, pri čemu su podaci tako organizirani da se lako i brzo pronađu i to u onom opsegu koji zadovoljava postavljeni kriterij, te prezentiraju u pogodnom obliku. Spremanjem, pronalaženjem i sortiranjem podataka upravlja poseban programski sustav: DBMS ( database management system).

Karakteristika baze podataka je:

1. velika količina podataka2. znatan broj dnevnih promjena3. različite razine izvještaja, kao:

- detaljni podaci- sumarni podaci- izračunati podaci

1.2 Vrste baza podataka

Prema stupnju usluge u smislu spremanja, održavanja, čitanja i pretraživanja podataka koju kreator aplikacije dobija od ugrađene programske opreme, te načinu organizacije podataka, baze možemo podijeliti na datotečne, hijerarhijske, mrežne, relacijske i objektne.

1.2.1 Datotečna baze podataka

Najstarije baze podataka koristile su datotečni sustav i to:- sa sekvencijalnim pristupom- sa slučajnim pristupom

Osnovna karakteristika datotečnih baza je, da je sustav za upravljanje datotekama kreatoru aplikacije pružao vrlo skromnu uslugu. U pravilu, kreiranje i uništavanje datoteke, te pisanje i čitanje. Kreator aplikacije je morao voditi računa o položaju

7

svakog znaka na disku. Najčešće se podacima pristupalo prema apsolutnom položaju na disku.Naročite poteškoće kod velikih datoteka, zadavalo je pretraživanje podataka, koje je u pravilu radilo sporo, a programeri su morali utrošiti značajno vrijeme i napr da opće implementiraju pretraživanje. Dakle, glavni napor programera bio je usredotočen na organizaciju podataka na disku i izradu procedura za spremanje, čitanje, te pretraživanje zapisa – slogova podataka. Problemi bi tek dolazili s održavanjem i potrebom naknadnih modifikacija. Dodavanje jednog polja zahtijevalo je pomicanje slogova, te izmjenu cijelih aplikacija koje sa slogom rade, jer je položaj svakog polja bio određen apsolutnom pozijom kao npr.: Ime studenta počinje s 35. byte-om sloga i završava na 64 poziciji.

Kako su programeri imali potpunu slobodu u organizaciji podataka, to je praktično svaka aplikacija, čak i unutar jedne tvrtke, bila inkompatibilna s drugima. O povezivanju aplikacija koje rade na različitim sustavima, nije se moglo ni sanjati.

1.2.2 Hijerarhijska baza podataka

Hijerarhijski model podataka nastao je šezdesetih godina, nakon što je IBM razvio sustav za upravljanje hijerarhijskom bazom IMS/VS, 1968. IMS je razvijen pod MVS operacijskim sustavom za mainframe računala. Element zapisa podatka je polje (field), pri čemu skup polja koji opisuju isti objekt čini slog ili rekord. Slogovi su u odnosu roditelj – dijete, pri čemu niti jedan slog ne može postojati kao dijete, ako za njega ne postoji roditeljski čvor. Podaci hijerarhiskog modela se organiziraju u stablo:

Hijerarhijske veze, te veze roditelj dijete realiziraju se hijerarhijskim i «Child-twin» pokazivačima.

1.2.3 Mrežna baza podataka

8

Poduzeće

Zaposlenik: Ante Ivić 1958Zaposlenik:Ivan Perić 1946

Zaposlenik: Ana Perić 1949

Dijete : Ivo Ivić 1980Dijete: Hrvoje Perić 1981

Dijete: Ana Ivić 1980

«Child-twin» pokazivač

Mrežni model podataka nastao je unapređenjem hijerarhiskog modela. Uočavamo da zaposlenici Ivan i Ana Perić mogu biti supružnici, te u tom slučaju dijete Hrvoje Perić može biti dijete kako Ivana, tako i Ane Perić:

Mrežni model implementira mogućnost pripadnosti jednog čvora u hijerarhiji većem broju nadređenih čvorova. Jednako tako, svaki roditeljski čvor može imati više djece. Veze isprepletene na ovaj način tvore mrežu, po čemu je mrežni model dobio ime.

1.2.4 Relacijska baza podataka

Programski sustav za upravljanje relacijskom bazom podataka RDBMS ( Relational database management system) nastao je kao implementacija pravila relacijskog modela podataka, koje je definirao Codd 1971. godine. Naravno, tijekom vremena, kako je raslo iskustvo i uočavane potebe, RDBMS je evoluirao, te danas postoje na tržištu programska rješenja koja omogućuju pridržavanje svih pravila relacijskog modela, a da istovremeno odzivna vremena budu zadovoljavajuća, sve «nestrpljivijim» pretražiteljima baza. Isto tako, cijena programske opreme, iskazana u $/transakciji ( provedenoj operaciji ) za cjelokupnu instalaciju je sasvim prihvatljiva. Relacijski model je skup pravila koji mora biti zadovoljen kod projektiranja baze podataka. Isto tako, Codd je definirao operacije nad relacijskim modelmom, koje kasnije implementira upitni jezik SQL ( Structured Query Language). Uspjeh relacijskog modela leži u činjenici njegove utemeljenosti na dva dobro definirana područja matematike: teoriji skupova i matematičke logike.

1.2.5 Objektna baza podataka

U posljednjem desetljeću je objektni pristup promatranja i analize aplikacijskih zadataka, te oblikovanja programskih rješenja, istisnuo raniji proceduralni pristup. Glavna razlika ova dva pristupa proizlazi iz činjenice, da su u realnom svijetu objekti opisani svojim atributima, te znaju izvršavati određene metode. Proceduralni pristup nas uči da usredotočimo svoju pažnju na niz koraka kojima se rješava programski problem. Nasuprot tome, objektni pristup upućuje koncentraciju kreatora objektnog modela na atribute i metode objekata iz realnog okruženja. Dakle, objektni pristup je bliži mišljenju u realnom svijetu, gdje objekti surađuju jedan s drugim, pri čemu je važno sučelje njihove interakcije, a manje su važni mehanizmi koji transformiraju ulazne podražaje u izlazne reakcije.

9

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

Dijete: Hrvoje Perić 1981

Oslikajmo gornju ideju primjerom: na ulicama New York-a već dvadesetih godina prošlog stoljeća su bili postavljeni automati za automatsku prodaju osvježavajućih pića ( i duhanskih proizvode, koji su jako štetni po ljudsko zdravlje, no to tada njihova prodaja na ovaj način, nije bila zabranjena ). Automat komunicira s kupcem preko tipki za izbor pića, te «prozora» za ubacivanje i povrat novca. Automati korišteni prije 80 godina su bili potpuno mehaničke naprave, a današnji koriste mikroračunala. No kupcu je svejedno, jer sučelje preko kojeg komunicira s automatom je praktično nepromijenjeno svih ovih godina: uvijek je to tipka sa slikom i natpisom pića koje naručuje.

Ideja objektno oblikovanog programa leži u dobro definiranom sučelju preko kojeg pozivač snabdjeva programski objekt ulazima i od njega dobija izlaze. Procedura obrade ostaje skrivena unutar pozvanog objekta. Upravo izrečeno, zapravo je ideja strukturnog programiranja, jedino objektni model donosi dobro definiran odnos među objektima, poboljšava komunikaciju među objektima preko interfejsa, te što je najvažnije, programske prevoditelje koji implementiraju objektni programski model. Objektni pristup unapređuje timsku izradu softvera, te povećava mogućnost ponovne upotrebe već napisanog koda ( eng. reusebility ).

Karakteristike objektnog programskog model su:

Enkapsulacija – program pozivač ( klijent ) pristupa pozvanoj strukturi (poslužitelju) isključivo preko svojstava ( property ) programskog sučelja, te pozivom izloženih metoda. Drugim riječima, neke varijable i procedure poslužiteljskog objekta su dostupne pozivaču, dok su druge skrivene. Kreator poslužiteljskog objekta u potpunosti kontrolira prava pristupa.

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

- jedna vrsta od ( a kind of )- jedan dio od ( a part of )

Pojasnimo primjerom: Osoba je opisana imenom, prezimenom i datumom rođenja. Student je jedna vrsta osobe, pa prema tome ima sve značajke osobe, ali povrh toga je njegova značajka godina studija koju pohađa. Zaposlenik je isto tako osoba, koji dodatno ima atribute: datum zaposlenja i plaća. Umirovljenik je osoba, čiji je specifičan atribut iznos mirovine ( drukčija poreska opterećenja u odnosu na plaću zaposlenika ).

U objektnom programskom modelu se definira prototip – klasa – Osoba, s atributima ime, prezime i godina rodjenja. Zatim klasa Student nasljeđuje sva svojstva osobe i njima dodaje specifičnost studenta – godina studija. Shodno tome, Zaposlenik nasljeđuje svojstva Osobe i dodaje datum zaposlenja i plaću, dok Umirovljenik nasljeđuje svojstva Osobe i dodaje mirovinu. Naravno, moguće je da netko «studira uz rad», pa bi objekt ZaposleniStudent nasljedio svojstva Zaposlenika i Studenta.

Dobitak ovakovog pristupa se iskazuje i tijekom razvoja klasa i tijekom održavanja. Naprimjer, ako klasa Osoba podržava metodu Godine starosti na dan, uz ulazni parametar Datum, onda se metoda implementira samo jednom, a koristi kod izračunavanja godina starosti u svakoj od nasljeđenih klasa. Dodatno, naslijeđene

10

klase mogu neke metode polaznih klasa nadjačati, pa se istim pozivom, zapravo odrađuje druga metoda specifična toj klasi.

Polimorfizam ( Polymorphism) – sposobnost korištenja istog izraza za izvođenje različitih operacija. Osnov ovog svojstva je poznat od najranijih programa. Zbrajamo li cijele brojeve, to se obavlja drukčijom metodom, nego kad zbrajamo brojeve u tekućem zarezu. Objektno programiranje je dosljedno, pa kreator klase određuje način izvršavanja izraza. Uzmimo na primjer klasu Boje. Poznato je da miješanjem npr. žute i plave boje dobijemo zelenu. Klasa boje može promijeniti značenje operatora plus (+) i dati kao rezultat zelenu boju, kad god se zbrajaju žuta i plava.

Poruke ( Messages) – Objekti komuniciraje putem poruka. Najčešće se implementira kao pridjeljivanje vrijednosti svojstvima ( set – get property) i funkcijskim pozivima.

Postojanost ( Persistence) - Gore izrečena svojstva odnose se na paradigmu objektog programiranja. Objektna baza mora implementirati gornja svojstva, ali isto tako implementirati svojstvo postojanosti ( perzistencije) velike količine podataka. Dakle, zapisati, čitati i pretraživati vrijednosti atributa svake instance objekta na mediju za masovnu pohranu podataka.

Koliko je autoru ovih redaka poznato, za sada ne postoji stroga, formlno prohvaćena definicija objektne baze. Doduše, mnogi proivođači sustava za upravljanje bazom podataka tvrde da su njihove baze objektne, ali je teško ići u ocjenu opravdanosti takva naziva, dok se ne prihvati formalna definicija što je objektna baza.

11

2 Relacijski model podataka

Osnovne principe i strukturu relacijskog modela podataka iznio je 1971. matematičar E.F. Codd, u to vrijeme član «IBM San Jose Research Laboratory». Najveća prednost relacijskog modela podataka je njegova utemeljenost na matematičkoj teoriji relacijske algebre ( R. Vujnović: SQL i relacijski model podataka, Znak 1995.).Prije iznošenja definicija i pravila relacijske algebre, najprije krenimo s primjerom, na kome ćemo ilustrirati maljkavosti mogućeg rješenja, koje se otklanjaju primjenom relacijskih pravila.

2.1 IS male knjižare

Kako je rečeno u definicijama informacijskog sustava i baze podataka, nije nužno da informacijski sustav bude podržan informacjskom tehnologijom. Pretpostavimo potrebu informacijskog sustava, dakle određenog ustroja, zapisivanja i korištenja informacija male trgovine knjigama. Raspoloživih naslova je tako mali broj, da se sve pregledno i bez napora može voditi olovkom na papiru.

Knjižara «FOKUS» prodaje mali broj naslova različitih izdavača. Svaki naslov je tiskan od strane samo jednog izdavača, ali jedan izdavač može izdati više naslova. IS mora raspolagati adresnim podacima izdavača, radi održavanja kontakata, poštom i telefonom. Naslov je napisan od strane jednog ili više autora. Potrebano je raspolagati podacima o autoru kao što su Ime i Prezime.

Luka, vlasnik i prodavač u knjižari, je na papiru napravio tablicu i pregledno unio slijedeće podatke:

Tablica:Knjige1Red. broj Naslov Izdavač Pošta Mjesto Ulica i kbr Telefon Autori

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

2SQL i relacijski model podataka ZNAK 10000 ZAGREB Vukovarska 56

01/413-8567

Ratko Vujnović

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

4Dalmatinska kuhinja LOGOS 21000 SPLIT Narodni trg 4

021/345-678

Ankica Biluš, Marija Rode

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

Ankica Biluš, Tanja Kesić

Luka prve probleme uočava nakon saznanja da je ZNAK preselio na novu adresu: Maksimirska 161, te da je izmijenjeni telefonski broj: 01/656-7879. Morao bi u svakom retku, gdje se pojavljuju ove informacije o izdavaču ZNAK, mijenjati. Čim bi knjižara prodavala veći broj Znakovih naslova, Luka bi uočio maljkavost svog modela podataka, jer bi morao u mnogo redaka brisati stare i upisivati nove podatke.

12

Luka ocjenjuje svoj model podataka:

Nedostatak: isti podatak o izdavačima je zapisan više puta, što ga izluđuje kod izmjena podataka. Već mu je na vrh glave brisanja i upisivanja potpuno istog podatka u mnogo redaka. Stoga zaključuje:

podijelit ću jedinstvenu tablicu Knjige1 u dvije: Knjige2 i Izdavači2, tako da svi podaci o izdavaču budu napisani samo jednom, pa će izmjenu adrsnih podataka izdavača, morati mijenjati na samo jednom mjestu.

Prednost: Sve informacije o jednoj knjizi su lako dostupne, čim se pronađe knjiga, odmah može pročitati izdavač i autore.

Tablica:Knjige2Red. broj Naslov Izdavač Autori

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

4 Dalmatinska kuhinja LOGOSAnkica Biluš, Marija Rode

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

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

Nadalje, Luka uočava da je mjesto odmah jednoznačno određeno, čim je poznat poštanski broj, dakle 10000 je ZAGREB, a 21000 SPLIT, pa odlučuje uštedjeti papir i napraviti novu tablicu Pošte, te iz tablice Izdavači ukloniti kolonu Mjesto.

Tablica:Knjige3Red. broj Naslov Izdavač Autori

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

4 Dalmatinska kuhinja LOGOSAnkica Biluš, Marija Rode

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

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

Tablica Pošte3:

13

Pošta Mjesto10000 ZAGREB10000 ZAGREB21000 SPLIT

Luki se ovo rješenje činilo dobro, sve dok nije odlučio tiskati prospekt o knjigama koje prodaje. Naime, u prospektu je trebao ispisati bibliografske podatke o svim autorima koji su napisali knjige. Uočio je veliki problem kod knjiga što su ih napisala dva ili više autora, te ponavljanje bibliografskih podataka autora u svakom retku. Isto tako, jedan autor je mogao napisati više knjiga za različite izdavače, s različitim koautorima. Nije bilo druge, nego iz tablice knjige izdvojiti kolonu autori, a da ne izgubi vezu između autora i knjiga, napraviti posebnu tablicu u koju će upisivati samo identifikaciju autora i knjiga. Kako su knjigu istog naslova, npr. SQL, mogli izdati različiti izdavači, odluči knjigu identificirati naslovom i nazivom izdavača:

Tablica:Knjige4Red. broj Naslov Izdavač

1 Baze podataka DRIP2 SQL i relacijski model podataka ZNAK3 ORACLE 7 ZNAK4 Dalmatinska kuhinja LOGOS5 Dalmatinski kolači LOGOS

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

Tablica Pošte4:Pošta Mjesto10000 ZAGREB10000 ZAGREB21000 SPLIT

Tablica: Autori4Ime Prezime Datum rođenjaMladen VargaRatko VojnovićDarko HrenićAnkica BilušMarija RodeTanja Kesić

14

Tablica: Knjige_Autori4Red. broj Naslov Izdavač Autor_ime Autor_prezime

1 Baze podataka DRIP Mladen Varga

2SQL i relacijski model podataka ZNAK Ratko

Vujnović

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

Na kraju, Luka uočava da bi značajno štedio papir i trud oko upisivanja u tablicu Knjige_Autori4, ako bi tablicu povezao s Knjige4 služeći se rednim brojem knjige.Nažalost, prednost polazne tablice Knjige1, da svi podaci o knjizi budu pregledni i lako dostupni više nije očuvana. Srećom, računalo može obavito ovo povezivanje brzo i lako, te je Luka odlučio naučiti pravila relacijskog modela i upotrijebiti programski sustav za upravljanje relacijskom bazom.

2.2 Pojmovi relacijskog modela podataka

Entitet je sve ono o čemu želimo i možemo skupljati informacije i čije se pojave mogu međusobno razlikovati ( identificirati). Tako na primjer, studenti jesu entitet jer razlikujemo svakog studenta imenom, prezimenom, datumom rođenja. Kamenčići na pješčanoj plaži nisu entitet, jer ne možemo razlikovati svakog od njih. ( Riječ entitet posuđena je iz latinskog jezike i znači: ens = biće, summ = jesam, esse=biti, i znači bitnost, ono što jest)

Neki autori razlikuju pojmove entitet i tip entiteteta, smatrajući svaku pojavu objekta entitetom, a prototipsku definiciju – klasu - tipom. Tako je Ivo Ivić, rođen 22.06.1981. entitet, a prototip ime, prezime, datum rođenja tip entiteta.

Atribut – opisuje svojstva entiteta. Svaki entitet opisan je skupom atributa. Tako je osoba opisana imenom, prezimenom, datumom rođenja. Svaki atribut može primiti jednu vrijednost: ime=Ivo, prezime=Ivić, datum rođenja=22.06.1981.

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

Očito su onda moguće pojave entiteta Kartezijev produkt svih domena. Tako Hrvatska pošta katalogizira poštanske brojeva u Hrvatskoj, dakle definira domenu poštanskih brojeva, a Državni sabor je donio Zakon o registraciji trgovačkih društava, definirajući moguće djelatnosti koje ova mogu obavljati, dakle domenu djelatnosti.Odgovor na pitanje: koje djelatnosti mogu biti obavljane u mjestima Hrvatske (svako mjesto za razliku od naselja ima poštanski broj) ćemo potražiti u Kartezijevom produktu pošta i djelatnosti, jer koliko je meni poznato, svaka djelatnost zakonski

15

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

Relacija je imenovani podskup Kartezijevog produkta domena:

Neka su Di domene atributa Ai, te neka su di elementi domene Di. Tada je relacija R podskup Di x Dj, pri čemu je i, j=1,2,3 … n & i <> j, gdje je n broj atributa entiteta.

Relacijska shem R sastoji se od naziva relacije i konačnog skupa (naziva) atributa odnosno stupaca ( A1, A2, … An ), koji opisuju istoimenu relaciju.Uobičajeni način pisanja relacijske sheme je R(A1,A2, … An), odnosno, R(A1:D1, A2:D2, … An:Dn).Ime relacije mora biti jedinstveno, jednako kao i imena atributa iste relacije. Redoslijed atributa relacije nije bitan.

N-torka je jedan element iz skupa Kartezijevog produkta svih atributa. U relaciji ne mogu postojati dvije identične n-torke.

Ključ relecije je minimalni skup atributa čije vrijednosti jednoznačno identificiraju svaku n-torku relacije.

Ključ relacije R skup je atributa K iz R, tako da svake dvije n-torke r1 i r2 relacije R imaju različite vrijednosti atributa K, tj. da je ri(K)=tj(K), samo za i=j.

Relacijska shema baze podataka je skup relacijskih shema.Relacijska baza podataka je skup relacija definiranih relacijskom shemom baze podataka.

U praksi je uobičajeno korištenje pojmova: tablica – je fizička implementacija relacijske shemekolona – implementacija atributaredak – implementacija n-torke

2.3 Relacijska algebra

Relacijska algebra definira skup formaliziranih operacija nad relacijama. Rezultat bilo koje operacije je relacija. Neke od operacija dobro su poznate u teoriji skupova. Osnovne operacije su:

- unija- razlika- Kartezijev produkt- projekcija- restrikcija- prirodno i theta spajanje- presjek- dijeljenje

Unija

16

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

Studenti1:Ime PrezimeIvo IvićAna MarićJosip Petrić

Studenti2:Ime PrezimeLuka DadićAna Marić

Studenti1_UNIJA_Studenti2:Ime PrezimeIvo IvićAna MarićJosip PetrićLuka Dadić

Razlika

Razlika – diferencija dviju unijski kompatibilnih relacija R(A1,A2, … An) i S(A1,A2, … An) je nova relacija T(A1,A2, … An) koja obuhvaća sve n-torke iz R, koje nisu sadržane u S.

Studenti1:Ime PrezimeIvo IvićAna MarićJosip Petrić

Studenti2:Ime PrezimeLuka DadićAna Marić

Studenti1_MINUS_Studenti2:Ime PrezimeIvo IvićJosip Petrić

Studenti2_MINUS_Studenti1:Ime PrezimeLuka Dadić

17

Kartezijev produkt

Kartezijev produkt dviju relacija R(A1,A2, … An) i S(B1,B2, … Bm) je nova relacija T(A1,A2, … An,B1,B2, …Bm) koja se sastoji od n-torki nastalih spajanjem svake n-torke relacije R sa svakom n-torkom relacije S.

Jasno je, broj n-torki u novoj relaciji T produkt je broja n-torki u R i S.

Projekcija

Projekcija relacije R nova je relacija T koja se sastoji od atributa relacije R po kojima je obavljena operacija projekcije i u kojoj su uklonjene jednake n-torke.

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

Restrikcija

Restrikcija relacije R(A1,A2, … An) je nova relacija T(A1,A2, …An) koja se sastoji od n-torki relacije R koje ispunjavaju zadani uvjet.

Spajanje

Theta-spoj je restrikcija Kartezijevog produkta relacija R i S opisana formulom A<operator>B, gdje je A atribut relacije R, a B atribut relacije S.

Vanjsko spajanje

Operacija vanjskog spoja relacija R i S je nova relacija T, koja je jednaka operaciji spoja R i S, uz dodatak n-torki iz relacija R i S koje nisu sadržane u spoju. Te n-torke su popunjene null-vrijednostima na mjestima nedostajućih atributa.

18

2.4 Coddova pravila

Radi izbjegavanja nesuglasja oko toga koji sustav za upravljanje bazom podataka je, a koji nije relacijski, Codd je 1985. definirao 12 pravila od kojih barem 6 sustav mora ispunjavati, kako bi se smatrao relacijskim. Za nas su značajna ova pravila, kako bismo razumjeli što podržava relacijska baza i kako bismo mogli iskoristiti njene mogućnosti, kod projektiranja relacijske baze podataka. Drugim rječima, narušavanjem ovih pravila postupkom projektiranja aplikacijske baze, naša baza ne može nositi atribut relacijska, iako koristimo relacijski sustav za upravljanje bazom.

Pravilo 0: Bilo koji sustav za upravljanje bazama podataka koji se smatra relacijskim, mora upravljati bazom podataka na potpuno relacijski način i relacijskom metodom.

1. Predstavljanje informacija: Sve informacije u relacijskoj bazi podataka logički su predtavljene isključivona jedan način: vrijednostima u tablicama, tj. relacijama

2. Obvezna logička dostupnost: Svaka najmanja vrijednost ( atom informacije, tj, jedna vrijednost atributa u jednoj n-torci) u relacijskoj bazi mora biti logički dostupna preko kombinacije imena relacije, vrijednosti promarnog ključa i imena atributa.

3. Prezentacija nepostojeće informacije: Relacijska baza podataka mora podržavati koncept Null vrijednosti, neovisno o tipu podatka. Pod pojmom Null vrijednosti se podrazumijeva vrijednost atributa koja nije poznata u datom vremenskom trenutku.

4. Dinamički on-line katalog: Na lokalnoj razini baza podataka opisana je na isti način kao i obični podaci, tako da ovlašteni korisnici mogu koristiti isti upitni jezik za pretraživanje strukture baze, opisa objekata baze, kao i za pretraživanje podataka.

5. Sveobuhvatni jezik za manipulaciju podacima: Relacijski sustav mora podržavati najmanje jedan jezik čiji se izrazi pomoću dobro definirane sintakse, mogu prezentirati kao nizovi znakova i koji mora podržavati:- definiranje podataka- definiranje pogleda- manipulaciju podacima ( interaktivno i iz aplikacije)- ograničenja vezana uz integritet podataka- autorizaciju orisnika- upravljanje transakcijama

6. Ažuriranje pogleda: Svi pogledi koji se po relacijskoj teoriji mogu ažurirati, moraju se moći ažurirati i u implementiranom modelu ( tablicama na kojima se pogled temelji).

7. Visok nivo unosa, ažuriranja i brisanja: Svojstvo manipulacije relacijom ili pogledom kao običnim operandom mora biti moguće ne samo kod pretraživanje, već i pri unosu, ažuriranju i brisanju podataka.

8. Fizička neovisnost podataka: Aplikacije i aktivnosti koje korisnik poduzima prema bazi potpuno su neovisne o metodi pristupa ili o strukturi spremanja podataka.

9. Logička neovisnost podataka: Aplikacije i aktivnosti koje korisnik poduzima prema bazi, ostaju nepromjenjene kad god je učinjena promjena na relacijama koja je po teoriji dopuštena i koje ne narušava neovisnost podataka.

19

10. Neovisnost integriteta: Ograničenja na integritet podataka ne smiju biti dio aplikacije već moraju biti sadržana u katalozima baze.

11. Neovisost distribucije: : Bez obzira na to, podržava li sustav distribuciju ili ne, jezik sustava mora biti takav da podržava distribuciju bez uticaja na aplikativne programe.

12. Pravilo o nesubverzivnosti: Ako sustav podržava jezik niskog nivoa, taj jezik ne smije biti korišten da bi se zaobišla ili ignorirala pravila o integritetu.

2.5 Ograničenja relacijskog modela

Ograničenja su definirana kako bi se podržala ispravnost i istinitost podataka. Pravila se nazivaju i pravilima integriteta podataka.Važno je imati na umu, da dobar informacijski sustav počiva na dobro definiranoj bazi podataka. Baza se pak temelji na dobro definiranom modelu podataka. Ključni činitelj dobrog modela podataka su ispravno uočena i provedena ograničenja.

Ograničenja dijelimo na:

- ograničenja strukture- ograničenja ponašanja

2.5.1 Ograničenja strukture

Ograničenja strukture nasljeđuju se iz definicije relacijskog model i izražavaju specifična svojstva elemenata relacijskog modela.

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

- Minimalne i maksimalne vrijednosti atributa- Uvjetom koji vrijednost mora zadovoljiti- Nabrajanjem vrijednosti

Ograničenje Null vrijednosti – definira da li vrijednost atributa može biti nedefinirana. Ako je dopuštena null vrijednost, ne moramo unijeti podatak, a ako nije dopuštena, često se kaže da je podatak mandatoran – obvezan, nije moguće upisati redak, ako se ne navede dopuštena vrijednost atributa.

Ograničenje jedinstvenosti ključa ili entitetski integritet – vrijednost primarnog ključa ne smije biti Null – vrijednost. Isto tako nije moguće unijeti dvije n-torke s istom vrijednosti primarnog ključa. Ista vrijednost primarnog ključa znači ili da je unijeta pogrešna vrijednost jednog od atributa koji identificiraju objekt, ili da se radi o istom objektu ili pak, da skup atributa koji moraju jedinstveno identificirati objekt nije dostatan.

20

Referencijsko ograničenje ili integritet stranog ključa – strani ključ u relaciji mora biti jednak jednoj od vrijednosti u relaciji gdje je on promarni ključ ili pak može ostati nedefiniran, tj. primiti Null-vrijednost.

Navedena ograničenja odnose se na strukturu podataka.

2.5.2 Ograničenja ponašanja

Ograničenje ponašanja vodi eliminaciji redudantnosti zapisa, a time olakšanim promjenama podatka i ušedi prostora za pohranu. Ograničenje ponašanja promatramo kroz različite tipove ovisnosti. Najvažnije su funkcijska, višeznačna i spojna ovisnost.

2.5.2.1 Funkcijska ovisnost

Neka su A i B podskupovi atributa u relacijskoj shemi R. Funkcijska ovisnost f:AB vrijedi onda i samo onda, ako za bilo koje dvije n-torke t1(A) i t2(A) za koje vrijedi t1(A)=t2(A), istovremeno vrijedi i t1(B)=t2(B). Tada kažemo da A funkcijski određuje B.

Na primjer, u tablici Knjige1, kad god je poštanski broj 10000, mjesto je Zagreb i kad god je poštanski broj 21000, određeno je mjesto Split. Kažemo da poštanski broj funkcijski određuje mjesto.

Definirani su aksiomi za izvođenje funkcijskih ovisnosti:

F1) Refleksivnost: ako je A podskup od B, tada B A. ( znak «čitat funkcijski određuje»)

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

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

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

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

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

Aksiomi F1, F2 i F6 nazivaju se Armstrongovi aksiomi i oni čine potpuni skup aksioma, jer se aksiomi F3, F4 i F5 daju izvesti iz njih. Navedene aksiome dobro je znati jer su temelj za pronalaženje funkcijskih ovisnosti i modifikacije nad strukturom podataka.

2.5.2.2 Višeznačna ovisnost

Neka su A i B disjunktni podskupovi atributa u relacijskoj shemi R i neka je relacijska shema Z jednaka Z = R – AB. Kažemo da relacija r udovoljava uvjetima višeznačne ovisnosti (VZO), odnosno A ->>, ako vrijedi: uvijek kada relacija r sadrži n-torke

21

t1(ABC)=a(b1)(c1) i t2(ABC)=a(b2)(c2), onda mora sadržavati i n-torke t3(ABC)=a(b1)(c2) i t4(ABC)=a(b2)(c1). Pojasnimo višeznačnu ovisnost primjerom.

Student Sport JezikIvić PLIVANJE NJEMAČKIIvić TRČANJE ENGLESKIIvić PLIVANJE ENGLESKIIvić TRČANJE NJEMAČKI

Dakle, student Ivić se bavi sportovima PLIVANJE i TRČANJE; te govori strane jezike NJEMAČKI i ENGLESKI. Dakle, ukoliko postoji n-torka da se jedan student (a=Ivić), bavi (b1=PLIVANJEM) i zna (c1=NJEMAČKI), te (b2=TRČANJEM) i (c2=ENGLESKI), onda moraju postaojati i n-torke (a=Ivić)(b1=PLIVANJE)(c2=ENGLESKI), kao i (a=Ivić)(b2=TRČANJE)(c1=NJEMAČKI).

To dokazuje da atributi Sport i Jezik nemaju nikakvih međusobnih ovisnosti, dok Student funkcijski određuje i Jezik i Sport, pa vrijede višeznačne ovisnosti:

STUDENT ->> SPORT i STUDENT ->> JEZIK

To dokazuje da se mogu pojavljivati redundantni podaci, koji mogu dovesti do anomalija u ažuriranju baze podataka, zato što moraju postojati sve kombinacije parova sport – jezik. Anomalija ove vrsti, odnosno ovisnost, riješit će se «razbijanjem» početne relacije na dvije:

Student SportIvić PLIVANJEIvić TRČANJE

Student JezikIvić NJEMAČKIIvić ENGLESKI

Dekompozicija tablica je reverzibilna, to jest, da se prirodnim spajanjem tablica po ključu student, dobija izvorna tablica kombinacija sportova i jezika.

2.6 Normalizacija

Normalizacija je postupak uklanjanja nepoželjnih funkcijskih ovisnosti, a provodi se radi postizanja dobrih statičkih i dinamičkih svojstava baze podataka:

- učinkovitost pristupa podacima i jednostavnost njihova pretraživanja- kontrola nad redundancijom ( višestrukim pojavljivanjem podataka u bazi)- kontrola nad anomalijama koje se mogu pojaviti kod ažuriranja podataka

22

Definirano je šest normalnih formi, a u praksi je potrebno i najčešće dovoljno, dovesti sve relacije u treću normalnu formu.

2.6.1 Prva normalna forma

Relacija se nalazi u prvoj normalnoj formi (1NF) ako je svaki njen atribut atomičan, što znači da sadrži samo jednu vrijednost, nikako više vrijednosti odvojenih npr. zarezom. Dvodimenzionalna tablica ima u svakoj ćeliji samo jednu elementarnu vrijednost, koja se ne može dalje rastaviti bez gubitka smisla informacije. Ključ uvijek ima jedinstvenu vrijednost, a za svaku njegovu vrijednost može se pojaviti samo jedna vrijednost neključnog atributa:

Definicija: Relacija se nalazi u prvoj normalnoj formi (1NF) ako su svi neključni atributi funkcijski zavisni o ključu relacije.

Primjer 1:

Čest je slučaj da se cijene artikala vode u Eurima, a prikazuju u Kunama, množeći iznos u Eurima tečajem Kune:

Tablica:Knjige_0#Naslov Cijena u

EURIMATečaj Kune

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

Ključ tablice Knjige_0 je Naslov ( # ispred imena označava primarni ključ). Jasno je da cijena svake knjige ovisi o kojoj se knjizi radi, a to nam jednoznačno određuje naslov knjige. Prema tome, neključni atribut cijena ovisi o ključu. Tečaj Kuna – Euro, nipošto ne ovise o naslovu knjige, dakle, tablica Knjige_0 nije u prvoj normalnoj formi. Tablica koja nije u prvoj normalnoj formi ne može se zvati relacijom, jer je po definiciji relacija barem u prvoj normalnoj formi.Rješenje: dekomponirati tablicu Knjiga_0 u dvije:

Tablica:Knjige_1#Naslov Cijena u

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

Tablica:Tečajna_Lista_1#Datum Tečaj Kune09.12.2002 7,42

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

23

Primjer 2:

Tablica:Knjige_0

Kataloška oznaka NaslovBroj strnica Izdavač Pošta Mjesto Autori

1 Baze podataka 162 DRIP 10000 ZAGREB Varga2 SQL i relacijski

model podataka419

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

kuhinja420

LOGOS 21000 SPLITBilušRode

5 Dalmatinski kolači

360LOGOS 21000 SPLIT

BilušKesić

U tablici Knjige_0, upisana je adresa izdavača, ali isto tako prezimena svih autora naslova. Tablica nije u prvoj normalnoj formi, jer podaci u koloni autori nisu atomični ( dakle, niti se ne može utvrđivati funkcijska ovisnost, jer jedan atom može funkcijski ovisiti, a drugi ne).

Rješenje: Rascijepiti neatomične podatke u koloni Autori, dodavanjem redaka za svakog autora, kako bi u jednoj ćeliji Autor, bude samo jedno prezime.

Tablica:Knjige_0A ( nema primarni ključ)Kataloška

oznaka NaslovBroj stranica Izdavač Pošta Mjesto Autor

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

podataka419

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

Sada imamo atomične podatke, te moramo definirati primarni ključ relacije. Postavlja se pitanje što određuje atribut Broj stranica? Jasno je da broj stranica knjige ovisi o Kataloškoj oznaci. Ključ mora imati jedinstvenu vrijednost, a u slučaju kada su jedan naslov napisala dvojica ili više autora, vrijednost atributa Kataloška oznaka se ponavlja. Stoga, definirajmo primarni ključ slaganjem atributa Kataloška oznaka + Autor (Relacija Knjige_1B). Primjetimo, hipotetski slučaj kada bi jedan naslov mogao napisati samo jedan autor, tada bi ključ mogao biti jednostavan, činio bi ga samo atribut Kataloška oznaka. ( Relacija Knjige_1A).

Relacija:Knjige_1A ( jednostavan ključ)

#Kataloška oznaka Naslov

Broj stranica

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

model podataka419

ZNAK 10000 ZAGREB Vujnović3 ORACLE 7 780 ZNAK 10000 ZAGREB Hrenić4 Dalmatinska 420 LOGOS 21000 SPLIT Biluš

24

kuhinja5 Dalmatinski kolači 360 LOGOS 21000 SPLIT Biluš

Tablica:Knjige_1B(složeni ključ)#Kataloška

oznaka NaslovBroj stranica Izdavač Pošta Mjesto #Autor

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

model podataka419

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

kuhinja420

LOGOS 21000 SPLIT Biluš4 Dalmatinska

kuhinja420

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

Svi neključni atributi ovise o ključu, pa možemo kazati da smo doveli relaciju u prvu normalnu formu ( u oba slučaja).Usprkos tome što smo relaciju doveli u prvu normalnu formu, uočavamo značajne anomalije, prije svega u redundantnosti podataka, što vodi nepotrebnom trošenju medija za spremanje podataka i vrlo je otežano mijenjanje. Dakle, nije dovoljno dovesti relaciju u prvu normalnu formu.

2.6.2 Druga normalna forma

Zavisnost neključnih atributa o dijelovima ključa je uzrok anomalija. Poželjna je potpuna funkcijska zavisnost o cijelom ključu, odnosno o svim dijelovima složenog ključa.

Relacija se nalazi u drugoj normalnoj formi (2NF) ako su svi neključni atributi potpuno funkcijski zavisni o bilo kojem (mogućem) ključu relacije i to o svim dijelovima ključa.

Relacija Knjige_1A ima jednostavan ključ, dakle čini ga samo jedan atribut i ona samim tim zadovoljava pravilo druge normalne forme. Dakle, možemo reći da je relacija odmah u drugoj normalnoj formi, ako joj je ključ jednostavan.

Relacija Knjige_1B nije u drugoj normalnoj formi, jer neključni atributi Pošta i Mjesto, doduše ovise o dijelu ključa Kataloški broj, tranzitivno preko Izdavača, ali ne ovise o dijelu ključa Autor. Isto tako, određeni autor funkcijski određuje Naslov, ali ne i izdavača, jer isti autor može napisati Naslov i za drugog izdavača.

Rješenje: Napraviti pouzdanu dekompoziciju relacije ( reverzibilnu), tako da se neključni atributi koji ovise samo o dijelu ključa premjeste u novu relaciju, skupa s dijelovima ključa koji ih funkcijski određuje. U našem primjeru, o dijelu ključa Autor, ne ovisi izdavač, pa prema tome niti atributi koji ovise o izdavaču. Kataloška oznaka

25

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

Relacija:Knjige_2#Kataloška

oznaka NaslovBroj starnica Izdavač Pošta Mjesto

1 Baze podataka 162 DRIP 10000 ZAGREB2 SQL i relacijski

model podataka419

ZNAK 10000 ZAGREB3 ORACLE 7 780 ZNAK 10000 ZAGREB4 Dalmatinska

kuhinja420

LOGOS 21000 SPLIT5 Dalmatinski kolači 360 LOGOS 21000 SPLIT

Relacija: Knjige_Autori_2

#Kataloška oznaka #Autor

1 Varga 2 Vujnović3 Hrenić4 Biluš4 Rode5 Biluš5 Kesić

Nakon dekompozicije, obje su relacije u drugoj normalnoj formi.

2.6.3 Treća normalna forma

Još uvijek nalazimo na redundantnost podataka. Naime, Izdavač jednoznačno određuje Poštu i Mjesto izdavača. Štoviše, Mjesto je funkcijski određeno poštanskim brojem. Anomalija ovakvih podataka se ogleda u nepotrebnom trošenju medija za spremanje, kao i potrebom za promjenama u više redaka poštanskog broja i mjesta kad se izdavač preseli u drugo mjesto.

Relacija se nalazi u trećoj normalnoj formi(3NF) ako ni jedan neključni atribut nije tranzitivno ovisan o bilo kojem ključu relacije.

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

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

U našem primjeru nalazimo tranzitivne zavisnosti: Izdavač je određen Kataloškim brojem, te Izdavač funkcijski određuje Poštu. Dakle, Pošta ovisi o ključu, ali tranzitivno preko Izdavača. Nadalje, Mjesto ovisi o Izdavaču tranzitivno preko Pošte. Dvije tranzitivne ovisnosti uklanjamo pouzdanim dekomponiranjem relacije Knjige_2 u relacije, Knjige_3, Izdavači_3 i Pošte_3:

26

Relacija:Knjige_3#Kataloška

oznaka NaslovBroj stranica Izdavač

1 Baze podataka 162 DRIP2 SQL i relacijski

model podataka419

ZNAK3 ORACLE 7 780 ZNAK4 Dalmatinska

kuhinja420

LOGOS5 Dalmatinski kolači 360 LOGOS

Relacija:Izdavači_3Izdavač PoštaDRIP 10000ZNAK 10000LOGOS 21000

Relacija:Pošte_3Pošta Mjesto10000 ZAGREB21000 SPLIT

2.6.4 Boyce-Coddova normalna forma

Dovođenje relacije u treću normalnu formu je zadovoljava većinu praktičnih primjena. Iako ona rješava ponašanje neključnih atributa, ne rješava problem koji se javlja kod složenih primarnih ključeva. Prepostavimo trgovačku kuću koja ima više referenata prodaje. Svaki od njih održava kontakt s jednim kupcem i prodaje mu jedan ili više artikala.

Relacija: Referent_Artikal_3#Referent #Artikal KupacIvić Papir NaprijedJurić Olovke PoletMarić Omotnice SrimaMarić Bilježnice SrimaTomić Flomasteri Swing

U gornjoj relaciji vrijede funkcijske zavisnosti:

(Referent,Artikal) Kupac, te Kupac Referent, jer referent veže određeni artikal uz jednog kupca, a kupac je vezan samo uz jednog referenta. Iako je relacija u trećoj normalnoj formi, uočava se redundancija podataka, koja uzrokuje anomalije u obradi: informacija da je kupac Srima vezan uz referenta Marić, jednom po artiklu omotnice, a drugi put po artiklu bilježnice, prisutna je u dvije n-torke. Ova se redundancija otklanja dekompozicijom na dvije relacije.

27

Relacija je u Boyce-Coddovoj normalnoj formi (BCNF) ako sve funkcijske zavisnosti relacije proizlaze iz njezinog ključa.

Relacija je u BCNF ako ne postoji ni jedan tranzitivno zavisan atribut, uključujući i atribute ključa. BCNF je gotovo identična 3NF, s time da uvjete o tranzitivnoj neovisnosti proteže i na sam ključ.

Iz definicije je jasno zašto relacija Referent_Artikal_3 nije u BCNF. Funkcijska zavisnost Kupac Referent ne proizlazi iz ključa.

Relacija: Kupac_Artikal_BCNF#Kupac #ArtikalNaprijed PapirPolet OlovkeSrima OmotniceSrima BilježniceSwing Flomasteri

Funkcijska zavisnost: (Kupac, Artikal) 0.

Relacija: Kupac_Referent_BCNF#Kupac ReferentNaprijed IvićPolet JurićSrima MarićSwing Tomić

Funkcijska zavisnost: Kupac Referent.

Gore provedena dekompozicija nije reverzibilna, jer je izgubljena funkcijska zavisnost Referent Artikal, dakle sačuvana je informacija o tome koji se artikli prodaju svakom kupcu, te koji referent opslužuje svakog kupca, ali je izgubljena informacija po kojim artiklima referent poslužuje kupca.

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

2.6.5 Četvrta normalna forma

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

Relacija: Student_Sport_Jezik_BCNF#Student #Sport #JezikIvić PLIVANJE NJEMAČKIIvić TRČANJE ENGLESKIIvić PLIVANJE ENGLESKIIvić TRČANJE NJEMAČKI

28

Kako je očito da u relaciji ne vrijedi niti jedna funkcijska zavisnost, relacija je u BCNF. Ipak, velika redundancija rezultira u manjkavosti korištenja medija za spremanje podataka i otežava izmjene podataka.

Relacija u kojoj je zadan skup funkcijskih i višeznačnih ovisnosti, u četvrtoj je normalnoj formi (4NF), ako je svaka višeznačna ovisnost X ->> Y trivijalna ili je X ključ relacije.

Pouzdanim dekomponiranjem se relacija prevodi u dvije nove relacije, koje spajanjem rezultiraju polaznom relacijom, pa kažemo da je dekompozicija reverzibilna, dakle pouzdana.

Relacija: Student_Jezik_5#Student #JezikIvić ENGLESKIIvić NJEMAČKI

Relacija: Student_Sport_5#Student #SportIvić PLIVANJEIvić TRČANJE

2.6.6 Peta normalna forma

Relacija R, u kojoj je zadan skup funkcijskih i spojnih ovisnosti, u petoj je normalnoj formi (5NF), ako je svaka spojna zavisnost *(R1,R2, ... Rn) trivijalna ili je svaki Ri ključ u R.

Relacija je u 5NF, ako su iz nje izbačene sve spojne zavisnosti, odnosno, ako se više ne može pozdano (reverzibilno) dekomponirati.

Relacija: Student_Instrument_NastavnikBr.Indeksa Instrument Nastavnik1 Violina Anić1 Flauta Perić2 Violina Perić

Problem se rješava dekompozicijom na 3 relacije:

Relacija: Student_Nastavnik_5Br.Indeksa Nastavnik1 Anić1 Perić2 Perić

Relacija: Student_Instrument_5

29

Br.Indeksa Instrument1 Violina1 Flauta2 Violina

Relacija: Instrument_Nastavnik_5Instrument NastavnikViolina AnićFlauta PerićViolina Perić

No, većina se relacija koje predstavljaju implementaciju n – arne ( n>2) veze ne može dekomponirati, jer ponovnim spajanjem nastaju nepostojeće n-torke:

Relacija: Student_Instrument_Nastavnik_SBr.Indeksa Instrument Nastavnik1 Violina Anić1 Violina Perić1 Flauta Perić2 Violina Perić

30

nova pogrešna n-torka

3 Životni ciklus baze podataka

Životni ciklus baze podataka slijedi identične korake koji se primjenjuju u analizi i oblikovanju programske podrške, koji su dobro utvrđeni sedamdesetih godina. Valja kazati, kako postavke programskog inženjerstva vuku svoje korijene iz inženjerstva općenito, odnosno graditeljstva. Naime, životni ciklus jedne zgrade, započinje stvaranjem idejnog rješenja, praćenog skicama i modelima, koje izrađuju arhitekti, surađujući s investitorom i budućim korisnicima. Metodom usmjerenog razgovora (interview) arhitekt saznaje želje investitora i uklapa ih u estetski prihvatljiva i tehnički izvediva rješenja. Nakon toga građevinski inženjeri izvode statičke i dinamičke proračune, s ciljem izračunavanja nosivosti temelja, zidova, kako bi zgrada izdržala teret vlastite konstrukcije, te dinamička naprezanja uzrokovana vjetrom ili možebitnim zemljotresom. Dizajneri interijera oblikuju unutrašnje uređenje do najsitnijeg detalja.Nakon što je zgrada izgrađena, slijedi njeno korištenje, održavanje, otklanjanje uočenih nedostataka, a ponekad i naknadne modifikacije u cilju zadovoljavanja zahtjeva koji su definirani tijekom eksploatacije objekta.

Identični životni ciklus prolazi informacijski sustav, pa tako i baza podataka, kao njegova sastavnica. Možemo povući usporedbu baze podataka s temeljem građevine.

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

- Analiza- Oblikovanje- Implementacija- Eksploatacija- Održavanje i naknadne modifikacije

3.1 Faze životnog ciklusa baze

Analiza – vrlo je vjerojatno da je neki posao odavna obavljan primjenom postojećih tehnoloških postupaka, prije informatizacije. Postupkom analize, primjenom metode usmjerenog razgovora (interview), s osobljem koje pozna tehnologiju posla, se identificiraju izlazi koje informacijski sustav mora producirati. Da bi se izlazi mogli producirati, potrebno je programsku podršku snabdjeti određenim ulazima. Neki ulazi će se definirati u tijeku izvođenja programa, no neki drugi moraju biti pohranjeni na mediju za mosaovnu pohranu podataka, najčešće magnetskim diskovima. Projektant baze podataka mora identificirati upravo te, tzv. perzistentne ulaze. Naprimjer, kod prodaje automobil, sve relevantne informacije o vozilu valja pohraniti u bazi podataka. Kupac definira kriterije koje mora zadovoljiti automobil od njegova interesa – kriterije pretraživanja. Ovi kriteriji ne moraju biti perzistentni, već se definiraju prije početka pretraživanja, te se zaboravljaju nakon obavljene potrage. Dakako, podržava li informacijski sustav naknadno pretraživanje, onda će i kriterije valjati sačuvati. Naime, u momentu pretrage kupac može ne pronaći željeni auto, a IS može osigurati spremanje njegovih kriterija, te po njima pretraživati, npr. jednom

31

dnevno, da li se u međuvremenu pojavio auto koji zadovoljava kriterije i o tome kupca obavijestiti e-mailom.

Logičko ( konceptualno) oblikovanje – faza analize završava definicijom pojmova i opisom entiteta, njihovih atributa, te mogućih domena, najčešće prirodnim jezikom (hrvatskim ili engleskim). Nakon toga, valja identificirati entitete, atribute i domene, te metode - funkcije. Najčešće imenice iz opisa prirodnim jezikom vode entitetima i njihivim atributima, a pridjevi i brojčani podaci definiraju domene. Rezultat ovog koraka su relacije prikazane prikladnim simbolima. Vrlo je vjerojatno da će u ovoj fazi relacije posjedovati nepoželjnu redundantnost, kao posljedicu nedopuštenih funkcijski zavisnosti, pa se primjenjuje postupak normalizacije, iterativno, sve dok ne dovedemo sve relacije barem i obavezno u treću normalnu formu (3NF). Nakon toga slijedi utvrđivanje međusobnih veza među relacijama i njihov prikaz modelom Entiteti – veze. Dakako, u prikazu se koristimo simbolima, zavisno izabranoj metodi.

Implementacija – je postupak definicije relacija u bazi podataka, pri čemu entiteti (ili tipovi entiteta) postaju tablice, atributi kolone, a domena služi kao podloga za izbor tipa podatka i eventualna integritetska ograničenja ( ograničenje null vrijednosti, ograničenje područja vrijednosti uvjetom koji podaci moraju zadovoljiti ili referencijalnim, tj. integritetom stranog ključa). Slijedi izrada objekata baze podataka, najčešće pomoću grafičkog korisničkog sučelja na razvojnom računalu proizvođača IS, te generiranje komandi upitnog jezika (SQL), koje se koriste za prenošenje objekata na odredišna računala kupca.

Statička i dinamička analiza – uvrđivanjem tipova podataka svake kolone, te poznavanjem načina kako korišteni RDBMS sprema podatke na mediju, a na temelju procjene broja n-torki, odnosno redaka svake tablice, procjenjuje se fizička veličina tablica. Isto tako, u najranijoij fazi definicije projeta, potrebno je definirati odzivna vremena kritičnih, često izvođenih upita. Najbolje je da definicija odzivnih vremena bude kvantificirana ( npr. 3 sekunde nakon klika na dugme «Traži» ). Da bi odzivna vremena bila zadovoljena, važno je pravilno procijeniti važnost i ušestalost pojedinih upita, te broj klijenata koji će istovremeno «napadati» bazu podataka. Analiza upita i odzivnih vremena rezultira definiranjem odgovarajućih indeksa, koji značajno ubrzavaju pretraživanje, ali nažalost usporavaju izmjene ( upisivanje – insert, promjene – update i brisanje – delete ), jer kod svake izmjene indeksi moraju biti reorganizirani. Stoga težimo identifikaciji minimalnog broja indeksa, koji zadovoljavaju kritične upite nad «vrućim» tablicama. Kako indeksi «troše» prostor na mediju za pohranu podataka, izračunava se «statika» indeksa na temelju broja redaka tablice i poznavanja organizacije indeksa korištenog RDBMS. Ova veličina, zajedno s veličinom prostora za pohranu tabličnih podataka, služe za procjenu veličine potrebnog prostora medija za masovnu pohranu ( diska).

Eksploatacija i održavanje baze podataka - već prije početka eksploatacije potrebno je planirati sigurnost podataka i to u smislu neovlaštenog pristupa podacima, te čuvanja pričuvnih podataka – backupa. Naime, moguće elementarne nepogode ili teroristički napadi mogu uništiti cijeli računalni sustav, skupa s podacima. Isto tako kvar računalnog hardvera ili čak upad «hackera» mogu uzrokovati gubitak podataka. I pored takvih katastrofa, organizacija mora nastaviti s radom i imati na raspolaganju podatke unijete u bazu do momenta katastrofe. Vremenski period ponovne raspoloživosti podataka može biti nekoliko sekundi ili nekoliko dana nakon gubitka,

32

pa zavisno definiciji ovog intervala, izrađujemo strategiju backupa, počev od «stand-by-backup-baze» za brzi nastavka rada, do klasničnog pristupa zamjene neispravnih dijelova računala i restauracije podataka, što može potrajati nekoliko sati ili čak dana.

Tijekom eksploatacije potrebno je pratiti odzivna vremena i korist predviđenih indeksa, te po potrebi brisati nekorisne i kreirati nove korisne indekse.

U ranim fazama projekta, nije moguće predvidjeti sve funkcionalnosti informacijskog sustava, ili još češće svjesno se ide s minimalnim funkcijama, kako bi se izišlo na tržište prije konkurencije i ostvariovao prihod. Potom se sustav obogaćuje, a to zahtijeva i promjene strukture baze podataka. Vrlo je važno promjenama ne ugroziti postojeće stanje, kako u smislu funkcionalnosti, tako i u smislu odzivnih vremena.

3.2 Vrste baza podataka

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

Na jednom polu su sustavi koji podupiru donošenje odluka, DSS (Decision support system), koji se samo i isključivo pretražuju. Dakle nema izmjena podataka, samo se čitaju. Kod ovakvih sustava možemo definirati neograničeni broj indeksa ( jasno, on je ograničen veličinom medija i maksimalnim brojem indeksa koje RDBMS podržava).

Na drugom polu su baze koje nitko nebi pretraživao, već bi samo upisivale podatke (insertirale) podatke, pa niti ne trebamo definirati indekse. Naravno, ovo su samo ekstremni slučajevi, dok je najčešće istovremeno pretraživanje i promjena podataka, a takve baze nazivamo OLTP ( on-line transaction processing), dakle, promjene se obavljaju u živo, usporedno s pretraživanjem. Baze ove vrsti, mogu imati ograničeni broj indeksa, jer indeksi ubrzavaju pretraživanje, ali usporavaju promjene, jer se zajedno s promjenom podataka, mora ažurirati i stablo svih indeksa, koji sadrže promijenjeni podataka. Ovdje je to istaknuto iz razloga denormalizacije baze. Naime, normalizacija uklanja redundantnost i anomalije održavanja podataka, ali vodi većem broju tablica, koje su zapisane na različitim cilindrima diska, najčešćeg medija za pohranu baza. Upitima se tablice spajaju, a to je «skupa» operacija, pa su upiti mnogo sporiji, nego li kad nema spajanja, tj. kad su podaci «pregledno» u istoj tablici.

Potrebno je pomiriti ove dvije suprotnosti, postupkom denormalizacije. Moramo razlikovati pojmove ne-normalizirane i denormalizirane strukture. Naime, dopušteno je postojanje redundantnih zapisa podataka, ali uz jasno razlikovanje «master» podatka, koji implementira atribut iz normalizirane relacije, od «slave» podatka, koji ubrzava pretraživanje i mora vjerno slijediti promjene vrijednosti «master» podatka. Funkcija slijeđenja se može ostvariti definiranjem okidača ( trigera ), koje «okida» promjena «master» podatka, te oni izvođenjem adekvatne SQL naredbe ažuriraju «slave» podatak. Drugi način denormalizacije se može provesti upotrebom materijaliziranih pogleda. Naime, pogled (view) se definira pomoću SQL naredbe koja spaja više relacija ( tablica i drugih pogleda), radi olakšanog pisanja kasnijih upita, te radi ograničenja pristupa objektima baze ( primjenom operacija projekcije i

33

restrikcije). Klasični pogled nema fizičkog zapisa podataka na mediju, već obavlja projekciju, restrikciju i spajanje dinamički, kada se upit definiran pogledom izvodi. Možemo sebi predočiti pogled, kao zamjenu složenog upita jednim imenom, a pozivom pogleda, se zapravo izvodi upit koji leži iza tog imena.Nasuprot tome, materijalizirani pogled ima fizički zapis podataka na magnetskom mediju, kao «slave» podatke, pa se pozivom imena materijaliziranog pogleda, zapravo čita fizički zapis kopije podataka. RDBMS osigurava da kopija podataka iz različitih izvornih tablica vjerno slijedi promjene izvornoh, «master» podataka. Promjene kopije se obavljaju kod izmjene «master» podataka, pa se tijekom upita nad materijaliziranim pogledom ne obavlja dinamički spajanje većeg broja tablica.Ovom tehnikom možemo postići bazu koja apsolutno udovoljava i najstrožim teoretskim zahtjevima, a da isto tako kritični upiti budu pokriveni materijaliziranim pogledima, čime se ostvaruju iznimno dobra odzivna vremena. Naravno, broj materijaliziranih pogleda mora biti ograničen, jer bi u protivnom usporio promjene podataka kod OLTP baza, pa treba vrlo brižljivo odabrati upite pokrivene materijaliziranim pogledom.

3.3 Postupak oblikovanja baze podataka

3.3.1 Izrada modela

Aktivnost oblikovanja na svakom polju djelatnosti, karakterizira izrada modela. Od male djece koja izrađuju modele realnih objekata pomoću Lego kockica, do nuklearnih fizičara koji izrađuju modele ponašanja jezgre atoma, fizički i mentalni modeli objekata iz realnog svijeta pomažu shvaćanju ponašanja realnih objekata i zbivanja, istraživanju ideja i razumijevanju događaja.

Modeli se mogu koristi za:- opis- specifikaciju- istraživanje- komunikaciju- analizu- kategorizaciju- imitaciju

ponašanja realnih objekata i zbivanja.

Važno je uočiti konflikt: model koji osigurava mnogo detalja da bi sustav opisao potpuno, može sakriti ili otežati shvaćanje cjelovitosti. To je stvorilo ideju stvaranja, tzv. ugniježđenih ili postupnih modela. Uzmimo na primjer izučavanje povijesti Hrvata, koju ne možemo učiti izolirano od povijesnih zbivanja europske i svjetske povijesti u svakom razdoblju. Učimo li istovremeno i svjetsku i hrvatsku povijest, dolazimo do toliko detalja, da od njih ne vidimo osnovne značajke razdoblja. Zato se učenje provodi najprije učenjem svjetske povijesti u osnovnim crtama, pa onda

34

hrvatske povijesti detaljnije ( u osnovnoj školi), onda se postupak ponavlja s više detalja o svjestkoj povijesti itd. ( u srednjoj školi).Dakle, uočavamo postupnost u razumijevanju i svladavanju problema, pa isti pristup valja primijeniti i kod modeliranja objekata i zbivanja – odnosno tehnoloških postupaka – predmeta informatizacije.

3.3.2 Različiti aspekti sustava

Model mora prikazivati realne objekte i zbivanja selektivno, uzimajući u obzir bitna obilježja. U pravilu model ispušta mnogo više detalja,nego li ih uključuje. Ako bi model uključio sve moguće detalje realnih objekata, pretpostavimo li da je to opće moguće, bio bi identičan realnom životu, pa vjerojatno teško razumljiv i prihvatljiv. Oslikajmo ideju primjerom. Bacimo kamenčić s visine 10 m i zanima nas brzina kojom udari pri padu na tlo. Kao što je poznato iz fizike, brzinu računamo po modelu opisanom formulom:

v= SQRT( 2gh)

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

v = 14.8 m/s

Pri tom smo zanemarili brojne činjenice koje utiču na slobodan pad, kao trenje zraka, tlak zraka, utjecaj mogućeg vjetra itd. Ako bi vrlo kompleksnim modelom uvažili sve te utjecaje, odstupanje rezultata bi bilo neznatno, a račun složen.

Ako pak računamo brzinu kojom satelit može pasti na zemlju, ranije zanemareni utjecaji se moraju uzeti u račun, jer je njihov doprinos značajan. Dakle, osnovno u izradi modela je izbor parametara od utjecaja na konačan rezultat, a u inženjerskom pristupu, nastojimo što jednostavnijim modelom dobiti najmanje loše rezultate.

Slijedi zaključak, da u cilju postizanja što boljeg modela valja koristiti različite tehnike zajedno. Na primjer, kod medicinskog ispitivanja pacijenta, liječnik stvara model njegova zdravstvenog stanja koristeći nalaze krvi, krvni tlak, rentgentske i ultrazvučne snimke, te analizom svih nalaza zaključuje o zdravstvenom stanju.

Isto tako moramo i mi, upotrijebiti različite tehnike koje se fokusiraju na različite aspekte sustava, ali koje se nadovezuju i isprepliću, dajući kompletnu sliku sustava.Koristit ćemo:

- Model entiteti – veze- Funkcijski model- Model toka podataka

3.3.3 Model entiteti – veze

Cilj modeliranja je definirati i razumjeti činjenice značajne za poslovnu aktivnost, koje informacije mora pamtiti, te vezu među njima.

35

Koristi se pristup od vrha nadolje (Top-Down), polazeći najprije od utvrđivanja entiteta, a potom njihovih atributa.

Pojmovi od značaja u analizi entiteta- Entitet- Veza- Atribut- Jedinstveni identifikator (primarni ključ)- Podtip- Nadtip

Što može biti entitet ?

Bilo što o čemu možemo prikupljati informacije. Bilo koja imenovana stvar. Sve ono što ima posebna svojstva, koja se mogu razlikovati, bilo u domenu realnih objekata i zbivanja ili u sferi apstraktnog mišljenja. Entitet je obično imenica u rečenici napisanoj tijekom usmjerenog razgovora (interview) s korisnicima postojeće tehnologije.

Primjer entiteta:

OSOBA, POSAO, PROJEKT, TVRTKA, ODJEL, ZAPOSLENIK, KUPAC, DOBAVLJAČ

Dobro je potražiti i sinonime: drukčija imena koja znače isto. Na primjer, što je KUPAC, TVRTKA, DOBAVLJAČ ? Vjerojatno ORGANIZACIJA.

Zavisno od izabrane metode za prikazivanje modela, entiteti se mogu prikazati jednim od grafičkih simola:

3.3.4 Veze

Veza predstavlja bilo koji način na koji dva objekta istog ili različitog tipa mogu biti upućeni jedan na drugoga. Svaku je vezu dobro imenovati, naprimjer:

ZAPOSLENIK obavlja POSAOPOSAO je dodijeljen ZAPOSLENIK-u

Veze su opisane stupnjem veze i opcionalnošću:

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

36

OSOBA OSOBA OSOBA

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

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

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

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

Opcionalnost veze

Postavlja se pitanje, da li ZAPOSLENIK-u uvijek mora biti dodijeljen POSAO, ili može i ne mora biti ?

Odgovor: ZAPOSLENIKU mora biti dodijeljen POSAO.

Sada vezu možemo čitati: Svaki ZAPOSLENIK obavlja jedan ili više POSLOVA, ili obratno, svaki POSAO je dodijeljen jednom ili više ZAPOSLENIKA.

Prikaz veze:

Martinova notacija:

Chenova notacija:

ORACLE notacija:

Stupanj ili kardinalni broj veze:

37

ZAPOSLENIK POSAOobavlja

dodijeljen

ZAPOSLENIK POSAOobavljaM

N

ZAPOSLENIK POSAO

Naziv veze Martinova notacija Chenova notacija ORACLE notacijaJedan prema više 1:N 1:N

Više prema više M:N M:N

Jedan i samo jedan 1:1 1:1

Opcionalnost veze:

Naziv veze Martinova notacija Chenova notacija ORACLE notacijaOpcionalna veza (može biti) jedan

0,1 0,1

Opcionalna veza (može biti) više

0,N 0,N

Obvezna veza (mora biti ) jedan

1 1

Obvezna veza (mora biti ) barem jedan ili više

1,N 1,N

Pravilo čitanja veza:

«Svaki ( entitet )mora biti /1/

ili ( veza )

može biti /0/

jedan ili više /N/

ili (entitet)

jedan i samo jedan /1/.»

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

38

Evo nekih korisnih parova imena veza:

temelji se na – osnov zakupuje se od – isporučujeimenovan za – povjerendio od – sastavljen ododgovoran za – u nadležnosti

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

Jedan projekt može obavljati više zaposlenika, a isto tako jedan zaposlenik može istovremeno ili u različitim vremenima, raditi na više projekata.

Vezu više prema više ( M:N) teško je implementirati i održavati, stoga se ona dekomponira u dvije veze 1 naprema više ( 0,1:N + 0,1:M ).

Dakle, veza M:N se dekomponira u dvije veze 1:N, umetanjem presječnog (eng. intersection) entiteta, pri čemu je kardinalni broj (stupanj veze), na strani polaznih entiteta 1 uz zadržanu opcionalnost, dakle 1 ili 0,1, a na strani presječnog entiteta 1,M. Dakle, polazna veza «Svaki Zaposlenik može biti uključen u više projekata i Svaki projekt može uključivati više zaposlenika» je sačuvana. Presječni entitet će imati dva strana ključa, koji su primarni ključevi u polaznim entitetima, a oni zajedno čine primarni ključ u presječnom entitetu.

3.3.6 Rekurzivna veza

Rekurzivna veza predstavlja vezu entiteta sa samim sobom. Koristi se za prikazivanje hijerarhije nelimitiranog broja kompatibilnih elemenata.Na primjer, u organizaciji koja je u pravilu hijerarhiski uređena, svaki zaposlenik ima pretpostavljenog (šefa), pri čemu ovaj ima svog pretpostavljenog i tako dalje, sve do vrha piramide.

39

ZAPOSLENIK PROJEKT uključen0,M

0,N

ZAPOSLENIK

ZAP_PROJ PROJEKT0,1

M

N

0,1

šef od0,1

Dakle, «Svaka osoba može ( glavni šef nema nad-šefa) imati jednog i samo jednog neposrednog šefa, a neke osobe su šefovi većem broju osoba.»

Rekurzivna veza je zgodna za prikazivanje sastavnica, dio od – sastavljen od, teritorijalne pripadnosti itd.

3.3.7 Učestalost pojedinih vrsta veza u realnim modelima

Oznaka veze Naziv veze Učestalost1,M : 0,1 barem jedan ili više prema može biti

jedan(5) VRLO ČESTO

0,M : 0,1 može biti više prema može biti jedan (4) ČESTO0,M : 1 može biti više prema jedan i samo

jedan(3) NIJE RIJETKO

1,M : 1 barem jedan ili više prema jedan i samo jedan

(2) RIJETKO

0,M : 0,N može biti više prema može biti više (4) ČESTO U POČETNOJ FAZI

1,M : 0,N barem jedan ili više prema može biti jedan

(4) ČESTO U POČETNOJ FAZI

1,M : 1,N barem jedan ili više prema barem jedan ili više

(1) VRLO RIJETKO

1 : 0,1 jedan i samo jedan prema može biti jedan

(2) RIJETKO

0,1 : 0,1 može biti jedan prem amože biti jedan

(2) RIJETKO

1 : 1 jedan i samo jedan prema jedan i samo jedan

(1) VRLO RIJETKO

Brojevi u zagradama određuju učestalost pojave, 1 = vrlo rijetko, 5=vrlo često.

3.3.8 Atributi

Općenito kazano atributi opisuju entitet.Namjena atributa je da:

- Kvalificiraju- Identificiraju- Klasificiraju- Kvantificiraju- Izraze stanje

40

OSOBAima šefa

0,N

Postupkom oblikovanja utvrđujemo atribute od značaja u opisu entiteta, a izostavljamo iz modela one koji nisu.Tako na primjer, entitet Student može biti opisan atributima:

Atribut Kategorija OpisIme IdentificiraPrezime IdentificiraZavršena srednja škola Kategorizira Npr. u statističkoj analizi

prolaznosti s obziro iz koje škole dolazi

Studijska grupa Klasificira Prema studijskim grupamaPoloženi ispiti Kvalificira Za upis na višu godinuTežina Kvantificira Nije od značaja u ISStatus Izražava stanje Redovito upisan, ponavlja,

parcijalno upisanBračno stanje Izražava stanje Noženjen, neudata,

oženjen, udata

Jasno je da neki atributi u IS «Studentska služba» nisu značajni, kao npr. težina pa ih ispuštamo iz određenog modela. Kod modela nekog drugog IS, npr. «Zdravstvena ustanova» atribut težina je od značaja, jer je poznato da može biti povezana s nekim bolestima, pa atribut mora biti uvršten u model.

3.3.9 Opcionalnost atributa

Vrijednosti nekih atributa mogu biti nepoznate i ostati nedefinirane, dok drugi atributi moraju obavezno biti definirani. Označimo u modelu opcionalnost simbolima:

* mora biti definirano može ostati nedefiniran

Na primjer, entitet osoba je opisan atributima:Osoba* Ime* Prezime* Spolo Datum rođenjao Adresa

3.3.10 Jedinstveni identifikator

Kako je već rečeno, svaki entitet ( npr. svaki student ) mora biti identificiran na jedinstven način, jednim atributom ili skupom atributa. Jedinstveni identifikator u fazi implementacije postaje primarni ključ.

41

Atribute koji jedinstveno identificiraju pojavu entiteta simbolički označimo znakom #.

Evo nekih primjera jedinstvenog identifikatora:

Proizvod# Bar kod

Ispit#Predmet#Datum

Osoba#JMBG

Osoba#Ime#Prezime#Datum rođenja#Adresa

Naravno, atributi koji identificiraju svaku pojavu entiteta, moraju biti definirani. Što ćemo izabrati za identifikator, ovisi o konkretnom informacijskom sustavu.

Motorno vozilo#Broj šasije

Tako na primjer, broj šasije motornog vozila je odličan identifikator, jer svako motorno vozilo na svijetu ima jedinstvenu oznaku, ali u IS «Trgovina rabljenim motornim vozilima» cilj je oglasiti prodaju što većeg broja vozila, pa tako imati veću zaradu, a vlasnici motornih vozila često ne znaju napamet ovaj broj, pa bi izbor takvog identifikatora, koji mora biti definiran, odvratio mnoge klijente da isti posao odrade kod konkurentskog internet site, koji ne traži unos kompliciranih oznaka.

Dakle, izbor atributa koji identificiraju entitet, mora biti pažljiv i razlikovat će se prema namjeni informacijskog sustava.

U fazi implementacije baze podataka, jedinstveni identifikator će postati primarni ključ tablice. Čest je slučaj da jedan objekt iz realnog svijeta može jedinstveno identificirati skup većeg broja atributa. Tako osobu u mnogim IS ne može identificirati samo Prezime, nego npr. skup atributa Ime, Prezime, Datum rođenja i Adresa stanovanja. Veze među tablicama ostvarujemo odnosom primarni – strani ključ. To znači, da bi u tablici – djetetu, svaka pripadnost roditelju, bila definirana skupom od više kolona, s tekstualnim vrijednostima, koji ponekad mogu imati nekoliko stotina znakova. Pri spajanju tablica računalni hardver mora usporediti da li su vrijednosti u svim relevantnim kolonama identične traženim vrijednostima, vjerojatno znak po znak, pri čemu sva mala slova moraju biti pretvorena u velika (pretpostavljamo da baza radi «case insensitive», dakle ne razlikuje malo i veliko slovo (a i A su isti znak). Da bi izbjegli narušavanje odzivnih vremena iz ovog razloga, vrlo često, u fazi implementacije biramo primarni ključ kao apstraktan, tj. definiramo kolonu cjelobrojnog tipa od 4 byta, čije vrijednosti baza automatski

42

generira, čime je osigurana jedinstvenost. Spajanje tablica onda ostvarujemo ovim apstraktnim identifikatorom, jer računalo vrlo brzo uspoređuje 4-bytne brojeve.Primarni ključ nazivamo apstraktnim, jer on ne identificira objekt u realno svijetu, samo interno u našem IS. Kako bi spriječili pojavu dva retka s istom vrijednošću atributa, koji su zapravo trebali biti primarni ključ, jer oni identificiraju objekt u realnom svijetu, definiramo jedinstveni indeks nad skupom tih atributa. Na taj način imamo osiguranu jedinstvenost i dobili smo na brzini spajanja tablica, te uštedjeli prostor za pohranu.

3.4 Videoteka - model praktičnog primjera

Nakon obavljenog usmjerenog razgovora s naručiteljem informacijskog sustava Videoteka, napravljene su slijedeće bilješke:

Videoteka upisuje članove koji posuđuju na određeni period kasete različitih naslova. Članovi su opisani imenom, prezimenom, kućnom adresom i brojem telefona. Član se ne može upisati ako nisu poznati ovi atributi, radi vraćanja zaboravljenih kaseta. Na svaku kasetu je snimljen samo jedan naslov ( film ). Naslov je opisan nazivom djela ( filma), žanrom, trajanjem u minutama, kratkim sadržajem te akterima, kao što su producent, režiser, glavni i ostali glumci. O svakoj kaseti se vodi evidencija njenog stanja (istrošenosti), radi planiranja zamjena. Kasete se izdaju za trajanje od jednog do više dana, a najam se naplaćuje na dan vraćanja, po jedinstvenoj cijeni Kuna/dan.Članovi često žele izabrati jedan od naslova njihovih omiljenih glumaca.

Među imenicama (tiskanim masnim podvučenim kurzivom), tražimo imena entiteta ili (imenice tiskane masnim kurzivom) su kandidadti za atribute, a glagoli sugeriraju metode ( SQL upit ).

Entitetski kandidati:

Članovi# Identifikator člana* Ime* Prezime* Poštanski broj* Mjesto* Ulica i Kućni broj* Telefono Datum Rodjenjao Spol

Naslovi# Identifikator naslova* Naslovo Trajanje minutao Žanro Opis

43

Kasete# Identifikator kasete* Naslov* Stanje

Akteri# Identifikator akterao Ime* Prezime

PosudbaKaseta# Identifikator člana# Identifikator kasete# Datum izdavanjao Planirani datum vraćanjao Stvarni datum vraćanja

Analizom entiteta, zaključujemo na relacije:

ClanoviMax dužina

Prosječna dužina

# ClanID Int4 – Autoident 4 4* Ime varchar(30) 30 7* Prezime varchar(30) 30 8$ PostaID Int4 - Strani ključ – ref:

Poste4 4

* Ulica varchar(50) 50 12* Kbr Int2 2 2o KbrDodatak varchar(10) 10 1o Kat Int2 2 2o DatumRodjenja smalldatetime 4 4$ Spol Int1 – Strani ključ ref:

Spolovi1 1

Total: 137 45

PosteMax dužina

Prosječna dužina

# PostaID Int4 4 4* Posta varchar(30) 30 9Total: 35 13

Spolovi

44

Max dužina

Prosječna dužina

# SpolID Int1 1 1* Spol varchar(30) 30 6Total: 31 7

NasloviMax dužina

Prosječna dužina

# NaslovID Int4 – Autoident 4 4* Naslov varchar(80) 80 16o TrajanjeMin Int2 2 2$ ZanrID Int1 1 1o Opis varchar(1024) 1024 250Total: 1111 273

ZanroviMax dužina

Prosječna dužina

# ZanrID Int1 1 1* Zanr varchar(30) 30 6Total: 31 7

KaseteMax dužina

Prosječna dužina

# KasetaID Int4 - Autoident 4 4$ NaslovID Int4 – ref: Naslovi 4 4$ StanjeKaseteID Int1 1 1Total: 9 9

StanjeKasetaMax dužina

Prosječna dužina

# StanjeKaseteID Int1 1 1* StanjeKasete varchar(30) 30 10Total: 31 11

AkteriMax dužina

Prosječna dužina

# AkterID Int4 – Autoident 4 4o Ime varchar(30) 30 10

45

* Prezime varchar(30) 30 10o Opis varchar(255) 255 60Total: 219 84

AkteriUlogeMax dužina

Prosječna dužina

# $ AkterID Int4 ref: Akteri 4 4# $ NaslovID Int4 ref: Naslovi 4 4# $ UlogaID Int1 ref: Uloge 1 1Total: 9 9

UlogeMax dužina

Prosječna dužina

# UlogaID Int1 1 1* Uloga varchar(30) 30 12Total: 31 13

PosudbeKasetaMax dužina

Prosječna dužina

# $ KasetaID Int4 ref: Kasete 4 4# $ ClanID Int4 ref:Clanovi 4 4# DatumIzdavanja smalldatetime 4 4o PlaniraniDatumVracanja smalldatetime 4 4o DatumVracanja smalldatetime 4 4Total: 20 20

Pojašnjenje:

- varchar(n) je varijabilni tekst maksimalne dužine n znakova, s tim da stvarno zauzeti prostor odgovara broju stvarno unijetih znakova (+ m byte-ove za zapis dužine teksta).

- Int1 – 1 byte-ni cio broj, 0 ... 255 ili –128 ...0 ... 127, ovisno bazi- Int2 – 2 byte-ni cio broj, -32786 ...0 ... 32767- Int4 – 4 byte-ni cio broj ( -2**31 ...0 ... 2**31 –1 )- Autoident – baza generira broj kod insertiranja zapisa- smalldatetime – zapis datuma, način zapisa ovisi o bazi, rezolucija reda

minuta, ( kod MS SQL Server 2000, 4 byte)- * - Obvezan unos, Null vrijednost nije dopuštena- $ - Strani ključ- ref – Referentna tablica- o – unos nije obvezan, dopuštena je Null vrjednost- # - dio primarnog ključa, unos obvezan

46

Maksimalna i očekivana dužina služe kao podloga za izračunavanje potrebnog prostora za pohranu tablica.

3.5 Model entiteti – veze ( MS SQL Server 2000)

3.6 Funkcije ( metode )

Članovi - Upis novog člana- Promjena podataka člana- Brisanje člana- Traženje

Naslovi- Upis novog naslova- Promjena podatakao o naslovu- Brisanje naslova- Traženje

Kasete- Upis nove kopije- Promjena stanja kopije ( uključuje otpis datoteke )- Traženje

Akteri- Upis

47

- Promjena- Brisanje- Traženje

Izdavanje – vraćanje kaseta- Izdavanje- Vraćanje

3.7 Impementacija objekata baze podataka – primjer dviju tablica ( Microsoft SQL Server 2000 ):

CREATE TABLE [dbo].[Akteri] ([AkterID] [int] IDENTITY (1, 1) NOT NULL ,[Ime] [varchar] (30) NULL ,[Prezime] [varchar] (30) NOT NULL ,[DatumRodjenja] [smalldatetime] NULL

) ON [PRIMARY]

CREATE TABLE [dbo].[Clanovi] ([ClanID] [int] IDENTITY (1, 1) NOT NULL ,[Ime] [varchar] (30) NOT NULL ,[Prezime] [varchar] (30) NOT NULL ,[DatumRodjenja] [smalldatetime] NULL ,[JMBG] [bigint] NULL ,[PostaID] [int] NOT NULL ,[Ulica] [varchar] (50) NOT NULL ,[Kbr] [smallint] NOT NULL ,[KbrDodatak] [varchar] (10)NULL ,[Kat] [smallint] NULL ,[TelefonOperater] [smallint] NULL ,[TelefonBroj] [int] NOT NULL ,[email] [varchar] (100) NULL

) ON [PRIMARY]

ALTER TABLE [dbo].[Akteri] WITH NOCHECK ADD CONSTRAINT [PK_Akteri] PRIMARY KEY CLUSTERED (

[AkterID]) ON [PRIMARY]

ALTER TABLE [dbo].[Clanovi] WITH NOCHECK ADD CONSTRAINT [PK_Clanovi] PRIMARY KEY CLUSTERED (

[ClanID]) ON [PRIMARY]

48

4 Indeksi

Pojasnimo najprije pojam indeksa, primjerom. Želimo pronaći značenje engleske riječi «event». U englesko – hrvatskom rječniku, u zaglavlju svake stranice su napisane početna i završna riječ koje se nalaze na toj stranici. Brzo listamo stranice, gledajući samo zaglavne riječi i pronalazimo onu na kojoj u zaglavlju stoji: «even ... excess». Kako se riječ «event» u abecednom poretku nalazi između ove dvije riječi, zadržavamo se na toj stranici i pronalazimo traženu riječ (sa značenjem događaj).

Dakle, riječ smo pronašli brzo, zato što su sve riječi u riječniku poredane po abecednom redu engleskih riječi. Kažemo da je rječnik indeksiran po engleskim riječima. Kada bi ovaj isti englesko-hrvatski rječnik upotrijebili za nalaženje engleskog prijevoda hrvatske riječi «nebo», morali bismo prelistati cijeli rječnik, jer nije poredan po hrvatskim riječima. Naravno, hrvatsko-engleski rječnik, koji sadrži iste riječi kao i prethodni, bi pomogao, jer je indeksiran po hrvatskim riječima.

Ovakvu vrstu indeksa, kod kojeg su podaci fizički poredani po indeksiranoj koloni (ili kolonama), sustav MS SQL Server naziva klasterirani indeks. Jasno je da se podaci fizički mogu poredati samo na jedan način, pa je isto tako moguć samo jedan klasterirani indeks u tablici. Ova vrsta indeks pomaže kod pretraživanja područja (ranga) vrijednosti.

Potražimo sada u knjizi R. Vujnović «SQL i relacijski model podataka», pojašnjenje pojma «indeksiranje». Na kraju knjige pronalazimo indeksno kazalo, te pod slovom «I», «indeksiranje, 151». Dakle, na stranici 151 započinje pojašnjenje pojma, te brzo pronalazimo stranicu s traženim podatkom. Ovakav indeks podržavaju i sustavi relacijskih baza, a MS SQL Server ga naziva neklasterirani indeks. Može se definirati veći broj indeksa ovog tipa i svaki od njih može uključiti jednu ili više kolona.

Pogledajmo primjer organizacije podataka ( MS SQL Server 2000, no slično podatke organiziraju i ostali sustavi) na mediju za pohranu. Poznato je da se podaci čitaju i zapisuju, dakle prenose u radnu memorije, u kvantima, stranicama.Stoga i baze podataka organiziraju podatke po stranicama, kako bi koristile uslugu operacijskog sustava na sukladan način. Stoga su i podaci zapisani u jednoj tablici, zapravo razbacani po stranicama, koje mogu biti na bilo kojem cilindru diska.

Primjer organizacije tablice Studenti(Ime, Prezime, Spol) slijedi. Poredani su po stranicama stohastički, kako su dodavani u tablicu, jer nije definiran indeks.

Želimo pronaći sve studente s prezimenom između Horvat i Koštić, uključivo i njih same, zato jer svi one obavljaju vježbe kao članovi grupe B. SQL upit će biti:

SELECT * FROM Studenti WHERE Prezime BETWEEN 'Horvat' AND 'Koštić'

Kako tablica nije indeksirana, RDBMS će krenuti od prvog zapisa na prvoj stranici, uspoređivati da li prezime nalazi u zadanom intervalu, te ga prikazati, nastavljajući zapis po zapis sve do zadnjeg zapisa na zadnjoj stranici. Ovakvo pretraživanje

49

zovemo potpuno pretraživanje tablice (full table scaning). Kod tablica s velikim brojem zapisa, uzima značajno vrijeme i odziv je spor.

Stranica Zapis Ime Prezime Spol

1

1 Ivo Ivić M2 Ante Perić M3 Jure Padovan M4 Anica Zubčić Z

21 Damir Kelava M2 Kristian Brunner M3 Marina Bajramović Z

3

1 Ivica Tomić M2 Slavko Dešković M3 Slavica Perović Z4 Miranda Poljak Z

4

1 Ivan Goran Penić M2 Ivana Marić Z3 Nikolina Meštović Z4 Mate Antić M5 Paško Ivanković M

51 Domagoj Horvat M2 Hrvoje Orlandini M3 Danijela Klisović Z

6

1 Ana Belić Z2 Ivana Zubović Z3 Domina Aljinović Z4 Kata Reić Z

71 Doris Koštić Z2 Mario Lojpur M3 Franka Dodić Z

Kreiramo li klasterirani indeks po koloni Prezime, podaci će biti reorganizirani po stranicama i poredni po abecedi prezimena, kako prikazuje donja slika. Pri tome, se kreira korijen indeksa, u našem primjeru sa dva zapisa, koji senalaze na stranici 14. i koji dijele čitavu sortiranu tablicu u dva podjednaka dijela. Ovi zapisi pokazuju na srednju razinu indeksa, odnosno da se Prezime Aljinović nalazi na stranici 15. srednje razine indeksa, a Lojpur na stranici 16. Srednja razina indeksa dijeli tablicu na još manje segmente, pokazujući stranicu slijedeće razine koja sadrži isti podatak. Konačno, zadnja razina klasteriranog indeksa sadrži same podatke.

Napomenimo da ovako klasterirani indeks kreira sustav za upravljanje relacijskom bazom Microsoft SQL Server 2000. Neki drugi sustavi ne poznaju ovaj tip indeksa, te štoviše pod istim nazivom – klasterirani indeks – mogu podrazumijevati potpuno drukčiju strukturu, no smatram da je korisnije pokazati organizaciju indeksa na konkretnom primjeru izabrane baze.

50

Klasterirani indeks: PrezimePosljednja razina ( leaf)

Str Zap Ime Prezime Spol

1

1 Domina Aljinović Z2 Mate Antić M3 Marina Bajramović Z

Srednja razina ( intermediate)Str   Na str

21 Ana Belić Z

15   

Aljinović 1 2 Kristian Brunner MBelić 2 3 Slavko Dešković MDodić 3Kelava 4

3

1 Franka Dodić Z2 Domagoj Horvat M3 Paško Ivanković M4 Ivo Ivić M

Korijen (root)4

1 Damir Kelava MStr   Na str 2 Danijela Klisović Z

14 

Aljinović 15 3 Doris Koštić ZLojpur 16

5

1 Mario Lojpur M2 Ivana Marić Z3 Nikolina Meštović Z4 Hrvoje Orlandini M

Str   Na str

6

1 Jure Padovan M

16   

Lojpur 5 2 Ivan Goran Penić MPadovan 6 3 Ante Perić MPoljak 7 4 Slavica Perović ZZubčić 8

71 Miranda Poljak Z2 Kata Reić Z3 Ivica Tomić M

81 Anica Zubčić Z2 Ivana Zubović Z

Kako se traži prezime «Horvat» ?Polazi se od korjena indeksa i pronalazi da je «Horvat» veće od «Aljinović» i manje od «Lojpur», pa se slijedi zadnji pokazivač od kojeg nije manji ( tj. veće ili jednako), dakle «Aljinović» i odlazi na stranicu 15. Tu se pronalazi da je «Horvat» veće od «Dodić» i manje od «Kelava», pa se slijedi pokazivač od «Dodić» i odlazi na stranicu 3. Zatim se pronalazi «Horvat», prikazuje i nastavlja po zapisima u slijedu i prezime uspoređuje s «Koštić», prikazujući ih, sve dok je prezime manje ili jednako «Koštić». Očito je ubrzanje traženja, jer broj srednjih razina nije velik, čak ni kod velikih tablica.

Pronađimo sada studenta s imenom «Ivo».

51

Indeks: ImeZadnja razina ( leaf)

Str Ime Na str Zap

23     

Ana 2 1Anica 8 1Ante 6 3

Srednja razina(interm)   Damir 4 1Str Ime Na str Danijela 4 2

21   

Ana 23 Domagoj 3 2Doris 24 Domina 1 1       Str   Na str Zap

24     

Doris 4 3Franka 3 1Hrvoje 5 4Ivan Goran 6 2

Korijen(root)   Ivana 5 2Str Ime Na str Ivana 8 2

20 

Ana 21      Ivica 22

Str   Na str Zap

25      

Ivica 7 3Ivo 3 4Jure 6 1Kata 7 2

Str   Na str Kristian 2 2

22   

Ivica 25 Marina 1 3Mate 26 Mario 5 1       Str      

26     

Mate 1 2Miranda 7 1Nikolina 5 3Paško 3 3Slavica 6 4Slavko 2 3

Indeks po koloni Prezime nam ne pomaže u pronalaženju imena. Zato kreirajmo indeks po koloni Ime. Indeks ponovo ima korijen, srednje razine, te posljednju razinu, koja pokazuje na stranicu i zapis na kojoj se nalaze svi podaci studenta kojem je ime «Ivo».

Dakle, «Ivo» je veći od «Ivica», no kako je to posljedni zapis na stranici korjena, slijedi se pokazivač od «Ivica» i odlazi na stranicu 22. srednje razine indeksa. Tu je «Ivo» veći od «Ivica», ali manji od «Mate», pa se odlazi na stranicu 25, gdje se pronalazi «Ivo», jer zadnja razina uvijek sadrži sve zapise indeksiranih kolona cijele tablice i odlazi na stranicu 3, zapis 4, što je kompletan zapis studenta s imenom «Ivo».

Ovakva struktura indeksa se naziva «B-tree»,tj. uravnoteženo stablo (eng. balanced tree). Karakterizira je da uvijek dijeli ciljelu tablicu na približno jednake segmente, a to znači da se nakon svake promjene podataka u tablici, koji obuhvaćaju i indeksne kolone, stablo mora reorganizirati. Naravno, to uzima vrijeme, pa je jasno da indeks ubrzava traženje, ali usporava izmjene: dodavanje, ažuriranje ili brisanje zapisa. Stoga je važno kreirati razuman broj indeksa, prema iskustvima iz prakse 5-7 i njima zadovoljiti često izvođene upite.

52

Potražimo sada sve zapise koji imaju vrijednost kolone Spol = «Z». Sada nam ne pomaže ni jdan ni drugi indeks, pa će se pretraživati cijela tablica.Da li bi nam pomogao neklasterirani indeks po koloni Spol ? Nebi, jer je 50% zapisa s vrijednošću «Z», pa bi pretraživanje stabla indeksa više trajalo, nego potpuno pretraživanje tablice. Ova vrsta indeksa je korisna, ako su podaci dobro distribuirani, dakle ako se ista vrijednost pojavljuje u 5 – 10 % slučajeva ( dakako, točan postotak ovisi o baznom sustavu i konkretnoj tablici).

53

5 SQL Upitni jezik

5.1 Uvod

SQL jezik inovirala je tvrtka IBM, polazeći od osnovnih operacija relacijskih baza podataka, kako ih je definirao Codd . SQL je neproceduralni jezik IV generacije. Pod time se podrazumijeva, da nije potrebno definirati korake ( proceduru) izvođenja, nego se definira «što želimo kao rezultat i način kako će rezulatat biti prikazan». Naredbe jezika dijele se u dvije skupine:

DML Data Manipulation Language

Komande za traženje, umetanje, izmjene i brisanje podataka.

DDL Data Definition Language

Komande za definiciju objekata ( tablica, indeksa, pgleda ) relacijske baze podataka.

5.2 Upiti u relacijskoj bazi podataka

5.2.1 Projekcija i restrikcija

Definirana je relacija ( tablica ) u relacijskoj bazi Studenti, s atributima ( kolonama ):

ImePrezimeDatumRodjenjaStudijIDPostaID

Izlistajmo sadržaj tablice i prikažimo ga na konzoli komandom:

SELECT * FROM Studenti;

Rezulta ovog upita je:

Ime Prezime DatumRodjenja StudijID PostaIDIvo Ivic 22.06.1981 1 21000Ana Matic 01.01.1980 1 22000Tomislav Butorovic 21.01.1982 1 21000Ana Marija Tomic 21.12.1981 1 20000Marko Markovic 24.07.1981 2

54

Helena Topic 05.08.1979 20000Hrvoje Antic 21.03.1981 1 23000Ante Zelic 08.09.1981 1 53000

Dakle, prikazane su sve kolone i svi retci tablice, pri čemu je poredak redaka slučajan, najčešće onim redom kako su retci upisivani u tablicu.

Često nam nisu potrebne sve kolone, pogotovu kod tablica s većim brojem kolona. Kolone koje želimo prikazati pobrojimo poslije ključne riječi SELECT, pa komanda kojom ćemo prikazati samo Ime i Prezime studenta izgleda:

SELECT Ime, Prezime FROM Studenti;

Rezultat izvođenja komande je:

Ime PrezimeIvo IvicAna MaticTomislav ButorovicAna Marija TomicMarko MarkovicHelena TopicHrvoje AnticAnte Zelic

Često želimo prikaz samo nekih redaka tablice i to onih koji zadovoljavaju određeni uvjet. Prikažimo Ime i Prezime studenata koji su upisani na studij «Matematike – Informatike». Pregledom tablice Studiji:

SELECT * FROM Studiji;

StudijID Studij1 Matematika - Informatika2 Tehnicka kultura - Informatika3 Matematika4 Matematika - Fizika5 Biologija - Kemija

nalazimo, da studij Matematike – Informatike ima oznaku StudijID=1. Tako će upit za prikaz imena i prezimena studenata Matematieke – Informatike biti:

SELECT Ime, PrezimeFROM StudentiWHERE StudijID=1

Ime PrezimeIvo IvicAna MaticTomislav Butorovic

Konačno, želimo studente Matematike – Informatike ali po abecednom redu prezimena:

55

SELECT Ime, PrezimeFROM StudentiWHERE StudijID=1ORDER BY Prezime

Ime PrezimeTomislav ButorovicIvo IvicAna Matic

Dakle, SQL – upitna komanda nad jednom tablicom ima opći oblik:

SELECT Kolona1, Kolona2, Kolona... | *FROM Tablica[ WHERE uvjet ][ ORDER BY Kolona2 [DESC], Kolona [DESC]... ]

pri čemu je redoslijed kolona proizvoljan i u SELECT klauzuli i u ORDER BY klauzuli. Želimo li prikazati sve kolone tablice u poretku kako je tablica definirana, možemo upotrijebiti simbol zvjezdice ( * ) koji uključuje sve kolone. Uvjet u WHERE klauzuli mora za svaki redak rezultirati s jednom od dvije moguće vrijednosti: ISTINA ili LAŽ. Prikazani će biti oni retci čija je vrijednost ISTINA. SELECT klauzula provodi relacijsku operaciju projekcije, a WHERE provodi operaciju restrikcije. Kada restrikcija nije potrebna, tj. žele li se prikazati svi reci, onda se WHERE klauzula ispušta ( uglate zagrade u gornjoj definiciji), jednako kao i ORDER BY klauzula, kada poredak nije eksplicitno definiran.

Kako Sustav za upravljanje relacijskom bazom podataka ( RDBMS ) izvodi ovaj upit (tablica nema definiranih indeksa ):

Prevede upit u niz poziva primitivnih procedura Utvrdi optimalan slijed izvođenja Kako nema definiranih indeksa ( ili kada je tablica s malim brojem redaka) izvodi

potpuno skeniranje tablice, dakle kreće od prvog do posljednjeg retka Stvori privremenu radnu tablicu, s kolonama

- Ime varchar(50)- Prezime varchar(50)uzimajući definiciju kolona iz temeljne tablice Studenti

Pročita prvi redak tablice Studenti i ako je vrijednost kolone StudijID=1, upiše vrijednosti Ime i Prezime u radnu tablicu. U slučaju da StudijID nije 1, ide na slijedeći redak.

Poreda retke u radnoj tablici po abecednom redu prezimena Ispiše rezultat u prozoru konzole

56

5.2.2 Prirodno spajanje

Nedostatak gornjih upita je taj, što brojčane oznake StudijID nisu dovoljno opisne, tj. iako vidimo oznaku studija, ne znamo o kojem se studiju radi, naravno, ne želimo li stalno tražiti naziv studija u tablici Studiji. Na sreću, SQL upitni jezik provodi i operaciju prirodnog spajanja dviju ili više tablica:

SELECT Ime, Prezime, Studenti.StudijID, Studiji.*FROM Studenti, StudijiORDER BY Prezime

Ime Prezime StudijID StudijID Studij1 Hrvoje Antic 2 1 Matematika - Informatika2 Hrvoje Antic 2 2 Tehnicka kultura - Informatika3 Hrvoje Antic 2 3 Matematika4 Hrvoje Antic 2 4 Matematika - Fizika5 Hrvoje Antic 2 5 Biologija - Kemija6 Tomislav Butorovic 1 1 Matematika - Informatika7 Tomislav Butorovic 1 2 Tehnicka kultura - Informatika8 Tomislav Butorovic 1 3 Matematika

- - -38 Ante Zelic 3 3 Matematika39 Ante Zelic 3 4 Matematika - Fizika40 Ante Zelic 3 5 Biologija - Kemija

Rezultat ovog upita je relacija, prikazana kao Kartezijev produkt tablica Studenti i Studiji. Dakle, svaki redak tablice Studenti je udružen sa svakim retkom tablice Studiji. Kako Studenti sadrži 8 redaka, a Studiji 5, to rezultantana tablica sadrži 40 redaka. Uočavamo da neki retci ne sadrže istinite podatke: student Hrvoje Antić je upisan na studij 2 – Tehnicka kultura – Informatika ( lijeva kolona StudijID u tablici ), pa povezivanje sa studijima 1, 3, 4 i 5 ne odgovara istini. Zato u pravilu, operaciju prirodnog spajanja ograničavamo na retke koji sadrže istinite podatke, dakle:

SELECT Ime, Prezime, Studenti.StudijID, Studiji.*FROM Studenti, StudijiWHERE Studenti.StudijID=Studiji.StudijIDORDER BY Prezime

Ime Prezime StudijID StudijID StudijHrvoje Antic 2 2 Tehnicka kultura - InformatikaTomislav Butorovic 1 1 Matematika - InformatikaIvo Ivic 1 1 Matematika - InformatikaMarko Markovic 2 2 Tehnicka kultura - InformatikaAna Matic 1 1 Matematika - InformatikaAna Marija Tomic 3 3 MatematikaHelena Topic 2 2 Tehnicka kultura - InformatikaAnte Zelic 3 3 Matematika

Rezultat upita je virtualna tablica, pod čime se misli da ne postoji njen fizički zapis na mediju, npr. disku, nego se dinamički izgrađuje pri izvođenju upita.Uobičajeni naziv za ovakav oblik spajanja tablica je «spajanje jednakosti» ( eng. «equi – join»).

57

5.2.3 Vanjsko ( Outer Join ) spajanje

Izvedimo sličan upit, kojim ćemo prikazati ime, prezime, poštanski broj i naziv pošte studenta:

Ime Prezime PostaID PostaID PostaHrvoje Antic 23000 23000 ZadarTomislav Butorovic 21000 21000 SplitIvo Ivic 21000 21000 SplitAna Matic 22000 22000 SibenikHelena Topic 20000 20000 DubrovnikAnte Zelic 53000 53000 Gospic

Nažalost, umjesto očekivanih 8 redaka, tablica ne sadrži retke:

Ana Marija TomicMarko Markovic

Razlog leži u nedefiniranim poštanskim brojevima ( prigodom prijave, studenti nisu prijavili adresu, jer su bili u fazi preseljenja ). No, mi želimo prikazati sve studente, čak i ako nije definiran poštanski broj. Naravno, ako pošta nije poznata, neće biti ispisana.

SELECT Ime, Prezime, Studenti.PostaID, Poste.*FROM StudentiLEFT OUTER JOIN Poste ON Studenti.PostaID=Poste.PostaIDORDER BY Prezime

Ime Prezime PostaID PostaID PostaHrvoje Antic 23000 23000 ZadarTomislav Butorovic 21000 21000 SplitIvo Ivic 21000 21000 SplitMarko Markovic NULL NULL NULLAna Matic 22000 22000 SibenikAna Marija Tomic NULL NULL NULLHelena Topic 20000 20000 DubrovnikAnte Zelic 53000 53000 Gospic

Engleski termin ovog oblik spajanja je LEFT OUTER JOIN, što možemo prevesti kao «spajanje slijeva», a prikazuje sve retke u tablici s lijeve strane ključne riječi ( Studenti ) . Svaki redak tablice Studenti će pokušati spojiti s tablicom Poste preko identičnih vrijednosti kolona PostaID i prikazati naziv pošte, kad god je spajanje uspješno, odnosno NULL vrijednost kad spajanje nije moguće.

Vrijednost NULL tumačimo kao nedefinirana ili nepoznata vrijednost.

58

Kako Sustav za upravljanje relacijskom bazom podataka ( RDBMS ) izvodi ovaj upit (tablice nemaju definirane indekse ):

Prevede upit u niz poziva primitivnih procedura Utvrdi optimalan slijed izvođenja Kako nema definiranih indeksa ( ili kada je tablica s malim brojem redaka) izvodi

potpuno skeniranje tablice, dakle kreće od prvog do posljednjeg retka tablice Studenti

Stvori privremenu radnu tablicu, s kolonama- Ime varchar(50)- Prezime varchar(50)- PostaID int ( iz tablice Studenti)- PostaID int ( iz tablice Poste)- Posta varchar(50)uzimajući definiciju kolona iz temeljnih tablica Studenti i Poste

Pročita prvi redak tablice Studenti i upiše vrijednosti u radnu tablicu:Ivo Ivic 21000

Pretraži tablicu Poste, počev od prvog retka za vrijednost Poste.PostaID=Studenti.PostaID, odnosno dok ne pronađe PostaID=21000

Upiše u redak radne tablice PostaID ( 21000 ) i Posta ( Split ) Ponovlja postupak čitanja svih redaka Poreda retke u radnoj tablici po abecednom redu prezimena Ispiše rezultat u prozoru konzole

Isto tako, moguće je spojiti tablicu s desna:

SELECT Studiji.*, Ime, PrezimeFROM StudentiRIGHT OUTER JOIN Studiji ON Studenti.StudijID=Studiji.StudijIDORDER BY Studiji.StudijID

StudijID Studij Ime Prezime1 Matematika - Informatika Ivo Ivic1 Matematika - Informatika Ana Matic1 Matematika - Informatika Tomislav Butorovic2 Tehnicka kultura - Informatika Marko Markovic2 Tehnicka kultura - Informatika Helena Topic2 Tehnicka kultura - Informatika Hrvoje Antic3 Matematika Ana Marija Tomic3 Matematika Ante Zelic4 Matematika - Fizika NULL NULL5 Biologija - Kemija NULL NULL

Ovim upitom prikazuju se sve moguće studijske grupe, te studenti onih studijskih grupa koje imaju upisane studente. Studiske grupe bez studenata, isto tako su navedene, ali naravno bez pridruženih studenata.

59

5.2.4 Unutrašnje ( Inner Join ) spajanje

U nekim prilikama, ipak želimo prikaz samo onih redaka koji se mogu spojiti s odgovarajućim recima druge tablice. Recimo, kada trebamo uputiti pisma na adrese studenata, studenti bez adrese trebaju biti ispušteni iz prikaza:

SELECT Ime, Prezime, Studenti.PostaID, PostaFROM StudentiINNER JOIN Poste ON Studenti.PostaID=Poste.PostaIDORDER BY Prezime

Ime Prezime PostaID PostaHrvoje Antic 23000 ZadarTomislav Butorovic 21000 SplitIvo Ivic 21000 SplitAna Matic 22000 SibenikHelena Topic 20000 DubrovnikAnte Zelic 53000 Gospic

Isti rezulata se dobije i primjenom «Equi-join» spajanjem, no ipak «INNER JOIN» zapis potpunog spajanja ima prednost, jer u komandi jasno razlikuje klauzulu restrikcije WHERE od spajanja INNER JOIN.

Dakle, sintaksa potpune upitne komande koja izvršava projekciju, potpuno i nepotpuno spajanje, restrikciju i određivanje poretka je:

SELECT Kolona1, Kolona2, ...FROM Tablica1[ INNER JOIN Tablica2 ON Kolona3=Kolona4 AND Kolona5=Kolona6 ][ LEFT OUTER JOIN Tablica3 ON Kolona7=Kolona8 AND ... ][ WHERE uvjet ][ ORDER BY Kolona1 [ ASC | DESC ], Kolona2 [ ASC | DESC ], ... ]

5.2.5 Funkcije u SQL Upitu

Često trebamo neke izračunate podatke, čija se vrijednost temelji na baznim podacima, upisanim u tablici.

Prikažimo ime i prezime studenata u jednoj koloni, spajanjem kolona ime i prezime, te ukupni broj slova imena i prezimena ( razmak nije uključen). Retke je potrebno poredati po dužini teksta, tako da student s najdužim imenom i prezimenom bude na vrhu poretka:

SELECT Prezime + ' ' + Ime, LEN(Prezime + Ime)FROM StudentiORDER BY LEN(Prezime + Ime) DESC

60

Ime Prezime Dužina Ime i PrezimeButorovic Tomislav 17Tomic Ana Marija 15Markovic Marko 13Topic Helena 11Antic Hrvoje 11Zelic Ante 9Matic Ana 8Ivic Ivo 7

Ključna riječ DESC ( DESCEDING ) označava inverzni poredak prikazane tablice. Predefiniran je poredak od manje vrijednosti prema većoj ASC ( ASCEDING ) i nije ga potrebno navoditi.

Neke često korištene funkcije:

Sintaksa OpisLEFT( Tekstualni izraz, n ) Izdvaja n pozicija s lijeva iz tekstualnog izraza

( obično tekstualna kolona tablice)RIGHT( Tekstualni izraz, n)

Izdvaja n pozicija s desna iz tekstualnog izraza ( obično tekstualna kolona tablice)

SUBSTRING( Tekstualni izraz, S, D)

Izdvaja D znakova iz tekstualnog izraza, počev od pozicije S izraza

LEN( Tekstualni izraz ) Daje dužinu ( broj slova ) tekstualnog izraza

Primjeri:

a) Prikazati početno slovo imena ( inicijal ) i prezime u jednoj koloni.

SELECT LEFT(Ime, 1) + '. ' + Prezime FROM Studenti

Inicijal PrezimeI. IvicA. MaticT. ButorovicA. TomicM. MarkovicH. TopicH. AnticA. Zelic

b) Prikazati dva posljednja slova prezimena studenta

SELECT RIGHT(Prezime, 2), Prezime FROM Studenti

2 zadnja slova Prezime

61

prezimenaic Ivicic Maticic Butorovicic Tomicic Markovicic Topicic Anticic Zelic

c) Prikazati 3 slova imena studenta, počev od 3. slova

SELECT SUBSTRING(Ime, 3, 3 ), ImeFROM Studenti

3 slova počev od 3. Pozicije Imeo Ivoa Anamis Tomislava M Ana Marijarko Markolen Helenavoj Hrvojete Ante

d) Prikazati sve studente čije je ime=Ivo'

SELECT *FROM StudentiWHERE Ime='Ivo'

Ime Prezime DatumRodjenja StudijID PostaIDIvo Ivic 22.06.1981 1 21000

e) Prikazati sve studente čije ime sadrži slovo i na bilo kojoj poziciji.

SELECT *FROM StudentiWHERE Ime LIKE '%i%'

Ime Prezime DatumRodjenja StudijID PostaIDIvo Ivic 22.06.1981 1 21000Tomislav Butorovic 21.01.1982 1 21000Ana Marija Tomic 21.12.1981 3 NULL

f) Prikazati sve studente kojima naziv pošte sadrži slovi i na bilo kojoj poziciji.

SELECT Ime, Prezime, Studenti.PostaID, PostaFROM Studenti

62

LEFT OUTER JOIN Poste ON Studenti.PostaID=Poste.PostaIDWHERE Posta LIKE '%i%'

Ime Prezime PostaID PostaIvo Ivic 21000 SplitAna Matic 22000 SibenikTomislav Butorovic 21000 SplitHelena Topic 20000 DubrovnikAnte Zelic 53000 Gospic

g) Prikazati sve studente kojima naziv pošte sadrži slovi i na bilo kojoj poziciji.

SELECT Ime, Prezime, Studenti.PostaID, PostaFROM StudentiLEFT OUTER JOIN Poste ON Studenti.PostaID=Poste.PostaIDWHERE Posta NOT LIKE '%i%'

Ime Prezime PostaID PostaHrvoje Antic 23000 Zadar

h) Prikazati ime, prezime i dužinu imena svim studentima, čije je ime duže od 5 slova. Poredati po dužini imena.

SELECT Ime, Prezime, LEN(Ime)FROM StudentiWHERE LEN(Ime) > 5ORDER BY LEN(Ime)

Ime PrezimeDuzina Imena

Helena Topic 6Hrvoje Antic 6Tomislav Butorovic 8Ana Marija Tomic 10

g) Prikazati ime i prezime studenta u jednoj koloni, te svaku pojavu malog slova a, zamijeniti velikim slovom A.

SELECT REPLACE(Ime + ' ' + Prezime, 'a', 'A')FROM Studenti

Ime PrezimeIvo IvicAnA MAticTomislAv ButorovicAnA MArijA TomicMArko MArkovicHelenA TopicHrvoje AnticAnte Zelic

63

5.2.6 Grupiranje podataka i sumarna izračunavanja

a) Zanima li nas koliko imamo ukupno studenata u tablici Studenti, izvest ćemo upit:

SELECT count(*)FROM Studenti

(No column name)8

Dakle, count(*), pri čemu * da nas zanima broj redaka, bez obzira na definiranu vrijednost kolona, će izbrojati ukupni broj redaka tablice.

Umetnemo li redak koji sadrži isključivo nedefinirane vrijednosti ( što je u suprotnosti s pravilima relacijskih baza ), broj redaka bit će 9.

b) Ispišimo sada ukupni broj studenta, te broj studenata koji imaju definiranu adresu (PostaID):

SELECT count(*) As BrojStudenata, count(PostaID) As ImaDefiniranuAdresuFROM Studenti

BrojStudenata ImaDefiniranuPostu8 6

c) Ispišimo broj studenata na svakoj studijskoj grupi. Grupe na kojima nema upisanih studenata nije potrebno prikazati, te poredati prema broju studenata na grupi, počev od najbrojnije grupe:

SELECT StudijID, count(*)FROM StudentiGROUP BY StudijIDORDER BY count(*) DESC

StudijID count(*)1 32 33 2

Kako programski sustav za upravljanje relacijskom bazom podataka( RDBMS) izvodi ovaj upit ( Pretpostavka je da tablica nije indeksirana):

RDBMS prevede definiranu komandu SQL upita u niz poziva primitivnih procedure

Izračuna optimalan redoslijed izvođenja primitiva

64

U bazi za privremene – radne tablice stvori tablicu čije su kolone:StudijID smallint ( Uzima definiciju kolone iz polazne tablice )Count1 int

Krene od prvog retka tablice Studenti i upiše vrijednost StudijID ( 1 ) u radnu tablicu, te brojačkoj koloni Count dodijeli vrijednost 1.

Prelazi na slijedeći redak i ponovno pronalazi StudijID=1. Kako oznaka studija postoji u radnoj tablici, uveča brojač pojava Count za 1, te on sada iznosi 2.

Prelazi na slijedeći redak i pronalazi StudijID=2, te stvori novi redak s brojačem na inicijalnoj vrijednosti 1.

Ove korake ponavlja sve do posljednjeg redka tablice, te svaki put kada naiđe na veijednost StudijID, koja ne postoji u tablici, stvori redak. Ako oznaka studija postoji u radnoj tablici, uvečava joj brojač za 1.

Sortira retke radne tablice od najveće do najmanje vrijednosti brojačke kolone.

d) Gore dobiveni rezultat je ispravan, ali nije razumljiv, jer oznake studija nisu deskriptivne. Zato bismo radije čitali rezultat uz puni naziv studijske grupe, pa zato moramo spojiti tablicu Studiji, gdje se opisi nalaze:

SELECT Studij, count(*) As BrojStudenataFROM Studenti SINNER JOIN Studiji ST ON S.StudijID=ST.StudijIDGROUP BY StudijORDER BY count(*) DESC

Studij BrojStudenataMatematika - Informatika 3Tehnicka kultura - Informatika 3Matematika 2

e) Zahtijeva li se prikaz samo onih studijskih grupa, na kojima je opisano više od 2 studenta, upit će biti:

SELECT Studij, count(*) As BrojStudenataFROM Studenti SINNER JOIN Studiji ST ON S.StudijID=ST.StudijIDGROUP BY StudijHAVING count(*) > 2ORDER BY count(*) DESC

Studij BrojStudenataMatematika - Informatika 3Tehnicka kultura - Informatika 3

Dakle, uvjet koji se odnosi na sumarne podatke definira se u klauzuli HAVING.

f) Želimo li pak, ispisati sve studijske grupe, te ukupan broj studenata upisan na svaku studijsku grupu, uključujući i grupe na kojima nema upisanih studenata, upit će biti:

SELECT Studij, count(Ime)

65

FROM Studiji STLEFT OUTER JOIN Studenti S ON S.StudijID=ST.StudijIDGROUP BY StudijORDER BY Studij DESC

Studij BrojStudenataBiologija - Kemija 0Matematika 2Matematika - Fizika 0Matematika - Informatika 3Tehnicka kultura - Informatika 3

Uočimo, da count(Ime) osigurava da BrojStudenata bude 0, kada na Studiju nema upisanih studenata, dok bi count(*) dao ispravan broj u slučaju da je barem jedan student upisan na Studijsku grupu, ali bi isto tako dao vrijednost jedan i kad na grupu nije upisan niti jedan student. U pravilu ćemo uvijek kada se tablice spajaju s OUTER JOIN, upotrijebiti count( Kolona ).

g) Ispis studenata i njihovih prosječnih ocjena, dobit ćemo upitom:

SELECT Ime, Prezime, AVG(Ocjena*1.0)FROM Studenti SLEFT OUTER JOIN StudentiOcjene SO ON S.StudentID=SO.StudentIDGROUP BY Ime, PrezimeORDER BY Prezime

Ime Prezime (no column name)Hrvoje Antic 2.7500Tomislav Butorovic 4.0000Ivo Ivic 4.0000Marko Markovic 2.7500Ana Matic 3.0000Ana Marija Tomic 3.0000Helena Topic 4.0000Ante Zelic 3.7500

h) Isto tako, možemo ispisati sve studente, čija je prosječna ocjena veća ili jednaka 3.5:

SELECT Ime, Prezime, AVG(Ocjena*1.0) As ProsječnaOcjenaFROM Studenti SLEFT OUTER JOIN StudentiOcjene SO ON S.StudentID=SO.StudentIDGROUP BY Ime, PrezimeHAVING AVG(Ocjena*1.0) >= 3.5ORDER BY Prezime

Ime Prezime ProsječnaOcjenaTomislav Butorovic 4.0000Ivo Ivic 4.0000Helena Topic 4.0000Ante Zelic 3.7500

66

i) Konačno, ispišimo sve studente s adresom 21000 ( Split ) koji imaju prosječnu ocjenu 3.5 ili veću, te ukupan zbroj ocjena i prosječnu ocjenu svakog studenta, a rezltate poredajmo po abecednom redu prezimena:

SELECT Ime, Prezime, PostaID, SUM(Ocjena) As ZbrojOcjena, AVG(Ocjena*1.0) As ProsječnaOcjenaFROM Studenti SLEFT OUTER JOIN StudentiOcjene SO ON S.StudentID=SO.StudentIDWHERE PostaID=21000GROUP BY Ime, Prezime, PostaIDHAVING AVG(Ocjena*1.0) >= 3.5ORDER BY Prezime

Ime Prezime PostaID 5.2.7 ZbrojOcjenaProsječnaOcjenaTomislav Butorovic 21000 16 4.0000Ivo Ivic 21000 16 4.0000

Uočimo da kod upita grupiranja, projekcija( klauzula SELECT ) sadrži kolone iz temeljnih tablica, kao Ime, Prezime i PostaID, te funkcije grupiranja,count(), SUM, AVG. Operacija grupiranja ( klauzula GROUP BY ) mora sadržavati sve kolone po kojima se grupiranje obavlja, dakle, Ime, Prezime i PostaID. Isto tako, rezultat grupiranja može se sortirati samo po kolonama koje su navedene SELECT klauzuli, jer one jedino i postoje u radnoj tablici, koja se naknadno sortira.

5.2.8 Logički složeni uvjeti

a) Ispišimo sve studente Studijske čije ime ili prezime započinje slovom a :

SELECT Ime, PrezimeFROM StudentiWHERE Ime LIKE 'a%' OR Prezime LIKE 'a%'

Ime PrezimeAna MaticAna Marija TomicHrvoje AnticAnte Zelic

Uvjet će biti zadovoljen ako Ime ili prezime započinje slovom A, pa su ova dva uvjeta povezana logičkim operatorom OR.

b) Ispišimo sve studente kojima Ime započinje slovom A a prezime slovom Z:

SELECT Ime, PrezimeFROM Studenti

67

WHERE Ime LIKE 'a%' AND Prezime LIKE 'z%'

Ime PrezimeAnte Zelic

Uvjet je zadovoljen samo u slučaju kada ime započinje slovom A, a prezime slovom Z, pa su ova dva uvjeta vezana logičkim operatorom AND.

c) Prikažimo studente, čije ime NE započinje slovomA i prezime započinje slovom A:

SELECT Ime, PrezimeFROM StudentiWHERE Ime NOT LIKE 'A%' AND Prezime LIKE 'A%'

Ime PrezimeHrvoje Antic

Bilo koji od logičkih izraza može biti negiran, odnosno, rezultirat će istinom kada ne-negirani uvjet daje laž.

d) Potrebno je izlistati sve studente, kojima ima ili prezime započinje slovom A, a da im je PostaID=22000:

SELECT Ime, Prezime, PostaIDFROM StudentiWHERE Ime LIKE 'A%' OR Prezime LIKE 'A%' AND PostaID=22000

Ime Prezime PostaIDAna Matic 22000Ana Marija Tomic NULLAnte Zelic 53000

Gornji upit nije dao očekivani rezultat, jer vidimo da samo jedan od tri studenta prebiva na PostaID=22000. Problem je uzrokovan logičkim povezivanjem elementarnih uvjeta. Naime, kao što kod računskih operacija množenje ima veći prioritet od zbrajanja, tako logički operator AND ima veći prioritet od OR operatora.Zato gornji uvjet zadovoljava svaki redak, čim ime započinje slovo A.

Redoslijed razvijanja pojedinih elementarnih uvjeta možemo odrediti upotrebo zagrada, pa je ispraljeni upit :

SELECT Ime, Prezime, PostaIDFROM StudentiWHERE ( Ime LIKE 'A%' OR Prezime LIKE 'A%' ) AND PostaID=22000

Ime Prezime PostaIDAna Matic 22000

Uočavamo da se najprije izračunava vrijednost logičkog izraza u zagradama.

68

5.2.9 Pobrojane vrijednosti

Ispišimo sve studente upisane na StudijID 1, 3 ili 5 :

SELECT Ime, Prezime, StudijID, PostaIDFROM StudentiWHERE StudijID IN ( 1, 3, 5 )

Ime Prezime StudijID PostaIDIvo Ivic 1 21000Ana Matic 1 22000Tomislav Butorovic 1 21000Ana Marija Tomic 3 NULLAnte Zelic 3 53000

Isti upit moguće je napisati ina ovaj način:

SELECT Ime, Prezime, StudijID, PostaIDFROM StudentiWHERE StudijID=1 OR StudijID=3 OR StudijID=5

Da se izbjegne ponavljanje imena kolone StudijID, prvi oblik upita, kod kojeg se nabroji lista traženih vrijednosti, je mnogo prikladniji i razumljiviji, te se redovito koristi. RDBMS izvodi oba upita na isti način.

5.2.10 Ugniježđeni upiti

a) Prikažimo sve studente koji studiraju na istoj studijskog grupi kao student čije je prezime Ivić.Ovaj zadatak bismo mogli odraditi pomoću dva uipta:

Upit 1: SELECT StudijIDFROM StudentiWHERE Prezime='Ivic'

Zatim očitamo vrijednost StudijID i izvedemo

Upit 2:SELECT Ime, Prezime, StudijIDFROM StudentiWHERE StudijID=1

Oba upita moguće je definirati kao jedinstveni, ugniježđeni upit:

69

SELECT Ime, Prezime, StudijIDFROM StudentiWHERE StudijID IN (SELECT StudijIDFROM StudentiWHERE Prezime='Ivic')

Ime Prezime StudijIDIvo Ivic 1Ana Matic 1Tomislav Butorovic 1

Dakle, umjesto da pobrojimo konstantne vrijednosti, možemo definirati upit koji vraća listu pobrojanih vrijednosti. Najprije se izvodi upit u zagradama, dakle ugniježđeni, a zatim vanjski. Može se ugnijezditi veći broj upita.

b ) Komplementarno gornjem upitu, možemo ispisati sve studente koji nisu upisani na isti studij kao student Ivić:

SELECT Ime, Prezime, StudijIDFROM StudentiWHERE StudijID NOT IN (SELECT StudijIDFROM StudentiWHERE Prezime='Ivic')

Ime Prezime StudijIDAna Marija Tomic 3Marko Markovic 2Helena Topic 2Hrvoje Antic 2Ante Zelic 3

Uočimo, upotrebu ključne riječi NOT, kojom se označava da uvjet zadovoljavaju svi studenti, čija je vrijednost StudijID različita od 1, tj. nemaju StudijID isti kao student Ivić.

Često se ugnježđuju upiti grupiranja, kao u primjeru:

c) Ispišimo sve studente, koji studiraju na studijskim grupama, na kojima je upisano više od 2 studenta.

SELECT Ime, Prezime, StudijIDFROM StudentiWHERE StudijID IN (SELECT StudijIDFROM StudentiGROUP BY StudijIDHAVING count(*) > 2)

Ime Prezime StudijIDIvo Ivic 1Ana Matic 1

70

Tomislav Butorovic 1Marko Markovic 2Helena Topic 2Hrvoje Antic 2

2.9 Jedinstvene vrijednosti redaka

a) Želimo znati početna slova ( inicijale ) imena studenata:

SELECT LEFT(Ime, 1)FROM StudentiORDER BY 1

InicijalAAAHHIMT

U slučaju velikog broja redaka u tablici, ovakav prikaz bi bio potpuno nepregledan, pa želimo vidjeti samo jedinstvene pojave svakog slova, jer nas saznanje da imamo jednog ili više studenata čije ime započinje s A zadovoljava:

SELECT DISTINCT LEFT(Ime, 1)FROM StudentiORDER BY 1

InicijalAHIMT

Ključna riječ DISTINCT označava da se retci s istom vrijednošću svih kolona, prokažu samo jednom.

Kako RDBMS izvodi ovaj upit:

Stvori privremenu radnu tablicu s kolonama kako je navedeno u SELECT klauzuli, dakle u našem primjeru, s jednom kolonom.

Izvodi upit pretražujući tablicu, provjeravajući zadovoljenje uvjeta ako postoji, poziva funkciju LEFT, koja vraća prvo slovo imena.

Upisuje vrijednosti projeciranih kolona onih redaka koji zadovoljavaju uvjet u radnu tablicu

Sortira retke u radnoj tablici po svim kolonama

71

Pretraži radnu tablicu ispisujući svaki put samo prvu pojavu retka, preskačući retke koji imaju iste vrijednosti u svim kolonama, kao već ispisani redak.

2.10 Null vrijednost

Pri upisu retka u tablicu, vrijednosti nekih kolona mogu biti nepoznate, te ih moramo ostaviti nedefiniranim. Naravno, neke kolone moraju imati obavezno unijete vrijednosti, pa se pri kreiranju tablice zahtijeva obavezan unos vrijednosti. U našem primjeru tablice Studenti, ime, prezime i studijska grupa moraju biti unijete, a PostaID, te datum rođenja mogu ostati nedefinirane. Nedefinirana vrijednost naziva se Null vrijednost.

a) Ispišimo sve studente koji imaju PostaID = Null :

SELECT Ime, Prezime, StudijID, PostaIDFROM StudentiWHERE PostaID IS Null

Ime Prezime StudijID PostaIDAna Marija Tomic 3 NULLMarko Markovic 2 NULL

Uočimo da se Null vrijednost testira ključnom rječju IS Null i da test = Null, gdje je znak jednakosti zamijenio ključnu riječ IS, ne mora dati očekivani rezultat. Naime, o postavkama baze podataka ovisi rezultat test = Null, no to prelazi okvire ovih skripta.

b) Prikažimo sve studente koji imaju definiranu vrijednost PostaID, dakle PostaID IS NOT Null :

SELECT Ime, Prezime, StudijID, PostaIDFROM StudentiWHERE PostaID IS NOT Null

Ime Prezime StudijID PostaIDIvo Ivic 1 21000Ana Matic 1 22000Tomislav Butorovic 1 21000Helena Topic 2 20000Hrvoje Antic 2 23000Ante Zelic 3 53000

72

5.3 SQL comande za definiciju objekata relacijske baze podataka

U prethodnom poglavlju smo izvodili upite nad već definiranim tablicama u koje su prethodno unijeti podaci. U ovom poglavlju ćemo definirati i izvoditi komande kojima se stvaraju, mijenjaju i uništavaju objekti relacijske baze. Različiti sustavi za upravljanje relacijskim bazama ( RDBMS ) pružaju mogućnost definiranja nekih specifičnih objekata, no svi sigurno podržavaju mogućnost kreiranja, mijenjanja i uništavanja tablica, pogleda ( views) i indeksa.

Isto tako, valja napomenuti da je mnogo prokladniji način stvaranja objekata korištenjem grafičkog korisničkog sučelja. Lakše je klikom miša odabrati željenu akciju ili tip podatka, nego pamtiti sintaksu komandi, te ćemo najvjerojatnije objekte baze kreirati koristeći grafički interfejs i pokazivačku jedinicu ( miš ) na razvojnom računalu. U fazi implementacije baze na ciljnom računalu ili većem broju ciljnih računala, bilo bi veoma neprikladno ponavljati niz već odrađenih «klikova». Srećom, danas korišteni sustavi relacijskih baza mogu generirati komande za stvaranje bazbih objekata. Mi moramo komande razumjeti i biti u stanju zadati ih ručno.U ovo poglavlju ćemo se upoznati samo s komandama u tekstualnom obliku.

5.3.1 Stvaranje, promjena i uništavanje tablice

Tablica sadrži kolone i retke. Kolone se moraju definirati prigodom stvaranja tablice, a retci se stvaraju unosom vrijednosti u tablicu. Tablica predstavlja fizičku implementaciju entiteta, a kolone atributa. Tablica je određena korisničkim imenom kreatora i imenom tablice. Isti korisnik mora svakoj tablici odabrati jedinstveno ime. Različiti korisnici mogu koristiti ista imena za svoje tablice. Kako jedan sustav za upravljanje relacijskim bazama može u isto vrijeme upravljati s više baza na istom stroju, kažimo da je tablica određena preko tri komponente:

Baza.Korisnik.Tablica

Jasno je, da u slučajevima kada se radna baza i korisnik podrazumijevaju, nije potrebnonavoditi bazu i korisnika.

5.3.1.1 Stvaranje tablice Studenti

Entitet Studenti opisan je atributima:

Atributi OpisIme Slobodno unijeti tekst, maksimalne dužine 30 znakova,

obavezan unosPrezime Slobodno unijeti tekst, maksimalne dužine 30 znakova,

obavezan unosDatumRodjenja Datum, unos nije obavezanStudijID Cio broj, s vrijednostima od 1 do 255, obavezan unos. Opis

73

brojčane oznake pogledati u tablici StudijiPostaID Cio broj, s vrijednostima od 10000 ( Zagreb) do 99999, unos

nije obavezan. Opis brojčanih vrijednosti pogledati u tablici Poste

Kod kreiranja tablice je veoma važno odabrati odgovarajući tip podatka svake kolone.Na taj način onemogućavamo unos nesuvislih ili nemogućih podataka, barem u onoj mjeri koliko je to moguće. Pojasnimo primjerom: ako bi kolona DatumRodjenja bila tekstualnog tipa, onda bi bo moguć unos datuma 30.02.2002, no znamo da veljača ne može imati 30 dana. Zato je važno da kolona DatumRodjenja bude datumskog tipa, pri čemu baza neće dopustiti unos nemogućeg datuma. Dakle, pravilnim izborom tipa podatka kolone sprečavamo nemoguće unose, no neispravni unosi još su uvijek moguću: npr. osobi rođenoj 2. siječnja 1980, još je uvijk moguće nepažnjom unijeti datum rođenja 1. veljače 1980.

Dakle, tablica Studenti imat će kolone:

Kolona Tip podatka Null vrijednost Opis tipa podatkaIme varchar(30) NOT Null tekstualni,

maksimalna dužina 30 znakova. Unosi «troše» onoliko byte-ova koliko je znakova unijeto, uz dodatk 2 byte za dužinu unijetog podatka

Prezime varchar(30) NOT Null tekstualni, maksimalna dužina 30 znakova

DatumRodjenja datetime Null Datumski podatak, 8 byte-ova ( ovisno RDBMS)

StudijID tinyint NOT Null brojčani podataka između 0 i 255, 1 byte

PostaID int Null brojčani podatak, 4 byte

Opisanu tablicu kreirajmo komandom:

CREATE TABLE Studenti (Ime varchar(30) NOT Null,Prezime varchar(30) NOT Null,DatumRodjenja datetimeNull,StudijID tinyint NOT Null

)

74

Tablicu Studenti, stvorenu gornjom komandom mogli smo kreirati i preko grafičkog korisničkog sučelja.

Kreiranje tablice preko GUI

5.3.1.2 Uništavanje tablice

Tablicu koju više ne trebamo možemo uništiti, komandom:

DROP TABLE Studenti

Želimo li ponovno stvoriti tablicu s istim imenom, postojeću moramo najprije uništiti, jer nisu moguće dvije tablice s istim imenom.

5.3.1.3 Izmjena strukture tablice

Pri kreiranju tablice Studenti, propustili smo kreirati kolonu PostaID. Vrlo je čest slučaj da se tijekom eksploatacije baze podataka moraju dodati neke kolone, kao posljedica naknadog proširenja zahtjeva. Uništavanje, radi ponovnog kreiranja tablice nije moguće jer su podaci već upisani, a to bi značilo njihov gubitak. Dapače, tablicu će koristiti postojeća aplikacija, pa ona ne smije biti nedostupna. Zato su nam na raspolaganju komande za dodavanje novih kolona, te za promjenu postojećih. Iz praktičnih razloga, nastojimo nikada ne uništiti postojeće kolone, jer neki segment aplikacije koji se poziva na stara imena kolona, neće raditi. Kolone možemo dodavati bez bojazni po greške postojećih aplikacija, naravno ako se pridržavamo i nekih drugih «praktičnih pravila» o kojima će biti riječi u slijedećem poglavlju.

Dodajmo kolonu PostaID int Null :

ALTER TABLE Studenti ADD PostaID int Null

Kolonu nije moguće dodadi uz zabranu Null vrijednosti ( NOT NULL ), ako nije definirana predefinirana ( default) vrijednost.

Navedimo i komandu za uništavanje kolone, iako je dobro izbjegavati takvu praksu, iz ranije opisanih razloga:

ALTER TABLE Studenti DROP COLUMN PostaID

Promijenimo tip podatka kolone StudijID iz tinyint u smallint ( 2 byte ).

ALTER TABLE Studenti2 ALTER COLUMN StudijID smallint

75

Pri izmjenama tipa podataka iz tipa većeg opseg vrijednosti u manji opseg, moramo osigurati da već upisane vrijednosti ne prelaze novi, manji opseg.Mijenjamo li maksimalno dopušteni broj znakova u kolonama varijabilne širine, može doći do gubitka dijela unosa koji ne stane u novu, manju dimenziju. Neke RDBMS će prijaviti grešku:

Server: Msg 8152, Level 16, State 9, Line 1String or binary data would be truncated.The statement has been terminated.

5.3.2 Stvaranje i uništavanje pogleda – view-a

U praksi ćemo vrlo često trebati ispise iz tablice Studenti povezane s tablicama Studiji i Poste, jer nas u pravilu zanima naziv studija i pošte. Da bi olakšali pretraživanje i izbjegli složenost često korištenih upita, stvorit ćemo pogled ( view) Vstudenti, koji će povezivati potrebne tablice. Isto tako, javlja se potreba da neke kolone ne budu dostupne stanovitoj grupi korisnika, dok ih neka druga skupina može čitati. U našem primjeru, zadržat ćemo kolonu DatumRodjenja skrivenom u pogledu Vstudenti.

CREATE VIEW VStudentiAS(

SELECT Ime, Prezime, Studij, S.PostaID, PostaFROM Studenti SINNER JOIN Studiji ST ON S.StudijID=ST.StudijIDLEFT OUTER JOIN Poste P ON S.PostaID=P.PostaID

)

Sada je ispis imena, prezimena, naziva studija, poštanskog broja i naziva pošte, krajnje jednostavan:

SELECT *FROM Vstudenti

Ime Prezime Studij PostaID PostaIvo Ivic Matematika - Informatika 21000 SplitAna Matic Matematika - Informatika 22000 SibenikTomislav Butorovic Matematika - Informatika 21000 SplitAna Marija Tomic Matematika NULL NULLMarko Markovic Tehnicka kultura - Informatika NULL NULLHelena Topic Tehnicka kultura - Informatika 20000 DubrovnikHrvoje Antic Tehnicka kultura - Informatika 23000 ZadarAnte Zelic Matematika 53000 Gospic

RDBMS pogled tretira kao virtualnu tablicu, dakle ne čita je s medija ( diska ) nego dinamički izgrađuje za vrijeme izvođenja upita, baš kao da smo zadali upit:

SELECT Ime, Prezime, Studij, S.PostaID, Posta

76

FROM Studenti SINNER JOIN Studiji ST ON S.StudijID=ST.StudijIDLEFT OUTER JOIN Poste P ON S.PostaID=P.PostaID

To znači da možemo primijeniti restrikciju i sortiranje:

SELECT *FROM VStudentiWHERE Studij LIKE '%Informatika%'ORDER BY Studij, Prezime

Ime Prezime Studij PostaID PostaTomislav Butorovic Matematika - Informatika 21000 SplitIvo Ivic Matematika - Informatika 21000 SplitAna Matic Matematika - Informatika 22000 SibenikHrvoje Antic Tehnicka kultura - Informatika 23000 ZadarMarko Markovic Tehnicka kultura - Informatika NULL NULLHelena Topic Tehnicka kultura - Informatika 20000 Dubrovnik

Zgodno je ovdje napomenuti, da suvremni sustavi za upravljanje relacijskim bazama omogućavaju stvaranje materijaliziranih pogleda. Naime, relacijska baza mora biti najmanje u 3. normalnoj formi, a to znači da svaka relacija ( tablica ) mora biti najmanje u toj ili višoj normalnoj formi. Kod ispisa podataka često moramo spajati veći broj tablica, što značajno ugrožava odzivna vremena, jer je operacija spajanja u pravilu vremenski zahtjevna, naročito pri spajanju relacija s velikim brojem unosa (redaka). Stoga se u praksi, nakon normaliziranja baze, često pristupa denormalizaciji. U tom postupku materijalizirani pogledi igraju značajnu ulogu, jer oni predstavljaju fizičku kopiju spojenih tablica, pri čemu RDBMS sam održava redudantne podatke. Korisnici baze vide relacije ( tablice) normalizirane, bez odstupanja od teoretskih postavki, a materijalizirani pogledi osiguravaju iznimno brze upite.

5.3.2.1 Uništavanje pogleda

Pogled koji više ne trebamo, ili ga želimo ponovno kreirati, možemo uništiti komandom:

DROP VIEW Vstudenti

Jasno je da uništavanje pogleda nema nikakvog utjecaja na bazne tablice i podatke.

5.3.3 Stvaranje indeksa

Cilj ovog poglavlja su naredbe SQL jezika za stvaranje objekata relacijske baze, pa tako i indeksa. Analizom upita, planiranjem indeksa, te ostalih potankosti vezanih uz indekse se bavimo u posebnom poglavlju, a ovdje samo kratko pojasnimo pojam i značaj indeksa.

77

Pretpostavimo da želimo pronaći u telefonskom imeniku splitskog područja sve osobe čije je prezime Ivić. Zadatak ćemo brzo obaviti, jer je imenik poredan po abecednom redu prezimena pretplatnika. No, ako bi zadatak bio pronaći sve osobe koje žive u Teslinoj ulici, potrošili bi mnogo više vremena. Jednostavno, morali bi krenuti od prvog pretplatnika, na prvoj stranici imenika, te svakom pretplatniku pregledati ulicu. Postupak provjere ulice bi provodili jednom po jednom, svim pretplatnicima, sve do posljednjeg na zadnjoj stranici imenika. Razlog za potpuno čitanje imenika leži u činjenici da je imenik sortiran po abecedi prezimena, ali ne i po ulicama. Dakle, imenik je indeksiran po prezimenu. Kada bi željeli isti imenik sortiran i po ulicama, to bi radi uštede papira mogli napraviti na ovaj način: dodati stranice s abecednim popisom ulica, te kod svake ulice nabrojati sve stranice i retke u kojima ćemo pronaći pretplatnike s adresom u Teslinoj ulici. To bi vjerojatno značilo, da bi brzo pronašli Teslinu ulicu i onda bismo za svakog pretplatnika morali pronaći stranicu, te ponovno za slijedećeg pretplatnika skoknuti na stranicu indeksa ulica, pročitati na kojoj se stranici nalazi slijedeći pretplatnik i tako redom.Dakle, indeksiranjem se značajno ubrzava pretraživanje.

Shvatimo naredbu za kreiranje indeksa kao sortiranje podataka u određenom poretku ( slučaj abecednog poretka po prezimenima ), odnosno, kao dodavanje stranica s abecednim poretkom ulica i pokazivačima stranica i redaka na kojima su pretplatnici date ulice.

Naravno, mi želimo indeksirati tablicu studenti, po prezimenu, kako bismo u tablici s mnogo redaka brzo pronašli traženo prezime ( naredbom je stvoren indeks koji odgovara indeksiranju ulica u gornjem tekstu).

CREATE INDEX Prezime_X ON Studenti(Prezime)

Postupak stvaranja indeksa u velikim tablicama, s nekoliko stotina tisuća i miliona redaka, može potrajati nekoliko minuta.

5.3.4 Uništavanje indeksa

Shvatimo komandu kao «trganje» iz telefonskog imenika dodanih stranica sa sortiranim ulicama. Srećom, stranice medija za pohranu podataka se proglašavaju slobodnima i bit će ponovno upotrebljene, dok recikliranje starog papira ipak ne ide tako glatko.

DROP INDEX Studenti.Prezime_X

Uočimo, da se indeks određuje imenom tablice i imenom indeksa, no to se može razlikovati od jednog do drugog sustava relacijskih baza.

Podrobnije o indeksima govori se u drugim poglavljima ovih skripta.

Opće pravilo stvaranja i uništavanja objekata baze podataka

78

- stvaranjeCREATE TipObjekta NazivObjekta (

Definicija objekta)

uništavanje

DROP TipObjekta NazivObjekta

5.4 Naredbe za upisivanje, promjenu i brisanje podataka

Cjeloviti informacijski sustav izgrađuje niz ekranskih formi – prozora preko kojih upisujemno, mijenjamo ili brišemo podatke u tablicama relacijske baze, služeći se programskim objektima za spajanje na bazu i rad sa skupovima podataka. No, pored toga, u svim fazama života baze podataka, postavlaju se nepredviđeni upiti, a isto tako se obavljaju ad hock izmjene podataka, pa stoga treba obratiti potrebnu pažnju i steći potrebnu sigurnost i samopouzdanje u korištenju naredbi za manipulaciju podacima.

5.4.1 Upisivanje ( insertiranje ) retka

Upišimo novog studenta u tablicu Studenti, čije je ime Marko, prezime Marić, rođen je 07.08.1980. i upisan je na studijsku grupu 1. Poštanski broj njegove adrese za sada nije poznat.

INSERT INTO Studenti( Prezime, Ime, StudijID, DatumRodjenja)VALUES( 'Martić', 'Marko', 1, '1980/08/07' )

Primjetimo da nakon ključne riječi INSERT INTO slijedi ime tablice, te lista kolona u koje će biti upisani podaci, dok ključnu riječ VALUES slijedi lista vrijednosti. Lista kolona i lista vrijednosti moraju se podudarati po broju i tipu podataka. Sustav će javiti grešku ako:

broj kolona nije jednak broju datih vrijednosti(There are more columns in the INSERT statement than values specified in the VALUES clause. )

upisujemo vrijednost čiji tip ne odgovara ili se ne može pretvoriti u tip kolone, npr. ako bismo u cjelobrojnu kolonu StudijID pokušali upisati tekst 'Marko'.(Syntax error converting the varchar value 'Marko' to a column of data type smallint.)

tekstualne konstante nisu zatvorene u jednostrukim navodnicima(The name 'Marko' is not permitted in this context. Only constants, expressions, or variables allowed here. Column names are not permitted.)

datum nije ispravan.(The conversion of a char data type to a datetime data type resulted in an out-of-range datetime value.)

nije navedena vrijednost za kolonu s obaveznim unosom ( NOT Null ), a da istovremeno nije zadana ( kod kreiranja tablice ) pretpostavljena (default)

79

vrijednost.(Cannot insert the value NULL into column 'Prezime', table 'DT.dbo.Studenti'; column does not allow nulls. INSERT fails.The statement has been terminated.)

5.4.2 Upisivanje svih kolona

Kada naredba za upisivanje retka obuhvaća listu svih kolona definiranih u tablici, nije neophodno navoditi listu kolona, već samo listu vrijednosti, pri čemu poredak vrijednosti mora odgovarati fizičkom poretku kolona u tablici:

INSERT INTO StudentiVALUES( 'Slavko', 'Perić', '1980/08/07', 1, 21000 )

Ovakvu naredbu možemo koristiti ad hock, dakle upotrijebimo i izbrišemo, ali nipošto u programima ili skriptama koje se koriste trajno. Naime, tijekom vremena prpizići će potreba za dodavanjem jedne ili više kolona u tablicu, što je uobičajena praksa kako primjena baze napreduje, a onda broj kolona tablice i navedenih vrijednosti se neće podudariti. Stoga je praktičana neophodnost da se uvijek navodi lista kolona u koje se upisuju vrijednosti. Naknadno dodane kolone moraju dopuštati Null vrijednost ili imati definiranu pretpostavljenu ( default ) vrijednost.

5.4.3 Upisivanje iz jedne tablice u drugu

Stvorimo li tablicu Studenti2, s kolonama Ime, Prezime i StudijID, tada u nju možemo upisati dio ili sve retke iz tablice Studenti, naredbom:

INSERT INTO Studenti2( Ime, Prezime, StudijID)SELECT Ime, Prezime, StudijIDFROM StudentiWHERE StudijID=1

Dobijena poruka je (5 row(s) affected), te možemo provjeriti sadržaj tablice Studenti2.

5.4.4 Pomjena podataka ( update )

Potrebno je promijeniti DatumRodjenja studentu Ivo Ivić. Ispravan datum je 21.06.1980.

UPDATE StudentiSET DatumRodjenja='1980/06/21'WHERE Ime='Ivo' AND Prezime='Ivić'

Prije izvođenja ovakve naredbe, moramo biti sigurni da će se promjena provesti samo željenom studentu, pa je kod ovakvih promjena najbolje koristiti primarni ključ u

80

WHERE klauzuli. Česte su greške koje se dese zbog brzopletosti, npr. izvođenjem komande:

UPDATE StudentiSET DatumRodjenja='1980/06/21'

Učinak je katastrofalan: svim studentima postavljen je isti datum rođenja. Naravno i za ovakve pogreške moramo predvidjeti lijek, no u svakom slučaju dobro je izbjeći ovako neugodne situacije, pažljivim zadavanjem naredbe UPDATE.

5.4.5 Promjena podataka tablice vrijednostima druge tablice

Svim studentima koji nemaju definiran poštanski broj, ( PostaID IS NULL), potrebno je upisati broj čija druga znamenka slijeva odgovara broju StudijID, a prva znamenka je 2.

Kako se radi o zahtjevnoj naredbi, najprije ćemo provjeriti naše razmišljanje izvođenjem SELECT upita, jer jasno je, pogrešno promijenjene podatke nije lako popraviti:

SELECT StudijID, S.PostaID, P.PostaIDFROM Studenti S, Poste PWHERE CONVERT(varchar, StudijID)=SUBSTRING(CONVERT(varchar, P.PostaID), 2,1) ANDP.PostaID BETWEEN 20000 AND 29999 AND S.PostaID IS NULL

StudijID S.PostaID P.PostaID3 NULL 230002 NULL 220001 NULL 21000

Kako smo zaista dobropostavili uvjet, to vidimo da su obuhvaćeni samo studenti kojima nije definirana PostaID ( NULL ), te da je prva znamenka slijeva poštanskog broja 2 i konačno StudijID i driga znamenka poštanskog broja se uvijek podudaraju.Stoga, provedimo promjene podataka:

UPDATE StudentiSET PostaiD=P.PostaIDFROM Studenti S, Poste PWHERE CONVERT(varchar, StudijID)=SUBSTRING(CONVERT(varchar, P.PostaID), 2,1) ANDP.PostaID BETWEEN 20000 AND 29999 AND S.PostaID IS NULL

Jasno je, da će nakon izvedene naredbe PostaID dobiti ranijom komandom izlistane vrijednosti.

81

5.4.6 Brisanje ( delete ) retka

Možemo brisati pojedinačne retke, grupu redaka koji zadovoljavaju određeni kriterij, ili pak sve retke u tablici.

5.4.6.1 brisanje jednog retka

Općenito, sigurno ćemo izbrisati samo jedan redak, ako se u WHERE klauzuli testira vrijednost primarnog ključa, jer on na jedinstven način identificira svaki redak.

Primarni ključ tablice Studenti je StudentID, čije vrijednosti automatski generira sustav relacijske baze ( Autonumber ).Brišemo, dakle trajno uklanjamo iz tablice, studenta Hrvoja Antića, čijije StudentID ( u mojoj tablici ) 7 naredbom:

DELETE FROM StudentiWHERE StudentID=7

Kako smo upotrijebili primarni ključ kao uvjet, to smo sigurni da je izbrisan najviše jedan redak.

5.4.6.2 brisanje više redaka koji zadovoljavaju uvjet

Pretpostavimo da su se svi studenti iz Zadarske i Šibenske županije ispisali sa studija, te ih moramo ukloniti iz tablice. Iskoritit ćemo pogodnost da sve pošte u Zadarskoj županiji započinju s 23, a u šibenskoj s 22, pa su u opsegu brojeva 22000 do 23999 zaparavo sva mjest ove dvije županije:

DELETE FROM StudentiWHERE PostaID BETWEEN 22000 AND 23999

Rezulta je: (3 row(s) affected).

brisanje svih redaka tablice

Vrlo jednostavno, kako se i da pretpostaviti, ispuštanjem uvjeta bit će izbrisani svi retci tablice.

DELETE FROM Studenti

Skrenimo pažnju, da je nakon izvedene komande, tablica potpuno prazna. Prije izvođenja ovakvih komandi, moramo biti sigurni što želimo.

82

6 Literatura:

1. Mladen Varga: «Baze podataka – Konceptualno, logičko i fizičko modeliranje podataka», Društvo za razvoj informacijske pismenosti (DRIP), Zagreb, 1994.

2. Darko Hrenić: «ORACLE», Znak, Zagreb, 1995.

3. Ratko Vujnović: «SQL i relacijski model podataka», Znak, Zagreb, 1995.

4. Malcolm Dodwell: «System Modelling Techniques» ( Course Notes ), Oracle Corporation UK Ltd, 1993.

5. David Solomon: «MS SQL Server 6.5», SAMS Publishing, 1996.

6. Kalen Delany: «Inside SQL Server 2000», 2000.

7. Ken Henderson: «The Gurus's Guide to Transact-SQL», Addison-Wesley, 2000.

83