of 191 /191
FESB | 1. Uvod 1 Baze podataka Radni materijali Predavanja

Radni materijali Predavanja - racunarstvo550.xyz. semestar/Baze podatak… · Metodologija projektiranja baza podataka ..... 15 1.3. Modeli baza podataka

  • Author
    doannhu

  • View
    237

  • Download
    9

Embed Size (px)

Text of Radni materijali Predavanja - racunarstvo550.xyz. semestar/Baze podatak… · Metodologija...

  • FESB | 1. Uvod 1

    Baze podataka

    Radni materijali Predavanja

  • FESB | 1. Uvod 2

    Sadraj 1. Uvod .................................................................................................................................................... 7

    1.1. Baza podataka i sustav za upravljanje bazama podataka ....................................................... 9

    1.1.1. Kako se ostvaruje fizika i logika nezavisnost podataka? ............................................ 12

    1.2. Metodologija projektiranja baza podataka ........................................................................... 15

    1.3. Modeli baza podataka ........................................................................................................... 18

    1.4. Tipovi i strukture baza podataka ........................................................................................... 22

    1.5. ivotni ciklus baze podataka ................................................................................................. 23

    2. Modeliranje podataka ................................................................................................................... 26

    2.1. Koraci u projektiranju baze podataka ................................................................................... 26

    2.1.1. Analiza i snimanje zahtjeva. .......................................................................................... 27

    2.1.2. Poetni (konceptualni) model baze podataka. .............................................................. 27

    2.1.3. Prevoenje konceptualnog modela u poetni logiki dizajn baze podataka. ............... 27

    2.1.4. Dorada logike sheme baze podataka. .......................................................................... 27

    2.1.5. Fiziki dizajn baze podataka. ......................................................................................... 27

    2.1.6. Uvoenje sigurnosnih zahtjeva i ogranienja. ............................................................... 27

    2.2. Entiteti i atributi .................................................................................................................... 29

    2.3. Veze i skupovi veza ................................................................................................................ 30

    2.4. Funkcionalnost veza .............................................................................................................. 31

    2.5. lanstvo entiteta u vezama ................................................................................................... 33

    2.6. Kardinalnost........................................................................................................................... 34

    2.7. Prikaz ER-modela pomodu dijagrama .................................................................................... 35

    2.8. Sloeni oblici u ER-modelima ................................................................................................ 37

    2.8.1. Slabi entiteti .................................................................................................................. 37

    2.8.2. Sloene veze u ER-modelima ......................................................................................... 38

    2.9. Konceptualni dizajn baze podataka primjenom ER-modela ................................................. 43

    2.10. Kako najjednostavnije do modela podataka? ................................................................... 44

    2.11. Zakljuak ............................................................................................................................ 45

    3. Relacijski model ............................................................................................................................. 46

    3.1. Struktura relacijskog modela ................................................................................................. 46

    3.1.1. Kartezijev produkt ............................................................................................................. 46

    3.1.2. Relacija............................................................................................................................... 46

  • FESB | 1. Uvod 3

    3.1.3. Atribut relacije ................................................................................................................... 47

    3.2. Kljuevi .................................................................................................................................. 48

    3.3. Shema baze podataka i baza podataka ................................................................................. 49

    3.4. Nula (null) vrijednosti ............................................................................................................ 51

    3.5. Ekvivalentnost naziva ............................................................................................................ 51

    3.6. Ogranienja u relacijskom modelu ........................................................................................ 52

    3.6.1. Pravilo integriteta entiteta ................................................................................................ 52

    3.6.2. Pravilo referencijalnog integriteta..................................................................................... 52

    3.7. Pretvaranje ER-modela u relacijski model ............................................................................. 54

    3.7.1. Pretvorba tipova entiteta .................................................................................................. 55

    3.7.2. Pretvorba binarnih veza .................................................................................................... 55

    3.7.3. Pretvorba involviranih veza ............................................................................................... 57

    3.7.4. Pretvorba pod-tipova ........................................................................................................ 58

    3.7.5. Pretvorba ternarnih veza ................................................................................................... 58

    3.7.6. Dekompozicija atributa ..................................................................................................... 59

    3.8. Usporedba relacijskog modela s mrenim i hijerarhijskim modelima .................................. 61

    4. Postupak normalizacije i normalizacijski model ............................................................................ 63

    4.1. Prva normalna forma (1NF) ................................................................................................... 65

    4.2. Funkcionalne zavisnosti - osnovne definicije i terminologija ................................................ 66

    4.3. Druga normalna forma (2NF) ................................................................................................ 68

    4.4. Treda normalna forma (3NF) ................................................................................................. 69

    4.5. Boyce-Codd-ova normalna forma (BCNF) ............................................................................. 71

    4.6. Vieznane zavisnosti i etvrta normalna forma (4NF) ......................................................... 73

    4.7. Zavisnosti spajanja i Peta normalna forma (5NF) .................................................................. 75

    4.8. Normalna forma kljueva i domena ...................................................................................... 77

    4.9. Razlozi zbog kojih se moe odustati od normalizacije .......................................................... 77

    4.10. Zakljuak ............................................................................................................................ 78

    5. Operacije relacijskog modela ........................................................................................................ 79

    5.1. Relacijska algebra .................................................................................................................. 81

    5.1.1. Operacije teorije skupova (Set-theory operations) ....................................................... 81

    5.1.2. Prirodne relacijske operacije (Native-relation operations) ........................................... 86

    5.1.3. Prioritet operatora relacijske algebre ........................................................................... 90

    5.1.4. Operacije sa nula vrijednostima .................................................................................... 90

    5.1.5. Primjeri relacijske algebre ............................................................................................. 94

  • FESB | 1. Uvod 4

    5.2. Relacijski raun .................................................................................................................... 100

    5.2.1. Relacijski raun n-torki ................................................................................................ 100

    5.2.2. Relacijski raun domena .............................................................................................. 101

    6. SQL (Structured Query Language) ............................................................................................... 103

    6.1. Obrada SQL naredbe ........................................................................................................... 104

    6.2. Definiranje baze podataka primjenom SQL (DATA DEFINITION LANGUAGE) ..................... 105

    6.2.1. Kreiranje tablica ........................................................................................................... 105

    6.2.1.1. Tipovi podataka ....................................................................................................... 106

    6.2.1.2. Ogranienja.............................................................................................................. 108

    6.2.1.3. Svojstvo IDENTITY[(seed, increment)] ..................................................................... 109

    6.2.1.4. Zabranjivanje NULL vrijednosti ................................................................................ 109

    6.2.1.5. Predodreene vrijednosti ........................................................................................ 110

    6.2.1.6. Oznaavanje primarnog kljua tablice..................................................................... 110

    6.2.1.7. Oznaavanje stranog kljua u tablici ....................................................................... 111

    6.2.1.8. Zabrana ponavljanja istih vrijednosti ...................................................................... 112

    6.2.1.9. Dodatna provjera upisanih vrijednosti .................................................................... 113

    6.2.1.10. Primjer kreiranja tablice .......................................................................................... 113

    6.2.2. Kreiranje privremenih tablica ...................................................................................... 115

    6.2.3. Kreiranje nove tablice na temelju postojede tablice ................................................... 115

    6.2.4. Izmjena postojede tablice ............................................................................................ 116

    6.2.4.1. Brisanje stupca ili ogranienja (constraints) iz tablice............................................. 116

    6.2.4.2. Promjene svojstava postojedih stupaca u tablici..................................................... 117

    6.2.4.3. Dodavanje novih stupaca ........................................................................................ 117

    6.2.4.4. Dodavanje novih ogranienja .................................................................................. 118

    6.2.5. Brisanje tablice ............................................................................................................ 119

    6.3. Indeksi ................................................................................................................................. 120

    6.3.1. Viestruki indeksi ......................................................................................................... 120

    6.3.2. CLUSTERED indeksi ...................................................................................................... 120

    6.3.3. Jedinstveni indeksi (UNIQUE INDEX) ........................................................................... 121

    6.3.4. Kreiranje i brisanje indeksa ......................................................................................... 121

    6.3.5. Indeksi : nedostatci ...................................................................................................... 121

    6.3.6. Indeksi zakljuak ....................................................................................................... 122

    6.4. Unos podataka u tablice ...................................................................................................... 123

    7. Upiti u bazu podataka ................................................................................................................. 125

  • FESB | 1. Uvod 5

    7.1. Jednostavni upiti nad jednom relacijom ............................................................................. 127

    7.1.1. Uvjetni izraz (search condition) ................................................................................... 128

    7.1.1.1. Predikati usporedbe (Comparision predicates) ....................................................... 128

    7.1.1.2. Predikati podruja (range predicates) ..................................................................... 129

    7.1.1.3. Predikati liste (list predicates) ................................................................................. 130

    7.1.1.4. Predikati uzorka (pattern predicates) ..................................................................... 132

    7.1.1.5. Predikati nepoznate vrijednosti .............................................................................. 135

    7.1.1.6. Logiki operatori - AND, OR, NOT ............................................................................ 136

    7.2. Oblikovanje izlaznih rezultata ............................................................................................. 140

    7.2.1. Preimenovanje stupaca u rezultatu ............................................................................ 140

    7.2.2. Zamjena podataka u rezultatu upita ........................................................................... 141

    7.2.3. Povezivanje podataka u rezultatu upita ...................................................................... 142

    7.2.4. Sortiranje izlaznih rezultata ......................................................................................... 143

    7.2.5. Izraunate kolone (Computed values) ......................................................................... 144

    7.2.6. Ograniavanje ispisa rezultata ..................................................................................... 145

    7.3. Upiti nad vie relacija .......................................................................................................... 147

    7.4. Upit kojim se kreira nova tablica (MAKE TABLE QUERY) - SELECT INTO ............................. 150

    7.5. Upiti sa naredbama za dodavanje, izmjenu i brisanje podataka ......................................... 152

    7.5.1. Append upiti (proirivanje tablice podacima iz drugih tablica) ................................... 152

    7.5.2. Izmjena (auriranje) podataka u tablici ....................................................................... 153

    7.5.3. Brisanje podataka iz tablice ......................................................................................... 154

    7.6. Alias-i ................................................................................................................................... 156

    7.7. Agregatne funkcije............................................................................................................... 158

    7.8. Grupni upiti (GROUP BY Query) .......................................................................................... 162

    7.8.1. Grupiranje podataka (GROUP BY) ............................................................................... 162

    7.8.2. HAVING uvjetni izraz ................................................................................................... 164

    7.9. Ugnijeeni upiti podupiti ................................................................................................ 170

    7.9.1. Podupiti liste ................................................................................................................ 170

    7.9.2. Podupiti sa predikatom usporedbe ............................................................................. 173

    7.9.3. Podupiti sa predikatom usporedbe ............................................................................. 178

    7.9.4. Korelirani pod-upiti (Cross-corellated queries) ........................................................... 182

    7.9.5. Podupiti sa predikatom postojanja (EXISTS, NOT EXISTS) ........................................... 184

    7.10. Unija................................................................................................................................. 186

    7.11. Optimizacija SQL upita ..................................................................................................... 189

  • FESB | 1. Uvod 6

  • FESB | 1. Uvod 7

    1. Uvod Problem klasine obrade podataka (File model)

    Nedostatke klasine (datotene) obrade podataka najbolje emo uoiti na jednom primjeru.

    Pogledajmo izdvojeni skup "aplikacija" u informacijskom sustavu neke proizvodno-trgovake radne organizacije koja koristi klasinu datotenu obradu podataka (eng. file model).

    Informacijskim sustavom zajedniki nazivamo sve programe, podatke i informacije koji se obrauju na raunalu.

    Svaka aplikacija je razvijana posebno, koristi svoje "privatne" datoteke sa fizikom strukturom podataka pogodnom upravo za tu aplikaciju.

    Slika 1.1. Klasina obrada podataka. Nezavisne, "privatne" datoteke za svaku aplikaciju

    Osnovni nedostaci prikazane obrade podataka su:

    1. Neminovna redundancija podataka, odnosno viestruko pamenje istih podataka.

    Npr., isti podaci o proizvodima se, u nekoj proizvodnoj radnoj organizaciji pamte i nekoliko desetaka puta, ili isti podaci o graanima u nekom komunalnom informacijskom sustavu i nekoliko stotina puta. Viestruko skladitenje istih podataka dovodi do nepremostivih problema pri njihovom auriranju (odravanju). Kada se neki podatak promijeni, to se mora uiniti na svim mjestima na kojima se on uva. To, ne samo da znaajno poveava trokove obrade podataka, nego je organizacijski praktino neizvodljivo, pa se, u raznim izvjetajima, pojavljuju razliite verzije istog podatka.

    2. Zavisnost programa od organizacije podataka.

    Programi su zavisni i od logike i od fizike strukture podataka. Fizika struktura podataka definira nain spremanja podataka na medijima vanjske memorije. Logika

  • FESB | 1. Uvod 8

    struktura je struktura podataka koju koristi programer. U klasinim datotekama razlika fizike i logike strukture podataka je mala.

    Zavisnost programa od logike strukture se oituje u tome to program zavisi, npr., od naziva i redoslijeda polja u zapisu, to ubacivanje novog polja u zapis ili bilo kakvo drugo restrukturiranje zapisa, koje ne mijenja sadraj podataka koje program koristi, ipak zahtijeva i izmjenu samog programa.

    Fizika zavisnost se oituje u tome to program zavisi od izabrane fizike organizacije datoteke i izabrane metode pristupa, naina sortiranja i slino.

    U osnovi i logika i fizika organizacija podataka su prilagoene konkretnom programu. Novi zahtjevi za informacijama, iz podataka koji ve postoje u datotekama, mogli bi zahtijevati izmjenu fizike i logike strukture podataka, a to bi zahtijevalo izmjene u ranije razvijenim programima. Umjesto toga, obino se za novi program stvara nova datoteka, a to dalje poveava redundanciju podataka.

    3. Niska produktivnost u razvoju informacijskog sustava (IS)

    Strukturiranje podataka u nezavisan skup datoteka je jedan od uzroka veoma niske

    produktivnosti u razvoju informacijskog sustava. Npr., ak i kada postoje svi podaci koji se zahtijevaju u nekoj aplikaciji, ali se oni nalaze u razliitim datotekama, na raznim medijima, sa razliitim fizikim organizacijama, pa zadovoljenje i nekog jednostavnog zahtjeva iziskuje znaajne napore programera. Nad strukturom podataka predstavljenom velikim brojem nezavisnih datoteka veoma je teko razviti softverske alate za brz i uinkovit razvoj aplikacija i za neposrednu komunikaciju korisnika sa sustavom.

  • FESB | 1. Uvod 9

    1.1. Baza podataka i sustav za upravljanje bazama podataka

    Prethodno nabrojeni razlozi uvjetovali su znaajne tehnoloke izmjene u upravljanju podacima. Od sredine ezdesetih godina do danas, izuzetno se brzo razvijaju sustavi za upravljanje bazom podataka (SUBP) ili eng. database management systems (DBMS).

    Slika 1.2. Sustav za upravljanje bazama podataka.

    Baza podataka osigurava:

    Organiziranje podataka

    Obradu podataka

    Rukovanje podacima Sigurnost podataka Baza podataka je skup meusobno povezanih podataka, pohranjenih u vanjskoj memoriji raunala. Podaci su istovremeno dostupni raznim korisnicima i aplikacijskim programima. Umjesto da su razbacani po nezavisnim datotekama, podaci su organizirani u jedinstvenu strukturu baze podataka. Podaci postaju jedinstveni resurs sustava i njima se mora upravljati na jedinstven nain, onako kako se upravlja i sa svim drugim vitalnim resursima poslovnih sustava.

  • FESB | 1. Uvod 10

    Dodavanje, izmjena, brisanje i itanje podataka obavlja se posredstvom zajednikog softvera. Korisnici i aplikacije pritom ne moraju poznavati detalje fizikog prikaza podataka, ve se referenciraju na logiku strukturu baze podataka.

    Slika 1.3. Pristup podacima preko odgovarajueg softvera - korisnici ne moraju poznavati detalje fizikog prikaza podataka.

    Sustav za upravljanje bazom podataka (Data Base Management System - DBMS) je posluitelj (server) baze podataka. DBMS : - oblikuje fiziki prikaz baze u skladu s traenom logikom strukturom; - obavlja u ime klijenata sve operacije s podacima; - brine se za sigurnost podataka, te automatizira administrativne poslove s bazom. Zahtjevi koji se postavljaju nad suvremenim SUBP:

    Opis i rukovanje podacima pomou posebnog jezika (SQL-Structured Query Language) Zatita integriteta podataka

    Visok nivo suelja prema korisniku (bez obzira na strukturu podataka)

    Slika 1.4. Zadaci sustava za upravljanje bazom podataka. Baze podataka predstavljaju viu razinu rada s podacima u odnosu na klasine programske jezike. Ta via razina rada oituje se u tome to tehnologija baza podataka nastoji (i u velikoj mjeri uspijeva) ispuniti sljedee ciljeve:

    1. Spremanje podataka sa minimalnom moguom redundancijom 2. Fizika nezavisnost podataka. Razdvaja se logika definicija baze od njene stvarne

    fizike grae. Znai, ako se fizika graa promijeni (na primjer, podaci se prepiu u druge datoteke na drugim diskovima), to nee zahtijevati promjene u postojeim aplikacijama.

  • FESB | 1. Uvod 11

    3. Logika nezavisnost podataka. Razdvaja se globalna logika definicija cijele baze podataka od lokalne logike definicije za jednu aplikaciju. Znai, ako se logika definicija promijeni (na primjer uvede se novi zapis ili veza), to nee zahtijevati promjene u postojeim aplikacijama. Lokalna logika definicija obino se svodi na izdvajanje samo nekih elemenata iz globalne definicije, uz neke jednostavne transformacije tih elemenata.

    4. Fleksibilnost pristupa podacima. Zahtijeva se da korisnik moe slobodno prebirati po podacima, te po svom nahoenju uspostavljati veze meu podacima. Ovaj zahtjev zadovoljavaju jedino relacijske baze.

    5. Istovremeni pristup do podataka. Baza mora omoguiti da vei broj korisnika istovremeno koristi iste podatke. Pritom ti korisnici ne smiju ometati jedan drugoga, te svaki od njih treba imati dojam da sam radi s bazom.

    4. uvanje integriteta. Nastoji se automatski sauvati korektnost i konzistencija podataka, i to u situaciji kad postoje greke u aplikacijama, te konfliktne istovremene aktivnosti korisnika.

    5. Mogunost oporavka nakon kvara. Mora postojati pouzdana zatita baze u sluaju kvara hardvera ili greaka u radu sistemskog softvera.

    6. Zatita od neovlatenog koritenja. Mora postojati mogunost da se korisnicima ogranie prava koritenja baze, dakle da se svakom korisniku reguliraju ovlatenja to on smije a to ne smije raditi s podacima.

    7. Zadovoljavajua brzina pristupa. Operacije s podacima moraju se odvijati dovoljno brzo, u skladu s potrebama odreene aplikacije. Na brzinu pristupa moe se utjecati odabirom pogodnih fizikih struktura podataka, te izborom pogodnih algoritama za pretraivanje.

    8. Mogunost podeavanja i kontrole. Velika baza zahtijeva stalnu brigu: praenje performansi, mijenjanje parametara u fizikoj gradi, rutinsko pohranjivanje rezervnih kopija podataka, reguliranje ovlatenja korisnika. Takoer, svrha baze se vremenom mijenja, pa povremeno treba podesiti i logiku strukturu.

    Ukupno 10 navedenih ciljeva. Ovakvi poslovi moraju se obavljati centralizirano.

  • FESB | 1. Uvod 12

    1.1.1. Kako se ostvaruje fizika i logika nezavisnost podataka? Da bi lake objasnili kako je ostvarena fizika i logika nezavisnost podataka - DBMS kao vieslojna arhitektura sa strogo definiranim sueljima izmeu slojeva.

    Slika 1.5. DBMS: vieslojna arhitektura. 1. Fiziki sloj Odnosi se na fiziki prikaz i raspored podataka na jedinicama vanjske memorije. To je aspekt kojeg vide samo sistem-programeri (oni koji su razvili DBMS). Moe se dalje podijeliti na vie pod-razina apstrakcije, od sasvim konkretnih staza i cilindara na disku, do ve donekle apstraktnih pojmova datoteke i zapisa kakve susreemo u klasinim programskim jezicima. Nain fizikog spremanja i rukovanja podacima. Odnosi se na raspored podataka na vanjskim ureajima.

    2. Globalni logiki sloj Odnosi se na logiku strukturu cijele baze. To je aspekt kojeg vidi projektant baze odnosno njen administrator. Zapis logike definicije naziva se shema (eng. schema). Shema je tekst ili dijagram koji definira logiku strukturu baze, i u skladu je sa zadanim modelom (koji je implementiran u DBMS-u). Imenuju se i definiraju svi tipovi podataka i veze

  • FESB | 1. Uvod 13

    meu tim tipovima, u skladu s pravilima koritenog modela. Shema uvodi i ogranienja kojim se uva integritet podataka. 3. Lokalni logiki sloj Odnosi se na logiku predodbu o dijelu baze kojeg koristi pojedina aplikacija. To je aspekt kojeg vidi korisnik ili aplikacijski programer. Podrazumijeva izradu front-end korisnike aplikacije za rad s bazom. Izbor programskog jezika zavisi o mogunostima pojedinih alata kao i potrebama krajnje aplikacije. Zapis jedne lokalne logike definicije zove se pogled (view) ili podshema. To je tekst ili dijagram kojim se imenuju i definiraju svi lokalni tipovi podataka i veze meu tim tipovima, opet u skladu s pravilima koritenog modela. Takoer, pogled zadaje preslikavanje kojim se iz globalnih podataka i veza izvode lokalni.

    Slika 1.6. Pojednostavnjena arhitektura DBMS-a. 1. Ako se promijeni fizika struktura baze podataka, nije neophodno mijenjati globalnu

    logiku strukturu (shemu baze podataka), ve samo preslikavanje sheme baze podataka u fiziku razinu.

    2. Ako se promijeni struktura sheme, pogledi ostaju nepromijenjeni, mijenja se samo nain preslikavanja sheme u pogled.

    1.+2. -> Logika i fizika nezavisnost programa od podataka. Na fizikom sloju, preko jezika koji se naziva jezik za definiciju podataka (Data Definition Language - DDL), specificira se fizika organizacija podataka, odnosno metode pristupa.

  • FESB | 1. Uvod 14

    Programer razvija svoju aplikaciju nad njemu pogodnom logikom strukturom koja predstavlja njegov "pogled" na cjelokupnu bazu podataka.

    On za to koristi neki uobiajeni programski jezik (C++, Basic, Javu ili neki drugi), u koji se ugrauju naredbe DDL-a i naredbe jezika za rukovanje podacima u bazi podataka (Data Manipulation Language - DML).

    npr. CREATE TABLE ( , ...

    ); Naredbe DML omoguuju "manevriranje" po bazi, te jednostavne operacije kao to su

    itanje, upis, promjenu ili brisanje zapisa. U nekim softverskim paketima, DML je zapravo biblioteka potprograma: "naredba" u DML svodi se na poziv potprograma. U drugim paketima zaista se radi o posebnom jeziku: programer tada pie program u kojem su izmijeane naredbe dvaju jezika, pa takav program treba prevoditi s dva prevodioca (DML-precompiler, obini compiler). Za korisnike neprofesionalce obino postoji i neki neproceduralni upitni jezik (Query Language) koji slui za interaktivno pretraivanje baze. Podsjea na govorni (engleski) jezik. Naredbe su neproceduralne, dakle takve da samo specificiraju rezultat kojeg elimo dobiti, a ne i postupak za dobivanje rezultata. Napomena: Jezik za definiciju podataka (Data Definition Language - DDL) i jezik za rukovanje podacima u bazi podataka (Data Manipulation Language - DML) nisu programski jezici. Dakle ti jezici su nam nuni da bi se povezali s bazom, no oni nam nisu dovoljni za razvoj aplikacija koje e neto raditi s podacima iz baze. Ovakva podjela na tri jezika danas je ve prilino zastarjela. Naime, kod relacijskih baza postoji tendencija da se sva tri jezika objedine u jedan sveobuhvatni. Primjer takvog integriranog jezika za relacijske baze je SQL: on slui za definiranje, manipuliranje i pretraivanje podataka. Integrirani jezik se moe koristiti interaktivno (preko on-line interpretera) ili se on moe pojavljivati uklopljen u aplikacijske programe. U 80-tim godinama 20. stoljea bili su dosta popularni i tzv. jezici 4. generacije (4-th Generation Languages - 4GL): rije je o jezicima koji su bili namijenjeni iskljuivo za rad s bazama, te su zato u tom kontekstu bili produktivniji od klasinih programskih jezika ope namjene. Problem s jezicima 4. generacije je bio u njihovoj nestandardnosti: svaki od njih je u pravilu bio dio nekog odreenog softverskog paketa za baze podataka, te se nije mogao koristiti izvan tog paketa (baze). U dananje vrijeme, aplikacije se najee razvijaju u popularnim objektno orijentiranim programskim jezicima (Java, C++, . . . ). Gotovo svi noviji softverski paketi (MySQL, MS Access, MS SQL Server, Oracle, DB2,) podravaju relacijski model i SQL. Svaki sadrava svoj DBMS, standardne klijente (npr. interaktivni interpreter SQL), te biblioteke i alate za razvoj aplikacija. Za interakcije s bazom koriste se unaprijed pripremljene klase objekata. Ovakva tehnika je dovoljno produktivna zbog koritenja gotovih klasa, a rezultirajui program se lako dotjeruje, uklapa u vee sustave ili prenosi s jedne baze na drugu. Glavna i odgovorna osoba u smislu upravljanja cjelokupnim sustavom baze podataka je administrator baze podataka. Funkcije administratora baze podataka:

    Razvoj globalnog sloja, odnosno upravljanje podacima u sustavu Izbor fizike organizacije baze podataka i metoda pristupa podacima

  • FESB | 1. Uvod 15

    Definicija i realizacija preslikavanja izmeu globalnog logikog sloja i fizikog sloja, te globalnog logikog sloja i lokalnih pogleda, odnosno definiranje ili pomo u definiranju pogleda na bazu podataka

    Osiguravanje sigurnosti podataka i integriteta baze podataka Definiranje strategija oporavka baze podataka poslije moguih oteenja (problema) Praenje efikasnosti (performansi) sustava

    Administrator baze podataka koristi jezik za definiciju podataka (DDL) za definiciju ope logike strukture baze podataka. Da bi lake obavio svoje zadatke administrator se koristi razliitim pomonim programima (programi za punjenje baze podataka (BP), "Dump/restore" rutine, programi za fiziku reorganizaciju BP, programi za ispis i analizu statistike koritenja podataka) Ipak, osnovni alat administratora baze podataka je rjenik (katalog) baze podataka (Data Dictionary). Rjenik baze podataka je baza podataka o bazi podataka (meta baza podataka) i u njemu su opisani svi objekti sustava (podaci, fizike i logike strukture, prava koritenja i slino). Rjenik podataka se puni prilikom definiranja odgovarajuih objekata u sustavu. Zbog sloenosti navedenih osnovnih i pomonih funkcija sustavi za upravljanje bazama podataka su sloeni i veoma skupi softverski sustavi. Meutim prednosti koje pruaju su takve da se i pored visoke cijene gotovo svuda uvode.

    1.2. Metodologija projektiranja baza podataka Tehnologija baza podataka omoguila je da se problem razvoja IS odnosu na realni sustav u kome djeluje postavi na slijedei nain:

    Sustav se najopenitije definira kao skup objekata (entiteta) i njihovih meusobnih veza (relacija).

    Objekti u sustavu mogu biti neki fiziki objekti, pojave, dogaaji i drugo. Objekti se u modelu nekog sustava opisuju preko svojih svojstava (atributa). Djelovanje okoline na sustav opisuje se preko ulaza u sustav, a djelovanje sustava na

    okolinu preko njegovih izlaza.

    Slika 1.7. Standardni shematski prikaz dinamikog ponaanja realnog sustava.

    Ulazi u sustav mijenjaju stanja sustava. Stanje sustava definira se kao skup informacija o prolosti i sadanjosti sustava koji je potreban da bi se, uz djelovanje buduih poznatih ulaza, mogli odrediti budui izlazi. U stanju sustava sadrana je cjelokupna povijest realnog

  • FESB | 1. Uvod 16

    sustava. preko njegovih izlaza. Stanje sustava opisuje osnovne karakteristike sustava. U jednom trenutku vremena ono predstavlja skup objekata sustava, skup njihovih meusobnih veza i skup vrijednosti atributa objekata u upravo tom trenutku. Izlazna transformacija definira neki nain mjerenja ili promatranja dinamikog ponaanja realnog sustava i daje, na osnovu stanja sustava, njegove izlaze. Primjer: Sustav skladite proizvoda Objekti: proizvodi, Atributi objekata: naziv, osobine, jedinica mjere i koliina u skladitu Veza izmeu objekata: sastav proizvoda, koji pokazuje od kojih se drugih proizvoda, promatrani proizvod, sastoji. Svaki prijem ili izdavanje proizvoda iz skladita predstavlja ulaz u sustav (jer mijenja njegova stanja). Osnovna komponenta stanja u sustavu: koliina svakog proizvoda u skladitu. Izlaz iz sustava: koliina zaliha svakog proizvoda (samo stanje sustava), ukupna vrijednost zaliha, ukupna vrijednost zaliha proizvoda odreene vrste i slino. Izlazna transformacija daje ove izlaze na osnovu stanja sustava. Informacijski sustav predstavlja model realnog sustava u kome djeluje. Podaci o ulazu (zahtjevnice, primke, otpremnice i sl.), preko programa za odravanje (koji modeliraju djelovanje ulaza na sustav), djeluju na bazu podataka (kartica zaliha materijala), koja modelira stanje sustava. Programi za izvjetavanje predstavljaju model izlazne transformacije (postupak izraunavanja ukupne vrijednosti zaliha, ...) i daju zahtijevane izlaze. Osnovu informacijskog sustava (IS-a) ini baza podataka, jer ona predstavlja osnovne, stabilne, sporo promjenjive osobine sustava, objekte u sustavu i njihove meusobne veze. Zato se projekt IS mora temeljiti na bazi podataka. Preduvjeti dobre baze podataka su:

    baza podataka predstavlja dobar model stanja realnog sustava, programi za odravanje dobro modeliraju djelovanje ulaza na stanje realnog sustava,

    Posljedica: bilo koja informacija potrebna za upravljanje (izlazi), ak i one koje nismo unaprijed predvidjeli, mogu se dobiti iz IS. Ako je informacijski sustav model realnog sustava u kome djeluje, onda se postupak projektiranja IS svodi na neku vrstu modeliranja realnog sustava, a za to su nam neophodna neka intelektualna sredstva (alati) i to:

    Model podataka kao intelektualno sredstvo za prikazivanje objekata sustava (statike sustava), njihovih atributa i njihovih meusobnih veza (statikih karakteristika sustava) preko logike strukture baze podataka.

    Model procesa kao intelektualno sredstvo za opisivanje dinamike sustava, djelovanja ulaza na stanje sustava i izlazne transformacije, preko programa nad definiranim modelom podataka.

    U ovom kolegiju baviti emo se samo modelima podataka, dok e modeli procesa biti prikazani samo usput, u onoj mjeri u kojoj to bude neophodno za izlaganje procesa projektiranja baza podataka.

    Podatak je neka (kodirana) injenica iz realnog sustava, on je nosilac informacije.

    Informacija je protumaeni (interpretirani) podatak.

  • FESB | 1. Uvod 17

    Krajnju interpretaciju podataka iz baze podataka daje korisnik IS, preko odgovarajuih programa ili upita. Interpretacija podataka se vri na osnovu strukture podataka, semantikih ogranienja na njihove vrijednosti, a preko operacija koje se nad njima mogu izvriti. Zbog toga svaki model podataka posjeduje tri osnovne komponente:

    1. Strukturu modela, odnosno skup postavki za opis objekata sustava, njihovih atributa i njihovih meusobnih veza

    2. Ogranienja - semantika ogranienja vrijednosti podataka koja se ne mogu predstaviti samom strukturom modela, a koja u svakom trenutku moraju biti zadovoljena. Ova ogranienja se obino nazivaju pravilima integriteta modela podataka

    3. Operacije nad postavkama strukture, pod definiranim ogranienjima, preko kojih je mogue opisati dinamiku sustava u modelima procesa

    Svaki model podataka treba zadovoljiti dva temeljna kriterija:

    1. mora biti pogodan za modeliranje realnih sustava 2. postavke, struktura, ogranienja i operacije koje se dobiju modeliranjem mogu se

    jednostavno implementirati na raunalu Po tome kako zadovoljavaju ove kriterije modeli podataka mogu se svrstati u tri skupine: 1. Prvu generaciju ine standardni programski jezici, koji se takoer mogu tretirati kao

    modeli podataka. Postavke za opisivanje strukture u njima su tipovi podataka kojima raspolau (prosti i sloeni tipovi kao to su zapis (record), vektor, lista, stablo, koji se meusobno ne mogu eksplicitno povezivati na eljene naine, pa se zato model podataka u njima predstavlja kao skup nepovezanih datoteka) Ogranienja nad ovim tipovima obino nije mogue direktno postaviti, a same operacije nisu dovoljno mone. Oni nisu dovoljno pogodni za modeliranje realnog sustava (zato je programiranje u njima teko), ali se model realnog sustava opisan pomou njih moe direktno implementirati na raunalu.

    2. Drugu generaciju ine tri klasina modela baze podataka, hijerarhijski, mreni i relacijski model.

    Ovi modeli posjeduju semantiki bogatije koncepte za opis strukture (mogue je definirati nain povezivanja zapisa, odnosno bazu podataka kao skup meusobno povezanih podataka) i znatno monije (makro) operacije. Zbog toga su pogodniji za opis realnog sustava, a postoje i komercijalno raspoloivi softveri, (SUBP/DBMS), za njihovu direktnu implementaciju na raunalu.

    3. Treu generaciju ine tzv. semantiki bogati modeli podataka i objektni modeli podataka (Model objekt i veze (entity-releationship), Semantic Data Model (SDM), Proireni relacijski model, Semantike mree i drugi)

    Posjeduju semantiki bogate koncepte za opis realnog sustava, ali za njih jo uvijek ne postoje softveri preko kojih bi se direktno mogli implementirati na raunalu.

    Imajui u vidu karakteristike generacije modela podataka, zadovoljavajui metodoloki pristup projektiranju baza mogao bi biti:

    1. Koristei neki model Tree generacije, formirati semantiki bogat model realnog sustava koji se analizira

    2. Prevesti dobiveni model u neki od modela Prve ili Druge generacije, u zavisnosti od softvera kojim raspolaemo i drugih faktora, i na taj nain implementirati bazu podataka na raunalu.

  • FESB | 1. Uvod 18

    Postupak prevoenja sa semantiki bogatijeg, na semantiki siromaniji model lako se moe se formalizirati, pa samim tim i automatizirati. U ovom kolegiju koristiti emo Entity-relationship model (Model objekti - veze), najpopularniji semantiki model za prvi korak, a relacijski model baze podataka e biti implementacijski model.

    1.3. Modeli baza podataka Znamo da su programski jezici vremenom evoluirali od neproceduralnih do objektno-orijentiranih. Modeli baza podataka su takoer evoluirali zbog uoavanih ogranienja:

    nedovoljno dobro opisivanje stvarnih veza meu podacima rast opsega i zahtjeva obrada nad bazom podataka promjena karaktera podataka koji se pohranjuju u baze podataka poveanje uinkovitosti svih sudionika u obradi podataka (od administratora baze

    podataka, preko programera do korisnika podataka) rastom i veom raspoloivou hardvera

    Zahvaljujui novim teoretskim postavkama novi su sustavi za upravljanje bazama podataka uspjeno su uklanjali trenutna ogranienja. Trend unaprjeivanja, danas je jo naglaeniji. Na slici 1.8. su prikazani dosada primjenjivani modeli sustava za upravljanje bazama podataka od njihove pojave do danas.

    Slika 1.8. Kronoloki prikaz razvoja i primjena modela sustava za upravljanje bazama podataka.

    1. Hijerarhijski model baze podataka. Baza je predoena jednim (izokrenutim) stablom ili skupom (izokrenutih) stabala. Pravokutnicima se oznaavaju tipovi zapisa. Za svaki par povezanih zapisa u meusobno

    susjednim razinama utvruje se odnos "roditelj-dijete" (roditelj je podatak na vioj razini). Svaki zapis podataka na vrnoj razini je hijerarhijski odreen kao korijenski segment. Unutar svakog zapisa dodaju se pokazivai prema zapisu na vioj razini (prema gore) i

    prema zapisima na nioj razini (prema dolje) u skladu sa odreenjem veza roditelj-dijete. Meu zapisima se uspostavlja fiziko povezivanje.

  • FESB | 1. Uvod 19

    Slika 1.9. Primjer hijerarhijske baze podataka

    2. Mreni model baze podataka. Veze meu zapisima znatno bolje opisuju veze meu podacima u realnom svijetu. Baza je

    predoena usmjerenim grafom. Meusobno zavisne strukture podataka nemaju strogo utvrenu hijerarhijsku strukturu. Zapisi se tipiziraju. Tip podataka je struktura podataka koja se moe objediniti zahvaljujui zajednikim osobinama podataka. Uvode se vezni segmenti podataka koji postoje i vezuju se sa njihovim vlasnicima. Ustanovljava se princip viestrukih roditelja. Vezni zapisi mogu imati istovremeno vie roditelja.

    Identino kao i kod hijerarhijskog modela unutar zapisa se dodaju pokazivai, tj. meu zapisima se uspostavlja fiziko povezivanje.

    Slika 1.10. Primjer mrene baze podataka.

    3. Relacijski model baze podataka. Zasnovane su na teoretskim postavkama koje je oblikovao Dr. E.F.Codd 1971 god.

    Osnova je matematikom pojmu relacije. Relacija je dvodimenzionalna tablica.

    Svaki redak tablice odgovara jednom zapisu.

    Stupci tablice opisuju elemente (atribute) sa isti smislom (osobinama). I podaci i veze meu podacima prikazuju se relacijskim tablicama.

    Osnovna razlika u odnosu na prethodne modele je nepostojanje fizike veze meu podacima. Veze meu podacima su potpuno logike. Veza izmeu zapisa u relacijskim tabelama uspostavlja se primjenom stranih kljueva. Klju nekog zapisa je atribut ili skup atributa koji nedvosmisleno odreuje sve lanove zapisa.

  • FESB | 1. Uvod 20

    Slika 1.11. Primjer relacijske baze podatka.

    Slika 1.12. Primjer uspostavljanja veza meu relacijama.

    4. Objektni model baza podataka. Inspiriran je objektno-orijentiranim programskim jezicima. Baza je skup trajno pohranjenih

    objekata koji se sastoje od svojih internih podataka i "metoda" (operacija) za rukovanje s tim podacima. Svaki objekt pripada nekoj klasi. Izmeu klasa se uspostavljaju veze nasljeivanja, agregacije, odnosno meusobnog koritenja operacija.

  • FESB | 1. Uvod 21

    Slika 1.13. Primjer objektne baze podataka.

    5. Objektno-relacijske model baze podataka.

    Otklanjaju probleme objektnih baza podataka. Teoretska podloga ve postoji, kasni valjana implementacija. Hijerarhijski i mreni model bili su u upotrebi u 60-tim i 70-tim godinama 20. stoljea. Od 80-tih godina pa sve do dananjih dana prevladava relacijski model. Oekivani prijelaz na objektne, pa kasnije i na objektno-relacijske baze podataka za sada se nije dogodio (iako je teoretska osnova postoji ve due vrijeme), tako da dananje baze podataka uglavnom jo uvijek moemo poistovjetiti s relacijskim bazama.

    Slika 1.14. Veliki broj DBMS razliitih proizvoaa. Vei broj nezavisnih implementacija

    uglavnom je posljedica fluktuacije (pretravanja) informatikog kadra meu jakom igraima na ovom podruju.

  • FESB | 1. Uvod 22

    1.4. Tipovi i strukture baza podataka Baze podataka moemo razlikovati prema nainu pristupa podacima, nainu raspodjele,

    obrade i odravanja podataka. 1. Centralizirana baza podataka terminalski pristup 2. Client- server pristup 3. Paralelna struktura baze podataka 4. Distribuirana baza podataka Centralizirana baza podataka terminalski pristup. Podrazumijeva smjetaj podataka na jednom mjestu (sredinjem raunalu) i terminalski pristup od strane korisnika. Ovakav pristup znai da se svi zahtjevi i obrade podataka vre na sredinjem raunalu, na kojem su smjeteni i podaci. Korisnik preko terminala, jedino unosi svoje zahtjeve, te dobija prikaz rezultata eljenih operacija. Ovakav nain organizacije baze postavlja velike zahtjeve na sredinje raunalo, koje osim smjetaja svih podataka, vri i sve operacije obrade podataka, njihovog formatiranja i prikaza. Stoga sredinje raunalo mora imati vrlo veliku procesorsku snagu i visoke performanse.

    Client- server pristup. Podaci su smjeteni na sredinjem raunalu (server), koje vri glavninu zahtjeva za manipuliranje i obradu podataka. Korisnici koji pristupaju bazi, taj pristup ostvaruju preko svojih PC raunala, koja su mreom povezana sa serverom. Za razliku od terminalskog pristupa, kod kojeg terminalske stanice nemaju nikakve mogunosti sudjelovanja u obradi podataka, PC raunala na strani klijenta djelomino sudjeluju u obradi podataka. Korisnik preko programskog suelja formira zahtjev za odreenim podacima, koji se prosljeuje serveru. Serversko raunalo prihvaa zahtjev, te ga obrauje, a rezultate te obrade vraa klijentu. Klijentsko raunalo prihvaa tako obraene podatke, te ih formira u obliku kojeg definira korisniko suelje.

    Paralelna struktura baze podataka Paralelna struktura podrazumijeva formiranje baze u okruju raunala meusobno povezanih u lokalnu mreu. Izmeu raunala postoji brza veza, ostvarena preko brzih mrenih kartica (100MB/s i vie). Podaci su najee smjeteni na samo jednom raunalu, ali se pri obradi podataka moe koristiti procesorska snaga svih raunala u mrei. Ovakvim konceptom baze dobiva se mogunost istovremenog koritenja resursa vie raunala, pa pojedina raunala mogu imati i neto slabije karakteristike. Distribuirana baza podataka Podrazumijeva strukturu baze podataka u kojoj su podaci raireni na vie raunala, koja su mreno povezana. Jednostavno reeno, distribuirana baza podrazumijeva vie lokalnih, meusobno povezanih baza. Pred samim korisnikom je ta rasprenost podataka skrivena, te on ima osjeaj da pristupa jednoj sredinjoj bazi. U dananjim uvjetima postoji sve vee potreba za realizacijom distribuiranih baza podataka. Razlozi za to su brojni:

    Mnogi korisnici za koje se rade baze podataka po svojoj prirodi su distribuirani na vie lokacija. Uzmimo primjer mnogih multinacionalnih kompanija, koje imaju podrunice diljem svijeta. Svaka podrunica u mjestu u kojem se nalazi formira svoju lokalnu bazu podataka, a sve te baze zatim se povezuju u distribuiranu bazu podataka, koja objedinjava sve lokalne baze. Rukovodstvo kompanije ima mogunost pristupa u sve baze i nadzora podataka koji se nalaze u bilo kojoj lokalnoj bazi.

    Distribucijom baze podataka poveava se raspoloivost i pouzdanost sustava. U sluaju ispada bilo kojeg raunala u mrei, podaci na tom mjestu postaju nedostupni

    korisnicima, ali su podaci na svim ostalim mjestima sauvani i dostupni.

  • FESB | 1. Uvod 23

    U distribuiranim sustavima se koristi tehnika repliciranja istih podataka na vie lokacija u mrei.

    Zbog obrade manjih baza podataka, brzina obrade na pojedinim mjestima je vea u odnosu na brzinu koju bi imao sustav koji obrauje veliku centraliziranu bazu.

    Da bi se u potpunosti iskoristile prednosti koje pruaju distribuirani sustavi, osim zadataka koji su zajedniki sa zadacima centraliziranih sustava, distribuirani sustavi moraju omoguiti:

    pristup udaljenim raunalima u mrei te prijenos upita i podataka izmeu raunala postojanje sistemskog kataloga s podacima o distribuciji podataka u mrei odravanje

    konzistentnosti podataka koji se repliciraju

    izradu strategije za izvoenje pretraivanja i obrada koje dohvaaju podatke iz vie lokalnih baza. oporavak sustava u sluaju ispada pojedinog raunala iz mree.

    1.5. ivotni ciklus baze podataka

    Uvoenje baze podataka u neko poduzee ili ustanovu predstavlja sloeni zadatak koji zahtijeva timski rad strunjaka raznih profila. To je projekt koji se moe podijeliti u slijedee faze:

    Planiranje razvoja

    Analiza i specifikacija zahtjeva

    Modeliranje podataka Implementacija

    Testiranje Odravanje

    Planiranje razvoja Projektiranje i izgradnja baza podataka i kupnja odgovarajueg softvera (sustava za upravljanje bazama podataka) nije jeftina, pa joj se ne smije nikako prii kao igraki grupice informatiara. Odluka da se pristupa izgradnji baze podataka (odnosno izgradnji IS) mora biti dobro promiljena. Mora je slijediti plan realizacije i osigurana financijska sredstva. Ako toga nema i rezultat e biti najvjerojatnije lo. Analiza i specifikacija zahtjeva Prouavaju se tokovi informacija u poduzeu. Uoavaju se podaci koje treba pohranjivati i veze medu njima. U velikom poduzeima, gdje postoje razne grupe korisnika, pojavit e se razni "pogledi" na podatke. Te poglede treba uskladiti tako da se eliminira redundancija i nekonzistentnost. Na primjer, treba u raznim pogledima prepoznati sinonime i homonime, te uskladiti terminologiju. Analiza potreba takoer treba obuhvatiti analizu transakcija (operacija) koje e se obavljati nad bazom podataka, budui da to moe isto imati utjecaja na sadraj i konani oblik baze. Vano je procijeniti frekvenciju i opseg pojedinih transakcija, te zahtjeve na performanse. Rezultat analize je dokument (pisan neformalno u prirodnom jeziku) koji se zove specifikacija potreba. Modeliranje podataka Razliiti pogledi na podatke, otkriveni u fazi analize, sintetiziraju se u jednu cjelinu - globalnu shemu. Precizno se utvruju tipovi podataka. Shema se dalje dotjeruje ("normalizira") tako da zadovolji neke zahtjeve kvalitete. Takoer, shema se prilagoava ogranienjima koje postavlja zadani model podataka, te se dodatno modificira da bi bolje mogla udovoljiti zahtjevima na performanse. Na kraju se iz sheme izvode pogledi (pod-sheme) za pojedine aplikacije (grupe korisnika).

  • FESB | 1. Uvod 24

    Implementacija Na osnovu sheme i pod-shema, te uz pomo dostupnog DBMS-a, fiziki se realizira baza podataka na raunalu. U DBMS-u obino postoje parametri kojima se moe utjecati na fiziku organizaciju baze. Parametri se podeavaju tako da se osigura efikasan rad najvanijih transakcija. Razvija se skup programa koji realiziraju pojedine transakcije te pokrivaju potrebe raznih aplikacija. Baza se inicijalno puni podacima. Testiranje Korisnici pokusno rade s bazom i provjeravaju da li ona zadovoljava svim zahtjevima. Nastoje se otkriti greke koje su se mogle potkrasti u svakoj od faza razvoja: dakle u analizi potreba, modeliranju podataka, implementaciji. Greke u ranijim fazama imaju tee posljedice. Npr. greka u analizi potreba uzrokuje da transakcije moda korektno rade, no ne ono to korisnicima treba ve neto drugo. Zato se u novije vrijeme, prije prave implementacije, razvijaju i priblini prototipovi baze podataka, te se oni pokazuju korisnicima kako bi se propusti otkrili prije implementacije. Odravanje Odvija se u vrijeme kad je baza ve ula u redovnu upotrebu. Sastoji se od sljedeeg:

    popravak greaka koje nisu bile otkrivene u fazi testiranja;

    uvoenje promjena zbog novih zahtjeva korisnika;

    podeavanje parametara u DBMS u svrhu poboljavanja performansi.

    Slika 1.15. Mogui problemi koji nastaju uslijed neprofesionalnog pristupa razvoju baze

    podataka.

  • FESB | 1. Uvod 25

    Odravanje zahtijeva da se stalno prati rad s bazom, i to tako da to praenje ne ometa korisnike. Administratoru baze podataka trebaju stajati na raspolaganju odgovarajui alati (utility programi). Posebnu panju treba obratiti na prve tri faze razvoja baza podataka (planiranje, analiza, modeliranje). Snimanje i analiza zahtjeva posebno su sloen zadatak. Informatizirati loe organiziran posao se moe ali je dobit ostvarena takvim sustavom sumnjiva. U procesu prikupljanja podataka o nekom sistemu treba se koristiti svim raspoloivim izvorima: postojeim informatikim rjeenjima, znanjem osoblja na svim razinama radne i upravljake hijerarhije, svim dokumentima koji nastaju unutar poslovnog procesa. Posebno je teko odrediti to je vano a to nije. Ako su prikupljene sve mogue informacije, i dobro analizirane, sve ostale faze u razvoju baze podataka biti e dobro utemeljene, i velika je ansa da e i konani rezultat biti uspjean.

  • FESB | Modeliranje podataka 26

    2. Modeliranje podataka Modeliranje podataka (data modeling) je tehnika organiziranja i dokumentiranja podataka sustava. Rezultat modeliranja je baza podataka.

    2.1. Koraci u projektiranju baze podataka Baza podataka uvijek predstavlja opis-sliku stvarnog procesa iz okoline. Pri tome se u bazu podataka pohranjuju podaci koji su meusobno povezani na razliite naine i njihove vrijednosti predstavljaju dio realnog svijeta. Prva stepenica na putu od zamisli do realizacije baze podataka je izrada globalne logike sheme baze podataka.

    Slika 2.1. Prvi cilj: logika shema baze podataka.

    Napomena: Rjenik podataka, ili meta-baza baze podataka sadri sve informacije koje opisuju konkretnu bazu podataka, poevi od osnovnih objekata poput atributa i entiteta, njihovih ogranienja, tipova podataka, kljueva, veza, pohranjenih procedura i svih ostalih objekata i pravila koja sainjavaju relacijsku bazu podataka. Projektiranje baze podataka je proces koji se odvija u sljedeim koracima: 1. Analiza i snimanje zahtjeva 2. Poetni (konceptualni) model baze podataka 3. Prevoenje konceptualnog modela u poetni logiki dizajn baze podataka 4. Dorada logike sheme baze podataka 5. Fiziki dizajn baze podataka 6. Uvoenje sigurnosnih zahtjeva i ogranienja

  • FESB | Modeliranje podataka 27

    2.1.1. Analiza i snimanje zahtjeva. Razumijevanje o tome to se eli postii, koje podatke treba spremiti u bazu podataka, koje e se obrade i upiti najee zahtijevati nad spremljenim podacima, to korisnik eli od baze podataka. Ova faza ukljuuje:

    o prikupljanje i analizu dokumenata koji se koriste u realnom sustavu, o niz opetovanih razgovora s grupama korisnika baze podataka, o analize postojeih raunalnih rjeenja i raspoloive dokumentacije.

    Postoji nekoliko metodologija i niz softverskih rjeenja kojima se prikupljena graa moe sistematizirati i organizirano predoiti. U naim primjerima smatrati emo da dobro poznajemo to se od nas trai (tj. da smo obavili potrebnu analizu zahtjeva), da znamo sve o podacima sa kojim elimo raditi i njihovoj meusobnim vezama.

    2.1.2. Poetni (konceptualni) model baze podataka. Prikupljene podatke pokuava se pretoiti u poetni dizajn (skicu) baze podataka. Skica baze podataka izrauje se primjenom neke prikladne metodologije. Obino se smatra da je konceptualni model krajnja toka u dizajniranju baze podataka - > Ovo nije potpuno tono. Konceptualni model je samo aproksimativni opis podataka, dobiven kroz vrlo subjektivno tumaenje informacija prikupljenih u fazi analize zahtjeva. Paljivija analiza obino e otkriti i ispraviti niz pogreaka u logikoj shemi baze podataka, negdje do kraja etvrte faze u dizajniranju baze podataka.

    2.1.3. Prevoenje konceptualnog modela u poetni logiki dizajn baze podataka. U ovoj fazi se odabire DBMS sustav za implementaciju i konani dizajn baze podataka. Pogodnim transformacijama pretvaramo skicu (konceptualni model) iz prethode faze u logiku shemu baze u izabranom DBMS-u.

    2.1.4. Dorada logike sheme baze podataka. U ovoj fazi analiziraju se skupovi relacija u relacijskoj shemi baze podataka (ako je odabran relacijski model DBMS-a), s ciljem da se uoe i otklone potencijalni probleme. Za razliku od poetne analize zahtjeva koja je izrazito subjektivna, doraivanje logike sheme baze podataka je postupak koji se temelji na preciznim teorijskim pravilima. Postupak se naziva proces normalizacije relacijskog modela ili prevoenje relacijskog modela u normalne forme.

    2.1.5. Fiziki dizajn baze podataka. Logiki dizajn je zavren, pa se ide na implementaciju bazu podataka (relacije), grade se indeksi, rasporeuju se datoteke na diskovima. Da bi se ostvarile poeljne performanse sustava (brzina odziva) u ovoj fazi je mogue redizajniranje pojedinih relacija.

    2.1.6. Uvoenje sigurnosnih zahtjeva i ogranienja. U ovoj fazi se

    Identificiraju uloge razliitih korisnika,

    Prilagoavaju njihovi pogledi na bazu podataka, Osigurava da svaka pojedina grupa korisnika vidi samo ono to joj zaista treba.

  • FESB | Modeliranje podataka 28

    Slika 2.2. Koraci u projektiranju baze podataka na primjeru baze podataka o knjigama

    Prve tri faze oigledno moemo objediniti pitanjem: kako oblikovati shemu za bazu podataka usklaenu s pravilima relacijskog modela, na temelju poznavanja ponaanja realnog sustava?. U stvarnim situacijama dosta je teko direktno pogoditi relacijsku shemu. Zato se sluimo jednom pomonom fazom koja se zove modeliranje podataka. Rije je o oblikovanju jedne manje precizne, konceptualne sheme, koja predstavlja apstrakciju onog dijela realnog svijeta koji nas zanima. Mi emo primijeniti metodologiju koja se naziva metoda entiteti(objekti)-veze (eng. Entity-relationship model). Shema koju nacrtamo naziva se ER-dijagram, i on se uspjeno, vie ili manje automatski, pretvara u relacijsku logiku shemu baze podataka. Zbog izostanka pravog standarda, postoji mnogo varijacija u crtanju ER-dijagrama. (Mi emo koristiti jednu od nijh. Ipak, da bi se lake snali u literaturi, u nekim primjerima ilustrirati emo i neke druge varijacije ER-dijagrama.) Modeliranje entiteta i veza zahtijeva da se svijet promatra preko tri kategorije:

    o entiteti: objekti ili dogaaji koji su nam od interesa; o veze: odnosi medu entitetima koji su nam od interesa; o atributi: svojstva entiteta i veza koja su nam od interesa.

  • FESB | Modeliranje podataka 29

    2.2. Entiteti i atributi Entitet je skup objekata realnog svijeta koji imaju neka zajednika svojstva. Npr. entitet je: Nogometna lopta na sportskom odjelu, sportski odjel, prodava na sportskom odjelu, adresa stanovanja prodavaa na sportskom odjelu.

    Slika 2.3. Entitet kao skup

    Entitet je ono o emu elimo spremati podatke, neto to je u stanju postojati ili ne postojati, te se moe identificirati. Entitet moe biti objekt ili bie (na primjer, kua, student, auto), odnosno dogaaj ili pojava (na primjer nogometna utakmica, praznik, servisiranje auta). Elementi entiteta imaju neka zajednika svojstva koja ih povezuju. Obino se trudimo prepoznati skupove slinih entiteta (entity set) ili tipove entiteta. Neki entiteti mogu se nalaziti istovremeno u dva skupa entiteta. Npr. skup entiteta ZAPOSLENICI ukljuuje entitet Marko Markovi. Isti entitet se moe nalaziti i u skupu entiteta DAVATELJI KRVI. Entitet je opisan nizom atributa. Npr. atributi entiteta ZGRADA su: adresa, broj katova, boja fasade, . . . Ukoliko neki atribut i sam zahtijeva svoje atribute, tada ga radije treba smatrati novim entitetom (na primjer model automobila u odnosu na automobil). Isto pravilo vrijedi i ako atribut moe istovremeno imati vie vrijednosti (na primjer kvar koji je popravljen pri servisiranju automobila). Svi entiteti unutar jednog skupa entiteta imaju isti skup atributa. Posjedovanje istih atributa je preduvjet za ustanovljavanje slinosti entiteta i utvrivanje pripadnosti istom skupu entiteta. Izborom atributa izraava se ono to nas u realnom svijetu zanima. Npr. skup entiteta ZAPOSLENICI moe imati atribute: ID_zaposlenika, ime, matini broj i spol, ali nema atributa: adresa stanovanja ili mjesto za parkiranje jer nas to u konkretnom sluaju ne zanima. Primjer: Za opis procesa studiranja osnovni entitet je STUDENT, tj. skup svih studenata sa nekim zajednikim svojstvima. Svaki student pojedinac predstavlja jedan element skupa STUDENT. Mogui atributi studenata su: ime, prezime, adresa, JMBG, matini broj, datum roenja itd. Jo primjera entiteta:

  • FESB | Modeliranje podataka 30

    - objekt, npr. DVD Avatar - apstraktni pojam, npr. hrvatski jezik - ustanova (FESB), organizacija (hotel Lav) - dogaaj proli/sadanji/budui roenje, kolovanje, smrt - povezanost razliitih objekata, npr. zaposlenost Za svaki atribut kojim se opisuje entitet, moramo utvrditi skup dozvoljenih vrijednosti (odnosno domenu atributa). Npr. za skup entiteta ili tip entiteta ZAPOSLENIK atribut ime je niz od maksimalno 20 znakova. Atribut ID_zaposlenika moe sadravati samo cijele brojeve od 1 do 9999. Npr. Entitet STUDENT i atribut DATUM ROENJA. Potrebno osigurati da podatak o datumu roenja u standardnom formatu datuma dan.mjesec.godina., te da po svojoj vrijednosti bude logian. Za svaki skup entiteta moramo izabrati klju. Klju je minimalni set atributa koji jednoznano odreuje jedan entitet u skupu entiteta. Kandidata za klju moe biti vie. U jednom skupu entiteta ne mogu postojati dva razliita primjerka entiteta s istim vrijednostima kandidata za klju. (Na primjer za tip entiteta AUTOMOBIL, kandidat za klju je atribut REG_BROJ). Ukoliko jedan tip entiteta ima vie kandidata za klju, tada biramo jednog od njih i proglaavamo ga primarnim kljuem. (Npr. primarni klju za tip entiteta STUDENT mogao bi biti atribut BROJ INDEKSA). Pretpostavljamo da svaki skup entiteta ima barem jedan primarni klju. Skup entiteta istog tipa predstavlja se pravokutnikom. Atributi se oznaavaju ovalima. Imena atributa koji ine primarni klju se podcrtavaju. Podaci o domeni (skupu vrijednosti) pojedinih atributa ispisuju se uz ime atributa. (Domene vrijednosti esto se zbog jasnoe prikaza izostavljaju iz ER-dijagrama.)

    Slika 2.4. Skup entiteta Zaposlenici.

    2.3. Veze i skupovi veza Veza predstavlja odnos izmeu dva ili vie entiteta. Npr. entiteti ZAPOSLENIK i ODJEL vezani su na nain da zaposlenik Jure Juri radi u odjelu prodaje igraaka. Slino kao i kod entiteta sve sline veze izmeu slinih entiteta okupljamo u skup veza ili u tip veze. Skup veza ili tip veza sa slinim svojstvima predstavlja se rombovima.

    Skup veza moemo predoiti kao skup n-troki: nnn EeEeee ,...,,..., 111 Svaka n-torka oznaava vezu izmeu entiteta e1 do en, gdje je ei entitet iz skupa entiteta Ei.

  • FESB | Modeliranje podataka 31

    Na poetku ograniiti emo se na veze izmeu tono dva tipa entiteta. Skup veza moe takoer sadravati opisne atribute. Opisni atributi opisuju odnos izmeu entiteta a ne same entitete. Npr. zaposlenik Jure Juri radi u odjelu prodaje igraaka od sijenja 2002.

    Slika 2.5. skup veza RADI U Svaka veza mora biti jednoznano odreena entitetima koje povezuje, a ne atributima koji je opisuju tj. svaka veza opisuje se iskljuivo preko kljueva entiteta koje povezuje. Veze RADI_U skupova entiteta ZAPOSLENICI i ODJELI prikazane su na slici 2.6.

    Slika 2.6. Veze RADI_U skupova entiteta ZAPOSLENICI i ODJELI

    2.4. Funkcionalnost veza Naini na koji veza moe povezati primjerke entiteta odreeni su svojstvima funkcionalnosti, obaveznosti lanstva, odnosno kardinalnosti. Poznavanje tih svojstava vano je da bi se veza u iduoj fazi oblikovanja ispravno prikazala unutar relacijske sheme. Promatramo vezu izmeu tipova entiteta E1 i E2. Funkcionalnost te veze je svojstvo koje kae je li za odabrani primjerak entiteta jednog tipa mogue jednoznano odrediti povezani primjerak entiteta drugog tipa. Drugim rijeima, funkcionalnost je svojstvo koje kae moe li

  • FESB | Modeliranje podataka 32

    se veza interpretirati kao preslikavanje (funkcija) iz skupa primjeraka entiteta jednog tipa u skup primjeraka entiteta drugog tipa. Funkcionalnost veze moe biti: o Jedan-naprama-jedan (1 : 1) Jedan primjerak prvog tipa entiteta moe biti u vezi s najvie jednim primjerkom drugog tipa entiteta. Takoer jedan primjerak drugog tipa moe biti u vezi s najvie jednim primjerkom prvog tipa. Npr. veza JE PROELNIK izmeu skupova entiteta NASTAVNIK i ZAVOD (na fakultetu).

    Slika 2.7. Primjer veze 1:1, primjer veza JE PROELNIK izmeu skupova entiteta NASTAVNIK i ZAVOD

    o Jedan-naprama-mnogo (1 : N). Jedan primjerak prvog tipa entiteta moe biti u vezi s 0, 1 ili vie primjeraka drugog tipa entiteta, no jedan primjerak drugog tipa moe biti u vezi s najvie jednim primjerkom prvog tipa. Npr. veza PREDAJE izmeu tipova entiteta NASTAVNIK i KOLEGIJ (Slika 2.8).

    Slika 2.8. Primjer veze (1 : N).

  • FESB | Modeliranje podataka 33

    o Mnogo-naprama-mnogo (M : N). Jedan primjerak prvog tipa entiteta moe biti u vezi s 0, 1 ili vie primjeraka drugog tipa entiteta, te takoer jedan primjerak drugog tipa moe biti u vezi s 0, 1 ili vie primjeraka prvog tipa. Npr. veza UPISAO izmeu tipova entiteta STUDENT i KOLEGIJ (Slika 2.9).

    Slika 2.9. Primjer veze (M : N)

    2.5. lanstvo entiteta u vezama Ako svaki primjerak entiteta nekog tipa mora sudjelovati u zadanoj vezi, tada kaemo da taj tip entiteta ima obavezno lanstvo u toj vezi. Npr. izmeu tipova entiteta ISPIT i KOLEGIJ zadana je veza IZ , koja ima funkcionalnost (N : 1). ISPIT ima obavezno lanstvo u vezi IZ, jer svaki ispit mora biti iz nekog kolegija.

    Slika 2.10. Primjer obaveznog lanstva.

    lanstvo entiteta u vezi moe biti i neobavezno. Npr. izmeu tipova entiteta NASTAVNIK i KATEDRA zadana je veza RADI NA, koja ima funkcionalnost (N : 1).

  • FESB | Modeliranje podataka 34

    NASTAVNIK ima neobavezno lanstvo u vezi RADI NA jer svaki nastavnik ne mora raditi na nekoj katedri (barem je takvo stanje na FESB-u).

    Slika 2.11. Primjer neobaveznog lanstva. Obavezno lanstvo entiteta u nekoj vezi se mora istaknuti. Odluka da li je lanstvo obavezno ili neobavezno koji put je stvar dogovora odnosno projektantove odluke (npr. lanstvo za entitet KOLEGIJ u vezi PREDAJE).

    Slika 2.12. Postoje li KOLEGIJI koji ne predaje ni jedan NASTAVNIK?

    .

    2.6. Kardinalnost Svojstva funkcionalnosti i obaveznosti lanstva mogu se otprilike izraziti samo jednim svojstvom koje se zove kardinalnost. I dalje promatramo vezu izmeu tipova entiteta E1 i 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. To znai da za svaku vezu utvrujemo dvije kardinalnosti, za jedan i za drugi smjer.

  • FESB | Modeliranje podataka 35

    Kardinalnost je obino nemogue sasvim tono izraziti, pa umjesto tonog broja navodimo interval u obliku donje i gornje granice. Dvije granice oznaavaju se oznakama 0, 1 ili M, te se odvajaju zarezom. Uobiajene kardinalnosti u smjeru od tipa E1 do tipa E2 :

    Primjer: Veza JE PROELNIK promatrana u smjeru od NASTAVNIK do ZAVOD ima kardinalnost

    0,1. Kardinalnost iste veze promatrane u suprotnom smjeru je 1,1. Veza UPISAO u smjeru od PREDMET do STUDENT ima kardinalnost 0,M (doputamo da

    neki predmeti ostanu neupisani). Ako traimo od svakog studenta da upie bar jedan predmet: kardinalnost iste veze u

    suprotnom smjeru je 1,M.

    2.7. Prikaz ER-modela pomou dijagrama Obiaj je da se ER-dijagram nacrta kao dijagram u kojem pravokutnici predstavljaju tipove entiteta, a rombovi veze. Veze su povezane bridovima s odgovarajuim tipovima entiteta. Imena tipova entiteta i veza, te funkcionalnost veza, uneseni su u dijagram. Atributi se crtaju kao ovali s tim da se nazivi atributa koji ine klju podcrtavaju. esto se pak, atributi ne ucrtavaju na ER-dijagram nego se prilae posebna lista atributa za svaki entitet odnosno vezu. U toj listi moemo specificirati obaveznost lanstva u vezama. Kao primjer jednostavnog cjelovitog ER-dijagrama, pogledajmo dijagram na koji prikazuje bazu podataka o fakultetu (Slika 2.13). Tipovi entiteta su:

    ZAVOD, s atributima IME ZAVODA, ADRESA, . . . KOLEGIJ, s atributima BR KOLEGIJA, NASLOV, SEMESTAR, . . .

    STUDENT, s atributima BR INDEKSA, IME STUDENTA, ADRESA, SPOL, . . .

    NASTAVNIK, s atributima IME NASTAVNIKA (pretpostavljamo da je jedinstveno), BR SOBE, . ..

    Podvueni atributi ine primarni klju. Veze su:

    JE PROELNIK, bez atributa. ZAVOD ima obavezno lanstvo.

    JE U, bez atributa. NASTAVNIK ima obavezno lanstvo. NUDI, bez atributa. KOLEGIJ ima obavezno lanstvo.

    UPISAO, s atributom DATUM UPISA.

    PREDAJE, bez atributa. KOLEGIJ ima na primjer obavezno lanstvo.

  • FESB | Modeliranje podataka 36

    Slika 2.13. Baza podataka o fakultetu.

    Slika 2.14. ER-dijagram baze podataka o fakultetu (drugi pogled na deavanja na fakultetu).

  • FESB | Modeliranje podataka 37

    Slika 2.15. Trei nain za prikazivanje ER-dijagrama, primjer: ER-model za spremanje podataka o knjigama.

    2.8. Sloeni oblici u ER-modelima

    2.8.1. Slabi entiteti Slabi entiteti su entiteti koji nemaju pravog kljua (do sada smo podrazumijevali da unutar skupa entiteta mora postojati barem jedan klju). Npr. poduzee osigurava svoje zaposlenike. Svaki zaposlenik ima svoju policu osiguranja koja pokriva i osiguranje lanova njegove obitelji. Ako zaposlenik napusti poduzee, prestaje se uplaivati njegova polica osiguranja. Zapravo, polica osiguranja se brie iz baze podataka kao i svi lanovi porodice zaposlenika koji su preko nje bili osigurani. Za lanove porodice znamo samo ime lana i dob. Atribut ime ne odreuje jednoznano entitet LAN PORODICE. lanovi porodice su skup slabih entiteta. Jednoznanost slabog entiteta postie se kombiniranjem nekog od njegovih atributa sa kljuem nekog drugog entiteta.

    Slika 2.16. Primjer slabog entiteta

  • FESB | Modeliranje podataka 38

    Skup entiteta iz kojeg uzimamo primarni klju naziva se identificirajui vlasnik slabog entiteta (identifying owner). Moraju vrijediti slijedea ogranienja:

    Identificirajui vlasnik slabog entiteta vezuje se sa slabim entitetom vezom tipa (1:N). Ovakav skup veza naziva se identificirajui skup veza (identifying relationship set) slabog entiteta.

    Svi elementi slabog entiteta imaju obavezno lanstvo u identificirajuem skupu veza.

    2.8.2. Sloene veze u ER-modelima U stvarnim situacijama pojavljuju se i sloenije veze od onih koje smo do sada promatrali. Vanije sloene veze :

    a. Involuirana (ukljuujua) veza b. Pod-tipovi c. Ternarne veze d. Agregacija

    a) Involuirana veza

    Involuirana veza povezuje jedan tip entiteta s tim istim tipom. Dakle rije je o binarnom odnosu izmeu raznih primjeraka entiteta istog tipa. Funkcionalnost takve veze opet moe biti (1 : 1), (1: N), odnosno (M : N).

    Slika 2.17. Primjeri za involuirane veze

    Lijevi dijagram na slici 2.17. napravljen je pod pretpostavkom da su proli brakovi osobe zaboravljeni, a poligamija zabranjena. lanstvo u vezi JE U BRAKU SA je neobavezno. Desni dijagram na slici 2.17. se odnosi na proizvode se proizvode u nekoj tvornici. Pritom se jedan sloeniji PROIZVOD sastoji od vie jednostavnijih. Isti jednostavniji proizvod pojavljuje se u vie sloenih.

  • FESB | Modeliranje podataka 39

    Slika 2.18. Primjeri za involuirane veze

    Dijagram na slici 2.18. ima ucrtanu strelicu koja pokazuje smjer tumaenja veze JE EF ZA. Moemo uzeti da je lanstvo u toj vezi neobavezno, ako u realnom svijetu postoji barem jedan suradnik koji nema efa. Ovakva involuirana veza uvodi naelo subordinacije, jedan entitet je nadreen a drugi entitet je podreen.

    b) Pod-tipovi Tip entiteta E1 je podtip tipa entiteta E2 ako je svaki primjerak od E1 takoer i primjerak od E2. E1 nasljeuje sve atribute od E2, no E1 moe imati i dodatne atribute. Situaciju opisujemo pomou specijalne (1 : 1) veze JE (engleski IS A) koja se moe pojaviti vie puta unutar ER-sheme. Tip veze IS A crta se u ER-dijagramu kao trokut okrenut prema nadreenom tipu.

    Slika 2.19. Primjeri podtipova

  • FESB | Modeliranje podataka 40

    Slika 2.19. sadri primjer ER-sheme s pod-tipovima i nad-tipovima. Rije je o tipovima entiteta za osobe koje se pojavljuju na fakultetu. NASTAVNIK ukljuuje profesore, docente i asistente. Uz pojam podtipova vezana su dva tipa ogranienja:

    ogranienje preklapanja (Overlap constraints) razluuje da li se dva pod-tipa mogu sadravati isti entitet. Za podtipove student i nastavnik intuitivni odgovor je ne. Za podtipove student i pomono osoblje odgovor je da.

    ogranianje pokrivanja (Covering constraints) razluuje da li su svi entiteti iz nadtipa nalaze u pod-tipu. Za nad-tip osoba i pod-tip nastavnik intuitivni odgovor je ne. Za nad-tip nastavnik i pod-tip profesor intuitivni odgovor je da.

    Kada se koriste pod-tipovi? Dva su osnovna razloga zato koristimo podtipove i nad-tipove (specijalizaciju ili generalizaciju) : 1. Nekim entitetima elimo dodati posebne atribute (posebne atribute dodajemo u pod-

    tipovima) 2. elimo izdvojiti skup entiteta koji se uestvuje u nekoj vezi. Skup entiteta Motorna vozila

    uestvuje u vezi registriran na sa skupom entiteta osobe.

    c) Ternarne veze

    Ternarne veze uspostavljaju se izmeu tri tipa entiteta. Dakle, rije je o ternarnom odnosu izmeu primjeraka triju tipova entiteta. Postoje brojne mogunosti za funkcionalnost ternarne veze, na primjer (N : M : P), (1 : N : M), (1 : 1 : N) ili ak (1 : 1 : 1).

    Slika 2.20. Primjer ternarne veze

    Primjer ternarne veze (Slika 2.20): Podaci o kompanijama, proizvodima koje one proizvode i zemljama u koje one izvoze svoje proizvode. Funkcionalnost ove veze je mnogo-naprama-mnogo-naprama-mnogo, dakle (N : M : P), jer na primjer za zadani par (kompanija, proizvod) postoji mnogo zemalja u koje ta kompanija izvozi taj proizvod, itd.

  • FESB | Modeliranje podataka 41

    Ternarnu vezu uvodimo samo onda kad se ona ne moe rastaviti na dvije binarne. Uzmimo da u primjeru sa slike 2.21. vrijedi pravilo: ako kompanija izvozi u neku zemlju, tada ona izvozi sve svoje proizvode u tu zemlju.

    Slika 2.21. Primjer rastavljanja ternarne veze sa slike 2.20. na dvije binarne Uz ovo pravilo, razmatrana ternarna veza moe se zamijeniti s dvije binarne, u skladu s dijagramom na slici 2.21.

    d) Agregacija Do sada smo kazali da veze predstavljaju odnose izmeu dvaju skupova entiteta (s izuzetkom involviranih veza i ternarnih veza). Katkada trebamo uspostaviti vezu izmeu skupa entiteta i skupa veza.

    Slika 2.22. Primjer agregacije.

  • FESB | Modeliranje podataka 42

    Npr. neka kompanija sponzorira razliite projekte. Svaki pojedini projekt sponzorira jedan ili vie odjela te kompanije to je opisano skupom veza SPONZORIRA. Odjel koji sponzorira neki projekt imenuje nekog od zaposlenika da nadzire rad na projektu. Veza nadzire je odnos izmeu entiteta zaposlenik i veze sponzirira (Slika 2.22). Da bi ovo mogli ostvariti uvodimo novo svojstvo ER-modela, tzv. agregaciju (Aggregation). Kada se koristi agregacija? Uvijek kada imamo potrebu uspostaviti vezu sa nekom drugom postojeom vezom. (esto se agregacija moe nadomjestiti ternarnom vezom.)

  • FESB | Modeliranje podataka 43

    2.9. Konceptualni dizajn baze podataka primjenom ER-modela Modeliranje podataka primjenom metode ER obino nas dovodi do niza pitanja:

    da li neto modelirati kao entitet ili atribut ? da li neto modelirati kao entitet ili vezu ? koje su veze obavezne a koje nisu ? da li primijeniti binarne ili ternarne veze ? da li koristiti agregacije ?

    Odgovor na ova pitanja nije jednostavan i obino ovisi o konkretnom primjeru koji se rjeava. Npr. pogledajmo neto modificirani primjer skupa veza RADI U. Modifikacija se sastoji u tome da je dodan atribut do. Pamti se interval u kojem neki zaposlenik radi u odjelu. Ovisno o tome elimo li pamtiti sve periode u kojima je zaposlenik radio u nekom odjelu ili nas zanima samo zadnji period mijenjati e se i ER-model (Slika 2.23).

    Slika 2.23. Primjer ER modela.

    U sluaju da elimo pamtiti sve periode kada je zaposlenik radio u odjelu ER-model izgledati e kao na slici 2.24.

    Slika 2.24. Modificirani primjer ER modela.

  • FESB | Modeliranje podataka 44

    2.10. Kako najjednostavnije do modela podataka? Modeliranje podataka nije jednostavan zadatak. Obino se podaci modeliraju kroz vie iteracija. Ipak najednostavniji pristup je za poetak sloiti vrlo jednostavnu priu kroz koju emo pokuati opisati realni sustav koji elimo modelirati. Primjer: natjecanje u Formuli 1. Pria glasi: svake godine odrava se natjecanje (prvenstvo) u Formuli 1. Natjecanje se sastoji od vie utrka. Utrke se voze na trkakim stazama. Na utrci se nastupaju vozai u bolidima. Bolide konstruiraju timovi. Ponoviti emo priu ali tako da u crveno obojimo imenice a u plavo glagole: Svake godine odrava se natjecanje (prvenstvo) u Formuli 1. Natjecanje se sastoji od vie utrka. Utrke se voze na trkakim stazama. Na utrci nastupaju vozai u bolidima. Bolide konstruiraju timovi. Oito emo u naem modelu imati entitete: godinje natjecanje, utrka, trkaka staza, voza, bolid i tim.

    Slika 2.25. Kandidati za tipove entiteta.

    Izmeu tipova entiteta potrebno je ucrtati odgovarajue veze.Kada je i to gotovo treba odrediti atribute entiteta i veza, funkcionalnost veza, obaveznost uestvovanja pojedinih entiteta, uoiti eventualne podtipove itd. (Slika 2.26).

  • FESB | Modeliranje podataka 45

    Slika 2.26. ER model natjecanja u Formuli 1.

    Ovaj postupak ne osigurava valjanost modela podataka. Ovo je samo nain da stvorite poetnu sliku o realnom sistemu koji modelirate na temelju koje e vam se otvoriti mnogo pitanja na koja tek treba odgovoriti. Slijedi niz razgovora, traenja odgovora na pitanja koja vas mue. Nakon toga vraate se na model i popravljate ga. Otvaraju se nova pitanja, novi razgovori, ponovno povratak na model podataka. Postupak traje dok se ne raiste sva pitanja koja vas mue i dok ne zakljuite da model podataka dobro opisuje to se dogaa u realnom sustavu (ili barem u onom njegovom dijelu koji nas zanima).

    2.11. Zakljuak ER model dovoljno je jednostavan da ga ljudi razliitih struka mogu razumjeti. Zato ER-dijagram slui za komunikaciju projektanta baze podataka i korisnika, i to u najranijoj fazi razvoja baze. Postojei DBMS ne mogu direktno implementirati ER-dijagram, ve zahtijevaju da se ona detaljnije razradi, te modificira u skladu s pravilima izabranog modela baze podataka (relacijskog, mrenog, odnosno hijerarhijskog modela.

  • FESB | Relacijski model 46

    3. Relacijski model Teorijske osnove relacijskog modela postavljene su jo krajem 60-tih godina 20. stoljea, u radovima E.F. Codd-a (IBM-ovi istraivaki centar). Model se dugo pojavljivao samo u akademskim raspravama i knjigama. Prve realizacije na raunalu bile su suvie spore i neefikasne. Zahvaljujui intenzivnom istraivanju, te napretku samih raunala, efikasnost relacijskih baza postepeno se poboljavala te je sredinom 80-tih godina 20. stoljea relacijski model postao prevladavajui.

    3.1. Struktura relacijskog modela

    3.1.1. Kartezijev produkt Neka je zadan niz skupova D1, D2, ... , Dn (koji nisu nuno razliiti). Kartezijev produkt ovih n skupova D1 x D2 x ... x Dn je skup svih moguih ureenih n-torki , tako da je d1D1, d2 D2, ..., dn Dn. Npr. Kartezijev produkt skupova A = {1, 2, 3, 4} i B = {4, 6, 8} A x B = {,,,,,,,,,,,}.

    3.1.2. Relacija Relacija definirana na n skupova je podskup Kartezijevog produkta tih n skupova. R D1 x D2 x ... x Dn

    Podskup sadri one n-torke Kartezijevog produkta koje zadovoljavaju zadatu relaciju. Npr. neka je na skupovima A = {1, 2, 3, 4} i B = {4, 6, 8} zadana relacija

    2/,: babaAxBR Relacija R u tom sluaju sadri ureene n-torke: R = {, , } Skupovi D1, D2, ..., Dn se nazivaju domenama relacije R. Broj domena na kojima je definirana neka relacija se naziva stupanj relacije. Razlikujemo unarne (na jednoj domeni), binarne (na dvije domene) i openito n-arne relacije (na n domena). Kardinalnost relacije je broj n-torki u relaciji. Kako je Kartezijev produkt skup ureenih n-torki, redoslijed elemenata u jednoj n-torki je bitan. Npr., ako na domenama I1 = {001, 007, 035}, I2 = {Marko, Ana}, I3 = {19, 22} definiramo relaciju R

    22,,035,19,,007,19,,001321 AnaAnaMarkoxIxIIR u njoj je bitno da prvi element trojke uzima vrijednost iz prvog, drugi iz drugog, a trei iz treeg skupa.

  • FESB | Relacijski model 47

    Ako vrijednostima elemenata u n-torkama pridruimo imena domena (semantika, da bismo interpretirali odgovarajue podatke, dajui sa istim ciljem i ime relaciji), moemo uiniti redoslijed elemenata u n-torkama beznaajnim. Primjer:

    AnaIMESTAROSTINDEXBRSTAROSTINDEXBRAnaIME

    STAROSTMarkoIMEINDEXBRSTAROSTINDEXxIMExBRSTUDENT

    :,22:,035:_,19:,007:_,:

    ,19:,:,001:__

    3.1.3. Atribut relacije Imenovana domena, sa imenom koje definira ulogu domene u relaciji se naziva atribut relacije. Atributi relacije STUDENT su BR_INDEX, IME i STAROST.Koncept atributa omoguuje predstavljanje relacije kao tablice. Relacija STUDENT se moe predstaviti sa:

    Relacija je ureeni skup, a tablica openito nije. Da bi tablica bila relacija moraju biti zadovoljeni slijedei uvjeti:

    1. Ne postoje dva identina retka u tablici 2. Nije vaan redoslijed redaka u tablici (ukoliko bilo koja dva retka zamijene mjesto

    nee se promijeniti semantika tablice) 3. Nije vaan redoslijed stupaca u tablici (ukoliko bilo koja dva stupca zamijene mjesto

    nee se promijeniti semantika tablice) Pored toga, da bi se mogao definirati jednostavan skup operacija nad relacijama, mora vrijediti i slijedei uvjet:

    4. Sve vrijednosti atributa u relacijama su atomske tj. nisu dozvoljeni atributi ili grupe atributa "sa ponavljanjem", odnosno nije dozvoljeno da vrijednosti nekih atributa u relaciji budu relacije (nisu dozvoljene "tablice u tablici").

    Ako relacija zadovoljava uvjet 4. tada je ona u Prvoj normalnoj formi. Svaka relacija u relacijskom modelu mora biti u prvoj normalnoj formi. Termin "normalizirana relacija" se koristi za relacije u prvoj normalnoj formi (Za ostale normalne forme mora se precizirati o kojoj normalnoj formi se radi). Primjer: Relacija (tablica) STUD_ISP, zapisana u slijedeem obliku, nije normalizirana, jer su NAZ_KOLEGIJA i OCJENA "grupa sa ponavljanjem"

  • FESB | Relacijski model 48

    Relacija STUD_ISP se moe dovesti u prvu normalnu formu (uvodei redundanciju podataka) na slijedei nain:

    3.2. Kljuevi injenica da su sve n-torke u relaciji razliite, govori da postoji jedan atribut ili vie atributa zajedno (u krajnjem sluaju svi atributi zajedno) ije vrijednosti jednoznano identificiraju jednu n-torku u relaciji (jednu redak u tablici). Taj atribut ili ta grupa atributa koji jednoznano identificiraju jednu n-torku u relaciji se nazivaju kljuem relacije (jedan atribut - jednostavni (prosti) klju, grupa atributa - sloen klju). Npr. u relaciji STUDENT, klju je BR_INDEX (prosti klju), dok je u relaciji STUD_ISP klju grupa BR_INDEX, NAZI_KOLEGIJA (sloen klju). Klju relacije se stroe definira na slijedei nain: Klju relacije R je takva kolekcija K njenih atributa koja zadovoljava slijedea dva uvjeta:

    1. Osobina jedinstvenosti: Ne postoje bilo koje dvije n-torke sa istom vrijednou K 2. Osobina neredundantnosti: Ako se bilo koji atribut izostavi iz K, gubi se osobina

    jedinstvenosti.

    Kolekcija atributa K koja zadovoljava samo osobinu jedinstvenosti naziva se nadklju relacije. U jednoj relaciji moe postojati vie razliitih kolekcija K atributa koje zadovoljavaju uvjete za definiciju kljua. (Npr., ako u relaciju STUDENT dodamo atribut JMBG - jedinstveni matini broj graana, i on e, pored BR_INDEX, zadovoljavati definiciju kljua). Sve takve kolekcije se nazivaju kandidati za klju. Jedan od kandidata koji se izabere da praktino slui za identifikaciju n-torke relacije se tada naziva primarni klju. Ostali (neizabrani) kandidati se tada nazivaju alternativnim kljuevima.

  • FESB | Relacijski model 49

    Atributi koji uestvuju u kljuevima (koji su dio kandidata za klju) nazivaju se kljunim atributima. Ostali atributi u relaciji su nekljuni (ili sporedni) atributi. Strani klju je atribut (ili grupa atributa) u relaciji R1 ija se vrijednost koristi za povezivanje sa vrijednou primarnog kljua u nekoj relaciji R2. Strani klju i njemu odgovarajui primarni klju moraju biti definirani nad istom domenom. Strani kljuevi slue da se uspostave veze izmeu relacija u relacijskoj bazi podataka. Npr., u relaciji STUD_ISP, BR_INDEX je strani klju, preko kojeg se ova relacija moe povezati sa relacijom STUDENT. Relacijska baza podataka je kolekcija vremenski promjenjivih relacija. Bazna (osnovna) relacija je relacija koja se ne moe izvesti iz ostalih relacija u relacijskoj bazi podataka. Izvedena relacija (pogled) je relacija koja se moe izvesti iz skupa danih baznih i izvedenih relacija, preko operacija koje se definiraju nad relacijama.

    3.3. Shema baze podataka i baza podataka Ekstenzija relacije je skup svih n-torki dane relacije, odnosno predstavljanje tablice navoenjem svih redaka. Tablica STUDENT i normalizirana tablica STUD_ISP predstavljaju ekstenzije odgovarajuih relacija. Intenzija relacije je generalizacija ekstenzije, ona je vremenski nepromjenljiva i oznaava se na slijedei nain: STUDENT (BR_INDEX, IME, STAROST ) STUD_ISP (BR_INDEX, NAZ_KOLEGIJA, IME, OCJENA) (Ispred zagrade je naziv relacije, u zagradi su navedeni atributi, a primarni klju podcrtan). Shema relacijske baze podataka je predstavljanje strukture relacijske baze podataka kao skupa intenzija relacija. Npr. pogledajmo prikaz sheme baze podataka i samu bazu podataka za jednu proizvodnu organizaciju: SHEMA BAZE PODATAKA RADNIK (RAD_ID, JMBG, IME, MJESTO_RO, RAD_STA, ORGJED_ID) ORG_JEDINICA (ORGJED_ID, NAZIV, MJESTO) PROJEKT (PROJ_ID, NAZIVPR, VODI_ID) ZADATAK (PROJ_ID, BRZAD, OPISZAD) RASPORED (RAD_ID, PROJ_ID, BRZAD, RAD_SATI ) DAKTILOGRAF(RAD_ID, KLASA) (Atribut VODI_ID je definiran nad istom domenom kao i RAD_ID, ili drugim rijeima u relaciji PROJEKT atribut RAD_ID imao bi ulogu da definira ifru voditelja projekta, pa zato i nosi ime VODI_ID).

  • FESB | Relacijski model 50

    BAZA PODATAKA RADNIK

    ORG_JEDINICA

    PROJEKT

    ZADATAK

    RASPORED

  • FESB | Relacijski model 51

    DAKTILOGRAF

    3.4. Nula (null) vrijednosti Termin "nula vrijednost" (eng. null value, koji emo obiljeavati sa ?) se koristi da oznai "jo nepoznatu vrijednost" za neki atribut ili "neprimjenjivo svojstvo" za neki entitete(objekt) ili vezu koje predstavlja tablica. Npr., u relaciji RADNIK radnik sa RAD_ID = r7 je za atribut MJESTO_RO "nula vrijednost" (?) jer je njegovo mjesto roenja "jo nepoznato" i odgovarajui podatak e se upisati u bazu podataka kada se sazna. Pretpostavimo da smo, umjesto da imamo posebnu relaciju DAKTILOGRAF, proirili relaciju RADNIK za atribut KLASA. Tada bi svi radnici, osim radnika r2 i r5 imali za vrijednost atributa KLASA nula vrijednost, jer je taj atribut "neprimjenjivo svojstvo" za sve druge radnike, zato to oni nisu daktilografi.

    3.5. Ekvivalentnost naziva Relacija se predstavlja kao tablica. U komercijalnim DBMS, umjesto "mat