Sveučilište u Zagrebu Prirodoslovno Matematički fakultet Matematički odsjek

Robert Manger

BAZE PODATAKA
Skripta

Drugo izdanje Zagreb, veljača 2011.

Robert Manger

2

PMF – Matematički odsjek

Baze podataka - skripta

Sadržaj
Predgovor ....................................................................................................................................... 7

1.

Uvod u baze podataka ........................................................................................................... 9 1.1. Osnovni pojmovi ......................................................................................................... 9 Baza podataka i sustav za upravljanje bazom podataka (DBMS) ........................ 9 Modeli za logičku strukturu baze podataka ........................................................ 10 Ciljevi koji se nastoje postići uporabom baza podataka .................................... 10 Arhitektura baze podataka .................................................................................. 11 Jezici za rad s bazama podataka ......................................................................... 13 UtvrĎivanje i analiza zahtjeva ............................................................................ 14 Oblikovanje (konceptualno, logičko i fizičko) ................................................... 14 Implementacija ................................................................................................... 15 Testiranje ............................................................................................................ 15 Odrţavanje ......................................................................................................... 16 Vaţnost izrade dokumentacije ........................................................................... 17 Predlošci za izradu dokumentacije ..................................................................... 18 Uporaba CASE alata i drugih vrsta softvera ...................................................... 23 1.1.1. 1.1.2. 1.1.3. 1.1.4. 1.1.5. 1.2. 1.2.1. 1.2.2. 1.2.3. 1.2.4. 1.2.5. 1.3. 1.3.1. 1.3.2. 1.3.3. 1.4.

Razvojni ciklus baze .................................................................................................. 14

Dokumentacija baze .................................................................................................. 16

Zadaci za vjeţbu ........................................................................................................ 24

2.

Konceptualno oblikovanje baze podataka ........................................................................ 27 2.1. Entiteti, atributi, veze................................................................................................. 27 Entiteti i njihovi atributi ..................................................................................... 27 Veze i njihovi atributi ......................................................................................... 28 Funkcionalnost veze, obaveznost članstva, kardinalnost ................................... 30 Otkrivanje entiteta, veza i atributa ..................................................................... 33 Crtanje dijagrama ............................................................................................... 35 Sastavljanje teksta koji prati dijagram ............................................................... 36 Prikaz involuirane veze ...................................................................................... 37 Prikaz pod-tipova i nad-tipova entiteta .............................................................. 39 Prikaz ternarne veze ........................................................................................... 40 PMF – Matematički odsjek 3 2.1.1. 2.1.2. 2.1.3. 2.2. 2.2.1. 2.2.2. 2.2.3. 2.3. 2.3.1. 2.3.2. 2.3.3. 2.4.

Oblikovanje konceptualne sheme .............................................................................. 33

Sloţenije veze ............................................................................................................ 37

Zadaci za vjeţbu ........................................................................................................ 42

...............2........3.3....... 3.........3....................3....... 52 3................... prevoĎenje relacije u treću normalnu formu .............................. prevoĎenje relacije u Boyce-Coddovu normalnu formu .2..................................1.................. 4........................... Pretvaranje konceptualne sheme u relacijsku shemu ................................................ 3........................................1....3..............................................2.............. 50 Zadaci za vjeţbu ...3.......................2.. Normalizacija ........ ponavljajuće skupine..3. Boyce-Codd-ova i četvrta normalna forma ..2........................2........... 4........... 3......1................... 3..... 55 4....2..1... 57 Parcijalne ovisnosti................... 63 Teškoće u radu s nenormaliziranim podacima ........... 66 Normalizacija kao ispravak konceptualnih grešaka ......... 3.......3....................................2........... 3.... 3..........2..................... 69 4..........4.... druga i treća normalna forma ................... 61 Odnos Boyce-Codd-ove prema drugoj i trećoj normalnoj formi .... 66 Zadaci za vjeţbu .................1..................1..4..... 4............................................ 4........................ prevoĎenje u prvu normalnu formu .......... 45 Pretvaranje sloţenijih veza u relacije ......nastavak logičkog oblikovanja baze podataka ....2............ 4.............................................................. atribut......................1...... 68 Razlozi kad se ipak moţe odustati od normalizacije.... n-torka ...1................................................1..............................2. 3...........1.................4.......... 3.2............... 3..1....................... 3........................................................... 44 Pretvorba entiteta i atributa ..3.3... 4. 58 Tranzitivne ovisnosti........................... 46 Pretvorba veza mnogo-naprama-mnogo ........1...........2............... 4.....................3........................................ 48 Pretvorba involuiranih veza . 4.......................................... 45 Pretvorba veza jedan-naprama-mnogo ................ 4................... 3....1..................................3............3.................................................. 43 3. 44 Relacijska shema............................1...... 4........ prevoĎenje relacije u četvrtu normalnu formu ............ Općenito o relacijskom modelu .................3................ 53 4.... 43 Relacija............ Prva........ 62 Višeznačne ovisnosti..... 50 Pretvorba pod-tipova i nad-tipova .................................. Relacijski model ...............logičko oblikovanje baze podataka ........ 55 Pod-zapisi... 61 Potreba za normalizacijom .............. načini njezina zapisivanja ...2......................... prevoĎenje relacije u drugu normalnu formu .................. 43 Kandidati za ključ...............2....... 59 Determinante... 48 Sastavljanje rječnika podataka ... 70 4 PMF – Matematički odsjek .......... primarni ključ ... 55 Funkcionalne ovisnosti izmeĎu atributa ili skupina atributa ........1........4............................................................ 4.......Robert Manger 3...... 4..................... 52 Pretvorba ternarnih veza.............

....3...................................................... 86 Jednostavni upiti................... 97 Organizacija datoteke ............................................... projekcije i ostalih operacija ......... 73 Skupovne operacije ................1....................................................2.................................... 105 Stvaranje početne verzije fizičke sheme .. 6. 5................3............ 5...... 80 Račun orijentiran na n-torke .................... 76 Kartezijev produkt i dijeljenje ........ 5..................................................................1....3. 73 5............................ 117 6.. 5......4...................................... 6......................................................1.........................2...........................................................................2..................................2.............................. 6................................................. Relacijska algebra .........Baze podataka ...... 5.....2.......................1.... 95 6............. 116 Optimizacija upita .1........................ 97 Elementi fizičke graĎe ........... 5......... 111 Zadaci za vjeţbu .....................................3................. 113 Izvrednjavanje selekcije..............................................................................2...............2...................... 107 Izvrednjavanje i optimizacija upita.................................................................. 119 PMF – Matematički odsjek 5 ......3.. 110 Opći tijek izvrednjavanja i optimizacije. 78 Prirodni spoj i slične operacije . Fizička graĎa baze podataka ................................................. 5..........................1. 6.1....................................... 6....................................................... 5.......................1.................. 6....................3................ Relacijski račun ..2........... 89 Grupirajući upiti ........3............................... 6..............................3......................... 6..2..... 75 Selekcija i projekcija ...............................skripta 5................. 6...................1.............................................................1....1...3..................................... 6..... 112 Izvrednjavanje prirodnog spoja .................4.........1..................2.......3.... 5.......... 88 Sloţeniji upiti ............................................. 6............................ Postavljanje upita u relacijskim bazama podataka .................... 5............................................3......1.4..........4. 6............... 97 6.................................................2......................................................................................2................................................ 5.3...................... Pretvorba relacijske sheme u fizičku shemu i njezina implementacija .. Fizičko oblikovanje i implementacija baze podataka ............................................... 85 Odnos relacijskog računa prema relacijskoj algebri ............ 84 Račun orijentiran na domene.3...1.......2............ 87 Zadaci za vjeţbu ..............2.................. 84 Jezik SQL ....................................... 100 Organizacija indeksa ............................................. 92 5...................................................................................1..... 109 Stvaranje i inicijalno punjenje baze .................................................... 5.....3.....................3....................... 108 Daljnje dotjerivanje fizičke sheme ....

......2..... Vremenski ţigovi .... Serijalizabilnost paralelnih transakcija..........................................2................... 131 Uporaba pogleda kao mehanizma zaštite ...................... 141 P.... 161 6 PMF – Matematički odsjek ...... 128 Istovremeni pristup ............. 7.........................2.... 141 P................2 ............ 139 7...... 151 P....3...............................................2........................................................... 150 P.............................................................. 7.3....................... 141 P..........................................1............................... Oblikovanje baze podataka o znanstvenoj konferenciji ............................................ Čuvanje integriteta ................. 143 P2................2...... 7..2...................................... Lokoti i zaključavanja ...... Sigurnost baze....3............................ 7.......................1..4..........................................................................1............ 123 UvoĎenje ograničenja kojima se uspostavlja integritet domene ........2 ................. 152 Literatura ............ 142 P............ Zadaci za vjeţbu .................................. 140 Prilozi.....3...............1.............................................3.........3.......... Dvofazni protokol zaključavanja .... 123 UvoĎenje ograničenja za čuvanje integriteta unutar relacije ..................... Konceptualna shema za znanstvenu konferenciju ................................Robert Manger 7................................................................ 125 Stvaranje pretpostavki za oporavak baze ....................1.................................................. 151 P............................2.....2............4...... 136 7....................... Specifikacija za znanstvenu konferenciju .........................................................1................4........ Specifikacija za bolnicu ...... Relacijska shema i rječnik podataka za znanstvenu konferenciju ..............1.... 142 P..............2... 124 UvoĎenje ograničenja kojima se čuva referencijalni integritet . Fizička shema za znanstvenu konferenciju ......... 123 7..3.................... 128 Davanje ovlaštenja korisnicima ...............................................2.............................. 7...........................3...................... 135 7. 138 7..................................................................1........................... Oblikovanje baze podataka o bolnici ............ Relacijska shema i rječnik podataka za bolnicu.................... Integritet i sigurnost baze podataka ............. 137 7...........................1........................1........................ 150 P........... 7................................. 134 7...................... Fizička shema za bolnicu ...........................................1........................................................................... Konceptualna shema za bolnicu ............... 7...............3...........................................1.......................1...1........4....2............................................3...................

te čuvanje integriteta odnosno sigurnosti podataka. dakle normalizacijom relacijske sheme dobivene metodama iz Poglavlja 3. već bi trebala odraţavati smisao i unutarnju povezanost samih podataka. naglasak je stavljen na postupak oblikovanja (projektiranja) baze. Poglavlje 2 obraĎuje konceptualno oblikovanje baze podataka. Sastavni dio druge faze je takozvana normalizacija.Baze podataka . no ujedno objašnjava i kako je baza zaista fizički graĎena. Na taj način. ili ona moţe predstavljati samostalni resurs i davati podršku raznim aplikacijama. te pokriva prvi dio logičkog oblikovanja koji rezultira polaznom relacijskom shemom. Druga faza stvara takozvanu logičku ili relacijsku shemu sastavljenu od relacija (tablica). Baza podataka moţe se pojaviti kao sastavni dio neke odreĎene aplikacije. Čak i u prvom. baza bi dugoročno trebala biti pogodna za promjene i evoluciju u skladu sa zahtjevima budućih aplikacija. Cilj oblikovanja je da se na osnovu utvrĎenih potreba za podacima odabere pogodna graĎa baze. Ova skripta sastoje se od 7 poglavlja. baza nastaje kao rezultat zasebnog razvojnog postupka koji je u većoj ili manjoj mjeri odvojen od razvoja samih aplikacija. Tekst pokriva sve vaţne teme koje se obično susreću u udţbenicima o relacijskim bazama podataka. Poglavlje 5 predstavlja malu digresiju u zamišljenom postupku oblikovanja: tu naime govorimo o postavljanju upita u relacijskim bazama podataka pomoću jezika kao što su relacijska algebra. bilo u fazi njezina oblikovanja bilo tijekom njezine kasnije uporabe. odnosno upitni dio SQL-a. relacijski račun. Ipak. ona zorno opisuje podatke ali još nije pogodna za implementaciju. U prvoj fazi nastaje konceptualna shema sastavljena od entiteta.skripta Predgovor Ova skripta sadrţe predavanja iz predmeta „Baze podataka“ koji se predaje studentima matematike na PMF-Matematičkom odsjeku Sveučilišta u Zagrebu. Treća faza daje kao rezultat naredbe u jeziku SQL kojima se realizira potrebna fizička graĎa baze zajedno s pomoćnim strukturama za pretraţivanje. koja je usklaĎena s mogućnostima uobičajenih softverskih paketa za upravljanje relacijskim bazama podataka. te se daje pregled razvojnog ciklusa baze odnosno načina njezinog dokumentiranja. te kako se nad njom obavljaju uobičajene operacije poput izvrednjavanja upita. Uobičajeni postupak oblikovanja baze podataka sastoji se od tri faze: to su konceptualno. Poglavlje 1 sadrţi uvod u baze podataka: tu se definiraju osnovni pojmovi. atributa i veza. U Poglavlju 4 bavimo se nastavkom logičkog oblikovanja. a pogotovo u drugom slučaju. odnosno fizičko oblikovanje. Poglavlje 3 objašnjava relacijski model za bazu podataka. Ta graĎa u pravilu ne bi smjela biti optimizirana za jednu odreĎenu aplikaciju. atributa i veza. gdje se logička struktura relacija popravlja tako da bolje izrazi unutrašnje osobine samih podataka. logičko. Oblikovanje baze podataka predstavlja ključni dio njezinog razvoja. dakle izradu odgovarajuće sheme entiteta. Zadnje Poglavlje 7 govori o čuvanju integriteta i sigurnosti baze podataka. Poglavlje 6 odnosi se na fizičko oblikovanje baze podataka u jeziku SQL. na primjer govori o relacijskom modelu i o jeziku SQL. PMF – Matematički odsjek 7 .

Kroz većinu poglavlja provlači se jedan odabrani studijski primjer: baza podataka o fakultetu. zadnje potpoglavlje sadrţi zadatke za vjeţbu. u prilogu se nalazi cjelovita dokumentacija za dodatna dva studijska primjera. Makar ova skripta u potpunosti pokrivaju predavanja iz predmeta „Baze podataka“ na PMFMatematičkom odsjeku. od vjeţbi se očekuje da one. te pruţe studentima mogućnost stvarnog rada s tim jezikom na računalu. Neki od tih zadataka su samostalni. puno detaljnije obrade jezik SQL. neki se odnose na studijske primjere. 8 PMF – Matematički odsjek .Robert Manger Ova skripta bogato su opskrbljena primjerima i zadacima koji prate i ilustriraju obraĎeno gradivo. osim praćenja tema s predavanja. Unutar svakog poglavlja. ona za sada samo djelomično pokrivaju vjeţbe iz istog predmeta. a neki na bazu podataka iz studentovog područja interesa. Naime. TakoĎer.

a specijalizirani softver koji posreduje izmeĎu aplikacija i podataka naziva se sustav za upravljanje bazom podataka. a zatim ćemo objasniti i druge pojmove koji su u vezi s njima. pohranjenih u vanjskoj memoriji računala. kvalitetu i pouzdanost u razvoju aplikacija koje se temelje na pohranjivanju i pretraţivanju podataka u računalu. Sustav za upravljanje bazom podataka (Data Base Management System . računala zapravo rijetko sluţe za računanje. Spomenuta zajednička kolekcija podataka naziva se baza podataka.1. 1. PMF – Matematički odsjek 9 . Ipak. on obavlja u ime klijenata sve operacije s podacima. brine se za sigurnost podataka. Osnovni pojmovi Osnovna ideja tehnologije baza podataka je u tome da pojedina aplikacija ne stvara svoje vlastite datoteke na disku. Isto tako. Umjesto toga. a znatno češće za spremanje i pretraživanje podataka. program razvijen u jeziku COBOL ili C moţe stvoriti datoteku na disku i u nju upisati podatke. Na primjer. od kojih svaka moţe imati svoju logičku strukturu. aplikacija ne pristupa izravno podacima na disku. Podaci su istovremeno dostupni raznim korisnicima i aplikacijskim programima. TakoĎer. takozvanog sustava za upravljanje bazom podataka (DBMS-a). Ta tehnologija osigurala je veću produktivnost. Baza podataka i sustav za upravljanje bazom podataka (DBMS) Baza podataka je skup meĎusobno povezanih podataka. sluţeći se uslugama specijaliziranog softvera koji je zaduţen da se brine za zajedničku kolekciju. To je izuzetno vaţna problematika: naime unatoč svom nazivu. te automatizira administrativne poslove s bazom. ona barata s podacima na posredan način. 1. ili otvoriti postojeću datoteku i iz nje pročitati podatke. brisanje i čitanje podataka obavlja se posredstvom posebnog softvera. Korisnici i aplikacije pritom ne moraju poznavati detalje fizičkog prikaza podataka. kad govorimo o bazama podataka. on je u stanju podrţati razne baze. tada mislimo na višu razinu rada s podacima od one koju podrţavaju klasični programski jezici. Uvod u baze podataka U ovom predmetu bavimo se problematikom trajnog pohranjivanja većih količina podataka u vanjskoj memoriji računala. Dalje. promjena. Mogućnost trajnog pohranjivanja podataka u računalima postoji gotovo jednako dugo koliko i sama računala. Ustvari mislimo na tehnologiju koja je nastala s namjerom da ukloni slabosti tradicionalne „automatske obrade podataka“ iz 60-tih i 70-tih godina 20. no u skladu s istim modelom. On oblikuje fizički prikaz baze u skladu s traţenom logičkom strukturom. Umjesto toga.skripta 1. sve aplikacije rabe zajedničku i objedinjenu kolekciju podataka. već se referenciraju na neku idealiziranu logičku strukturu baze.Baze podataka . Ubacivanje. Sluţeći se klasičnim programskim jezicima u principu je moguće stvoriti trajne kolekcije podataka na disku i izgraditi aplikacije koje rabe takve podatke.DBMS) je posluţitelj (server) baze podataka. stoljeća. TakoĎer.1. U nastavku ćemo najprije pokušati preciznije definirati ova dva ključna pojma. te je podrţana u svim programskim jezicima.1.

podaci u bazi moraju biti logički organizirani u skladu s onim modelom kojeg podrţava odabrani DBMS. Baza je predočena mreţom koja se sastoji od čvorova i usmjerenih lukova. na primjer UNIX. Specijalni slučaj mreţnog. Proizvod tvrtke IBM.1. Ciljevi koji se nastoje postići uporabom baza podataka Spomenuli smo da baze podataka predstavljaju višu razinu rada s podacima u odnosu na klasične programske jezike.  MS SQL Server. Modeli za logičku strukturu baze podataka Model podataka je skup pravila koja odreĎuju kako sve moţe izgledati logička struktura baze podataka. stoljeća. DBMS spada u temeljni softver kojeg većina korisnika i organizacija ne razvija samostalno već ga kupuju zajedno s računalom. Svi ovi proizvodi uz sam DBMS uključuju u sebi i dodatne alate za razvoj aplikacija. Linux i MS Windows. popularan na raznim platformama.  Objektni model.  Hijerarhijski model. Svi prije spomenuti poznati DBMS-i koji su danas u širokoj uporabi podrţavaju isključivo relacijski model. Svako stablo sastoji se od čvorova i veza „nadreĎenipodreĎeni“ izmeĎu čvorova. Baza je predočena kao skup trajno pohranjenih objekata koji se sastoje od svojih internih „atributa“ (podataka) i „metoda“ (operacija) za rukovanje tim podacima. Baza je predočena jednim stablom (hijerarhijom) ili skupom stabala. Hijerarhijski i mreţni model bili su u uporabi u 60-tim i 70-tim godinama 20.1. 1. Očekivani prijelaz na objektni model za sada se nije desio. agregacije. Svaki objekt pripada nekoj klasi. Čvorovi predstavljaju tipove zapisa (slogova podataka). Dosadašnji DBMS-i obično su podrţavali neki od sljedećih modela:  Relacijski model. prvenstveno kao podrška web aplikacijama. Od 80tih godina pa sve do današnjih dana prevladava relacijski model. Zasnovan je na matematičkom pojmu relacije.Robert Manger Slično kao i operacijski sustav. Besplatni proizvod tvrtke MySQL AB. Proizvod istoimene tvrtke. Inspiriran je objektno-orijentiranim programskim jezicima.  MySQL. Microsoftov proizvod.  Oracle. Danas postoji svega nekoliko vaţnih i široko zastupljenih DBMS-a. 1. IzmeĎu klasa se uspostavljaju veze nasljeĎivanja. Točnije rečeno. a lukovi definiraju veze meĎu tipovima zapisa. Ta viša razina rada očituje se u tome što tehnologija baza podataka nastoji (i u velikoj mjeri uspijeva) ispuniti sljedeće ciljeve. pokriva gotovo sve računalne platforme. I podaci i veze meĎu podacima prikazuju se tablicama koje se sastoje od redaka i stupaca. Čvorovi su tipovi zapisa. administriranje baze i slično.  DB2. Model čini osnovu za oblikovanje i implementiranje baze. a odnos „nadreĎeni-podreĎeni" izraţava hijerarhijske veze meĎu tipovima zapisa.3. namijenjen prvenstveno velikim mainframe računalima.  Mrežni model. namijenjen posluţiteljskim računalima s operacijskim sustavima MS Windows.2. te druge vrste veza. tako da današnje baze podataka uglavnom još uvijek moţemo poistovjetiti s relacijskim bazama. 10 PMF – Matematički odsjek .

podaci se prepišu u druge datoteke na drugim diskovima). Ovakvi poslovi moraju se obavljati centralizirano. Arhitektura baze podataka Arhitektura baze podataka sastoji se od tri „sloja“ i sučelja meĎu slojevima. te konfliktne istovremene aktivnosti korisnika. mijenjanje parametara u fizičkoj graĎi. to neće zahtijevati promjene u postojećim aplikacijama. od sasvim konkretnih staza i cilindara na disku. Razdvaja se logička definicija baze od njezine stvarne fizičke graĎe. Na brzinu pristupa moţe se utjecati odabirom pogodnih fizičkih struktura podataka. Mogućnost podešavanja i kontrole. Administratoru trebaju stajati na raspolaganju razni alati i pomagala. Operacije s podacima moraju se odvijati dovoljno brzo. te svaki od njih treba imati dojam da sam radi s bazom. do već donekle apstraktnih pojmova datoteke i zapisa (sloga) kakve susrećemo u klasičnim programskim jezicima.        1. i to u situaciji kad postoje greške u aplikacijama. Sama fizička razina moţe se dalje podijeliti na više pod-razina apstrakcije. Zadovoljavajuća brzina pristupa. reguliranje ovlaštenja korisnika. Čuvanje integriteta. Pritom ti korisnici ne smiju ometati jedan drugoga. Velika baza zahtijeva stalnu brigu: praćenje performansi. to neće zahtijevati promjene u postojećim aplikacijama.  Fizička razina odnosi se na fizički prikaz i raspored podataka na jedinicama vanjske memorije. Baza mora omogućiti da veći broj korisnika istovremeno rabe iste podatke. dakle da se svakom korisniku reguliraju ovlaštenja što on smije a što ne smije raditi s podacima. Istovremeni pristup do podataka. te izborom pogodnih algoritama za pretraţivanje. Znači. te po svom nahoĎenju uspostavljati veze meĎu podacima. Zaštita od neovlaštene uporabe. Riječ je o tri razine apstrakcije. ako se fizička graĎa promijeni (na primjer. Mora postojati mogućnost da se korisnicima ograniče prava uporabe baze. Razdvaja se globalna logička definicija cijele baze podataka od lokalne logičke definicije za jednu aplikaciju. u skladu s potrebama odreĎene aplikacije.skripta   Fizička nezavisnost podataka.Baze podataka . TakoĎer.4. Fleksibilnost pristupa podacima.1. Opis globalne logičke definicije PMF – Matematički odsjek 11 . rutinsko pohranjivanje rezervnih kopija podataka. kao što je prikazano na Slici 1. Raspored pohranjivanja opisuje kako se elementi logičke definicije baze preslikavaju na fizičke ureĎaje. Nastoji se automatski sačuvati korektnost i konzistencija podataka. dakle korisnik je mogao pretraţivati podatke jedino onim redoslijedom koji je bio predviĎen u vrijeme oblikovanja i implementiranja baze. uz neke jednostavne transformacije tih elemenata.1. Danas se podrazumijeva da korisnik moţe slobodno prebirati po podacima. Odgovorna osoba zove se administrator baze podataka. Mora postojati pouzdana zaštita baze u slučaju kvara hardvera ili grešaka u radu sistemskog softvera. pa povremeno treba podesiti i logičku strukturu. Ovom zahtjevu zaista zadovoljavaju jedino relacijske baze.  Globalna logička razina odnosi se na logičku strukturu cijele baze. ako se globalna logička definicija promijeni (na primjer uvede se novi zapis ili veza). Lokalna logička definicija obično se svodi na izdvajanje samo nekih elemenata iz globalne definicije. Znači. To je aspekt kojeg vidi projektant baze odnosno njezin administrator. načini pristupanja podacima bili su unaprijed definirani. Mogućnost oporavka nakon kvara. svrha baze se vremenom mijenja. Logička nezavisnost podataka. U starijim mreţnim i hijerarhijskim bazama. To je aspekt kojeg vide samo sistemski programeri (oni koji su razvili DBMS).

i u skladu je sa zadanim modelom.Robert Manger naziva se shema (engleski takoĎer schema). TakoĎer. Shema je tekst ili dijagram koji definira logičku strukturu baze. dok se logička neovisnost postiţe razlikovanjem lokalne logičke razine i globalne logičke razine. podešavanjem njemu dostupnih parametara. To je aspekt kojeg vidi korisnik ili aplikacijski programer. opet u skladu s pravilima rabljenog modela.  Aplikacijski program 1 Aplikacijski program 2 Aplikacijski program 3 Lokalna logička razina Pogled 1 Pogled 2 Pogled 3 Shema Globalna logička razina Raspored pohranjivanja Fizička razina Datoteke Datoteke Datoteke Datoteke Slika 1. Dakle imenuju se i definiraju svi tipovi podataka i veze meĎu tim tipovima.1: Arhitektura baze podataka. TakoĎer. shema moţe uvesti i ograničenja kojim se čuva integritet podataka. DBMS tada automatski generira potrebni raspored pohranjivanja i fizičku bazu. Projektant odnosno administrator moţe samo donekle utjecati na fizičku graĎu baze. Primijetimo da se fizička neovisnost podataka spomenuta u Odjeljku 1. pogled u svojoj konačnoj realizaciji zadaje i način na koji se iz globalnih podataka i veza izvode lokalni. Na taj način. Lokalna logička razina odnosi se na logičku predodţbu o dijelu baze kojeg rabi pojedina aplikacija. Opis jedne lokalne logičke definicije zove se pogled (engleski view) ili pod-shema. Za stvaranje baze podataka potrebno je zadati samo shemu i poglede.3 ustvari postiţe time što se pravi razlika izmeĎu fizičke i globalne logičke razine. opisana troslojna arhitektura omogućuje ispunjavanje dvaju najvaţnijih ciljeva koji se nastoje postići uporabom baza podataka. 12 PMF – Matematički odsjek . To je tekst ili dijagram kojim se imenuju i definiraju svi lokalni tipovi podataka i veze meĎu tim tipovima. u skladu s pravilima rabljenog modela.1.

Sluţi neposrednom korisniku za interaktivno pretraţivanje baze. već dobivaju ili pohranjuju podatke posredstvom DBMS-a.DDL). Naime. Dakle ti jezici su nam nuţni da bismo stvorili bazu i povezali se s njom. pa takav program treba prevoditi s dva prevodioca (DML-precompiler. manipuliranje i pretraţivanje. DML i QL nisu programski jezici.skripta Programi i korisnici ne pristupaju izravno fizičkoj bazi.  Jezik za opis podataka (Data Description Language . C.QL).5. Ti jezici tradicionalno se dijele na sljedeće kategorije. te jednostavne operacije kao što su upis. te se nije mogao rabiti izvan tog paketa ili baze. U nekim softverskim paketima. te su zato u tom kontekstu bili produktivniji od programskih jezika opće namjene.4GL): riječ je o jezicima koji su bili namijenjeni isključivo za rad s bazama.1.1. PMF – Matematički odsjek 13 . U drugim paketima zaista se radi o posebnom jeziku: programer tada piše program u kojem su izmiješane naredbe dvaju jezika. … ) s ugnijeţĎenim DML-naredbama. Naredbe DML omogućuju „manevriranje“ po bazi.Baze podataka . a ne i postupak za dobivanje rezultata. Problem s jezicima 4. U 80-tim godinama 20. Sluţi programeru za uspostavljanje veze izmeĎu aplikacijskog programa i baze. dakle takve da samo specificiraju rezultat kojeg ţelimo dobiti. a zatim ih dalje realizira kao ekvivalentne operacije na fizičkoj razini. no oni nam nisu dovoljni za razvoj aplikacija koje će nešto raditi s podacima iz baze. Jezici za rad s bazama podataka Komunikacija korisnika odnosno aplikacijskog programa i DBMS-a odvija se pomoću posebnih jezika.  Jezik za manipuliranje podacima (Data Manipulation Language . Naglasimo da gore spomenuti jezici DDL. kod relacijskih baza postoji tendencija da se sva tri jezika objedine u jedan sveobuhvatni. i to na logičkoj razini. Svi DBMS-i spomenuti u 1. To je jezik koji podsjeća na govorni (engleski) jezik. Sluţi projektantu baze ili administratoru u svrhu zapisivanja sheme ili pogleda. Primjer takvog integriranog jezika za relacijske baze je SQL: on sluţi za definiranje podataka.  Jezik za postavljanje upita (Query Language . Dakle tim jezikom definiramo podatke i veze meĎu podacima. promjena. Naredbe su ne-proceduralne. stoljeća bili su dosta popularni i takozvani jezici 4. generacije (4-th Generation Languages . 1. Ovakva podjela na tri jezika danas je već prilično zastarjela. Naredbe DDL obično podsjećaju na naredbe za definiranje sloţenih tipova podataka u jezicima poput COBOL-a ili C-a.1 koji su danas u širokoj uporabi koriste se isključivo SQL-om za sve tri svrhe. brisanje ili čitanje zapisa. Komunikacija programa odnosno korisnika s DBMS-om obavlja se na lokalnoj logičkoj razini.DML). DML je zapravo biblioteka potprograma: „naredba“ u DML svodi se na poziv potprograma. To znači da DBMS na transparentan način prevodi korisničke zahtjeve za podacima s lokalne logičke razine na globalnu logičku razinu. obični compiler). Integrirani jezik se moţe rabiti interaktivno (preko on-line interpretera) ili se on moţe pojavljivati uklopljen u aplikacijske programe. Tradicionalni način razvoja aplikacija koje rade s bazom je uporaba klasičnih programskih jezika (COBOL. generacije je bio u njihovoj nestandardnosti: svaki od njih je u pravilu bio dio nekog odreĎenog softverskog paketa za baze podataka.

Taj dokument rijetko se odnosi samo na podatke. C++. oblikovanje (projektiranje). on ujedno definira i najvaţnije transakcije s podacima. Oblikovanje (konceptualno. Za interakcije s bazom rabe se unaprijed pripremljene klase objekata. Utvrđivanje i analiza zahtjeva Da bi se utvrdili zahtjevi. Budući da je oblikovanje prilično sloţena aktivnost. rezultat oblikovanja mogu takoĎer biti i pogledi (pod-sheme) za potrebe pojedinih vaţnijih aplikacija.2. razgovara se s korisnicima. 1. oblikovanje predlaţe način kako da se podaci na pogodan način grupiraju. 1. Uočavaju se podaci koje treba pohranjivati i veze meĎu njima. testiranje i odrţavanje. Razvojni ciklus baze UvoĎenje baze podataka u neku ustanovu predstavlja sloţeni zadatak koji zahtijeva primjenu pogodnih metoda i alata. Kod većih baza. Dakle gledaju se dokumenti koji su u opticaju. Rezultat utvrĎivanja i analize zahtjeva je dokument (obično pisan neformalno u prirodnom jeziku) koji se zove specifikacija. a razvijeni program se lako dotjeruje. logičko i fizičko) Cilj oblikovanja je da se u skladu sa specifikacijom oblikuje graĎa baze. implementacija. Ovakva tehnika je dovoljno produktivna zbog uporabe gotovih klasa. operacija) koje će se obavljati s podacima. No u slučaju baza podataka taj ciklus ima neke svoje specifičnosti. te zapisana na način da ju rabljeni DBMS moţe razumjeti i realizirati. Riječ je o razvojnom ciklusu koji je dobro poznat u softverskom inţenjerstvu i koji se u sličnom obliku pojavljuje kod razvoja bilo koje vrste softverskih produkata. tako da se eliminira redundancija i nekonzistentnost. graĎena u skladu s pravilima rabljenog modela podataka. gdje postoje razne grupe korisnika. 14 PMF – Matematički odsjek . Analiza zahtjeva treba pomiriti te razlike. Dok je analiza zahtjeva otprilike odredila koje vrste podataka baza treba sadrţavati i što se s njima treba moći raditi. strukturiraju i meĎusobno poveţu. u raznim nazivima podataka treba prepoznati sinonime i homonime. C#. prate se radni procesi. proučavaju se tokovi informacija u dotičnoj ustanovi. te zahtjeve na performanse. aplikacije se najčešće razvijaju u standardnim objektno orijentiranim programskim jezicima (Java. pojavit će se razna tumačenja značenja i svrhe pojedinih podataka. proučava se postojeći softver.Robert Manger U današnje vrijeme. uklapa u veće sustave ili prenosi s jedne baze na drugu. a često i cijele aplikacije. Glavni rezultat oblikovanja trebala bi biti shema cijele baze. nas u ovim skriptama najviše zanima oblikovanje. budući da to redovito ima utjecaja na sadrţaj i konačni oblik baze.2. Analiza zahtjeva takoĎer mora obuhvatiti analizu transakcija (postupaka.2. Od navedenih pet aktivnosti. Ipak. te uskladiti terminologiju. … ). To je projekt koji se moţe podijeliti u pet aktivnosti: utvrĎivanje i analiza zahtjeva. Vaţno je procijeniti frekvenciju i opseg pojedinih transakcija.1.2. te timski rad stručnjaka raznih profila. te razni načini njihove uporabe. Na primjer. ona se obično dijeli u tri faze koje slijede jedna iza druge i koje ćemo sad ukratko opisati. zbog cjelovitosti izlaganja. 1. u ovom potpoglavlju ukratko ćemo opisati sve aktivnosti. U velikim organizacijama.

O toj dokumentaciji opširnije ćemo govoriti u Potpoglavlju 1. Većina DBMS-a opskrbljena je alatima koji nam olakšavaju transfer podataka iz takvih izvora u bazu. 1. Pritom se dodaju pomoćne strukture i mehanizmi za postizavanje traţenih performansi. ili kao tekstualni dokumenti. odnosno Poglavljima 3 i 4. ispravljanja i usklaĎivanja podataka. U slučaju DBMS-a zasnovanog na SQL-u. te se mjere performanse. Greške u ranijim aktivnostima imaju teţe posljedice jer se provlače i kroz kasnije aktivnosti pa PMF – Matematički odsjek 15 . te se na disku stvaraju prazne SQL tablice sa svim pratećim strukturama i mehanizmima. zbog potrebe čišćenja. Daljnji postupak sastoji se od punjenja praznih tablica s početnim podacima. dakle opis njezine fizičke graĎe. Dakle pokreću se najvaţnije transakcije s podacima. na primjer kao obične datoteke. Svi rezultati oblikovanja opisuju se u odgovarajućim dokumentima koji zajedno čine projektnu dokumentaciju baze. Testiranje Testiranje baze provodi se tako da korisnici pokusno rade s bazom i provjeravaju zadovoljava li ona svim zahtjevima. Ona zorno opisuje sadrţaj baze i načine povezivanja podataka u njoj. No postupak je obično ipak mukotrpan i ne da se sasvim automatizirati. da bi se utvrdila stabilnost i pouzdanost rada pod opterećenjem. Sastavni dio logičkog oblikovanja je i takozvana normalizacija.Baze podataka . pojam fizičke razine treba shvatiti uvjetno. razvijaju se aplikacije koje obavljaju najvaţnije transakcije s podacima.2. atributa i veza. Kao glavni rezultat druge faze oblikovanja nastaje logička shema.3.3. pokreću se SQL naredbe koje čine fizičku shemu baze. odnosno implementaciji. te čuvanje integriteta i sigurnosti podataka. oblikovanju. koja je u slučaju relacijskog modela sastavljena od relacija (tablica).   Navedene tri faze oblikovanja detaljno ćemo obraditi u Poglavlju 2. neformalan i pogodan ljudima za razumijevanje. Takvi podaci obično postoje u nekom obliku. Implementacija Implementacija se svodi na fizičku realizaciju oblikovane baze na odgovarajućem posluţiteljskom računalu. 1.skripta  Konceptualno oblikovanje.2. TakoĎer se mogu uključiti i SQL naredbe kojima se pogledi (podsheme) za pojedine aplikacije realiziraju kao virtualne tablice izvedene iz stvarnih tablica. Time je omogućeno testiranje. no još je nedovoljno razraĎen da bi omogućio izravnu implementaciju. Fizičko oblikovanje. gdje se primjenom posebnih pravila nastoji popraviti logička struktura samih relacija. Glavni rezultat prve faze oblikovanja je takozvana konceptualna shema cijele baze.4. tako da se ona bolje prilagodi inherentnim osobinama samih podataka. prati se njihov učinak. Prikaz je jezgrovit. Glavni cilj testiranja je otkrivanje i popravak grešaka koje su se mogle potkrasti u svakoj od prethodnih aktivnosti: dakle u analizi zahtjeva. sastavljena od entiteta. Glavni rezultat treće faze oblikovanja je fizička shema cijele baze. odnosno Poglavlju 6 ovog priručnika . U slučaju uporabe DBMS-a zasnovanog na jeziku SQL. Fizička shema zapravo je niz SQL naredbi kojima se relacije iz logičke sheme realiziraju kao SQL tablice. Nakon što su početni podaci uneseni u bazu. Logičko oblikovanje. TakoĎer se nastoji simulirati očekivana frekvencija pojedinih transakcija.

Mjerenjem performansi tijekom testiranja nastoji se na utvrditi jesu li zadovoljeni zahtjevi vezani uz performanse. na primjer dodavanjem novih pomoćnih struktura podataka (indeksa) ili rasporeĎivanjem podataka na više diskova. a to onda znači da tog podatka neće biti ni projektnoj dokumentaciji ni u implementiranoj bazi. Riječ je o kontinuiranom procesu. Moramo biti svjesni činjenice da baza koja se ne mijenja vrlo brzo postaje neuporabljiva. Neki autori proces odrţavanja opisuju moţda i primjerenijim pojmom evolucije. izuzetno je vaţno da baza od početka ima zdravu graĎu koja odraţava inherentnu logiku i povezanost samih podataka.3. Korekcijsko održavanje svodi se na naknadni popravak grešaka koje nisu bile otkrivene tijekom testiranja. prikazati nekoliko predloţaka za njezinu izradu. Kao i općenito u softverskom inţenjerstvu. administrator baze moţe to pokušati ispraviti podešavanjem odreĎenih parametara fizičke organizacije.Robert Manger zahtijevaju više truda da se poprave. Pritom te promjene neće utjecati na ispravni rad već postojećih aplikacija. koje se razlikuju po sadrţaju i svrsi traţenih promjena.3. pa popravak treba izvršiti u svim dokumentima i shemama. tako i kod baza podataka moţemo govoriti o nekoliko vrsta odrţavanja. dakle nova revizija shema. mi ćemo se ograničiti isključivo na projektnu dokumentaciju za baze podataka. Ispravno normalizirana relacijska baza moći će se mijenjati bez većih problema. Ipak. ta zdrava graĎa znači normaliziranost. Istaknut ćemo vaţnost takve dokumentacije. Adaptacijsko održavanje je potrebno onda kad ţelimo bazu prilagoditi novom DBMS-u koji se nije rabio u vrijeme oblikovanja i početne implementacije. U ovim skriptama. te spomenuti alate koji se pritom obično rabe. 16 PMF – Matematički odsjek .5. Razvojnu dokumentaciju dalje moţemo podijeliti na dokumente koji prate pojedine aktivnosti iz razvojnog ciklusa. U takvom slučaju slijedi opet popravak grešaka. Općenito. 1. 1. na primjer je li brzina odziva zadovoljavajuća. Na primjer. a promjene će se svoditi na povremeno ubacivanje novih podataka u već postojeće relacije ili dodavanje sasvim novih relacija.1. te u samoj bazi. loše performanse mogu biti i posljedica grešaka u oblikovanju. dokumenata i same baze. dakle na dokumente koji nastaju tijekom aktivnosti oblikovanja baze. pa tako i baza podataka popraćen je odgovarajućom dokumentacijom. U slučaju da performanse nisu dovoljno dobre.2. Dokumentacija baze Svaki softverski produkt. greška u analizi moţe uzrokovati da u specifikaciji nedostaje neki vaţni podatak. Održavanje Odrţavanje se odvija u vrijeme kad je baza već ušla u redovitu uporabu. budući da su one zaštićene svojstvima fizičke i logičke nezavisnosti opisanim u Odjeljku 1. Perfekcijsko održavanje je mijenjanje sheme baze u svrhu prilagoĎavanja novim aplikacijama koje nisu postojale tijekom polaznog utvrĎivanja i analize zahtjeva. Naglasimo da je odrţavanje baze nuţnost na koju se treba pripremiti već tijekom njezinog razvoja i uzimati je u obzir tijekom cijelog njezinog ţivota. razlikujemo korisničku dokumentaciju namijenjenu korisnicima i razvojnu dokumentaciju namijenjenu softverskim inţenjerima. na primjer posljedica neuočavanja vaţnih veza izmeĎu odreĎenih vrsta podataka. gdje su baza i njezini prateći dokumenti podvrgnuti stalnim promjenama. Kod relacijskih baza. Da bi promjene tekle što lakše i bezbolnije.

Jedino pod tim uvjetom dokumentacija će ostati relevantna za daljnje odrţavanje. TakoĎer. Ne treba zaboraviti da u razvoju i odrţavanju baze obično sudjeluje veći broj ljudi. Sadrţi fizičku shemu baze. Opisuje konceptualnu shemu baze. ili tako da se u jednom dokumentu biljeţi tko je i kada izvršio kakvu promjenu.2. Dokumentacija na konceptualnoj razini Dokumentacija na logičkoj razini Dokumentacija na fizičkoj razini Slika 1. Odnos izmeĎu ta tri dijela prikazan je na Slici 1. dokumentacija je neophodna tijekom testiranja i kasnijeg odrţavanja baze.3. TakoĎer. netko tko se tek ţeli upoznati s bazom lakše će se snaći u konceptualnoj shemi nego u fizičkoj shemi. te njihovu kolektivnu memoriju.  Projektna dokumentacija na logičkoj razini. Na primjer.  Projektna dokumentacija na konceptualnoj razini. Završni dio projektne dokumentacije je dokumentacija na fizičkoj razini. i zato se dijeli na tri dijela. budući da ona predstavlja jedini relevantni izvor informacija o graĎi baze. Projektna dokumentacija predstavlja sponu izmeĎu svih tih ljudi koji se moţda nikada nisu sreli. To se moţe realizirati tako da se sami dokumenti čuvaju u više verzija. te da osobe koje će kasnije mijenjati bazu nisu one iste osobe koje su je stvorile. Sva tri dijela moraju se čuvati zato jer svaki od njih daje korisnu i komplementarnu informaciju o graĎi baze. dakle konceptualna i logička shema. u slučaju prebacivanja na novi DBMS logička shema moţe predstavljati bolje polazište nego fizička.2: Dijelovi projektne dokumentacije. te konzistentan prelazak iz pojedine razvojne faze ili aktivnosti u drugu.1.skripta 1. Ona se jedina izravno rabi za implementaciju baze.  Projektna dokumentacija na fizičkoj razini. ta promjena mora se unijeti i u dokumentaciju. Projektna dokumentacija za bazu podataka prati sve tri faze oblikovanja. Strelice na toj slici označavaju da svaki prethodni dokument predstavlja polazište za izradu idućeg dokumenta. Zaista. PMF – Matematički odsjek 17 . Kod manjih baza dovoljno je da projektna dokumentacija u svakom trenutku odraţava aţurno stanje. No to ne znači da se dovršetkom fizičke sheme mogu pobrisati prethodni dokumenti. sva tri dijela dokumentacije moraju se istovremeno mijenjati tako da ostanu meĎusobno konzistentni i konzistentni s realiziranom bazom.Baze podataka . Štoviše. osoba koja namjerava izvršiti promjenu u bazi prisiljena je rabiti dokumentaciju da bi ustanovila gdje i što treba promijeniti. pripadna projektna dokumentacija mora se čuvati zbog kasnijeg odrţavanja. Dokumentira logičku shemu baze. Važnost izrade dokumentacije Projektna dokumentacija za bazu podataka vaţna je zato jer ona omogućuje ispravan tijek samog oblikovanja i implementacije u skladu s pravilima struke. Nakon što se baza implementira i uĎe u redovitu uporabu. No kod većih i sloţenijih baza korisno je da se osim aţurnog stanja dokumentira i povijest promjena. Kad god doĎe do promjene u graĎi baze.

uz kojeg stoji više ili manje tekstualnih dopuna. „mjehurići“ i spojnice meĎu njima. a mjehurići atribute. Entitet se tada crta kao pravokutnik s upisanim imenom entiteta na vrhu i upisanim imenima svih atributa u sredini. Riječ je o pojednostavnjenoj vrsti izvornog Chen-ovog dijagrama. odnosno veze. Sljedeće četiri slike prikazuju konceptualnu shemu jedne te iste baze prikazanu na tri načina. atributi. Dokumentacija na fizičkoj razini uvijek je goli ASCII tekst. Riječ je vrlo jednostavnoj bazi koja sadrţi podatke o studentima i predmetima na nekom fakultetu. Rekli smo da dokumentacija na konceptualnoj razini ustvari opisuje konceptualnu shemu baze koja se sastoji od elemenata koji se zovu entiteti. Postoji nekoliko predloţaka za prikaz konceptualne sheme. Prednost ovakvog načina prikazivanja je da je sva informacija prikazana na dijagramu. 18 PMF – Matematički odsjek . Dokumentacija na konceptualnoj razini uglavnom je grafička. Nedostatak je da dijagram moţe postati nepregledan i prenatrpan mjehurićima ukoliko imamo mnogo atributa. Opisat ćemo tri najvaţnija predloška. Nedostatak informacije o atributima na dijagramu nadomještava se tekstom koji prati dijagram. mi ćemo u nastavku ovih skripti rabiti isključivo reducirani Chen-ov dijagram s popratnim tekstom. preostali se mogu smatrati neznatnim varijacijama tih triju. Taj dijagram moţemo upotrijebiti za prikaz konceptualne sheme baze na taj način da entitet interpretiramo kao posebnu vrstu klase koja ima atribute ali nema operacije. Kao grafički elementi pojavljuju se pravokutnici. dakle prvenstveno se oslanja na dijagrame. Dokumentacija na logičkoj razini moţe dijelom biti grafička. I dalje su na dijagramu prisutna imena entiteta i veza. gdje su zbog bolje preglednosti nacrtani samo pravokutnici (entiteti). uporabom opisanih triju obrazaca. Slika 1. rombovi veze. te pamti koji student je upisao koji predmet. Dijagram sadrţi svu potrebnu informaciju.Robert Manger 1. no ipak se više oslanja na tekstualne dijelove koji se oblikuju uporabom bogate tipografije (raznoliki fontovi. svi se oni sastoje od neke vrste dijagrama. Predlošci za izradu dokumentacije Projektna dokumentacija sastoji se od tekstualnih i grafičkih dijelova. nema potrebe za tekstualnim nadopunama. Od tri spomenuta predloška za prikaz konceptualne sheme. a izbačeni su mjehurići (atributi). rombovi (veze) i spojnice meĎu njima.6 daje istu informaciju u obliku UML-ovog class dijagrama. rombovi.  Izvorni Chen-ov dijagram. Class dijagram je jedan od standardnih UML dijagrama i on originalno sluţi za prikaz klasa objekata i veza izmeĎu tih klasa. veza i atributa. Naime.3.3 prikazuje shemu u obliku izvornog Chen-ovog dijagrama. Slika 1. te oznake kardinalnosti veza. te oznake takozvanih kardinalnosti veza. Na Slikama 1.  UML-ov class dijagram. taj predloţak se u praksi pokazuje najspretnijim budući da on predstavlja dobar kompromis izmeĎu izraţajnosti i jednostavnosti.2.4 i 1. Pritom pravokutnici označavaju entitete. Veza (ili asocijacija po UML-ovoj terminologiji) crta se kao spojnica izmeĎu pravokutnika s upisanim imenom na sredini i upisanim oznakama kardinalnosti (ili multipliciteta po UML-ovoj terminologiji) na krajevima.  Reducirani Chen-ov dijagram. U sam dijagram su kao jedini tekstualni elementi ubačena imena entiteta. podcrtavanje i slično).5 vidimo ekvivalentni reducirani Chen-ov dijagram s popratnim tekstom. UML je standardizirani i danas vrlo popularan grafički jezik koji se rabi u objektno-orijentiranim metodama za razvoj softvera.

PMF – Matematički odsjek 19 . STUDENT 0.3: Izvorni Chen-ov dijagram.M PREDMET ŠIFRA PREDMETA NASLOV SEMESTAR ECTSBODOVI Slika 1.Baze podataka .M DATUM UPISA UPISAO OCJENA 1.skripta JMBAG PREZIME IME GODINA STUDIJA STUDENT 0.4: Reducirani Chen-ov dijagram.M UPISAO 1.M PREDMET Slika 1.

SEMESTAR. PREZIME. na primjer podcrtavanje istaknutih atributa koji čine takozvani primarni ključ relacije. te sadrţi ime relacije i imena atributa jedno ispod drugog.  Grafički prikaz relacijske sheme. IME. ECTS-BODOVI. TakoĎer ga rabe neki današnji DBMS-i poput MS SQL Server. koji sadrţi najprije ime relacije.6: UML-ov class dijagram. Poţeljno je unutar redaka rabiti bogatu tipografiju.Robert Manger Tip entiteta STUDENT ima atribute: JMBAG. GODINA STUDIJA Tip entiteta PREDMET ima atribute: ŠIFRA PREDMETA.* UPISAO +DATUM UPISA +OCJENA Slika 1. Veza UPISAO ima atribute: DATUM UPISA.. GraĎa cijele baze prikazana je nizom ovakvih redaka: koliko relacija toliko redaka. Zato se ona takoĎer naziva i relacijska shema. STUDENT +JMBAG +PREZIME +IME +GODINA STUDIJA PREDMET +ŠIFRA PREDMETA +NASLOV +SEMESTAR +ECTS-BODOVI 0. Pojavio se u softverskim paketima za rad s podacima na osobnim računalima poput MS Access. Slika 1. TakoĎer je poţeljno priloţiti takozvani rječnik podataka: popis svih atributa koji se pojavljuju s neformalnim opisom njihovog značenja i tipa vrijednosti koje mogu poprimiti. Što se tiče dokumentacije na logičkoj razini.  Tekstualni prikaz relacijske sheme.5: Popratni tekst uz reducirani Chen-ov dijagram. U slučaju relacijske baze logička shema je skup relacija (tablica) graĎenih od atributa (stupaca). OCJENA. Jedan pravokutnik prikazuje jednu relaciju. rekli smo da ona opisuje logičku shemu baze. Tradicionalno se rabi u knjigama i člancima o relacijskim bazama podataka. GraĎa jedne relacije prikazuje se jednim retkom teksta. NASLOV. dakle one spajaju atribut u jednoj relaciji PMF – Matematički odsjek 20 .* 1. Opisat ćemo dva bitno različita predloška za prikaz relacijske sheme koji su danas najčešće u uporabi.. GraĎa baze opisuje se dijagramom koji se sastoji od pravokutnika i strelica. Strelice označavaju takozvani referencijalni integritet. Ključ je označen odgovarajućom ikonom ili kraticom. a zatim okrugle zagrade unutar kojih su nanizana imena atributa odvojena zarezima.

uporabom opisanih dvaju obrazaca.FK2 JMBAG ŠIFRA PREDMETA DATUM UPISA OCJENA Slika 1. SEMESTAR. STUDENT(JMBAG. NASLOV. mi ćemo u nastavku ovog priručnika dati prednost onom prvom. Uz ovakav dijagram opet je poţeljno priloţiti rječnik podataka. DATUM UPISA. Sljedeće dvije slike prikazuju relacijsku shemu jedne te iste baze prikazanu na dva načina. Riječ je opet o bazi o studentima. vjerujemo da je grafički prikaz unatoč svojoj popularnosti donekle nekorektan sa stanovišta relacijskog modela. ŠIFRA PREDMETA. predmetima i upisima koju smo upoznali na prethodnim slikama. Od dva spomenuta predloška za prikaz relacijske sheme. ECTS-BODOVI ) UPISAO (JMBAG. budući da atribute (stupce) relacija prikazuje kao da su redci.7: Tekstualni prikaz relacijske sheme. U oba slučaja mogli bismo kao nadopunu dodati rječnik podataka koji se nalazi na idućoj Slici 1.8: Grafički prikaz relacijske sheme.8 grafički prikaz. Naime.7 sadrţi tekstualni prikaz relacijske sheme. STUDENT PK JMBAG PREZIME IME GODINA STUDIJA PK PREDMET ŠIFRA PREDMETA NASLOV SEMESTAR ECTS-BODOVI UPISAO PK. PREZIME. IME. GODINA STUDIJA) PREDMET (ŠIFRA PREDMETA.Baze podataka . Slika 1.9.FK1 PK. PMF – Matematički odsjek 21 . OCJENA) Slika 1. dakle tekstualnom prikazu.skripta koji je ujedno ključ u drugoj relaciji. a Slika 1.

sam sadrţaj tog teksta moţe se razlikovati ovisno o DBMS-u. fizička shema zapravo je niz naredbi. Ipak. U skladu s time. no dijelom mogu biti zadane i u nekom dodatnom komandnom jeziku kojeg razumije dotični DBMS.Robert Manger IME PODATKA JMBAG PREZIME IME GODINA STUDIJA ŠIFRA PREDMETA NASLOV SEMESTAR TIP Niz od toĉno 10 znamenki Niz znakova Niz znakova Cijeli broj izmeĊu 1 i 5 Niz od toĉno 5 znamenki Niz znakova „zimski“ ili „ljetni“ OPIS Šifra koja jednoznaĉno odreĊuje studenta Prezime studenta Ime studenta Godina koju je student upisao Šifra koja jednoznaĉno odreĊuje predmet Naslov predmeta Semestar u kojem se predmet predaje Bodovi koje student dobiva ako poloţi predmet Datum kad je odreĊeni student upisao odreĊeni predmet Ocjena koju je odreĊeni student dobio iz odreĊenog predmeta ECTS-BODOVI Mali cijeli broj DATUM UPISA Datum OCJENA Cijeli broj izmeĊu 2 i 5 Slika 1. 22 PMF – Matematički odsjek . U slučaju uporabe DBMS-a zasnovanog na jeziku SQL. jer se svaki DBMS koristi donekle različitom sintaksom SQL-a te raspolaţe drukčijim komandnim jezikom. Te naredbe su u pravilu zapisane u SQL-u. a to je tekst sastavljen od ASCII znakova.9: Rječnik podataka kao prilog relacijskoj shemi. Kao što smo već prije spominjali. projektna dokumentacija na fizičkoj razini sadrţi fizičku shemu baze. postoji samo jedan predloţak za dokumentaciju na fizičkoj razini.

To je zato što ćemo se istim DBMS-om koristiti i za izvoĎenje primjera i vjeţbi.skripta Sljedeća Slika 1. PRIMARY KEY(JMBAG. Podrţano je crtanje svih dijagrama koje ta metoda propisuje.'5').SIFRA_PREDMETA). Riječ je o programskom paketu koji sluţi softverskim inţenjerima za razvoj softvera u skladu s nekom odreĎenom razvojnom metodom. GODINA_STUDIJA ENUM('1'. osnovni alat za izradu te dokumentacije je tekst procesor poput MS Word. za izradu dijagrama koje ćemo umetnuti u tekst potreban nam je dodatni alat. SIFRA_PREDMETA NUMERIC(5) UNSIGNED NOT NULL. OCJENA ENUM('2'. te je prilagoĎena objektno-orijentiranim metodama razvoja softvera.  Specijalizirani CASE alat. Uporaba CASE alata i drugih vrsta softvera Budući da je projektna dokumentacija u osnovi tekstualni dokument s umetnutim dijagramima.'2'.'L'). U skladu s time. te je automatizirana izrada odgovarajuće razvojne dokumentacije. DATUM_UPISA DATE. CREATE TABLE STUDENT (JMBAG NUMERIC(10) UNSIGNED NOT NULL. Većina današnjih CASE alata daje podršku za aktivnosti analize zahtjeva i oblikovanja. INDEX R_JMBAG_IND (JMBAG). IME CHAR(20). gotovo sve fizičke sheme i naredbe u SQL-u pisat ćemo u skladu sa sintaksom kojom se koristi MySQL.3. SEMESTAR ENUM('Z'. PRIMARY KEY(JMBAG)) ENGINE=INNODB.10 prikazuje fizičku shemu naše baze o studentima. CREATE TABLE PREDMET (SIFRA_PREDMETA NUMERIC(5) UNSIGNED NOT NULL.'5'). INDEX R_SP_IND (SIFRA_PREDMETA).Baze podataka . PRIMARY KEY(SIFRA_PREDMETA)) ENGINE=INNODB. takvi CASE alati prvenstveno omogućuju PMF – Matematički odsjek 23 .'3'.'4'. PREZIME CHAR(20).10: Fizička shema zapisana u jeziku SQL. 1. U slučaju nekog drugog DBMS-a naredbe bi se donekle razlikovale. Slika 1. NASLOV CHAR(80). Koristi se inačica sintakse SQL-a iz DBMS-a MySQL. Ipak. FOREIGN KEY (JMBAG) REFERENCES STUDENT(JMBAG).'4'. ECTS_BODOVI NUMERIC(2) UNSIGNED. U nastavku ovog priručnika.'3'. i on se moţe odabrati na dva načina. CREATE TABLE UPISAO (JMBAG NUMERIC(10) UNSIGNED NOT NULL.3. FOREIGN KEY (SIFRA_PREDMETA) REFERENCES PREDMET(SIFRA_PREDMETA)) ENGINE=INNODB. predmetima i upisima.

Imate li kakvo objašnjenje? Zadatak 1. Opišite što bi se sve loše moglo desiti kad bi više korisnika nekontrolirano pristupalo istim podacima u isto vrijeme. zaključujemo da su CASE alati pogodniji za veće projekte na kojima rade iskusniji projektanti.Robert Manger crtanje UML dijagrama. Zato on moţe korisniku ispravljati greške kod crtanja. Kako to da od 90-tih godina 20.4. Osim svih standardnih UML dijagrama. zahtijeva više vremena za savladavanje. na primjer na osnovu grafičkog prikaza relacijske sheme oni mogu automatski generirati naredbe u SQL-u za stvaranje tablica. Zato nam on ne moţe baš u velikoj mjeri kontrolirati ili automatizirati posao oblikovanja. na koji način DBMS obavlja oporavak baze? Kojim se pomoćnim strukturama podataka on pritom koristi? PMF – Matematički odsjek 24 . koji sadrţi razne grafičke predloške bez obzira na njihovo značenje. Neki od takvih paketa imaju uključene i elemente koji se pojavljuju na dijagramima vezanim uz baze podataka. te košta više novaca. Što mislite. a manje pogodnim u drugim. Općeniti alat za crtanje dijagrama. Java ili C# istisnuli klasične programske jezike poput C ili COBOL.  Obje spomenute vrste softvera imaju svoje prednosti i nedostatke. Kao primjer kvalitetnog CASE alata koji je pogodan za oblikovanje baza podataka navodimo Visual Paradigm.  Prednost općenitog alata za crtanje je da on ima jednostavno sučelje poput uobičajenih uredskih paketa. taj paket podrţava i crtanje jedne inačice Chen-ovih dijagrama za konceptualnu shemu baze podataka. Riječ je o paketu opće namjene za crtanje raznih vrsta dijagrama.  Prednost CASE alata je da on „razumije“ sintaksu i semantiku dijagrama. dijagrami koje oni proizvode mogu biti zapisani u standardnim grafičkim formatima. Zadatak 1. te takoĎer i elementi poput pravokutnika. stoljeća do danas objektne baze podataka nisu uspjele istisnuti iz uporabe relacijske baze? Pritom su u istom razdoblju objektno-orijentirani programski jezici poput C++. bolji CASE alati nastoje automatizirati dio projektantskog posla. općeniti alati za crtanje bolji su za male projekte i osobe koje se samo povremeno bave bazama podataka. TakoĎer. tako da se lako mogu uklopiti u druge dokumente. što ih čini pogodnijim u jednim situacijama. TakoĎer. Kao primjer općenitog alata za crtanje dijagrama koji je pogodan za naše svrhe navodimo MS Visio.  Nedostatak općenitog alata za crtanje je da on samo editor slika koji ne razumije smisao dijagrama za baze podataka. Objasnite zašto se mogućnost oporavka baze nakon kvara ističe kao vaţan cilj kojeg bi tehnologija baza podataka trebala ostvariti. Objasnite zašto se mogućnost istovremenog rada više korisnika s istim podacima ističe kao poseban cilj kojeg bi tehnologija baza podataka trebala ostvariti. Uzevši u obzir nabrojane prednosti i mane. S druge strane.2. 1.  Nedostatak CASE alata je da je on kompliciraniji.1. U njemu već postoje predlošci za većinu UML dijagrama i za grafički prikaz logičke sheme baze podataka. mjehurića u rombova koji mogu posluţiti za sastavljanje Chen-ovih dijagrama. a neki imaju uključene i dodatne dijagrame koji su specifični za oblikovanje baze podataka. Zadaci za vježbu Zadatak 1.3. pa se korisnici ne moraju posebno pripremati da bi radili s njime.

4. Koji alat vam se čini spretniji? Jeste li uočili neke prednosti ili mane jednog alata u odnosu na drugi? Zadatak 1.Baze podataka .5. Pod pretpostavkom da znate programirati. IME. sluţeći se najprije alatom MS Paint.6. GODINA_STUDIJA) izravno pohranjuje u datoteku. napišite program u COBOL-u ili C-u koji podatke o studentima (JMBAG. te ih odatle moţe i pročitati.6 (UML class dijagram). Zadatak 1. Precrtajte Sliku 1. Napišite specifikaciju za neku jednostavniju bazu podataka iz vašeg područja interesa. PREZIME. PMF – Matematički odsjek 25 .skripta Zadatak 1. a zatim MS Visio. Jamči li takav način pohranjivanja podataka fizičku odnosno logičku nezavisnost podataka? Obrazloţite odgovor.

Robert Manger 26 PMF – Matematički odsjek .

STUDENT. a to je konceptualno oblikovanje. te koje daljnje informacije joj treba dodati tijekom te pretvorbe. na primjer: KUĆA. Na primjer za entitet AUTO mogli bismo uvesti atribut MODEL tog auta. SERVISIRANJE AUTA. atributi. GODINA STUDIJA. IME. atributi STUDENTA su JMBAG (jedinstveni matični broj akademskog graĎanina). AUTO. NASLOV.skripta 2. Entitet je opisan atributima. Moglo bi se reći da ta shema zapravo u prvom redu opisuje stvarni svijet o kojem ţelimo biljeţiti podatke. bića. nešto što je u stanju postojati ili ne postojati. pojave ili dogaĎaji koji su nam od interesa. to ne umanjuje njezinu uporabljivost. SEMESTAR u kojem se predaje.1. u prvom redu zato što joj nedostaju brojni detalji. Ukoliko neki atribut i sam zahtijeva svoje atribute. veza i atributa.Baze podataka . …. ECTS-BODOVI koji odreĎuju njegovu teţinu. atributi KUĆE su: ULICA. PREZIME. Entitet moţe biti stvar ili biće. uključili sve potrebne podatke. …. …. Konceptualna shema ne moţe se automatski implementirati pomoću današnjih DBMS-a. Entiteti.1. Entiteti i njihovi atributi Entitet je nešto o čemu ţelimo spremati podatke. …. BROJ KATOVA. odnosno dogaĎaj ili pojava. na primjer KATEGORIJA kojoj taj model PMF – Matematički odsjek 27 . te se moţe identificirati. na primjer: NOGOMETNA UTAKMICA.1. NASTAVNIK. Konceptualna shema daje zoran i jezgrovit prikaz baze koji je osloboĎen tehničkih detalja. a tek onda na posredan način i samu bazu. sastavljenu od entiteta. U toj komunikaciji korisnici nastoje utvrditi jesu li projektanti prepoznali sve poslovne procese. U nastavku ćemo podrobnije opisati sva tri pojma. veze Modeliranje entiteta i veza zahtijeva da svijet promatramo preko tri kategorije:  entiteti: stvari. FAKULTET. Glavni cilj te faze je stvoriti konceptualnu shemu baze. BOJA FASADE. Ipak. POLAGANJE ISPITA. a atributi PREDMETA koji se predaje na fakultetu su ŠIFRA PREDMETA. Konceptualno oblikovanje baze podataka U ovom poglavlju opisujemo prvu fazu oblikovanja baze podataka. te ispravno shvatili odnose meĎu tim podacima. Na primjer. tada ga radije treba smatrati novim entitetom. U skladu s poslovicom da slika govori tisuću riječi. . 2. PREDMET (na fakultetu). te da ona moţe sluţiti kao sredstvo za komunikaciju projektanata i korisnika. Vaţno svojstvo konceptualne sheme je da je ona razumljiva ljudima svih struka. No ako za opis MODELA trebamo dodatne atribute. KUĆNI BROJ.  atributi: svojstva entiteta ili veza koja su nam od interesa. …. budući da postoje jasna pravila koja kaţu kako se ona dalje pretvara u relacijsku shemu.  veze: odnosi meĎu entitetima koji su nam od interesa. opis se najviše oslanja na dijagrame. 2.

2. IME. PREZIME. atribut KVAR je zapravo lista vrijednosti. od kojih je svaki opisan donekle drukčijim vrijednostima atributa. jer se na jednom servisiranju moţe popraviti više kvarova. a niz KVAROVA popravljenih na istom SERVISIRANJU AUTA dobiva se uspostavljanjem veze izmeĎu tih dvaju entiteta. no zato kombinacija atributa REGISTARSKA OZNAKA (auta na servisu) i DATUM (kad je servisiranje obavljeno) predstavlja kandidat za ključ. Za zadani tip entiteta moţe postojati cijeli skup primjeraka (pojava) entiteta tog tipa. Razlika izmeĎu tipa i primjerka entiteta slična je razlici izmeĎu općeg i posebnog broja u matematici. Dopušta se da dva entiteta imaju atribute s istim imenom. OIB i JMBG. no tada se podrazumijeva da su to ustvari atributi s istim značenjem i istim tipom vrijednosti. TakoĎer. Isto pravilo vrijedi i ako atribut moţe istovremeno poprimiti više vrijednosti. tada MODEL moramo smatrati entitetom. Kandidat za ključ je atribut. Od ponuĎenih kandidata za ključ za STUDENTA. koje su najjednostavnije i najčešće u primjenama. STUDENT je tip čiji primjerci su konkretni studenti Petar Petrović. …. 2. Ukoliko jedan tip entiteta ima više kandidata za ključ. Veze i njihovi atributi Uspostavljanjem veze izmeĎu dvaju ili više entiteta izraţavamo činjenicu da se ti entiteti nalaze u nekom odnosu. za entitet SERVISIRANJE AUTA. GODINU STUDIJA. Dragica Horvat. zato što je on uvrijeţen u akademskoj zajednici. Na primjer. GODINA kad se taj model pojavio na trţištu. dobri kandidati za ključ su JMBAG. kao primarni ključ moţemo odabrati JMBAG. ili skup atributa. Binarna veza uspostavlja se izmeĎu točno dva tipa entiteta. 28 PMF – Matematički odsjek . oba entiteta STUDENT i NASTAVNIK mogu imati atribut PREZIME. svi atributi koji opisuju isti entitet moraju imati različita imena. no realizira se povezivanjem pojedinih primjeraka entiteta dotičnih tipova. Ime entiteta zajedno sa pripadnim popisom atributa zapravo odreĎuje tip entiteta. Odabir primarnog ključa vaţna je odluka koja povlači konkretne posljedice kod kasnije implementacije baze. Marko Marković. Na primjer. ne mogu postojati dva različita primjerka entiteta istog tipa s istim vrijednostima kandidata za ključ. Stanje binarne veze opisuje se kao skup ureĎenih parova primjeraka entiteta koji su trenutno povezani. tada biramo jednog od njih koji nam se čini najpogodnijim da sluţi za identifikaciju. zato jer je to atribut koji opisuje bilo koju osobu bez obzira je li ona student ili nastavnik. Tada opet KVAR moramo smatrati entitetom. za tip entiteta AUTO.Robert Manger pripada. Unutar jedne konceptualne sheme. Dakle. Za sada ćemo se ograničiti na takozvane binarne veze. za tip entiteta STUDENT. ili razlici izmeĎu klase i objekta u objektno-orijentiranim programskim jezicima. Za tip entiteta SERVISIRANJE AUTA teško je naći jedan atribut koji bi jednoznačno odreĎivao primjerak tog entiteta. a odnos izmeĎu AUTA i njegovog MODELA trebamo tumačiti kao vezu izmeĎu dva entiteta. tipovi entiteta moraju imati različita imena. U običnom ţivotu sluţimo se i kombinacijom atributa PREZIME i IME. Svaki od tih konkretnih studenata ima drukčiju kombinaciju vrijednosti za JMBAG. no strogo govoreći ta kombinacija nije pouzdan kandidat za ključ jer se lako moţe desiti da dva studenta imaju isto ime i prezime. Na primjer. Na primjer. kandidat za ključ je atribut REGISTARSKA OZNAKA. čije vrijednosti jednoznačno odreĎuju primjerak entiteta zadanog tipa.1. te ga proglašavamo primarnim ključem. Veza se uvijek definira na razini tipova entiteta. Na primjer.

PMF – Matematički odsjek 29 . moţe se desiti da Marko Marković dodatno upiše Matematičku analizu. Njome se izraţava činjenica da studenti upisuju izborne predmete na fakultetu. koje moţemo razlikovati na osnovu NASLOVA. studentica Dragica Horvat je upisala tri predmeta: Linearnu algebru. veza UPISAO moţe imati atribut DATUM UPISA. TakoĎer vidimo da postoji 5 primjeraka entiteta PREDMET. dakle mogu se pojaviti novi parovi. Na primjer. STUDENT UPISAO PREDMET Marko Marković Baze podataka Linearna algebra Petar Petrović Matematiĉka analiza Dragica Horvat Programiranje u C-u Marija Janković Analitiĉka geometrija Slika 2. a nestati postojeći. Zaista. U svakom trenutku. za koje smo zbog jednostavnosti pretpostavili da ih moţemo razlikovati na osnovu IMENA i PREZIMENA. Spojnice na slici prikazuju parove povezanih primjeraka entiteta.skripta Kao primjer. dakle atribute koje ne moţemo pripisati ni jednom od tih tipova. a Marija Janković je upisala Analitičku geometriju 5. veza moţe imati i svoje atribute. DATUM UPISA ne moţemo smatrati atributom entiteta STUDENT zato jer isti student moţe upisati razne predmete na razne datume. predmet Matematička analiza nije upisao nitko od studenata. Na primjer. rujna 2010. promatramo binarnu vezu UPISAO izmeĎu tipova entiteta STUDENT i PREDMET. rujna 2010. gdje svaki pojedini par označava da je dotični student upisao dotični predmet. DATUM UPISA ne moţe biti ni atribut od PREDMET jer isti predmet moţe biti upisan od raznih studenata na razne datume. Na primjer. Stanje veze moţe se vremenom mijenjati.Baze podataka . moţemo zabiljeţiti da je Marko Marković upisao Linearnu algebru 3. Slično.1: Stanje veze. Osim što povezuje tipove entiteta. Dakle. parovi povezanih primjeraka entiteta. U jednom trenutku. Vidimo da postoje 4 primjerka entiteta STUDENT. stanje veze UPISAO moţe izgledati kao na Slici 2.1. Konkretna vrijednost DATUMA UPISA zapravo se pridruţuje uz konkretni par primjeraka za STUDENT i PREDMET koji su povezani. student Marko Marković je upisao predmet Linearna algebra. stanje veze prikazuje se kao skup parova primjeraka tih entiteta. Programiranje u C-u i Analitičku geometriju. a da Petar Petrović odustane od Baza podataka.

1. OZNAKA NAZIV OPIS 1:1 Jedan primjerak od E1 moţe biti povezan najviše s Jedanjednim primjerkom od E2. TakoĎer. 1:M M:1 M:M Tabela 2. jedan napramaprimjerak od E2 moţe biti povezan s više jedan primjeraka od E1. Zaista. Funkcionalnost te veze je svojstvo koje kaţe je li za odabrani primjerak entiteta jednog tipa moguće jednoznačno odrediti povezani primjerak entiteta drugog tipa.Robert Manger Slično kao tipovi entiteta. TakoĎer. Poznavanje tih svojstava vaţno je da bi se veza u idućoj fazi oblikovanja ispravno prikazala unutar relacijske sheme. jedan primjerak napramaod E2 moţe biti povezan najviše s jednim jedan primjerkom od E1. svi atributi koji pripadaju istoj vezi moraju imati različita imena.3. a jedan predmet moţe biti upisan od više studenata. makar se ona mogu primijeniti i u općenitijem slučaju.primjeraka od E2. Jedan primjerak od E1 moţe biti povezan najviše s Mnogojednim primjerkom od E2. Drugim riječima. Mi ćemo navedena svojstva za sada definirati samo za slučaj binarne veze. jedan student moţe upisati više predmeta. obaveznost članstva. obaveznosti članstva. jedan primjerak od E2 mnogo moţe biti povezan s više primjeraka od E1. S obzirom da se ista veza moţe promatrati u dva smjera.1: Vrste funkcionalnosti za vezu izmeĎu tipova entiteta E1 i E2. kardinalnost Načini na koji veza moţe povezati primjerke entiteta odreĎeni su svojstvima funkcionalnosti.1. Istovremeno. 30 PMF – Matematički odsjek . Opet se dopušta da dvije veze ili entitet i veza imaju atribute s istim imenom. Promatramo vezu izmeĎu tipova entiteta E1 i E2. postoje 4 vrste funkcionalnosti koje su opisane u Tabeli 2. TakoĎer. i veze unutar iste sheme moraju imati različita imena. Jedan primjerak od E1 moţe biti povezan s više Jedanprimjeraka od E2. jedan primjerak od napramaE2 moţe biti povezan najviše s jednim primjerkom mnogo od E1. 2. To se lijepo vidi na Slici 2. Funkcionalnost veze. MnogoJedan primjerak od E1 moţe biti povezan s više naprama. odnosno kardinalnosti. Prije spomenuta veza UPISAO izmeĎu tipova entiteta STUDENT i PREDMET ima funkcionalnost M:M. Istovremeno. funkcionalnost je svojstvo koje kaţe moţe li se veza interpretirati kao preslikavanje (funkcija) iz skupa primjeraka entiteta jednog tipa u skup primjeraka entiteta drugog tipa.1. no tada se podrazumijeva da su to ustvari atributi s istim značenjem i istim tipom vrijednosti. od E1 do E2 i obratno.

Baze podataka . dakle traţimo da svaki zavod u svakom trenutku ima svog pročelnika. PMF – Matematički odsjek 31 .3. tip entiteta NASTAVNIK nema obavezno članstvo jer ne mora svaki nastavnik obavljati duţnost pročelnika.2: Veza s funkcionalnošću M:1. Zaista. U prije spomenutoj vezi JE PROĈELNIK. svaki nastavnik pripada samo jednom zavodu. NASTAVNIK Georg Cantor Kurt Goedel ZAVOD PRIPADA Edgar Codd Zavod za matematiku Felix Klein Zavod za raĉunarstvo Blaise Pascal Alan Turing Slika 2.skripta Kao primjer za funkcionalnost M:1 navodimo vezu PRIPADA izmeĎu tipova entiteta NASTAVNIK i ZAVOD (organizacijska jedinica unutar fakulteta). Kao primjer za funkcionalnost 1:1 navodimo vezu JE PROĈELNIK izmeĎu tipova entiteta NASTAVNIK i ZAVOD. S druge strane.2. Kaţemo da E1 ima obavezno članstvo u toj vezi ako svaki primjerak od E1 mora sudjelovati u vezi. Slika 2.3 prikazuje jedno stanje te veze. Jedno stanje veze ilustrirano je Slikom 2. a jedan zavod moţe imati samo jednog pročelnika. Ista veza ako se gleda u suprotnom smjeru moţe sluţiti kao primjer za funkcionalnost 1:M. To se opet vidi na Slici 2. Zbog jednostavnosti smo pretpostavili da nastavnike moţemo razlikovati na osnovu imena i prezimena. Jedan nastavnik moţe biti pročelnik najviše jednog zavoda (onog kojem inače pripada). moţemo zahtijevati da ZAVOD ima obavezno članstvo. no jedan zavod moţe zapošljavati mnogo nastavnika. Analogno se definira i obaveznost članstva za E2. Opet promatramo vezu izmeĎu tipova entiteta E1 i E2. dakle mora biti povezan barem s jednim primjerkom od E2.

Kardinalnost te veze u smjeru od E1 do E2 definira se kao broj primjeraka od E2 koji istovremeno mogu biti povezani s odabranim primjerkom od E1. Kardinalnost u smjeru od E2 do E1 definira se analogno. Jedan primjerak od E1 mora biti povezan s najmanje jednim.2: Kardinalnost veze promatrane u smjeru od tipa E1 do tipa E2.M Jedan primjerak od E1 moţe biti povezan s nijednim ili najviše s jednim primjerkom od E2. no moţda i s više primjeraka od E2.3: Veza s funkcionalnošću 1:1. I dalje promatramo vezu izmeĎu tipova entiteta E1 i E2. te se odvajaju zarezom. Jedan primjerak od E1 mora biti povezan s točno jednim primjerkom od E2. Jedan primjerak od E1 moţe biti povezan s nijednim.M 1. s jednim ili s više primjeraka od E2. Svojstva funkcionalnosti i obaveznosti članstva mogu se otprilike izraziti samo jednim svojstvom koje se zove kardinalnost. To znači da za svaku vezu utvrĎujemo dvije kardinalnosti.1 1.1 0. pa umjesto točnog broja navodimo interval u obliku donje i gornje granice. 1 ili M. Tabela 2. Uobičajene kardinalnosti navedene su i opisane u Tabeli 2. Kardinalnost je obično nemoguće sasvim točno izraziti.Robert Manger NASTAVNIK Georg Cantor Kurt Goedel ZAVOD JE PROĈELNIK Zavod za matematiku Edgar Codd Felix Klein Zavod za raĉunarstvo Blaise Pascal Alan Turing Slika 2. Dvije granice označavaju se oznakama 0. 32 PMF – Matematički odsjek .2. OZNAKA OPIS 0. za jedan i za drugi smjer.

osobu ili pojavu? Ako da. U pravilu. tada bilo koji primjerak od E1 mora biti povezan barem s jednim primjerkom od E2 pa je članstvo obavezno. Dilema se rješava odgovaranjem na sljedeća pitanja. Na projektantu je da odluči što je vaţno a što se moţe ispustiti. ako je donja granica 1 ili više.3.2. objekti) i glagoli (predikati). Opis koraka treba shvatiti uvjetno.M. Veza UPISAO u smjeru od PREDMET do STUDENT ima kardinalnost 0. čime traţimo od svakog studenta da upiše bar jedan predmet. Naravno. navedimo da veza JE PROĈELNIK promatrana u smjeru od NASTAVNIK do ZAVOD ima kardinalnost 0. Analiziraju se rečenice iz specifikacije i uočavaju imenice (subjekti.  Inače. onda je to opet entitet. te drugi dio funkcionalnosti. onda je to entitet. Očito je da kod binarnih veza donja granica za kardinalnost u smjeru od E1 do E2 zapravo odreĎuje obaveznost članstva za E1. Oblikovanje konceptualne sheme Nakon što smo se u prethodnom potpoglavlju upoznali s elementima konceptualne sheme. U oblikovanju uvijek ostaje mjesta za dosjetljivost.M jer dopuštamo da neki predmeti ostanu neupisani. Zaista. Dakle pokušavamo opisati korake kojima se na osnovu specifikacije dolazi do projektne dokumentacije na konceptualnoj razini.skripta Kao primjer. u ovom potpoglavlju bavimo se samim postupkom oblikovanja te sheme.1. No mogli bismo zahtijevati da kardinalnost iste veze u suprotnom smjeru bude 1. Kardinalnost iste veze promatrane u suprotnom smjeru je 1. pa je članstvo neobavezno.  Imenice upućuju na entitete i atribute.  Inače je taj pojam atribut.Baze podataka . Gledanjem kardinalnosti iste veze ali u smjeru od E2 do E1 otkrivamo obaveznost članstva za E2. gornja granica za kardinalnost u smjeru od E1 od E2 odreĎuje jedan dio funkcionalnosti veze. svojstvo kardinalnosti kod binarnih veza moţe sluţiti kao zamjena za svojstva funkcionalnosti i obaveznosti članstva. PMF – Matematički odsjek 33 . Kod veza koje nisu binarne stvar se ipak komplicira i korisno je navoditi sva tri svojstva.1 i 2. elementi sheme trebaju se prepoznati čitanjem specifikacije. je li taj pojam svojstvo koje moţe poprimiti više vrijednosti kad njime opisujemo neki predmet.1. veze i atributi. S druge strane. Otkrivanje entiteta.  Glagoli upućuju na veze. ako je ta donja granica 0. projektant se često susreće s dilemom treba li neku značajnu imenicu iz specifikacije shvatiti kao entitet ili kao atribut.1. veza i atributa Prvi korak u oblikovanju konceptualne sheme je otkrivanje samih elemenata od kojih se ta shema sastoji. ne mora svaka riječ iz specifikacije predstavljati element sheme. improvizaciju i kreativnost. 2. 2. Sve se ovo moţe provjeriti na slikama 2.  Ima li pojam označen imenicom neka svoja dodatna svojstva koja treba pamtiti? Ako da. a to su entiteti.2. onda primjerak od E1 ne mora biti povezan ni s jednim primjerkom od E2. Slično. naime treba biti svjestan da se postupak oblikovanja ne moţe do kraja opisati ni definirati. U tom smislu. U prepoznavanju elemenata sheme.

 Veze su: UPISAO izmeĎu STUDENT i PREDMET. NASTAVNIK. ZAVOD. Da bismo imali pouzdani primarni ključ. makar se u ovoj fazi još ne zahtijeva da taj tip bude točno odreĎen. Poţeljno je da za svaki atribut imamo neku pribliţnu predodţbu o tipu vrijednosti koje on moţe poprimiti. tako da zbroj njihovih ECTS-bodova u svakom semestru bude barem 30. 34 PMF – Matematički odsjek . no zdrav razum nam kaţe da treba dodati i PREZIME i IME.  Tipovi entiteta su: STUDENT. kao primarni ključ dodajemo umjetni atribut ŠIFRA PREDMETA. Predmeti moraju biti izabrani najkasnije do 15.  Atributi su: (studentova) GODINA STUDIJA. U tom slučaju projektant treba dodatno razgovarati s korisnicima da bi otklonio nejasnoće.  ZAVOD za sada nema atributa. PREDMET. te BROJ SOBE (u kojoj ima ured i gdje ga studenti mogu naći). projektant moţe po vlastitom nahoĎenju dodavati umjetne atribute koji sluţe za identifikaciju ili klasifikaciju (šifre. za svaki entitet treba odabrati primarni ključ. veze i atribute. SEMESTAR (kad se predmet predaje).  NASTAVNIK za sada ima atribut PLAĆA. PREDAJE izmeĎu NASTAVNIK i PREDMET. Pritom svaki predmet ima samo jednog nastavnika. Dodajemo IME ZAVODA koje je ujedno i primarni ključ. Pritom biraju neke od ponuĎenih izbornih predmeta. te OPIS DJELATNOSTI. OIB moţe posluţiti kao primarni ključ. Analizom ovih rečenica otkrivamo sljedeće entitete. potrebno je za svaki entitet utvrditi koji atributi ga opisuju. Da bi bolje upravljao ljudskim resursima. TakoĎer.  Veza UPISAO ima atribute DATUM UPISA i OCJENA. rujna. Na kraju akademske godine fakultet pohvaljuje studente koji su postigli najbolje ocjene iz upisanih predmeta. Svake akademske godine zavod nudi nekoliko izbornih predmeta za studente i osigurava nastavnike koji će predavati te predmete. Svaki nastavnik je član točno jednog zavoda. No opet je prirodno da dodamo NASLOV. Fakultet je organiziran u zavode. Dalje za svaki tip entiteta ili vezu treba utvrditi pripadni popis atributa. a ne pojedinim entitetima. TakoĎer. Kao primjer. Očito. Po vlastitom nahoĎenju dodajemo OIB. Ostale veze nemaju atributa. pročelnik zavoda moţe mijenjati plaće svojih nastavnika. Dalje. veza i atributa moţe zapeti ukoliko je specifikacija nejasna ili nepotpuna. PREZIME.Robert Manger Nakon što smo otkrili entitete.  PREDMET na osnovu utvrĎenog ima atribute SEMESTAR i ECTS-BODOVI. dodajemo još i JMBAG. Postupak otkrivanja entiteta. oznake. te kardinalnosti. TakoĎer. OCJENA (koju je student dobio iz predmeta). … ). IME. ili atribute za koje je očito da nedostaju. DATUM UPISA (kad je student izabrao i upisao predmet). Ne treba zaboraviti mogućnost da neki atributi pripadaju vezi izmeĎu entiteta. JE PROĈELNIK izmeĎu NASTAVNIK i ZAVOD. ECTS-BODOVI (za predmet). veze i atribute. NUDI izmeĎu ZAVOD i PREDMET. Nastavnici iz istog zavoda izmeĎu sebe biraju pročelnika. U specifikaciji pišu sljedeće rečenice. PRIPADA izmeĎu NASTAVNIK i ZAVOD. zamislimo da trebamo oblikovati konceptualnu shemu baze podataka fakulteta. Jedna od zadaća zavoda je da se brine o nastavi. za svaku vezu treba odrediti njezinu funkcionalnost.  Jasno je da STUDENT ima atribut GODINA STUDIJA. Studenti svake akademske godine upisuju godinu studija. obaveznosti članstva.

netočna kardinalnost i slično. sve dok se ne doĎe do dijagrama na kojeg korisnici više nemaju primjedbi. Isto tako. Nakon što je nacrtao dijagram.M. a ne vidi se tko je bio prethodni pročelnik.4. Ako postoje propusti. Uz spojnice su takoĎer upisane oznake kardinalnosti veze. Ipak. idući korak u oblikovanju konceptualne shema je da se ti elementi poveţu i prikaţu u obliku dijagrama. Riječ je o prikazu konceptualne sheme za bazu podataka o fakultetu.skripta Dalje za svaku vezu odreĎujemo njezinu kardinalnost u jednom i u drugom smjeru.1. Primijetimo da reducirani Chen-ov dijagram kakvim se mi koristimo opisuje samo entitete i veze. gdje su tipovi entiteta nacrtani kao pravokutnici. Imena tipova entiteta odnosno veza upisana su u odgovarajuće pravokutnike odnosno rombove.2. projektant se vraća na korak otkrivanja veza i atributa. a ne vidi se što je imao upisano prošle godine. i to tako da kardinalnost u smjeru od jednog do drugog tipa entiteta piše bliţe drugom tipu. a obratno je 1. krivo postavljena veza. veze i atribute. Dakle za studenta se biljeţi koje predmete je on upisao ove akademske godine.  JE PROĈELNIK u smjeru od NASTAVNIK do ZAVOD je 0. a veze kao rombovi. ponovo crta dijagram i opet ga pokazuje korisnicima. te da se nedostajuća informacija mora dostaviti u tekstu koji prati dijagram. time je odmah odreĎena i njihova funkcionalnost. Primijetimo da ova jednostavna shema opisuje samo trenutno stanje na našem fakultetu. dakle nedostatak nekog entiteta ili veze.Baze podataka .1. projektant svoj crteţ svakako treba pokazati korisnicima. Na taj način lagano se pronalaze eventualni propusti u konceptualnoj shemi. Ciklus oblikovanja konceptualne sheme moţe se iterirati više puta.  UPISAO u smjeru od STUDENT do PREDMET ima kardinalnost 1. a obratno je 1.M. Ovo ispuštanje informacija radi se zato da bi dijagram bio jednostavan i pregledan. atributa obično ima mnogo. a ne sadrţi informacije o atributima. te obaveznost članstva entiteta u njima. Sluţimo se reduciranim Chenovim dijagramom.1. odgovarajući romb je povezan spojnicama s odgovarajućim pravokutnicima.M. te ga treba analizirati zajedno s njima. a u obratnom smjeru 0. PMF – Matematički odsjek 35 . a ne pamti „povijest“. Budući da su sve naše veze binarne.  NUDI u smjeru od ZAVOD do PREDMET je 0.1. to znači da konceptualna shema nije u potpunosti opisana samim dijagramom. a obratno je 1. a obratno je 1.  PRIPADA u smjeru od NASTAVNIK do ZAVOD je 1.M. za zavod se biljeţi tko je njegov sadašnji pročelnik. 2. Da bi se znalo izmeĎu kojih tipova entiteta je uspostavljena odreĎena veza. Naime.  PREDAJE u smjeru od NASTAVNIK do PREDMET je 0. Crtanje dijagrama Nakon što smo otkrili sve entitete.2.M. čije elemente smo otkrili u prethodnom odjeljku. Primjer dijagrama nacrtanog prema navedenim pravilima vidi se na Slici 2. i tako dalje. Baza koja bi pamtila povijest dogaĎaja imala bi sloţeniju shemu.1. pa bi njihovo ucrtavanje stvorilo veliku guţvu.

36 PMF – Matematički odsjek .5. za svaki tip entiteta podvlačenjem označavamo primarni ključ.1 NUDI JE PROĈELNIK PRIPADA 0. tekst koji prati dijagram sa Slike 2. Osim ovih najnuţnijih informacija. zašto je pretpostavio da neka veza ima baš neku odreĎenu kardinalnost.M STUDENT Slika 2. na primjer projektantovo objašnjenje zašto je uveo neki atribut kojeg nije bilo u specifikaciji.M PREDAJE 1.4: Dijagram s entitetima i vezama za bazu podataka o fakultetu.1 1. Znači za svaki entitet i vezu navodimo sve atribute. U prvom redu. zašto je odabrao primarni ključ na odreĎeni način.1 1. tu mora biti uključen popis atributa za svaki tip entiteta i svaku vezu.4 mogao bi izgledati kao što je prikazano na Slici 2.M UPISAO 0.Robert Manger ZAVOD 1. Sastavljanje teksta koji prati dijagram Zadnji korak u oblikovanju konceptualne sheme je sastavljanje teksta koji prati dijagram.2.3.M PREDMET 0. tekst koji prati dijagram moţe po potrebi uključiti i dodatne sadrţaje. 2.M 1. Za naš primjer baze podataka o fakultetu.1 NASTAVNIK 1. i tako dalje.1 0. Taj tekst treba dati one informacije o konceptualnoj shemi koje se ne vide na samom dijagramu. TakoĎer.

GODINA STUDIJA. No postoje situacije kad nam binarne veze nisu dovoljne. ako se atribut zove PREZIME. i tako dalje. U nastavku ćemo opisati tri vrste sloţenijih veza. 2. Slika 2.5: Popratni tekst uz dijagram sa Slike 2. OPIS DJELATNOSTI. te ćemo objasniti pravila za njihovo crtanje na dijagramima. Ipak. BROJ SOBE. 2. u tekst moţemo uključiti i neku vrstu rječnika podataka. PREZIME. gdje je za svaki atribut otprilike objašnjeno što on znači i koji tip vrijednosti on moţe poprimiti. Tip entiteta ZAVOD ima atribute: IME ZAVODA. Ako to ţelimo. Ostale veze nemaju atribute. Tip entiteta NASTAVNIK ima atribute: OIB. PLAĆA. Funkcionalnost takve veze opet moţe biti 1:1. onda je to očito podatak koji sluţi a identifikaciju predmeta i vjerojatno izgleda kao kombinacija znakova s propisanom duljinom i obrascem. onda bi to trebao biti cijeli broj.3.1. Složenije veze U dosadašnjim primjerima pojavljivale su se samo binarne veze. ECTS-BODOVI. 1:M. dakle takve koje povezuju dva različita tipa entiteta. Njezino stanje opisuje se kao skup ureĎenih parova primjeraka entiteta istog tipa koji su povezani. Veza UPISAO ima atribute: DATUM UPISA.4. NASLOV. SEMESTAR. već se ostavlja za logičku razinu. Na primjer.6 sadrţi primjere za involuirane veze s različitim funkcionalnostima. tada je jasno što on znači te da on moţe poprimiti vrijednosti koje odgovaraju ljudskim prezimenima.skripta Tip entiteta STUDENT ima atribute: JMBAG. ako se zove ECTS-BODOVI. takav rječnik nije obavezan na konceptualnoj razini oblikovanja. a i najpoţeljnija zbog svoje jednostavnosti. ako se zove ŠIFRA PREDMETA. Slika 2.Baze podataka . PREZIME. Ta vrsta odnosa meĎu entitetima je najčešća.3. OCJENA. IME. odnosno M:M. IME. PMF – Matematički odsjek 37 . Tip entiteta PREDMET ima atribute: ŠIFRA PREDMETA. Na konceptualnoj razini zapravo je dovoljno da atributi imaju smislene nazive iz kojih se naslućuje njihovo značenje i tip. Prikaz involuirane veze Involuirana veza povezuje jedan tip entiteta s tim istim tipom.

Primjerci entiteta opisuju dijelove proizvoda koji se proizvode u nekoj tvornici. neobavezno.Robert Manger 0. Treći dijagram na Slici 2.M SADRŢI Slika 2. Funkcionalnost veze je 1:1. koja povezuje tip entiteta OSOBA sa samim sobom. Funkcionalnost je 1:M jer jedan šef moţe imati više podreĎenih suradnika. Veza prikazuje odnos suradnika u nekom poduzeću.6 prikazuje vezu SADRŢI koja povezuje entitet DIO PROIZVODA sa samim sobom.6: Primjeri za involuirane veze.1 0. koja povezuje tip entiteta SURADNIK sa samim sobom.6 prikazuje vezu JE ŠEF ZA. dakle povezani su oni primjerci entiteta OSOBA koji su u braku.6 prikazuje vezu U BRAKU S. Biljeţi se tko je kome šef. Funkcionalnost veze je očito M:M. te da se isti jednostavniji dio pojavljuje se u više sloţenijih. a poligamija zabranjena. Prvi dijagram na Slici 2. a ako je sloţen onda se od nečega sastoji. naravno. Veza prikazuje odnos izmeĎu sloţenijih i jednostavnijih dijelova. dakle da jedan sloţeniji dio sadrţi više jednostavnijih. Riječ je o bračnoj vezi izmeĎu osoba.1 OSOBA U BRAKU S 0. Drugi dijagram na Slici 2.1 0. Članstvo entiteta u toj vezi je. a ne obratno). Članstvo entiteta u vezi je obavezno jer skoro svaki suradnik ima svog šefa. a jedan suradnik ima najviše jednog neposrednog šefa.M SURADNIK 0. jer ako je dio jednostavan onda se nekamo ugraĎuje. 38 PMF – Matematički odsjek .M JE ŠEF ZA DIO PROIZVODA 0. Dijagram ima ucrtanu strelicu koja pokazuje smjer tumačenja veze (jedan je šef za više suradnika. naime pretpostavlja se da su prošli brakovi zaboravljeni. Članstvo entiteta u vezi je najvjerojatnije obavezno. a onaj koji nema šefa (glavni direktor) je šef drugima.

Pritom E1 nasljeĎuje sve atribute od E2.skripta 2. Riječ je o posebnoj vezi s funkcionalnošću 1:1 koja povezuje primjerak entiteta E1 s njim samim shvaćenim kao primjerkom od E2. PMF – Matematički odsjek 39 .3.7: Primjeri za pod-tipove i nad-tipove.1 NASTAVNIK 1.1 JE JE 0. dakle ne bi se smjelo rabiti u druge svrhe osim za povezivanje pod-tipova i nad-tipova. no taj izuzetak ne smeta jer sve pojave veze JE imaju u biti isto značenje.Baze podataka .1 JE 0. Prikaz pod-tipova i nad-tipova entiteta Tip entiteta E1 je pod-tip tipa entiteta E2 ako je svaki primjerak od E1 takoĎer i primjerak od E2.1 1. Primijetimo da je ime veze JE rezervirano.1 STUDENT 0. a ne obratno). Obavezno se crta strelica prema gore koja naglašava smjer tumačenja veze (primjerak od E1 je primjerak od E2. a izmeĎu crtamo romb koji prikazuje vezu s nazivom JE (engleski IS A).1 PROFESOR Slika 2. OSOBA 1.2. no E1 moţe imati i dodatne atribute. Primijetimo takoĎer da se sama veza JE moţe pojaviti više puta na istom dijagramu ako imamo više parova entiteta koji su u odnosu pod-tip . Time je napravljena iznimka od općenitog pravila da svaka veza unutar sheme mora imati jedinstveno ime.nadtip. Situaciju da je E1 pod-tip od E2 crtamo na dijagramu tako da pravokutnik za E1 smjestimo ispod pravokutnika za E2.

budući da postoji više vrsta funkcionalnosti. pritom svaki od njih uključuje neke specifične atribute. docente i profesore. PROFESOR moţe imati svoje specifične atribute koji općenito nisu primjenjivi na NASTAVNIKA. Riječ je o tipovima entiteta za osobe koje se pojavljuju na fakultetu. on uključuje atribute koji su primjenjivi za sve osobe. dakle opet kao romb s upisanim imenom veze. Primjer ternarne veze sa Slike 2.M IZVOZI 0. Stanje te veze biljeţi se kao skup 40 PMF – Matematički odsjek .8: Primjer ternarne veze. te se gleda broj primjeraka trećeg tipa koji su u vezi s dva fiksirana primjerka. SPOL. Uz spojnice su opet upisane oznake kardinalnosti veze. 2.Robert Manger Slika 2. na primjer PREZIME. Dok tip NASTAVNIK uključuje sve asistente. a ne dvije. te zemljama u koje one izvoze svoje proizvode. proizvodima koje one proizvode. i to tako da kardinalnost u smjeru od odabrana dva tipa prema trećem tipu piše blizu trećem tipu. Na primjer.M 0.3. Ternarna veza prikazuje se na dijagramu slično kao binarna. a time posredno i pod-tip od OSOBA. Stanje ternarne veze opisuje se kao skup ureĎenih trojki primjeraka entiteta koji su trenutno povezani. Prikaz ternarne veze Ternarna veza uspostavlja se izmeĎu tri tipa entiteta. tip PROFESOR uključuje samo one nastavnike koji imaju zvanje profesora. što znači da posredno nasljeĎuje i atribute od OSOBE. Slično.4 odnosi se na podatke o kompanijama. a još manje na OSOBU. IME. fiksiraju se primjerci entiteta odabranih dvaju tipova. Razlika je da sad iz romba izlaze tri spojnice prema odgovarajućim pravokutnicima.7 sadrţi dijagram sheme s pod-tipovima i nad-tipovima. Svojstva ternarne veze teţe je opisati nego kod binarne veze. STUDENT bi mogao imati atribut GODINA STUDIJA koji nije primjenjiv na NASTAVNIKA a ni na općenitu OSOBU. DATUM ROĐENJA … Tipovi STUDENT i NASTAVNIK su pod-tipovi od OSOBA. tako da se na jedan od tri načina odaberu dva od tri tipa entiteta. PROFESOR nasljeĎuje sve atribute NASTAVNIKA. Za istu vezu mogu se promatrati tri kardinalnosti. te više kombinacija za obaveznost članstva. Vidimo da je PROFESOR podtip od NASTAVNIK.3. KOMPANIJA 0. NASTAVNIK bi mogao imati svoj specifični atribut DATUM ZAPOŠLJAVANJA. Najopćenitiji tip je OSOBA.M PROIZVOD ZEMLJA Slika 2.

8 vrijedi pravilo: ako kompanija izvozi u neku zemlju. Moguće je takoĎer da za zadani par (kompanija.M RADI PRODAJE 1. dovoljno je provjeriti je li odgovarajući par kompanije i proizvoda povezan vezom RADI. Iz dviju binarnih veza RADI i PRODAJE moguće je reproducirati polaznu ternarnu vezu IZVOZI. tada ona odmah izvozi sve svoje proizvode u tu zemlju. jer na primjer svaka kompanija nešto proizvodi i to što proizvodi nekamo izvozi. Uz ovo pravilo. jer na primjer za zadani par (kompanija. mogli bismo promatrati i veze koje povezuju četiri ili pet ili još više tipova entiteta. KOMPANIJA 1. proizvod) dotična kompanija ne proizvodi dotični proizvod. Funkcionalnost veze je mnogo-napramamnogo-naprama-mnogo. proizvoda i zemlje povezana vezom IZVOZI. Sva tri entiteta u vezi na Slici 2. da bismo provjerili je li zadana trojka primjeraka kompanije. tada veza mora ostati ternarna. Ternarnu vezu uvodimo samo onda kad se ona ne moţe rastaviti na dvije binarne. te je li istovremeno odgovarajući par kompanije i zemlje povezan vezom PRODAJE. Uzmimo da u primjeru sa Slike 2.Baze podataka . kao što je prikazano na Slici 2.M. Pritom veza RADI biljeţi radi li neka odreĎena kompanija neki odreĎeni proizvod. Za takve veze još bi u većoj mjeri vrijedio savjet da ih po mogućnosti treba rastaviti na nekoliko jednostavnijih veza.M 1. razmatrana ternarna veza moţe se zamijeniti s dvije binarne. PMF – Matematički odsjek 41 .9: Rastavljanje ternarne veze na dvije binarne. Ako pravilo ne vrijedi. Pritom jedna trojka znači da dotična kompanija proizvodi dotični proizvod i izvozi ga u dotičnu zemlju.skripta ureĎenih trojki sastavljenih od primjeraka triju tipova. proizvod) moţe postojati mnogo zemalja u koje ta kompanija izvozi taj proizvod.4 imaju obavezno članstvo.9. a PRODAJE biljeţi pojavljuje li se neka kompanija na trţištu neke zemlje.M PROIZVOD ZEMLJA Slika 2. One bi očito bile još sloţenije od ternarnih.M 1. tako da je kardinalnost oblika 0. dakle M:M:M. Slično kao ternarne veze. Naime. koje povezuju tri tipa entiteta. Naglašavamo da je ova zamjena veza ispravna samo od uvjetom da zaista vrijedi gore spomenuto pravilo.

Na osnovu specifikacije koju ste dobili rješavanjem Zadatka 1.Robert Manger 2.4. Zadatak 2. Zadaci za vježbu Zadatak 2. Pročitajte specifikaciju baze podataka o znanstvenoj konferenciji koja se nalazi na početku Priloga 2.3. 42 PMF – Matematički odsjek .5 oblikujte konceptualnu shemu za bazu podataka iz vašeg područja interesa. nedostaju mnogi vaţni podaci o fakultetu. Usporedite vaše rješenje s onim u prilogu. Pročitajte specifikaciju baze podataka o bolnici koja se nalazi na početku Priloga 1.4 i 2. Zadatak 2. pa shodno tome i u konceptualnoj shemi sa Slike 2. Očito je da već u specifikaciji iz Odjeljka 2. Zadatak 2.5. moraju se evidentirati posudbe knjiga članovima.1. te zaposlenicima knjiţnice.2. Usporedite vaše rješenje s onim u prilogu.5. TakoĎer. Na osnovu te specifikacije i bez čitanja ostatka priloga sami oblikujte odgovarajuću konceptualnu shemu. veze i atribute bi po vašem mišljenju trebalo dodati? Zadatak 2.2. Oblikujte konceptualnu shemu za bazu podataka o knjiţnici. Predvidite da ta baza mora pohranjivati podatke o knjigama u knjiţnici. Na osnovu te specifikacije i bez čitanja ostatka priloga sami oblikujte odgovarajuću konceptualnu shemu.1. Predloţite nadopunu te sheme: koje entitete.4. članovima knjiţnice.

1 prikazana je relacija STUDENT. pa je teško razlikovati jedno od drugog. od relacijske sheme do njezine konačne implementacije vrlo je kratak put. no tada se podrazumijeva da su to ustvari atributi s istim značenjem. Model se dugo pojavljivao samo u akademskim raspravama i knjigama. te način kako se zapisuje relacijska shema. s atributima JMBAG. te napretku samih računala. I danas se ogromna većina DBMS-ova koristi baš tim modelom. Općenito o relacijskom modelu Relacijski model bio je teoretski zasnovan još krajem 60-tih godina 20.1. vaţno svojstvo relacijske sheme je da se ona moţe više-manje izravno implementirati pomoću današnjih DBMS-a. efikasnost relacijskih baza postepeno se poboljšavala. definiran je tip ili skup dozvoljenih vrijednosti za atribut. IME. Redak nazivamo n-torka.zato stupac poistovjećujemo s atributom i obratno. Ipak. Dopušta se da dvije relacije imaju atribute s istim imenom. 3. Svaka relacija ima svoje ime po kojem je razlikujemo od ostalih u istoj bazi. stoljeća. Vrijednost atributa mora biti jednostruka i jednostavna (ne ponavlja se. 3. budući da su u njoj i entiteti i veze meĎu entitetima pretvoreni u relacije. PREZIME.skripta 3. na Slici 3. dakle shemu koja opisuje logičku strukturu baze u skladu s pravilima relacijskog modela podataka. Broj atributa se zove stupanj relacije.1. Atribut ima svoje ime po kojem ga razlikujemo od ostalih u istoj relaciji. Relacija sadrţi podatke o studentima koji su upisani na fakultetu. Kao primjer. Jedan redak relacije obično predstavlja jedan primjerak entiteta. a broj n-torki je kardinalnost relacije. GODINA STUDIJA. a to je logičko oblikovanje. Zatim ćemo izloţiti pravila kojima se konceptualna shema baze dobivena u prethodnom Poglavlju 2 pretvara u relacijsku shemu. Zahvaljujući intenzivnom istraţivanju.1. Pod nekim uvjetima toleriramo situaciju da vrijednost atributa nedostaje (nije upisana). U jednoj relaciji ne smiju postojati dvije jednake n-torke. naime relaciju tumačimo kao skup ntorki. ili biljeţi vezu izmeĎu dva ili više primjeraka. Dakle. koji se takoĎer zove i zove domena atributa. ne da se rastaviti na dijelove). U ovom poglavlju najprije ćemo detaljnije opisati svojstva relacijskog modela.logičko oblikovanje baze podataka U ovom poglavlju počinjemo govoriti o drugoj fazi oblikovanja baze podataka. PMF – Matematički odsjek 43 . atribut. u radovima Edgara Codd-a. stoljeća relacijski model je postao prevladavajući. Relacijska shema manje je razumljiva korisnicima od konceptualne. Relacijski model . Vrijednosti jednog atributa su podaci iste vrste. Zahvaljujući današnjem softveru. Glavni cilj te faze je stvoriti relacijsku shemu baze. n-torka Relacijski model zahtijeva da se baza podataka sastoji od skupa pravokutnih tablica takozvanih relacija.Baze podataka . Sredinom 80-tih godina 20. Prve realizacije na računalu bile su suviše spore i neefikasne. Jedan stupac relacije obično sadrţi vrijednost jednog atributa (za entitet ili vezu) . Relacija. Tako dobivena relacijska shema obično još nije u svom konačnom obliku. naime ona se dalje podvrgava postupku dotjerivanja (normalizacije) koji će biti opisan u sljedećem Poglavlju 4.

stupac).Robert Manger STUDENT JMBAG 0036398757 1191203289 1192130031 1191205897 0165043021 0036448430 0246022858 PREZIME Marković Petrović Horvat Janković Kolar Grubišić Vuković IME Marko Petar Dragica Marija Ivan Katica Janko GODINA STUDIJA 1 2 2 1 3 3 1 Slika 3.1 atribut JMBAG čini ključ. Vrijednost primarnog atributa ne smije ni u jednoj n-torki ostati neupisana. načini njezina zapisivanja GraĎu relacije kratko opisujemo takozvanom shemom relacije. K uvijek postoji.1. Izbacivanjem suvišnih atributa doći ćemo do podskupa koji zadovoljava i svojstvo 2.1. Budući da su sve n-torke u R meĎusobno različite. promjene i brisanja n-torki. shema izgleda ovako: 44 PMF – Matematički odsjek . za relaciju o studentima sa Slike 3. češće se koriste neposredni termini (tablica. permutiranjem redaka i stupaca tablice dobivamo drukčiji zapis iste relacije. skup svih atributa zadovoljava svojstvo 1. Atributi koji sastavljaju primarni ključ zovu se primarni atributi. Uvedena terminologija potječe iz matematike. Primarni atributi su podvučeni. Dakle. Ako izbacimo iz K bilo koji atribut. redak. 3. Kandidati za ključ.1: Relacija s podacima o studentima. 3.3. atribut). njezin atribut column. Relacijska shema. Naime. u relaciji o studentima sa Slike 3. n-torka. Ova svojstva su „vremenski neovisna“. primarni ključ Ključ K relacije R je podskup skupa atributa od R sa sljedećim svojstvima: 1. Kombinacija IMENA i PREZIMENA vjerojatno nije ključ jer se mogu pojaviti osobe s istim imenom i prezimenom. Na primjer. To je redak koji se sastoji od imena relacije.1. Dakle ne mogu u R postojati dvije n-torke s istim vrijednostima atributa iz K.2. a n-torku row. tada se narušava svojstvo 1. Dešava se da relacija ima više kandidata za ključ. U komercijalnim DBMS-ovima i pripadnoj dokumentaciji. 2. u smislu da vrijede u svakom trenutku bez obzira na povremene unose. Vrijednosti atributa iz K jednoznačno odreĎuju n-torku u R. Relacija ne propisuje nikakav redoslijed svojih n-torki i atributa. Tada jedan on njih proglašavamo primarnim ključem. Na primjer. Jezik SQL relaciju naziva table. te popisa imena atributa odvojenih zarezima i zatvorenih u zagrade. umjesto „matematičkih“ termina (relacija.

PMF – Matematički odsjek 45 . Na primjer. Na taj način pokazat ćemo kako se iz cijele konceptualne sheme dobiva relacijska shema. dobivamo relacijsku shemu prikazanu na Slici 3. nego onako kako to prirodno zahtijevaju sami podaci. dakle popisom svih atributa. Na primjer.4 i 2. Doduše. SEMESTAR.6. PLAĆA) ZAVOD (IME ZAVODA. shema baze ima onoliko redaka koliko u njoj ima relacija. OPIS DJELATNOSTI) Slika 3.5. Jedan primjerak entiteta prikazan je jednom n-torkom. Opisani prikaz relacijske sheme vrlo je koncizan i pregledan. 3. Ako pravilo o pretvorbi entiteta primijenimo na cijelu konceptualnu shemu sa Slika 2.5. Zato je potrebno da se shema nadopuni rječnikom podataka.2. Atributi tipa postaju atributi relacije. Tipovi ne moraju biti definirani onako kako će to zahtijevati fizička shema.2. Za relacijsku shemu sa Slike 3. Pretvaranje konceptualne sheme u relacijsku shemu U nastavku objašnjavamo kako se pojedini elementi konceptualne sheme pretvaraju u relacije. Primarni ključ entiteta postaje primarni ključ relacije. PREZIME. sudjelovanje entiteta u vezama moţe zahtijevati da se u relaciju dodaju još neki atributi koji nisu postojali u odgovarajućem tipu entiteta. BROJ SOBE. Pretvorba entiteta i atributa Svaki tip entiteta prikazuje se jednom relacijom. PREZIME. jer se iz nje ne mogu prepoznati veze meĎu entitetima. relacijska shema izgleda kao na Slici 3. PREZIME.skripta STUDENT (JMBAG. za bazu podataka o fakultetu opisanu konceptualnom shemom na Slikama 2.5.2. IME. ECTS-BODOVI) . No o tome ćemo govoriti u idućim odjeljcima.4 i 2. pripadni rječnik podataka mogao bi izgledati kao što se vidi na Slici 3.Baze podataka .2: Pretvorba entiteta iz baze podataka o fakultetu u relacije. ECTS-BODOVI) NASTAVNIK (OIB.4 i 2. NASLOV. To je za sada krnja shema. no u njemu nedostaju informacije o tipovima atributa. GODINA STUDIJA) PREDMET (ŠIFRA PREDMETA. Relacijska shema cijele baze zapisuje se tako da se naniţu sheme za sve relacije od kojih se ta baza sastoji. STUDENT (JMBAG. 3. s pripadnim tipovima vrijednosti i neformalnim opisom. NASLOV.5. Dakle. tip entiteta PREDMET iz fakultetske baze podataka sa Slika 2.5 prikazuje se relacijom PREDMET (ŠIFRA PREDMETA. IME. GODINA STUDIJA) .1. IME. SEMESTAR.

Prvo rješenja za prikaz te veze i pripadnih entiteta izgleda ovako: POSUĐIVAĈ (BROJ ISKAZNICE. to jest za sve knjige koje trenutno nisu posuĎene. dovoljno je pogledati odgovarajuću n-torku iz relacije PREDMET. NASLOV. tada vezu moţemo prikazati na prethodni način. IME. PREZIME. IME ZAVODA.3: Konceptualna shema baze podataka o knjiţnici. BROJ ISKAZNICE. SEMESTAR. Na primjer. Lako se vidi da uvoĎenje stranog ključa zaista omogućuje da se polazna veza reproducira u oba smjera. u relaciju KNJIGA dodali smo kao strani ključ BROJ ISKAZNICE osobe koja je posudila knjigu. Drugo rješenje za prikaz iste veze POSUDBA zahtijeva tri relacije. … ) . Relacije POSUĐIVAĈ i KNJIGA odgovaraju samim tipovima entiteta. tada relacija za E1 treba uključiti primarne atribute od E2. ako u konceptualnoj shemi sa Slike 2. Pretvorba veza jedan-naprama-mnogo Ako tip entiteta E1 ima obavezno članstvo u vezi s tipom E2 koja ima funkcionalnost M:1. gdje treća relacija sluţi za prikaz same veze: 46 PMF – Matematički odsjek . promotrimo vezu na Slici 3. POSUĐIVAĈ POSUDBA KNJIGA Slika 3.2.3 koja prikazuje posuĎivanje knjiga u knjiţnici. NASLOV. taj strani ključ omogućuje da se veza POSUDBA reproducira u oba smjera.4 svaki predmet mora biti ponuĎen od nekog zavoda. da bismo za zadani predmet ustanovili koji zavod ga nudi. Obratno. … ) KNJIGA (INVENTARSKI BROJ. Slično kao prije. Ključ jedne relacije koji je prepisan u drugu relaciju zove se strani ključ (u toj drugoj relaciji).Robert Manger 3.2. Ako tip entiteta E1 nema obavezno članstvo u M:1 vezi s tipom E2. Da bismo prikazali vezu posuĎivanja. Na primjer. da bismo za zadani zavod pronašli koje sve predmete on nudi. ECTS-BODOVI) . moramo pretraţiti relaciju PREDMET i izdvojiti sve n-torke sa zadanom vrijednošću za IME ZAVODA – svaka od njih opisuje jedan od traţenih predmeta. te iz nje pročitati vrijednost atributa IME ZAVODA. ili uvoĎenjem nove relacije čiji atributi su primarni atributi od E1 i E2. Primijetimo da će vrijednost atributa BROJ ISKAZNICE ostati prazna u mnogim n-torkama relacije KNJIGA. dakle uvoĎenjem stranog ključa. ADRESA. Kao primarne ključeve uveli smo atribute BROJ ISKAZNICE (posuĎivača) odnosno INVENTARSKI BROJ (knjige). tada se veza NUDI svodi na to da u relaciju PREDMET ubacimo ključ relacije ZAVOD: PREDMET (ŠIFRA PREDMETA. Kao primjer.

dakle na sve M:1. i to posuĎivaču s upisanom vrijednošću BROJA ISKAZNICE. da bismo ustanovili status neke odreĎene knjige. Glavna prednost uvoĎenja posebne relacije za prikaz veze umjesto stranog ključa je u tome da na taj način nećemo imati praznih vrijednosti atributa. Na primjer. IME ZAVODA. pretraţujemo relaciju POSUDBA i izdvajamo sve n-torke sa odgovarajućom vrijednošću za BROJ ISKAZNICE – svaka od tih n-torki sadrţi INVENTARSKI BROJ jedne od posuĎenih knjiga. Atribut OIB PROĈELNIKA unutar relacije ZAVOD odnosi se na pročelnika dotičnog zavoda. Slično. OIB NASTAVNIKA. u relaciji POSUDBA traţimo n-torku s odgovarajućom vrijednošću INVENTARSKOG BROJA – ako takvu n-torku ne naĎemo tada knjiga nije posuĎena. BROJ ISKAZNICE) . atribut IME ZAVODA unutar relacije NASTAVNIK biljeţi kojem zavodu pripada taj nastavnik. NASLOV. tada se relacijska shema sa Slike 3. IME. 1:M i 1:1 veze sa Slike 2. ECTS-BODOVI). SEMESTAR.Baze podataka . ključ u relaciji POSUDBA isti je kao u KNJIGA. PREZIME. Atribut OIB NASTAVNIKA u relaciji PREDMET odreĎuje nastavnika koji predaje taj predmet. PLAĆA) ZAVOD (IME ZAVODA. PREZIME. Budući da jedna knjiga moţe biti posuĎena samo jednom posuĎivaču. Samo one knjige koje su trenutno posuĎene predstavljene su n-torkom u relaciji POSUDBA. Na primjer u relaciju POSUDBA mogli bismo uvesti atribut DATUM VRAĆANJA.4.2 pretvara u shemu prikazanu na Slici 3. 1:M i 1:1 veza. IME ZAVODA. STUDENT (JMBAG. Ipak. GODINA STUDIJA) PREDMET (ŠIFRA PREDMETA. Na Slici 3. Izloţena pravila za prikaz veze s funkcionalnošću M:1 analogno se primjenjuju i na veze s funkcionalnošću 1:M i 1:1. BROJ SOBE.4. PMF – Matematički odsjek 47 . ADRESA.4 sve novosti u odnosu na Sliku 3. … ) KNJIGA (INVENTARSKI BROJ.skripta POSUĐIVAĈ (BROJ ISKAZNICE. … ) POSUDBA (INVENTARSKI BROJ. Atribut IME ZAVODA u relaciji PREDMET odreĎuje zavod koji nudi dotični predmet. Vidimo da su u relacije koje odgovaraju entitetima dodani strani ključevi koji omogućuju reproduciranje svih M:1.4: Pretvorba veza jedan-naprama-mnogo za bazu o fakultetu. OIB PROĈELNIKA. NASTAVNIK (OIB. IME. Slično kao strani ključ. Posebna relacija za prikaz veze je pogotovo preporučljiva ako veza ima svoje atribute. IME.2 označene su crvenom bojom. dobivena shema još uvijek ne biljeţi M:M vezu UPISAO. da bismo pronašli koje sve knjige je posudio odreĎeni posuĎivač. PREZIME. inače je posuĎena. Ako ta pravila primijenimo na našu bazu podataka o fakultetu. Obratno. OPIS DJELATNOSTI) Slika 3. NASLOV. posebna relacija za prikaz veze opet omogućuje da se ta veza reproducira u oba smjera.

uočili smo da se iz sheme ne vide tipovi tributa. IME. veza UPISAO iz fakultetske baze sa Slike 2. IME ZAVODA. OCJENA) Slika 3.2. IME ZAVODA.Robert Manger 3. Pretvorba veza mnogo-naprama-mnogo Veza s funkcionalnošću M:M uvijek se prikazuje posebnom relacijom. ŠIFRA PREDMETA. STUDENT (JMBAG.5.4 i 2. da bismo pronašli sve studente koji su upisali zadani predmet. pretraţujemo relaciju UPISAO i izdvajamo sve n-torke s odgovarajućom vrijednošću za JMBAG – svaka od izdvojenih n-torki sadrţi ŠIFRU PREDMETA kojeg je taj student upisao. BROJ SOBE. koji put se moţe desiti da iz imena pojedinih atributa nije lako odrediti njihovo značenje.2. OIB PROĈELNIKA. veze i atribute kao na Slikama 2. OCJENA) . OPIS DJELATNOSTI) UPISAO (JMBAG. ECTS-BODOVI). Naime. Zaista. pretraţujemo relaciju UPISAO ali tako da izdvojimo n-torke s odgovarajućom vrijednošću za ŠIFRU PREDMETA – svaka od izdvojenih n-torki otkriva JMBAG jednog od traţenih studenata. GODINA STUDIJA) PREDMET (ŠIFRA PREDMETA. Na primjer. OIB NASTAVNIKA. te od kojih se atributa sastoji svaka pojedina relacija. budući da isti student moţe upisati više predmeta. dobivamo shemu prikazanu na Slici 3. koja se sastoji od primarnih atributa za oba tipa entiteta zajedno s eventualnim atributima veze. IME. Obratno. PREZIME. NASLOV. to jest sastoji se od kombinacije atributa JMBAG i ŠIFRA PREDMETA. da bismo ustanovili koje je sve predmete upisao zadani student.4 prikazuje se relacijom: UPISAO (JMBAG. ŠIFRA PREDMETA. NASTAVNIK (OIB. DATUM UPISA. Ipak. TakoĎer. 48 PMF – Matematički odsjek . SEMESTAR. To je napokon cjelovita relacijska shema za našu bazu podataka o fakultetu. Činjenica da je jedan student upisao jedan predmet prikazuje se jednom n-torkom u relaciji UPISAO. PREZIME.5. PLAĆA) ZAVOD (IME ZAVODA. Lako se vidi da opisana relacija zaista omogućuje da se pripadna M:M veza reproducira u oba smjera. Ključ za UPISAO je očito sloţen. DATUM UPISA. Sastavljanje rječnika podataka Rekli smo da relacijska shema na koncizan način opisuje logičku strukturu baze u skladu s relacijskim modelom. 3.5: Relacijska shema za bazu podataka o fakultetu. a isti predmet moţe biti upisan od više studenata.3. Na primjer. iz te sheme se vidi od kojih se relacija sastoji cijela baza. ni jedan od tih atributa sam nije dovoljan da jednoznačno odredi n-torku. Ubacivanjem relacije UPISAO u shemu sa Slike 3. koja je ekvivalentna konceptualnoj shemi budući da sadrţi sve entitete.4.4.

skripta IME ATRIBUTA JMBAG PREZIME IME GODINA STUDIJA ŠIFRA PREDMETA NASLOV SEMESTAR TIP Niz od toĉno 10 znamenki Niz znakova Niz znakova Cijeli broj izmeĊu 1 i 5 Niz od toĉno 5 znamenki Niz znakova „zimski“ ili „ljetni“ Mali cijeli broj Niz od toĉno 11 znamenki Niz od toĉno 3 znamenke Cijeli broj Niz znakova OPIS Šifra koja jednoznaĉno odreĊuje studenta Prezime osobe Ime osobe Godina koju je student upisao Šifra koja jednoznaĉno odreĊuje predmet Naslov predmeta Semestar u kojem se predmet predaje Bodovi koje student dobiva ako poloţi predmet Šifra koja jednoznaĉno odreĊuje osobu OdreĊuje sobu u kojoj sjedi nastavnik Neto plaća osobe u kunama Jednoznaĉno odreĊuje zavod unutar fakulteta Tekst koji opisuje djelatnost zavoda Datum kad je odreĊeni student upisao odreĊeni predmet Ocjena koju je odreĊeni student dobio iz odreĊenog predmeta ECTS-BODOVI OIB BROJ SOBE PLAĆA IME ZAVODA OPIS DJELATNOSTI Niz znakova DATUM UPISA Datum OCJENA Cijeli broj izmeĊu 2 i 5 Slika 3.6: Rječnik podataka za bazu podataka o fakultetu. PMF – Matematički odsjek 49 .Baze podataka .

Pretvaranje složenijih veza u relacije Dosad izloţena pravila obično su dovoljna za pretvorbu konceptualne sheme u relacijsku. Na primjer.3. tip atributa REGISTARSKA OZNAKA (automobila) definiramo kao niz od 8 znakova gdje su prva dva znaka slova. te da se on priloţi uz shemu. Kao primarni ključ za identificiranje osoba odabrali smo OIB.Robert Manger Ovi nedostaci informacije nadoknaĎuju se tako da se sastavi rječnik podataka. Relacija BRAK zapisuje bračnu vezu. No isto tako smo kao primarni ključ mogli odabrati i OIB ŢENE. tip atributa PREZIME definiramo kao niz znakova proizvoljne duljine. te upišemo u tabelu sve atribute na koje naiĎemo. s time da taj tip moţemo preciznije podesiti uvoĎenjem raznih ograničenja. Kod odreĎivanja tipova treba uzeti u obzir da današnji DBMS-i očekuju da će atributi biti cijeli ili realni brojevi. No ako se pojavljuju i sloţenije veze.1. te im odredimo tip. Slično.6. ADRESA. U ovom potpoglavlju opisujemo kako se svaka od sloţenijih vrsta veza moţe pretvoriti u relacije. Znači. makar DBMS moţda neće biti u stanju obavljati tako detaljnu kontrolu znak-po-znak. Rječnik podataka je tabela u kojoj su popisani svi atributi. Pretvorba involuiranih veza Involuirane veze prikazuju se pomoću relacija slično kao binarne veze. Kao primarni ključ u relaciji BRAK odabrali OIB MUŢA. Posluţit ćemo se primjerima sa Slike 2. za svaki atribut treba odrediti tip u jednom od ovih oblika. ili nizovi znakova. budući da su prošli brakovi zaboravljeni a poligamija zabranjena. s time da isti atribut upišemo samo jednom.6. Budući da se još uvijek bavimo logičkom razinom oblikovanja. 50 PMF – Matematički odsjek . 3. … ) BRAK (OIB MUŢA. Primjenom opisanog postupka na našu bazu podataka o fakultetu dobivamo rječnik podataka koji je prikazan na Slici 3. dakle jedna njezina n-torka opisuje jednu osobu. PREZIME. Prva relacija OSOBA odgovara samom tipu entiteta za osobe. IME. tada su nam potrebna dodatna pravila. dakle jedna njezina n-torka biljeţi par od jedne muške i jedne ţenske osobe koje su u braku. iduća četiri znamenke. Zaista. makar će DBMS sigurno nametnuti neku gornju ogradu na duljinu.5. eventualno datumi ili novčani iznosi. ili znakovi. bez obzira što DBMS u konačnoj implementaciji moţda neće moći uvaţiti neka od njih ili će nametnuti neka svoja. Taj rječnik sluţi kao nadopuna relacijske sheme sa Slike 3. te je za svakog od njih definiran tip i opisano značenje. OIB ŢENE. 3. DATUM VJENĈANJA) . ona su dovoljna kod jednostavnijih konceptualnih shema koje sadrţe samo binarne veze. Rječnik podataka stvaramo tako da proĎemo svim relacijama iz sheme. identifikator muškog supruţnika jednoznačno odreĎuje cijeli brak. a zadnja dva opet slova.3. Zatim atributima u tabeli na što razumljiviji način opišemo njihovo značenje. Tip entiteta OSOBA i 1:1 vezu U BRAKU S najbolje je (zbog neobaveznosti) prikazati pomoću dvije relacije: OSOBA (OIB. ograničenja vezana uz tip biramo na najprirodniji način. Točnije.

tad je dotični muškarac neoţenjen. da bismo ustanovili koje sve jednostavne dijelove sadrţi zadani sloţeni dio. Tip entiteta SURADNIK i 1:M vezu JE ŠEF ZA prikazujemo jednom relacijom: SURADNIK (MATIĈNI BROJ. da bismo prikazali vezu izmeĎu šefova i suradnika. Lako se vidi da opisana relacija zaista omogućuje da se pripadna M:M veza reproducira u oba smjera. takvih da taj sloţeni dio sadrţi u sebi taj jednostavni dio. Na primjer. a jedan jednostavni dio se moţe pojaviti u više sloţenih. OPIS. da bismo za zadanog suradnika ustanovili tko je njemu šef. IME DIJELA. Sasvim analogno postupamo da bismo pronašli bračni status i eventualnog bračnog druga zadane ţenske osobe. Kao primarni ključ za identificiranje dijelova uveli smo atribut BROJ DIJELA. iz odgovarajuće n-torke relacije SURADNIK čitamo MATIĈNI BROJ ŠEFA. Obratno. PREZIME. Tip entiteta DIO PROIZVODA i M:M vezu SADRŢI moramo prikazati pomoću dvije relacije: DIO PROIZVODA (BROJ DIJELA. Relacija SADRŢI zapisuje vezu izmeĎu sloţenih i jednostavnih dijelova. IME. Na primjer. da bismo pronašli sve sloţene dijelove koji sadrţe zadani jednostavni dio. Ubacivanje atributa MATIĈNI BROJA ŠEFA očigledno omogućuje da se veza JE ŠEF ZA reproducira u oba smjera.Baze podataka . dakle jedna njezina n-torka biljeţi par od jednog sloţenog i jednog jednostavnog dijela. Obratno. Ovo neće uzrokovati mnogo praznih vrijednosti atributa. u relaciji BRAK traţimo n-torku sa zadanim OIB-om MUŢA . Atributi BROJ DIJELA SLOŢENOG i BROJ DIJELA JEDNOSTAVNOG iste su vrste kao atribut BROJ DIJELA. ali se odnose na sloţeni odnosno jednostavni dio u paru. ali se odnosi na šefa dotičnog suradnika. … ) SADRŢI (BROJ DIJELA SLOŢENOG. pretraţujemo relaciju SADRŢI ali tako da izdvojimo n-torke s fiksiranom vrijednošću za BROJ DIJELA JEDNOSTAVNOG – svaka od izdvojenih n-torki otkriva BROJ DIJELA SLOŢENOG za jedan od traţenih sloţenih dijelova. No. da bismo za zadanog šefa ustanovili koji su sve suradnici njemu podreĎeni.skripta Lako se vidi da relacija BRAK zaista omogućuje da se polazna veza U BRAKU S reproducira u oba smjera. da bismo za zadanu mušku osobu utvrdili bračni status. budući da većina suradnika ima šefa. inače iz n-torke čitamo OIB njegove ŢENE. Prva relacija DIO PROIZVODA odgovara samom tipu entiteta za dijelove proizvoda. Riječ je o relaciji koja odgovara samom tipu entiteta za suradnike. pretraţujemo relaciju SADRŢI i izdvajamo sve n-torke s fiksiranom vrijednošću za BROJ DIJELA SLOŢENOG – svaka od izdvojenih n-torki sadrţi BROJ DIJELA JEDNOSTAVNOG za jedan od uključenih jednostavnih dijelova. Taj novi atribut je iste vrste kao MATIĈNI BROJ. MATIĈNI BROJ ŠEFA. pretraţujemo relaciju SURADNIK i izdvajamo sve n-torke s odgovarajućom vrijednošću za MATIĈNI BROJ ŠEFA – svaka izdvojena n-torka opisuje jednog podreĎenog suradnika. u istu relaciju smo dodali novi atribut.ako takve n-torke nema. i to zato što jedan sloţeni dio moţe sadrţavati više jednostavnih. PMF – Matematički odsjek 51 . Dodali smo i atribut KOLIĈINA koji kaţe koliko komada tih jednostavnih dijelova ulazi u taj sloţeni dio. BROJ DIJELA JEDNOSTAVNOG. Primarni ključ u relaciji SADRŢI mora biti sastavljen od oba broja dijela. Na primjer. MATIĈNI BROJ ŠEFA. ustvari strani ključ. KOLIĈINA). …) .

Kao primarne ključeve u te tri relacije uveli smo atribute IME KOMPANIJE. IME PROIZVODA i IME ZEMLJE. proizvodima i zemljama. i tako dalje. nije svjesna hijerarhije tipova.Robert Manger 3.8 imamo relacijsku shemu koja se sastoji od četiri relacije: KOMPANIJA (IME KOMPANIJE. jer na primjer za zadanu kompaniju i zadani proizvod moţe biti više zemalja u koje ta kompanija izvozi taj proizvod. Predloţeni način prikaza zapravo omogućuje da se odnos pod-tipova i nad-tipova po potrebi reproducira unutar aplikacija. Pretvorba ternarnih veza Ternarna veza gotovo uvijek se prikazuje posebnom relacijom. odnosno IME ZEMLJE. Dakle svaka od ovih relacija odgovara jednom od tipova entiteta. Naime. To znači da se relacijska baza mora sastojati isključivo od relacija (tablica). te nasljeĎivanje atributa. Veza JE izmeĎu pod-tipova i nad-tipova uspostavlja se na osnovu pojavljivanja iste vrijednosti OIB u raznim relacijama. a izmeĎu tih relacija ne moţe postojati nikakva struktura. … ) IZVOZI (IME KOMPANIJE. Kao primarni ključ za identificiranje osobe uveli smo OIB. 52 PMF – Matematički odsjek . Za primjer sa Slike 2. Dakle n-torke u različitim relacijama s istom vrijednošću OIB-a odnose se na istu osobu. U meĎuvremenu. Odnosi pod-tipova i nad-tipova entiteta. pa tako ni hijerarhija. IME PROIZVODA. Primijetimo da relacijski model zapravo nije pogodan za prikaz pod-tipova i nad-tipova. … ) PROIZVOD (IME PROIZVODA. IME ZEMLJE. No objektne baze za sada još nisu u širokoj uporabi. moramo se zadovoljiti ovakvim polovičnim rješenjem. … ) ZEMLJA (IME ZEMLJE. … ) . … atributi specifiĉni za profesore … ) .3. hijerarhija tipova za osobe sa Slike 2. IME PROIZVODA. ni jedna dva od ta tri atributa ne odreĎuju n-torku. … atributi zajedniĉki za sve tipove osoba … ) STUDENT (OIB. 3. Prve tri relacije odgovaraju samim tipovima entiteta. osnovna ideja relacijskog modela je jednostavnost i jednoobraznost strukture. dakle jedna njezina n-torka izraţava činjenicu da se odreĎeni proizvod odreĎene kompanije izvozi u odreĎenu zemlju. Četvrta relacija IZVOZI prikazuje promatranu ternarnu vezu.7 prikazuje se sljedećim relacijama. Pretvorba pod-tipova i nad-tipova Pod-tip nekog tipa entiteta prikazuje se posebnom relacijom koja sadrţi primarne atribute nadreĎenog tipa i atribute specifične za taj pod-tip. Naime. Primarni ključ u IZVOZI je trojka atributa IME KOMPANIJE. OSOBA (OIB.3. puno prirodnije i izravnije bi se trebali moći realizirati u objektnom modelu za baze podataka. … atributi specifiĉni za nastavnike … ) PROFESOR (OIB.3. odnosno njezina logička struktura. … atributi specifiĉni za studente … ) NASTAVNIK (OIB.2. Na primjer. koja sadrţi primarne atribute svih triju tipova entiteta zajedno s eventualnim atributima veze. Pritom sama baza. Kod ternarnih veza čija funkcionalnost nije M:M:M broj primarnih atributa moţe biti manji. dakle u ovom slučaju kompanijama.

Sad tu konceptualnu shemu pretvorite u relacijsku shemu.1 dobili ste nadopunjenu konceptualnu shemu baze podataka o fakultetu. oblikujte relacijsku shemu i rječnik podataka za bazu podataka iz vašeg područja interesa. Zadatak 3.skripta Slično kao u prethodnim slučajevima. Sad tu nadopunjenu konceptualnu shemu pretvorite u (nadopunjenu) relacijsku shemu. Na primjer. Na osnovu te sheme i bez čitanja ostatka priloga sami oblikujte odgovarajuću relacijsku shemu i rječnik podataka. Na osnovu te sheme i bez čitanja ostatka priloga sami oblikujte odgovarajuću relacijsku shemu i rječnik podataka. TakoĎer sastavite odgovarajući rječnik podataka. U Prilogu 1 pronaĎite konceptualnu shemu baze podataka o bolnici. Zadatak 3. pretraţujemo relaciju IZVOZI i izdvajamo sve n-torke s fiksiranim vrijednostima za IME KOMPANIJE i IME PROIZVODA – svaka od izdvojenih n-torki otkriva IME ZEMLJE za jednu od traţenih zemalja. odnosno za zadani proizvod i zemlju popis kompanija koje taj proizvod izvoze u tu zemlju.Baze podataka .2 dobili ste konceptualnu shemu za bazu podataka o knjiţnici. Na osnovu konceptualne sheme koju ste dobili rješavanjem Zadatka 2. Analognim pretraţivanjima mogli bismo za zadanu kompaniju i zemlju pronaći popis proizvoda koje ta kompanija izvozi u tu zemlju. Rješavanjem Zadatka 2.1. TakoĎer sastavite odgovarajući rječnik podataka. PMF – Matematički odsjek 53 . 3.4. Rješavanjem Zadatka 2. Usporedite vaše rješenje s onim u prilogu.4.3.3.6? Zadatak 3. Usporedite vaše rješenje s onim u prilogu. Zadatak 3. U Prilogu 2 pronaĎite konceptualnu shemu baze podataka o znanstvenoj konferenciji. i ovdje se lako vidi da uvedena relacija za prikaz veze zaista omogućuje da se ta veza reproducira u svim smjerovima. Zadaci za vježbu Zadatak 3. da bismo za zadanu kompaniju i zadani proizvod ustanovili u koje sve zemlje ta kompanija izvozi taj proizvod.5 i 3.2.5. Koje nove relacije ili novi atributi su se pojavili u odnosu na Slike 3.

Robert Manger 54 PMF – Matematički odsjek .

Baze podataka - skripta

4. Normalizacija - nastavak logičkog oblikovanja baze podataka
U ovom poglavlju nastavljamo govoriti o drugoj fazi oblikovanja baze podataka, dakle opet govorimo o logičkom oblikovanju. Opisat ćemo postupak daljnjeg dotjerivanja polazne relacijske sheme dobivene primjenom pravila iz prethodnog poglavlja. Dotjerivanje je potrebno zato što polazna relacijska shema moţe sadrţavati odreĎene nepravilnosti. Te nepravilnosti treba otkloniti prije nego što krenemo u fizičko oblikovanje. Sam postupak dotjerivanja zove se normalizacija. U daljnjem tekstu najprije opisujemo jednostavniji i u praksi više rabljeni dio normalizacije, a to je prevoĎenje u prvu, drugu i treću normalnu formu. Zatim se bavimo sloţenijim dijelom normalizacije koji je vezan uz Boyce-Codd-ovu i četvrtu normalnu formu. Na kraju raspravljamo o tome zašto je normalizacija uopće potrebna, te moţemo li od nje odustati.

4.1.

Prva, druga i treća normalna forma

Teorija normalizacije zasnovana je na pojmu normalnih formi. Svaka normalna forma predstavlja odreĎeni „zahtjev na kvalitetu“ kojeg bi relacija trebala zadovoljavati. Što je normalna forma viša, njezini zahtjevi su stroţi. Relacije dobivene postupkom iz Poglavlja 2 i 3 morale bi u najmanju ruku biti u prvoj normalnoj formi. No Edgar Codd je u svojim radovima iz ranih 1970-tih godina definirao daljnja mjerila kvalitete koja su izraţena drugom i trećom normalnom formom. 4.1.1. Pod-zapisi, ponavljajuće skupine, prevođenje podataka u prvu normalnu formu Kad smo govorili o relacijskom modelu za bazu podataka, naglasili smo da vrijednost atributa unutar relacije (sadrţaj jedne kućice unutar tablice) mora biti jednostruka i jednostavna. Dakle u jednu kućicu ne moţe se upisati više vrijednosti, nego najviše jedna vrijednost. TakoĎer, ta upisana vrijednost ne smije biti sloţena, nego takva da ju sama baza smatra nedjeljivom. Ovo svojstvo jednostrukosti i jednostavnosti zove se jednim imenom svojstvo prve normalne forme (oznaka: 1NF). Dakle, kaţemo da relacija jeste u 1NF, jer su vrijednosti njezinih atributa jednostruke i nedjeljive. Primijetimo da 1NF zapravo ne predstavlja nikakav posebni zahtjev na relaciju, budući da je to svojstvo već ugraĎeno u sam relacijski model i definiciju relacije. Dakle, u relacijskoj bazi podataka niti ne moţe postojati relacija koja ne bi već otpočetka bila u 1NF. Pojam 1NF zapravo je izmišljen zbog drugih modela podataka gdje podaci ne moraju biti normalizirani čak ni u tom najjednostavnijem smislu. Ukoliko bazu podataka oblikujemo na način opisan u Poglavlju 2, tada vjerojatno nećemo imati prilike susresti se s nenormaliziranim podacima. Naime, oblikovanjem konceptualne sheme dobit ćemo entitete i veze čiji atributi već imaju jednostruke i jednostavne vrijednosti (inače bismo morali uvesti više entiteta i nove veze meĎu njima, ili više atributa). Pretvorbom takvih entiteta i veza po pravilima iz Poglavlja 3 dobit ćemo korektne relacije, dakle one u 1NF. PMF – Matematički odsjek 55

Robert Manger

Znanje o 1NF potrebno nam je prvenstveno u situaciji kad neke podatke već imamo pohranjene u nekom ne-relacijskom obliku, te ih ţelimo izravno prebaciti u relacijsku bazu. Zapisi (slogovi) u ne-relacijskim kolekcijama podataka mogu biti nenormalizirani, naime oni mogu sadrţavati takozvane pod-zapise ili ponavljajuće skupine. Na primjer, u nekom poduzeću mogli bismo imati datoteku s podacima o suradnicima. Zapis o jednom suradniku mogao bi imati oblik prikazan Slikom 4.1. Vidimo da se tu pojavio pod-zapis s osobnim podacima samog suradnika, te ponavljajuća skupina koja se ponavlja za svako dijete tog suradnika. Podaci očito nisu u 1NF.

SURADNIK
MATIĈNI BROJ SURADNIKA OSOBNI PODACI SURADNIKA
PREZIME IME GODINA ROĐENJA

IME DJETETA

GODINA ROĐENJA DJETETA

Slika 4.1: Nenormalizirani zapis o suradniku.

Da bismo nenormalizirane podatke pohranili u relacijskoj bazi, moramo ih prevesti u 1NF. Dakle, uvoĎenjem dovoljnog broja relacija i atributa moramo eliminirati sve ponavljajuće skupine i pod-zapise. Postupak prevoĎenja izgleda otprilike ovako.  Uvodi se jedna osnovna relacija, te onoliko pomoćnih relacija koliko ima ponavljajućih skupina.  Fiksni dio zapisa prikazuje se kao jedna n-torka u osnovnoj relaciji, s time da je svaki pod-zapis rastavljen na nekoliko zasebnih atributa.  Svaka pojava ponavljajuće skupine unutar zapisa prikazuje se kao zasebna n-torka u odgovarajućoj pomoćnoj relaciji. Zbog čuvanja veze s polaznim zapisom u tu n-torku se prepisuje i neki od identifikacijskih podataka iz fiksnog dijela zapisa.

R
A B C
D E

F

G

R (A, B, C-D, C-E ) S (A, F, G )
Slika 4.2: Shematski prikaz prevoĎenja u 1NF. 56 PMF – Matematički odsjek

Baze podataka - skripta

Postupak prevoĎenja u 1NF shematski je prikazan Slikom 4.2. Na toj slici vidi se pretvorba jednog pod-zapisa i jedne ponavljajuće skupine. Ako imamo više pod-zapisa ili više ponavljajućih skupina, tada se zahvati sa Slike 4.2 moraju iterirati. Ako ovaj postupak prevoĎenja u 1NF primijenimo na naše zapise o suradnicima sa Slike 4.1, dobit ćemo sljedeće dvije relacije. SURADNIK (MATIĈNI BROJ SURADNIKA, PREZIME SURADNIKA, IME SURADNIKA, GODINA ROĐENJA SURADNIKA) DIJETE (MATIĈNI BROJ SURADNIKA, IME DJETETA, GODINA ROĐENJA DJETETA) . Na primjer, podaci o suradniku koji ima troje djece bit će prikazani jednom n-torkom u relaciji SURADNIK i trima n-torkama u relaciji DIJETE (po jedna za svako dijete). Veza izmeĎu te četiri n-torke uspostavlja se na osnovu iste vrijednosti MATIĈNOG BROJA SURADNIKA. 4.1.2. Funkcionalne ovisnosti između atributa ili skupina atributa Većina normalnih formi zasnovana je na pojmu funkcionalne ovisnosti izmeĎu atributa ili skupina atributa. Zato, prije nego što počnemo govoriti o drugoj, trećoj ili višim normalnim formama, moramo naučiti što je to funkcionalna ovisnost. Za zadanu relaciju R, atribut B od R je funkcionalno ovisan o atributu A od R (oznaka: A → B) ako vrijednost od A jednoznačno odreĎuje vrijednost od B. Dakle ako u isto vrijeme postoje u R dvije n-torke s jednakom vrijednošću od A, tada te n-torke moraju imati jednaku vrijednost od B. Analogna definicija primjenjuje se i za slučaj kad su A i B sloţeni atributi (dakle skupine atributa). Kao primjer za postojanje funkcionalnih ovisnosti, promotrimo sljedeću (namjerno loše oblikovanu) relaciju: UPISAO (JMBAG, ŠIFRA PREDMETA, NASLOV PREDMETA, OIB NASTAVNIKA, BROJ SOBE NASTAVNIKA, OCJENA) . Riječ je opet o relaciji koja biljeţi da su studenti upisali predmete na fakultetu i dobili iz njih odgovarajuće ocjene. Uzimamo da JMBAG jednoznačno odreĎuje studenta, a ŠIFRA PREDMETA jednoznačno odreĎuje predmet. Pretpostavljamo da svaki predmet ima jednog nastavnika, a svaki nastavnik jednu sobu. TakoĎer smatramo da OIB NASTAVNIKA jednoznačno odreĎuje nastavnika. Vidimo da u relaciji postoji velik broj funkcionalnih ovisnosti. Navodimo neke od njih: (JMBAG, ŠIFRA PREDMETA) → OCJENA , ŠIFRA PREDMETA → NASLOV PREDMETA , ŠIFRA PREDMETA → OIB NASTAVNIKA , ŠIFRA PREDMETA → BROJ SOBE NASTAVNIKA , OIB NASTAVNIKA → BROJ SOBE NASTAVNIKA .

PMF – Matematički odsjek

57

ŠIFRA PREDMETA → BROJ SOBE NASTAVNIKA . u prethodnoj relaciji UPISAO. Primijetimo da definicija 2NF zaista ima smisla jedino ako je primarni ključ relacije sloţen.  Iz polazne relacije izbacuju se i prebacuju u nove svi oni atributi koji su parcijalno ovisni o ključu. Očito. u njoj postoje parcijalne ovisnosti: ŠIFRA PREDMETA → NASLOV PREDMETA . te BROJ SOBE NASTAVNIKA nisu potpuno funkcionalno ovisni o primarnom ključu. Preciznije:  Uz polaznu relaciju dodaje se onoliko novih relacija koliko ima različitih dijelova primarnog ključa koji sudjeluju u parcijalnim ovisnostima. te se preporuča da se ona prevede u 2NF. Postupak prevoĎenja svodi se na razbijanje polazne relacije u barem dvije.  Uz prebačene atribute. no B nije funkcionalno ovisan ni o jednom pravom podskupu od A.3. U skladu s prethodno rečenim. Da bi se parcijalne ovisnosti mogle „proskribirati“. no pritom se sačuvaju svi semantički odnosi meĎu podacima. kao što će biti pokazano u Odjeljku 4. Relacija je u drugoj normalnoj formi (oznaka: 2NF) ako je svaki njezin ne-primarni atribut potpuno funkcionalno ovisan o primarnom ključu.Robert Manger U slučaju funkcionalne ovisnosti o skupini atributa. svaki atribut relacije je funkcionalno ovisan o ključu. 4. Za njih kaţemo da su parcijalno ovisni o tom ključu. budući da su ovisni samo o ŠIFRA PREDMETA. relacija je u 2NF ako u njoj nema parcijalnih ovisnosti atributa o primarnom ključu. ŠIFRA PREDMETA → OIB NASTAVNIKA .1. te on postaje ključ u toj novoj relaciji. atribut B od R je potpuno funkcionalno ovisan o (sloţenom) atributu A od R ako vrijedi: B je funkcionalno ovisan o A. tako da se prekinu nepoţeljne parcijalne ovisnosti. uvodi se još i dodatni pojam potpune funkcionalne ovisnosti. Za zadanu relaciju R. Parcijalna ovisnost smatra se nepoţeljnim svojstvom. relacija koja nije u 2NF loše je oblikovana. no ta ovisnost ne mora biti potpuna. kao što smo već rekli. NASLOV PREDMETA. a ne i o JMBAG-u. ŠIFRA PREDMETA).1.3. 58 PMF – Matematički odsjek . Drugim riječima. Parcijalne ovisnosti. S druge strane. Relacija s jednostavnim ključem (dakle ključem koji se sastoji samo od jednog atributa) automatski je u 2NF. Relacija UPISAO nije u 2NF jer. OIB NASTAVNIKA.  Pritom u jednu novu relaciju idu oni atributi koji su ovisni o istom dijelu primarnog ključa. Naime ona moţe uzrokovati teškoće kod manipuliranja s podacima. Na primjer. prevođenje relacije u drugu normalnu formu Vidjeli smo da u prethodnoj relaciji UPISAO postoje atributi NASLOV PREDMETA . OIB NASTAVNIKA i BROJ SOBE NASTAVNIKA koji nisu potpuno funkcionalno ovisni o primarnom ključu. atribut OCJENA je potpuno funkcionalno ovisan o primarnom ključu (JMBAG. Vaţna vrsta funkcionalne ovisnosti koju redovito susrećemo u svakoj relaciji je ovisnost atributa o ključu. uvodi se pojam druge normalne forme. u novu relaciju prepisuje se i odgovarajući dio primarnog ključa.

ili parcijalne ovisnosti iz raznih dijelova ključa. pod uvjetom da srednji atribut nije kandidat za ključ. pa je zato dobila ime PREDMET.1. Pritom OIB NASTAVNIKA zaista nije kandidat za ključ u relaciji PREDMET budući da isti nastavnik moţe predavati više predmeta. D ) R (A.4. i tranzitivna ovisnost se smatra nepoţeljnim svojstvom. D ) Slika 4. C. BROJ SOBE NASTAVNIKA je tranzitivno ovisan o ŠIFRI PREDMETA. 4. Ta nova relacija zapravo opisuje predmet na fakultetu. TakoĎer. OCJENA) PREDMET (ŠIFRA PREDMETA. PREDMET ima jednostavan ključ pa je automatski u 2NF. posredstvom OIB NASTAVNIKA. OIB NASTAVNIKA. Vidimo da ŠIFRA PREDMETA postaje ključ u novoj relaciji. te su u nju prebačeni svi parcijalno-ovisni atributi zajedno sa ŠIFROM PREDMETA. uvodi se pojam treće normalne forme.1. R (A. C ) S (A. NASLOV PREDMETA. prevođenje relacije u treću normalnu formu Primijetimo da u prethodnoj relaciji PREDMET postoji sljedeći niz funkcionalnih ovisnosti: ŠIFRA PREDMETA → OIB NASTAVNIKA → BROJ SOBE NASTAVNIKA . Naime. PMF – Matematički odsjek 59 . Slično kao parcijalna ovisnost.3. Naime i ona moţe uzrokovati slične teškoće kod manipuliranja s podacima. u polaznoj verziji UPISAO sve parcijalne ovisnosti kreću iz istog dijela ključa. tada se zahvati sa Slike 4. Postupak prevoĎenja u 2NF shematski je prikazan Slikom 4. B. a to je ŠIFRA PREDMETA. obje relacije su u 2NF. Zato postupak prevoĎenja stvara samo jednu novu relaciju.Baze podataka . U našem slučaju. Nakon opisanog prevoĎenja. Ako imamo više parcijalnih ovisnosti iz istog dijela ključa. Tranzitivne ovisnosti. što će takoĎer biti pokazano u Odjeljku 4. Ovakav niz. Na toj slici pretpostavljeno je da polazna relacija ima samo jednu parcijalnu ovisnost. B. Zaista.3 moraju iterirati.3. u preostaloj verziji UPISAO više nema parcijalnih ovisnosti pa ona zadovoljava definiciju 2NF. Da bi se i tranzitivne ovisnosti mogle „proskribirati“. nazivamo tranzitivna ovisnost. postupak prevoĎenja u 2NF razbit će polaznu relaciju UPISAO u sljedeće dvije relacije: UPISAO (JMBAG. BROJ SOBE NASTAVNIKA) .3: Shematski prikaz prevoĎenja u 2NF. ŠIFRA PREDMETA.skripta U našem konkretnom primjeru.

u preostaloj verziji PREDMET više nema tranzitivnih ovisnosti pa ona zadovoljava definiciju 3NF. postupak prevoĎenja u 3NF razbija polaznu relaciju PREDMET u sljedeće dvije relacije: PREDMET (ŠIFRA PREDMETA. TakoĎer. Dakle polazna relacija se razbija u barem dvije. B. vrijedi: X sadrţi ključ za R ili je A primarni atribut. NASTAVNIK ima samo dva atributa pa je sigurno u 3NF.4: Shematski prikaz prevoĎenja u 3NF.Robert Manger Relacija je u trećoj normalnoj formi (oznaka: 3NF) ako je u 2NF i ako ne sadrţi tranzitivne ovisnosti. Nakon opisanog prevoĎenja. u polaznoj verziji od PREDMET postojala je samo jedna tranzitivna ovisnost sa srednjim atributom OIB NASTAVNIKA. takvu da A nije dio od X. relacija R je u 3NF ako za svaku funkcionalnu ovisnost X → A u R. Preciznije. relacija koja nije u 3NF loše je oblikovana.  Iz polazne relacije izbacuju se i prebacuju u nove svi oni atributi koji su tranzitivno ovisni. C ) R (A. obje relacije su u 3NF. te da nova relacija zapravo opisuje nastavnika i u skladu s time dobiva ime NASTAVNIK. R (A. PMF – Matematički odsjek 60 . C ) Slika 4. Zato postupak prevoĎenja stvara samo jednu novu relaciju. U našem konkretnom primjeru. Preciznije:  Uz polaznu relaciju dodaje se onoliko novih relacija koliko ima različitih atributa koji se pojavljuju kao srednji atributi u tranzitivnim ovisnostima. Opet u skladu s prethodno rečenim. u novu relaciju prepisuje se i odgovarajući srednji atribut. OIB NASTAVNIKA) NASTAVNIK (OIB NASTAVNIKA. tako da se prekinu nepoţeljne tranzitivne ovisnosti. te on postaje ključ u toj novoj relaciji. te je u nju prebačen tranzitivno-ovisni atribut BROJ SOBE NASTAVNIKA zajedno s OIB NASTAVNIKA. Postupak prevoĎenja u 3NF sličan je postupku za 2NF. a da pritom ne doĎe do nikakvog gubitka informacije.  Pritom u jednu novu relaciju idu oni atributi u čijim tranzitivnim ovisnostima se pojavljuje isti srednji atribut. Naime. te se preporuča da se ona prevede u 3NF. a BROJ SOBE NASTAVNIKA nije primarni atribut. Vidimo da OIB NASTAVNIKA postaje ključ u novoj relaciji. a pritom OIB NASTAVNIKA nije ključ. B ) S (B. Naime. Prije navedena relacija PREDMET nije u 3NF jer imamo funkcionalnu ovisnost OIB NASTAVNIKA → BROJ SOBE NASTAVNIKA .  Uz prebačene atribute. BROJ SOBE NASTAVNIKA) . NASLOV PREDMETA.

Kasniji autori uveli su i šestu normalnu formu. Zato najprije moramo objasniti taj pojam. Na toj slici pretpostavljeno je da polazna relacija ima samo jednu tranzitivnu ovisnost. Postupak prevoĎenja analogan je onom PMF – Matematički odsjek 61 . no vrlo rijetko se susreću relacije u 3NF koje nisu u višim normalnim formama. ŠIFRA PREDMETA i OIB NASTAVNIKA. Zato su te više normalne forme prvenstveno od teorijskog značaja. OIB NASTAVNIKA. ili tranzitivne ovisnosti s raznim srednjim atributima. Determinanta je atribut (ili kombinacija atributa) unutar neke relacije o kojem je neki drugi atribut unutar iste relacije potpuno funkcionalno ovisan. Edgar Codd je definirao pojačanu varijantu 2NF i 3NF koja se zove Boyce-Codd-ova normalna forma. Preporuča se da se ona prevede u BCNF.skripta Postupak prevoĎenja u 3NF shematski je prikazan Slikom 4. BROJ SOBE NASTAVNIKA. 4. OIB NASTAVNIKA → BROJ SOBE NASTAVNIKA . Boyce-Coddova normalna forma je posebno zanimljiva jer ona moţe posluţiti kao efikasna zamjena za 2NF i 3NF. teorija normalizacije nije se zaustavila na tome. dakle: UPISAO (JMBAG. Kao primjer relacije koja nije u BCNF moţe nam posluţiti ona ista koju smo promatrali kad smo govorili o 2NF i 3NF. ŠIFRA PREDMETA → OIB NASTAVNIKA . godine uveo četvrtu i petu normalnu formu. i pritom nijedna od njih nije kandidat za ključ. Mi ćemo ipak opisati Boyce-Coddovu i četvrtu normalnu formu. U svojim kasnijim radovima iz druge polovice 70-tih godina 20. 3NF. Ponovo uočavamo sljedeće funkcionalne ovisnosti: ŠIFRA PREDMETA → NASLOV PREDMETA . Dakle relacija nije u BCNF.2. stoljeća. Ako imamo više tranzitivnih ovisnosti s istim srednjim atributom. NASLOV PREDMETA. te mogućim izvorom poteškoća.4. 4. U praksi je lako naići na relacije koje odstupaju od 2NF.1. ŠIFRA PREDMETA. Ronald Fagin je 1977.Baze podataka . i 1979.4 moraju iterirati. Vidimo da postoje dvije determinante. no nećemo se baviti ni petom ni šestom formom. tada se zahvati sa Slike 4. Boyce-Codd-ova i četvrta normalna forma Makar su za svakodnevne potrebe obično dovoljne i prve tri normalne forme. OCJENA) .2. Slično kao prije. relacija koja nije u BCNF smatra se loše oblikovanom. Relacija je u Boyce-Codd-ovoj normalnoj formi (oznaka: BCNF) ako je svaka njezina determinanta ujedno i kandidat za ključ. prevođenje relacije u Boyce-Coddovu normalnu formu Definicija Boyce-Codd-ove normalne forme zasnovana je na pojmu determinante. a tek nakon toga moţemo izreći definiciju same normalne forme. Determinante.

 Uz prebačene atribute. Drukčije rečeno. Vidimo da smo sad jednim prevoĎenjem dobili ono isto rješenje za koje su prije bila potrebna dva prevoĎenja.Robert Manger za 2NF ili 3NF. BCNF predstavlja efikasnu i kompaktnu zamjenu za 2NF i 3NF. Drugim riječima. Detaljnije:  Uz polaznu relaciju dodaje se onoliko novih relacija koliko ima različitih takvih determinanti. te ona postaje ključ u toj novoj relaciji. Dakle polazna relacija se na pogodan način razbija u nekoliko manjih. OCJENA) PREDMET (ŠIFRA PREDMETA. Situacija je slična onoj na glazbenoj akademiji. BROJ SOBE NASTAVNIKA) . gdje je opet pretpostavljeno da JMBAG jednoznačno odreĎuje studenta. 2NF i 3NF postoji bliska veza. tako da se prekinu nepoţeljne ovisnosti o determinanti koja nije kandidat za ključ. Zato BCNF uključuje u sebi sve zahtjeve koje postavljaju 2NF i 3NF. U tom smislu. Ili obratno. Dakle. NASLOV PREDMETA. Razlog je u tome što pojam determinante poopćuje razne oblike funkcionalnih ovisnosti koje smo prije razmatrali.  Iz polazne relacije izbacuju se i prebacuju u nove svi oni atributi koji su ovisni o nekoj tih determinanti. Na osnovu ovih primjedbi moglo bi se pomisliti da je BCNF zapravo ekvivalentna 2NF i 3NF. relacija koja jeste u BCNF mora nuţno biti u 2NF i 3NF. te da je riječ samo o drukčijoj formulaciji istih svojstava. ona ne moţe biti ni u BCNF. 4. gdje postoji više nastavnika violine. OIB NASTAVNIKA) NASTAVNIK (OIB NASTAVNIKA. no ima samo jednog nastavnika za zadani predmet. Zaista: i parcijalne i tranzitivne ovisnosti zapravo odreĎuju neku vrstu determinante koja nije kandidat za ključ. Ako ovaj postupak prevoĎenja u BCNF primijenimo na našu polaznu relaciju UPISAO.  Pritom u jednu novu relaciju idu oni atributi koji su ovisni o istoj determinanti. a ŠIFRA PREDMETA predmet: 62 PMF – Matematički odsjek . najprije u 2NF. Naš primjer odnosi se na fakultet gdje jedan predmet predaje više nastavnika.2. Sve skupa moţe se opisati sljedećom relacijom. ona se zbog postojanja dviju determinanti koje nisu kandidat za ključ razbija na ukupno tri relacije koje izgledaju ovako: UPISAO (JMBAG. BCNF se moţe smatrati „trećom-i-pol normalnom formom“. Primjeri relacija koje jesu u 2NF i 3NF no nisu u BCNF zapravo su vrlo rijetki. U nastavku ćemo izloţiti jedan takav primjer – on se zasniva na postojanju dva kandidata za ključ koja su oba sloţena i preklapaju se u jednom atributu. u novu relaciju prepisuje se i sama determinanta. ali svaki nastavnik predaje samo jedan predmet. Svaki student upisuje više predmeta. a svaki student uči jedan instrument „u klasi“ samo jednog nastavnika. makar relacija koja je u BCNF nuţno mora biti u 2NF i 3NF.2. Odnos Boyce-Codd-ove prema drugoj i trećoj normalnoj formi Upravo smo vidjeli da izmeĎu BCNF. ili više nastavnika klavira. OIB NASTAVNIKA odreĎuje nastavnika. ŠIFRA PREDMETA. No pokazuje se da BCNF ipak postavlja na relaciju malo jači zahtjev od 2NF i 3NF. ako relacija nije u 2NF ili 3NF. moţe se desiti da relacija koja jest u 2NF i 3NF ipak nije u BCNF. zatim u 3NF.

3. Promatrajmo opet relaciju IZVOZI koja nam je poznata iz prošlog poglavlja i koja prikazuje vezu izmeĎu kompanija. relacija nije ni u 2NF. Obje novonastale relacije su u BCNF.5: Shematski prikaz prevoĎenja u BCNF. Pritom determinanta OIB NASTAVNIKA nije kandidat za ključ jer moţe postojati više studenata koji su upisali nastavnikov predmet u njegovoj klasi. Višeznačne ovisnosti. Znači zaista imamo primjer relacije koja je u 2NF i 3NF no nije u BCNF. OIB NASTAVNIKA.skripta UPISAO (JMBAG. proizvoda i zemalja: PMF – Matematički odsjek 63 . Sad je relacija u 2NF i 3NF. Pritom smo im dali imena koja najbolje opisuju njihovo značenje. OIB NASTAVNIKA) PREDAJE (OIB NASTAVNIKA. R (A.2. Iz prve od njih vidimo u čijoj klasi je odreĎeni student upisao odreĎeni (to jest nastavnikov) predmet. ŠIFRA PREDMETA) . ona se raspada na sljedeće dvije relacije: KLASA (JMBAG. B. no ne i u BCNF jer i dalje postoji ovisnost: OIB NASTAVNIKA → ŠIFRA PREDMETA . B ) T ( A. Kao u našem primjeru.5. jer postoji parcijalna ovisnost OIB NASTAVNIKA → ŠIFRA PREDMETA . Ista relacija tada izgleda ovako: UPISAO (JMBAG. ŠIFRA PREDMETA) . C ) S ( A. 4. a iz druge vidimo koji to predmet predaje odreĎeni nastavnik. OIB NASTAVNIKA) . No mi moţemo drukčije izabrati primarni ključ. Postupak prevoĎenja u BCNF za slučaj relacije koja jeste u 2NF i 3NF shematski je prikazan Slikom 4. prevođenje relacije u četvrtu normalnu formu Četvrtu normalnu formu najlakše je opisati pomoću primjera. ŠIFRA PREDMETA. Uz ovako odreĎeni primarni ključ. C ) Slika 4. Ako na zadnju verziju relacije UPISAO primijenimo naš postupak prevoĎenja u BCNF.Baze podataka . na slici je pretpostavljeno da polazna relacija ima dva kandidata za ključ koja su oba sloţena i preklapaju se u jednom atributu.

6. IME ZEMLJE). Lagano je provjeriti da je relacija u BCNF. Atributi IME KOMPANIJE. Dosadašnja pravila normalizacije ne pomaţu nam da eliminiramo redundanciju u relaciji IZVOZI. Pokazuje se da je to zato što redundancija nije bila uzrokovana funkcionalnim ovisnostima. IME PROIZVODA. IME PROIZVODA. IME ZEMLJE) . 64 PMF – Matematički odsjek . Ako prihvatimo da vrijedi takvo pravilo.6 stječe se dojam da vrijedi pravilo: čim kompanija izvozi u neku zemlju. Podacima s prethodne Slike 4. tada nam postaje očito da relacija IZVOZI mora sadrţavati veliku dozu redundancije.6: Primjer relacije koja nije u četvrtoj normalnoj formi.Robert Manger IZVOZI (IME KOMPANIJE. Uočena redundancija će se eliminirati ako zamijenimo polaznu relaciju IZVOZI s dvije manje relacije RADI i PRODAJE: RADI (IME KOMPANIJE. već takozvanim višeznačnim ovisnostima. Jedna n-torka relacije IZVOZI izraţava činjenicu da zadana kompanija svoj zadani proizvod izvozi u zadanu zemlju. ona odmah izvozi sve svoje proizvode u tu zemlju. IZVOZI IME KOMPANIJE IBM IBM IBM IBM IBM IBM HP HP HP HP HP HP Fujitsu Fujitsu IME PROIZVODA Desktop Desktop Desktop Mainframe Mainframe Mainframe Desktop Desktop Desktop Server Server Server Mainframe Mainframe IME ZEMLJE Francuska Italija Velika Britanija Francuska Italija Velika Britanija Francuska Španjolska Irska Francuska Španjolska Irska Italija Francuska Slika 4.7. odnosno IME ZEMLJE jednoznačno odreĎuju primjerke odgovarajućih entiteta. U nastavku slijedi odgovarajuća definicija. U jednom trenutku ona moţe izgledati kao na Slici 4. IME PROIZVODA) PRODAJE (IME KOMPANIJE.6 tada odgovaraju podaci na Slici 4. Na osnovu podataka na Slici 4.

skripta RADI IME KOMPANIJE IBM IBM HP HP Fujitsu PRODAJE IME KOMPANIJE IBM IBM IBM HP HP HP Fujitsu Fujitsu IME PROIZVODA Desktop Mainframe Desktop Server Mainframe IME ZEMLJE Francuska Italija Velika Britanija Francuska Španjolska Irska Italija Francuska Slika 4. skup proizvoda koje zadana kompanija izvozi u zadanu zemlju ovisi samo o kompaniji a ne o zemlji. moţe se matematički dokazati da čim u relaciji R (A. uvodi se pojam četvrte normalne forme. skup zemalja u koje zadana kompanija izvozi zadani proizvod ovisi samo o kompaniji a ne i o proizvodu. tada su svi atributi od R funkcionalno ovisni o A. Cvrijednost) ovisi samo o A-vrijednosti. Višeznačna ovisnost od A do B (oznaka: A →→ B) vrijedi ako skup B-vrijednosti koje se u R pojavljuju uz zadani par (A-vrijednost. nuţno mora vrijediti i ovisnost A →→ C. U našem primjeru. R je u 4NF ako je u BCNF i sve višeznačne ovisnosti u R su zapravo funkcionalne ovisnosti. Nije slučajno da su se odmah pojavile dvije višeznačne ovisnosti. a ne i o C-vrijednosti. Analogna definicija primjenjuje se i kad su A. B i C sloţeni atributi (dakle skupine atributa). Da bi se takva ovisnost mogla eliminirati. Takve ovisnosti zapravo se uvijek pojavljuju u paru. B. Zato kod nas vrijede sljedeće višeznačne ovisnosti: IME KOMPANIJE →→ IME PROIZVODA . B. Ekvivalentno.Baze podataka . Slično. na primjer A →→ B. PMF – Matematički odsjek 65 . C) postoji ovisnost A →→ B.7: PrevoĎenje u četvrtu normalnu formu. C). Iz upravo objašnjenih razloga. IME KOMPANIJE →→ IME ZEMLJE . Zadana je relacija s tri atributa: R (A. Relacija R je u četvrtoj normalnoj formi (oznaka: 4NF) ako vrijedi: kad god postoji višeznačna ovisnost u R. višeznačna ovisnost smatra se nepoţeljnom pojavom. Naime.

BROJ SOBE NASTAVNIKA. teškoće su otprilike slične. OCJENA) . Ilustrirat ćemo to na primjerima relacija iz prethodnih odjeljaka. Do teškoća u radu s UPISAO dolazi onda kad preko nje pokušavamo upravljati podacima o nastavnicima ili predmetima. promjene i brisanja podataka. C ) Slika 4. Primjer s relacijom IZVOZI otkriva nam i općenitu postupak za prevoĎenje relacije u 4NF. koja nije u 2NF. Promatrajmo opet polaznu verziju relacije UPISAO iz Odjeljka 4. tako da u njima nema višeznačnih ovisnosti. OIB NASTAVNIKA.3.3. ŠIFRA PREDMETA.1. Potreba za normalizacijom Normalizacija je u prvom redu potrebna zato jer se njome izbjegavaju teškoće koje bi nastupile ako bi radili s nenormaliziranim podacima. Znači. NASLOV PREDMETA. veza i atributa. 4. Polazna relacija uvijek ima tri atributa (ili tri skupine atributa) i dvije višeznačne ovisnosti. Teškoće u radu s nenormaliziranim podacima Ako relacije nisu normalizirane. B.8: Shematski prikaz prevoĎenja u 4NF. Te dvije jednostavnije relacije sigurno jesu u 4NF budući da svaka od njih ima po dva atributa.3. R ( A. B ) T ( A. U nastavku ovog potpoglavlja detaljnije ćemo raspraviti o ovim tvrdnjama. osim što biljeţi koji student je upisao koji predmet. ni jedna od uočenih višeznačnih ovisnosti nije funkcionalna ovisnost. IZVOZI nije u 4NF i zato je treba rastaviti na RADI i PRODAJE. takoĎer govori i o nastavnicima i predmetima: UPISAO (JMBAG.8. Sve je to shematski prikazano Slikom 4.Robert Manger U našoj relaciji IZVOZI. Primijetimo da ta relacija. dolazi do teškoća kod unosa.  Polaznu relaciju pretvaramo u dvije manje relacije od po dva atributa (odnosno dvije skupine atributa).1.  U svaku od novih relacija stavljamo po dva atributa (odnosno dvije skupine atributa) koji u polaznoj relaciji sudjeluju u istoj višeznačnoj ovisnosti. Na primjer: 66 PMF – Matematički odsjek . Bez obzira o kojoj normalnoj formi je riječ. Od normalizacije moţemo odustati samo u nekim rijetkim situacijama. C ) S ( A. no i tada moramo biti svjesni eventualnih loših posljedica takve odluke. Postupak izgleda ovako. 4. Normalizacija je korisna i zato jer se njome naknadno otkrivaju i ispravljaju greške u oblikovanju entiteta.

to ne moţemo učiniti sve dok bar jedan student ne upiše taj predmet (naime ne smijemo imati praznu vrijednost primarnog atributa JMBAG). Ako zaboravimo neki od tih predmeta. ona odmah izvozi sve svoje proizvode u tu zemlju: PMF – Matematički odsjek 67 . te promijeniti vrijednost za NASLOV PREDMETA u svim takvim n-torkama.  Da bismo promijenili broj sobe odreĎenog nastavnika. govori i o nastavnicima: PREDMET (ŠIFRA PREDMETA.  Ako nastavnik privremeno ne predaje ni jedan predmet. onoliko puta koliko ima studenata u klasi tog nastavnika. OIB NASTAVNIKA. Na primjer:  Ne moţemo evidentirati činjenicu da zadani nastavnik predaje zadani predmet.Baze podataka . Do teškoća u radu s PREDMET dolazi baš onda kad preko nje pokušavamo mijenjati podacima o nastavnicima. proizvoda i zemalja.4. ako ţelimo unijeti podatke o novom nastavniku i njegovoj sobi.skripta  Ako u bazu ţelimo unijeti podatke o novom predmetu. koja se odnosi na glazbenu akademiju i koja nije u BCNF. Do teškoća u radu s ovom verzijom relacije UPISAO doći će opet onda kad preko nje počnemo raditi s podacima o predmetima i nastavnicima. govori i o samim predmetima i nastavnicima: UPISAO (JMBAG.2. Promatrajmo na kraju relaciju IZVOZI iz Odjeljka 4. Ako zaboravimo izvršiti neku od promjena. Primijetimo da ta relacija.   Promatrajmo dalje relaciju PREDMET iz Odjeljka 4. sve dok bar jedan student ne upiše taj predmet baš kod tog nastavnika. iz baze će nestati svi podaci o tom predmetu. imat ćemo kontradiktorne podatke. Ako shodno tome pobrišemo odgovarajuće n-torke. Promatrajmo zatim relaciju UPISAO iz Odjeljka 4. tada moramo naći sve n-torke koje sadrţe odgovarajuću vrijednost za ŠIFRU PREDMETA. osim o tome koji student je upisao koji predmet. Ako ţelimo promijeniti naslov nekog postojećeg predmeta. OIB NASTAVNIKA) . Na primjer:  Ne moţemo unijeti podatke o novom nastavniku i njegovoj sobi. BROJ SOBE NASTAVNIKA) . to ne moţemo učiniti dok tog nastavnika ne zaduţimo s bar jednim predmetom i dok bar jedan student ne upiše taj predmet. što oteţava aţuriranje. Bit će onoliko promjena koliko ima studenata koji su upisali taj predmet. Primijetimo da ta relacija. Pretpostavimo da svi studenti koji su upisali neki predmet naknadno odustanu od tog predmeta. Slično.1. moramo izvršiti promjenu u svakoj n-torki koja odgovara nekom predmetu kojeg predaje taj nastavnik. tada iz baze nestaju svi podaci o njemu i njegovoj sobi.  Ako svi studenti u klasi nekog nastavnika odustanu od sudjelovanja u klasi. osim o predmetima. ŠIFRA PREDMETA. NASLOV PREDMETA. imat ćemo kontradiktorne podatke. sve dok ga nismo zaduţili s bar jednim predmetom.2.3 koja prikazuje vezu izmeĎu kompanija. koja nije u 3NF. briše se evidencija da taj nastavnik predaje taj predmet. Ta relacija nije u 4NF zbog pretpostavljenog pravila da čim kompanija izvozi u neku zemlju.  Veza nastavnika i predmeta zapisana je s velikom redundancijom.2.

ne dobivamo posebnu relaciju za studente. U skladu s ovom primjedbom. pojavu nenormaliziranih podataka moţemo promatrati kao rezultat greške u postupku oblikovanja.1.1 dobili prevoĎenjem u 1NF. te da predavanje predmeta od strane nastavnika predstavlja vezu izmeĎu predmeta i nastavnika. no to je zato što u polaznim podacima nismo imali nikakvih atributa za studente osim JMBAG. neki od njih pokušavaju istovremeno opisati više tipova entiteta. Postupak prevoĎenja iz Odjeljaka 4. TakoĎer nastaju nove relacije PREDMET i NASTAVNIK koje odgovaraju istoimenim entitetima.1. To nije u skladu s postupkom oblikovanja opisanim u Poglavljima 2 i 3. Umjesto toga. Veza izmeĎu predmeta i nastavnika ispravno se realizira preko stranog ključa u relaciji PREDMET. IME PROIZVODA.  Da bismo evidentirali da je neka kompanija počela izvoziti u neku novu zemlju. dakle u pogrešnom prepoznavanju entiteta. Naime. trebalo je uočiti da kao tipove entiteta zapravo imamo studente i predmete. U nastavku ćemo detaljnije analizirati primjere nenormaliziranih podataka iz prethodnih odjeljaka. morat ćemo unijeti onoliko n-torki koliko ima proizvoda te kompanije. treći opet istovremeno zapisuju više veza. Zapis SURADNIK iz Odjeljka 4. Na primjer:  Da bismo evidentirali da neka kompanija ima novi proizvod. a ponavljajuću skupinu o djetetu bismo proglasili zasebnim entitetom. pod-zapis s osobnim podacima suradnika odmah bismo razbili u više jednostavnih atributa. Naime. TakoĎer. tu se krši pravilo da vrijednosti atributa za entitet koji odgovara suradniku moraju biti jednostavne i jednostruke. ili relacijama koje biljeţe jednu i samo jednu vezu.3. Relacija UPISAO iz Odjeljka 4. zatim u 3NF. Doduše. Naime.1 koji nije ni u 1NF očito nije mogao nastati ispravnom primjenom postupka oblikovanja entiteta. Do teškoća u radu s relacijom IZVOZI dolazi zbog toga što ona s velikom redundancijom opisuje dvije nezavisne veze izmeĎu triju entiteta. Zaista. morat ćemo unijeti onoliko n-torki koliko ima zemalja u koje ta kompanija izvozi svoje proizvode. Kad bismo takvu ispravnu konceptualnu shemu pretvorili u relacije.3 koja nije u 2NF nastala je zato što se dogaĎaj upisivanja predmeta od strane studenta pogrešno interpretirao kao zasebni tip entiteta s vlastitim atributima. trebalo je uočiti da postoji i tip entiteta za nastavnike. atributa i veza. postepeno ispravlja te greške. IME ZEMLJE) .1. morao bi rezultirati relacijama koje govore o jednom i samo jednom entitetu.1. najprije u 2NF. taj postupak.3 i 4.Robert Manger IZVOZI (IME KOMPANIJE. Izvor takve greške obično se nalazi već u oblikovanju konceptualne sheme. tim postupkom relacija UPISAO reducira se u oblik koji sluţi isključivo za biljeţenje veze izmeĎu studenata i predmeta. Da smo poštovali to pravilo. drugi biljeţe vezu izmeĎu entiteta no istovremeno navode i svojstva samih entiteta. te ćemo odrediti greške u konceptualnom oblikovanju koje su dovele do njihove pojave. te da je upisivanje samo veza izmeĎu tih tipova. te bismo uveli vezu izmeĎu suradnika i djece. ukoliko je ispravno proveden. 68 PMF – Matematički odsjek .4. 4.2.1. odmah bismo dobili one iste relacije koje smo u Odjeljku 4. Normalizacija kao ispravak konceptualnih grešaka U prethodnom odjeljku uočili smo da svi nenormalizirani podaci imaju jednu zajedničku osobinu: oni pokušavaju govoriti o više stvari u isto vrijeme. veza i atributa.

zaključujemo da pravila normalizacije nisu ništa drugo nego formalni opis intuitivno prihvatljivih principa o zdravom i prirodnom oblikovanju entiteta. Ako imamo aplikacije kod kojih se zahtijeva izuzetno velika brzina odziva. promatrajmo sljedeću relaciju: KUPAC (OIB KUPCA. POŠTANSKI BROJ. Efikasna uporaba podataka. oblikovanje uspijemo provesti na ispravan način. tada je bolje da su podaci za njih već pripremljeni u nenormaliziranom obliku. Dešava se da nekoliko atributa u relaciji čine cjelinu koja se u aplikacijama nikad ne rastavlja na sastavne dijelove.2. PREZIME. Normalizacija predstavlja mehanizam naknadnog prepoznavanja i ispravljanja grešaka. SvoĎenjem u normalnu formu pogrešno oblikovane relacije ponovo se vraćaju u onaj oblik koje bi imale da grešaka nije bilo.  PMF – Matematički odsjek 69 . nastala je zato što smo odnose izmeĎu nastavnika. pa relacija nije u 3NF. Budući da se podaci iz adrese rabe i aţuriraju „u paketu“. Uspostavljanje veza meĎu podacima u manjim relacijama traje znatno dulje nego čitanje podataka koji su već povezani i upisani u jednu veliku ntorku.3. No postoje razlozi zbog kojih iznimno moţemo odustati čak i od takve skromne normalizacije. Navest ćemo dva moguća razloga. Razlozi kad se ipak može odustati od normalizacije Već smo napomenuli da je za većinu praktičnih primjera dovoljno relacije normalizirati do 3NF. 4. odmah bi nastale one iste relacije RADI i PRODAJE koje smo mi dobili kao rezultat prevoĎenja u 4NF. Na primjer. Na osnovu svega izloţenog.3. No mi znamo da POŠTANSKI BROJ. Naime. To naravno ne znači da je postupak normalizacije nepotreban. Zapravo se radilo o dvije nezavisne binarne veze. koja nije u 4NF. predmeta i studenata na glazbenoj akademiji pogrešno tumačili kao ternarnu vezu. IME GRADA. podaci bi umjesto relacijom UPISAO odmah bili prikazani relacijama KLASA i PREDAJE koje smo mi dobili prevoĎenjem u BCNF. Normalizacijom se velike relacije razbijaju na mnogo manjih. ne moţe doći do prije spominjanih teškoća. IME GRADA je funkcionalno ovisno o POŠTANSKOM BROJU. koja jeste u 2NF i 3NF no nije u BCNF. tada ćemo odmah dobiti relacije u visokim normalnim formama i normalizacija neće imati što raditi. Ukoliko. sluţeći se projektantskom vještinom i intuicijom. gdje se greške počinjene u ranijim fazama uspješno ispravljaju u kasnijim fazama. Zahvaljujući normalizaciji. te ULICA I KUĆNI BROJ čine cjelinu koja se zove adresa. Strogo govoreći.  Složeni atribut. Relacija IZVOZI iz Odjeljka 4. IME. baš naprotiv. IME GRADA. veza i atributa. proizvoda i zemalja pogrešno prikazali jednom ternarnom vezom umjesto dvjema binarnim vezama. postupak oblikovanja postaje samokorigirajući proces. ULICA I KUĆNI BROJ) .2.Baze podataka . Da smo krenuli od tih binarnih veza. U aplikacijama je često potrebno podatke iz malih relacija ponovo sastavljati u veće nenormalizirane n-torke.3. Da smo odmah uočili te binarne veze.2.skripta Relacija UPISAO iz Odjeljka 4. Nije preporučljivo razbijati ovu relaciju na dvije. greške su uvijek moguće i mi nikad ne znamo je li do njih došlo ili nije. nastala je opet zato što smo odnose izmeĎu kompanija.

a isti dobavljač nudi razne dijelove. Na fakultetu se nastava iz jednog predmeta odrţava uvijek u istoj predavaonici. treba utvrditi mogu li se u tom konkretnom slučaju zaista desiti teškoće u radu s nenormaliziranim podacima koje smo opisali u Odjeljku 4. Tvornica sklapa proizvode od dijelova. PMF – Matematički odsjek 70 . Jedna isporuka šalje se jednom kupcu i moţe sadrţavati više komada raznih proizvoda. Zadatak 4. Isti dio moţe se dobiti od raznih dobavljača po raznim cijenama. Suradnici neke ustanove rade na raznim projektima. Zamijenite zapis relacijama u 3NF. Za tu procjenu je vaţno razumijevanje značenja podataka i načina kako će se oni zaista rabiti. Prevedite tu relaciju u 3NF ako je to potrebno.3.4.4. Zadatak 4.1 dobili ste nadopunjenu relacijsku shemu baze podataka o fakultetu. Situacija je opisana sljedećom relacijom: RASPORED (BROJ PREDAVAONICE. Zadaci za vježbu Zadatak 4. Zadatak 4. 4. Drugim riječima.3. ŠIFRA PREDMETA). Zadatak 4.1. Normalizirajte tu shemu tako da sve relacije budu barem u 3NF. BROJ PROJEKTA. ISPORUKA BROJ ISPORUKE DATUM SLANJA BROJ KUPCA IME KUPCA ADRESA KUPCA BROJ PROIZVODA IME PROIZVODA KOMADA CIJENA PO KOMADU Slika 4. Rješavanjem Zadatka 3. TakoĎer. CIJENA). no u nekoliko termina tjedno. Zadatak 4. ROK ZAVRŠETKA PROJEKTA).2. treba predvidjeti hoće li se zahtijevati izuzetno velika brzina kod pronalaţenja podataka. TERMIN. IME DOBAVLJAĈA. Rješavanjem Zadatka 3.2 dobili ste relacijsku shemu za bazu podataka o knjiţnici. ADRESA DOBAVLJAĈA. BROJ DOBAVLJAĈA.Robert Manger Projektant baze podataka treba procijeniti kada treba provesti normalizaciju do kraja a kada ne. Situacija je prikazana nenormaliziranim zapisom na Slici 4. Tvornica isporučuje svoje proizvode kupcima. PLAĆA.5. a te dijelove kupuje od raznih dobavljača. PREZIME I IME. Prevedite tu relaciju u 3NF ako je to potrebno.9: Nenormalizirani zapis o isporuci proizvoda kupcu.9.6. Pritom jedan suradnik radi na točno jednom projektu. Situacija je opisana sljedećom relacijom: SURADNIK (MATIĈNI BROJ. Situacija je opisana sljedećom relacijom: CJENIK (BROJ DIJELA.1. Normalizirajte tu shemu tako da sve relacije budu barem u 3NF.

ŠIFRA M-PREDMETA.8.3 dobili ste relacijsku shemu za bazu podataka iz vašeg područja interesa.skripta Prevedite tu relaciju u BCNF ako je to potrebno. Zadatak 4. Zadatak 4. Normalizirajte tu shemu tako da sve relacije budu barem u 3NF. te izborne predmete iz računarstva. ŠIFRA R-PREDMETA).7. Prevedite tu relaciju u 4NF ako je to potrebno. Studenti upisuju izborne predmete iz matematike. PMF – Matematički odsjek 71 .Baze podataka . Situacija je opisana sljedećom relacijom: UPISAO (JMBAG. Rješavanjem Zadatka 3. Ne postavljaju se nikakvi uvjeti na izbor jednih u odnosu na druge.

Robert Manger 72 PMF – Matematički odsjek .

Ti izrazi graĎeni su od unarnih i binarnih operacija. 5. a ne o praktičnom jeziku kojeg bi korisnici neposredno rabili. U svojim ključnim radovima. Pritom je riječ o algebarskim operacijama čiji operandi su relacije. U ovom i idućim potpoglavljima. Mi ćemo se koristiti sintaksom s ključnim riječima nalik na programske jezike.1. Postavljanje upita u relacijskim bazama podataka U prethodnim poglavljima pratili smo postupak oblikovanja baze podataka. Ovo poglavlje podijeljeno je u tri potpoglavlja. Usput smo se takoĎer upoznali s relacijskim modelom za bazu podataka. stoljeća. a rezultati opet relacije. SQL je zapravo utemeljen na jednoj vrsti relacijskog računa. Dakle odgovor na upit izraţava se kao nova (virtualna) relacija dobivena iz postojećih relacija primjenom algebarskih operacija. za zadavanje i praćenje primjera upita sluţit će nam baza podataka o fakultetu opisana relacijskom shemom sa Slike 3. relacijski model ne bi vrijedio mnogo bez svoje dinamičke komponente.skripta 5. PMF – Matematički odsjek 73 . a takoĎer on s lakoćom moţe simulirati sve operacije iz relacijske algebre. sintaksa u pojedinim knjigama ili člancima se donekle razlikuje. Treće poglavlje predstavlja danas najrašireniji jezik za rad s relacijskim bazama. Relacijska algebra svodi se na izvrednjavanje algebarskih izraza. operanada. Relacijska algebra Relacijsku algebru uveo je Edgar Codd u svojim radovima iz 70-tih godina 20. Sad će nam u središtu interesa biti dinamički aspekt relacijskog modela.5 Pretpostavljat ćemo da trenutno stanje te baze izgleda kao na Slici 5. Prva dva potpoglavlja bave se relacijskom algebrom i relacijskim računom – riječ je o upitnim jezicima zasnovanima na algebri odnosno predikatnom računu koji se doduše ne rabe izravno u praksi no vaţni su za teoriju. Postavljanje upita moţe se interpretirati kao primjena matematičkih operacija kojima se iz postojećih relacija dinamički stvaraju nove virtualne relacije. a njegova vrijednost predstavlja odgovor na upit. koji se očituje u postojanju fleksibilnih jezika za postavljanje upita. u skladu s matematičkim temeljima samog relacijskog modela. Baza koju je normalizacija razbila u velik broj malih relacija ne bi bila osobito pogodna za aplikacije kad ne bi postojao fleksibilan i brz način pronalaţenja i pregrupiranja podataka. te zagrada.Baze podataka . Zaista. Makar se to na prvi pogled moţda ne vidi. Edgar Codd takve jezike smatra sastavnim dijelom relacijskog modela. Pritom smo se ograničili na statički aspekt tog modela. a to je SQL.1. dakle bavili smo se logičkom strukturom relacijske baze. Svaki algebarski izraz predstavlja jedan upit u bazu. U ovom poglavlju nakratko ćemo prekinuti s praćenjem postupka oblikovanja da bismo se osvrnuli na još neka vaţna svojstva relacijskih baza. Vidjet ćemo da se. Govorili smo o konceptualnom i logičkom oblikovanju uključujući i normalizaciju. Jezici za postavljanje upita u relacijskim bazama podataka proučavaju se jednako dugo kao i same relacijske baze. ti jezici mogu precizno matematički opisati. Budući da je riječ je o matematičkoj notaciji.

NASTAVNIK OIB 13257600947 25810043761 33571209458 44102179316 50076128203 67741205512 PREZIME Cantor Goedel Codd Klein Pascal Turing IME Georg Kurt Edgar Felix Blaise Alan IME_ZAVODA Zavod za matematiku Zavod za matematiku Zavod za raĉunarstvo Zavod za matematiku Zavod za matematiku Zavod za raĉunarstvo BROJ_SOBE 102 305 127 252 101 315 PLACA 12000 14000 16000 12000 11000 13000 PREDMET SIFRA_ PRED META 56001 72001 72005 56002 72009 NASLOV Baze podataka Linearna algebra Matematiĉka analiza Programiranje u C-u Analitiĉka geometrija IME_ZAVODA Zavod za raĉunarstvo Zavod za matematiku Zavod za matematiku Zavod za raĉunarstvo Zavod za matematiku OIB_ NASTAVNIKA 33571209458 44102179316 25810043761 67741205512 44102179316 SEMESTAR L Z L Z L ECTS_ BODOVI 5 6 6 5 5 UPISAO JMBAG 0036398757 1191203289 1191203289 1192130031 1192130031 1192130031 1191205897 0165043021 0165043021 0165043021 0036448430 0246022858 0246022858 0246022858 0246022858 0246022858 SIFRA_PREDMETA 72001 56001 56002 72001 56002 72009 72009 56001 72001 56002 56001 56001 72001 72005 56002 72009 DATUM_UPISA 2010-09-05 2009-10-03 2009-10-03 2009-09-15 2009-09-15 2009-09-15 2010-09-05 2008-10-03 2008-10-03 2009-06-10 2009-09-04 2010-09-03 2010-09-03 2010-09-20 2010-09-25 2010-09-25 OCJENA 2 2 5 4 2 3 4 5 Slika 5. 74 PMF – Matematički odsjek .1: Stanje baze podataka o fakultetu..Robert Manger STUDENT JMBAG 0036398757 1191203289 1192130031 1191205897 0165043021 0036448430 0246022858 PREZIME Marković Petrović Horvat Janković Kolar Grubišić Vuković IME Marko Petar Dragica Marija Ivan Katica Janko GODINA_STUDIJA 1 2 2 1 3 3 1 ZAVOD IME_ZAVODA Zavod za matematiku Zavod za raĉunarstvo OIB_PROCELNIKA 25810043761 33571209458 OPIS_DJELATNOSTI Ovaj zavod bavi se svim podruĉjima teorijske i primijenjene matematike . Ovaj zavod bavi se raĉunarskom znanošću i softverskim inţenjerstvom ....

1..2: Relacija koja je kompatibilna s relacijom STUDENT iz fakultetske baze. 5. . dakle skup n-torki koje su u R i takoĎer u S... presjek od R i S.Baze podataka .1 dobivamo rezultate prikazane na Slici 5. Neka R i S označavaju relacije. dakle moraju imati isti stupanj i iste atribute (ista imena i tipove). Moţemo zamišljati da ta relacija biljeţi studente nekog drugog fakulteta.2. Naime.. U stvarnosti se zapravo rijetko susreće situacija iz prethodnog primjera gdje smo skupovne operacije mogli primijeniti na relacije koje zaista postoje u bazi.1. U nastavku ovog potpoglavlja opisujemo redom pojedine algebarske operacije koje se pojavljuju u relacijskoj algebri. graĎenu jednako kao STUDENT.. razlika od R i S. u kojoj se nalaze n-torke popisane na Slici 5. Dakle skupovne operacije prvenstveno sluţe zato da se pomoću njih jednostavniji upiti kombiniraju u sloţenije.  R intersect S . Tada primjenom skupovnih operacija i u skladu sa Slikom 5. promatrajmo relaciju NOVI_STUDENT.5 baza na Slici 5. dakle skup n-torki koje su u R no nisu u S. ako su R i S virtualne relacije koje sadrţe odgovore na dva jednostavnija upita.. Kao primjer.1 ima neznatno promijenjena imena atributa. Znatno je češća situacija kad te operacije primjenjujemo na virtualne relacije koje su nastale kao odgovor na druge upite.3. PMF – Matematički odsjek 75 . Skupovne operacije Sjetimo se da su relacije ustvari skupovi n-torki.skripta Primjećujemo da u odnosu na shemu sa Slike 3. izbjegnuta je uporaba domaćih slova ili bjelina unutar imena. Zato na njih moţemo primjenjivati uobičajene skupovne operacije. to jest jednako graĎene.  R intersect S podatke koji istovremeno zadovoljavaju oba upita...  R minus S podatke koji odgovaraju na prvi upit no ne odgovaraju na drugi. Da bi se ove operacije mogle primijeniti. Tada je:  R union S .  R minus S . dakle skup n-torki koje su u R ili u S (ili u obje relacije). To je napravljeno zbog prilagodbe sintaktičkim pravilima stvarnih jezika poput SQL. relacije R i S moraju biti kompatibilne. Zaista. s time da meĎu njima ima i onih koji su takoĎer upisali i naš fakultet. unija od R i S. kao što su unija. Za svaku operaciju dajemo primjere njihove uporabe. tada:  R union S sadrţi podatke koji zadovoljavaju kriterije barem jednog od tih jednostavnijih upita. presjek i razlika. NOVI_STUDENT JMBAG 1191205336 1192130031 1191621335 0165043021 0248022869 PREZIME Drašković Horvat Iveković Kolar Zalar IME Janko Dragica Ivka Ivan Mladen GODINA_STUDIJA 2 2 1 3 1 Slika 5. Operacije su s obzirom na svoje meĎusobne sličnosti i srodnosti razvrstane u nekoliko odjeljaka.

≤. vide se na Slici 5. ≥. dakle odgovori na upite. Uvjet B je formula koja se sastoji od:  konstanti ili atributa.Robert Manger STUDENT union NOVI_STUDENT JMBAG 0036398757 1191203289 1192130031 1191205897 0165043021 0036448430 0246022858 1191205336 1191621335 0248022869 PREZIME Marković Petrović Horvat Janković Kolar Grubišić Vuković Drašković Iveković Zalar IME Marko Petar Dragica Marija Ivan Katica Janko Janko Ivka Mladen GODINA_STUDIJA 1 2 2 1 3 3 1 2 1 1 STUDENT intersect NOVI_STUDENT JMBAG 1192130031 0165043021 PREZIME Horvat Kolar IME Dragica Ivan GODINA_STUDIJA 2 3 STUDENT minus NOVI_STUDENT JMBAG 0036398757 1191203289 1191205897 0036448430 0246022858 PREZIME Marković Petrović Janković Grubišić Vuković IME Marko Petar Marija Katica Janko GODINA_STUDIJA 1 2 1 3 1 Slika 5. Primijetimo da uvijek vrijedi: R intersect S = R minus (R minus S). Selekcija i projekcija Selekcija je unarni operator koji izvlači uz relacije one n-torke koje zadovoljavaju zadani Booleovski uvjet.  operatora za usporeĎivanje =. koristimo se svim trima operacijama. >. U nastavku navodimo nekoliko primjera od kojih svaki sadrţi jedan upit sa selekcijom i odgovarajući izraz u relacijskoj algebri. jer bismo jednu od njih mogli zamijeniti s druge dvije.1. 5. <. Izračunate vrijednosti izraza.3: Rezultati skupovnih operacija. Znači. 76 PMF – Matematički odsjek .  logičkih operatora and. zbog udobnosti.4. nisu nuţne sve tri skupovne operacije. Selekcija na relaciji R u skladu s Booleovskim uvjetom B označavamo s R where B.2. not. or. Ipak. ≠.

PMF – Matematički odsjek 77 .4: Odgovori na upite sa selekcijom. Upit 3: pronaĎi one studente koji su iz predmeta sa šifrom 56001 dobili ocjenu veću od 2. Upit4: pronaĎi brojeve soba svih nastavnika. dakle odgovori na upite. vide se na Slici 5. Projekcija je unarni operator koji iz relacije izvlači zadane atribute. ODGOVOR1 JMBAG 0036398757 1191205897 0246022858 PREZIME Marković Janković Vuković IME Marko Marija Janko GODINA_STUDIJA 1 1 1 ODGOVOR2 SIFRA_ PRED META 56001 NASLOV Baze podataka IME_ZAVODA Zavod za raĉunarstvo OIB_ NASTAVNIKA 33571209458 SEMESTAR L ECTS_ BODOVI 5 ODGOVOR3 JMBAG 0165043021 0036448430 SIFRA_PREDMETA 56001 56001 DATUM_UPISA 2008-10-03 2009-09-04 OCJENA 3 5 Slika 5.5. ODGOVOR5 := (PREDMET where SIFRA_PREDMETA = 72009) [OIB_NASTAVNIKA].Baze podataka . Upit5: pronaĎi OIB nastavnika koji predaje predmet sa šifrom 72009. ODGOVOR4 := NASTAVNIK [BROJ_SOBE].…. ODGOVOR1 := STUDENT where GODINA_STUDIJA = 1. …. Projekciju relacije R na njezine atribute A1. Am]. U sloţenim algebarskim izrazima smatrat ćemo da projekcija ima viši prioritet od ostalih operacija. ODGOVOR3 := UPISAO where ((SIFRA_KOLEGIJA = 56001) and (OCJENA > 2)). Izračunate vrijednosti izraza. ODGOVOR2 := PREDMET where NASLOV = 'Baze podataka'. osim ako nije drukčije označeno zagradama.skripta Upit 1: pronaĎi sve studente na prvoj godini. A2. U nastavku navodimo dva primjera upita gdje odgovarajući izraz u relacijskoj algebri sadrţi projekciju. Am označavat ćemo s R[A1. s time da se u rezultirajućoj relaciji eliminiraju n-torke duplikati.A2. Upit2: pronaĎi sve predmete s naslovom Baze podataka.

JMBAG)) ) [STUDENT1. SIFRA_PREDMETA]. kao što je to bilo učinjeno u petom upitu. jer jedna iz relacije izvlači retke. Odgovori za oba upita prikazani su na Slici 5. STUDENT.JMBAG < STUDENT.6. Da bismo pronašli točno odreĎene podatke unutar relacije. ODGOVOR7 := ( ( STUDENT1 times STUDENT) where ( (STUDENT1.Robert Manger ODGOVOR4 BROJ_SOBE 102 305 127 252 101 315 ODGOVOR5 OIB_NASTAVNIKA 44102179316 Slika 5. Drugi primjer (Upit 7) pronalazi sve parove prezimena studenata koji su na istoj godini studija. Primijetimo da su selekcija i projekcija komplementarne operacije. ograničenjem da JMBAG prvog studenta u paru mora biti manji od JMBAG-a drugog studenta spriječili smo da se u odgovoru isti par studenata pojavljuje dvaput (u dva poretka).GODINA_STUDIJA = STUDENT. ispisat ćemo za svakog studenta sve predmete koje on nije upisao: SVE_KOMBINACIJE := STUDENT[JMBAG] times PREDMET[SIFRA_PREDMETA]. a zadnjih n2 komponenti čine n2-torku u S.PREZIME. pa zatim sastavljamo odgovor na upit: STUDENT1 aliases STUDENT. Kartezijev produkt je prva od operacija koje nam omogućuju odgovaranje na sloţenije upite gdje je potrebno povezivanje podataka iz raznih relacija. a druga stupce.PREZIME].5: Odgovori na upite sa projekcijom. obično moramo kombinirati i selekciju i projekciju. Za to nam je potrebno napraviti Kartezijev produkt relacije STUDENT sa samom sobom. dakle skup svih (n1+n2)-torki čijih prvih n1 komponenti čine n1-torku u R. posebnim operatorom aliases uvodimo „pseudonim“ (drugo ime) za relaciju STUDENT. PMF – Matematički odsjek 78 . ODGOVOR6 := SVE_KOMBINACIJE minus UPISAO[JMBAG. Atribut u R times S ima isto ime kao odgovarajući atribut u R odnosno S. Kao prvi primjer uporabe Kartezijevog produkta (Upit 6). Kod drugog upita. s time da se po potrebi to ime proširuje imenom polazne relacije i točkom (slično kao za komponentu struct-a u jeziku C).GODINA_STUDIJA) and (STUDENT1. te da se student pojavljuje u paru sam sa sobom. Da ne bi došlo do zbrke s imenima atributa.3. Kartezijev produkt i dijeljenje Neka su R i S relacije stupnja n1 odnosno n2. 5.1. Tada algebarski izraz R times S daje Kartezijev produkt od R i S.

skripta ODGOVOR6 JMBAG 0036398757 0036398757 0036398757 0036398757 1191203289 1191203289 1191203289 1192130031 1192130031 1191205897 1191205897 1191205897 1191205897 0165043021 0165043021 0036448430 0036448430 0036448430 0036448430 SIFRA_PREDMETA 56001 72005 56002 72009 72001 72005 72009 56001 72005 56001 72001 72005 56002 72005 72009 72001 72005 56002 72009 ODGOVOR7 STUDENT1. R1 A a1 a1 a1 a2 a2 a3 a4 B b1 b2 b3 b1 b2 b1 b4 R2 B b1 R3 B b1 b2 b3 R1 divideby R2 A a1 a2 a3 R1 divideby R3 A a1 Slika 5.7: Apstraktni primjer dijeljenja.y> pojavljuju u R za sve m-torke <y> u S.7. Rezultat dijeljenja R sa S. Na toj slici isti simboli oblika ai odnosno bj označavaju jednake vrijednosti atributa. je skup svih (n-m)-torki <x> takvih da se ntorke <x. a S relacija stupnja m. PMF – Matematički odsjek 79 .PREZIME Janković Vuković Janković Horvat Kolar Slika 5. i neka se svi atributi od S pojavljuju i u R.6: Odgovori na upite s Kartezijevim produktom. Ovdje x i y predstavljaju skupinu od jedne ili više vrijednosti atributa. oznakom R divideby S. Neka je R relacija stupnja n. Definicija se bolje moţe razumjeti na osnovu apstraktnog primjera sa Slike 5.PREZIME Marković Marković Vuković Petrović Grubišić STUDENT.Baze podataka .

Naime. Dijeljenje se uvodi zbog udobnosti. To ćemo opet ilustrirati primjerima s našom fakultetskom bazom podataka. U rezultirajućoj relaciji zajednički atribut se pojavljuje samo jednom. ODGOVOR8 JMBAG 0246022858 ODGOVOR9 JMBAG 1191203289 0165043021 0246022858 Slika 5.B] minus ( (R[A. Upit 9: pronaĎi JMBAG-ove onih studenata koji su upisali barem one predmete koje je upisao student s JMBAG-om 1191203289. dakle odgovori na upite. dijeljenje se moţe primijeniti i općenitije. ODGOVOR8 := UPISAO[JMBAG.8: Odgovori na upite s operacijom dijeljenja.9. Upit 8: pronaĎi JMBAG-ove studenata koji su upisali sve predmete. operacija dijeljenja predstavlja način implementiranja univerzalne kvantifikacije u relacijskoj algebri. SIFRA_PREDMETA] divideby ( UPISAO where JMBAG = 1191203289 )[SIFRA_PREDMETA] .Robert Manger U nastavku slijede još neki primjeri upita koji se odnose na bazu podataka o fakultetu i koji se mogu zapisati pomoću operacije dijeljenja.4.C.1. za relacije R(A.B].B] times S) minus R )[A. a R divideby S2 daje S1. 80 PMF – Matematički odsjek . Definicija se bolje moţe razumjeti na osnovu apstraktnog primjera sa Slike 5. ako je R dobivena kao R = S1 times S2. Na primjer. dakle i na relacije koje nisu bile dobivene Kartezijevim produktom. Kao što joj ime kaţe. prirodni spoj je operacija koja na najprirodniji način uspostavlja veze izmeĎu podataka u raznim relacijama.B.8. Primijetimo da se dijeljenje donekle moţe smatrati inverznom operacijom u odnosu na Kartezijev produkt. Kao što vidimo.D) i S(C. Na toj slici isti simboli oblika ai odnosno bj odnosno ck označavaju jednake vrijednosti atributa.D) vrijedi: R divideby S = R[A. R join S sastoji se od svih n-torki dobivenih spajanjem jedne ntorke iz R s jednom n-torkom iz S koja ima iste vrijednosti zajedničkih atributa. naime ono nije nuţno jer se moţe izraziti i preko prethodno opisanih operacija. 5. Izračunate vrijednosti izraza. No naravno. tada R divideby S1 daje S2. SIFRA_PREDMETA] divideby PREDMET[SIFRA_PREDMETA]. ODGOVOR9 := (UPISAO[JMBAG. Prirodni spoj i slične operacije Prirodni spoj (natural join) je binarna operacija primjenjiva na dvije relacije R i S koje imaju bar jedan zajednički atribut. Na taj način dobivaju se lijepo oblikovani odgovori na sloţene upite. vide se na Slici 5.

Odgovori na Upite 10 i 11 prikazani su na Slici 5. Na primjer. PMF – Matematički odsjek 81 . B. IME]. Naime. Upit 10: pronaĎi prezimena i imena svih studenata koji su upisali predmet sa šifrom 56001.Baze podataka . za relacije R(A. D) vrijedi: R join S = ( (R times S) where R.9: Apstraktni primjer prirodnog spoja. ODGOVOR10 := ( (UPISAO where SIFRA_PREDMETA = 56001) join STUDENT) [PREZIME. Detaljno izvrednjavanje Upita 12 vidi se na Slici 5. D] . Upit 11: pronaĎi broj sobe nastavnika koji predaje predmet sa šifrom 72005. ODGOVOR11 := ( (PREDMET where SIFRA_PREDMETA = 72005) join NASTAVNIK) [BROJ_SOBE].10. ODGOVOR12 := ( ( (STUDENT where GODINA_STUDIJA = 2) join UPISAO) join PREDMET) [OIB_NASTAVNIKA] .C) [ A. riječ je o operaciji koja bi se uvijek mogla izraziti preko prije uvedenih operacija. R.10: Odgovori na Upite 10 i 11 koji rabe prirodni spoj. ODGOVOR10 PREZIME Petrović Kolar Grubišić Vuković IME Petar Ivan Katica Janko ODGOVOR11 BROJ_SOBE 305 Slika 5. C) i S(C. Upit 12: PronaĎi OIB-e nastavnika koji predaju predmete koje je upisao bar jedan student na drugoj godini studija. Prirodni spoj uvodi se samo zbog udobnosti. B.C = S.C.skripta R A a1 a2 a3 a4 B b1 b1 b2 b2 C c1 c1 c2 c3 S B b1 b1 b2 C c1 c1 c3 D d1 d2 d3 R join S A a1 a1 a2 a2 a4 B b1 b1 b1 b1 b2 C c1 c1 c1 c1 c3 D d1 d2 d1 d2 d3 Slika 5.11.

Robert Manger STUDENT where GODINA_STUDIJA = 2
JMBAG 1191203289 1192130031 PREZIME Petrović Horvat IME Petar Dragica GODINA_STUDIJA 2 2

(STUDENT where GODINA_STUDIJA = 2) join UPISAO
JMBAG 1191203289 1191203289 1192130031 1192130031 1192130031 PREZIME Petrović Petrović Horvat Horvat Horvat IME Petar Petar Dragica Dragica Dragica GODINA_ STUDIJA 2 2 2 2 2 SIFRA_ PREDMETA 56001 56002 72001 56002 72009 DATUM_ UPISA 2009-10-03 2009-10-03 2009-09-15 2009-09-15 2009-09-15 OCJENA

2 2 5 4 2

( (STUDENT where GODINA_STUDIJA = 2) join UPISAO ) join PREDMET
JMBAG 1191203289 1191203289 1192130031 1192130031 1192130031 .... .... .... .... .... .... SIFRA_ PREDMETA 56001 56002 72001 56002 72009 .... .... .... .... .... .... OIB_ NASTAVNIKA 33571209458 67741205512 44102179316 67741205512 44102179316 ... ... ... ... ... ...

ODGOVOR12
OIB_NASTAVNIKA 33571209458 67741205512 44102179316

Slika 5.11: Izvrednjavanje Upita 12 koji rabi dva prirodna spoja. Osim prirodnog spoja, u literaturi se takoĎer spominje i nešto općenitija operacija koja se zove theta-spoj. Preciznije, neka su R i S relacije od kojih prva ima atribut A, a druga atribut B. Theta-spoj od R i S preko A i B, u oznaci R join(A θ B) S, definira se kao skup onih n-torki Kartezijevog produkta R sa S za koje je predikat R.A θ S.B istina. Pritom simbol θ predstavlja jedan od operatora za usporedbu: =, <, >, ≠, ≤, ≥ . Dakle, za razliku od prirodnog spoja gdje se n-torke iz različitih relacija spajaju samo na osnovu jednakosti vrijednosti atributa, thetaspoj omogućuje i općenitija spajanja na osnovu nejednakosti. Očito je da se theta-spoj uvijek moţe izraziti preko Kartezijevog produkta i selekcije. Vanjski spoj (outer join) je još jedna operacija vrlo slična prirodnom spoju. Primjenjiva je pod istim uvjetima i daje kao rezultat relaciju s istom shemom. No sadrţaj rezultirajuće relacije R outerjoin S je nešto bogatiji nego sadrţaj od R join S. Naime, pored svih n-torki iz R join S, relacija R outerjoin S sadrţi i sve „nesparene“ (nespojene) n-torke iz R odnosno S. Pritom su te nesparene n-torke na odgovarajući način proširene nedostajućim (null) vrijednostima. Dakle, za isti primjer R i S koji smo imali Slici 5.9, R outerjoin S izgleda kao što je prikazano na Slici 5.12.

82

PMF – Matematički odsjek

Baze podataka - skripta R
A a1 a2 a3 a4 B b1 b1 b2 b2 C c1 c1 c2 c3

S
B b1 b1 b2 C c1 c1 c3 D d1 d2 d3

R outerjoin S
A a1 a1 a2 a2 a4 a3 B b1 b1 b1 b1 b2 b2 C c1 c1 c1 c1 c3 c2 D d1 d2 d1 d2 d3 -

Slika 5.12: Apstraktni primjer vanjskog spoja. Vanjski spoj obično se rabi za traţenje podataka koji ne zadovoljavaju neki uvjet. Na primjer: Upit 13: pronaĎi naslove predmeta koje do 31. prosinca 2009. godine nije upisao ni jedan student. ODGOVOR13 := ( ( PREDMET outerjoin (UPISAO where DATUM_UPISA < 2010-01-01) ) where (JMBAG is null) ) [NASLOV]. Ovdje smo upotrijebili uvjet „JMBAG is null“ koji je istinit za one n-torke gdje JMBAG nema upisanu vrijednost. Odgovor na upit vidi se na Slici 5.13.

PREDMET outerjoin (UPISAO where DATUM_UPISA < 2010-01-01)
SIFRA_ PRED META 56001 NASLOV Baze podataka Baze podataka Baze podataka Linearna algebra Linearna algebra Programiranje u C-u Programiranje u C-u Programiranje u C-u Analitiĉka geometrija Matematiĉka analiza ... ... ... ... ... ... ... ... ... ... ... JMBAG 1191203289 0165043021 0036448430 1192130031 0165043021 1191203289 1192130031 0165043021 1192130031 DATUM_UPISA 2009-10-03 2008-10-03 2009-09-04 2009-09-15 2008-10-03 2009-10-03 2009-09-15 2009-06-10 2009-09-15 ... ...

72001 56002

... ...

72009 72005

... -

ODGOVOR13
NASLOV Matematiĉka analiza

Slika 5.13: Izvrednjavanje Upita 13 koji rabi vanjski spoj. Vanjski spoj R outerjoin S kojeg smo mi promatrali takoĎer se naziva i simetrični ili dvostrani vanjski spoj. Naime, u rezultirajuću relaciju on dodaje nesparene n-torke i iz R i iz S. Moguće je promatrati i lijevi odnosno desni vanjski spoj koji dodaje nesparene n-torke samo iz R odnosno samo iz S. PMF – Matematički odsjek 83

Robert Manger

5.2.

Relacijski račun

Relacijski račun takoĎer je uveo Edgar Codd u svojim radovima iz 70-tih godina 20. stoljeća, i to kao alternativu relacijskoj algebri. Riječ je opet o matematičkoj notaciji, no ovaj put ona je zasnovana na predikatnom računu. Upit se izraţava tako da zadamo predikat kojeg traţene n-torke moraju zadovoljavati. Postoje dvije varijante relacijskog računa: račun orijentiran na n-torke, gdje su osnovni objekti n-torke, te račun orijentiran na domene, gdje su osnovni objekti vrijednosti iz domena za atribute. Te dvije varijante detaljnije ćemo obraditi u sljedeća dva odjeljka ovog potpoglavlja. Zadnji odjeljak unutar potpoglavlja objasnit će odnos relacijskog računa i relacijske algebre. 5.2.1. Račun orijentiran na n-torke U slučaju računa orijentiranog na n-torke, izrazi koji izraţavaju upit sastoje se od sljedećih elemenata.  Varijable n-torke, koje poprimaju vrijednosti iz imenovane relacije. Ako je t varijabla koja „prolazi“ relacijom R, a A je atribut od R, tada t.A označava vrijednost od A unutar t.  Uvjeti oblika x θ y gdje je θ operator za usporeĎivanje =, <, >, ≠, ≤ ili ≥ . Bar jedno od x i y mora biti oblika t.A, a drugo moţe biti konstanta. Uvjeti takoĎer mogu biti oblika R(t), što znači da je t n-torka u relaciji R.  Dobro oblikovane formule (WFF). One su graĎene od logičkih veznika and, or, not, te egzistencijalnog kvantifikatora i univerzalnog kvantifikatora , u skladu sa sljedećim pravilima. - Svaki uvjet je WFF. - Ako su f1 i f2 WFF, tada su to i f1 and f2, f1 or f2, i not f1. - Ako je f jedna WFF u kojoj se t pojavljuje kao slobodna varijabla, tada su t ( f ) i t ( f ) takoĎer WFF. Pojava varijable u WFF je vezana ukoliko je ta varijabla uvedena kvantifikatorom, inače je slobodna. - Ništa drugo nije WFF. Izraz računa orijentiranog na n-torke je oblika { t.A, u.B, v.C, ... | f }, gdje su t, u, v, ... varijable n-orke, A, B, C, ... su atributi odgovarajućih relacija, a f je WFF koja sadrţi t, u, v, ... kao slobodne varijable. U nastavku slijede primjeri upita u relacijskom računu orijentiranom na n-torke koji su vezani uz našu fakultetsku bazu podataka. Odgovori su prikazani na Slici 5.14. Upit 14: pronaĎi sve šifre predmeta. { p.SIFRA_PREDMETA | PREDMET(p) } . Upit 15: pronaĎi JMBAG-ove svih studenata na prvoj godini. { s.JMBAG | STUDENT(s) and s.GODINA_STUDIJA = 1} . Upit 16: PronaĎi JMBAG-ove i prezimena studenata koji su upisali predmet sa šifrom 56002.

84

PMF – Matematički odsjek

Upit 14: pronaĎi sve šifre predmeta. Odgovori na upite izgledaju isto kao na Slici 5. PMF – Matematički odsjek 85 . v3. atributi od relacije R. Upit 17: pronaĎi šifre onih predmeta koje je upisao bar jedan student na drugoj godini.SIFRA_PREDMETA | PREDMET(p) and u (UPISAO(u) and u. (odgovor na Upit 14) SIFRA_ PREDMETA 56001 72001 72005 56002 72009 (Odgovor na Upit 15) JMBAG 0036398757 1191205897 0246022858 (Odgovor na Upit 16) JMBAG 1191203289 1191130031 0165043021 0246022858 PREZIME Petrović Horvat Kolar Vuković (odgovor na Upit 17) SIFRA_ PREDMETA 56001 56002 72001 72009 (Odgovor na Upit 18) PREZIME Vuković Slika 5.skripta { s.SIFRA_PREDMETA and s (STUDENT(s) and s. su ili varijable ili konstante. TakoĎer. { S | PREDMET (SIFRA_PREDMETA: S) } . imamo takozvane uvjete članstva oblika R (A: v1. B: v2. Na primjer.PREZIME | STUDENT (s) and i p u (PREDMET(p) and UPISAO(u) and p.JMBAG.JMBAG} . . C: v3. { s. Pravila za WFF su ista kao u računu orijentiranom na n-torke.2..JMBAG = u.JMBAG and s.SIFRA_PREDMETA = p. 5.2.. B. ) gdje su A.PREZIME | STUDENT(s) and u (UPISAO(u) and u.14. v2.JMBAG and u. s...JMBAG = s. Račun orijentiran na domene Kod računa orijentiranog na domene varijable „prolaze“ domenama a ne relacijama.Baze podataka . GODINA_STUDIJA: 2) je istina ako i samo ako postoji n-torka u relaciji STUDENT takva da je JMBAG = 1191203289 i GODINA_STUDIJA = 2.SIFRA_PREDMETA = u. U nastavku slijede isti primjeri upita koje smo u prethodnom odjeljku riješili pomoću računa orijentiranom na n-torke. No sada su rješenja zapisana pomoću računa orijentiranog na domene.. { p. uvjet STUDENT (JMBAG: 1191203289. . Upit 18: pronaĎi prezimena onih studenata koji su upisali sve predmete. ..JMBAG = s.GODINA_STUDIJA = 2)) } .14: Odgovori na upite u relacijskom računu.SIFRA_PREDMETA and u. a v1.SIFRA_PREDMETA = 56002) } . C.

Za nekoliko najvaţnijih algebarskih operacija navodimo ekvivalente u relacijskom računu orijentiranom na n-torke: R1 union R2 . Mi se ovdje nećemo baviti strogim dokazivanjem ekvivalentnosti relacijskog računa i relacijske algebre. P | STUDENT (JMBAG: J.. SIFRA_PREDMETA: S))) } . { S | PREDMET (SIFRA_PREDMETA: S) and J (UPISAO (SIFRA_PREDMETA: S.2. R1 times R2 . { J | STUDENT (JMBAG: J. Upit 17: pronaĎi šifre onih predmeta koje je upisao bar jedan student na drugoj godini. GODINA_STUDIJA: 2)) } .. { < t. Pritom je svejedno sluţimo li se računom orijentiranim na n-torke ili na domene. { t | R1(t) and not R2(t) } . JMBAG: J) and STUDENT (JMBAG: J. then.. PREZIME: P) and S (if PREDMET (SIFRA_PREDMETA: S) then UPISAO (JMBAG: J. or i not. TakoĎer vrijedi i obratno: svaki upit zapisan pomoću relacijskog računa moţe se prevesti u ekvivalentan izraz u relacijskoj algebri. PREZIME: P) and UPISAO (JMBAG: J. Dakle. R1 minus R2 . svaki upit zapisan u relacijskoj algebri moţe se zamijeniti ekvivalentnim upitom u relacijskom računu.Robert Manger Upit 15: pronaĎi JMBAG-ove svih studenata na prvoj godini. Strogi dokaz tvrdnje o izraţajnoj ekvivalentnosti relacijskog računa i relacijske algebre moţe se naći u literaturi. To je dozvoljeno zato jer se implikacija moţe izraziti pomoću and. { t | R1(t) or R2(t) } . Prvu verziju tog dokaza objavio je već Edgar Codd u svojem članku iz 1972.. { J.3.. Umjesto toga. Postoje doduše i upiti koji se ne mogu zapisati ni u jednom od razmatranih jezika. U zadnjem upitu smo se zbog udobnosti koristili implikacijom if . GODINA_STUDIJA: 1) } . Odnos relacijskog računa prema relacijskoj algebri Srodnost izmeĎu relacijskog računa i relacijske algebre je u tome što su ti jezici ekvivalentni u smislu izraţajnosti. SIFRA_PREDMETA: 56002) } . dajemo samo jednu ilustraciju.. Štoviše. godine. 5. 86 PMF – Matematički odsjek .. r > | R1(t) and R2(r) } .. Upit 18: pronaĎi prezimena onih studenata koji su upisali sve predmete. Upit 16: PronaĎi JMBAG-ove i prezimena studenata koji su upisali predmet sa šifrom 56002. Codd je u istom radu izloţio redukcijski algoritam kojim se upit u računu pretvara u izraz u algebri. { P | J (STUDENT (JMBAG: J.

5. kod postavljanja upita u relacijskoj algebri. najrašireniji današnji jezik SQL uglavnom je zasnovan na računu orijentiranom na n-torke. Jezik SQL SQL je najrašireniji jezik za rad s relacijskom bazom podataka. U širenju SQL-a tijekom 80-tih godina vaţnu ulogu odigrala je softverska kuća Oracle Corporation: ona je ugradila SQL u svoj DBMS. Uporabu SQL-a u razvoju web aplikacija tijekom 90-tih godina potakla je kompanija MySQL AB svojim besplatnim DBMS-om.A) } . a B je Booleovski uvjet koji se odnosi na atribut A.njegova zadnja verzija objavljena je 2008.2.. R1 i R2 su relacije. bili su pod pritiskom trţišta prisiljeni prihvatiti SQL i odustati od eventualnih vlastitih jezika. promjenu i mijenjanje podataka. Naime. davanje i oduzimanje ovlaštenja korisnicima. Sve u svemu. Ovdje < t. Glavna razlika izmeĎu relacijskog računa i relacijske algebre je u tome što je račun u mnogo većoj mjeri „neproceduralan“ od algebre. a njegova dotjerana varijanta pojavljuje se u današnjem IBM-ovom relacijskom DBMS-u zvanom DB2. Ostale naredbe ukratko će se obraditi u potpoglavljima 6. to jest on mora postavljeni upit nekom vrstom redukcijskog algoritma prevesti u neki oblik relacijske algebre.1 i 7. Drugi poznati jezik QBE (Query by Example) rabi račun orijentiran na domene. kod postavljanja upita u relacijskom računu.A | R1(t) } . S druge strane. Voditelj tog projekta i glavni dizajner SQL-a bio je Donald Chamberlin.skripta R1 where B (A) .. U ovom potpoglavlju bavit ćemo se isključivo postavljanjem upita. TakoĎer postoje i brojne funkcije za računanje s podacima. Informix Inc. No jezik se ne zaustavlja na tome: postoje i naredbe za stvaranje relacija. Jezik se postepeno usavršavao. te ga je time učinila dostupnim i popularnim na svim vaţnijim računalnim platformama. 7.3. godine. Stoga praktični jezici za postavljanje upita više liče na relacijski račun nego na relacijsku algebru. relacijski račun moţemo smatrati matematičkim modelom za način kako bi korisnici trebali postavljati upite. stoljeća u sklopu razvojnoistraţivačkog projekta System R unutar kompanije IBM. godine bio je donesen prvi ISO/ANSI standard za SQL . upravljanje transakcijama. već 1986. A je atribut odgovarajuće relacije.2. PMF – Matematički odsjek 87 . No bez obzira kako izgledao jezik za korisnike. { t | R1(t) and B (t. Svojstvo neproceduralnosti smatra se poţeljnim za neposredne korisnike. Sama kratica znači Structured Query Language. { t. R1[A] .Baze podataka .. r > znači kombinaciju n-torki t i r. DBMS prilikom interpretiranja tog jezika mora odrediti postupak pronalaţenja traţenih podataka. Zbog pojave raznih „dijalekata“. korisnik dobrim dijelom konstruira postupak odgovaranja na upit time što bira odgovarajuće operacije i utvrĎuje redoslijed njihovog izvršavanja. unos. Na primjer. na primjer Ingres Corporation. Jezik je nastao u 70-tim godinama 20.. U skladu sa svojim imenom. Drugi tadašnji proizvoĎači DBMS-a. Relacijsku algebru moţemo smatrati matematičkim modelom za način kako će DBMS dalje interpretirati i izvrednjavati korisničke upite. SQL u prvom redu omogućuje postavljanje upita u relacijskim bazama podataka. Digital Equipment Corporation. korisnik samo specificira podatke koje ţeli dobiti a ne zadaje način kako da se do tih podataka doĎe. Sybase Inc.

Treći odjeljak obraĎuje grupirajuće upite. U nastavku slijede primjeri jednostavnih SQL upita koji su vezani uz našu fakultetsku bazu podataka sa Slike 5. Spomenuta ekvivalencija je vaţna za interpretiranje SQL upita. 88 PMF – Matematički odsjek . PREZIME. No lagano se realiziraju i sve operacije iz relacijske algebre. prezimena i imena svih studenata na drugoj godini studija. Nastavak ovog potpoglavlja sastoji se od tri odjeljka. Upit 22: pronaĎi JMBAG-ove onih studenata koji su iz predmeta sa šifrom 56001 dobili ocjenu veću od 2. SQL je u izraţajnom smislu ekvivalentan relacijskoj algebri odnosno relacijskom računu. SELECT JMBAG FROM UPISAO WHERE SIFRA_PREDMETA = 56001 AND OCJENA IN (3. dakle upite koji umjesto podataka pohranjenih u bazi ispisuju podatke dobivene grupiranjem i daljnjom obradom pohranjenih podataka. dakle svaki SQL upit moţe se prevesti u algebru ili račun. ili Upit 23: ispiši imena studenata koja počinju na slovo 'M'. SELECT DISTINCT OIB_NASTAVNIKA FROM PREDMET. Upit 21: ispiši sve podatke o nastavnicima u obliku rang liste s obzirom na njihove plaće. 5. Naglasimo da ta naredba nije isto što i operacija selekcije iz relacijske algebre. 5).1. s time da je matematička notacija zamijenjena ključnim riječima nalik na govorni engleski jezik. postavljaju se fleksibilnom naredbom SELECT.Robert Manger Upitni dio SQL-a uglavnom je zasnovan na relacijskom računu. pa tako i oni najjednostavniji. Upit 19: pronaĎi JMBAG-ove.15. IME FROM STUDENT WHERE GODINA_STUDIJA = 2. 4. Jednostavni upiti Svi upiti u SQL-u. U prvom od njih dajemo primjere jednostavnih upita u SQL-u koji pretraţuju jednu relaciju. mada moţe obavljati i njezinu zadaću. Drugi odjeljak bavi se sloţenijim upitima gdje sudjeluje više relacija ili se pojavljuju ugnijeţĎeni pod-upiti.1.3. te obratno. svaki upit zapisan u algebri ili računu moţe se izraziti i u SQL-u. Odgovori su prikazani na Slici 5. Zahvaljujući takvim svojstvima. SELECT JMBAG. bezimena i privremena relacija koja ispisuje na zaslonu ili prosljeĎuje u aplikacijski program. Upit 20: ispiši OIB-e nastavnika koji predaju bar jedan predmet. SELECT * FROM NASTAVNIK ORDER BY PLACA DESC. Rezultat izvoĎenja naredbe SELECT shvaća se kao nova. naime DBMS odgovara na upit tako da ga interno prevede u neku vrstu algebarskog izraza kojeg dalje izvrednjava. SELECT JMBAG FROM UPISAO WHERE SIFRA_PREDMETA = 56001 AND OCJENA > 2.

SELECT PREZIME. ORDER BY omogućuje da se zadaje način kako će ispis biti sortiran. 5. Naredba se moţe protezati kroz više redaka. dozvoljeno je odjednom rabiti više relacija.Baze podataka .skripta SELECT IME FROM STUDENT WHERE IME BETWEEN 'B' AND 'C'. a iza WHERE navode se uvjeti koje podaci moraju zadovoljiti. Kao prvo. sortirano po prezimenima. te kombinirati podatke iz njih. Složeniji upiti Upiti u SQL-u mogu poprimiti puno sloţenije oblike od onih koje smo vidjeli u prethodnom odjeljku.3. Kao što smo vidjeli. Ispišite prezimena svih nastavnika zajedno s uvećanim plaćama. no mora završiti s točka-zarezom.15: Odgovori na jednostavne upite u SQL-u. SELECT IME FROM STUDENT WHERE IME LIKE 'B%'.2. IzmeĎu riječi SELECT i FROM navode se imena atributa koje ţelimo ispisati. (Odgovor na Upit 19) JMBAG 1191203289 1192130031 PREZIME Petrović Horvat IME Petar Dragica (Odgovor na Upit 20) OIB_NASTAVNIKA 33571209458 44102179316 25810043761 67741205512 (Odgovor na Upit 21) OIB 33571209458 25810043761 67741205512 13257600947 44102179316 50076128203 PREZIME Codd Goedel Turing Cantor Klein Pascal IME Edgar Kurt Alan Georg Felix Blaise IME_ZAVODA Zavod za raĉunarstvo Zavod za matematiku Zavod za raĉunarstvo Zavod za matematiku Zavod za matematiku Zavod za matematiku BROJ_SOBE 127 305 315 102 252 101 PLACA 16000 14000 13000 12000 12000 11000 (Odgovor na Upit 22) JMBAG 0165043021 0036448430 (Odgovor na Upit 23) IME Marko Marija (Odgovor na Upit 24) PREZIME Cantor Codd Goedel Klein Pascal Turing PLACA * 2 24000 32000 28000 24000 22000 26000 Slika 5. a po potrebi i WHERE i ORDER BY. u naredbi za postavljanje upita obavezno se pojavljuju ključne riječi SELECT i FROM. TakoĎer. PLACA*2 FROM NASTAVNIK ORDER BY PREZIME. jedna SELECT naredba moţe se ugnijezditi unutar druge. tako da rezultat prve naredbe sluţi kao dio uvjeta u drugoj. ili Upit 24: fakultet je odlučio svim nastavnicima udvostručiti plaću. PMF – Matematički odsjek 89 . iza FROM slijede imena relacija iz kojih se čitaju podaci.

Drugo rješenje za isti upit rabi ugnijeţĎenu SELECT naredbu koja pronalazi popis JMBAGova studenata koji su upisali traţeni predmet.SIFRA_PREDMETA AND OIB_NASTAVNIKA = 44102179316. rješenje je analogno onome kojim smo se koristili u relacijskoj algebri.Robert Manger U nastavku slijedi nekoliko primjera sloţenijih SQL upita koji su opet vezani uz našu fakultetsku bazu podataka sa Slike 5. PREZIME FROM STUDENT. a druga u trećoj. Operator IN provjerava nalazi li se zadana vrijednost podataka u zadanom skupu vrijednosti.JMBAG FROM STUDENT TEMP1. STUDENT TEMP2 WHERE TEMP1.JMBAG. Drugo rješenje je niz od tri SELECT naredbe. PREZIME FROM STUDENT WHERE JMBAG IN (SELECT JMBAG FROM UPISAO WHERE SIFRA_PREDMETA IN (SELECT SIFRA_PREDMETA FROM PREDMET WHERE OIB_NASTAVNIKA = 44102179316)). SELECT STUDENT. Upit 25: pronaĎi JMBAG-ove i prezimena studenata koji su upisali predmet sa šifrom 72009. PREDMET WHERE STUDENT.JMBAG. SELECT STUDENT. PREZIME FROM STUDENT WHERE JMBAG IN ili (SELECT JMBAG FROM UPISAO WHERE SIFRA_PREDMETA = 72009).JMBAG = UPISAO. Upit 27: pronaĎi sve parove JMBAG-ova studenata koji su na istoj godini studija. U takvom slučaju zapravo se stvara Kartezijev produkt. SELECT JMBAG. SELECT TEMP1. TEMP2. a uvjet iza WHERE izdvaja bez ponavljanja kombinacije različitih studenata koji su na istoj godini.16.JMBAG = UPISAO. Primijetimo da smo ime prvog atributa iza ključne riječi SELECT morali proširiti s imenom relacije kao prefiksom – to je zato da bismo izbjegli dvoznačnost. UPISAO WHERE STUDENT.SIFRA_PREDMETA = PREDMET.JMBAG < TEMP2.JMBAG AND TEMP1.JMBAG. Upit 26: pronaĎi JMBAG-ove i prezimena studenata koji su upisali barem jedan predmet koji predaje nastavnik s OIB-om 44102179316.GODINA_STUDIJA = TEMP2. UPISAO. Da bi se ista relacija STUDENT bez dvoznačnosti mogla rabiti kao da je riječ o dvije relacije. to jest naredba proizvodi sve kombinacije n-torki iz prve relacije s n-torkama iz druge relacije. Dakle naša SELECT naredba stvara Kartezijev produkt relacije STUDENT same sa sobom. 90 PMF – Matematički odsjek . Prvo rješenje zasnovano je na jednostrukoj SELECT naredbi koja simultano rabi tri relacije. Kao što vidimo.GODINA_STUDIJA. SELECT JMBAG. Prvo rješenje zasnovano je na jednostrukoj SELECT naredbi koja simultano rabi dvije relacije. Odgovori su prikazani na Slici 5.JMBAG AND SIFRA_PREDMETA = 72009.JMBAG AND UPISAO.1. gdje je prva od njih ugnijeţĎena drugoj. ili Opet imamo dva rješenja. No uvjet iza WHERE izbacit će one kombinacije n-torki koje nas ne zanimaju. PREZIME FROM STUDENT. naime isto ime atributa pojavljuje se u obje relacije.

SIFRA_PREDMETA = PREDMET. Budući da su u relaciji UPISAO studenti zadani pomoću JMBAG-a a ne pomoću prezimena. pa smo za te dvije kopije morali uvesti nadimke N1 odnosno N2. prezimena i imena onih studenata koji su upisali sve predmete. Upit 30: pronaĎi JMBAG-ove.PLACA FROM NASTAVNIK N1. PREZIME. Rješenje slijedi takvu promijenjenu formulaciju. svodi se na tri ugnijeţĎene SELECT naredbe.Baze podataka .PLACA > N1. da SQL nema univerzalni kvantifikator ali ima egzistencijalni.JMBAG AND PREZIME = 'Kolar').PLACA.PREZIME.JMBAG = STUDENT. Uvjet oblika NOT EXISTS (SELECT … ) je istina ako i samo ako je rezultat uključene SELECT naredbe prazan. SELECT * FROM PREDMET WHERE SIFRA_PREDMETA NOT IN (SELECT SIFRA_PREDMETA FROM UPISAO. NASTAVNIK N2 WHERE N1. IME FROM STUDENT WHERE NOT EXISTS (SELECT * FROM PREDMET WHERE NOT EXISTS (SELECT * FROM UPISAO WHERE UPISAO. SELECT PREZIME.JMBAG AND UPISAO. Prvo od njih simultano rabi dvije „kopije“ relacije NASTAVNIK. Upit 31: ispiši prezimena i imena nastavnika koji ništa ne predaju. STUDENT WHERE UPISAO. Upit 28: ispiši prezimena i plaće za sve nastavnike koji imaju veću plaću od nastavnika Cantora. PLACA FROM NASTAVNIK WHERE PLACA > (SELECT PLACA FROM NASTAVNIK WHERE PREZIME = 'Cantor').skripta morali smo uvesti nadimke (aliase) TEMP1 odnosno TEMP2 za njezinu prvu odnosno drugu pojavu. SELECT N2. Budući. PMF – Matematički odsjek 91 . N2.PREZIME = 'Cantor' AND N2. Drugo rješenje oslanja se na činjenicu da će ugnijeţĎeni upit proizvesti samo jednu vrijednost atributa koju dalje moţemo usporeĎivati s operatorom >.JMBAG = STUDENT. SELECT JMBAG. upit smo ovako morali preformulirati: pronaĎi one studente za koje ne postoji predmet kojeg oni nisu upisali. ili Opet imamo dva rješenja. Upit 29: ispiši sve podatke o predmetima koje nije upisao student Kolar. te se koristi egzistencijalnim kvantifikatorom EXISTS.SIFRA_PREDMETA)). u ugnijeţĎenom upitu morali smo se takoĎer koristiti i podacima iz relacije STUDENT.

U nastavku slijedi nekoliko primjera grupirajućih SQL-upita. (Odgovor na Upit 25) JMBAG 1192130031 1191205897 0246022858 PREZIME Horvat Janković Vuković (Odgovor na Upit 26) JMBAG 0036398757 1192130031 1191205897 0165043021 0246022858 PREZIME Marković Horvat Janković Kolar Vuković (Odgovor na Upit 27) TEMP1. i slično.16: Odgovori na sloţenije upite u SQL-u. ili minimum vrijednosti izraza. 92 PMF – Matematički odsjek .17. Za stanje baze sa Slike 5. prosjek. Primjeri su opet vezani uz našu fakultetsku bazu podataka. postoji funkcija koja daje broj n-torki u grupi.Robert Manger SELECT PREZIME. IME FROM NASTAVNIK WHERE OIB NOT IN (SELECT OIB_NASTAVNIKA FROM PREDMET). Na primjer. Takve grupne vrijednosti nastaju primjenom neke od grupnih funkcija.3. Upit je moguće izraziti i s jednostrukom SELECT naredbom. 5.JMBAG 0036398757 0036398757 0246022858 1191203289 0036448430 TEMP2. No često su nam potrebne i vrijednosti koje odgovaraju cijelim grupama (ustvari skupovima) n-torki.3. Grupirajući upiti Do sada su se odgovori na naše upite sastojali od vrijednosti koje se doslovno pojavljuju u pojedinim n-torkama pojedinih relacija baze. no tada morali rabiti neku vrstu vanjskog spoja. ili zbroj vrijednosti nekog izraza za sve n-torke u grupi. dakle upita gdje se n-torke iz baze razvrstavaju u grupe.1 odgovori na naše grupirajuće upite prikazani su na Slici 5.JMBAG 1191205897 0246022858 1191205897 1192130031 0165043021 (Odgovor na Upit 28) PREZIME Goedel Codd Turing PLACA 14000 16000 13000 (Odgovor na Upit 29) SIFRA_ PRED META 72005 72009 NASLOV Matematiĉka analiza Analitiĉka geometrija IME_ZAVODA Zavod za matematiku Zavod za matematiku OIB_ NASTAVNIKA 25810043761 44102179316 SEMESTAR L L ECTS_ BODOVI 6 5 (Odgovor na Upit 30) JMBAG 0246022858 PREZIME Vuković IME Janko (Odgovor na Upit 31) PREZIME IME Cantor Pascal Georg Blaise Slika 5. pa se na te grupe primjenjuju grupne funkcije. maksimum. Predloţeno rješenje vrlo je čitljivo i zasniva se na ugnijeţĎenom upitu.

U ispisu se pojavljuje mali kozmetički dodatak: izraz COUNT(*) preimenovan je u BROJ_NASTAVNIKA. jedino što sada dijelimo u grupe n-torke iz relacije NASTAVNIK. To znači da će upit proizvesti samo jedan redak ispisa. Upit 36: ispiši popis JMBAG-ova. SELECT IME_ZAVODA. Upit je sličan prethodnom. Grupiranje po godini studija postiţe se primjenom klauzule GROUP_BY. s time da se broje sve n-torke. te za svakog studenta broj koliko je predmeta on upisao. Ovo je najjednostavnija vrsta grupirajućeg upita. prezimena i imena svih studenata. SELECT MIN(PLACA). Upit 35: odredi prosječnu plaću nastavnika za svaki pojedini zavod. Jedini izrazi koji se u grupirajućem upitu smiju pojaviti u listi iza klauzule SELECT su vrijednosti grupnih funkcija ili atribut po kojem je izvršeno grupiranje. SUM (PLACA) FROM NASTAVNIK. čak i one koje sadrţe null-vrijednosti. MAX(PLACA). Popis treba biti leksikografski sortiran po prezimenima studenata. SELECT GODINA_STUDIJA. AVG(PLACA) PROSJECNA_PLACA FROM NASTAVNIK GROUP BY IME_ZAVODA. Primjenom grupnih funkcija pronalazimo minimum. a kriterij grupiranja je vrijednost atributa IME_ZAVODA. Ovdje je riječ o upitu gdje skup n-torki relacije STUDENT treba podijeliti u grupe s obzirom na vrijednosti atributa GODINA_STUDIJA.skripta Upit 32: ispiši najmanju i najveću plaću nastavnika. Pojavljuje se funkcija AVG(…) koja daje srednju vrijednost (aritmetičku sredinu) zadanog izraza za n-torke u grupi. SELECT IME_ZAVODA. COUNT(*) BROJ_NASTAVNIKA FROM NASTAVNIK GROUP BY IME_ZAVODA. pa će se takvo ime stupca pojaviti u zaglavlju ispisane tablice. Upit 34: sastavi izvještaj koliko ima nastavnika u pojedinom zavodu.Baze podataka . PMF – Matematički odsjek 93 . Upit 33: sastavi izvještaj koliko ima studenata na kojoj godini. maksimum odnosno zbroj vrijednosti atributa PLACA na skupu svih nastavnika. I ovaj upit je sličan prethodnima. Upit će proizvesti onoliko redaka ispisa koliko ima različitih godina studija. COUNT(*) FROM STUDENT GROUP BY GODINA_STUDIJA. te zbroj plaća za sve nastavnike. Funkcija COUNT(*) daje broj n-torki u grupi. Grupa je samo jedna i sastoji se od svih ntorki relacije NASTAVNIK.

COUNT(*) UPISAO_PREDMETA FROM STUDENT.Robert Manger SELECT STUDENT. 94 PMF – Matematički odsjek . klauzula HAVING djeluje nakon grupiranja i njome je moguće izdvojiti samo neke grupe te izbaciti neţeljene grupe. STUDENT. Upit 37: ispiši JMBAG-ove studenata koji su poloţili manje od dva predmeta.SIFRA_PREDMETA AND GODINA_STUDIJA >= 2 GROUP BY UPISAO. Ovo je najsloţeniji primjer u ovom odjeljku. Za prebrojavanje koliko ima različitih ne-null vrijednosti. zajedno s brojem predmeta koje su poloţili.JMBAG = STUDENT. grupiranje.JMBAG ORDER BY PREZIME. no odnosi se na grupe dobivene pomoću GROUP BY. Dakle uvjet iza klauzule WHERE primjenjuje se prije grupiranja. Upit 38: ispiši prezimena i imena studenata s druge ili treće godine koji su skupili barem 10 ECTS-bodova. zajedno s brojem skupljenih ECTS-bodova. IME. Ovdje vidimo sloţeniju SELECT naredbu.JMBAG AND UPISAO.SIFRA_PREDMETA = PREDMET. UPISAO WHERE STUDENT. SELECT JMBAG. Dakle. COUNT(OCJENA) POLOZIO_PREDMETA FROM STUDENT GROUP BY JMBAG HAVING COUNT(OCJENA) < 2. morali bismo rabiti COUNT (DISTINCT …). PREZIME. Klauzula ORDER BY primjenjuje se nakon grupiranja i njome se sortiraju redci ispisa koji odgovaraju grupama.JMBAG. gdje se pojavljuje više relacija. IME. Ispis treba biti silazno sortiran prema broju ECTS-bodova. Naglasimo još jednom da WHERE djeluje prije grupiranja.JMBAG = UPISAO. SELECT PREZIME. izdvajanje n-torki pomoću WHERE. zatim se klauzulom WHERE izdvajaju kombinacije s istim JMBAG-om. gdje se najprije kombiniraju n-torke iz dviju relacija STUDENT i UPISAO. te se na kraju takve kombinirane i izdvojene n-torke grupiraju u skladu s JMBAG-om. te sortiranje ispisa. PREDMET WHERE UPISAO.JMBAG HAVING SUM(ECTS_BODOVI) >= 10 ORDER BY 3 DESC. Klauzula HAVING je analogna klauzuli WHERE. SUM(ECTS_BODOVI) ZBROJ_ECTS FROM UPISAO. s time da se broje sve pojave iste vrijednosti. a ne na polazne n-torke.JMBAG GROUP BY STUDENT. Funkcija COUNT(…) daje broj ne-null vrijednosti zadanog izraza u n-torkama iz grupe. a HAVING i ORDER BY nakon grupiranja. izdvajanje grupa pomoću HAVING.

 pronaĎi restorane koji posluţuju sva jela koje voli gurman Pero.17: Odgovori na grupirajuće upite u SQL-u. jelima i restoranima. Zadaci za vježbu Zadatak 5.Baze podataka .4. Promatramo bazu podataka o gurmanima. IME_RESTORANA) POSLUZUJE (IME_RESTORANA. te koji gurman voli koje jelo.  pronaĎi gurmane koji posjećuju bar jedan restoran koji posluţuje jelo koji oni vole.JMBAG 0036448430 1192130031 1191205897 0165043021 0036398757 1191203289 0246022858 PREZIME Grubišić Horvat Janković Kolar Marković Petrović Vuković IME Katica Dragica Marija Ivan Marko Petar Janko UPISAO_PREDMETA 1 3 1 3 1 2 5 (Odgovor na Upit 37) JMBAG 0036398757 1191205897 0036448430 0246022858 POLOZIO_PREDMETA 0 0 1 0 (Odgovor na Upit 38) PREZIME Horvat Kolar Petrović IME Dragica Ivan Petar ZBROJ_ECTS 16 16 10 Slika 5. Za promatranu bazu sljedeće upite zapišite u relacijskoj algebri:  pronaĎi restorane koji posluţuju bar jedno jelo koje voli gurman Pero. Baza biljeţi koji gurman posjećuje koji restoran. upite iz Zadatka 5. Zadatak 5. PMF – Matematički odsjek 95 .skripta (Odgovor na Upit 32) MIN(PLACA) 11000 MAX(PLACA) 16000 SUM(PLACA) 78000 (Odgovor na Upit 33) GODINA_ STUDIJA 1 2 3 COUNT(*) 3 2 2 (Odgovor na Upit 34) IME_ZAVODA Zavod za matematiku Zavod za raĉunarstvo BROJ_ NASTAVNIKA 4 2 (Odgovor na Upit 35) IME_ZAVODA Zavod za matematiku Zavod za raĉunarstvo PROSJECNA_ PLACA 12250 14500 (Odgovor na Upit 36) STUDENT.1.2. 5. koji restoran posluţuje koje jelo. Za bazu podataka o gurmanima. Relacijska shema izgleda ovako: POSJECUJE (IME_GURMANA. IME_JELA) VOLI (IME_GURMANA.1 zapišite u relacijskom računu orijentiranom na n-torke. IME_JELA).

BROJ_ISKAZNICE. NASLOV.  pronaĎi naslove svih knjiga koje su bile posuĎene 15. godine. IZDAVAC) CLAN (BROJ_ISKAZNICE.  ispiši sve podatke o knjigama koje nikad nisu bile posuĎene članu s brojem iskaznice 34216.B). AUTOR. Zadatak 5.3. Zadatak 5. upite iz Zadatka 5.  pronaĎi prezime i ime člana kojem je knjiga s naslovom „Kome zvono zvoni“ bila posuĎena 12. Promatramo bazu podataka o knjiţnici.9.6.  ispiši prezimena.1 zapišite u jeziku SQL.  ispiši naslov i autora bilo koje knjige izdane od Prentice-Hall koja je bila posuĎena članu s prezimenom Perić prije 21.7. Zadatak 5. Zadatak 5. Za bazu podataka o gurmanima. Promatramo tri relacije: R(A. Za promatranu bazu sljedeće upite zapišite u relacijskoj algebri:  pronaĎi naslove i autore svih knjiga koje je izdao izdavač Prentice-Hall. članovima i o posudbama knjiga članovima. Atribut KATALOSKI_BROJ jednoznačno odreĎuje izdanje knjige. Zadatak 5.D). Za bazu podataka o gurmanima.5 zapišite u relacijskom računu orijentiranom na n-torke. Relacijska shema izgleda ovako: KNJIGA (KATALOSKI_BROJ. oţujka 2011. T(C. imena i adrese članova kojima su bile posuĎene sve knjige napisane od autora Hemingwaya. Za bazu podataka o knjiţnici. a BROJ_ISKAZNICE jednoznačno odreĎuje člana knjiţnice. ADRESA) POSUDBA (KATALOSKI_BROJ. IME.4. S(B. upite iz Zadatka 5. Za bazu podataka o knjiţnici.Robert Manger Zadatak 5. upite iz Zadatka 5.C).5 zapišite u jeziku SQL.5. 96 PMF – Matematički odsjek . upite iz Zadatka 5. Relacije govore o knigama. godine. veljače 2011.  ispiši naslove i autore svih knjiga koje nikad nisu bile posuĎene. Zadatak 5. srpnja 2010. PREZIME. DATUM_POSUDJIVANJA).5 zapišite u relacijskom računu orijentiranom na domene.  pronaĎi imena članova koji su posudili sve one knjige koje je posudio član s brojem iskaznice 67542. upite iz Zadatka 5.8.1 zapišite u relacijskom računu orijentiranom na domene. godine. Za bazu podataka o knjiţnici. Dokaţite da vrijedi sljedeća jednakost algebarskih izraza: ( R join S ) join T = R join ( S join T) .

a vrijeme potrebno za postupke u glavnoj memoriji je zanemarivo. jer će na taj način biti u stanju bolje podesiti one parametre unutar fizičkog oblikovanja kojima raspolaţe. najčešće na magnetskom disku. Elementi fizičke građe Baza podataka fizički se pohranjuje u vanjskoj memoriji računala. Veličina bloka je konstanta operacijskog sustava i ona moţe iznositi na primjer 512 byte ili 4096 byte. PMF – Matematički odsjek 97 . na primjer ako ţelimo pročitati samo jedan byte iz vanjske memorije. Zatim objašnjavamo kako se ti elementi organiziraju u datoteke i indekse.1. dobro je da projektant razumije o čemu je tu riječ. sastavljenu od SQL naredbi CREATE TABLE i CREATE INDEX. Dakle opisat ćemo samu fizičku graĎu baze. budući da se o detaljima fizičke realizacije zapravo brine DBMS. IzvoĎenjem tih naredbi DBMS automatski stvara fizičku bazu. te implementacijom baze. ali isto tako i algoritme koji omogućuju rad s pohranjenim podacima. Glavni cilj te faze je stvoriti fizičku shemu baze. Poglavlje je podijeljeno u tri potpoglavlja. U ovom poglavlju takoĎer ćemo opisati načine na koji je baza podataka fizički realizirana. Dakle. Zato je brzina nekog algoritma za rad s vanjskom memorijom odreĎena brojem blokova koje algoritam mora prenijeti. Pritom nas zanima i statički i dinamički aspekt te realizacije.Baze podataka . tada moramo prenijeti cijeli odgovarajući blok. Vaţno je znati da operacijski sustav računala dijeli vanjsku memoriju u jednako velike blokove (sektore). a to su blokovi. 6.1. pretraţiti buffer u glavnoj memoriji i izdvojiti traţeni byte. Fizičko oblikovanje i implementacija baze podataka Ovo poglavlje posvećeno je trećoj fazi oblikovanja baze podataka. U ovom potpoglavlju najprije proučavamo elemente fizičke graĎe. Osnovna operacija s vanjskom memorijom je prijenos bloka sa zadanom adresom iz vanjske memorije u glavnu.ili nanosekundama). na primjer odgovaranje na sloţene upite. dakle opis njezine fizičke graĎe. zapisi i pokazivači. Svaki blok jednoznačno je zadan svojom adresom. Ova znanja nisu izravno potrebna projektantu baze podataka. a to je fizičko oblikovanje. Ipak. 6. Fizička shema zapravo je tekst sastavljen od naredbi u SQL-u ili nekom drugom jeziku kojeg razumije DBMS. To nam omogućuje da bolje razumijemo način na koji DBMS početnu verziju fizičke sheme. od fizičkog oblikovanja baze do njezine stvarne implementacije vrlo je kratak put. Drugo potpoglavlje izravno se bavi izradom fizičke sheme na osnovu relacijske sheme. pretvara u fizičku bazu. ili obratno. Dio glavne memorije koji sudjeluje u prijenosu (i ima jednaku veličinu kao i sam blok) zove se buffer. U trećem potpoglavlju govorimo o izvrednjavanju upita nad podacima koji su pohranjeni u implementiranoj bazi. Blok je najmanja količina podataka koja se moţe prenijeti.1. Fizička građa baze podataka Fizička baza podataka gradi se od datoteka i indeksa pohranjenih na disku.skripta 6. U prvom potpoglavlju opisujemo fizičku graĎu baze. Vrijeme potrebno za prijenos bloka (mjereno u milisekundama) neusporedivo je veće od vremena potrebnog za bilo koju radnju u glavnoj memoriji (mjereno u mikro.

…). promotrimo opet relaciju STUDENT sa Slike 3. na primjer točnu duljinu pojedinog podatka u byte-ovima. pa ih pohranimo na disk. Na taj način dobivamo niz zapisa pohranjenih na disk. ako je datoteka nastala kao fizički prikaz relacije. promjena postojećeg zapisa.1: Datoteka s podacima o studentima na fakultetu. IME). Jedna datoteka obično sluţi za fizičko prikazivanje jedne relacije iz relacijske baze. te zapise poredamo u nekom redoslijedu. ili kombinacija osnovnih podataka. zapisi se moraju rasporediti po blokovima. Ideja je ilustrirana Slikom 6. Tip zapisa zadaje se kao ureĎena n-torka osnovnih podataka (komponenti). što 98 PMF – Matematički odsjek . te bi se na primjer sastojao od: niza od 10 znamenki (JMBAG). dakle jedan zapis ima točno jednu vrijednost svakog od osnovnih podataka i ta vrijednost je prikazana fiksiranim brojem byte-ova. svaku njezinu n-torku pretvaramo u zapis. Ukoliko ima više kandidata za ključ. Primijetimo da. Smatramo da su zapisi fiksne duljine. Budući da se vanjska memorija sastoji od blokova. datoteka ne mora imati ključ. Kandidat za ključ je osnovni podatak. Primijetimo da smo prilikom pretvorbe relacije STUDENT u datoteku nuţno morali uvesti brojne fizičke detalje koji nisu postojali u relacijskom modelu. 3 2 1 1192130031 1191203289 Horvat Petrović Marković Dragica Petar Marko 1 2 2 0036398757 Slika 6. više zapisa sprema se u jedan blok. Datoteka je konačni niz zapisa (slogova) istog tipa pohranjenih u vanjskoj memoriji. Da bismo fizički prikazali tu relaciju. i za datoteke se moţe uvesti pojam ključa. tada odabiremo jednog od njih da bude primarni ključ.1. Sam zapis sastoji se od konkretnih vrijednosti osnovnih podataka. niz znakova. Pritom uzimamo da je u jednom bloku smješten cijeli broj zapisa. i tako dalje. Pogodan tip zapisa za podatke o studentu mogao bi se precizno definirati u programskom jeziku poput C-a ili COBOL-a. Slično kao kod relacija. Tipične operacije koje se obavljaju nad datotekom su: ubacivanje novog zapisa. U nastavku ovog odjeljka detaljnije opisujemo kako se zapisi koji čine datoteku pohranjuju u vanjskoj memoriji. Na primjer. ili pronalaţenje zapisa gdje zadani osnovni podaci imaju zadane vrijednosti. za razliku od relacije. tada ona ima primarni ključ i on se poklapa s onim kojeg smo odabrali za relaciju.1 koja sadrţi podatke o studentima upisanim na fakultet. S obzirom da je zapis obično znatno manji od bloka. redoslijed podataka unutar zapisa. izbacivanje zapisa. znak. čija vrijednost jednoznačno odreĎuje zapis unutar datoteke. dva niza od po 20 znakova (PREZIME. Riječ je o pojmu koji nam je poznat iz programskih jezika poput C-a ili COBOL-a. dakle datoteku.Robert Manger Osnovna struktura koja se pojavljuje u fizičkoj graĎi baze podataka naziva se datoteka. Ipak. gdje je svaki osnovni podatak opisan svojim imenom i tipom (cijeli ili realni broj. te jedne dodatne znamenke (GODINA STUDIJA). meĎusobni redoslijed zapisa. jer mogu postojati zapisi-duplikati.

a to je pokazivač (pointer). dakle povezivanje dijelova datoteke u cjelinu. kao što je ilustrirano Slikom 6. Naime... Poloţaj i redoslijed blokova koji čine istu datoteku odreĎen je posebnim pravilima koja čine takozvanu organizaciju datoteke. te da dio bloka moţda ostaje neiskorišten.skripta znači da ni jedan zapis ne prelazi granicu izmeĎu dva bloka. blok 2 (zapis) (zapis) (zapis) …. (zapis) (zapis) (zapis) …. blok N Slika 6. U svakom slučaju. PMF – Matematički odsjek 99 .2: Datoteka sastavljena od blokova u kojima su zapisi. Neke od organizacija datoteka opisat ćemo u sljedećem odjeljku.. adresa zapisa gradi se kao ureĎeni par adrese bloka i pomaka u byteovima unutar bloka.Baze podataka . Ovakav način pohranjivanja omogućuje da jednoznačno odredimo poloţaj zapisa na disku. te pristup iz jednog dijela te cjeline u drugi. Riječ je o podatku unutar zapisa ili bloka jedne datoteke koji pokazuje na neki drugi zapis ili blok u istoj ili drugoj datoteci. blok 1 (zapis) (zapis) (zapis) …... cijela datoteka obično zauzima više blokova. Pokazivač se obično realizira tako da njegova vrijednost doslovno bude adresa zapisa ili bloka kojeg treba pokazati – to je takozvani fizički pokazivač.2. No mogući su i logički pokazivači koji pokazuju na implicitan način. ti blokovi se ne moraju nalaziti na uzastopnim adresama na disku. na primjer navoĎenjem vrijednosti primarnog ključa zapisa kojeg treba pokazati.. Na kraju ovog odjeljka spomenut ćemo još jedan vaţni element fizičke graĎe. Budući da se datoteka obično sastoji od velikog broja zapisa. Pokazivači se obilato rabe u raznim organizacijama datoteka – oni omogućuju uspostavljanje veza izmeĎu zapisa ili blokova.

dakle svaki blok sadrţi fizički pokazivač na idući blok. Pritom su zapisi te datoteke rasporeĎeni u više blokova. …… …..3.. …. …… …. 100 PMF – Matematički odsjek .. Način meĎusobnog povezivanja blokova iz iste datoteke odreĎen je posebnim pravilima koja čine organizaciju datoteke.. Organizacija datoteke U prethodnom odjeljku vidjeli smo da se relacija iz relacijske baze fizički prikazuje kao datoteka u vanjskoj memoriji računala... Ti blokovi su meĎusobno povezani u vezanu listu. Kao adresu cijele datoteke pamtimo adresu prvog bloka. ….. …. U ovom odjeljku opisat ćemo nekoliko najvaţnijih organizacija. blok 1 ….. Zapisi su poredani u onoliko blokova koliko je potrebno...... …. …… …. GraĎa je prikazana na Slici 6..... ….. blok N Slika 6.1... Jednostavna datoteka. ….. Svaka od njih ima svoje prednosti i nedostatke u pogledu efikasnog obavljanja osnovnih operacija nad datotekom.2. blok 3 …..Robert Manger 6.. blok 2 ….3: Jednostavna datoteka. …....

….. ….. takozvanih pretinaca. 0 1 2 …... …… …. 2. …. …. …… …. No nedostatak je da bilo kakvo traţenje... Pretinac P-1 P-1 Zaglavlje Slika 6:4: Hash datoteka... pa vrijeme traţenja linearno raste s veličinom datoteke. izbacuju i mijenjaju zapisi.... …… …. Pretinac 0 ….Baze podataka .... P-1.... …... Hash datoteka.. Ista funkcija kasnije omogućuje i brzo pronalaţenje zapisa sa zadanom vrijednošću ključa. Zapisi su rasporeĎeni u P cjelina. …… …. ….. …… …. …... …. ….. …... …... zahtijeva sekvencijalno čitanje blok po blok. 1. (buckets) označenih rednim brojevima 0..... Zadana je takozvana hash funkcija h( ) – ona daje redni broj h(k) pretinca u kojeg treba spremiti zapis s vrijednošću ključa k... ….... …… …. …. … ...skripta Prednost jednostavne organizacije je da se kod nje lagano ubacuju.. Svaki pretinac graĎen je kao vezana lista blokova. na primjer traţenje zapisa sa zadanom vrijednošću primarnog ključa.... Pretinac 1 Pretinac 2 …. …… …....... ….. PMF – Matematički odsjek 101 . …. To znači da će jedno traţenje u prosjeku zahtijevati čitanje pola datoteke.

Naime. pa se za vrijeme rada s datotekom moţe drţati u glavnoj memoriji. te ako je broj pretinaca P dobro odabran. hash datoteka nije pogodna ako ţelimo pronaći zapise gdje je vrijednost ključa u nekom intervalu. p). Preciznije: indeks je pomoćna datoteka koja olakšava traţenje zapisa u osnovnoj datoteci. u indeksu moţe postojati više parova s istim v. makar ipak malo sporiji nego hash datoteka. hash funkcija ima tendenciju „razbacivanja“ podataka na kvazi-slučajan način. te zatim pretraţimo samo h(k)-ti pretinac.5. Skup mogućih vrijednosti ključa obično je znatno veći od broja pretinaca. (v.4. za zadanu vrijednost k u indeksu moţe postojati najviše jedan par (k. Zaista. Indeks-sekvencijalna datoteka je najpopularnija organizacija zasnovana na indeksu. dakle on ne mora sadrţavati pokazivače na sve zapise u osnovnoj datoteci. Ako je h() zaista uniformna. …. tada primarni indeks moţe biti razrijeđen. p2). Hash datoteka moţe se smatrati dijametralno suprotnom organizacijom od jednostavne. Tada se naime neće dešavati da se pretinci neravnomjerno pune. TakoĎer. tada ni jedan od pretinaca nije suviše velik. Nedostatak hash datoteke je da ona ne moţe sačuvati sortirani redoslijed po ključu za zapise. čitamo indeks. već je dovoljno da sadrţi adrese blokova i najmanju vrijednost ključa za svaki blok. Daljnje dvije organizacije datoteke koje ćemo opisati zasnivaju se na tome da se uz osnovnu datoteku s podacima rabi i takozvani indeks. a p je fizički ili logički pokazivač na jedan od zapisa u osnovnoj datoteci koji sadrţi tu vrijednost podatka. (v. Zapisi u sekundarnom indeksu su parovi oblika (v. a p je fizički pokazivač na zapis u osnovnoj datoteci koji sadrţi tu vrijednost ključa. Riječ je o osnovnoj datoteci koja je organizirana jednostavno i kojoj je zbog brţeg traţenja po primarnom ključu dodan primarni indeks. p1). p). gdje je k vrijednost ključa. da bismo pronašli zapis sa zadanom vrijednošću ključa k. p3). Ako je osnovna datoteka uzlazno sortirana po ključu.Robert Manger Fizički pokazivači na početke pretinaca čine zaglavlje koje se smješta u prvi blok ili prvih nekoliko blokova datoteke. Cijela graĎa hash datoteke vidljiva je na Slici 6. pa će sve vezane liste biti podjednako kratke. saznajemo adresu odgovarajućeg bloka iz 102 PMF – Matematički odsjek . Brojevi na slici predstavljaju vrijednosti ključa. Da bismo pronašli zapis sa zadanom vrijednošću ključa k. GraĎa je prikazana Slikom 6. Budući da odabrani podatak nema svojstvo ključa. prednost hash organizacije u tome što ona omogućuje gotovo izravni pristup na osnovu ključa. Zbog svojstava primarnog ključa. Zapisi u primarnom indeksu su parovi oblika (k. Zato je vaţno da h( ) uniformno (jednoliko) distribuira vrijednosti ključa na pretince. Prednost indeks-sekvencijalne organizacije je da ona omogućuje prilično brz pristup na osnovu ključa. Zaglavlje je obično dovoljno malo. Indeks koji omogućuje traţenje po primarnom ključu naziva se primarni indeks. Indeks koji omogućuje traţenje po podatku koji nije ključ naziva se sekundarni indeks. te da h(k) bude ostatak kod dijeljenja k s brojem pretinaca P. Adresu zaglavlja pamtimo kao adresu cijele datoteke. dok jednostavna organizacija dozvoljava jedino sekvencijalni pristup. Pristup na osnovu ključa tada zahtijeva svega nekoliko čitanja blokova. Naime. dakle mogu postojati parovi (v. Kao adresu cijele datoteke pamtimo adresu indeksa. najprije računamo h(k). p). Primjer dobre hash funkcije h( ) zasniva se na tome da se vrijednost ključa k shvati kao cijeli broj. gdje je v vrijednost podatka.

Daljnja prednost indeks-sekvencijalne organizacije je da ona omogućuje čitanje svih zapisa osnovne datoteke sortirano po ključu – u tu svrhu slijedimo adrese blokova onim redom kako su one upisane u indeksu.5: Indeks-sekvencijalna datoteka.skripta osnovne datoteke. moguće je lako pronaći zapise gdje je vrijednost ključa u nekom intervalu. te izravno pristupamo tom bloku. Invertirana datoteka dobiva se daljnjom nadogradnjom indeks-sekvencijalne. Osnovna datoteka 3 10 23 28 42 Primarni indeks 10 11 blok 2 3 5 8 blok 1 23 27 blok 3 28 31 38 blok 4 42 46 blok 5 Slika 6. Nedostatak indeks-sekvencijalne organizacije je da se kod nje znatno kompliciraju operacije ubacivanja. TakoĎer. pretraţuje i po nekom PMF – Matematički odsjek 103 . I dalje imamo osnovnu datoteku i primarni indeks. TakoĎer. Dakle indekssekvencijalna datoteka predstavlja dobar kompromis izmeĎu jednostavne i hash datoteke. svaka promjena u osnovnoj datoteci zahtijeva da se provede i odgovarajuća promjena u indeksu. indeks je sam po sebi sloţena struktura koja troši dodatni prostor na disku. no dodan je barem jedan sekundarni indeks koji omogućuje da se ista osnovna datoteka. mijenjanja ili izbacivanja podataka.Baze podataka . osim po primarnom ključu. pa je to razlog zašto je ona toliko popularna. Naime.

Robert Manger drugom podatku. Sekundarni indeks je uvijek gust, dakle on sadrţi pokazivač na svaki zapis iz osnovne datoteke. Ideja je ilustrirana Slikom 6.6. Brojevi na slici predstavljaju vrijednosti ključa, a slova vrijednosti drugog podatka po kojem pretraţujemo. Kao adresu cijele datoteke pamtimo ili adresu primarnog ili adresu sekundarnog indeksa – dakle istim podacima moţe se pristupiti na dva različita načina.
Osnovna datoteka 3 10 23 28 42 Primarni indeks 10 11 a e a 3 5 8 c a b a a a a a b b c 23 27 a c c c c c d e 28 31 38 d e a Sekundarni indeks e e

42 46 -

b e c

Slika 6.6: Invertirana datoteka. Prednost invertirane organizacije je brz pristup po više kriterija, te mogućnost sortiranog ispisa ili intervalnog pretraţivanja po svim tim kriterijima. Nedostatak je da se aţuriranje podataka još više komplicira, te se troši još više dodatnog prostora na disku. Hash datoteka s podijeljenom hash funkcijom. Riječ je poopćenju prije opisane hash datoteke. Cilj koji se ţeli postići je mogućnost traţenja ne samo po primarnom ključu nego i po drugim podacima. GraĎa datoteke izgleda isto kao na Slici 6.4. No hash funkcija je definirana općenitije, tako da osim ključa uzima kao argumente i ne-ključne podatke. Pretpostavimo da ţelimo pronaći zapise gdje istovremeno podatak A1 ima vrijednost v1, podatak A2 ima vrijednost v2, ..., podatak Ar ima vrijednost vr. Pretpostavimo takoĎer da se redni broj pretinca u hash tablici moţe izraziti kao niz od B bitova – to znači da je broj pretinaca P = 2B. Postupamo na sljedeći način. 104 PMF – Matematički odsjek

Baze podataka - skripta    Podijelimo B bitova u skupine: b1 bitova za podatak A1, b2 bitova za podatak A2, ..., br bitova za podatak Ar. Zadamo pogodne „male“ hash funkcije hi(vi), i=1,2, ..., r, gdje hi preslikava vrijednost vi podatka Ai u niz od bi bitova. Redni broj pretinca za zapis u kojem je A1=v1, A2=v2, ..., Ar=vr zadaje se spajanjem malih nizova bitova. Dakle: h(v1,v2, ..., vr) = h1(v1) | h2(v2) | ... | hr(vr). Ovdje je | oznaka za „lijepljenje“ nizova bitova.

Doprinos jednog podatka u razdijeljenoj hash funkciji treba biti proporcionalan s veličinom domene tog podatka i s frekvencijom njegovog pojavljivanja u upitima. Dakle, veća domena ili češće pojavljivanje u upitima zahtijeva veći broj bitova. Kao primjer, promatramo zapise o studentima fakulteta sa Slike 6.1. Ţelimo ih spremati u hash datoteku s 1024 (=210) pretinaca. Podijelimo 10 bitova u rednom broju pretinca na sljedeći način: 5 bitova za JMBAG, 3 bita za PREZIME, 2 bita za GODINU_STUDIJA. Zadajemo sljedeće hash funkcije, gdje su v1, v2, v3 vrijednosti za JMBAG, PREZIME i GODINU_STUDIJA: h1(v1) = v1 % 32 (ostatak kod dijeljenja s 32) , h2(v2) = (broj znakova u v2 koji su različiti od bjeline) % 8, h3(v3) = v3 % 4 . Tada je redni broj pretinca za zapis (1192130031, Horvat, Dragica, 2) zadan s (01111|110|10)2 = (506)10. Da bismo pronašli zapis (ili više njih) u kojem je A1=v1, A2=v2, ..., Ar=vr, računamo redni broj pretinca h(v1,v2, ...,vr) i sekvencijalno pretraţimo taj jedan pretinac. Ako u upitu nije fiksirana vrijednost podatka Ai, tada bi bitova u rednom broju pretinca ostaje nepoznato, a broj pretinaca koje moramo pretraţiti povećava se 2bi puta. Što manje vrijednosti za A1, A2, ... , Ar je poznato, to će biti veći broj pretinaca koje moramo pretraţiti. Na primjer, ako traţimo sve studente na drugoj godini, tada su nam u rednom broju pretinca poznata zadnja 2 bita: 10, no prvih 8 bitova je nepoznato. Treba pretraţiti 28=256 pretinaca, dakle 1/4 datoteke. Ako traţimo sve studente s prezimenom Horvat, tada su nam u rednom broju pretinca poznata srednja tri bita: 110, no prvih 5 i zadnja 2 bita su nepoznata. Dakle sad treba pretraţiti 25+2=27=128 pretinaca, to jest 1/8 datoteke. Prednost podijeljene hash funkcije u odnosu na invertiranu datoteku je da se ne troši dodatni prostor za indekse. TakoĎer, operacije ubacivanja, izbacivanja i promjene zapisa su znatno jednostavnije budući da nema indeksa koje treba odrţavati. No traţenje zapisa u kojem su specificirane vrijednosti samo nekih od podataka traje dulje nego kod invertirane organizacije. Smatra se da je organizacija pomoću podijeljene hash funkcije dobra za datoteke koje nisu prevelike i čiji sadrţaj se često mijenja. 6.1.3. Organizacija indeksa U prethodnom odjeljku vidjeli smo da neke organizacije datoteke uključuju u sebi pomoćnu datoteku – indeks. Budući da je indeks sam za sebe takoĎer jedna datoteka, on isto mora biti organiziran na odgovarajući način. U ovom odjeljku opisat ćemo uobičajeni način fizičkog PMF – Matematički odsjek 105

Robert Manger prikazivanja indeksa pomoću takozvanog B-stabla. Riječ je o hijerarhijskoj strukturi podataka koja omogućuje da indeks zaista efikasno obavlja svoje osnovne zadaće, a to su brzo pronalaţenje zadane vrijednosti podatka, te čuvanje sortiranog redoslijeda svih vrijednosti. Počinjemo s definicijom B-stabla. B-stablo reda m je m-narno stablo sa sljedećim svojstvima:  korijen je ili list ili ima bar dvoje djece;  svaki čvor, izuzev korijena i listova, ima izmeĎu m /2 i m djece;  svi putovi od korijena do lista imaju istu duljinu. Primijetimo da drugo svojstvo osigurava da je B-stablo „razgranato“ u širinu. Treće svojstvo osigurava „balansiranost“, dakle da su sve grane jednako visoke. U nastavku detaljno opisujemo prikaz gustog primarnog indeksa pomoću B-stabla. Prikaz ostalih vrsta indeksa je vrlo sličan. Gusti primarni indeks prikazuje se kao B-stablo sagraĎeno od blokova vanjske memorije, i to tako da jedan čvor bude jedan blok. Veza izmeĎu roditelja i djeteta realizira se tako da u bloku-roditelju piše fizički pokazivač na blok-dijete. TakoĎer vrijedi sljedeće.  Unutrašnji čvor ima sadrţaj oblika (p0, k1, p1, k2, p2, … , kr, pr), gdje je pi pokazivač na i-to dijete dotičnog čvora (0 ≤ i ≤ r), ki je vrijednost ključa (1 ≤ i ≤ r). Vrijednosti ključa unutar čvora su sortirane, dakle k1 ≤ k2 ≤ … ≤ kr. Sve vrijednosti ključa u pod-stablu koje pokazuje p0 su manje od k1. Za 1≤ i < r, sve vrijednosti ključa u pod-stablu kojeg pokazuje pi su u poluotvorenom intervalu [ ki, ki+1). Sve vrijednosti ključa u pod-stablu kojeg pokazuje pr su veće ili jednake kr.  List sadrţi parove oblika (k, p), gdje je k vrijednost ključa, a p je fizički pokazivač na pripadni zapis u osnovnoj datoteci. Parovi unutar lista su uzlazno sortirani po k. List ne mora biti sasvim popunjen. Jednom zapisu osnovne datoteke odgovara točno jedan par (k, p) u listovima B-stabla.

18

-

-

-

10

12

-

-

22

28

34

38

4 6 8

10 -

-

12 14 16

18 20 -

22 24 26

28 30 32

34 36 -

38 40 42

Slika 6.7: Gusti primarni indeks prikazan kao B-stablo reda 5.

Na Slici 6.7 vidimo gusti primarni indeks neke datoteke prikazan kao B-stablo reda 5. Primijetimo da se indeks u obliku B-stabla moţe shvatiti kao hijerarhija jednostavnijih indeksa.

106

PMF – Matematički odsjek

7 nakon što je u njega ubačena nova vrijednost ključa 23. k2. p1. Slika 6. dalje čitamo čvor s adresom p0. IzvoĎenjem tih naredbi DBMS stvara fizičku graĎu baze. zbog odnosa veličine bloka. Kad nas taj postupak konačno dovede u list. Efikasnost prikaza indeksa pomoći B-stabla počiva na činjenici da u realnim situacijama Bstablo nikad nema preveliku visinu. p2. Lančana reakcija promjena moţe doći sve do korijena. Ako je k < k1. Ako je ki ≤ k < ki+1. k1. Na primjer. Mali broj razina znači mali broj čitanja blokova s diska pri traţenju. k2. samo u obrnutom smjeru. U tu svrhu slijedimo put od korijena do lista koji bi morao sadrţavati par (k.7 traţimo vrijednost ključa 30. te do smanjenja visine stabla. pr). kr. Naime. Ako je k ≥ kr. … . a većinu detalja automatski odreĎuje DBMS pomoću svojih ugraĎenih pravila.8 prikazuje B-stablo s prethodne Slike 6.2. duljine ključa i duljine adrese.Baze podataka . 6. U tom smislu. 18 28 - - 10 12 - - 22 24 - - 34 38 - - 4 6 8 10 - - 12 14 16 18 20 - 22 23 - 24 26 - 28 30 32 34 36 - 38 40 42 Slika 6. red B-stabla m moţe biti prilično velik. koji se takoĎer moţe rascijepiti čime se visina stabla povećava za 1. kr. Prilikom izbacivanja moţe doći do saţimanja čvorova. Pretvorba relacijske sheme u fizičku shemu i njezina implementacija Rekli smo da je fizička shema baze tekst sastavljen od naredbi u SQL-u ili nekom drugom jeziku. Izbacivanje podatka iz B-stabla odvija se analogno kao ubacivanje. To se radi tako da redom čitamo unutrašnje čvorove oblika (p0. te usporedimo k s k1. taj opis je samo implicitan budući da iz njega ne moţemo doslovno pročitati kako će datoteke biti organizirane. te da se nakon toga izvrši promjena i u nadreĎenom čvoru. fizička shema moţe se shvatiti opisom fizičke graĎe. dalje čitamo čvor kojeg pokazuje pi. to jest sastoji se od svega 3-4 razine. Za razliku od traţenja koje se odvija brzo i efikasno. koristimo se adresom pr. ubacivanje podataka u B-stablo je komplicirana operacija koja često zahtijeva da se neki od čvorova rascijepi na dva. Ipak. p). Projektant tu ima prilično ograničen utjecaj. pa Bstablo postaje „široko i nisko“. ako u B-stablu sa Slike 6.8: Ubacivanje vrijednosti 23 u B-stablo s prethodne slike. traţimo u njemu par sa zadanim k. proći ćemo put koji je na slici označen crvenim strelicama. … .skripta U indeksu koji je prikazan kao B-stablo moguće je vrlo brzo za zadanu vrijednost ključa k pronaći pokazivač p na odgovarajući zapis u osnovnoj datoteci. PMF – Matematički odsjek 107 .

Njome se definira jedna relacija iz baze. TakoĎer je moguće zadati koji atribut ili kombinacija atributa čine primarni ključ te relacije. CREATE TABLE UPISAO (JMBAG NUMERIC(10) UNSIGNED NOT NULL. ECTS_BODOVI NUMERIC(2) UNSIGNED. PRIMARY KEY(OIB)).'4'. CREATE TABLE NASTAVNIK (OIB NUMERIC(11) UNSIGNED NOT NULL. OPIS_DJELATNOSTI CHAR(160). IME CHAR(20). OCJENA ENUM('2'. 108 PMF – Matematički odsjek . OIB_NASTAVNIKA NUMERIC(11) UNSIGNED. SIFRA_PREDMETA NUMERIC(5) UNSIGNED NOT NULL. IME CHAR(20). Slika 6. SEMESTAR ENUM('Z'. PREZIME CHAR(20). PRIMARY KEY(IME_ZAVODA)). DATUM_UPISA DATE. Kod odreĎivanja tipova obično moramo napraviti neke kompromise budući da je popis tipova koje podrţava DBMS ograničen.'L'). Pritom tipove atributa odredimo najbolje što moţemo u skladu s pripadnim rječnikom podataka.9: Početna verzija fizičke sheme za bazu podataka o fakultetu. PRIMARY KEY(JMBAG. PRIMARY KEY(SIFRA_PREDMETA)).'3'. dakle ime relacije. PREZIME CHAR(20).'5'). GODINA_STUDIJA ENUM('1'.2.'4'. PLACA NUMERIC(5) UNSIGNED. CREATE TABLE ZAVOD (IME_ZAVODA CHAR(40) NOT NULL.SIFRA_PREDMETA)).'3'. IME_ZAVODA CHAR(40).'2'. NASLOV CHAR(80). OIB_PROCELNIKA NUMERIC(11) UNSIGNED. Početnu verziju fizičke sheme dobivamo tako da svaku relaciju iz prethodno razvijene relacijske sheme opišemo jednom naredbom CREATE TABLE.'5'). CREATE TABLE STUDENT (JMBAG NUMERIC(10) UNSIGNED NOT NULL. te smije li neki atribut imati neupisane vrijednosti ili ne smije.1.Robert Manger 6. PRIMARY KEY(JMBAG)). CREATE TABLE PREDMET (SIFRA_PREDMETA NUMERIC(5) UNSIGNED NOT NULL. Stvaranje početne verzije fizičke sheme Najvaţnija SQL naredba koja se pojavljuje u fizičkoj shemi baze je naredba CREATE TABLE. IME_ZAVODA CHAR(40). BROJ_SOBE NUMERIC(3) UNSIGNED. te imena i tipovi atributa.

9 prikazuje početnu fizičku shemu za bazu podataka o fakultetu. Naredbe CREATE TABLE sa Slike 6.9 osigurava da će se u svim datotekama traţenje po primarnom ključu odvijati relativno brzo.Baze podataka . te indeksi za atribute JMBAG odnosno SIFRA_PREDMETA u relaciji UPISAO.9 kojim se uvodi indeks za atribut PREZIME u relaciji STUDENT. a traţenje po ključu bi zahtijevalo sekvencijalno čitanje cijele datoteke.skripta Slika 6. 6. efikasno se pronalaze svi predmeti koje je upisao zadani student. PMF – Matematički odsjek 109 .10: Sekundarni indeksi za bazu podataka o fakultetu. Odabirom hash tablice dodatno se ubrzava traţenje po ključu. CREATE INDEX UJ_IND ON UPISAO (JMBAG). Time postaje moguće brzo pronalaţenje studenta po prezimenu ili brzi ispis svih studenata sortirano po prezimenu. omogućuju i prikaz relacije u obliku hash tablice. U tu svrhu rabe se SQL naredbe CREATE INDEX. Definirani su primarni ključevi.10 prikazuje dodatak shemi sa Slike 6. IzvoĎenjem naredbi sa Slike 6. TakoĎer. MySQL će automatski stvoriti fizičku bazu gdje će svaka od pet relacija biti prikazana kao jedna datoteka. CREATE INDEX SP_IND ON STUDENT (PREZIME). koja je dobivena na osnovu relacijske sheme sa Slike 3.6.2. fizička shema sa Slike 6. No traţenje po drugim podacima bit će sporo jer će zahtijevati sekvencijalno čitanje odgovarajućih datoteka. Tipovi atributa neznatno se razlikuju od onih sa Slike 3. Slika 6. te svi studenti koji su upisali zadani predmet. Dakle ne bi bilo ugraĎenog indeksa.6. no usporavaju se sve operacije koje ovise o sortiranom redoslijedu po ključu. Rabit će se jedna vrsta indeks-sekvencijalne organizacije koja se u MySQL-ovoj terminologiji zove MyISAM: dakle zapisi datoteke bit će rasporeĎeni u blokove. Rabi se MySQL-ova inačica SQL-a. indeks-sekvencijalna datoteka za prikaz relacije STUDENT odnosno UPISAO nadograĎuje se do invertirane organizacije.5 i rječnika podataka sa Slike 3. na primjer tekstualni podaci imaju ograničenje duljine. Jedinstvenost vrijednosti ključa u hash tablici DBMS moţe garantirati provjerom sadrţaja pretinca prilikom svakog upisa podataka. Pretraţivanje po odabranim podacima koji nisu ključevi moţemo ipak ubrzati ako DBMS-u naredimo da sagradi odgovarajuće sekundarne indekse. U tom slučaju MySQL bi se za prikaz relacije mogao koristiti i jednostavnom datotekom. te će u datoteku automatski biti ugraĎen primarni indeks koji osigurava svojstvo primarnog ključa i ubrzava pretraţivanje po ključu. Neki DBMS-i. Stvaranjem tih sekundarnih indeksa.9 mogle su se napisati i bez navoĎenja primarnog ključa. Slika 6.9. ne bi se garantirala jedinstvenost vrijednosti ključa. Pojavljuje se pet naredbi CREATE TABLE od kojih svaka odgovara jednoj relaciji sa Slike 3.2.5. Daljnje dotjerivanje fizičke sheme Zbog navoĎenja primarnih ključeva i uporabe primarnih indeksa. na primjer Oracle. Tada u odgovarajućoj naredbi CREATE TABLE moramo navesti posebnu opciju. CREATE INDEX US_IND ON UPISAO (SIFRA_PREDMETA).

moramo je inicijalno napuniti s podacima. fizička baza podataka nastaje izvoĎenjem naredbi iz fizičke sheme. > USE fakultet. INSERT INTO NASTAVNIK VALUES (13257600947.10. UPDATE PREDMET SET OIB_NASTAVNIKA = 67741205512 WHERE NASLOV = 'Baze podataka'. dakle bazu u kojom nema ni jedne relacije. Zato projektant baze ne smije pretjerivati sa stvaranjem indeksa. Indeks je zaista potreban samo za one podatke po kojima se vrlo često pretraţuje. 'Marko'.10 stvaraju se sve datoteke i indeksi koji čine fizičku bazu podataka o fakultetu. to jest u njima neće biti n-torki. fakultetska baza imat će sve potrebne relacije.9.txt kao komandnu datoteku (script file). već treba procijeniti koje su stvarne potrebe aplikacija.Robert Manger UvoĎenjem sekundarnih indeksa poboljšavaju se performanse baze prilikom pretraţivanja. čime će se izvesti sve SQL naredbe CREATE TABLE i CREATE INDEX sa Slike 6. Treći redak pokreće CreateTables. Nakon upravo opisanog postupka. a u slučaju MySQL-a oni izgledaju ovako. Drugi redak otvara tu bazu.txt. Stvaranje i inicijalno punjenje baze Kao što smo već rekli. Detalji postupka donekle se razlikuju ovisno o DBMSu. 12000).10. DELETE FROM UPISAO WHERE JMBAG = 1191203289. '1'). 6. Da bi s takvom bazom mogli išta smisleno raditi. Prvi redak stvara praznu bazu fakultet. 102. dakle ukupni sadrţaj Slike 6. pohranjena kao jedna tekstualna datoteka s imenom CreateTables. Inicijalno punjenje u principu je moguće obaviti standardnim SQL naredbama za aţuriranje. > CREATE DATABASE fakultet. 'Markovic'. odnosno promjenu ili brisanje jedne ili više n-torki. 110 PMF – Matematički odsjek .txt. Prethodni redci zapravo su naredbe koje se izvode na interaktivan način unutar komandne ljuske mysql. 'Cantor'. no te relacije će biti prazne.3. Na primjer. izvoĎenjem svih naredbi sa Slike 6. treća mijenja nastavnika za predmet Baze podataka. > SOURCE CreateTables. u SQL-u postoje naredbe nalik na SELECT koje sluţe za ubacivanje n-torke u relaciju. a četvrta briše sve upise predmeta za studenta s JMBAG-om 1191203289. i 6.9 i 6. Pretpostavljeno je da je cjelokupna fizička shema. No treba biti svjestan da svaki sekundarni indeks predstavlja dodatni teret za DBMS budući da on zauzima prostor na disku i mora se aţurirati. INSERT INTO STUDENT VALUES (0036398757. ili ako se zahtijeva izuzetno velika brzina odziva. 'Georg'.9 i 6.2. Naime. 'Zavod za matematiku'. U nastavku navodimo nekoliko primjera takvih naredbi: prve dvije ubacuju novog studenta odnosno novog nastavnika.

računanje statistika i slično. kao što su unos nove n-torke (zapisa).Baze podataka . DBMS takoĎer treba imati na raspolaganju i algoritme koji omogućuju interpretaciju i izvrednjavanje sloţenih upita. 0036398757 1191203289 1192130031 1191205897 0165043021 0036448430 0246022858 Markovic Petrovic Horvat Jankovic Kolar Grubisic Vukovic Marko Petar Dragica Marija Ivan Katica Janko 1 2 2 1 3 3 1 Sljedeće naredbe izvode iz komandne ljuske mysql – njima se sadrţaj iz StudentData. vrijednosti atributa odvojene su znakovima tab i poredane su onako kako je odreĎeno u odgovarajućoj naredbi CREATE TABLE. Nakon inicijalnog punjenja. Daljnji odjeljci opisuju neke detalje unutar postupka. promjenu ili brisanje n-torke. te pronalaţenje n-torke sa zadanom vrijednošću ključa ili nekog drugog podatka.txt“ INTO TABLE STUDENT. No od implementacije baze očekuje se i više: ona takoĎer treba efikasno odgovarati na sloţene upite gdje se povezuju ili grupiraju podaci iz raznih relacija. Na primjer.skripta Osim standardnih SQL naredbi. u slučaju naše fakultetske baze podataka bilo bi moguće izvesti upite iz Potpoglavlja 5. TakoĎer. U ovom potpoglavlju nastojat ćemo prikazati način na koji DBMS odgovara na upite.3.txt pretvara u 7 n-torki relacije STUDENT. pretpostavimo da tekstualna datoteka StudentData. Prvi odjeljak prikazuje opći tijek tog postupka. > LOAD DATA INFILE “StudentData. Dakle. kao što su algoritmi za izvrednjavanje algebarskih operacija. Na primjer. pomoću raznih alata i programskih jezika mogli bismo dalje razvijati aplikacije koje bi sluţile za daljnje aţuriranje podataka. u većini DBMS-a stoje nam na raspolaganju i dodatni mehanizmi kojima se inicijalno punjenje baze moţe obaviti na efikasniji način. > USE fakultet. podrazumijevali smo da DBMS zna obavljati jednostavne radnje s relacijama (datotekama). baza je spremna za rad. izvještavanje. uz algoritme za osnovne operacije s datotekama. te pravila za optimizaciju upita.3. te da onda jednom naredbom taj sadrţaj pretočimo u bazu. Svaki redak datoteke odgovara jednoj n-torki iz relacije STUDENT. 6. Izvrednjavanje i optimizacija upita Kad smo u prethodnim potpoglavljima govorili o fizičkoj graĎi i implementaciji baze podataka. PMF – Matematički odsjek 111 . MySQL nam omogućuje da inicijalni sadrţaj jedne relacije pripremimo u obliku tekstualne datoteke.txt sadrţi sljedeće podatke za 7 studenata.

te se u odreĎenim okolnostima moţe pokazati brţim ili sporijim od ostalih. Optimizacija na niţoj razini trebala bi osigurati da se od raspoloţivih algoritama bira onaj koji je u danoj situaciji najbrţi. Faza prevoĎenja upita iz SQL-a u relacijsku algebru potrebna je zato jer relacijska algebra. Zadnje dvije faze u pronalaţenju odgovora na upit ponavljaju se više puta. Svaki od tih algoritama ima svoje prednosti i mane.3. Niţa razina optimizacije: odabir algoritma za izvrednjavanje pojedine algebarske operacije. Nakon prevoĎenja. Transformacija se obavlja primjenom posebnih pravila o ekvivalenciji algebarskih izraza. Izraz je pogodniji za izvrednjavanje ako se on moţe izračunati u kraćem vremenu ili uz manji utrošak memorije. Pritom nam je u središtu paţnje izvrednjavanje prirodnog spoja. dakle jednom za svaku operaciju u transformiranom algebarskom izrazu. Sljedeća dva odjeljka zato detaljnije opisuju konkretne algoritme za izvrednjavanje algebarskih operacija. budući da se kod te operacije najbolje vide neke vaţne ideje koje su primjenjive i na druge operacije. U ovom odjeljku takoĎer smo vidjeli da se postupak odgovaranja na upite nastoji ubrzati primjenom dvaju vidova optimizacije. Sam algoritam prevoĎenja iz SQL-a u relacijsku algebru nećemo opisivati jer je riječ o naprednijem gradivu koje izlazi iz okvira ovog teksta.Robert Manger 6. 2. PrevoĎenje upita u relacijsku algebru. Na osnovi svega rečenog u ovom odjeljku. Sloţenost takvih algoritama mjeri se količinom podataka koje treba pročitati ili ispisati.1. S obzirom da su relacije fizički prikazane datotekama. Viša razina optimizacije: algebarska transformacija. prikazuje upit u proceduralnom obliku koji omogućuje izvrednjavanje. odgovor na upit moguće je dobiti izvršavanjem operacija koje se pojavljuju u algebarskom izrazu u redoslijedu koji je odreĎen samim izrazom. u zadnjem odjeljku navodimo kao ilustraciju nekoliko primjera pravila za optimizaciju. Algoritam je utemeljen na prije spominjanoj ekvivalenciji SQL-a i relacijske algebre u smislu izraţajnosti. Izvrednjavanje pojedine algebarske operacije odabranim algoritmom. 3. polazni algebarski izraz koji je bio dobiven prevoĎenjem iz SQL-a nastoji se transformirati u ekvivalentni izraz koji je pogodniji za izvrednjavanje. Ovdje pod ekvivalentnim izrazima smatramo one koji imaju jednaku vrijednost. Optimizacija upita je sloţeno područje koje takoĎer izlazi iz okvira ovog teksta. Odabir se zasniva na heurističkim pravilima koja procjenjuju brzinu algoritma na osnovu raznih parametara kao što su veličine ulaznih datoteka. Opći tijek izvrednjavanja i optimizacije Upit se obično postavlja u neproceduralnom jeziku kao što je SQL. Pronalaţenje odgovora na postavljeni upit odvija se četiri faze. postojanje ili nepostojanje indeksa. 112 PMF – Matematički odsjek . način na koje su one sortirane. vidimo da se postupak odgovaranja na upite u najvećoj mjeri svodi na izvrednjavanje operacija iz relacijske algebre. algoritmi za izvrednjavanje algebarskih operacija zapravo su algoritmi koji čitaju jednu ili dvije ulazne datoteke te ispisuju izlaznu datoteku. Sjetimo se da se u algebarskim izrazima pojavljuju unarne ili binarne operacije koje od relacija rade relacije. Ipak. 1. za razliku od SQL-a. poštujući redoslijed koji je zapisan u samom izrazu. Faza optimizacije na niţoj razini uvodi se zato jer za jednu algebarsku operaciju obično imamo na raspolaganju više algoritama koji je izvrednjavaju. U fazi optimizacije na višoj razini. 4. i tako dalje.

a R2 se čita onoliko puta koliko ima segmenata u R1. Nakon ovog poboljšanja R1 se očigledno čita samo jednom. PMF – Matematički odsjek 113 .2. Algoritam ugniježĎenih petlji. inaĉe ako ( tekuća skupina zapisa iz R2 sadrţi manju vrijednost za B nego tekuća skupina zapisa iz R1 ) pokušaj učitati iduću skupinu zapisa iz R2. datoteku R1 čitamo samo jednom.B. pokušaj učitati idući zapis iz R2.C) prirodni spoj od R1 i R2. učitaj prvi zapis iz R1.Baze podataka . inicijaliziraj praznu S.C) sa zajedničkim atributom B. makar ne nuţno i najefikasniji način. Algoritam je opisan sljedećim pseudokodom. } Prema ovom pseudo-kodu. Nakon što smo pročitali cijelu R2 i obavili sva potrebna usporeĎivanja. no za svaki zapis iz R1 iznova moramo čitati cijelu datoteku R2. dok ( nismo prešli kraj od R2) { ako ( tekući zapisi iz R1 i R2 sadrţe istu vrijednost za B ) stvori kombinirani zapis i ispiši ga u S. Poboljšana verzija algoritma osobito je dobra onda kad je jedna od datoteka dovoljno mala da cijela stane u glavnu memoriju. Datoteka S koja sadrţi prirodni spoj od R1 i R2 lagano se moţe generirati sljedećim algoritmom koji podsjeća na klasično saţimanje. a atributi u istoimene osnovne podatke. Pretpostavimo da su datoteke R1 i R2 uzlazno sortirane po zajedničkom podatku B.B) i R2(B. Doslovno se primjenjuje definicija prirodnog spoja. Razmotrit ćemo nekoliko načina kako se pomoću datoteka R1 i R2 moţe generirati datoteka S. Tada se i R1 i R2 čitaju samo jednom. dok ( nismo prešli kraj od R1 ) { učitaj prvi zapis iz R2. Svaka od ovih triju relacija fizički se prikazuje jednom (istoimenom) datotekom: n-torke se pretvaraju u zapise. Označimo sa S (A. Algoritam se moţe poboljšati tako da u glavnu memoriju učitamo segment od što više blokova iz R1. učitamo idući segment od R1 u glavnu memoriju te ponavljamo postupak. učitaj prvu skupinu zapisa iz R1. Algoritam zasnovan na sortiranju i sažimanju. Izvrednjavanje prirodnog spoja Promatramo relacije R1(A. učitaj prvu skupinu zapisa iz R2. } pokušaj učitati idući zapis iz R1. Preinačimo petlje tako da usporeĎujemo svaki zapis učitan iz R2 sa svakim zapisom iz R1 koji je trenutno u glavnoj memoriji. inicijaliziraj praznu S.3. dok ( nismo prešli kraj ni od R1 ni od R2) { ako ( tekuća skupina zapisa iz R1 sadrţi manju vrijednost za B nego tekuća skupina zapisa iz R2 ) pokušaj učitati iduću skupinu zapisa iz R1. To je očigledan. Tada u R1 i u R2 moţemo uočiti skupine uzastopnih zapisa s istom vrijednošću za B.skripta 6.

pokušaj učitati idući zapis iz R1. tada ih najprije treba sortirati. Riječ je o prilično dugotrajnom postupku koji zahtijeva višestruko prepisivanje cijele datoteke. algoritam treba preraditi tako da učitava segment po segment od svake skupine. Ipak. 114 PMF – Matematički odsjek . dok ( nismo prešli kraj od R1 ) { pomoću indeksa pronaĎi i učitaj sve zapise iz R2 koji imaju istu vrijednost za B kao tekući zapis iz R1. pa tek onda računati prirodni spoj. Kombinacija zadanog zapisa iz datoteke R1 sa zadanim zapisom iz datoteke R2 pojavljuje se u prirodnom spoju S ako i samo ako oba zadana zapisa imaju jednaku vrijednost za B. na primjer R2. a rabiti indeks veće datoteke. moţe generirati na sljedeći način. ako su R1 i R2 jako velike. Ako i R1 i R2 imaju indeks za B. učitaj prvi zapis iz R1. pokušaj učitati iduću skupinu zapisa iz R2. Da bismo sortirali veću datoteku. cijeli postupak se isplati u odnosu na algoritam ugnijeţĎenih petlji. To moţe dovesti do značajne uštede u obimu posla. koja sadrţi prirodni spoj od R1 i R2. Dakle sortiranje polaznih R1 i R2 trajat će znatno dulje nego generiranje S od već sortiranih R1 i R2. posebno sortiramo svaki segment i ispisujemo ga natrag u vanjsku memoriju. } } Pretpostavili smo da su skupine zapisa iz R1 odnosno R2 s istom vrijednošću za B dovoljno male tako da stanu u glavnu memoriju. } Algoritam jednom pročita cijelu R1.Robert Manger inaĉe { svaki zapis iz tekuće skupine iz R1 kombiniraj sa svakim zapisom iz tekuće skupine iz R2 te sve generirane zapise ispiši u S. Algoritam zasnovan na hash funkciji i razvrstavanju. Pretpostavimo da jedna od datoteka R1 i R2. sve dok na kraju ne dobijemo cijelu sortiranu datoteku. Ako R1 i R2 nisu sortirane kao što se traţilo u opisanom algoritmu. tada treba sekvencijalno čitati manju datoteku. ima sekundarni indeks za zajednički podatak B. dijelimo je na segmente koji stanu u glavnu memoriju. Segmenti jedne datoteke tada će se morati više puta učitavati. Pod ovakvim pretpostavkama i R1 i R2 se čitaju samo jednom. Tada se datoteka S. Razvrstavanjem zapisa iz R1 i R2 u skupine onih s bliskom vrijednošću h lakše ćemo odrediti koji parovi zapisa se mogu kombinirati. Algoritam zasnovan na indeksu. pokušaj učitati iduću skupinu zapisa iz R1. Zadajemo hash funkciju h koja ovisi o zajedničkom podatku B. U literaturi postoje mnogi dobri algoritmi za sortiranje. inicijaliziraj praznu S. tekući zapis iz R1 kombiniraj sa svakim od učitanih zapisa iz R2 te generirane zapise ispiši u S. Dalje se sortirani segmenti postepeno saţimaju u sve veće i veće. Ukoliko skupine ne stanu u glavnu memoriju. No iz R2 se neposredno čitaju samo oni zapisi koji sudjeluju u prirodnom spoju. Zato hash funkcija za oba takva zapisa daje istu vrijednost. no oni obično predviĎaju da cijela datoteka stane u glavnu memoriju.

Algoritam se tada sastoji od sljedećih pet koraka. 3. PMF – Matematički odsjek 115 . 3 i 4 ilustrirani na Slici 6. 1. 4. Učitaj u glavnu memoriju odgovarajuću skupinu zapisa iz R1. Inicijaliziraj praznu datoteku S. Ponovi korak 4. Analizom algoritma lagano se vidi da se svaka od datoteka R1 i R2 čita točno dvaput. Odaberi hash funkciju h. Kombiniraj tekući zapis iz R2 sa svim zapisima iz R1 (u glavnoj memoriji) koji imaju jednaku vrijednost za B. 5.skripta Korak 1: Interval 1 0 1 2 Korak 2: h() u intervalu 3 R1. 2.znači da jedna skupina stane u glavnu memoriju.1 R2.i S Slika 6.1 Interval 3 P-1 Korak 3: h() u intervalu 3 R2. Pritom je k odabran tako da 1/k od datoteke R1 stane u glavnu memoriju.11.11: Izvrednjavanje prirodnog spoja pomoću hash funkcije i razvrstavanja. Ako je h zaista uniformna hash funkcija.Baze podataka . slično kao što smo to napravili s datotekom R1. Čitaj sekvencijalno R1 i razvrstaj njezine zapise u k skupina (pomoćnih datoteka) tako da jedna skupina sadrţi sve zapise iz R1 koje h preslikava u jedan od intervala. Čitaj sekvencijalno R2 i razvrstaj njezine zapise u k skupina (pomoćnih datoteka). Ako smo u koraku 4 već obradili svaki od k intervala.i Kombinacija zapisa R2.3 R2 h() u intervalu 2 R2. Sekvencijalno čitaj odgovarajuću skupinu zapisa iz R2. Dobivene kombinacije ispiši u S. Odaberi jedan od intervala za vrijednost h.2 h() u intervalu 1 Interval 2 R1.3 R1 h() u intervalu 2 R1. tada su sve skupine podjednako velike . Pritom su koraci 1. tada je algoritam završen. 2. Neka je R1 manja od R2. s time da odabereš novi interval za vrijednost od h.2 h() u intervalu 1 Korak 4: Glavna memorija R1. Podijeli ukupni raspon hash vrijednosti na k podjednakih intervala.

Sad ćemo samo ukratko rezimirati ideje. to traje predugo. Izvrednjavanje selekcije. Hash organizacija ne podrţava intervalno pretraţivanje. Osnovni problem implementiranja projekcije je: kako u S eliminirati zapise-duplikate?  Najjednostavniji algoritam za računanje projekcije zasnovan je na ugnijeţĎenim petljama. inicijaliziraj praznu S.Robert Manger 6. Zadana je relacija R i njezin atribut A. već se kreće u zadanom intervalu. R je fizički prikazana istoimenom datotekom. No ista vrijednost za A moţe se pojaviti više puta. pokušaj učitati idući zapis iz S. Algoritam je opisan sljedećim pseudo-kodom. dakle na jednostavno organizirane datoteke nadopunjene sekundarnim indeksima koji su prikazani B-stablima (primarni gusti indeks je samo specijalni slučaj sekundarnog). Drugi no znatno rjeĎe rabljeni način ubrzavanja selekcije je primjena hash organizacije. Izloţit ćemo osnovne ideje za izvrednjavanje tih dviju operacija.1 već smo opisali algoritme za pristup. obično se radi o pristupu na osnovi primarnog ključa ili o pristupu na osnovi ostalih podataka. U Potpoglavlju 6. no obično se svodi na traţenje zapisa u datoteci R sa zadanom vrijednošću nekih podataka.  Invertiranje datoteka pomoću indeksa je vjerojatno najfleksibilnija metoda ubrzavanja selekcije. dok ( nismo prešli kraj od R ) { duplikat = 0. Indeks-B-stablo podrţava ovakvo intervalno pretraţivanje.  Neki oblici uvjeta B zahtijevaju da u R traţimo zapise gdje vrijednost zadanog podatka nije fiksirana.3. Ako je R velika. budući da je u njemu sačuvan sortirani redoslijed zapisa po dotičnom podatku. Izvrednjavanje selekcije R where B ovisi o obliku uvjeta B. pokušaj učitati idući zapis iz R. projekcije i ostalih operacija Osim prirodnog spoja. pokušaj učitati prvi zapis iz S. a zatim ćemo kratko napomenuti kako se implementiraju ostale operacije. Većina današnjih relacijskih DBMS-a oslanja se na invertirane datoteke. Zadana je relacija R i Booleovski uvjet B. } 116 PMF – Matematički odsjek . pa treba izgraditi pomoćne strukture podataka koje omogućuju izravniji pristup do traţenih zapisa.  Naivni algoritam za selekciju bio bi: sekvencijalno čitanje cijele R i provjera svakog zapisa zadovoljava li on B. Izvrednjavanje selekcije. Dakle. na standardni način. najvaţnije relacijske operacije su selekcija i projekcija. očito treba pročitati cijelu datoteku R i izdvojiti sve vrijednosti podatka A koje se pojavljuju. a unutrašnja petlja prolazi trenutno stvorenim dijelom datoteke S. učitaj prvi zapis iz R. Da bismo generirali datoteku koja odgovara projekciji S = R[A]. dok ( nismo prešli kraj od S i duplikat==0 ) { ako ( tekući zapisi iz R i S sadrţe istu vrijednost za A ) duplikat = 1. Izvrednjavanje projekcije. } ako ( duplikat == 0 ) prepiši vrijednost za A iz tekućeg zapisa iz R na kraj od S kao novi zapis. Vanjska petlja čita datoteku R.3. R je fizički prikazana istoimenom datotekom na standardni način.

Zato algoritmi za računanje presjeka liče na one za računanje prirodnog spoja. odluka što je bolje ovisi o fizičkoj graĎi baze podataka. Time smanjujemo potrebno vrijeme ukoliko se obje selekcije izvrednjavaju podjednako „sporo“ (dakle pregledom cijele relacije). a ne one od S. Niţa razina svodi se na izbor pogodnog algoritma za izvrednjavanje svake pojedine operacije unutar algebarskog izraza.Baze podataka . Ako se jedna relacija odvija brzo (na primjer zahvaljujući postojanju pomoćnih fizičkih struktura podataka) a druga sporo. U sortiranom nizu duplikati će se pojavljivati jedan iza drugoga. Optimizacija upita U prethodnim odjeljcima vidjeli smo da se optimizacija upita provodi na dvije razine. Očito vrijedi ovakva ekvivalencija: ( R where B1 ) where B2 = R where (B1 and B2 ). treba eliminirati zapise-duplikate. Kombiniranje selekcija. Tada je bolje postupiti na sljedeći način: izdvojiti sve vrijednosti za A koje se pojavljuju u R te zatim sortirati niz izdvojenih vrijednosti. već sluţi samo za ilustraciju. jer će rezultirajuća selekcija takoĎer biti spora.4. pa se oni obično ne implementiraju zasebno. odnosno pravila o tome koji od raspoloţivih algoritama je pogodan u kojoj situaciji.skripta  Ako je R velika.  Presjek dviju relacija moţe se shvatiti kao specijalni slučaj prirodnog spoja gdje su svi atributi zajednički. Viša razina bavi se transformacijom algebarskog izraza u oblik koji je pogodniji za izvrednjavanje. Obje razine optimizacije provode se tako da DBMS primjenjuje odgovarajuća pravila. Pritom se prvih šest primjera odnose na algebarsku transformaciju.3. Da bismo zornije prikazali postupak optimizacije upita. tada vrijedi: PMF – Matematički odsjek 117 . Znači. pa ih je lako eliminirati jednim sekvencijalnim čitanjem. Još jedna ideja je: razvrstati izdvojene vrijednosti za A u skupine pomoću hash funkcije. pa ih je opet lako eliminirati. Naš popis nije ni u kojem slučaju cjelovit ni konačan.  Unija dviju relacija R1 i R2 dobiva se na očigledni način. Opet pomaţe sortiranje datoteke R1 i R2. tada se kombiniranje ne isplati. a zadnji primjer na izbor algoritma za izvrednjavanje. Kod implementacije ostalih operacija pojavljuju se slične ideje kao kod prirodnog spoja ili projekcije. Izraz s lijeve strane treba pretvoriti u oblik s desne strane. Ako uvjet B sadrţi samo atribute od R. dakle pravila o ekvivalenciji algebarskih izraza. Pritom. slično kao kod projekcije. algoritam s ugnijeţĎenim petljama zahtijeva previše vremena. u nastavku ovog odjeljka navodimo sedam primjera pravila za optimizaciju. Izvlačenje selekcije ispred prirodnog spoja ili Kartezijevog produkta. Duplikati će se tada naći u istoj skupini. Računanje skupovne razlike takoĎer je slično.  Daljnji relacijski operatori mogu se izraziti pomoću već razmatranih. Pravila ovog tipa obično predstavljaju poslovnu tajnu proizvoĎača DBMS-a i sredstvo kojim oni pokušavaju postići komparativnu prednost jedan pred drugim. Bolji algoritam nije moguć jer se ionako svaki zapis iz datoteke R1 mora kombinirati sa svakim zapisom iz datoteke R2.  Izvrednjavanje ostalih operacija. 6. Na primjer:  Kartezijev produkt dviju relacija R1 i R2 računa se ugnijeţĎenom petljom. ili uporaba hash funkcije. dakle spajanjem datoteka.

Robert Manger ( R join S) where B = (R where B) join S. Moramo paziti da projiciranjem iz relacija ne izbacimo zajednički atribut prije nego što je bio obavljen prirodni spoj. B' predstavlja ostatak od B. Slična ekvivalencija moţe se napisati i za operaciju times. Općenitije.Y ] ) [ X ] = R[ X ] .Z ]) [ X. U ovom jednostavnom slučaju. tada je: ( R join S )[ X ] = R[ X ] join S[ X ] . Y i Z atributi od relacije R. To je posebno preporučljivo onda kad postoje fizička sredstva za brzu selekciju. tada vrijedi: ( (R[ X. Ako su X. Zato je dobro najprije smanjiti broj n-torki selektiranjem. ta jednakost je očigledna. ţelimo naći JMBAG-ove svih studenata na drugoj godini studija koji su upisali neki predmet kod nastavnika Kleina i dobili ocjenu veću od 2. 118 PMF – Matematički odsjek . BS sadrţi samo atribute od S. Ako uvjet B sadrţi samo atribute X po kojima se obavlja projiciranje. Upit se moţe izraziti kao: RESULT := ( (STUDENT join UPISAO join PREDMET) where ((GODINA_STUDIJA=2) and (OCJENA>2) and (OIB_NASTAVNIKA=44102179316)) ) [JMBAG]. Projiciranje moţe dugo trajati zbog eliminacije „duplikata“. ako B rastavimo na B = BR and BS and BC and B'. Na primjer. ( R times S) where B = (R where B) times S. tada je: R[ X ] where B = (R where B) [ X ] . Umjesto tri projekcije dovoljna je samo jedna. tada vrijedi: ( R join S) where B = ( (R where (BR and BC)) join (S where (BS and BC)) ) where B' . Primjenom transformacije dobivamo optimizirani izraz: RESULT := ( (STUDENT where GODINA_STUDIJA=2) join (UPISAO where OCJENA>2) join (PREDMET where OIB_NASTAVNIKA=44102179316) ) [JMBAG].Y. gdje BR sadrţi samo atribute od R. No u dugačkim i kompliciranim izrazima nije lako uočiti redundantno projiciranje. Kombiniranje projekcija. Ovakva transformacija se preporuča jer ona moţe znatno smanjiti broj n-torki koje ulaze u prirodni spoj odnosno Kartezijev produkt. Izvlačenje selekcije ispred projekcije. BC sadrţi zajedničke atribute od R i S. Ako X označava zajedničke atribute od relacija R i S. Izvlačenje projekcije ispred prirodnog spoja.

a adresa bloka zauzima 4 byte. treba odabrati algoritam ugnijeţĎenih petlji. Operacija intersect je specijalni slučaj od join. Ovo pravilo zasnovano je na analizi sloţenosti pojedinih algoritama koju smo proveli u Odjeljku 6. Predzadnja jednakost vrijedi pod pretpostavkom da X sadrţi primarne atribute od R (a time i od S). jer projekcija moţe spriječiti efikasnu implementaciju prirodnog spoja. Datoteka nikad ne sadrţi više od 100 zapisa. 6. tada je najefikasniji algoritam zasnovan na sortiranju i saţimanju. Datoteka s najboljim rezultatima neke računalne igre sastoji se od zapisa čiji oblik je prikazan na slici 6. Najčešća operacija je ispis rang liste najboljih rezultata (prvih n mjesta).2. Znači. Predloţite pogodnu organizaciju datoteke. PMF – Matematički odsjek 119 . Duljina zapisa je 40 byte. Tada odluku o izboru algoritma donosimo na sljedeći način. pa za nju vrijede ista pravila kao za join.  Ako su datoteke R1 i R2 već sortirane po zajedničkom podatku B. Optimizacija skupovnih operacija. AS atributi od S. Optimalni izbor algoritma za izvrednjavanje prirodnog spoja. ( R minus S ) [ X ] = R [ X ] minus S [ X ] . projekcija moţe stvoriti privremenu relaciju na koju nisu primjenjive postojeće pomoćne fizičke strukture.2.  Ukoliko je jedna datoteka dovoljno mala da stane u glavnu memoriju. Transformacijama se nastoji smanjiti broj n-torki koje sudjeluju u operacijama union i minus. ( R where B1 ) [ X ] union ( R where B2 ) [ X ] = ( R where (B1 or B2) ) [ X ] .skripta No pravilo ne vrijedi za proizvoljan skup atributa X.4. Zadaci za vježbu Zadatak 6. Nacrtajte odgovarajući dijagram.3. Treba izračunati prirodni spoj za relacije koje su pohranjene su u datotekama R1 i R2. ( R minus S ) where B = ( R where B ) minus ( S where B ) . Zahvat ne mora uvijek biti koristan. Koji put su od koristi sljedeća pravila koja se odnose na skupovnu uniju ili razliku: ( R union S ) where B = ( R where B ) union ( S where B ) .12. AC = AR ∩ AS zajednički atributi od R i S. Pretpostavljamo da se blok vanjske memorije sastoji od 512 byte.1.  Za velike datoteke R1 i R2 bez indeksa. Opet se smanjuje broj n-torki koje ulaze u prirodni spoj. ( R union S ) [ X ] = R [ X ] union S [ X ] . tada je najbolji algoritam zasnovan na indeksu.2. odluka što je bolje opet ovisi o fizičkoj graĎi. Neka su AR atributi od R.  Ako je jedna datoteka znatno veća od druge i ima odgovarajući indeks. najbolji je algoritam zasnovan na hash funkciji i razvrstavanju.Baze podataka . Stoje nam na raspolaganju četiri algoritma za računanje prirodnog spoja koji su bili opisani u Odjeljku 6. Na primjer. Tada vrijedi: ( R join S )[ X ] = ( R[(X ∩ AR) U AC] join S[(X ∩ AS) U AC] ) [ X ] .

 Koji vijci imaju promjer u zadanom intervalu?  Koji su vijci s duljinom navoja u zadanom intervalu?  Koji vijci imaju promjer glave u zadanom intervalu?  Razne Booleovske kombinacije prethodnih upita.12: Zapis s najboljim rezultatima računalne igre.Robert Manger BODOVI PREZIME I IME DATUM Slika 6. Nacrtajte odgovarajući dijagram. a adresa bloka zauzima 4 byte. Osim traţenja po identifikacijskom broju. a prijevod 35 znakova. Blok vanjske memorije sastoji se od 512 byte. a adresa bloka zauzima 4 byte. STRANA RIJEĈ PRIJEVOD Slika 6. Duljina zapisa je oko 120 byte. Slika 6. IDENTIFIKACIJSKI BROJ PROMJER VIJKA (mm) DULJINA NAVOJA (mm) PROMJER GLAVE …. Duljina zapisa je 150 byte. Očekujemo da će datoteka sadrţavati nekoliko tisuća zapisa. Oblik zapisa vidljiv je na Slici 6. Rječnik sadrţi oko 10000 riječi. Predloţite pogodnu organizaciju datoteke. Pretpostavljamo da se blok vanjske memorije sastoji od 512 byte.13. javlja se potreba za odgovaranjem na sljedeće upite. Nacrtajte odgovarajući dijagram.13: Zapis o automobilu. Najčešća operacija je: traţenje podataka o automobilu sa zadanim registarskim brojem. Očekujemo da će datoteka sadrţavati više od tisuću zapisa. Nacrtajte odgovarajući dijagram.15. Pretpostavljamo da se blok vanjske memorije sastoji od 512 byte. a adresa bloka zauzima 4 byte.2. Pritom se dozvoljava zadavanje početka strane riječi (prvih nekoliko slova) . Datoteka sadrţi tehničke karakteristike vijaka koji se rabe u nekoj tvornici. Datoteka sadrţi rječnik stranih riječi i sastoji se od zapisa čiji oblik je prikazan na Slici 6.14: Zapis o stranoj riječi.4.3. Slika 6. Zadatak 6. Datoteka automobila u nekom gradu sastoji se od zapisa čiji oblik je prikazan na Slici 6. znači duljina zapisa je 50 byte. Strana riječ zauzima 15 znakova.tada treba ispisati sve riječi koje počinju na zadani način i njihove prijevode. Zadatak 6. REGISTARSKA OZNAKA TIP AUTOMOBILA GODINA PREZIME I PROIZVODNJE IME VLASNIKA AUTOMOBILA ….15: Zapis o vijku. Predloţite pogodnu organizaciju datoteke. Predloţite pogodnu organizaciju datoteke. Zadatak 6. Najčešća operacija je ispis prijevoda za zadanu stranu riječ.14. 120 PMF – Matematički odsjek .

Rješavanjem Zadatka 3.10. Ukupan broj zaposlenih je nekoliko stotina. 49. Zadatak 6. dakle prepravite dijagram iz prethodnog zadatka. Osim traţenja na osnovi matičnog broja. Slika 6. 25. Na osnovu te sheme i bez čitanja ostatka priloga sami oblikujte odgovarajuću fizičku shemu za MySQL. 144. 225. Pretvorite tu relacijsku shemu u fizičku shemu za MySQL. Pretvorite tu relacijsku shemu u fizičku shemu za MySQL. Nacrtajte odgovarajući dijagram. Zadatak 6. 100. Zadatak 6. 169.1 ili 4. 196.7. Predloţite pogodnu organizaciju datoteke. Zbog fluktuacije kadra česta su ubacivanja i izbacivanja zapisa. Zadatak 6.skripta Zadatak 6. 121. Zapisi osnovne datoteke sadrţe sljedeće vrijednosti primarnog ključa: 1. Rješavanjem Zadatka 3.16: Zapis o zaposleniku. dakle oni sa zadanim zanimanjem i iz zadanog odjela.2 dobili ste relacijsku shemu baze podataka o knjiţnici.2 ili 4. Oblik zapisa prikazan je na Slici 6. 81. Na osnovu te sheme i bez čitanja ostatka priloga sami oblikujte odgovarajuću fizičku shemu za MySQL. 256. Uskladite indeks B-stablo s tom promjenom. 9. Datoteka sadrţi podatke o zaposlenima u nekom poduzeću. Rješavanjem Zadatka 3. Duljina zapisa je 200 byte. a adresa bloka zauzima 4 byte.16. 16.6. Pretpostavljamo da se blok vanjske memorije sastoji od 512 byte.8. 4. Zadatak 6. Usporedite vaše rješenje s onim u prilogu. Zadatak 6. 36. U Prilogu 2 pronaĎite normaliziranu relacijsku shemu baze podataka o znanstvenoj konferenciji. PMF – Matematički odsjek 121 .12.11.5.Baze podataka . traţe se i zaposleni sa zadanim zanimanjem ili iz zadanog odjela.1 dobili ste nadopunjenu relacijsku shemu baze podataka o fakultetu. MATIĈNI BROJ PREZIME I IME ZANIMANJE ODJEL …. Usporedite vaše rješenje s onim u prilogu. U Prilogu 1 pronaĎite relacijsku shemu baze podataka o bolnici. Prikaţite gusti indeks za tu datoteku pomoću B-stabla reda 3. Nacrtajte odgovarajući dijagram. Pretvorite tu relacijsku shemu u fizičku shemu za MySQL. Često se traţe i zaposleni koji istovremeno zadovoljavaju dva ovakva uvjeta.8 dobili ste relacijsku shemu za bazu podataka iz vašeg područja interesa. 64.3 ili 4. Zadatak 6. U osnovnu datoteku iz prethodnog zadatka ubačen je novi zapis s vrijednošću primarnog ključa 32.9.

Robert Manger 122 PMF – Matematički odsjek .

U ovom poglavlju upoznat ćemo se s nizom mehanizama za čuvanje integriteta i sigurnosti baze. drugi se implementiraju onda ako ih projektant ugradi u svoju fizičku shemu. U drugom poglavlju proučavamo dva aspekta sigurnosti: to su mogućnost oporavka baze u slučaju tehničkog oštećenja. no dio brige moţe preuzeti i projektant. Konzistentnost znači da su različiti podaci meĎusobno usklaĎeni.1. PMF – Matematički odsjek 123 . 7. dakle ne protuslove jedan drugome. Voljeli bismo kad bi se baza podataka sama mogla braniti od narušavanja integriteta. Prvo potpoglavlje govori o integritetu baze. Korektnost znači da svaki pojedini podatak ima ispravnu vrijednost. Treće poglavlje bavi se mehanizmima kojima DBMS omogućuje istovremeni rad korisnika. te konkretne načine njihovog uvoĎenja u fizičku shemu. Integritet baze lako bi se mogao narušiti na primjer pogrešnim radom aplikacija.1. tada DBMS neće izvršiti traţenu promjenu.1. U tu svrhu.Baze podataka . te zaštita od neovlaštenih radnji korisnika. Uvedena ograničenja DBMS će uključiti u konačnu realizaciju baze. suvremeni DBMS-i dozvoljavaju projektantu baze da definira takozvana ograničenja (constraints). Integritet i sigurnost baze podataka Ovo poglavlje posvećeno je integritetu i sigurnosti baze podataka.skripta 7. odrţavajući pritom integritet baze čak i onda kad korisnici istovremeno izvode konfliktne radnje. Neke od tih mehanizama automatski pokreće DBMS prilikom svog redovnog rada. treći opet stoje na raspolaganju administratoru koji ih pokreće po potrebi. Projektant uvodi ograničenja tako da ih upiše u fizičku shemu baze. Ako neko ograničenje nije zadovoljeno. Riječ je o problematici koja je izuzetno vaţna za ispravno funkcioniranje baze nakon što je ona bila implementirana te je ušla je u redovnu uporabu. Sljedeća tri odjeljka opisuju tri vrste ograničenja. Čuvanje integriteta Čuvati integritet baze znači čuvati korektnost i konzistentnost podataka. Riječ je o uvjetima (pravilima) koje korektni i konzistentni podaci moraju zadovoljavati. Integritet i sigurnost u prvom redu su briga administratora baze. već će dotičnoj aplikaciji poslati poruku o greški. Zahtjev da vrijednost primarnog atributa ne smije biti prazna takoĎer spada u ovu kategoriju. Uvođenje ograničenja kojima se uspostavlja integritet domene Ograničenja za integritet domene izraţavaju činjenicu da vrijednost atributa mora biti iz odgovarajuće domene. 7. To znači da će u kasnijem radu kod svake promjene podataka DBMS automatski provjeravati jesu li sva ograničenja zadovoljena. Poglavlje je podijeljeno u tri potpoglavlja. te o načinima kako projektant moţe dograditi svoju fizičku shemu tako da osigura čuvanje integriteta.

1 vidi se jedan način kako se uvoĎenjem dodatnog uvjeta moţe osigurati integritet domene za naš atribut BROJ_SOBE u zgradi s tri etaţe. Uvođenje ograničenja za čuvanje integriteta unutar relacije Ograničenja za čuvanje integriteta unutar relacije čuvaju korektnost veza izmeĎu atributa te relacije. Kao primjer.1 iznimno rabi sintaksu MS SQL Server-a. Vidimo da smo za neke atribute uspjeli vrlo precizno odrediti tipove. Slično rješenje postoji i u Oracle-u. dakle i 099 i 501. Pretpostavimo da su troznamenkasti brojevi soba tako oblikovani da prva znamenka odgovara etaţi. Zaista. 7. U skladu s time. CREATE TABLE NASTAVNIK (OIB NUMERIC(11) UNSIGNED NOT NULL. Slika 7. Dodatni uvjet zadan je unutar naredbe CREATE TABLE NASTAVNIK –dakle prikazana je nova verzija te naredbe koja bi trebala zamijeniti verziju sa Slike 6. čime smo osigurali integritet domene. ispravni brojevi soba su samo oni izmeĎu 101 i 399. '4'. godinu studija. No popis podrţanih tipova obično je presiromašan. 2 i 3. Da smo GODINU_ STUDIJA proglasili malim cijelim brojem.Robert Manger Ograničenje na integritet domene uvodi se u prvom redu tako da se u naredbi CREATE TABLE atributu pridruţi odgovarajući tip. BROJ_SOBE NUMERIC(3) CHECK (BROJ_SOBE BETWEEN 101 AND 399). PREZIME CHAR(20). DBMS će spriječiti upis studenta u 6. Najvaţniji primjer takvog ograničenja je ono koje traţi da dvije n-torke unutar iste relacije ne smiju imati jednaku vrijednost primarnog ključa. označene s 1. '2'. za GODINU_STUDIJA zadali smo da je tip ENUM. Slično ograničenje moţe se postaviti i za atribut koji nije odabran za primarni ključ ali je kandidat za ključ. Slika 7. '5'. PLACA NUMERIC(5) UNSIGNED. Tada tip NUMERIC(3) UNSIGNED kojeg smo pridruţili atributu BROJ_SOBE ne čuva integritet domene. uz eventualnu klauzulu NOT NULL.9.1. pogledajmo opet početnu fizičku shemu za bazu podataka o fakultetu na Slici 6. mnogi DBMS-i dozvoljavaju da se u shemu ugradi i precizniji uvjet kojeg vrijednosti atributa moraju zadovoljavati. na primjer funkcionalne ovisnosti. Zamislimo sada da se naš fakultet nalazi u zgradi koja ima tri etaţe. tako da samim pridruţivanjem tipa često ne uspijevamo u potpunosti izraziti potrebno ograničenje. što znači da GODINA_STUDIJA moţe poprimati samo vrijednosti iz navedene liste '1'. 124 PMF – Matematički odsjek . IME_ZAVODA CHAR(40). a DBMS će zbog tipa NUMERIC(3) UNSIGNED dozvoliti unos bilo kojeg pozitivnog troznamenkastog broja. Naime.1: Osiguravanje integriteta domene za BROJ_SOBE. tada ne bismo mogli spriječiti pogrešan upis. '3'.9. Takav uvjet moţe se uklopiti u naredbu CREATE TABLE ili se on moţe pojaviti kao zasebna naredba.2. IME CHAR(20). Budući da pridruţivanje tipa atributu ne osigurava da će se u potpunosti čuvati integritet domene. Na Slici 7. Budući da MySQL ovdje ne daje pravu podršku. PRIMARY KEY(OIB)).

Ako pogledamo fizičku shemu za bazu podataka o fakultetu na Slici 6. Svaka vrijednost takvog atributa u prvoj relaciji mora biti prisutna i u drugoj relaciji. Drugi način uvoĎenja istih ograničenja je eksplicitno stvaranje primarnih indeksa naredbom CREATE UNIQUE INDEX. pa BROJ_SOBE jednoznačno odreĎuje n-torku o nastavniku. s time da naredba CREATE TABLE ostaje nepromijenjena.9 tada ne čuva integritet unutar relacije jer se njome ne osigurava jedinstvenost vrijednosti za BROJ_SOBE. Tada atribut BROJ_SOBE postaje kandidat za ključ unutar relacije NASTAVNIK. UNIQUE(BROJ_SOBE)). CREATE TABLE NASTAVNIK (OIB NUMERIC(11) UNSIGNED NOT NULL. PLACA NUMERIC(5) UNSIGNED. naime ne smije se desiti da dva nastavnika sjede u istoj sobi. IME_ZAVODA CHAR(40).2 vide se dva načina kako se u MySQL-u uvoĎenjem dodatnog ograničenja moţe osigurati svojstvo ključa za BROJ_SOBE. dakle na atribut u jednoj relaciji koji je ujedno primarni ključ u drugoj relaciji. IME CHAR(20). zajedno s imenom ili imenima atributa koji čine primarni ključ odnosno kandidat za ključ.Baze podataka . CREATE UNIQUE INDEX NB_IND ON NASTAVNIK (BROJ_SOBE). PRIMARY KEY(OIB).1. zamislimo sada da na našem fakultetu vrijedi pravilo da svaki nastavnik mora imati zasebnu sobu. no način sa Slike 6.9. Drugi način svodi se na to da se shemi sa Slike 6. Prvi način svodi se na ubacivanje klauzule UNIQUE u naredbu CREATE TABLE NASTAVNIK – ovakva verzija naredbe trebala bi zamijeniti verziju sa Slike 6. BROJ_SOBE NUMERIC(3) UNSIGNED. vidimo da u svim naredbama CREATE TABLE postoje odgovarajuće klauzule PRIMARY KEY. Shema sa Slike 6. Kao primjer. Najčešće je riječ o ograničenjima koja se odnose na strani ključ.9 smatra se čitljivijim. 7. Uvođenje ograničenja kojima se čuva referencijalni integritet Ograničenja za čuvanje referencijalnog integriteta sluţe zato da se očuva konzistentnost veza izmeĎu relacija. Slika 7.9. Umjesto klauzule PRIMARY KEY mogli smo uporabiti naredbu CREATE UNIQUE INDEX. Znači. Na Slici 7. PREZIME CHAR(20). PMF – Matematički odsjek 125 .3.9 doda nova naredba CREATE UNIQUE INDEX. već u polaznoj verziji sheme osigurali smo da se čuva svojstvo ključa.skripta Ograničenje kojim se izraţava svojstvo ključa uvodi se u prvom redu tako da se u naredbu CREATE TABLE stavi klauzula PRIMARY KEY odnosno UNIQUE.2: Dva načina osiguravanja da BROJ_SOBE ima svojstvo ključa.

te ime relacije u kojoj taj isti atribut predstavlja strani ključ. Fizička shema sa Slike 6. koju moţemo rabiti kao zamjenu za shemu sa Slike 6. naime u njoj nisu označeni nikakvi odnosi izmeĎu atributa u različitim relacijama. Zahvaljujući navoĎenju sekundarnih indeksa.10. Naredbe su opet zapisane u sintaksi MySQL-a. Pritom nije moguće u relaciji ZAVOD istovremeno zadati i strani ključ OIB PROĈELNIKA jer bi taj strani ključ zahtijevao baš suprotni redoslijed stvaranja dviju relacija. Dakle eksplicitno navodimo ime atributa koji predstavlja strani ključ u dotičnoj relaciji. Relacija PREDMET sadrţi strane ključeve IME ZAVODA i OIB NASTAVNIKA koji odgovaraju primarnom ključu u relaciji ZAVOD odnosno NASTAVNIK. Svaki od primarnih atributa JMBAG i ŠIFRA PREDMETA iz relacije UPISAO predstavlja sam za sebe strani ključ vezan uz primarni ključ iz relacije STUDENT odnosno PREDMET.6.5 i 3.9 ne čuva integritet ni jednog od ovih stranih ključeva.3 sadrţi novu verziju fizičke sheme za bazu podataka o fakultetu. to jest sadrţe samo klauzule FOREIGN KEY.3 drukčiji nego na Slici 6. 126 PMF – Matematički odsjek . Jedini strani ključ kojeg smo ispustili je OIB PROĈELNIKA u relaciji ZAVOD. Kao drugo.3 usput zamjenjuje i Sliku 6.9. Primijetimo da je redoslijed naredbi CREATE TABLE na Slici 7. naime nema više potrebe za zasebnim naredbama CREATE INDEX. iz relacije PREDMET neće se moći brisati n-torka sa ŠIFROM PREDMETA koja se pojavljuje u relaciji UPISAO. DBMS na primjer neće dozvoliti da se u relaciju UPISAO ubaci n-torka s vrijednošću JMBAG koje nema u relaciji STUDENT. U današnjim DBMS-ima ograničenje kojim se čuva svojstvo stranog ključa uvodi se tako da se u odgovarajuću naredbu CREATE TABLE stavi klauzula FOREIGN KEY … REFERENCES … .9. To je zato što se bilo koja relacija sa stranim ključem moţe stvoriti tek nakon što već postoji ona relacija koju taj strani ključ referencira. Nakon realizacije sheme sa Slike 7.Robert Manger Ako pogledamo našu bazu podataka o fakultetu sa Slike 3. uz svaki strani ključ morali smo eksplicitno deklarirati sekundarni indeks koji će sluţiti za traţenje po tom ključu. Kao prvo. Na Slici 7. jedino takva graĎa datoteka unutar MySQL-a omogućuje provjeru svojstava stranog ključa. TakoĎer. dakle ključ iz relacije ZAVOD. tada uočavamo da u njoj postoji mnogo stranih ključeva. Zahvaljujući klauzulama FOREIGN KEY. ova nova verzija ima uvedena ograničenja za čuvanje integriteta gotovo svih prije navedenih stranih ključeva. Na primjer. Relacija NASTAVNIK ima kao strani ključ IME ZAVODA. Slika 7.3. odgovarajuće naredbe CREATE TABLE obično izgledaju jednostavnije.3 vidimo takoĎer i neke specifičnosti MySQL-a. morali smo zahtijevati da se za sve datoteke umjesto standardne indeks-sekvencijalne organizacije rabi specifična organizacija InnoDB. U relaciji ZAVOD nalazi se strani ključ OIB PROĈELNIKA koji odgovara ključu OIB iz relacije NASTAVNIK. Slika 7. relacija NASTAVNIK se zbog stranog ključa IME ZAVODA mora stvarati nakon relacije ZAVOD. a ostali parametri se biraju automatski. Kod drugih DBMS-a. Naime.

SIFRA_PREDMETA NUMERIC(5) UNSIGNED NOT NULL. OCJENA ENUM('2'.skripta CREATE TABLE STUDENT (JMBAG NUMERIC(10) UNSIGNED NOT NULL. PMF – Matematički odsjek 127 . PRIMARY KEY(IME_ZAVODA)) ENGINE=INNODB.Baze podataka . SEMESTAR ENUM('Z'. PRIMARY KEY(JMBAG)) ENGINE=INNODB. Slika 7. PREZIME CHAR(20). INDEX NI_IND (IME_ZAVODA). PLACA NUMERIC(5) UNSIGNED. BROJ_SOBE NUMERIC(3) UNSIGNED. CREATE TABLE ZAVOD (IME_ZAVODA CHAR(40) NOT NULL. PREZIME CHAR(20). INDEX PI_IND (IME_ZAVODA). CREATE TABLE NASTAVNIK (OIB NUMERIC(11) UNSIGNED NOT NULL. INDEX US_IND (SIFRA_PREDMETA). INDEX PO_IND (OIB_NASTAVNIKA). PRIMARY KEY(JMBAG. CREATE TABLE UPISAO (JMBAG NUMERIC(10) UNSIGNED NOT NULL. FOREIGN KEY (IME_ZAVODA) REFERENCES ZAVOD(IME_ZAVODA).3: Čuvanje integriteta za strane ključeve.'3'. PRIMARY KEY(SIFRA_PREDMETA). FOREIGN KEY (SIFRA_PREDMETA) REFERENCES PREDMET(SIFRA_PREDMETA)) ENGINE=INNODB. OPIS_DJELATNOSTI CHAR(160). FOREIGN KEY (IME_ZAVODA) REFERENCES ZAVOD(IME_ZAVODA)) ENGINE=INNODB. ECTS_BODOVI NUMERIC(2) UNSIGNED.'3'.'2'. IME CHAR(20). PRIMARY KEY(OIB).'5'). INDEX UJ_IND (JMBAG). NASLOV CHAR(80). IME CHAR(20).'L'). CREATE TABLE PREDMET (SIFRA_PREDMETA NUMERIC(5) UNSIGNED NOT NULL.'4'. OIB_PROCELNIKA NUMERIC(11) UNSIGNED. OIB_NASTAVNIKA NUMERIC(11) UNSIGNED. FOREIGN KEY (OIB_NASTAVNIKA) REFERENCES NASTAVNIK(OIB)) ENGINE=INNODB.'4'.'5'). SIFRA_PREDMETA). FOREIGN KEY (JMBAG) REFERENCES STUDENT(JMBAG). DATUM_UPISA DATE. GODINA_STUDIJA ENUM('1'. IME_ZAVODA CHAR(40). IME_ZAVODA CHAR(40).

Njezin nastanak i odrţavanje iziskuju goleme količine ljudskog rada.Robert Manger Na kraju. No meĎu-stanja koja nastaju nakon pojedinih operacija unutar transakcije mogu biti nekonzistentna.1. U ovom potpoglavlju opisujemo kako projektant odnosno administrator baze mogu postići da se ti mehanizmi aktiviraju tijekom rada baze. No u tijeku realizacije tog prebacivanja doći će do privremene nekonzistencije. nepaţnje korisnika ili zlonamjernih radnji. gdje se zadani novčani iznos prebacuje s jednog bankovnog računa na drugi. 7. Shema sa Slike 7. Makar jedna transakcija s korisničkog stanovišta predstavlja jednu nedjeljivu cjelinu. Vjerojatno bi bilo dovoljno provjeravati samo sekundarne ključeve u relaciji UPISAO. 128 PMF – Matematički odsjek . pogrešnih transakcija. prebacivanje novaca s jednog bankovnog računa na drugi čuva konzistenciju u smislu da ukupna količina novca na svim računima ostaje ista.2. 7. ili obratno.2. Na primjer. Ostali odjeljci bave se suptilnijim aspektom koji se tiče zaštite baze od neovlaštenih radnji korisnika. dakle oporavkom baze u slučaju njezinog većeg ili manjeg oštećenja. Današnji DBMS-i raspolaţu djelotvornim mehanizmima za sigurnost. novci će netragom nestati ili će se stvoriti niotkud. sjetimo se da se rad s bazom u pravilu svodi na pokretanje takozvanih transakcija. te povećanje salda na drugom. pogotovo onog za referencijalni integritet. To znači da se ne smije desiti da podaci budu uništeni ili oštećeni zbog tehničkog kvara. Zato se od DBMS-a očekuje da on u što većoj mjeri garantira sigurnost podataka. bit će stavljeni na drugi račun prije nego što su bili skinuti s prvog. no ono se realizira kroz dvije zasebne promjene u bazi: smanjivanje salda na jednom računu. budući da se jedino tu radi o nešto većoj količini podataka. Transakcija koja iz bilo kojeg razloga nije do kraja bila obavljena morala bi biti neutralizirana – dakle svi podaci koje je ona do trenutka prekida promijenila morali bi natrag dobiti svoje polazne vrijednosti. predstavlja teret za DBMS i doprinosi usporavanju rada. transakcija mora u cijelosti biti izvršena ili uopće ne smije biti izvršena. Ako se transakcija prekine tijekom realizacije. jer će novci biti skinuti s jednog računa a neće još biti stavljeni na drugi. Takvo prebacivanje predstavlja jednu logičku cjelinu. Osnovno svojstvo transakcije je da ona prevodi bazu iz jednog konzistentnog stanja u drugo.3 predstavlja svojevrsno pretjerivanje jer smo za 5 relacija uveli 5 referencijalnih integriteta. Projektant zato treba odmjeriti koja ograničenja su stvarno potrebna. ona se obično realizira kao niz od nekoliko elementarnih zahvata u samoj bazi. treba napomenuti da provjera svakog ograničenja. Da bi se očuvao integritet baze. Sigurnost baze Baza podataka predstavlja dragocjen resurs. Stvaranje pretpostavki za oporavak baze Da bismo bolje razumjeli načine kako sve moţe doći do oštećenja baze. Tipičan primjer transakcije je bankovna transakcija. a koja se mogu zanemariti ili zamijeniti odgovarajućim provjerama u aplikacijama. Prvi odjeljak bavi se tehničkim aspektom sigurnosti.

Rabi se postupak odmotavanja unatrag (roll-back). te hardverske greške. Dakle čita se ţurnal od kraja prema početku. Najprije se uspostavlja stanje iz zadnje rezervne kopije. Na primjer. Daljnji.skripta Rekli smo već da se baza podataka u toku svog rada moţe naći u neispravnom stanju. Sam postupak neutralizacije moţe se promatrati kao svojevrsni mikroskopski oblik oporavka. Naime. Od suvremenog DBMS-a očekuje se da u svim slučajevima oštećenja baze omogući njezin oporavak.  Ţurnal datoteka omogućuje neutralizaciju transakcije koja je došla do kraja i trajno je promijenila bazu. Time se uspostavlja stanje zabiljeţeno zadnjom rezervnom kopijom (moţda od prošlog tjedna). Pritom završetak moţe biti potvrda (commit) da je transakcija ispravno obavljena. Zatim se rabi postupak odmotavanja unaprijed (roll-forward).  Rezervna kopija baze omogućuje ponovno uspostavljanje baze u slučaju njezinog znatnijeg oštećenja. Za jednu transakciju ţurnal evidentira adresu svakog zapisa kojeg je transakcija promijenila. dakle povratak u stanje koje je što aţurnije i pritom još uvijek konzistentno. pa se te stare vrijednosti ponovo upisuju na odgovarajuća mjesta u bazu. Navedene pretpostavke za oporavak baze zaista omogućuju razne oblike oporavka. Zato se kopiranje ne obavlja suviše često. a DBMS će neutralizirati promjene podataka. pronalaze se stare vrijednosti zapisa koje je transakcija mijenjala. mora biti ispunjena bar neka od sljedećih pretpostavki. a u slučaju opoziva one se neutraliziraju odnosno zaboravljaju. softverske greške u DBMS-u ili operacijskom sustavu. Ona se dobiva snimanjem cijele baze na drugi medij (drugi disk ili magnetsku traku). Dakle čita se ţurnal datoteka od početka prema kraju. PMF – Matematički odsjek 129 . dakle transakcija koja se počela izvršavati. kad god aplikacija ustanovi da se transakcija ne moţe izvršiti do kraja.  Održava se žurnal-datoteka. Za vrijeme izvršavanja transakcije DBMS samo privremeno pamti promjene u bazi. zajedno s prethodnom vrijednošću tog zapisa i novom vrijednošću. najčešći razlog koji dovodi do oštećenja baze je baš neispravno izvedena transakcija. no nije bila ni neutralizirana.Baze podataka . ili njezin opoziv (rollback). već periodički u unaprijed predviĎenim terminima – na primjer jednom tjedno. nije bila obavljena do kraja. te se ponovo unose u bazu sve zabiljeţene promjene podataka redom za svaku potvrĎenu transakciju.  DBMS-ovom kontrolom transakcija uz mogućnost opoziva znatno se smanjuje broj transakcija koje će oštetiti bazu svojim djelomičnim izvoĎenjem. te da eksplicitno objavi njezin završetak. Postupak se svodi na presnimavanje svih podataka iz rezervne kopije natrag u bazu.  Uključen je DBMS-ov mehanizam za upravljanje transakcijama. Riječ je o datoteci gdje je ubiljeţena „povijest“ svake transakcije koja je mijenjala bazu nakon zadnjeg stvaranja rezervne kopije.  Rezervna kopija i ţurnal datoteka zajedno omogućuju još bolji oporavak baze koja je pretrpjela znatnije oštećenje. ali se naknadno utvrdilo da je bila pogrešna ili nepotrebna. te promjene se trajno upisuju u bazu. U slučaju potvrde. ona će ju opozvati. na primjer kvar diska. Budući da se ispravni rad s bazom postiţe cjelovitim izvoĎenjem transakcija. i to u trenutku kad smatramo da je baza u konzistentnom stanju. no mnogo rjeĎi razlozi koji takoĎer mogu dovesti do oštećenja baze su: pogrešno sastavljena transakcija. Stvaranje kopije je dugotrajna operacija koja moţe ometati redovni rad korisnika. Tada DBMS očekuje od aplikacije da ona eksplicitno najavi početak transakcije.  Povremeno se stvara rezervna kopija baze. Time se uspostavlja prilično aţurno stanje koje je prethodilo oštećenju. No da bi oporavak zaista bio moguć.

To se zove autocommit mode. uključivanje pojedinog mehanizma donosi veću sigurnost.   Stvaranje rezervne kopije MySQL baze obavlja se pozivom usluţnog programa mysqldump. 130 PMF – Matematički odsjek . ali opterećuje svakodnevni rad baze i smanjuje performanse. u mnogim DBMS-ima uporaba odreĎenih mehanizama zaštite moguća je samo pod uvjetom da su datoteke organizirane na odgovarajući način. to jest projektantova fizička shema mora biti kompatibilna s njegovim vlastitim planovima za kasniju zaštitu. Naime.Robert Manger Opisani mehanizmi i sredstva za oporavak baze mogu se uključivati i dodavati po potrebi. Naime. Time je odreĎeno ime datoteke u koju će se upisivati sve promjene baze. dakle svaku SQL naredbu on smatra zasebnom cjelinom i odmah ju izvršava u bazi. Projektant treba procijeniti kakve vrste transakcija će se izvršavati. projektant treba dati odgovarajuće preporuke budućem administratoru i programerima. a opoziv neuspjele transakcije naredbom ROLLBACK. No taj default moţe se promijeniti tako da aplikacija ili korisnik pošalju naredbu SET AUTOCOMMIT = 0. Štoviše. tada treba zaustaviti mysqld i ponovo ga pokrenuti bez navedene opcije. Taj program prilikom pokretanja čita komandnu datoteku koja u svojem standardnom obliku sadrţi opciju oblika --log-update=ime_datoteke . ali pod uvjetom da su sve datoteke tipa InnoDB.  MySQL po defaultu ne upravlja transakcijama. Nakon toga. Takva ograničenja projektant mora uzeti u obzir kod oblikovanja fizičke graĎe. koliki je stvarni rizik od oštećenja. odluka koja će se sredstva rabiti zapravo spada u nadleţnost projektanta. U nastavku ćemo opisati kako se opisani mehanizmi i sredstva za oporavak baze realiziraju u MySQL-u. MySQL po defaultu odrţava ţurnal datoteku. Na osnovu svoje procjene. Ako ţelimo isključiti ţurnal datoteku. sam DBMS realiziran je kao program mysqld . tako da njima obično rukuju administrator baze i programeri koji razvijaju aplikacije. Ipak. Program se poziva iz komandne ljuske operacijskog sustava i prima opcije koje odreĎuju koja baza će se presnimiti kamo. Potvrda da je transakcija uredno završila postiţe se naredbom COMMIT. moguće je upravljati transakcijama. Početak transakcije mora se eksplicitno označiti naredbom BEGIN. te u kojoj mjeri se isplati ţrtvovati performanse zbog veće sigurnosti.

skripta Kao primjer upravljanja transakcijama u MySQL-u. Primijetimo da fizička shema sa Slike 7. CREATE. 7.*). Doseg ovlaštenja moţe biti: globalno za sve baze koje kontrolira dotična instalacija MySQL (*. UPDATE NASTAVNIK SET PLACA = PLACA – 1000 WHERE PREZIME = 'Turing'.ime_relacije). odnosno u slučaju ALL daju mu se sva ovlaštenja. Cijeli ovaj niz naredbi proglašen je nedjeljivom cjelinom koja se mora izvršiti u cijelosti ili se uopće ne smije izvršiti. Na taj način čuva se konzistencija u smislu da ukupan zbroj plaća ostaje isti. PMF – Matematički odsjek 131 . ALTER. COMMIT. …. Kao prvi primjer davanja ovlaštenja u MySQL. Dakle. UvoĎenje korisnika i upravljanje njihovim ovlaštenjima obično je posao administratora baze. SET AUTOCOMMIT = 0. ili čak za pojedine atribute unutar jedne relacije.*). Promjene se obavljaju u relaciji NASTAVNIK koja je opisana fizičkom shemom na Slici 7. te predloţi njihova ovlaštenja. ovlaštenje je pridruţeno „e-mail adresi“ ime_korisnika@ime_stroja. Odabir InnoDB je nuţnost jer MySQL znade upravljati jedino transakcijama koje se odvijaju nad takvim datotekama. a plaća nastavnika Pascala povećava za 1000. Davanje ovlaštenja korisnicima Zaštita podataka od neovlaštene uporabe uglavnom se postiţe tako da se korisnicima pomoću SQL naredbi GRANT i REVOKE dodjeljuju ili uskraćuju ovlaštenja.3. Projektantovi naputci mogu kasnije sluţiti administratoru kao obrazac za uvoĎenje daljnjih korisnika. Ipak. u nastavku je prikazan niz naredbi kojima se plaća nastavnika Turinga smanjuje za 1000.3 traţi da sve datoteke budu tipa InnoDB.) SET AUTOCOMMIT = 1. DROP. Uobičajena ovlaštenja su: SELECT. DELETE. dobro je da projektant u sklopu fizičkog oblikovanja baze već predvidi nekoliko tipičnih korisnika. BEGIN. To znači da ista osoba moţe imati drukčija ovlaštenja ukoliko se prijavljuje s drugog stroja. pojedino ovlaštenje veţe se uz kombinaciju MySQL-ovog imena korisnika i imena stroja s kojeg se korisnik prijavljuje. U MySQL. INSERT. a njima se korisnika ovlašćuje da pokreće istoimene SQL naredbe.2. za jednu relaciju jedne baze (ime_baze. za jednu takvu bazu (ime_baze. najprije navodimo naredbu GRANT kojom administrator neregistriranom (anonymous) korisniku dozvoljava pretraţivanje fakultetske baze fakultet.2. ALL. UPDATE NASTAVNIK SET PLACA = PLACA + 1000 WHERE PREZIME = 'Pascal'. UPDATE. (ili ROLLBACK.Baze podataka .

(ispisuje se: nepoznato_ime@local host) > USE fakultet. > CREATE DATABASE someuser. 'Zavod za racunarstvo'.Robert Manger > GRANT SELECT on fakultet. te smije pretraţivati fakultetsku bazu fakultet. 33571209458. (poruka o greški) . Na kraju radi s bazom fakultet gdje uspješno pregledava sadrţaj jedne relacije... > SELECT * FROM PREDMET. navodimo naredbe kojima administrator stvara korisnika someuser s lozinkom loz000. Nakon što se izvela ova naredba GRANT. > GRANT ALL ON someuser. > INSERT INTO PREDMET VALUES (33333. Dalje prikazujemo jednu moguću sesiju korisnika someuser.. 5)). moguća je ovakva sesija neregistriranog korisnika koji uspješno pregledava sadrţaj fakultetske baze no ne uspijeva izvršiti promjene u njoj. a redci koji počinju s > izvode se unutar komandne ljuske mysql..* TO ''@localhost. moţe raditi sve što hoće u svojoj bazi s imenom someuser. 'Novi naslov' .* TO someuser@localhost IDENTIFIED BY 'loz000'. Zatim uspješno stvara i aţurira relaciju unutar svoje baze someuser gdje ima sva ovlaštenja. $ mysql –u someuser –p Enter password: ****** (loz000) > SELECT USER( ). . Kao drugi primjer davanja ovlaštenja u MySQL-u. Redci koji počinju sa $ izvode se u ljusci operacijskog sustava. $ mysql –u nepoznato_ime > SELECT USER.. someuser najprije neuspješno pokušava gledati bazu tudja_baza za koju nema nikakvih ovlaštenja.* TO someuser@localhost. (ispis) . > GRANT SELECT ON fakultet.... 132 PMF – Matematički odsjek . (ispisuje se: someuser@localhost) > USE tudja_baza. 'L'. Nakon što se prijavio navoĎenjem lozinke. koji se prijavljuje s lokalnog računala. . no ne uspijeva izvršiti promjene u njoj.

'Novi naziv'). no uspijeva pročitati relaciju NASTAVNIK iz iste baze.. Najprije vidimo naredbe kojima administrator korisniku someuser oduzima pravo čitanja relacija PREDMET. (poruka o greški) . Zatim je moguća sljedeća sesija korisnika someuser.* FROM ''@localhost.. 'Zavod za racunarstvo'. ZAVOD i UPISAO u fakultetskoj bazi fakultet. .. > GRANT SELECT ON fakultet. > INSERT INTO PREDMET VALUES (33333.. > USE fakultet..Baze podataka .. > SELECT * FROM PREDMET. > REVOKE SELECT ON fakultet. PRIMARY KEY(ID))..skripta > SHOW TABLES. NAZIV CHAR(20)... . . (ispis) .. gdje on nakon prijave neuspješno pokušava čitati relaciju PREDMET iz fakultetske baze.. (poruka o greški) .. $ mysql –u someuser -p Enter password: ****** (loz000) > USE fakultet. . U nastavku slijedi primjer oduzimanja ovlaštenja u MySQL. 'L'. > USE someuser.* FROM someuser@localhost.. > INSERT INTO PROBA VALUES (44. > REVOKE SELECT on fakultet. 5)).. 33571209458. (poruka o greški) . > CREATE TABLE PROBA (ID NUMERIC(2) UNSIGNED NOT NULL..STUDENT TO someuser@localhost.NASTAVNIK TO someuser@localhost. > GRANT SELECT ON fakultet. PMF – Matematički odsjek 133 . 'Novi naslov'. > SELECT * FROM PREDMET..

Definiranje pogleda za pojedine vrste korisnika moglo bi se prepustiti administratoru baze. Svaki DBMS ima neke svoje specifičnosti. (ispis) . Pritom se virtualne relacije koje čine pogled izvode iz stvarnih relacija koje čine globalnu shemu. tako da se mogućnosti davanja i oduzimanja ovlaštenja dosta razlikuju. Ako to nije učinio prije. budući da je to aktivnost koja zadire u logičku razinu oblikovanja. Korisnik tada „vidi“ samo dio baze.4 sadrţi prvi primjer uporabe pogleda kao mehanizma zaštite u fakultetskoj bazi sa Slike 6. Da bi zaštita preko pogleda zaista funkcionirala. Ako postoji podrška za korisničke skupine. projektant ili administrator mogu odreĎenom korisniku pridruţiti njegov pogled na bazu. Da bismo zaista zaštitili podatak 134 PMF – Matematički odsjek . a ostali podaci su mu nedostupni. No pogledi mogu sluţiti i za zaštitu podataka. Na taj način. naredbe GRANT i REVOKE primjenjive su ne samo na stvarne relacije nego i na poglede. Naredba je pisana u sintaksi MySQL.. jedino što u njoj nema atributa PLACA. . ali da moţe pristupiti pogledima. Na kraju ovog odjeljka treba još naglasiti da se sustav ovlaštenja uvijek oslanja na zaštitu fizičkih direktorija i datoteka na razini operacijskog sustava računala. U SQL-u se relacija-pogled zadaje naredbom CREATE VIEW. čime on nasljeĎuje sva ovlaštenja za tu skupinu.. Prethodni primjeri naredbi GRANT i REVOKE sadrţavali su u sebi specifičnosti MySQL-a. Gornji dio Slike 7. U relacijskom modelu. potrebno je još dotičnom korisniku regulirati ovlaštenja. tada se ovlaštenja ne trebaju dodjeljivati individualnim korisnicima već skupinama. Cilj koji se u tom primjeru ţeli postići je skrivanje povjerljivog podatka o plaći nastavnika. pa su mu time bitno ograničene njegove mogućnosti zlouporabe podataka. Ono što MySQL nema. a izvoĎenje iz globalnih relacija opisuje se naredbom SELECT koja je ugnijeţĎena u CREATE VIEW.13. korisnik je prisiljen raditi samo s onim podacima koje smo obuhvatili pogledima.. točnije program mysqld. a mnogi drugi DBMS-i imaju. projektant bi najvaţnije poglede trebao definirati u sklopu svoje fizičke sheme navoĎenjem odgovarajućih naredbi CREATE VIEW.Robert Manger > SELECT * FROM NASTAVNIK. Navedena naredba CREATE VIEW stvara virtualnu relaciju NAST_VIEW1 koja izgleda skoro isto kao i stvarna relacija NASTAVNIK. i globalna shema i pogled (pod-shema) zadaju se kao skup relacija. Naime. mogućnost je uvoĎenja korisničkih skupina. No bolje je da se time bavi projektant. Uporaba pogleda kao mehanizma zaštite U Poglavlju 1 spomenuli smo poglede (pod-sheme) kao sredstvo za postizavanje logičke nezavisnosti podataka.. Naime. Tako na primjer u slučaju MySQL-a zaštita u operacijskom sustavu mora biti postavljena tako da jedini proces koji smije pristupati fizičkim direktorijima i datotekama bude sam MySQL. 7.3.2. Pomoću GRANT i REVOKE mora se osigurati da korisnik nema pristupa do stvarnih relacija. Svakog individualnog korisnika smještavamo u neku skupinu. Takav način rada je spretan ako imamo velik broj korisnika sa sličnim ovlaštenjima.

naruše integritet baze. Šifre upisanih predmeta zamijenjene su naslovima predmeta. Opet se sluţimo sintaksom MySQL-a. koje bi mogle biti u meĎusobnom konfliktu. Slika 7. Tajnica smije pristupiti svim podacima o nastavnicima.SIFRA_PREDMETA = PREDMET. ali sve to samo za nastavnike iz njezinog zavoda. Donji dio Slike 7. Ipak.SIFRA_PREDMETA. IME. no skriveni su mu podaci o upisima drugih studenata. DBMS i u tom slučaju mora paţljivo koordinirati radnje korisnika. Svaki korisnik pritom treba imati dojam da sam radi s bazom. broj prodanih autobusnih karata za istu voţnju autobusom treba simultano biti dostupan raznim potencijalnim kupcima koji bi istovremeno htjeli kupiti kartu za tu voţnju. naime on ne smije dopustiti da te istovremene radnje.3.JMBAG = 0036398757 AND UPISAO. CREATE VIEW NAST_VIEW2 AS SELECT * FROM NASTAVNIK WHERE IME_ZAVODA = 'Zavod za raĉunarstvo'. Riječ je o mehanizmima koji su ugraĎeni u DBMS i PMF – Matematički odsjek 135 . PREDMET WHERE UPISAO. Obično je riječ o prividnoj istovremenosti (dijeljenje vremena istog računala). Znači jedan te isti podatak.skripta o plaći. CREATE VIEW UPISAO_VIEW AS SELECT PREDMET.OCJENA FROM UPISAO. CREATE VIEW NAST_VIEW1 AS SELECT OIB. Dakle tajnica vidi „horizontalni“ segment originalne relacije (samo neke retke). UPISAO. pohranjen na jednom mjestu. Dotični student vidi podatke o predmetima koje je on upisao.Baze podataka . 7. potreban je raznim osobama i raznim aplikacijama. UPISAO.DATUM_UPISA. Od suvremenog DBMS-a traţi se da korisnicima omogući istovremeni pristup do podataka. Dakle student vidi relaciju koja u tom obliku ne postoji u bazi već se dobiva spajanjem podataka iz dviju postojećih relacija. čak i njihovim plaćama. Istovremeni pristup Većina baza podataka po svojoj prirodi je višekorisnička. PREZIME. Prikazana naredba CREATE VIEW stvara pogled NAST_VIEW2 namijenjen tajnici Zavoda za računarstvo unutar fakulteta. BROJ_SOBE FROM NASTAVNIK.4: Uporaba pogleda u fakultetskoj bazi podataka.4 vidimo još jedan primjer zaštite fakultetske baze podataka pomoću pogleda. U ovom potpoglavlju bavimo se mehanizmima i metodama za čuvanje integriteta baze u uvjetima istovremenog rada korisnika.4 sadrţi treći primjer uporabe pogleda u fakultetskoj bazi podataka.NASLOV. Korisnik tada vidi „vertikalni“ segment originalne relacije (samo neke stupce). Na primjer. moţda čak u isto vrijeme. U srednjem dijelu Slike 7. Naredba CREATE VIEW pisana u MySQL-u definira pogled UPISAO_VIEW namijenjen studentu s JMBAG-om 0036398757. IME_ZAVODA. većinu korisnika baze moramo ovlaštenjima prisiliti da rabe NAST_VIEW1 kao zamjenu za NASTAVNIK.

Dakle u bazi sada piše da nema slobodnih sjedala. U tom trenutku postoji samo jedno slobodno sjedalo u autobusu. dva studenta morala bi sjediti na istom sjedalu u autobusu. ako to svojstvo zaista vrijedi. zamislimo da studenti iz naše fakultetske baze podataka organiziraju ekskurziju autobusom. da učinak istovremenog izvršavanja transakcija mora biti ekvivalentan nekom sekvencijalnom izvršavanju. dakle jedna iza druge u nekom (bilo kojem) redoslijedu. Traţeno svojstvo.Robert Manger aktiviraju se automatski. Serijalizabilnost paralelnih transakcija Kao što smo rekli u prošlom potpoglavlju. 3.3. 6. Zahtjev da se integritet baze ne smije narušiti zbog istovremenog pristupa preciznije se izraţava kao svojstvo serijalizabilnosti. istovremeno pokušavaju dobiti kartu za ekskurziju. ili o metodama koje moraju rabiti programeri prilikom pisanja svojih aplikacija. Dva studenta. Da bismo odrţali integritet baze. učitani broj je neaţuran. 136 PMF – Matematički odsjek . Naţalost. Dolazi do slijedećeg vremenskog redoslijeda izvršavanja elementarnih operacija. Iz istih razloga i T2 izdaje drugom studentu kartu. te koliko još ima slobodnih sjedala. Dakle. Slično i T2 unosi u bazu svoju promijenjenu vrijednost za broj slobodnih sjedala. 7. 4. Vidimo da se ovaj način stvorila jedna karta previše. Studenti koji ţele ići na ekskurziju moraju na on-line način rezervirati svoje mjesto u autobusu. T2 smanjuje pročitanu vrijednost s 1 na 0. Pokreću se dvije transakcije. T1 izdaje studentu kartu. T1 učitava iz baze broj slobodnih sjedala. drugim riječima. Budući da je na početku svog rada naišla na broj slobodnih sjedala veći od 0. Nekontrolirano paralelno izvršavanje transakcija moţe vrlo lako dovesti do neţeljenih efekata.1. 1. Tada je prilikom uporabe baze moguć sljedeći scenarij. svaki sa svog računala od kuće. Ili. Dakle u bazu se ponovo upisuje da nema slobodnih sjedala. Promjena je za sada učinjena samo u radnoj memoriji računala. Broj studenata koji će ići na ekskurziju ograničen je brojem sjedala u autobusu. T1 smanjuje pročitanu vrijednost s 1 na 0. Zbog evidencije tko sve ide na ekskurziju. 8. ona se obično realizira kao niz od nekoliko elementarnih zahvata u samoj bazi. Budući da je stanje baze još uvijek nepromijenjeno. T2 učitava iz baze broj slobodnih sjedala. dakle 1. U višekorisničkoj bazi dešavat će se da se nekoliko transakcija izvodi paralelno. T1 i T2. kaţemo da je dotično paralelno izvršavanje skupa transakcija bilo serijalizabilno. Promjena je opet učinjena samo u radnoj memoriji. naša fakultetska baza podataka proširena je novim relacijama. 2. T1 unosi u bazu promijenjenu vrijednost za broj slobodnih sjedala. 5. naziva se serijalizabilnost. 7. koje za svako sjedalo u autobusu biljeţe koji student ga je zauzeo. rad korisnika s bazom podataka svodi se na pokretanje unaprijed definiranih transakcija. Osnovne operacije koje pripadaju raznim transakcijama tada će se vremenski ispreplesti. koje DBMS „istovremeno“ obavlja. Da bismo to pokazali. Makar jedna transakcija sa korisničkog stanovišta predstavlja jednu nedjeljivu cjelinu. moramo zahtijevati da učinak tih paralelnih transakcija bude isti kao da su se one izvršavale sekvencijalno. svojstvo serijalizabilnosti ne moţe se a priori garantirati.

Uporaba lokota krije u sebi i odreĎene opasnosti. Ovaj mehanizam dovoljan je da otkloni probleme iz prethodnog primjera. Veličina dijela baze kojem je pridruţen jedan lokot odreĎuje takozvanu zrnatost zaključavanja (granularity). U prethodnoj situaciji jedan (bilo koji) student trebao je dobiti kartu. Baza je podijeljena na više dijelova.skripta Ozbiljni DBMS ne smije dopustiti slijed dogaĎaja iz prethodnog primjera. Time se zapravo izbjegava (sasvim) istovremeni pristup istom podatku. Kad transakcija naiĎe na podatke koji su već zaključani.one će vječno čekati jedna drugu. T2 će (nakon kratkog čekanja) učitati već aţuriranu vrijednost (0 slobodnih sjedala). zamislimo da sada obje transakcije T1 i T2 zaključavaju podatak u bazi kojem misle pristupiti. 4. Pretpostavimo da postoji transakcija kojom dva putnika mogu zamijeniti sjedala (na primjer pušač i nepušač). 3. Najveća od njih je mogućnost meĎusobne blokade dviju ili više transakcija (takozvani deadlock). Uobičajena tehnika koju meĎu ostalima rabi i MySQL zasniva se na lokotima. Tada je moguć slijedeći način obavljanja elementarnih operacija.3. Očigledno ni T1 ni T2 više ne mogu nastaviti rad . a T2 obavlja istu zamjenu ali u suprotnom redoslijedu. Zamislimo sada da su istovremeno pokrenute dvije transakcije ovakve vrste. to je kontrola zaključavanja jednostavnija za DBMS. T2 traţi lokot za sjedalo 1.Baze podataka . dok je drugi trebao dobiti obavijest da više nema slobodnih mjesta. PMF – Matematički odsjek 137 . 1. Zaista. opet ćemo se posluţiti jednim zamišljenim scenarijem vezanim uz našu studentsku ekskurziju autobusom. ali mora čekati jer je T2 već zaključala dotični podatak. Znači „istovremeno“ izvršavanje T1 i T2 sada je serijalizabilno. Zrnatost suvremenih DBMS-a je obično reda veličine ntorke ili bar fizičkog bloka. a otključat će ga tek nakon što ga aţurira.2. nazovimo ih T1 i T2. T1 traţi lokot za sjedalo 2. Čim je obavila svoju operaciju. ali mora čekati jer je T1 već zaključala taj podatak. T1 zaključa podatak o sjedalu 1 jer mu misli pristupiti. pa drugi student neće dobiti kartu. Rješenje koje je danas najčešće u uporabi izgleda ovako. te mora osigurati da se ta blokada spriječi ili prekine. Što je zrno krupnije. Transakcija koja ţeli pristupiti nekom podatku najprije mora „uzeti“ odgovarajući lokot i time zaključati dotični dio baze. Dakle. Iz istih razloga T2 zaključa podatak o sjedalu 2. Lokoti i zaključavanja Lokoti su pomoćni podaci koji sluţe za koordinaciju konfliktnih radnji. DBMS u svakom trenutku mora garantirati serijalizabilnost. transakcija treba „vratiti“ lokot i time otključati podatke. Uzmimo da za svako sjedalo u autobusu baza podataka pohranjuje ime putnika (studenta) koji sjedi na tom sjedalu. Neka T1 mijenja imena putnika na sjedalima 1 i 2. Očito je potrebna neka vrsta kontrole (koordinacije) istovremenog izvršavanja transakcija. no stupanj paralelnosti rada je manji. Da bismo točnije objasnili o čemu se radi. 2. Tada će T1 prva zaključati broj slobodnih sjedala. ona mora čekati dok ih prethodna transakcija ne otključa. DBMS koji rabi lokote mora računati s upravo opisanom mogućnošću blokade transakcija. tako da jednom dijelu odgovara točno jedan lokot. 7. Slično. Razni DBMS-i to rade na razne načine.

 U slučaju InnoDB postoji i mogućnost zaključavanja ili otključavanja na razini cijele relacije. Dvofazni protokol zaključavanja Na osnovu do sada pokazanih primjera. Ako takve blokirane transakcije postoje. Ti detalji ovise o tipu datoteke koja sluţi za prikaz relacije. te otključa sjedalo 2. upisuje mu zapamćeno drugo ime (dakle Marko). Blokada je moguća. T2 zaključa sjedalo 1. na primjer InnoDB. 8.Robert Manger  Privremeno se dopušta blokada. 6.  Kod jednostavnijih tipova datoteka. Lokoti se opet uzimaju automatski. koje obje mijenjaju imena putnika na istim sjedalima 1 i 2. Opet promatramo transakciju kojom u autobusu dva putnika (studenta) mijenjaju sjedala. 2. T2 ponovo zaključa sjedalo 2. te otključa sjedalo 2. T2 zaključa sjedalo 2. još jednom ćemo se posluţiti zamišljenim „scenarijem“ vezanim uz našu studentsku ekskurziju autobusom. T2 ponovo zaključa sjedalo 1. U nastavku ovog odjeljka opisat ćemo detaljnije način uporabe lokota u MySQL-u. postoji mogućnost za nekorektno izvršavanje istovremenih transakcija čak i onda kad se podaci zaključavaju. 7. na primjer MyISAM. 5. a pogrešni utisak stekao se zato što su primjeri bili suviše jednostavni. opisani način izvršavanja transakcija T1 i T2 nije serijalizabilan. čita ime Ivan i pamti ga kao prvo ime.  Kod sloţenijih tipova datoteki. rabe se lokoti na razini n-torke. Neka na početku na tim sjedalima sjede studenti Ivan i Marko. a Ivana nema nigdje. MySQL na početku izvršavanja transakcije automatski uzima lokote za sve relacije koje sudjeluju u toj transakciji. jedna od njih se prekida. te otključa sjedalo 2. moglo bi se povjerovati da uporaba lokota (uz izbjegavanje blokade) daje garanciju za serijalizabilnost. To naţalost nije točno. bilo koji sekvencijalni redoslijed 138 PMF – Matematički odsjek . čita ime Marko i pamti ga kao svoje drugo ime. čime se izbjegava blokada. Da bismo to pokazali. rabe se lokoti na razini cijele relacije. čita ime Marko i pamti ga kao svoje prvo ime. te otključa sjedalo 1. T1 ponovo zaključa sjedalo 1. T1 ponovo zaključa sjedalo 2. Naime. neutralizira se njezin dotadašnji učinak. Vidimo da sada na oba sjedala sjedi Marko. te otključa sjedalo 1. čita ime Marko i pamti ga kao drugo ime. dakle bez eksplicitne naredbe u transakciji. no povremeno se kontrolira ima li blokiranih transakcija (traţi se ciklus u usmjerenom grafu koji prikazuje koja transakcija čeka koju). te otključa sjedalo 1. te otključa sjedalo 1. T1 zaključa sjedalo 1. upisuje mu svoje zapamćeno drugo ime (dakle Marko). te se ona se ponovo starta u nekom kasnijem trenutku. Uzmimo da su istovremeno pokrenute dvije identične transakcije. T1 zaključa sjedalo 2. T1 i T2.3. no ona se otklanja prekidanjem i neutralizacijom jedne transakcije. upisuje mu svoje zapamćeno prvo ime (dakle opet Marko). 1. upisuje mu zapamćeno prvo ime (dakle Ivan). 3. 4.3. Pritom se kod svih transakcija lokoti uzimaju u istom redoslijedu. te otključa sjedalo 2. Znači. Tada je moguć sljedeći redoslijed obavljanja elementarnih operacija. Naime. No ta mogućnost se ostvaruje jedino ako transakcija sadrţi eksplicitne naredbe LOCK TABLES … odnosno UNLOCK TABLES … 7.

tada je teško reći koja metoda je bolja. ukratko spominjemo tehniku zasnovanu na vremenskim žigovima (time stamps). u svom posebnom trenutku koji je odreĎen vremenskim ţigom. Upravo navedeni primjer uvjerio nas je da zaključavanje podataka samo po sebi nije garancija za serijalizabilnost. Svakoj transakciji pridruţuje se identifikacijski broj.4. Obje garantiraju serijalizabilnost. Čitanja i promjene istog podatka dozvoljavaju se samo ako se one odvijaju u redoslijedu vremenskih ţigova pripadnih transakcija.skripta izvršavanja proizveo bi dvostruku zamjenu. zaključavanja i otključavanja se zbivaju u dvije razdvojene faze tokom izvršavanja transakcije. dakle dvofazni protokol zaključavanja i vremenske ţigove. ukupni učinak svih transakcija je isti kao da se svaka od njih izvršavala trenutačno.  Ako u svakoj od transakcija sva zaključavanja slijede prije prvog otključavanja. Naime.3. U slučaju narušavanja tog redoslijeda. 7.Baze podataka . S druge strane. koraci 5 i 6 morat će zamijeniti redoslijed. Naime. Zaista. Kao primjer. a Marko na sjedalu 2. a T2 je već mijenjala taj isti x. Opisani način izvršavanja transakcija u skladu s vremenskim ţigovima garantira serijalizabilnost. T2 ima ţig t2 > t1. Dovoljno je od transakcija zahtijevati da se pokoravaju jednom stroţem „pravilu ponašanja“. No postoje i metode koje ne rabe lokote. U najmanju ruku. neutralizirati i ponovo startati s većim vremenskim ţigom. Za očekivati je da će metoda s vremenskim ţigovima biti efikasnija ukoliko je riječ o bazi gdje transakcije najčešće pristupaju različitim podacima i ne smetaju jedna drugoj. Obje transakcije tada će korektno obaviti svoj posao.11 s dvostrukom zamjenom sjedala. No srećom. uporaba lokota se više isplati u bazi gdje postoje zajednički podaci kojima sve transakcije moraju pristupiti. Da bi bila u skladu sa protokolom. Dvofazni protokol zaključavanja bit će bolje razumljiv ukoliko se vratimo prethodnom primjeru na Slici 7. moţe se dokazati da vrijedi sljedeća tvrdnja. U razdoblju izmeĎu čitanja i aţuriranja podatak mora ostati zaključan. no obje stvaraju dodatno opterećenje za DBMS. ako transakcija T1 ima ţig t1. Ako usporedimo dvije razmatrane metode za koordinaciju istovremenih transakcija. Vremenski žigovi Dvofazni protokol zaključavanja (uz izbjegavanje blokade) predstavlja primjer tehnike za koordinaciju paralelnog izvršavanja transakcija zasnovane na lokotima. te ga samo jednom otključati (nakon aţuriranja). tada se T1 mora neutralizirati. takozvani vremenski ţig. Lako se uvjeriti da. Razlog zašto transakcije T1 i T2 nisu korektno radile je baš taj što se one nisu pokoravale protokolu. pa ih zatim opet zaključavale. transakcija mora samo jednom zaključati podatak o sjedalu (prije čitanja). PMF – Matematički odsjek 139 . tada proizvoljno istovremeno izvršavanje tih transakcija mora biti serijalizabilno. Preciznije. jer T2 neće moći pristupiti sjedalu 2 dok ga T1 nije aţurirala i otključala. Na primjer. uz ovu promjenu „ponašanja“. Navedeno pravilo zove se dvofazni protokol zaključavanja. prije opisani redoslijed dogaĎaja više nije moguć. to jest Ivan bi opet bio na sjedalu 1. obje su otključavale podatke. stvar se lagano moţe spasiti. jedna od transakcija mora se prekinuti. T1 ţeli pročitati podatak x.

Zadatak 7.4. Zadatak 7.3 dobili ste fizičku shemu za bazu podataka iz vašeg područja interesa. te eventualne naredbe CREATE VIEW.2 dobili ste fizičku shemu baze podataka o knjiţnici. Precizno definirajte ovlaštenja za tipiĉnog korisnika iz svake skupine.1 dobili ste fizičku shemu nadopunjene baze podataka o fakultetu.2 ili 4.1. Razmislite koje sve vrste (skupine) korisnika bi mogle rabiti bazu podataka o fakultetu. Nadogradite tu shemu tako da osigurate čuvanje integriteta za neke od stranih ključeva. Rješavanjem Zadatka 6. Nadogradite tu shemu tako da osigurate čuvanje integriteta za neke od stranih ključeva. Napišite odgovarajuće naredbe GRANT i REVOKE. 140 PMF – Matematički odsjek . Sluţite se sintaksom MySQL. te eventualne naredbe CREATE VIEW.Robert Manger 7.5. Rješavanjem Zadatka 6.2. Rješavanjem Zadatka 6. Zadaci za vježbu Zadatak 7.3.3. Zadatak 7. Precizno definirajte ovlaštenja za tipičnog korisnika iz svake skupine.4. Nadogradite tu shemu tako da osigurate čuvanje integriteta za neke od stranih ključeva. Razmislite koje sve vrste (skupine) korisnika bi mogle rabiti bazu podataka iz vašeg područja interesa koju ste dobili rješavanjem Zadatka 6. Sluţite se sintaksom MySQL. Zadatak 7. Napišite odgovarajuće naredbe GRANT i REVOKE.

Informacije o jednoj operaciji su: tip operacije. pacijent. Kirurške operacije koje se obavljaju nad pacijentima. P. Specifikacija za bolnicu UtvrĎivanjem i analizom zahtjeva dobili smo sljedeću specifikaciju. i tako dalje. Nad istim pacijentom moţe se obaviti više kirurških operacija. P. prezime. a za ostale prisutne kirurge se smatra da oni asistiraju pri operaciji. Jednu operaciju obavlja samo jedan kirurg. Pacijent se obično smješta u bolničku sobu prilikom dolaska u bolnicu. Svaki konzultant ima svoju specijalnost. vrijeme i mjesto. Sestra moţe ili ne mora biti zaduţena za sobu. Jedna operacija se odvija samo u jednoj sali. odnosno baza podataka o znanstvenoj konferenciji. Ona govori o bolnici. njezinim prostorijama.1. Oblikovanje kreće od specifikacije koja je dobivena utvrĎivanjem i analizom zahtjeva. PMF – Matematički odsjek 141 . Operacijske sale u kojima se odvijaju operacije. te smo ga ilustrirali na studijskom primjeru baze podataka o fakultetu. te o odgovarajućim odnosima i pravilima. ime. odnosno fizičko oblikovanje. Svaka soba moţe primiti mnogo pacijenata. liječnicima. Sestra moţe ili ne mora biti zaduţena za salu. Kirurzi koji obavljaju operacije. Informacije o jednom kirurgu su: OIB. kirurg. osoblju i pacijentima. prezime i ime. logičko. takozvani konzultanti. Za jedno salu moţe biti zaduţeno više sestara.1.skripta Prilozi U prethodnim poglavljima opisali smo postupak oblikovanja baze podataka. Kirurge nadgledaju stariji kirurzi.1. a zatim se odvija u tri uobičajene faze: Konceptualno. no za istu sobu moţe biti zaduţeno više sestara. U ovim prilozima isti postupak provodimo kroz još dva studijska primjera. koji su smješteni u jednokrevetnim privatnim sobama. Informacije koje treba pamtiti o pacijentu uključuju osobni identifikacijski broj (OIB). Konzultanti (stariji kirurzi) bolnice smiju imati i svoje privatne pacijente. Pritom jedna sestra moţe biti zaduţena najviše za jednu sobu. adresu i tako dalje. a to su baza podataka o bolnici. Pacijenti koji zauzimaju sobe. Oblikovanje baze podataka o bolnici U ovom studijskom primjeru bavimo se pojednostavnjenom i donekle neobičnom bolnicom. datum. Medicinske sestre zadužene za sobe. Svaka sala ima svoju identifikacijsku oznaku. Medicinske sestre zadužene za sale. no ne moţe biti zaduţena za više od jedne sale. Neke sale su specijalno opremljene za neke vrste operacija. adresa.Baze podataka . broj telefona. no ista sala moţe biti poprište mnogih operacija. koji takoĎer mogu obavljati operacije ili asistirati. Sestra je jednoznačno odreĎena svojim OIB-om.

dakle skup relacija od kojih svaka ima zadano ime. Konceptualnu shemu oblikujemo crtanjem reduciranog Chenovog dijagrama entiteta i veza. te obaveznost članstva entiteta u vezama.  1:M veze ZADUŢENA ZA SOBU odnosno ZADUŢENA ZA SALU su zbog neobaveznosti članstva prikazane posebnim relacijama. dakle entitete. Dobivena relacijska shema prikazana je na Slici P. za koje OPERACIJA ima obavezno članstvo. Vidimo da je svaki tip entiteta iz konceptualne sheme prikazan jednom relacijom u logičkoj shemi. Konceptualna shema za bolnicu Početni dio oblikovanja baze podataka o bolnici je konceptualno oblikovanje. te sastavljanjem dodatnog teksta koji prati dijagram. Primijetimo da je dobivena relacijska shema već u četvrtoj normalnoj formi. To je zato što je polazna konceptualna shema bila zdravo oblikovana. Iz Slike P.2.  TakoĎer.1. Ako bi većina sestara bile zaduţene za sobe. Dobiveni dijagram prikazan je na Slici P.1 i Slike P.3. Slike P.2 .  Veza ZAUZIMA prikazana je stranim ključem ID SOBE u relaciji PACIJENT. budući da u njoj PACIJENT ima skoro obavezno članstvo. te o obaveznosti članstva njezinih entiteta.1 vidljivo je od kojih se sve tipova entiteta i veza sastoji naša shema. S druge strane. a zbog upisanih kardinalnosti zadane su i funkcionalnosti veza.  Slično. a pripadni popratni tekst nalazi se na Slici P. Te relacije sadrţe ključne atribute odgovarajućih entiteta i dodatni atribut DATUM ZADUŢIVANJA.1 odreĎuje popis atributa za pojedini tip entiteta odnosno vezu. prikaz veze zavisi o njezinoj funkcionalnosti. a rječnik podataka na Slici P. Čitanjem prethodne specifikacije otkrivamo elemente od kojih se sastoji konceptualna shema naše baze.  Veza ASISTIRA je zbog svoje funkcionalnosti M:M morala biti prikazana posebnom relacijom koja sadrţi ključne atribute od KIRURG i OPERACIJA zajedno s dodatnim atributom ULOGA. atribute i primarni ključ. Mogla je biti prikazana i ubacivanjem OIB KONZULTANTA u relaciju KIRURG.1. no tada bi u istu relaciju morali ugurati i dodatni atribut DATUM ZADUŢIVANJA. dakle popis svih atributa s objašnjenjem njihovog tipa i značenja. Sluţeći se uobičajenim pravilima.1. konceptualnu shemu sa Slike P. PODVRGAVA SE odnosno ODVIJA SE. 142 PMF – Matematički odsjek . Relacijska shema i rječnik podataka za bolnicu Nastavak oblikovanja baze podataka o bolnici je logičko oblikovanje. veze i atribute. veza LIJEĈI prikazana je stranim ključem OIB KONZULTANTA u relaciji PRIVATNI PACIJENT. TakoĎer usput sastavljamo rječnik podataka. no tada bi ubačeni atribut bio prazan za sve kirurge koje nitko ne nadgleda. tada bi moţda bilo bolje vezu ZADUŢENA ZA SOBU prikazati stranim ključem ID SOBE unutar relacije SESTRA. OIB PACIJENTA i ID SALE u relaciji OPERACIJA prikazuju veze OBAVLJA.3.2 pretvaramo u relacijsku shemu.Robert Manger P.4. P. tako da nije potrebno provoditi dodatni postupak normalizacije.  1:M veza NADGLEDA je zbog neobaveznosti članstva prikazana posebnom relacijom. strani ključevi OIB KIRURGA.

Baze podataka - skripta P.1.4. Fizička shema za bolnicu Zadnji dio oblikovanja baze podataka o bolnici predstavlja fizičko oblikovanje. Relacijsku shemu naše baze pretvaramo u fizičku shemu tako da graĎu svake relacije sa Slike P.3 opišemo odgovarajućom SQL naredbom CREATE TABLE. Pritom tipove atributa odreĎujemo u skladu s rječnikom podataka sa Slike P.4. Ukoliko se sluţimo sintaksom iz MySQL, tada dobivena fizička shema izgleda kao na Slikama P.5 i P.6. Tekst sa Slike P.5 i P.6 treba smatrati početnom verzijom fizičke sheme koju je moguće dalje dotjerivati. Ta početna verzija osigurava integritet domena za atribute u onoj mjeri koliko to dopuštaju mogućnosti zadavanja tipova u MySQL-u. TakoĎer, osigurana je jedinstvenost vrijednosti primarnog ključa unutar svake relacije. Primijetimo da shema sa Slika P.5 i P.6 za sada ne osigurava referencijalni integritet, dakle konzistentnu uporabu vrijednosti za strane ključeve. Naime, u našoj bazi postoji vrlo velik broj stranih ključeva:  ID SOBE u relaciji PACIJENT,  OIB KONZULTANTA u relaciji PRIVATNI PACIJENT,  OIB KIRURGA, ID SALE, i OIB PACIJENTA u relaciji OPERACIJA,  ID OPERACIJE, i OIB KIRURGA u relaciji ASISTIRA,  OIB NADGLEDANOG, i OIB KONZULTANTA u relaciji NADGLEDA,  ID SOBE u relaciji ZADUŢENA ZA SOBU,  ID SALE u relaciji ZADUŢENA ZA SALU. Automatska provjera svih ovih ključeva ne dolazi u obzir jer bi to previše zakompliciralo fizičku graĎu baze, te degradiralo njezine performanse. Ipak, neke vaţnije provjere mogle bi se implementirati uvoĎenjem sekundarnih indeksa i klauzulama FOREIGN KEY.

PMF – Matematički odsjek

143

Robert Manger

KONZULTANT 0,1 1,1 0,1

LIJEĈI

NADGLEDA

JE

0,M 0,M PRIVATNI PACIJENT 0,1

1,1 KIRURG 0,M

1,1

JE

OBAVLJA

ASISTIRA

1,1 PACIJENT 1,1 0,M PODVRGAVA SE

0,M

0,M OPERACIJA

0,M 0,M

ZAUZIMA

ODVIJA SE

0,1 SOBA 0,1

1,1 SALA 0,1

ZADUŢENA ZA SOBU

1,M

1,M

ZADUŢENA ZA SALU

SESTRA

Slika P.1: Dijagram s entitetima i vezama za bazu podataka o bolnici.

144

PMF – Matematički odsjek

Baze podataka - skripta

. Tip entiteta KIRURG ima atribute: OIB, PREZIME, IME, ADRESA, BROJ TELEFONA. Tip entiteta KONZULTANT je pod-tip od KIRURG, ima dodatni atribut: SPECIJALNOST (grana kirurgije u kojoj se specijalizirao). Tip entiteta PACIJENT ima atribute: OIB, PREZIME, IME, ADRESA, DATUM ROĐENJA, SPOL. Tip entiteta PRIVATNI PACIJENT JE POD-tip od PACIJENT, ima dodatni atribut: ID PRIVATNE SOBE. Tip entiteta SESTRA ima atribute: OIB, PREZIME, IME, STRUĈNI STUPANJ. Tip entiteta SOBA (misli se na ne-privatnu sobu) ima atribute: ID SOBE, TIP SOBE, BROJ KREVETA. Tip entiteta SALA ima atribute: ID SALE, TIP SALE. Tip entiteta OPERACIJA ima atribute: ID OPERACIJE, TIP OPERACIJE, DATUM, VRIJEME. Veza ASISTIRA ima atribut: ULOGA (kirurga u operaciji). Veza ZADUŢENA ZA SOBU ima atribut: DATUM ZADUŢIVANJA. Veza ZADUŢENA ZA SALU ima atribut: DATUM ZADUŢIVANJA. Ostale veze nemaju atribute.

Slika P.2: Popratni tekst uz dijagram sa Slike P.1.

PMF – Matematički odsjek

145

OIB PACIJENTA. PREZIME. BROJ KREVETA) SALA (ID SALE. OIB KIRURGA. 146 PMF – Matematički odsjek . TIP OPERACIJE. PACIJENT (OIB. DATUM ZADUŢIVANJA) ZADUŢENA ZA SALU (OIB SESTRE. ADRESA. ID SALE. OIB KIRURGA. VRIJEME) ASISTIRA (ID OPERACIJE. ID SOBE. IME. PREZIME. TIP SOBE. ID SALE. STRUĈNI STUPANJ) SOBA (ID SOBE. ID PRIVATNE SOBE) SESTRA (OIB.3: Relacijska shema za bazu podataka o bolnici. DATUM ROĐENJA. PREZIME. IME. OIB KONZULTANTA) ZADUŢENA ZA SOBU (OIB SESTRE. ULOGA) NADGLEDA (OIB NADGLEDANOG. DATUM ZADUŢIVANJA) Slika P. SPECIJALNOST). OIB KONZULTANTA. IME. ADRESA. TIP SALE) OPERACIJA (ID OPERACIJE. ID SOBE. SPOL) PRIVATNI PACIJENT (OIB.Robert Manger KIRURG (OIB. DATUM. BROJ TELEFONA) KONZULTANT (OIB.

grad. PMF – Matematički odsjek 147 .Baze podataka .4: Rječnik podataka za bazu podataka o bolnici. drţava Pozivni broj zemlje.skripta IME ATRIBUTA OIB PREZIME IME ADRESA TIP Niz od toĉno 11 znamenki Niz znakova Niz znakova Niz znakova Niz znamenki Niz znakova Kratki niz znakova Datum Vrijeme „muško“ ili „ţensko“ Kratki niz znakova Kratki niz znakova Cijeli broj Kratki niz znakova Kratki niz znakova Niz znamenki Kratki niz znakova Niz znakova OPIS Šifra koja jednoznaĉno odreĊuje osobu Prezime osobe Ime osobe Ulica. mjesec i godina kad se nešto dogodilo Sat i minuta kad se nešto dogodilo Oznaka spola osobe Oznaka struĉnog stupnja sestre Oznaka tipa bolniĉke sobe Broj koliko kreveta ima u bolniĉkoj sobi Šifra koja jednoznaĉno odreĊuje operacijsku salu Oznaka tipa operacijske sale Šifra koja jednoznaĉno odreĊuje operaciju Oznaka tipa operacije Opis uloge kirurga u operaciji BROJ TELEFONA SPECIJALNOST ID (PRIVATNE) SOBE DATUM VRIJEME SPOL STRUĈNI STUPANJ TIP SOBE BROJ KREVETA ID SALE TIP SALE ID OPERACIJE TIP OPERACIJE ULOGA Slika P. broj unutar mreţe Naziv grane u kojoj se kirurg specijalizirao Šifra koja jednoznaĉno odreĊuje bolniĉku sobu Dan. poštanski broj. grada ili mreţe. kućni broj.

CREATE TABLE PACIJENT (OIB NUMERIC(11) UNSIGNED NOT NULL. PRIMARY KEY (ID_SOBE)) ENGINE = INNODB. Slika P. CREATE TABLE SESTRA (OIB NUMERIC(11) UNSIGNED NOT NULL. DATUM_RODJENJA DATE. STRUCNI_STUPANJ ENUM('SSS'. PRIMARY KEY (OIB)) ENGINE = INNODB. OIB_KONZULTANTA NUMERIC(11) UNSIGNED NOT NULL. SPOL ENUM('M'. TIP_SOBE CHAR(20).5: Fizička shema za bazu podataka o bolnici (prvi dio). BROJ_KREVETA NUMERIC(2) UNSIGNED. ID_PRIVATNE_SOBE CHAR(5). CREATE TABLE KONZULTANT (OIB NUMERIC(11) UNSIGNED NOT NULL. PRIMARY KEY (OIB)) ENGINE = INNODB. ID_SOBE CHAR(5). PREZIME CHAR(20). ADRESA CHAR(80). CREATE TABLE PRIVATNI_PACIJENT (OIB NUMERIC(11) UNSIGNED NOT NULL.Robert Manger CREATE TABLE KIRURG (OIB NUMERIC(11) UNSIGNED NOT NULL. CREATE TABLE SOBA (ID_SOBE CHAR(5) NOT NULL. PRIMARY KEY (OIB)) ENGINE = INNODB. PREZIME CHAR(20). PREZIME CHAR(20). ADRESA CHAR(80). 'Z'). 'VSHS'. BROJ_TELEFONA NUMERIC(15) UNSIGNED. IME CHAR(20). IME CHAR(20). PRIMARY KEY (OIB)) ENGINE = INNODB. PRIMARY KEY (OIB)) ENGINE = INNODB. IME CHAR(20). 148 PMF – Matematički odsjek . SPECIJALNOST CHAR(40). 'VSS').

DATUM_ZADUZIVANJA DATE. CREATE TABLE ASISTIRA (ID_OPERACIJE NUMERIC(7) UNSIGNED NOT NULL. ID_SALE CHAR(5) NOT NULL. VRIJEME TIME. PRIMARY KEY (ID_OPERACIJE)) ENGINE = INNODB. PRIMARY KEY (ID_OPERACIJE. Slika P.Baze podataka . PMF – Matematički odsjek 149 . OIB_KIRURGA NUMERIC(11) UNSIGNED NOT NULL. PRIMARY KEY (OIB_SESTRE)) ENGINE = INNODB. ID_SOBE CHAR(5) NOT NULL. CREATE TABLE NADGLEDA (OIB_NADGLEDANOG NUMERIC(11) UNSIGNED NOT NULL. ID_SALE CHAR(5) NOT NULL. OIB_KIRURGA NUMERIC(11) UNSIGNED NOT NULL.skripta CREATE TABLE SALA (ID_SALE CHAR(5) NOT NULL. CREATE TABLE ZADUZENA_ZA_SOBU (OIB_SESTRE NUMERIC(11) UNSIGNED NOT NULL. TIP_SALE CHAR(20). CREATE TABLE ZADUZENA_ZA_SALU (OIB_SESTRE NUMERIC(11) UNSIGNED NOT NULL. PRIMARY KEY (OIB_NADGLEDANOG)) ENGINE = INNODB. OIB_KONZULTANTA NUMERIC(11) UNSIGNED NOT NULL. DATUM_ZADUZIVANJA DATE. ULOGA CHAR(40). TIP_OPERACIJE CHAR(20). PRIMARY KEY (OIB_SESTRE)) ENGINE = INNODB. DATUM DATE.6: Fizička shema za bazu podataka o bolnici (drugi dio). CREATE TABLE OPERACIJA (ID_OPERACIJE NUMERIC(7) UNSIGNED NOT NULL. OIB_PACIJENTA NUMERIC(11) UNSIGNED NOT NULL. PRIMARY KEY (ID_SALE)) ENGINE = INNODB. OIB_KIRURGA)) ENGINE = INNODB.

sudionik se treba odlučiti na kojim sve sjednicama misli prisustvovati. postupak kreće od specifikacije. Popusti su sljedeći: 20% za sudionika koji je i autor rada prihvaćenog za prezentaciju. te se nastavlja kroz faze konceptualnog. Sudionici mogu mijenjati svoje polazne prijave. Opisani su postupci vezani uz pripremu. Svaka tema ima dakle 4 sjednice. e-mail adresa. Ona govori o znanstvenoj konferenciji. Organizatori upućuju svoj poziv za sudjelovanje raznim fakultetima. odnosno fizičkog oblikovanja. Raspored tema i sjednica. Kao i prethodnim primjerima. Standardna kotizacija za jednu sjednicu je 50 EUR. pod uvjetom da se te sjednice vremenski ne preklapaju. institutima i kompanijama. Specifikacija za znanstvenu konferenciju UtvrĎivanjem i analizom zahtjeva dobili smo sljedeću specifikaciju. Recenzenti pregledavaju pristigle radove. dodavanjem novih sjednica ili 150 PMF – Matematički odsjek . Svaki recenzent je poznati stručnjak za odreĎenu temu konferencije i sam je odgovoran za recenziranje svih pristiglih radova koji su svrstani u njegovu temu. i tako dalje). O svakom sudioniku treba pamtiti nekoliko osobnih podataka (na primjer. Prezentacije se odrţavaju u dva paralelna toka (dvije dvorane istovremeno). poštanska adresa. te znanstvenim radovima koji će se izlagati na sjednicama. 40% za sudionika koji je ujedno i predsjedavajući neke od sjednica. Svaki sudionik moţe prijaviti prisustvovanje na po volji mnogo sjednica. Računanje kotizacije. Recenzente imenuje organizacijski odbor konferencije. P. ObraĎuje se 8 tema (na primjer Umjetna inteligencija. Svaka sjednica traje 2 sata i posvećena je točno jednoj temi. Softversko inţenjerstvo. Kao odgovor stiţe nekoliko stotina radova (članaka). Općenito o konferenciji. Evidencija sudionika. radno mjesto. Svaki rad se svrstava u jednu od tema konferencije. Sudjelovanje na sjednicama.Robert Manger P2. Zbog ograničenja trajanja. Oblikovanje baze podataka o znanstvenoj konferenciji U ovom studijskom primjeru ţelimo oblikovati bazu podataka koja će sluţiti kao podrška organizatorima neke znanstvene konferencije. titula. 30% za autora koji će takoĎer i prezentirati rad. CC 2011 traje 4 dana. samo 120 radova bit će zaista prihvaćeno za prezentaciju na CC 2011. Computing Conference 2011 (kratica CC 2011) omogućuje prezentaciju novih rezultata u računarskim znanostima. TakoĎer.1. Organizatori ţele da sve teme budu podjednako zastupljene. Zadnja informacija sluţi za računanje kotizacije. logičkog. zato će biti prihvaćeno najviše 15 radova po temi. a svaki dan radi se 8 sati. Baze podataka. njezinim organizatorima i sudionicima. Očekuje se da će na CC 2011 sudjelovati nekoliko tisuća ljudi. Računalna grafika.2. prezime i ime. Postupak recenziranja. organizaciju i odvijanje konferencije. … ).

temama. te otkrivamo entitete.Baze podataka .8. PMF – Matematički odsjek 151 . Iz Slike P. Dobivena relacijska shema prikazana je na Slici P. P. na osnovu konceptualne sheme sa Slika P.8 daje popis atributa za pojedini tip entiteta odnosno vezu. nije pogodno zato jer većina radova neće biti prihvaćena za prezentaciju na konferenciji.8 izravno dolazimo do početne verzije relacijske sheme i do rječnika podataka.7 i P. P.skripta odustajanjem od njih.7. sudionik šalje organizatorima jednu ili više novčanih doznaka. Relacijska shema i rječnik podataka za znanstvenu konferenciju U prvom dijelu logičkog oblikovanja. zasnovano na umetanju stranog ključa OZNAKA SJEDNICE u relaciju RAD. Baza podataka treba čuvati sve relevantne podatke o potencijalnim sudionicima. organizatori mu vraćaju preplaćeni iznos u obliku jedne doznake. Čini se da je to bolje rješenje nego da smo u relaciju TEMA stavili strani ključ E-MAIL ADRESA RECENZENTA. Ukoliko sudionik preplati kotizaciju. Novčane doznake. veze i atribute od kojih se sastoji konceptualna shema naše baze. način prikaza veze zavisi o njezinoj funkcionalnosti. Konceptualna shema za znanstvenu konferenciju U skladu s pravilima konceptualnog oblikovanja.10 i on detaljnije objašnjava tip i značenje za svaki atribut. prvo se zadaju teme.7 vidljivi su tipovi entiteta.2. Alternativno rješenje. a pripadni popratni tekst je na Slici P.9. Tu konceptualnu shemu opet dokumentiramo u obliku reduciranog Chen-ovog dijagrama s popratnim tekstom. radovima. Posredno se vide i funkcionalnosti veza. pa su zato prikazane posebnim relacijama AUTORSTVO odnosno PRISUSTVO.2. S druge strane. Rječnik podataka vidljiv je na Slici P. s time da odgovarajući tip entiteta ima obavezno članstvo.  Veza POSLAO već je implicitno prikazana time što se u relaciji DOZNAKA pojavljuje E-MAIL ADRESA SUDIONIKA (pošiljatelja doznake). te kardinalnosti veza. te obaveznost članstva entiteta u vezama.2 . čitamo prethodnu specifikaciju. a onda se za svaku od njih traţi recenzent. veze.  Veza ODGOVORAN ZA prikazana je pomoću stranog ključa OZNAKA TEME u relaciji RECENZENT. recenzentima i doznakama. Slike P.  Ostale veze imaju funkcionalnost 1:M.3. Uočavamo da je svaki tip entiteta iz konceptualne sheme prikazan jednom relacijom u dobivenoj logičkoj shemi. a sastoji se od skupa relacija gdje svaka od njih ima zadano ime. atribute i primarni ključ.  Veza PRIHVAĆEN ZA prikazana je posebnom relacijom PRIHVAĆANJE. te o obaveznosti članstva njezinih entiteta. No sudionikove prijave dva tjedna prije početka CC 2011 smatraju se konačnima. sjednicama. Zato se te veze prikazuju ubacivanjem stranog ključa u pripadnu relaciju. Naime.  Veze JE AUTOR i PRISUTAN NA su veze s funkcionalnošću M:M. Da bi namirio svoju kotizaciju. Dijagram je prikazan je na Slici P.

12 i P. naime sve njezine relacije su u 4NF. Kao i u prošlim primjerima.10. Naime. čak ni u 3NF.9. pa tu relaciju moramo normalizirati. OZNAKA DVORANE) čine kandidate za ključ.13. ista ustanova moţe biti rasporeĎena na više adresa. TakoĎer. trebalo je uočiti da postoji M:1 veza izmeĎu SUDIONIKA i TARIFE koja odreĎuje po kojoj tarifi dotični sudionik plaća kotizaciju. DOZNAKA.11. Zaključujemo sljedeće. Nova verzija relacijske sheme koja nastaje normalizacijom prikazana je na Slici P. čime nastaje nova relacija koju moţemo zvati TARIFA.  U relaciji SUDIONIK ipak postoji jedna druga tranzitivna ovisnost: E-MAIL ADRESA → STATUS → IZNOS KOTIZACIJE. Postupak normalizacije svodi se na razbijanje relacije SUDIONIK na dvije.  U relaciji SJEDNICA kombinacije atributa (DATUM. postupak oblikovanja relacijske sheme odmah bi nam dao shemu u 4NF i nikakav daljnji postupak normalizacije ne bi bio potreban. Zbog toga SUDIONIK nije u 3NF. No mi smo ipak uveli OZNAKU SJEDNICE kao spretniju kraticu. VRIJEME OD.11 je u dovoljnoj mjeri normalizirana. Nas ovdje zanima adresa na kojoj je dotična osoba. pa je relacija RECENZENT u 4NF. Pritom tipove atributa nastojimo što bolje uskladiti s rječnikom podataka sa Slike P.9 provjeravamo je li ona u dovoljno visokoj normalnoj formi. Shema sa Slike P. Zato relaciju SJEDNICA ostavljamo u sadašnjem obliku. Dobivena fizička shema prikazana je na Slikama P. Naime. Primijetimo da je odstupanje od 4NF u shemi sa Slike P. VRIJEME DO. VRIJEME DO. a ne matična adresa cijele ustanove.  Smatramo da NAZIV USTANOVE u relaciji SUDIONIK odnosno RECENZENT ne odreĎuje POŠTANSKU ADRESU. U odnosu na prethodnu verziju sa Slike P.  pojavila se nova relacija TARIFA. tekst sa Slika P. Zbog toga ovdje nije riječ o tranzitivnoj ovisnosti. te treba li je prevesti u višu normalnu formu.12 i P.  Primijetimo da u relaciji SJEDNICA postoji funkcionalna ovisnost VRIJEME OD → VRIJEME DO ili VRIJEME DO → VRIJEME OD. Da smo to sve uvaţili otpočetka.4. TEMA. VRIJEME OD. Zato. SJEDNICA nije u BCNF. Ne moţe doći do anomalija koje su inače prisutne kod relacija koje nisu u 3NF. strogo govoreći.9 nastupilo zbog propusta u oblikovanju entiteta i veza. Za svaku relaciju iz sheme sa Slike P. normaliziranu relacijsku shemu naše baze za znanstvenu konferenciju pretvaramo u fizičku shemu. atribute DATUM. P. No razbijanje te relacije na manje ne bi imalo smisla. Naime. ta početna verzija uglavnom osigurava integritet 152 PMF – Matematički odsjek . u novoj verziji postoje samo dvije razlike:  relacija SUDIONIK ima jednostavniju graĎu. AUTORSTVO. Koristili smo se sintaksom MySQL-a. To radimo tako da graĎu svake relacije sa Slike P.  Relacije RAD. PRIHVAĆANJE i PRISUSTVO su očito u 4NF pa ih ne treba mijenjati. OZNAKA DVORANE upisujemo (zbog udobnosti) uvijek zajedno s OZNAKOM SJEDNICE. Naime.11 opišemo odgovarajućom SQL naredbom CREATE TABLE. trebalo je uočiti da postoji tip entiteta TARIFA koji govori da bilo koji sudionik s odreĎenim statusom plaća istu kotizaciju.13 tek je početna verzija fizičke sheme koju je moguće dalje dotjerivati.2. OZNAKA DVORANE) odnosno (DATUM.Robert Manger U nastavku logičkog oblikovanja bavimo se normalizacijom. Fizička shema za znanstvenu konferenciju U sklopu fizičkog oblikovanja.

no ne osigurava referencijalni integritet za strane ključeve.skripta domena za atribute i jedinstvenost vrijednosti primarnih ključeva.  BROJ RADA i E-MAIL ADRESA AUTORA u relaciji AUTORSTVO. Automatska provjera referencijalnog integriteta za neke od tih ključeva mogla bi se po potrebi implementirati uvoĎenjem sekundarnih indeksa i klauzulama FOREIGN KEY. To bi zahtijevalo nadopunu nekih od naredbi CREATE TABLE sa slika P.  OZNAKA TEME i E-MAIL ADRESA PREDSJEDAVAJUĆEG u relaciji SJEDNICA.13.Baze podataka .12 odnosno P. Primijetimo da u našoj bazi za znanstvenu konferenciju postoji velik broj stranih ključeva:  STATUS u relaciji SUDIONIK.  E-MAIL ADRESA SUDIONIKA u relaciji DOZNAKA.  OZNAKA TEME u relaciji RECENZENT.  BROJ RADA i OZNAKA SJEDNICE u relaciji PRIHVAĆANJE.  E-MAIL ADRESA SUDIONIKA i OZNAKA SJEDNICE u relaciji PRISUSTVO. PMF – Matematički odsjek 153 .

1 RECENZENT Slika P.1 TEMA 0.Robert Manger DOZNAKA 0.1 RAD SUDIONIK 1.7: Dijagram entiteta i veza za bazu podataka o znanstvenoj konferenciji.M 0.M JE AUTOR POSLAO 0.M 1.M SJEDNICA 1.M 1.M 1.M SVRSTAN U PRIHVAĆEN ZA PRISUTAN NA PREDSJEDAVA 1.1 0.1 0.1 0. 154 PMF – Matematički odsjek .M ODGOVORAN ZA POSVEĆENA 1.1 1.M 1.

PLAĆENI IZNOS (jedan sudionik u jednom danu moţe imati samo jednu doznaku). Slika P. POŠTANSKA ADRESA. NAZIV TEME. VRIJEME OD. NASLOV RADA. pon2. IME. NAZIV USTANOVE. Tip entiteta RECENZENT ima atribute: E-MAIL ADRESA. POŠTANSKA ADRESA.skripta Tip entiteta RAD ima atribute: BROJ RADA. … ĉet8). Tip entiteta SJEDNICA ima atribute: OZNAKA SJEDNICE (pon1. Tip entiteta TEMA ima atribute: OZNAKA TEME. Ni jedna veza nema atribute veze. OPIS TEME. TITULA. DATUM. NAZIV USTANOVE. TITULA. autor. OZNAKA DVORANE (gdje se odrţava). PREZIME. Tip entiteta SUDIONIK ima atribute: E-MAIL ADRESA. predsjednik).8: Popratni tekst uz dijagram sa Slike P. izlagaĉ. PMF – Matematički odsjek 155 . IME. VRIJEME DO. STATUS (obiĉni. BROJ STRANICA. DATUM. IZNOS KOTIZACIJE (po sjednici). PREZIME.7.Baze podataka . Tip entiteta DOZNAKA ima atribute: E-MAIL ADRESA SUDIONIKA.

NAZIV USTANOVE. DATUM.9: Početna verzija relacijske sheme za bazu podataka o znanstvenoj konferenciji. OPIS TEME) DOZNAKA (E-MAIL ADRESA SUDIONIKA. OZNAKA TEME) TEMA (OZNAKA TEME. DATUM. IME. 156 PMF – Matematički odsjek . OZNAKA TEME. TITULA. PREZIME. VRIJEME OD. TITULA. PREZIME. POŠTANSKA ADRESA. NAZIV USTANOVE. PLAĆENI IZNOS) SJEDNICA (OZNAKA SJEDNICE. VRIJEME DO. OZNAKA SJEDNICE) PRISUSTVO (E-MAIL ADRESA SUDIONIKA. OZNAKA DVORANE.Robert Manger RAD (BROJ RADA. E-MAIL ADRESA AUTORA) PRIHVAĆANJE (BROJ RADA. OZNAKA SJEDNICE) Slika P. RECENZENT (E-MAIL ADRESA. IME. E-MAIL ADRESA PREDSJEDAVAJUĆEG) AUTORSTVO (BROJ RADA. POŠTANSKA ADRESA. NAZIV TEME. NASLOV RADA. IZNOS KOTIZACIJE). STATUS. BROJ STRANICA) SUDIONIK (E-MAIL ADRESA.

poštanski broj. „autor“. kućni broj.dr. „izlagaĉ“ ili „predsjedavajući“ Mali cijeli broj Kratki niz znakova Niz znakova Niz znakova Datum Mali cijeli broj „pon1“.skripta IME ATRIBUTA BROJ RADA NASLOV RADA BROJ STRANICA E-MAIL ADRESA TITULA PREZIME IME NAZIV USTANOVE POŠTANSKA ADRESA STATUS TIP Cijeli broj Niz znakova Mali cijeli broj Niz znakova „Prof.Baze podataka . … „ĉet8“ Vrijeme Kratki niz znakova OPIS Šifra koja jednoznaĉno odreĊuje rad Naslov koji piše na radu Broj koliko rad ima stranica Rabi se kao šifra koja jednoznaĉno odreĊuje osobu Jedna od uobiĉajenih kratica za akademski ili struĉni naziv Prezime osobe Ime osobe Jednoznaĉno odreĊuje ustanovu gdje radi osoba Adresa osobe u ustanovi gdje radi: ulica. „pon2“. grad. PMF – Matematički odsjek 157 . „Doc.10: Rječnik podataka za bazu podataka o znanstvenoj konferenciji.dr.sc“. drţava Status sudionika koji odreĊuje kolika će mu biti kotizacija Iznos kotizacije u eurima koji sudionik mora platiti za svaku sjednicu gdje je prisutan Kratka šifra koja jednoznaĉno odreĊuje temu Puni naziv teme Opširnije obrazloţenje što spada a što ne spada u odreĊenu temu Dan. mjesec i godina kad se nešto dogaĊa Novĉani iznos u eurima koji je uplaćen preko doznake Šifra koja jednoznaĉno odreĊuje dan i termin odrţavanja sjednice Sat i minuta poĉetka odnosno kraja sjednice Šifra koja jednoznaĉno odreĊuje dvoranu IZNOS KOTIZACIJE OZNAKA TEME NAZIV TEME OPIS TEME DATUM PLAĆENI IZNOS OZNAKA SJEDNICE VRIJEME (OD ili DO) OZNAKA DVORANE Slika P.sc“ i sl Niz znakova Niz znakova Niz znakova Niz znakova „obiĉni“.

NAZIV USTANOVE. IME. 158 PMF – Matematički odsjek . OZNAKA SJEDNICE) Slika P. TARIFA (STATUS. DATUM. IZNOS KOTIZACIJE) RECENZENT (E-MAIL ADRESA.Robert Manger RAD (BROJ RADA. STATUS). OPIS TEME) DOZNAKA (E-MAIL ADRESA SUDIONIKA. OZNAKA DVORANE. NASLOV RADA. PREZIME. OZNAKA SJEDNICE) PRISUSTVO (E-MAIL ADRESA SUDIONIKA. E-MAIL ADRESA AUTORA) PRIHVAĆANJE (BROJ RADA. OZNAKA TEME. NAZIV USTANOVE. E-MAIL ADRESA PREDSJEDAVAJUĆEG) AUTORSTVO (BROJ RADA. POŠTANSKA ADRESA. PLAĆENI IZNOS) SJEDNICA (OZNAKA SJEDNICE. VRIJEME DO. OZNAKA TEME) TEMA (OZNAKA TEME. POŠTANSKA ADRESA. DATUM. BROJ STRANICA) SUDIONIK (E-MAIL ADRESA. VRIJEME OD. IME. PREZIME. NAZIV TEME. TITULA. TITULA.11: Normalizirana verzija relacijske sheme za bazu podataka o znanstvenoj konferenciji.

dr.sc'. CREATE TABLE TEMA (OZNAKA_TEME CHAR(3) NOT NULL. 'Doc.dr. NAZIV_USTANOVE CHAR(40).dr. NASLOV_RADA CHAR(160). IME CHAR(20). 'I'. OPIS_TEME CHAR(160). CREATE TABLE SUDIONIK (E_MAIL_ADRESA CHAR(40) NOT NULL. 'A'. PRIMARY KEY (E_MAIL_ADRESA)) ENGINE = INNODB. Slika P. 'P') NOT NULL. CREATE TABLE TARIFA (STATUS ENUM('O'.sc'). NAZIV_USTANOVE CHAR(40). IME CHAR(20). PRIMARY KEY (OZNAKA_TEME)) ENGINE = INNODB. STATUS ENUM('O'.sc'. PRIMARY KEY (STATUS)) ENGINE = INNODB.dr.Baze podataka .'Mr.sc'.'Mr. POSTANSKA_ADRESA CHAR(80). PRIMARY KEY (BROJ_RADA)) ENGINE = INNODB.skripta CREATE TABLE RAD (BROJ_RADA NUMERIC(4) UNSIGNED NOT NULL. IZNOS_KOTIZACIJE NUMERIC(3) UNSIGNED. TITULA ENUM('Prof.sc'. CREATE TABLE RECENZENT (E_MAIL_ADRESA CHAR(40) NOT NULL. BROJ_STRANICA NUMERIC(2) UNSIGNED. TITULA ENUM('Prof.sc'). POSTANSKA_ADRESA CHAR(80).12: Fizička shema za bazu o znanstvenoj konferenciji (prvi dio). PREZIME CHAR(20).sc'. 'I'. PMF – Matematički odsjek 159 . PREZIME CHAR(20). 'A'. 'Dr.sc'. 'Dr. NAZIV_TEME CHAR(40). 'P'). PRIMARY KEY (E_MAIL_ADRESA)) ENGINE = INNODB. 'Doc. OZNAKA_TEME CHAR(3) NOT NULL.

'pon5'. 'cet8') NOT NULL. 'uto8'. 160 PMF – Matematički odsjek . 'sri4'. 'sri7'. 'cet4'. 'uto3'. 'cet1'. 'uto6'. 'sri3'. 'pon5'. 'pon8'. 'uto3'. PRIMARY KEY (BROJ_RADA. 'pon6'. 'cet2'. 'uto8'. DATUM DATE. 'uto1'. 'uto6'. 'uto5'. 'cet3'. 'uto7'. 'pon3'. OZNAKA_DVORANE CHAR(4). CREATE TABLE PRISUSTVO (E_MAIL_ADRESA_SUDIONIKA CHAR(40) NOT NULL. 'pon5'. 'cet3'. 'cet6'. E_MAIL_ADRESA_PREDSJEDAVAJUCEG CHAR(40) NOT NULL. 'uto7'. 'pon3'. 'pon8'. CREATE TABLE AUTORSTVO (BROJ_RADA NUMERIC(4) UNSIGNED NOT NULL. 'uto3'. 'sri2'. 'sri4'. 'sri2'. 'uto4'.13: Fizička shema za bazu o znanstvenoj konferenciji (drugi dio). 'cet1'. OZNAKA_TEME CHAR(3) NOT NULL. 'uto5'. PRIMARY KEY (OZNAKA_SJEDNICE)) ENGINE = INNODB. 'cet5'. OZNAKA_SJEDNICE ENUM ('pon1'. 'sri6'.'uto2'. 'sri1'. DATUM)) ENGINE = INNODB. 'sri8'. 'sri8'. 'cet5'. 'cet3'. 'pon6'. 'uto1'. 'sri5'. OZNAKA_SJEDNICE ENUM ('pon1'. 'pon2'. 'uto8'. 'uto7'. 'cet5'. 'sri5'. 'pon7'. 'sri6'. CREATE TABLE PRIHVACANJE (BROJ_RADA NUMERIC(4) UNSIGNED NOT NULL. 'pon7'. 'cet2'. 'cet8') NOT NULL. 'pon8'. 'cet6'. 'uto6'. 'cet6'.'uto2'. 'sri5'. CREATE TABLE SJEDNICA (OZNAKA_SJEDNICE ENUM ('pon1'. 'pon4'. PLACENI_IZNOS NUMERIC(4) UNSIGNED. 'pon7'.Robert Manger CREATE TABLE DOZNAKA (E_MAIL_ADRESA_SUDIONIKA CHAR(40) NOT NULL. 'uto4'. 'pon6'. 'sri8'. 'pon2'. 'sri1'. 'sri7'. DATUM DATE NOT NULL. 'cet4'. 'cet1'. VRIJEME_DO TIME. 'sri3'. 'sri7'. 'uto5'. 'cet2'. 'pon3'. 'sri1'. 'pon4'. VRIJEME_OD TIME. 'sri4'. OZNAKA_SJEDNICE)) ENGINE = INNODB. 'sri6'. 'pon2'. E_MAIL_ADRESA_AUTORA)) ENGINE = INNODB. E_MAIL_ADRESA_AUTORA CHAR(40) NOT NULL. 'cet7'. 'sri2'. Slika P. 'cet8') NOT NULL. 'sri3'. 'cet7'. 'cet7'. 'cet4'. 'uto1'. PRIMARY KEY (E_MAIL_ADRESA_SUDIONIKA. PRIMARY KEY (BROJ_RADA)) ENGINE = INNODB. 'uto4'. 'pon4'.'uto2'. PRIMARY KEY (E_MAIL_ADRESA_SUDIONIKA.

2010.Hill. Sebastopol CA. Korth.  R.  On-line dokumentacija : http://www. 4th Edition. Apress. 2009. Priručnici za jezik SQL:  A. Sebastopol CA.Baze podataka . logičko i fizičko modeliranje podataka. DRIP. 2003. AddisonWesley. Upper Saddle River NJ. J. D. Sudarshan: Database System Concepts. O’Reilly Media Inc. McGraw. 2002. Ramakrishnan. Churcher: Beginning Database Design . Varga: Baze podataka – konceptualno. O’Reilly Media Inc. Hernandez: Database Design for Mere Mortals .J.  M. McGraw-Hill. 2005.  R. 2006. DuBois: MySQL. 2003. Addison-Wesley.  M. 2008. H.  R. Axmark: MySQL Reference Manual. Date: An Introduction to Database Systems. Elmasri. Silberschatz.mysql.  R. 4th Edition.  M. 1994. 2002. Beaulieu: Learning SQL.J. Upper Saddle River NJ. Wrox. Hoboken NJ. Navathe: Fundamentals of Database Systems.A Hands-On Guide to Relational Database Design. 2008. 6th Edition.F.F. Widenius. New York. Addison-Wesley. Udţbenici o oblikovanju baza podataka:  C. 3rd Edition. Dokumentacija za MySQL:  P. 2nd Edition. Berkley CA. Sebastopol CA. 2007.  A. Addison-Wesley. Zagreb. S. S. 8th Edition. O’Reilly & Associates.skripta Literatura Općeniti udţbenici o bazama podataka:  C. Molinaro: SQL Cookbook. Reading MA. Gehrke: Database Management Systems.com/documentation/ PMF – Matematički odsjek 161 . Reading MA.From Novice to Professional. New York. Van der Lans: Introduction to SQL.  A. 2010. Addison-Wesley. Stephens: Beginning Database Design Solutions. Reading MA. 6th Edition.

Sign up to vote on this title
UsefulNot useful