Baze Podataka

dr Pavle Kalu eri
dr Slobodan Obradovi
Baze podataka
Beograd 2007
Autori: Recenzenti: Izdava: Lektor Korice: Prelom: Tira: tampa:
dr Pavle Kalu eri dr Slobodan Obradovi dr Dragoslav Peri dr Petar Bonjakovi Via elektrotehnika kola u Beogradu An elka Kovaevi Kuk Kristijan i Dimi Gabrijela ? dr Slobodan Obradovi 200 Akademska tampa, Zemun
CIP Katalogizacija u publikaciji Narodna biblioteka Srbije, Beograd 004.652.4(075.8) ? ISBN 86 82589 66 4 ? Kalu eri, Pavle Baze podataka Pavle Kalu eri Slobodan Obradovi. Beograd : Via elektrotehnika kola, 2007. III, 209 str. graf. prikazi ; 24 cm ? Tira 200. Bibliografija: str 199-200. Registar. ISBN 86-82589-66-4 1. Obradovi, Slobodan a) Relacione baze podataka b) COBISS-ID 101187340
Predgovor etvrtom izdanju

U posljednjih deset godina, u etiri prethodna izdanja knjige Projektovanje informacionih sistema - relacione baze podataka bilo je mnogo izmjena zbog promjena koje su se deavale na tritu kako hardvera tako i softvera ove danas vrlo propulzivne oblasti. Odluili smo stoga napisati, nov i savremen tekst novi udbenik pod naslovom Baze podataka. Udbenik Baze podataka ima teite na sintezi i eksploataciji relacionih baza podataka. Oblast projektovanja informacionih sistema je samo kratko dotaknuta u mjeri koliko je potrebno da bi se neka baza podataka uspjeno mogla inkorporirati u informacioni sistem. Primjena raunara u informacionim tehnologijama na naim prostorima je dominantna i iroko rasprostranjena. Ve i najmanja privatna firma, prodavnica, kola, apoteka ili ugostiteljski objekat, ako ele da budu konkurentni, moraju svoje poslovanje da prepuste raunaru. Na osnovni cilj bio je stoga da omoguimo studentu da stekne praktino znanje o projektovanju informacionih sistema, te organizaciji i eksploataciji relacionih baza podataka kako bi to mogao odmah u praksi i da primjeni. Nismo se uputali u ozbiljna teorijska razmatranja. Primjeri u knjizi su jednostavni i mogu da poslue kao dobar kostur za nadgradnju nekog realnog sistema. Za vjebe iz ovoga predmeta, na kojima svaki student u toku studija treba da projektuje i eksploatie svoju malu bazu podataka, tampan je poseban Prirunik grupe autora na elu sa dr Slobodanom Obradoviem koji sa ovim udbenikom predstavlja zaokruenu cjelinu. Student koji uspjeno savlada materiju iz ove knjige nadamo se da je dobio sliku o projektovanju i upotrebi relacionih baza podataka, a inenjeru u praksi ova knjiga moe korisno da poslui kao prvi korak koji ga uvodi u tajne ove oblasti. U Beogradu, u jesen 2007. godine autori
Projektovanje informacionih sistema
Predgovor Sadraj
I DIO - SINTEZA LOGIKOG MODELA

1. Uvodna razmatranja
1.1 Pojam podatka 1.2 Objekat posmatranja - entitet 1.3 Model podataka 1.3.1 Hijerarhijski model 1.3.2 Mreni model 1.3.3 Relacioni model
1
3 4 8 9 14 15
2. Relacioni model
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 Pojam relacije Entitet Atribut Domen Primarni klju Spoljnji klju Coddova pravila Distribuirane baze podataka
17
18 20 20 21 21 22 23 26
3. Osnove relacione algebre

3.1 Tradicionalni operatori pogodni za auriranje 3.1.1 Unija 3.1.2 Presjek 3.1.3 Razlika 3.1.4 Proizvod 3.2 Specijalni operatori pogodni za izvjetavanje 3.2.1 Selekcija 3.2.2 Projekcija 3.2.3 Spajanje (Join) 3.2.4 Operacija dijeljenja 3.3 Dodatni operatori
29
29 30 31 31 31 32 32 33 33 34 35
Relacione baze podataka
II
4. Sinteza relacionog modela

5.1 E-R model 5.1.1 Osnovne definicije i pojmovi E-R modela 5.1.2 Objekti 5.1.3 Veze ili vezni objekti 5.2 Prevo enje ER-modela na relacioni oblik 5.2.1 Prevo enje binarnih veza na relacioni oblik 5.2.2 Prevo enje unarnih veza na relacioni oblik 5.2.3 Prevo enje veza reda veeg od dva 5.3 Normalizacija 5.3.1 Prva, druga i trea normalna forma 5.3.2 Problem gubitka informacija 5.3.3 Ostale normalne forme 5.3.4 Primjeri normalizacije
89
90 90 90 93 101 102 104 105 107 111 114 114 115
5. Osnove projektovanja
7.1 7.2 7.3 7.4 7.5 7.6 Prikupljanje informacija Izrada modela Analiza postojeeg sistema Projektovanje novog sistema Realizacija sistema Vo enje i vrednovanje projekta
159
160 164 165 165 169 171
II DIO - SINTEZA FIZIKOG MODELA

6. SQL
4.1 Naredbe za definisanje podataka 4.1.1 Izmjena vrijednosti atributa, dodavanje novog atributa u postojeu tabelu - ALTER TABLE 4.1.2 Izbacivanje relacije iz baze podataka - DROP TABLE 4.1.3 Indeksi 4.2 Naredbe za rukovanje podacima 4.2.1 Upiti nad jednom tabelom Klauzula WHERE Klauzula ORDER BY Upotreba NULL vrijednosti Klauzula GROUP BY
37
42 46 46 47 50 53 55 58 60 61
III
62 65 73 76 78 82 84
4.2.2 Upiti nad jednom tabelom 4.2.3 Ugnjedeni upiti i spajanje relacija 4.2.4 Auriranje baze podataka 4.3 Kreiranje i korienje pogleda (VIEW) 4.4 Upravljake naredbe 4.5 Aplikativni programi 4.6 Primjer razvoja aplikacije
7. MS ACCESS
6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 Osnovne karakteristike MS Accessa Kreiranje nove baze podataka Kreiranje upita Kreiranje obrazaca Izvjetaji Makroi Moduli Aplikacije i MDE datoteke Rad u mrenom okruenju Povezivanje sa MS Office-om
119
120 122 129 133 139 144 145 147 150 154
8. Primjeri
8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 Informacioni sistem sekretarijata za saobraaj Dio informacionog sistema advokatske kancelarije Informacioni sistem sportskog saveza Informacioni sistem kolske biblioteke Dio informacionog sistema studentske slube Dio informacionog sistema klinikog centra Informacioni sistem video kluba Dio informacionog sistema lanca robnih kua Informacioni sistem sportskog takmienja Primjer razvoja aplikacije u dBase IV Primjer razvoja aplikacije Accessu
173
173 174 175 179 183 184 186 188 189 194
Zadaci Literatura Indeks
206 199 207
Logiki modeli informacionih sistema
Glava 1
1.0 Uvod
Obrada podataka, pored numerikih prorauna, bila je i ostala sve do danas jedna od najvanijih oblasti primjene elektronskih raunara. Istina, ljudi su i mnogo prije nego to su raspolagali raunarima, praktino od onda kada su postali svjesna bia i shvatili da nisu besmrtni, nastojali da ostave "pisane" tragove, neke "podatke", kako bi sljedeim generacijama ostao bilo kakav zapis o njima. Prvi problem sa kojim se ovjek, u elji da iza njega neto ostane, susreo, bio je nepostojanje pisma. Peinski ovjek je ostavljao tragove crteima na zidovima peina u kojima su ivjeli (Altamira, Zavala, itd.). Sa pojavom prvog pisma, u poetku veoma komplikovanog (klinasto pismo, hijeroglifi), "poruke" su se ostavljale na kamenim ploama (nadgrobni spomenici, 10 Boijih zapovjesti,..) jer je za arhiviranje podataka nedostajao pogodan memorijski medijum.
Osjetan napredak u tehnici arhiviranja nastupio je kada su se kao "memorijski medijum" poele koristiti posebno pripremljene koe ivotinja, a pronalazak papirusa i pergamenta bio je prvi veliki korak naprijed. Konano, pronalaskom papira, i tehnike tampe, izgledalo je da je problem memorisanja i arhiviranja podataka u potpunosti i definitivno uspjeno rijeen. Me utim, ubrzo se poeo poveavati broj arhiviranih podataka pa se pojavio novi problem organizacija podataka u arhivama i uvanje papirnih dokumenata. Pri tome, broj papirnih dokumenata rastao je vrlo brzo to je stvorilo novi, dodatni, problem - problem obrade podataka to jest njihova efikasna eksploatacija s obzirom na teak pristup konkretnim podacima u papirnim arhivama. Pronalaenje podatka, u velikim arhivama je mukotrpan i dugotrajan posao, pa je mogunost pore enja i obrade vie podataka u svrhu dobijanja novih informacija ograniena neki puta i ljudskim vijekom istraivaa. Tako su pojedinci provodili itav radni vijek kopajui po pranjavim arhivama za podacima kojima bi potvrdili ili opovrgli neke njihove stavove ili teorije. Sa kakvim problemima se suoavamo kada iz tako, na papiru, arhiviranih podataka treba dobiti neku informaciju, najbolje ilustruje jedan jednostavan primjer:
Pretpostavimo da rektor nekog univerziteta sa dugogodinjom tradicijom hoe da sazna ime studenta koji je na tom univerzitetu, od njegovog osnivanja, kao najmla i zavrio studije, u najkraem roku, a sa najveom prosjenom ocjenom. Pod pretpostavkom da u arhivi univerziteta postoje pisani tragovi o svim studentima koji su studirali na tom univerzitetu. do traene informacije moe se doi ako se pregledaju svi studentski dosijei i za svakog studenta: zapie datum ro enja zapie datum upisa na fakultet, zapie datum diplomiranja,
izrauna vrijeme studiranja izrauna starost studenta izrauna srednja ocjena, Nakon toga treba: pore ati studente po duini studentskog staa, pore ati studente po visini srednje ocjene pore ati studente po starosti, i konano nai me u njima onoga najmla eg koji ja za najkrae vrijeme postigao najbolji uspjeh. Nije potrebno podrobno objanjavati koji je, i koliki je, to posao ako se mora obaviti runo za veliki broj studenata.
Problem obrade i eksploatacije velikog broja podataka rijeen je efikasno tek pojavom digitalnog raunara i odgovarajue magnetne, odnosno elektronske, memorije u drugoj polovici XX vijeka. Paralelno sa brzim razvojem raunarskog hardvera u posljednjih 30 godina, (prije svega pojavom monih personalnih raunara), korisnici su postajali sve zahtjevniji i u pogledu softvera koji bi im omoguio jednostavan, brz i efikasan pristup te obradu velikog broja podataka. U tu svrhu raunari su se poeli povezivati u lokalne, a zatim i, globalne, fleksibilne mree, koje omoguavaju brz pristup i efikasnu obradu velikog broja razliitih podataka lociranih na raznim mjestima, a to je do nedavno bila privilegija samo velikih raunskih centara. Prvi modeli za organizaciju, memorisanje, manipulaciju i obradu podataka u tada jo skromnim bazama podataka pojavili su se ezdesetih godina XX vijeka. U centru ovih modela nalaze se dva pojma, pojam: podatka, i informacije. Definiimo stoga ta se danas podrazumijeva pod tim pojmovima.
1.1
Osnovni pojmovi
Pod pojmovima podatak i informacija, u strunoj literaturi, danas se podrazumijeva:

podatak je iskaz definisan jednom prostom izjavnom reenicom, informacija je novi podatak koji posjeduje relevantnu novinu, neko novo saznanje, a rezultat je obrade poznatih podataka.
Dobijanje nove, relevantne informacije je nemogue bez posjedovanja odgovarajuih kljunih podataka koji je definiu. Ako nemamo mogunosti da ih saznamo, osu eni smo na neuspjeh.
I mi u svakodnevnom ivotu koristimo podatke - eksploatiemo nae kune baze podataka, kako bismo mogli uspjeno da rijeimo nae ivotne probleme. Na primjer, ako u gradu u trgovinama vlada nestaica nekog artikla, ukoliko ne dobijemo pravovremeno pouzdan podatak gdje i kada e se on moi nabaviti, ostaemo bez informacije gdje se moe nabaviti, a to znai i bez njega.
Odnos podatka, obrade podataka i nove informacije vidi se na sljedeem primjeru - ocjenjivanju uenika u koli.
Podaci su ocjene iz pojedinih predmeta ( na primjer: biologija-5, matematika-5, fizika-4, maternji jezik-5, strani jezik-4, itd.). Obradom, izraunavanjem srednje vrijednosti, dobija se prosjena ocjena svakog uenika (4,6) to je nova informacija, novo saznanje, novi podatak, koji se ne moe saznati bez obrade prethodno poznatih podataka. Na kraju, na bazi ove nove informacije dolazimo i do novog saznanja podatka kakav je uspjeh postigao neki uenik.
Postupak obrade podataka (slika 1.1), dobijanja novih informacija i sticanja novih saznanja, moe se na osnovu svega do sada reenog podeliti u etiri faze:
podatak-1 obrada podataka informacija
podatak-2
podatak-n
Slika 1.1 Dobijanje nove informacije iz niza poznatih podataka prikupljanje podataka, memorisanje i organizacija prikupljenih podataka, obrada podataka (raunanje, sortiranje, grupisanje itd.), dobijanje novih informacija - sticanje novih saznanja.
1.2
Objekat posmatranja - entitet
Podaci koje sakupljamo, memoriemo, organizujemo i obra ujemo nalaze se u svijetu oko nas i vezani su za neki proces koji se odvija u dijelu realnog svijeta iz naeg okruenja, dijelu koji elimo da blie upoznamo na osnovu podataka iz njega. Proces po definiciji predstavlja promjenu jedne ili vie veliina u vremenu (na primjer: promjena temperature vazduha, kretanje nataliteta u nekom regionu, varijacija bruto nacionalnog dohotka, promjena optereenosti elektroenergetskog sistema, itd.). Podaci kojima se opisuje proces (koji je kontinualan u vremenu) su diskretne veliine (poznajemo ih samo u odre enim vremenskim trenucima) pa je postupak analize i praenja procesa preko podataka neka vrste analogno-digitalne (A/D) konverzije. Iz diskretne baze podataka nova informacija dobija se obradom diskretnih podataka pa je i nova informacija diskretna veliina.
Da bismo izveli pomenutu A/D konverziju, i kontinualni proces opisali ogranienim brojem diskretnih podataka, prisiljeni smo da definiemo nae vi enje za nas interesantnog dijela realnog svijeta. Dobijeni rezultat naziva se kratko model-objekat, entitet, ili samo objekat. Svojstva objekata opisuju se preko atributa (koje moramo odabrati u fazi modelovanja objekta) a skup dozvoljenih vrijednosti koje neki atribut moe uzeti naziva se domen.
Na primjer, objekat UENIK opisuje se atributima ocjenama iji domen je skup prirodnih brojeva od jedan (1) do pet (5)
Broj atributa (n) koji su od znaaja za opis nekog entiteta zavisi od procesa i obrade podataka koju treba obaviti. Koji su to relevantni atributi kojima e se opisati neki entitet u svakom konkretnom sluaju mora da definie kompetentna osoba, jer e od toga zavisiti upotrebljivost i vjerodostojnost obradom dobijenih informacija. Ako odaberemo premalo atributa, ili atribute koji nisu relevantni za taj proces, model e biti jednostavan za obradu i analizu, ali e mu vjerodostojnost biti mala, pa e i broj korisnih i upotrebljivih informacija koje on moe da prezentira biti ogranien, ili ih uopte nee ni biti. A ako se model opie pretjerano velikim brojem atributa, njegovoj vjerodostojnosti se nee moi prigovoriti, ali manipulacija podacima postaje teka - a dobijene informacije najee konfuzne. Prema tome: prepoznavanje mjere pri modelovanju procesa (pri izboru broja atributa) jedan je od osnovnih zadataka projektanta informacionog sistema.
Ako je, na primjer, predmet naeg interesovanja lan radnog kolektiva posmatran sa aspekta linog dohotka, onda atribut broj cipela nije relevantan. Me utim, ako nam je potrebna informacija za nabavku HTZ opreme koju ta firma nabavlja za svoje radnike, onda su broj cipela i veliina radnog odijela i te kako vani podaci.
Entitet ili objekat, po prirodi moe biti veoma razliit kao na primjer:
dio okruenja (lan kolektiva, aparat, zgrada..) apstraktni pojam (neka mjera, neije zvanje, boja,..) doga aj (udes, postupak upisa studenata,...) asocijacija (polaznik-kurs, predmet-nastavnik,) itd.
Kako je proces po definiciji dinamika kategorija (njegovi pokazatelji se mijenjaju u vremenu) to se i podaci kojima se proces opisuje moraju aurirati, odnosno "osvjeavati" u vremenu. Kada, kako esto, i ko e aurirati podatke sljedei je vaan faktor u projektovanju informacionog sistema pa i to mora biti precizno definisano. Veliine koje se ne mijenjaju u vremenu kao to su; broj , ubrzanje zemljine tee g, dielektrina konstanta vakuma 0 i tome slino dovoljno poznavati samo jedanput. Posmatrajmo postupak modelovanja objekta na jednom jednostavnom primjeru:
Pretpostavimo da u sektoru za urbanizam neke optine ele da imaju informacije o ulicama u toj optini. Entitet (objekat), je prema tome ULICA, a relevantni atributi kojima se opisuje ulica mogli bi biti: naziv, duina, irina, vrsta kolovoza, godina izgradnje, broj kua dok podatak o promjeni temperature asfalta u toku godine, u ovome sluaju, neemo smatrati relevantnim. Entitet ULICA definisan preko atributa moemo predstaviti kao: ULICA < naziv, duina, irina, vrsta_kol., god_ izg., broj_kua > Za svaku ulicu vrijednosti nabrojanih atributa, dakle podaci kojima se jedna ulica poblie opisuje, su razliiti, a mogu se vremenom i promijeniti (na primjer: promjena naziva ulice, duine, broja kua itd.) to zahtijeva pomenuto, povremeno, osvjeavanje podataka.
10
Veliina, odnosno duina, tabele u kojoj e se nalaziti podaci o svim ulicama u optini zavisi od broja ulica pa je broj redova u tabeli, broj takozvanih slogova, ili n-torki, jednak broju ulica u toj optini. Na primjer: ULICA
Naziv
Sime Milutinovia Jove Jovanovia Vuka Karadia Zeke Buljubae
Duina irina (km) (m)

0.56 0.20 1.75 0.08 12.3 7.5 6.00 5.50
Vrsta kolovoza
asfalt granitne kocke asfalt kaldrma
Godina izgradnje
1908 1898 1864 1888
Broj kua
231 56 442 12
Slika 1.2 Primjer tabele ULICA
Izgradnjom nove ulice, njeni podaci se onda samo dopisuju u ve postojei spisak, u postojeu tabelu. Prema tome; svaka tabela mora da ima definisano:
ime ili naziv tabele, spisak atributa i niz vrijednosti atributa, to jest podatke.
Da rezimiramo; tabela se sastoji od polja u koja se upisuju podaci. Slaganjem polja u jednome redu tabele dobijamo jedan: slog, red, ili n-torku, a skup svih redova (slogova), svih n-torki neke tabele ini: tijelo tabele kao to je to prikazano na slici 1.3. Neka druga tabela, u istom sektoru pomenute optine, moe da sadri podatke o nekom drugom entitetu - objektu, na primjer, stambenim zgradama u toj optini. Nazovimo tu tabelu ZGRADA, a skup za nju relevantnih atributa mogao bi biti:
ZGRADA < ulica, kuni_br., god_izg., br_sprat., br_stanova, itd. .>
U tabeli (Umjesto termina TABELA neki autori koriste termin DATOTEKA a esto, posebno u literaturi o relacionim bazama podataka, uz jo neka ogranienja, i termin RELACIJA) ZGRADA ulica je atribut, dok je u
11
prethodnom primjeru tabela imala taj naziv. Naziv atributa u jednoj tabeli moe prema tome biti naziv neke druge tabele. Izbor imena atributa i tabela je proizvoljan a diktiran je prije svega naim eljama, interesima i pogledima koje na realni svijet hoemo da bacimo preko podataka koje posjedujemo, odnosno koje informacije oekujemo da iz njih moemo dobiti.
naziv tabele atribut1 atribut2 atribut3 atribut4 atribut5 polje n-torka
Tijelo tabele
{
Slika 1.3 Elementi tabele
Preporuuje se da ime tabela kao i atributa treba da asociraju na prirodu procesa koji se u toj tabeli prati podacima. Korienje istih naziva treba u principu izbjegavati jer to najee dovodi do greaka koje se tek kasnije u toku rada otkrivaju. Kod izbora imena atributa posebno treba biti obazriv, jer osnovno pravilo kae da: atribut mora biti tako odabran (definisan) da se moe iskazati samo jednom izrinom reenicom, to jest definisati samo jednim elementarnim (atomarnim) podatkom. Ako je za opis atributa potrebno vie podataka, onda nije vie u pitanju atribut, nego po svoj prilici novi entitet sa svojim atributima.
Tako u navedenim primjerima, kada je od interesa bio entitet - stambena ZGRADA - naziv ulice u kojoj se ta zgrada nalazi je u tabeli ZGRADA atribut za koji postoji atomaran podatak naziv te ulice. Ali ako nam pored naziva ulice treba jo podataka o ulici (na primjer, duina, irina, itd.) ULICA postaje novi objekat entitet sa svojim atributima a atribut "naziv ulice" u tabeli ZGRADA treba brisati.
12
U toku eksploatacije pomenutih podataka o ulicama i zgradama moe se ukazati potreba da jednovremeno posmatramo i ULICE i ZGRADE. Pristup rjeavanju problema se tada komplikuje. U tom sluaju se od tih dvaju tabela, koje su oigledno u prirodi me usobno povezane (jer zgrade se nalaze u ulicama), formira baza podataka odnosno informacioni sistem koji mora da sadri u sebi tu vezu me u objektima kako bi bio vjerodostojna slika realnog procesa koga posmatramo i kako bi o njemu mogli da dobijamo relevantna nova saznanja i informacije.
1.3 Veze me u objektima

Svijet u kome ivimo je veoma kompleksan pa su tako i informacioni sistemi koji ga opisuju po svojoj prirodi kompleksni, ma koliko se mi trudili da model objekta pojednostavimo. Izdvojeni model objekti (kada ih ima vie) su redovito me usobno povezani vezama koje su refleksija veza koje postoje me u objektima i u realnom svijetu. Jer, ako to ne bi bio sluaj, informacioni sistem ne bi bio realna slika dijela svijeta koji opisujemo, pa ne bi imao nikakvu praktinu vrijednost. Prirodu veza me u objektima najee diktira ovjek, rje e su te veze poslijedica neke prirodne zakonitosti. U osnovi veza me u objektima su najee zakoni, statuti, propisi, dogovori itd., a koji su rezultat ljudskih aktivnosti. Danas razlikujemo tri tipa veza me u objektima i to:
veza tipa 1 : 1 veza tipa 1 : N veza tipa N : M
1.3.1 Veza tipa 1 : 1 Pretpostavimo da je na nekom univerzitetu uspostavljen informacioni sistem u kome izme u ostaloga postoje i dva objekta:
FAKULTET DEKAN
13
Prva tabela FAKULTET sadri atribute kojima se opisuju fakulteti toga univerziteta na primjer:
FAKULTET <naziv, adresa, telefon, ...............itd. >
a druga, DEKAN, sadri atribute koji poblie definiu dekane fakulteta, na primjer:
DEKAN <ifra_dekana, ime, prezime, adresa, telefon, itd,...>
Ako je zakonom odre eno da svaki fakultet moe da ima samo jednog dekana, a da samo jedan profesor (jedna osoba) moe biti dekan, onda je veza me u tabelama FAKULTET i DEKAN definisana veza je tipa 1 : 1 - a moe se grafiki predstaviti u vidu romba kao:
FAKULTET DEKAN
1:1 1.3.2 Veza tipa 1 : N U informacionom sistemu univerziteta moe da postoji i objekat PROFESOR iji atributi treba da poblie opiu profesore. Na primjer:
PROFESOR <ifra_profesora, ime, prezime, zvanje, adresa, itd,...>
Ako zakonski propisi propisuju da jedan profesor moe biti u radnom odnosu samo na jednom (1) fakultetu, a da svaki fakultet angauje vie (N) profesora, onda je veza izme u objekata FAKULTET i PROFESOR tipa 1 : N.
FAKULTET PROFESOR
1:N 1.3.3 Veza tipa N : M Proirenje ovog univerzitetskog informacionog sistema moe se odnositi i na studente. O svakom studentu treba imati neke podatke, na primjer:
STUDENT < Br._ind, ime, prezime, god._ro , adresa, itd,....>
14
Kako u toku studija svaki student dolazi u kontakt sa vie (M) profesora, ali i svaki profesor dri predavanja veem broju (N) studenata to je veza me u objektima PROFESOR i STUDENT tipa M : N.
STUDENT PROFESOR
M:N
1.4 Modeli informacionih sistema

Pedesetih godina prolog vijeka pojavio se problem kako modelirati i objediniti objekte u jedan cjeloviti informacioni sistem pa su od tada do danas razvijeni sljedei modeli:
model prve generacije bazirani na programskim jezicima, modeli druge generacije hijerarhijski i mreni, te model tree generacije objektno orjentisan - relacioni model. .
Danas je u primjeni dominantan model tree generacije, takozvani model objekat-veze (MOV), (Entity-Relationship ili E-R model), koji se pri implementaciji na raunar transformie u relacioni. Relacioni model je pokazao takvu superiornost u primjeni da su ostali modeli praktino naputeni. Me utim treba naglasiti da, bez obzira koji model je u pitanju, u svakom od njih mora uvijek postojati mogunost:
definisanja podataka, definisanja pravila za ouvanje podataka, definisanja pravila manipulacije podacima.
1.4.1 Hijerarhijski model baze podataka Modeli, bazirani na programskim jezicima, odrali su se kratko, takorei nije ni bilo vremena da se implementiraju iz razvojne u eksploatacionu fazu.
15
Prvi model koji je naao primjenu i u praksi bio je hijerarhijski model a pojavio se ezdesetih godina prolog vijeka. Osnovni razlog zato je hijerarhija bila osnova za modeliranje informacionih sistema je injenica da je hijerarhija prisutna u svakodnevnom ivotu gdje smo mi, od malih nogu, od autoriteta roditelja u porodici, preko firme u kojoj radimo, vojske u kojoj smo sluili vojni rok, preduzea u kome smo zaposleni, crkve ili neke druge institucije kojoj pripadamo itd. naviknuti na hijerarhiju. Osnovni nedostatak hijerarhijskog modela je nepostojanje egzaktne matematike teorije koja ga prati i koja i omoguila njegovu punu implementaciju na raunar. To je i bio podstrek E.F.Codd-u da poetkom sedamdesetih godina prolog vijeka definie, dizajnira i prezentira danas najpopularniji relacioni model, koji e biti detaljnije opisan u sledeim poglavljima. Analizirajmo nekoliko primjera hijerarhijskog modela kako bi sagledali sve njegove karakteristike prednosti i mane. Primjer I Pretpostavimo da je u nekoj firmi potrebno projektovati informacioni sistem (bazu podataka) internog kolovanja njihovih slubenika. Preduzee dri niz razliitih kurseva na razliitim lokacijama. Neki od kurseva se nastavljaju jedan na drugi, pa je uspjeno zavren prethodni kurs, uslov za upis narednog.
Odgovarajua baza podataka, nazovimo je DOKVALIFIKACIJA, za svaki kurs treba da sadri sljedee informacije: broj kursa, naziv kursa, mjesto i vrijeme odravanja, broj kursa koji je uslov za uspjeno poha anje slijedeeg, detalje o predavaima (ime, prezime, adresa, itd..), detalje o polaznicima (ime, prezime, ocjena, itd).
Struktura hijerarhijskog modela predstavlja se grafiki jer je pregledna u grafikoj formi (to je jedna od malobrojnih prednosti hijerarhijskog modela nad relacionim), kako se to vidi na priloenoj slici 1.4.
16
DOKVALIFIKACIJA USLOV naziv ifra uslova ifra kursa vrijeme odravanja KURSEVI mjesto
NASTAVNICI ifra nastavnika ime ifra polaznika ime
POLAZNICI ocjena
Slika 1.4 Primjer hijerarhijske strukture informacionog sistema
Sa skice je vidljivo da hijerarhijska struktura ima svoj naziv, svoju osnovu ili korijen (DOKVALIFIKACIJA), koja se u zavisnosti od strukture dalje grana i to uvijek prema dole. U konkretnom sluaju osnova, DOKVALIFIKACIJA, ima svoje dvije pod-tabele koje joj slijede. To su: USLOV i KURSEVI, pri emu tabela USLOV mora biti logiki povezana sa tabelom KURSEVI (mora se znati ta je preduslov za poha anje narednog kursa). Tabela USLOV nema svojih pod-tabela nema "nasljednika", dok tabela KURSEVI ima dva nasljednika, dvije pod-tabele i to: NASTAVNICI POLAZNICI. Tabele USLOV i KURSEVI su prema tome nasljednici u bazi DOKVALIFIKACIJA, a tabela KURSEVI je istovremeno roditelj za tabele NASTAVNICI i POLAZNICI.
Precizno definisana me usobna povezanost pojedinih tabela definie pomenutu hijerarhiju u ovom primjeru:
KURSEVI - POLAZNICI, KURSEVI - NASTAVNICI, DOKVALIFIKACIJA - USLOV
a to je na slici 1.4. jasno vidljivo.

17
Hijerarhijskim modelom sve veze me u tabelama, odnosno me u atributima pojedinih tabela, moraju biti precizno definisane. Hijerarhijski model podataka bio je prvi ozbiljniji pokuaj modelovana informacionog sistema. Me utim, on je ubrzo naputen jer za uspjean rad sa njim svi korisnici informacionog sistema, a ne samo njegov administrator, morali su poznavati mnoga, ne ba jednostavna pravila i ogranienja u primjeni, kao i strukturu, zavisnost i prirodu veza izme u pojedinih polja atributa me usobno povezanih tabela. Priroda i vrsta veza me u objektima odre ena je, kao to to vidjeli, spoljnim, esto nametnutim, uslovima (zakoni, pravilnici, statuti, dogovori itd.), pa ako i ta kategorija mora biti poznata i projektantu i administratoru, a i korisniku baze podataka, za iru primjenu hijerarhijskog informacionog sistema to sigurno nije neka ozbiljna referenca. Ima sluajeva za koje je u hijerarhijskom modelu nema rjeenja. To se odnosi na sluajeve kada jedan roditelj moe imati vie nasljednika, ali i svaki nasljednik moe imati vie roditelja. To su pomenute veze tipa M : N. Definicija je u bukvalnom smislu rijei apsurdna, ali u prenosnom smislu, u informacionim sistemima mogue je da se pojavi. Pokaimo to na jednom primjeru: Primjer II
Neka u dijelu hijerarhijski organizovanog informacionog sistema nekog univerziteta (nazovimo ga UNIVERZITET), postoje tabele sa slijedeim atributima: FAKULTET < sifrafak, naziv, adresa, telefon, ..........> REKTOR < sifrarek, ime, prezime, adresa, telefon.................> DEKAN < matbr, ime, prezime, adresa, zvanje, sifrafak,.......> PROFESOR < sifraprof, ime, prezime, adresa, sifrafak, ........> STUDENT < broj indexa, ime, prezime, adresa, sifrafak,.......>
Organizaciona struktura univerziteta nam kazuje da su tabele FAKULTET (F), koje izlaze iz korijena tabele UNIVERZITET (a koja ima u istom hijerarhijskom nivou i tabelu REKTOR,) roditelji za tabele PROFESOR (P),koju naslije uje tabela i STUDENT (S). Tabele
18
DEKAN (D) i FAKULTET su dodatno me usobno povezane, i nalaze se u istom hijerarhijskom nivou slika 1.5. Ako zakonska praksa ne dozvoljava profesoru da jednovremeno radi na dva fakulteta, onda jednom fakultetu pripada N profesora, ali svaki profesor pripada samo jednom fakultetu.
Ovaj tip veze 1:N (jedan prema vie) u hijerarhijskoj strukturi se lako prestavlja, jer jedan roditelj (FAKULTET), logino, moe imati vie nasljednika (PROFESOR-a).
Izme u tabela STUDENT i PROFESOR veza je drugaija, jer profesor predaje veem broju (N) studenata, a student slua predavanja vie (M) profesora. Veza je tipa N : M i ne moe se na slici 1.5 grafiki predstaviti
Veze M:N mora biti transformisana u dvije veze tipa 1 : N. Na taj nain se odstupa od hijerarhijske strukture i model se ne moe vie smatrati hijerarhijskim. Istina, i u relacionim bazama postoji isti problem, ali je lake rjeiv a model pri tome ostaje relacioni. Zbog tekoa pri rjeavanju problema veza tipa M:N, i jo nekih nedostataka, hijerarhijske baze podataka su danas prava rijetkost. Me utim, mora se priznati da je hijerarhijski nain memorisanja podataka u prednosti u pogledu brzine pristupa podacima, jer su putevi pristupa podacima tano definisani hijerarhijskim vezama me u tabelama, to kod relacionog modela, u tako eksplicitnoj formi, nije sluaj. Hijerarhijski sistem ima jo nedostataka. To su prije svega:
nekontrolisan gubitak informacija (brisanjem tabele RODITELJA gubi se i tabela NASLJEDNIK, svi podaci u njoj, kao i sve nie rangirane tabele sa podacima u njima), te pojava redundance podataka (potreba za memorisanjem istog podatka na vie mjesta) to komplikuje auriranje podataka, uz jednovremeno smanjenje pouzdanosti informacija koje se iz takvog informacionog sistema dobijaju.
19
univerzitet
rektor
F1
D1
F2
D 2
......itd
P1
P2
P3
.....itd
s1
s2
s3
........itd
Slika 1.5 Hijerarhijska struktura informacionog sistema univerziteta
Do kakve greke zbog pojave redundance moe doi ilustrujmo opet jednim primjerom. Primjer III
Pretpostavimo da je kliniki centar uspostavio informacioni sistem koji se bazira na hijerarhijskom modelu. Poto je u organizaciji rada u ustanovama ovakvog tipa hijerarhijska struktura, zbog naina poslovanja, izrazito prisutna u svim segmentima rada, to e slika poslovanja preslikana u hijerarhijsku strukturu biti sigurno realna. Pretpostavimo da je projektant hijerarhijskog informacionog sistema predvidio, izme u ostaloga, slijedee objekte i veze me u njima: Korijen stabla je KLINIKI CENTAR. Prvi nii nivo su KLINIKE (sa svim relevantnim podacima o njima), zatim LJEKARI (sa podacima o njima), MEDICINSKO OSOBLJE, POMONO OSOBLJE, LABORATORIJE, KABINETI, PACIJENTI itd. - sa svim podacima o njima. Organizacionom strukturom rada zna se koji ljekari pripadaju kojoj klinici, te koje osoblje i pacijenti, pripadaju nekom ljekaru i klinici. Sistem na prvi pogled treba da funkcionie besprijekorno. Pretpostavimo sada slijedei hipotetiki sluaj. Pacijent xy dolazi zbog zdravstvenih problema na ispitivanje. On bude primljen na kliniRelacione baze podataka
20
ku K1 (na primjer interna klinika) i biva dodijeljen ljekaru te klinike L1. Na prijemnom odjeljenju klinike K1 uzimaju se svi potrebni podaci od pacijenta i unose u njihovu tabelu PACIJENTI, koja stoji na raspolaganju svima zainteresovanim ljekarima i osoblju ali samo na klinici K1. Opte podatke (prezime, ime, adresu, i sl.) uzima slubenik na alteru, a podatke o zdravstvenom stanju: anamnezu (linu i porodinu) i nakon pregleda dijagnozu, ljekar u prijemnom odjeljenju. Na osnovu dijagnoze bolesnik se upuuje u odjeljenje na lijeenje. Na ispitivanju, na klinici K1, utvrdi se da je za pacijenta xy potreban hirurki zahvat. Pacijent biva prebaen na kliniku K2 (hirurgija) sa svom prateom (papirnom) dokumentacijom (anamneza, dijagnoza, terapija, eventualne alergije itd). Na prijemnom odjeljenju klinike K2, njihov slubenik unosi ponovo sve podatke o pacijentu u tabelu PACIJENTI (ali sada klinike K2), iako ti podaci ve postoje na klinici K1 (ovo je redundanca - ponavljanje podataka). Nakon hirurkog zahvata, u post-operativnom toku, dolazi do komplikacija i pacijent bude podvrgnut dodatnoj terapiji (na primjer antibioticima). U toku te terapije pacijent doivi ok i nakon toga postaje alergian na upotrebljeni antibiotik A1. Intervencijom deurnog osoblja pacijent bude spasen, a u tabelu PACIJENTI na klinici K2 (ali ne i K1) unosi se dodatni podatak alergian na antibiotik A1. Kada se stanje potpuno normalizuje pacijent bude otputen kui. Nakon nekog vremena isti pacijent oboli od gripe koja se iskomplikuje i pre e u upalu plua tako da je pacijentu opet potreban kliniki tretman. On dolazi ponovo na kliniku K1 (interna) gdje, na prijemnom odjeljenju, nakon unoenja njegovog matinog broja, slubenik vidi da je pacijent xy ve bio hopitalizovan na toj klinici, i zato ne uzima opte podatke od njega, nego ga odmah proslije uje ljekarima. Ljekari uzimaju novu anamnezu, postavljaju novu dijagnozu i upuuju pacijenta na odjeljenje te klinike na lijeenje. Ljekar na odjeljenju, koji ima uvid u podatke o pacijentu iz tabele PACIJENTI klinike K1, vidi da nema smetnje da se ukljui terapija antibioticima (taj podatak postoji samo na klinici K2), propisuje terapiju antibiotikom A1 koja dovodi do fatalnog ishoda.
21
injenica da su razliiti podaci o istom pacijentu bili upisani na dva mjesta (klinike K1 i K2), da nisu bili jednovremeno aurirani, dovela je u ovom sluaju do pogrene informacije koja je imala fatalan ishod.
Svi pomenuti nedostatci hijerarhijskog modela uinili su da se ova tehnologija danas definitivno smatra zastarjelom i odbaenom. 1.4.2 Mreni model Mreni model nastao je kao proirenje i pokuaj poboljanja hijerarhijskog. Osnovna razlika, u odnosu na hijerarhijski model, lei u injenici da se dozvolilo da nasljednik ima vie roditelja, to znai da ovakav model prihvata i veze tipa M:N. Na taj nain veze me u pojedinim tabelama, grafiki interpretirane, lie na paukovu mreu odakle je model i dobio ime slika 1.6.
U primjeru hijerarhijski organizovanog informacionog sistema klinikog centra, ako hoemo da otklonimo mogunost pojave greke uslijed redundance onda tabele PACIJENT (i eventualno LABORATORIJA) moraju biti dostupne ljekarima i osoblju na svim klinikama. To se moe postii povlaenjem veza od KLINIKA do svih PACIJENATA i LABORATORIJA, pa dobijamo paukovu mreu kako se to vidi na priloenoj skici 1.6.
Povezivanje tabela me usobnim vezama u mrenom modelu nije niim limitirano osim logikom na kojoj se informacioni sistem bazira, a dijelovi mrene strukture mogu biti i hijerarhijske pod-strukture.
klinika 1 klinika 2 klinika 3
laboratoria
pacijent
Slika 1.6 Primjer mrenog modela

22
Inae, i za mrene strukture informacionih sistema vai veina nedostataka navedenih kod hijerarhijskih, pa se zbog toga rje e nalaze u praksi i gotovo je sigurno da e za kratko vrijeme potpuno ieznuti. 1.4.3 Relacioni model Relacioni model je danas najrasprostranjeniji model informacionog sistema zahvaljujui pre svega sledeim osobinama:
struktura modela je jednostavna a baza podataka je predstavljena samo skupom tabela i funkcionalnim vezama me u njima, razvijena je matematika teorija koja omoguava jednostavnu interpretaciju ovog modela na raunaru.
Kao to mu i samo ime govori, ovaj model se zasniva na tabelama i relacijama me u njima koje nisu odre ene ni hijerarhijski, ni mreno, nego funkcionalno.
23
Glava 2
2.0 Relacioni model - uvod
Principe i strukturu relacionog modela objavio je E. F. Codd 1970. godine u svome radu: A Relation Model of Data for Large Shared Data Banks Communications of the ACM, Volume 13, Number 6, (1970.), pages 377-387. Od tada se ovaj model stalno usavrava i danas je za organizaciju, manipulaciju i obradu podataka opteprihvaen u svijetu. Njegova osnovna prednost, u odnosu na hijerarhijski i mreni model, je u tome to se u potpunosti oslanja na matematiku disciplinu, takozvanu relacionu algebru, ime je omoguena raunarska podrka, razvoj specifinog softvera, i obrada uz zagarantovanu konzistentnost podataka i rezultata a objektno orjentisani programski jezici (na primjer Visual Basic) u potpunosti zadovoljavaju sve zahtjeve za implementaciju operacija pomenute relacione algebre.
24
2.1 Osnovne definicije

Na prvi pogled izgleda da se sistem, formiran kao relaciona baza podataka, sastoji od nasumice nabacanih i me usobno nevezanih, tabela u kojima za svaki objekat sistema koji je predstavljan tabelom:
a redovi n-torke ili slogove (sa podacima). kolone predstavljaju atribute (sa podacima),
Me utim, kada se malo bolje sagleda sutina relacione organizacije, tek tada prednosti ovog modela postaju evidentne. Stoga je potrebno objasniti osnovne principe na kojima se bazira relacioni model i definisati osnovne pojmove u njemu. To su:
relacija, entitet, atribut, domen, kardinalnost relacije, primarni sekundarni klju.
2.1.1 Pojam relacije u relacionom modelu Relacija, osnovni element relacionog modela ustvari je sinonim, uz neka ogranienja, za tabelu ili datoteku. E. F. Codd je u svom radu, kojim je po prvi puta promovisao relacioni model, pod relacijom definisao pravougaono podruje - tabelu koje se sastoji od kolona (atributa i vrijednosti atributa - podataka) te redova (n-torki, odnosno slogova sa podacima). Ovako definisana tabela predstavlja skup vrijednosti ali postoje i odre eni uslovi koje neka tabela mora da zadovolji da bi bila i relacija. Ti uslovi su:
25
a. Sve vrijednosti podataka jednog atributa moraju biti istog tipa.

Na primjer, sve vrijednosti atributa "dan_mjesec_godina" moraju biti datumi, sve vrijednosti atributa "plata" moraju biti numerikog, dakle brojnog karaktera, vrijednosti atributa "ime i prezime" moraju imati slovni (alfanumeriki) karakter itd.
Unutar jedne relacije, svaki atribut moe biti drugog tipa, to je sa stanovita raunarskog softvera kvalitativna novina koja je traila doradu i proirenje do tada poznatih programskih jezika (Fortran, Pascal, itd.), kod kojih je, u njihovim verzijama, matrina varijabla (dakle tabela) morala imati sve vrijednosti varijable (podatke) istog tipa (REAL, INTEGER, LOGICAL itd.). Svaki podatak u tabeli-relaciji predstavlja samo skup znakova i nita vie. Na osnovu jednog podatka u relaciji ne moe, i ne smije se, doznati niti zakljuivati nita o vrijednostima drugih atributa u istoj ili drugoj n-torci te relacije. Drugim rijeima: u relacionoj bazi podataka ne smiju postojati funkcionalne zavisnosti me u atributima. b. Unutar jedne relacije ne smiju postojati dvije identine n-torke, dvije n-torke sa identinim vrijednostima atributa identinim podacima. Ovo je logian zahtjev, jer dvostruko memorisanje podataka moe biti tetno (redundanca podataka), a nije ni potrebno. c. Redoslijed n-torki u relaciji je proizvoljan. d. Svi atributi unutar jedne relacije moraju imati razliita imena, dok je redoslijed njihovog navo enja tako e proizvoljan. 2.1.2 Entitet Entitet je dio model realnog svijeta opisan ogranienim brojem atributa.
26
2.1.3 Atribut Atribut je jedno od svojstava entiteta (objekta) kojeg posmatramo, i o kojem sakupljamo podatke. Svi podaci u jednom redu, jednom slogu, odnosno jednoj n-torci, definiu jednu jedinku datog objekta, dok jedna kolona opisuje jedno svojstvo svih jedinki. Na primjer, u objektu:
SLUBENIK < JMBG, ime, prezime, dat_ro , adresa, tel, > svaka n-torka sadri gore navedene podatke o jednom slubeniku, dok kolona JMBG, sadri jedinstvene matine brojeve svih slubenika tog preduzea.
Atributi u trenutku skupljanja podataka u relacionoj bazi podataka ne moraju obavezno imati poznate vrijednosti i u tom sluaju ih nazivamo Null - vrijednostima a treba ih, posebno ako ih u nekoj relaciji ima vie, izbjegavati.
Tako ne bi bilo racionalno u tabelu SLUBENIK uvesti i atribut "odlikovanja", jer se odlikovanja ne dijele masovno i nasumice (bar u civilizovanim zemljama), pa e za veinu slubenika u tom polju ostati prazno mjesto, to jest Null-vrijednost. Rjeenje problema bilo bi u kreiranju nove tabele, nazovimo je: ODLIKOVANJA < JMBG, medalja > a u kojoj bi se registrovali samo odlikovani slubenici sa njihovim matinim brojem (JMBG) i nazivom medalje koju su dobili, pa bi shodno tome relacija ODLIKOVANJA bila potpuno popunjena, a preko matinog broja JMBG bila bi povezana (u relaciji) sa osnovnom tabelom SLUBENIK i ostalim podacima o njemu.
Pri projektovanju informacionog sistema, u skladu sa potrebama, treba veoma paljivo i studiozno iz mnotva moguih atributa odabrati i definisati samo one koji opisuju objekat na, za nas, zadovoljavajui i prihvatljiv nain. Na primjer:
27
U sluaju objekta SLUBENIK kao atribut odabran je datum ro enja ("dat_ro ") sa namjerom posjedovanja podataka o starosnoj dobi svakog slubenika u preduzeu, a vjerovatno ne samo zbog mogunosti estitanja ro endana slubenicima od strane direkcije firme. Nije usvojen atribut "godine_starosti" jer bi to bilo loe rjeenje. Baza podataka morala bi se u tom sluaju svaki dan osvjeavati s obzirom da su svi slubenici svakog dana jedan dan stariji i uvijek postoji mogunost da ba toga dana neko od slubenika ima ro endan, da postaje i godinu dana stariji, to zahtijeva stalno auriranje baze, to jest izmjenu podatka u njoj. U sluaju kada je atribut "datum ro enja", taj podatak je konstantan, a godine starosti se bez problema mogu, za svakoga, u svakom trenutku, izraunati iz poznatog tekueg datuma.
2.1.4 Domen Domen je skup vrijednosti koje atribut moe da poprimi. Na primjer: U relaciji SLUBENIK, atribut "pol" moe da poprimi samo dvije vrijednosti, muko ili ensko, pa mu je domen dva. Domen za atribut "zvanje" ima onu vrijednost koliko ima razliitih zvanja slubenika angaovanih u toj firmi. Domen atributa "telefon" najvjerovatnije je jednak broju ntorki u relaciji (izuzev ukoliko dva slubenika ne koriste isti telefonski broj, ili ako ima slubenika bez telefonskog prikljuka). 2.1.5 Primarni klju Primarni klju, ili esto krae samo klju, je atribut (ponekad, ako je to neophodno, i skup, odnosno kombinacija atributa) ija vrijednost jednoznano definie samo jednu n-torku, samo jedan slog, u nekoj relaciji - tabeli, to znai da jednoznano izdvaja samo jedan red - jedan slog, u njoj.
28
Prema tome: U jednoj relaciji ne smiju postojati dvije razliite n-torke sa istom vrijednou kljunog atributa. Ukoliko ne postoji atribut koji zadovoljava uslove za kljuni atribut, klju se moe kreirati kombinacijom dva ili vie atributa. Primarni klju mora biti: jedinstven, nepromjenljiv i uvijek raspoloiv. Izbor primarnog kljua je veoma vaan jer se jedino preko njega moe pristupiti jednoj, i samo jednoj, n-torci u nekoj relaciji, pa uz poznati naziv atributa moemo tako pristupiti i jednom, i samo jednom, podatku posmatranog objekta. Primarni klju se esto obiljeava (markira) prilikom definisanja relacije. U literaturi se kljuni atribut najee oznaava znakom # iskljuivo iz razloga da bi tabela relacija bila preglednija za korisnika. Neki savremeni softverski paketi koji se koriste za upravljanje relacionom bazama podataka (ACCESS, na primjer) kao oznaku za klju koriste i doslovno znak kljua ( ).
Na primjer, u relaciji SLUBENIK, kandidat za primarni klju na naim prostorima je matini broj gra anina (JMBG), s obzirom da od svih navedenih atributa u relaciji SLUBENIK samo za matini broj moemo biti sigurni da je jedinstven, to jest da ne postoje dvije osobe sa istim matinim brojem. Takvu tvrdnju ne moemo, na primjer, izrei za ime, prezime, adresu ili telefonski broj. Ali ako u tom preduzeu moe biti angaovan i neki stranac (koji nema na JMBG) onda se za kljuni atribut mora traiti neko drugo rjeenje.
Relacija SLUBENIK sa obiljeenim kljuem glasi:

SLUBENIK < JMBG#, ime, prezime, dat_ro , adresa, telefon >
Ukoliko u nekoj relaciji nismo u stanju da "izdvojimo" kandidata za ulogu primarnog kljua, problem se rjeava na dva naina:
29
ili definisanjem grupe atributa (sloeni klju) koji onda imaju jedinstvenu vrijednost za svaki slog, ili uvo enjem novog, dodatnog, atributa, nazovimo ga jednostavno "ifra", pri emu se onda pogodnim izborom te ifre (na primjer, redni brojevi) obezbje uje njena jednoznanost.
Na kraju, napomenimo da neki savremeni softverski paketi (ORACLE, na primjer) doputaju da relacija sadri i identine n-torke, dakle da u relaciji ne mora biti definisan primarni klju. Razlog za to je unos podataka iz drugih izvora, na primjer iz programa za rad sa tabelama (EXCELL, na primjer), koji po pravilu nemaju mehanizme koji bi sprijeili pojavu duplikata (identinih vrijednosti kljunih atributa ili itavih n-torki). Naravno, postoje postupci pomou kojih se ovakvi zapisi mogu eliminisati iz tabela ako je to potrebno. Me utim, jedno je sigurno:
nepostojanjem primarnog kljua gubi se mogunost direktnog pristupa u nekoj relaciji jednoj i samo jednoj n-torci.
2.1.6 Spoljni (vanjski, strani) klju Spoljni klju (na primjer u relaciji A) je atribut koji u drugoj relaciji (na primjer B) ima ulogu primarnog kljua. Osnovna uloga spoljnih kljueva je uspostavljanje veza (relacija) me u tabelama, a ne identifikacija n-torki. Na primjer u relacijama:
BOLNICA < ifrabol#, naziv_bolnice, adresa, telefon,...> LJEKAR < ifraljek#, ifrabol, ime, prez, adresa,.....> "ifrabol#" je u relaciji BOLNICA primarni klju, a u relaciji LJEKAR atribut, i slui za povezivanje relacija. Na taj nain moemo, na primjer, za ljekara iju ifru poznajemo, dobiti telefonski broj bolnice u kojoj radi, unosei poznatu ifru bolnice (ifrabol#) iz njegove n-torke u relaciji LJEKAR, u relaciju BOLNICA (gdje je ifrabol# primarni klju), oitavajui nakon toga vrijednost atributa "telefon" u n-torci relacije BOLNICA.
30
Spoljni klju (naziva se jo i strani klju), moe, ali i ne mora se, posebno obiljeiti (sa ! ili $). I to se opet samo u tekstu, jer to obiljeavanje iskljuivo doprinosi vizuelnoj preglednosti modela. Jedino ako je strani klju ujedno i dio nekog primarnog sloenog kljua, onda ga treba obiljeiti uobiajenom oznakom (#) za primarni klju.
2.2 Codd-ova pravila

E.F. Codd je u svojim radovima definisao 12 pravila od kojih najmanje 6 mora biti ispunjeno da bi se informacioni sistem mogao smatrati relacionim. Ta pravila su rezultat teorijskog pristupa ovome problemu. S obzirom na obim ove knjige ograniimo se na definiciju 6 osnovnih pravila, ne uputajui se i u njihovo dokazivanje. Osnovno ili nulto pravilo koje predstavlja conditio sine qua non u relacionim bazama podataka glasi: Svaki sistem za upravljanje bazama podataka, koji se smatra, ili koji jeste, relacioni, mora imati mogunost upravljanja bazom podataka na relacioni nain i relacionim metodama. Ostala pravila su: 1. Predstavljanje informacija
Sve informacije u relacionoj bazi podataka moraju logiki biti predstavljene na isti nain: vrijednostima podataka u tabelama - relacijama.
2.
Logika dostupnost podacima

Svaki podatak mora imati atomarnu, nedjeljivu vrijednost, koja logiki mora biti dostupna korisniku uz pomo: imena relacije u kojoj se nalazi, vrijednosti primarnog kljua te relacije i imena atributa u toj relaciji.
31
3.
Mogunost prikazivanja nepostojee informacije

Relaciona baza podataka podrava koncept nultog podatka, (Null). Pod pojmom nultog podatka podrazumijeva se vrijednost atributa koja u datom trenutku nije poznata. To, dakle, nije vrijednost koja je predstavljena nulom, ili nizom nula, nizom praznih (blank) mjesta, ili nizom bilo kojih drugih znakova. To je jednostavno, trenutno nepoznata vrijednost podataka, i predstavlja specifikum i kontroverzniji aspekt relacionog modela informacionog sistema. Tako, na primjer, atribut "telefon" u relaciji SLUBENIK ima Null-vrijednost u trenutku primanja nekog slubenika u radni odnos ukoliko taj slubenik nema telefonski broj.
4.
Dinamiki katalog
Relaciona baza podataka mora biti tako prezentirana da autorizovani korisnici mogu primijeniti neki od relacionih jezika na podatke u njoj. Pod ovim se podrazumijeva: pristup sistemskim katalozima, pristup relacijama koje su u toku rada za stalno, ili samo na ogranieni vremenski rok prisutne i pristup relacijama koje se programski kreiraju (tzv. dinamiki katalozi) a koji sadre nove informacije.
5.
Softverski paket za manipulaciju bazom podataka

Softverski paketi omoguavaju manipulisanje podacima u relacionoj bazi podataka, i oni su manje ili vie prilagoeni korisniku - manipulatoru. Svaki od njih sadri programski jezik koji pomou definisane sintakse, i na korisniku blizak nain, omoguava:
32
definisanje tabela, definisanje atributa, unoenje podataka, definisanje proizvoljnog pogleda definisanje proizvoljnog upita, manipulaciju podacima, postavljanje ogranienja korisnicima, autorizaciju korisnika, te upravljanje proizvoljnim transakcijama.
6.
Nezavisnost integriteta baze

Nijedno ogranienje integriteta (sigurnosti ouvanja podataka) ne smije se pri organizaciji logikog modela relacione baze podataka nai u aplikativnom dijelu softverskog programa dostupnom irem broju korisnika, nego iskljuivo u dijelovima koji su pod kontrolom administratora baze. Drugim rijeima, pravila integriteta se definiu u okviru sinteze baze podataka.
Nakon objavljivanja Codd-ovog rada veliki broj autora nastavio je da sa bavi teorijom i praksom sinteze i eksploatacije baze podataka. Tako je naknadno, nakon 12 Cood-ovih pravila definisano jo est dodatnih a mogu se nai u strunoj literaturi.1
2.2 Ogranienja i pravila pri projektovanju

U relacionom modelu potrebno je u pojedinim relacijama ograniiti vrednosti nekih atributa. Ve postojanje domena atributa predstavlja odre eno ogranienje (starost, cijena, itd...). Ali postoje i tzv. opta ogranienja koja vae za svaki relacioni model i koja se nazivaju pravilima integriteta relacionog modela. To su:
Ratko Vujnovi: SQL Relacijski model podataka, Znak, Zagreb 1996.

33
1. Integritet entiteta: Nijedan atribut koji je primarni klju ili dio primarnog kljua, ne smije nikada da uzme null vrijednost. 2. Referencijalni integritet: Skup vrijednosti spoljnjeg kljua relacije R1 mora biti podskup skupa vrijednosti primarnog kljua relacije R2 sa kojom se povezuje R1. Relacije R1 i R2 moraju biti razliite. Pored ogranienja koja su zadana strukturom modela, mogu se, za bolju specifikaciju semantike, iskazati dodatna, eksplicitna ogranienja. Na primjer:
Neka jednostavna ogranienja mogu se iskazati preko definicije domena atributa (ocena na ispitu mora biti vea ili jednaka 5 a manja ili jednaka od 10). Neka sloenija ogranienja oznaavaju poslovni integritet. Na primjer, student da bi upisao narednu godinu, na nekim fakultetima mora poloiti sve ispite iz prethodne godine, a na nekim moe prenijeti dva ispita.
Ostala pravila kojima se definie kvalitet, i koja mora da ispuni svaki sistem za upravljanje bazama podataka da bi se smatrao relacionim, mogu se ukratko saeti kao:
a. programskim jezikom tree generacije ne smiju se zaobii pravila integriteta definisana relacionim jezikom. b. mora postojati mogunost kreiranja "pogleda" na bazu podataka i definisanja operacija nad njima te izvravanja operacija odravanja baze podataka. c. aplikacioni programi2 moraju ostati nepromjenjeni ako se promjene bazne relacije u sistemu (sem u sluaju promjene strukture tabela); d. aplikacioni programi moraju ostati nepromjenjeni i ako se promjeni fizika organizacija baze podataka ili fiziki metod pristupa;
2
Programi kojima se korisniku omoguava jednostavno korienje nekog informacionog sistema

34
Naalost, danas je situacija takva da veina sistema za odravanje baza podataka ne zadovoljava sve navedene kriterijume. Problemi koji se javljaju uvijek su u vezi odravanja integriteta baze. Da rezimiramo: relacioni model je danas dominantan zahvaljujui strogoj matematikoj teoriji na kojoj se bazira. Softverski paketi, koji se koriste u manipulisanju relacionim bazama podataka me usobno su slini pa korisnik, koji je savladao jedan, sa malo truda moe da se prebaci i na neki drugi. Uvo enjem tehnike objektnog programiranja, dizajn aplikativnih programa postao je blizak korisniku, jer veina novih paketa sadri podprograme prilago ene manipulaciji podacima, kao i gotove "generatore" za razne obrasce, izvjetaje i aplikacije. Hardverska konfiguracija savremenih personalnih raunara omoguava postavljanje i najveih softverskih paketa (ORACLE, na primjer) na danas ve praktino standardnim konfiguracijama personalnih raunara.
2.3 Distribuirane baze podataka

Pod distribuiranom bazom podataka smatra se informacioni sistem koji radi u raunarskoj mrei i koji ima najmanje dva dislocirana raunara, sa dislociranim tabelama, u kojima se nalaze podaci. Distribuirane baze podataka zbog svoje kompleksnosti donose i niz problema, kako u njihovom projektovanju, tako i u eksploataciji. Pri tome, do danas jo nije u potpunosti razvijena matematika teorija koja bi podravala ovakve sisteme to donekle oteava njihovu sintezu posebno u smislu tajnosti i privatnosti. Osnovni problemi na ijem rjeavanju se danas radi su:
pravo pristupa (ko, kada i kojim podacima moe pristupiti), ouvanje podataka (ko ima pravo promjene podataka), i potpuna tajnost podataka.
35
Organizacija distribuiranih baza podataka je tako postavljena da se globalni informacioni sistem sastoji od vie lokalnih baza podataka, a uvijek postoje najmanje dva upravljaka nivoa, sistema, i to:
lokalni upravljaki sistem (LDBMS - Local Database Management System), i globalni sistem (DDBMS - Distributed Database Management System).
Pomenuti sistemi su iskljuivo logiki, dakle me usobno su samo softverski povezani, tako da korisnik distribuirane baze podataka sa svog radnog mjesta, sa svog raunara, ne vidi tu distribuiranost i ima osjeaj da je povezan samo sa jednim centralizovanim informacionim sistemom. Evolucija naina obrade zajednikih podataka tekla je od obrade na jednom centralnom raunaru, preko obrade na nepovezanim raunarima, do obrade podataka u mrenom okruenju, u poetku sa serverom3 datoteka, a danas sa distribuiranom obradom.
Kod prvog modela sa centralnim raunarom serverom, podaci i aplikacije su se nalazili na jednom centralnom raunaru (host), a zaposleni su mu pristupali preko glupih terminala na kojima nije postojala mogunost obrade. Aplikacije su pri tome obino podjeljene na dva dijela:
eoni dio (front end) odgovoran za komunikaciju sa korisnikom i pozadinski dio (back end) odgovoran za upravljanje podacima.
Prednosti ovakvog rjeenja su:

lako administriranje, pouzdanost podataka brz pristup, zatita podataka (rezervne kopije) i zajedniko korienje skupih periferijskih ure aja.
Centralni, glavni raunar koji upravlja raunarskom reom

36
Mane ovoga rjeenja su:

potreba za inoviranjem centralnog raunara te, mali broj proizvo aa namjenskih raunara (visoke cijene).
Obrada podataka na nepovezanim personalnim raunarima poinje pojavom personalnih raunara na tritu i operativnih sistema DOS, Unix i Windows kada je veliki broj proizvo aa ovakvih raunara oborio cijene i uinio ih dostupnim velikom broju korisnika. Rad na samostalnim radnim stanicama ima mnogo prednosti:
jeftine su i jednostavne za upotrebu, korisnik sam prilago ava radnu stanicu svojim potrebama, dostupno je mnotva "alata" i aplikacija od raznih proizvo aa.
Naravno, ima i nedostataka mana. To su:

podaci su raspodijeljeni na vie raunara, podaci na jednoj stanici su autonomni i korisnik je odgovoran za upravljanje podacima, podaci na jednom raunaru nisu uvijek dostupni svim korisnicima kojima mogu zatrebati jer se ne mogu koristiti zajedniki skupi ure aji.
U posljednjih desetak godina trend razvoja raunarske tehnike ide u pravcu stvaranja veih, globalnih raunarskih mrea. U prvo vrijeme su to bile lokalne mree (u okviru fakulteta, ustanove, preduzea itd.), zatim je dolo do njihovog povezivanja (na nivou univerziteta, industrijskog koncerna, itd.), da bi se konano dolo i do globalnih svjetskih mrea (danas je najpoznatija od njih - Internet). Da bi mogli da koriste zajednike podatke u lokalnoj mrei datoteke se smjetaju na server datoteka (file server). To je samostalan raunar koji je obino centralno vorite preko kojeg se koriste zajedniki resursi (na primjer diskovi i tampai). Program za upravljanje bazom podataka, izvrava se na svakoj radnoj stanici u mrei, a uzima podatke sa servera i kasnije ih vraa i kopira opet na server.
37
Ovaj koncept nije dobar kod viekorisnikih aplikacija jer sistem sa serverom ne doputa istovremeno viestruko pristupanje istom skupu podataka (data concurrency), veliki je "saobraaj" na mrei kada mnogo korisnika radi, i zato lako dolazi do zaguenja. injenica da je korisnik raunara koji je u mrei u stanju da, uz poznavanje odgovarajuih lozinki i kljunih rijei, pristupi praktino svakom raunaru i svakom podatku u toj mrei, odrazila se i na daljni razvoj informacionih sistema jer se podaci vie ne nalaze na jednom mjestu, oni su distribuirani, a korisnik treba da zna kako i gdje da ih prona e. Dakle dolazi se do obrade po modelu klijent/server, odnosno do distribuirane obrade aplikacija (distributed application processing) koja objedinjuje dobre strane obrade u mrenom okruenju sa visokim performansama centralizovanih sistema. Ovi sistemi su vieslojni i sadre tri komponente:
server baze podataka, aplikacije klijenata i mreu.
Serveri (back end) obezbje uju efikasno upravljanje resursima posebno u uslovima kada vie klijenata istovremeno zahtijeva isti resurs. Oni obezbje uju:
upravljanje bazom podataka, kontrolu pristupa (i bezbjednost podataka) i centralizovano zadovoljenje pravila integriteta.
Aplikacija - klijent (front end) omoguava svim korisnicima komforan rad sa podacima a obezbje uje:
najpogodniji interfejs prema korisniku za odre enu vrstu obrade, upravlja nainom prikaza podataka korisniku, izvrava logiku aplikacije, proverava ispravnost ulaznih podataka i trai i prihvata podatke od servera.
38
Dio ovih aktivnosti u distribuiranoj obradi (poslednje tri) mogu se realizovati i kao poseban sloj u obradi podataka pa mogu biti locirane blie serveru, takozvani aplikacioni server (application server). Ovo je srednji sloj (midle tier), vieslojne arhitekture, pa ovakvi sistemi imaju i odre enih prednosti. To su rije svega:
svaki raunar u sistemu moe biti izabran posebno, tako da najbolje ispunjava zahteve obrade, sistem je fleksibilan i otvoren u pogledu izmena hardvera i softvera i sistem se lako moe proirivati.
Na kraju, treba istai i mogunost specijalizacije i zasebnog razvoja svake funkcionalne komponente kao i upotrebu grafikog radnog okruenja i objektno orijentisanih alata.
23
Glava 2
2.0 Relacioni model - uvod
Principe i strukturu relacionog modela objavio je E. F. Codd 1970. godine u svome radu: A Relation Model of Data for Large Shared Data Banks Communications of the ACM, Volume 13, Number 6, (1970.), pages 377-387. Od tada se ovaj model stalno usavrava i danas je za organizaciju, manipulaciju i obradu podataka opteprihvaen u svijetu. Njegova osnovna prednost, u odnosu na hijerarhijski i mreni model, je u tome to se u potpunosti oslanja na matematiku disciplinu, takozvanu relacionu algebru, ime je omoguena raunarska podrka, razvoj specifinog softvera, i obrada uz zagarantovanu konzistentnost podataka i rezultata a objektno orjentisani programski jezici (na primjer Visual Basic) u potpunosti zadovoljavaju sve zahtjeve za implementaciju operacija pomenute relacione algebre.
24
2.1 Osnovne definicije

Na prvi pogled izgleda da se sistem, formiran kao relaciona baza podataka, sastoji od nasumice nabacanih i me usobno nevezanih, tabela u kojima za svaki objekat sistema koji je predstavljan tabelom:
a redovi n-torke ili slogove (sa podacima). kolone predstavljaju atribute (sa podacima),
Me utim, kada se malo bolje sagleda sutina relacione organizacije, tek tada prednosti ovog modela postaju evidentne. Stoga je potrebno objasniti osnovne principe na kojima se bazira relacioni model i definisati osnovne pojmove u njemu. To su:
relacija, entitet, atribut, domen, kardinalnost relacije, primarni sekundarni klju.
2.1.1 Pojam relacije u relacionom modelu Relacija, osnovni element relacionog modela ustvari je sinonim, uz neka ogranienja, za tabelu ili datoteku. E. F. Codd je u svom radu, kojim je po prvi puta promovisao relacioni model, pod relacijom definisao pravougaono podruje - tabelu koje se sastoji od kolona (atributa i vrijednosti atributa - podataka) te redova (n-torki, odnosno slogova sa podacima). Ovako definisana tabela predstavlja skup vrijednosti ali postoje i odre eni uslovi koje neka tabela mora da zadovolji da bi bila i relacija. Ti uslovi su:
25
a. Sve vrijednosti podataka jednog atributa moraju biti istog tipa.

Na primjer, sve vrijednosti atributa "dan_mjesec_godina" moraju biti datumi, sve vrijednosti atributa "plata" moraju biti numerikog, dakle brojnog karaktera, vrijednosti atributa "ime i prezime" moraju imati slovni (alfanumeriki) karakter itd.
Unutar jedne relacije, svaki atribut moe biti drugog tipa, to je sa stanovita raunarskog softvera kvalitativna novina koja je traila doradu i proirenje do tada poznatih programskih jezika (Fortran, Pascal, itd.), kod kojih je, u njihovim verzijama, matrina varijabla (dakle tabela) morala imati sve vrijednosti varijable (podatke) istog tipa (REAL, INTEGER, LOGICAL itd.). Svaki podatak u tabeli-relaciji predstavlja samo skup znakova i nita vie. Na osnovu jednog podatka u relaciji ne moe, i ne smije se, doznati niti zakljuivati nita o vrijednostima drugih atributa u istoj ili drugoj n-torci te relacije. Drugim rijeima: u relacionoj bazi podataka ne smiju postojati funkcionalne zavisnosti me u atributima. b. Unutar jedne relacije ne smiju postojati dvije identine n-torke, dvije n-torke sa identinim vrijednostima atributa identinim podacima. Ovo je logian zahtjev, jer dvostruko memorisanje podataka moe biti tetno (redundanca podataka), a nije ni potrebno. c. Redoslijed n-torki u relaciji je proizvoljan. d. Svi atributi unutar jedne relacije moraju imati razliita imena, dok je redoslijed njihovog navo enja tako e proizvoljan. 2.1.2 Entitet Entitet je dio model realnog svijeta opisan ogranienim brojem atributa.
26
2.1.3 Atribut Atribut je jedno od svojstava entiteta (objekta) kojeg posmatramo, i o kojem sakupljamo podatke. Svi podaci u jednom redu, jednom slogu, odnosno jednoj n-torci, definiu jednu jedinku datog objekta, dok jedna kolona opisuje jedno svojstvo svih jedinki. Na primjer, u objektu:
SLUBENIK < JMBG, ime, prezime, dat_ro , adresa, tel, > svaka n-torka sadri gore navedene podatke o jednom slubeniku, dok kolona JMBG, sadri jedinstvene matine brojeve svih slubenika tog preduzea.
Atributi u trenutku skupljanja podataka u relacionoj bazi podataka ne moraju obavezno imati poznate vrijednosti i u tom sluaju ih nazivamo Null - vrijednostima a treba ih, posebno ako ih u nekoj relaciji ima vie, izbjegavati.
Tako ne bi bilo racionalno u tabelu SLUBENIK uvesti i atribut "odlikovanja", jer se odlikovanja ne dijele masovno i nasumice (bar u civilizovanim zemljama), pa e za veinu slubenika u tom polju ostati prazno mjesto, to jest Null-vrijednost. Rjeenje problema bilo bi u kreiranju nove tabele, nazovimo je: ODLIKOVANJA < JMBG, medalja > a u kojoj bi se registrovali samo odlikovani slubenici sa njihovim matinim brojem (JMBG) i nazivom medalje koju su dobili, pa bi shodno tome relacija ODLIKOVANJA bila potpuno popunjena, a preko matinog broja JMBG bila bi povezana (u relaciji) sa osnovnom tabelom SLUBENIK i ostalim podacima o njemu.
Pri projektovanju informacionog sistema, u skladu sa potrebama, treba veoma paljivo i studiozno iz mnotva moguih atributa odabrati i definisati samo one koji opisuju objekat na, za nas, zadovoljavajui i prihvatljiv nain. Na primjer:
27
U sluaju objekta SLUBENIK kao atribut odabran je datum ro enja ("dat_ro ") sa namjerom posjedovanja podataka o starosnoj dobi svakog slubenika u preduzeu, a vjerovatno ne samo zbog mogunosti estitanja ro endana slubenicima od strane direkcije firme. Nije usvojen atribut "godine_starosti" jer bi to bilo loe rjeenje. Baza podataka morala bi se u tom sluaju svaki dan osvjeavati s obzirom da su svi slubenici svakog dana jedan dan stariji i uvijek postoji mogunost da ba toga dana neko od slubenika ima ro endan, da postaje i godinu dana stariji, to zahtijeva stalno auriranje baze, to jest izmjenu podatka u njoj. U sluaju kada je atribut "datum ro enja", taj podatak je konstantan, a godine starosti se bez problema mogu, za svakoga, u svakom trenutku, izraunati iz poznatog tekueg datuma.
2.1.4 Domen Domen je skup vrijednosti koje atribut moe da poprimi. Na primjer: U relaciji SLUBENIK, atribut "pol" moe da poprimi samo dvije vrijednosti, muko ili ensko, pa mu je domen dva. Domen za atribut "zvanje" ima onu vrijednost koliko ima razliitih zvanja slubenika angaovanih u toj firmi. Domen atributa "telefon" najvjerovatnije je jednak broju ntorki u relaciji (izuzev ukoliko dva slubenika ne koriste isti telefonski broj, ili ako ima slubenika bez telefonskog prikljuka). 2.1.5 Primarni klju Primarni klju, ili esto krae samo klju, je atribut (ponekad, ako je to neophodno, i skup, odnosno kombinacija atributa) ija vrijednost jednoznano definie samo jednu n-torku, samo jedan slog, u nekoj relaciji - tabeli, to znai da jednoznano izdvaja samo jedan red - jedan slog, u njoj.
28
Prema tome: U jednoj relaciji ne smiju postojati dvije razliite n-torke sa istom vrijednou kljunog atributa. Ukoliko ne postoji atribut koji zadovoljava uslove za kljuni atribut, klju se moe kreirati kombinacijom dva ili vie atributa. Primarni klju mora biti: jedinstven, nepromjenljiv i uvijek raspoloiv. Izbor primarnog kljua je veoma vaan jer se jedino preko njega moe pristupiti jednoj, i samo jednoj, n-torci u nekoj relaciji, pa uz poznati naziv atributa moemo tako pristupiti i jednom, i samo jednom, podatku posmatranog objekta. Primarni klju se esto obiljeava (markira) prilikom definisanja relacije. U literaturi se kljuni atribut najee oznaava znakom # iskljuivo iz razloga da bi tabela relacija bila preglednija za korisnika. Neki savremeni softverski paketi koji se koriste za upravljanje relacionom bazama podataka (ACCESS, na primjer) kao oznaku za klju koriste i doslovno znak kljua ( ).
Na primjer, u relaciji SLUBENIK, kandidat za primarni klju na naim prostorima je matini broj gra anina (JMBG), s obzirom da od svih navedenih atributa u relaciji SLUBENIK samo za matini broj moemo biti sigurni da je jedinstven, to jest da ne postoje dvije osobe sa istim matinim brojem. Takvu tvrdnju ne moemo, na primjer, izrei za ime, prezime, adresu ili telefonski broj. Ali ako u tom preduzeu moe biti angaovan i neki stranac (koji nema na JMBG) onda se za kljuni atribut mora traiti neko drugo rjeenje.
Relacija SLUBENIK sa obiljeenim kljuem glasi:

SLUBENIK < JMBG#, ime, prezime, dat_ro , adresa, telefon >
Ukoliko u nekoj relaciji nismo u stanju da "izdvojimo" kandidata za ulogu primarnog kljua, problem se rjeava na dva naina:
29
ili definisanjem grupe atributa (sloeni klju) koji onda imaju jedinstvenu vrijednost za svaki slog, ili uvo enjem novog, dodatnog, atributa, nazovimo ga jednostavno "ifra", pri emu se onda pogodnim izborom te ifre (na primjer, redni brojevi) obezbje uje njena jednoznanost.
Na kraju, napomenimo da neki savremeni softverski paketi (ORACLE, na primjer) doputaju da relacija sadri i identine n-torke, dakle da u relaciji ne mora biti definisan primarni klju. Razlog za to je unos podataka iz drugih izvora, na primjer iz programa za rad sa tabelama (EXCELL, na primjer), koji po pravilu nemaju mehanizme koji bi sprijeili pojavu duplikata (identinih vrijednosti kljunih atributa ili itavih n-torki). Naravno, postoje postupci pomou kojih se ovakvi zapisi mogu eliminisati iz tabela ako je to potrebno. Me utim, jedno je sigurno:
nepostojanjem primarnog kljua gubi se mogunost direktnog pristupa u nekoj relaciji jednoj i samo jednoj n-torci.
2.1.6 Spoljni (vanjski, strani) klju Spoljni klju (na primjer u relaciji A) je atribut koji u drugoj relaciji (na primjer B) ima ulogu primarnog kljua. Osnovna uloga spoljnih kljueva je uspostavljanje veza (relacija) me u tabelama, a ne identifikacija n-torki. Na primjer u relacijama:
BOLNICA < ifrabol#, naziv_bolnice, adresa, telefon,...> LJEKAR < ifraljek#, ifrabol, ime, prez, adresa,.....> "ifrabol#" je u relaciji BOLNICA primarni klju, a u relaciji LJEKAR atribut, i slui za povezivanje relacija. Na taj nain moemo, na primjer, za ljekara iju ifru poznajemo, dobiti telefonski broj bolnice u kojoj radi, unosei poznatu ifru bolnice (ifrabol#) iz njegove n-torke u relaciji LJEKAR, u relaciju BOLNICA (gdje je ifrabol# primarni klju), oitavajui nakon toga vrijednost atributa "telefon" u n-torci relacije BOLNICA.
30
Spoljni klju (naziva se jo i strani klju), moe, ali i ne mora se, posebno obiljeiti (sa ! ili $). I to se opet samo u tekstu, jer to obiljeavanje iskljuivo doprinosi vizuelnoj preglednosti modela. Jedino ako je strani klju ujedno i dio nekog primarnog sloenog kljua, onda ga treba obiljeiti uobiajenom oznakom (#) za primarni klju.
2.2 Codd-ova pravila

E.F. Codd je u svojim radovima definisao 12 pravila od kojih najmanje 6 mora biti ispunjeno da bi se informacioni sistem mogao smatrati relacionim. Ta pravila su rezultat teorijskog pristupa ovome problemu. S obzirom na obim ove knjige ograniimo se na definiciju 6 osnovnih pravila, ne uputajui se i u njihovo dokazivanje. Osnovno ili nulto pravilo koje predstavlja conditio sine qua non u relacionim bazama podataka glasi: Svaki sistem za upravljanje bazama podataka, koji se smatra, ili koji jeste, relacioni, mora imati mogunost upravljanja bazom podataka na relacioni nain i relacionim metodama. Ostala pravila su: 1. Predstavljanje informacija
Sve informacije u relacionoj bazi podataka moraju logiki biti predstavljene na isti nain: vrijednostima podataka u tabelama - relacijama.
2.
Logika dostupnost podacima

Svaki podatak mora imati atomarnu, nedjeljivu vrijednost, koja logiki mora biti dostupna korisniku uz pomo: imena relacije u kojoj se nalazi, vrijednosti primarnog kljua te relacije i imena atributa u toj relaciji.
31
3.
Mogunost prikazivanja nepostojee informacije

Relaciona baza podataka podrava koncept nultog podatka, (Null). Pod pojmom nultog podatka podrazumijeva se vrijednost atributa koja u datom trenutku nije poznata. To, dakle, nije vrijednost koja je predstavljena nulom, ili nizom nula, nizom praznih (blank) mjesta, ili nizom bilo kojih drugih znakova. To je jednostavno, trenutno nepoznata vrijednost podataka, i predstavlja specifikum i kontroverzniji aspekt relacionog modela informacionog sistema. Tako, na primjer, atribut "telefon" u relaciji SLUBENIK ima Null-vrijednost u trenutku primanja nekog slubenika u radni odnos ukoliko taj slubenik nema telefonski broj.
4.
Dinamiki katalog
Relaciona baza podataka mora biti tako prezentirana da autorizovani korisnici mogu primijeniti neki od relacionih jezika na podatke u njoj. Pod ovim se podrazumijeva: pristup sistemskim katalozima, pristup relacijama koje su u toku rada za stalno, ili samo na ogranieni vremenski rok prisutne i pristup relacijama koje se programski kreiraju (tzv. dinamiki katalozi) a koji sadre nove informacije.
5.
Softverski paket za manipulaciju bazom podataka

Softverski paketi omoguavaju manipulisanje podacima u relacionoj bazi podataka, i oni su manje ili vie prilagoeni korisniku - manipulatoru. Svaki od njih sadri programski jezik koji pomou definisane sintakse, i na korisniku blizak nain, omoguava:
32
definisanje tabela, definisanje atributa, unoenje podataka, definisanje proizvoljnog pogleda definisanje proizvoljnog upita, manipulaciju podacima, postavljanje ogranienja korisnicima, autorizaciju korisnika, te upravljanje proizvoljnim transakcijama.
6.
Nezavisnost integriteta baze

Nijedno ogranienje integriteta (sigurnosti ouvanja podataka) ne smije se pri organizaciji logikog modela relacione baze podataka nai u aplikativnom dijelu softverskog programa dostupnom irem broju korisnika, nego iskljuivo u dijelovima koji su pod kontrolom administratora baze. Drugim rijeima, pravila integriteta se definiu u okviru sinteze baze podataka.
Nakon objavljivanja Codd-ovog rada veliki broj autora nastavio je da sa bavi teorijom i praksom sinteze i eksploatacije baze podataka. Tako je naknadno, nakon 12 Cood-ovih pravila definisano jo est dodatnih a mogu se nai u strunoj literaturi.1
2.2 Ogranienja i pravila pri projektovanju

U relacionom modelu potrebno je u pojedinim relacijama ograniiti vrednosti nekih atributa. Ve postojanje domena atributa predstavlja odre eno ogranienje (starost, cijena, itd...). Ali postoje i tzv. opta ogranienja koja vae za svaki relacioni model i koja se nazivaju pravilima integriteta relacionog modela. To su:
Ratko Vujnovi: SQL Relacijski model podataka, Znak, Zagreb 1996.

33
1. Integritet entiteta: Nijedan atribut koji je primarni klju ili dio primarnog kljua, ne smije nikada da uzme null vrijednost. 2. Referencijalni integritet: Skup vrijednosti spoljnjeg kljua relacije R1 mora biti podskup skupa vrijednosti primarnog kljua relacije R2 sa kojom se povezuje R1. Relacije R1 i R2 moraju biti razliite. Pored ogranienja koja su zadana strukturom modela, mogu se, za bolju specifikaciju semantike, iskazati dodatna, eksplicitna ogranienja. Na primjer:
Neka jednostavna ogranienja mogu se iskazati preko definicije domena atributa (ocena na ispitu mora biti vea ili jednaka 5 a manja ili jednaka od 10). Neka sloenija ogranienja oznaavaju poslovni integritet. Na primjer, student da bi upisao narednu godinu, na nekim fakultetima mora poloiti sve ispite iz prethodne godine, a na nekim moe prenijeti dva ispita.
Ostala pravila kojima se definie kvalitet, i koja mora da ispuni svaki sistem za upravljanje bazama podataka da bi se smatrao relacionim, mogu se ukratko saeti kao:
a. programskim jezikom tree generacije ne smiju se zaobii pravila integriteta definisana relacionim jezikom. b. mora postojati mogunost kreiranja "pogleda" na bazu podataka i definisanja operacija nad njima te izvravanja operacija odravanja baze podataka. c. aplikacioni programi2 moraju ostati nepromjenjeni ako se promjene bazne relacije u sistemu (sem u sluaju promjene strukture tabela); d. aplikacioni programi moraju ostati nepromjenjeni i ako se promjeni fizika organizacija baze podataka ili fiziki metod pristupa;
2
Programi kojima se korisniku omoguava jednostavno korienje nekog informacionog sistema

34
Naalost, danas je situacija takva da veina sistema za odravanje baza podataka ne zadovoljava sve navedene kriterijume. Problemi koji se javljaju uvijek su u vezi odravanja integriteta baze. Da rezimiramo: relacioni model je danas dominantan zahvaljujui strogoj matematikoj teoriji na kojoj se bazira. Softverski paketi, koji se koriste u manipulisanju relacionim bazama podataka me usobno su slini pa korisnik, koji je savladao jedan, sa malo truda moe da se prebaci i na neki drugi. Uvo enjem tehnike objektnog programiranja, dizajn aplikativnih programa postao je blizak korisniku, jer veina novih paketa sadri podprograme prilago ene manipulaciji podacima, kao i gotove "generatore" za razne obrasce, izvjetaje i aplikacije. Hardverska konfiguracija savremenih personalnih raunara omoguava postavljanje i najveih softverskih paketa (ORACLE, na primjer) na danas ve praktino standardnim konfiguracijama personalnih raunara.
2.3 Distribuirane baze podataka

Pod distribuiranom bazom podataka smatra se informacioni sistem koji radi u raunarskoj mrei i koji ima najmanje dva dislocirana raunara, sa dislociranim tabelama, u kojima se nalaze podaci. Distribuirane baze podataka zbog svoje kompleksnosti donose i niz problema, kako u njihovom projektovanju, tako i u eksploataciji. Pri tome, do danas jo nije u potpunosti razvijena matematika teorija koja bi podravala ovakve sisteme to donekle oteava njihovu sintezu posebno u smislu tajnosti i privatnosti. Osnovni problemi na ijem rjeavanju se danas radi su:
pravo pristupa (ko, kada i kojim podacima moe pristupiti), ouvanje podataka (ko ima pravo promjene podataka), i potpuna tajnost podataka.
35
Organizacija distribuiranih baza podataka je tako postavljena da se globalni informacioni sistem sastoji od vie lokalnih baza podataka, a uvijek postoje najmanje dva upravljaka nivoa, sistema, i to:
lokalni upravljaki sistem (LDBMS - Local Database Management System), i globalni sistem (DDBMS - Distributed Database Management System).
Pomenuti sistemi su iskljuivo logiki, dakle me usobno su samo softverski povezani, tako da korisnik distribuirane baze podataka sa svog radnog mjesta, sa svog raunara, ne vidi tu distribuiranost i ima osjeaj da je povezan samo sa jednim centralizovanim informacionim sistemom. Evolucija naina obrade zajednikih podataka tekla je od obrade na jednom centralnom raunaru, preko obrade na nepovezanim raunarima, do obrade podataka u mrenom okruenju, u poetku sa serverom3 datoteka, a danas sa distribuiranom obradom.
Kod prvog modela sa centralnim raunarom serverom, podaci i aplikacije su se nalazili na jednom centralnom raunaru (host), a zaposleni su mu pristupali preko glupih terminala na kojima nije postojala mogunost obrade. Aplikacije su pri tome obino podjeljene na dva dijela:
eoni dio (front end) odgovoran za komunikaciju sa korisnikom i pozadinski dio (back end) odgovoran za upravljanje podacima.
Prednosti ovakvog rjeenja su:

lako administriranje, pouzdanost podataka brz pristup, zatita podataka (rezervne kopije) i zajedniko korienje skupih periferijskih ure aja.
Centralni, glavni raunar koji upravlja raunarskom reom

36
Mane ovoga rjeenja su:

potreba za inoviranjem centralnog raunara te, mali broj proizvo aa namjenskih raunara (visoke cijene).
Obrada podataka na nepovezanim personalnim raunarima poinje pojavom personalnih raunara na tritu i operativnih sistema DOS, Unix i Windows kada je veliki broj proizvo aa ovakvih raunara oborio cijene i uinio ih dostupnim velikom broju korisnika. Rad na samostalnim radnim stanicama ima mnogo prednosti:
jeftine su i jednostavne za upotrebu, korisnik sam prilago ava radnu stanicu svojim potrebama, dostupno je mnotva "alata" i aplikacija od raznih proizvo aa.
Naravno, ima i nedostataka mana. To su:

podaci su raspodijeljeni na vie raunara, podaci na jednoj stanici su autonomni i korisnik je odgovoran za upravljanje podacima, podaci na jednom raunaru nisu uvijek dostupni svim korisnicima kojima mogu zatrebati jer se ne mogu koristiti zajedniki skupi ure aji.
U posljednjih desetak godina trend razvoja raunarske tehnike ide u pravcu stvaranja veih, globalnih raunarskih mrea. U prvo vrijeme su to bile lokalne mree (u okviru fakulteta, ustanove, preduzea itd.), zatim je dolo do njihovog povezivanja (na nivou univerziteta, industrijskog koncerna, itd.), da bi se konano dolo i do globalnih svjetskih mrea (danas je najpoznatija od njih - Internet). Da bi mogli da koriste zajednike podatke u lokalnoj mrei datoteke se smjetaju na server datoteka (file server). To je samostalan raunar koji je obino centralno vorite preko kojeg se koriste zajedniki resursi (na primjer diskovi i tampai). Program za upravljanje bazom podataka, izvrava se na svakoj radnoj stanici u mrei, a uzima podatke sa servera i kasnije ih vraa i kopira opet na server.
37
Ovaj koncept nije dobar kod viekorisnikih aplikacija jer sistem sa serverom ne doputa istovremeno viestruko pristupanje istom skupu podataka (data concurrency), veliki je "saobraaj" na mrei kada mnogo korisnika radi, i zato lako dolazi do zaguenja. injenica da je korisnik raunara koji je u mrei u stanju da, uz poznavanje odgovarajuih lozinki i kljunih rijei, pristupi praktino svakom raunaru i svakom podatku u toj mrei, odrazila se i na daljni razvoj informacionih sistema jer se podaci vie ne nalaze na jednom mjestu, oni su distribuirani, a korisnik treba da zna kako i gdje da ih prona e. Dakle dolazi se do obrade po modelu klijent/server, odnosno do distribuirane obrade aplikacija (distributed application processing) koja objedinjuje dobre strane obrade u mrenom okruenju sa visokim performansama centralizovanih sistema. Ovi sistemi su vieslojni i sadre tri komponente:
server baze podataka, aplikacije klijenata i mreu.
Serveri (back end) obezbje uju efikasno upravljanje resursima posebno u uslovima kada vie klijenata istovremeno zahtijeva isti resurs. Oni obezbje uju:
upravljanje bazom podataka, kontrolu pristupa (i bezbjednost podataka) i centralizovano zadovoljenje pravila integriteta.
Aplikacija - klijent (front end) omoguava svim korisnicima komforan rad sa podacima a obezbje uje:
najpogodniji interfejs prema korisniku za odre enu vrstu obrade, upravlja nainom prikaza podataka korisniku, izvrava logiku aplikacije, proverava ispravnost ulaznih podataka i trai i prihvata podatke od servera.
38
Dio ovih aktivnosti u distribuiranoj obradi (poslednje tri) mogu se realizovati i kao poseban sloj u obradi podataka pa mogu biti locirane blie serveru, takozvani aplikacioni server (application server). Ovo je srednji sloj (midle tier), vieslojne arhitekture, pa ovakvi sistemi imaju i odre enih prednosti. To su rije svega:
svaki raunar u sistemu moe biti izabran posebno, tako da najbolje ispunjava zahteve obrade, sistem je fleksibilan i otvoren u pogledu izmena hardvera i softvera i sistem se lako moe proirivati.
Na kraju, treba istai i mogunost specijalizacije i zasebnog razvoja svake funkcionalne komponente kao i upotrebu grafikog radnog okruenja i objektno orijentisanih alata.
39
Glava 3
3.0 Osnove relacione algebre - uvod
Za manipulisanje podacima i tabelama u relacionim bazama podataka potrebna su osnovna znanja iz relacione algebre. Relaciona algebra spada u matematiku oblast teorije skupova, relativno je nova disciplina, i na njoj se bazira relacioni model baze podataka. Operatori relacione algebre dijele se u dvije grupe i to:
- osnovni operatori, - operatori pridruivanja.
Relacioni operatori su sa stanovita matematike teorije operatori visokog nivoa jer operiu sa relacijama, dakle sa skupovima vrijednosti (tabelama), a ne samo sa jednom, i kao rezultat daju opet relaciju skup vrijednosti novu relaciju. E.F.Codd je u svome radu relacione operatore podijelio u dvije grupe i to:
- tradicionalne operatore - koji su pogodni za auriranje - specijalne operatore - koji su pogodni za izvjetavanje.
39
40
3.1 Tradicionalni operatori

Tradicionalni operatori izvode se nad minimum dvije relacije. To su:
unija (UNION), presjek (INTERSECT), razlika (DIFFERENCE), proizvod (CARTESIAN PRODUCT).
3.1.1 Unija Unija dva skupa, dvije relacije A i B, je relacija koja se sastoji od svih elemenata koji pripadaju relacijama ili A ili B. Svaka relacija je po definiciji skup n-torki, pa je i unija dvije relacije skup n-torki, ali ne mora u optem sluaju biti i relacija. Relacija, naime, ne smije sadravati razliite tipove n-torki pa se teoretski moe napraviti unija od dvije relacije koja ima razliite atribute. Rezultat je u tom sluaju tabela, ali nije i relacija. Da se ovo ne bi desilo definiu se i ogranienja koja moraju biti zadovoljena kako bi nad dvije relacije bila izvodljiva operacija unija, a da rezultat pri tome opet bude relacija. Za takve relacije se kae da su union-kompatibilne. Ta ogranienja su:
1. obje relacije moraju imati iste atribute, 2. isti atributi moraju biti definisani nad istim domenom.
Operacija unija nad relacijama A i B simboliki se oznaava sa: AB.

Primjer: Unija dvije relacije A i B:
A
IFRA # 3244 1772 PREZIME Aksentijevi Maksimovi IME Petar Ilija TEL. BROJ 0710 334 952 015 723 543
B
IFRA # 3244 2345 40 PREZIME Aksentijevi Petrovi IME Petar Dara TEL. BROJ 0710 334 952 081 17 318
41
je relacija (C=AB) sa istim atributima i eliminisanim viestrukim, identinim, n-torkama dakle:
C=AB
IFRA# 3244 1172 2345 PREZIME Aksentijevi Maksimovi Petrovi IME Petar Ilija Dara TEL:BROJ 0710 334 952 015 723 543 081 17 318
3.1.2 Presjek Presjek dvije relacije A i B (oznaava se sa AB ) je nova relacija koja sadri sve n-torke koje su zajednike za obje relacije.
U prethodnom primjeru to je telefonski pretplatnik sa ifrom 3244, jer je on prisutan u obje relacije:
C = AB
IFRA # 3244 PREZIME Aksentijevi IME Petar TEL. BROJ 0710 334 952
3.1.3
Razlika Razlika A - B dvaju relacija (razlika se oznaava i sa A/B ) je nova relacija koja ima iste atribute kao i relacije A i B, a tijelo se sastoji samo od onih n-torki koje se nalaze u relaciji A, a ne nalaze u B. Prema tome za razliku vai pravilo: A B B A.
U prethodnom primjeru rezultat razlike bio bi shodno tome:
A B ili (A / B)
IFRA # 1772 PREZIME Maksimovi IME Ilija TEL. BROJ 015 723543 543
B A ili (B / A)
IFRA # 2345 PREZIME Petrovi IME Dara TEL. BROJ 081 17318 41
42
3.1.4 Proizvod Pojam proizvoda u relacionoj algebri je neto iri od pojma prostog Dekartovog, odnosno Kartezijevog proizvoda. Naime, Kartezijev proizvod dva skupa A i B, definie se kao skup ure enih parova u kojem prvi element pripada skupu A, a drugi skupu B. U relacionoj algebri, me utim, uvijek elimo da dobijemo ure en skup n-torki, a ne ure en skup parova, pa se stoga definicija Kartezijevog skupa proiruje na taj nain to se umjesto skupa elemenata uzima skup n-torki, pri emu je svaka tako novodobijena n-torka rezultat spajanja ure enog para n-torki. Treba napomenuti da kod izvo enja proizvoda dvije relacije postoji opasnost da do e do greke ukoliko te dvije relacije imaju atribute sa istim imenima, a nemaju isto znaenje.
Ilustracije radi pogledajmo primjer proirenog Kartezijevog proizvoda relacija ALFA i BETA
ALFA
A B
BETA
C D E
ALFA*BETA
A B C D E
a1 a2 a3
b1 b2 b3
c1 c2
d1 d2
e1 e2
a1 a1 a2 a2 a3 a3
b1 b1 b2 b2 b3 b3
c1 c2 c1 c2 c1 c2
d1 d2 d1 d2 d1 d2
e1 e2 e1 e2 e1 e2
Ali ako bi eljeli da napravimo proizvod relacija:

PROFESOR <ifra#, ime, prezime, zvanje, adresa, ..... > i STUDENT <ifra#, ime, prezime, adresa,.....>
to ne bi bilo mogue, jer se imena atributa (ime, prezime i adresa) ponavljaju. Rjeenje u ovakvim sluajevima je u preimenovanju atributa u jednoj od relacija, na primjer u relaciji STUDENT: STUDENT <ifrast#, imest, prezimest, adresast,.......>
42
43
3.2 Specijalni operatori

U specijalne operatore spadaju:
selekcija, projekcija, spajanje, dijeljenje.
3.2.1 Selekcija
Selekcija, ili kako se jo naziva ogranienje ili restrikcija, izdvaja iz relacije samo one n-torke koje zadovoljavaju zadani kriterijum (uslov), koji je definisan logiki. N-torke u kojoj je taj logiki uslov zadovoljen, definiu onda novu relaciju.
Na primjer, nad relacijom ROBA: ROBA < ifra#, naziv, proizvo a, datum, adresa,....> moemo napraviti selekciju po atributu "adresa", i tako iz relacije ROBA izdvojiti samo one n-torke za koje je vrijednost atributa "adresa" neka unapred zadana, na primjer: adresa = Trebinje Na taj nain dobijamo novu, izvedenu relaciju, koja onda mora imati i novo ime.
Treba naglasiti da upit kojim se vri selekcija mora uvijek biti logian i izvodljiv. U protivnom se selekcija ne moe provesti. 3.2.2 Projekcija Projekcija relacije daje novu relaciju koja se sastoji samo od odreenih (ili samo jednog) atributa zadane relacije. Rezultat operacije projekcija je podskup izabranih atributa neke relacije sa svim njenim ntorkama. Na primjer:
Projekcija relacije ROBA iz malopre anjeg primjera po atributima ifra#, naziv i adresa proizvo aa bila bi:
43
44
ROBA1 < ifra#, naziv, adresa > a imala bi isti broj n-torki kao i relacija ROBA, s obzirom da ne mogu postojati dvije n-torke u relaciji ROBA sa istom ifrom.
esto se deava da se primjenom projekcije, iz nesmotrenosti, mogu izgubiti neki podaci jer u novonastaloj tabeli mogu da se pojave identine n-torke (to u sluaju selekcije nije moglo da se desi), koje onda u nekim softverskim paketima bivaju bez upozorenja brisane, kako bi dobijeni rezultat ponovo bila relacija.
Na primjer, projekcija relacije: STUDENT < broj_ind#, ime, prezime, ime_oca, dat_rod,... > po atributu "broj_ind#" ima sigurno isti broj n-torki kao i relacija STUDENT s obzirom da ne postoje dva studenta sa istim brojem indeksa. Ali, projekcija po atributu "ime" imae po svoj prilici manji broj slogova jer postoji velika vjerovatnoa da e se pojaviti dva ili vie studenta sa istim imenom, pa e u projektovanoj relaciji ostati samo jedno od njih jer se identine n-torke eliminiu.
3.2.3 Spajanje (join) Operacija spajanja ima vie podvrsta od kojih su dvije najvanije:
prirodno spajanje, spajanje pod nekim uslovom.
Prirodno spajanje relacija A i B daje relaciju AB koja ima sve atribute relacije A, i one atribute relacije B koje nema relacija A.
Na primjer, relacije A i B A < x1, x2, x3,....xn, y1, y2,....ym > B < y1, y2,...,ym, z1, z2,....zp > spojene prirodno daju relaciju AB: AB < x1, x2,.....xn, y1, y2,.....ym, z1, z2,.....zp > ili, relacije ALFA i BETA:
44
45
ALFA
IFRAD# d001 d002 d003 NAZIV Comex Unita Dual MJESTO Toronto Vancouver Beograd
BETA
IFRAD# d001 d002 d003 IFRAP# p991 p678 p007 BROJ KOM. 324 23 12564
spojene prirodnim spajanjem daju kao rezultat relaciju GAMA
GAMA
IFRAD# d001 d002 d003 NAZIV Comex Unita Dual MJESTO Toronto Vancouver Beograd IFRAP# p991 p678 p007 BROJ KOM. 324 23 12564
Ako relacije koje se prirodno spajaju nemaju nijedan zajedniki atribut, onda operacija prirodnog spajanja prelazi u Kartezijev proizvod. Spajanje pod nekim uslovom () izvodi se nad relacijama samo onda kada one nemaju nijedan isti atribut. Rezultat spajanja je u tom sluaju Kartezijev proizvod tih relacija koji sadri samo one n-torke koje zadovoljavaju logiki uslov definisan izrazom (), pa se ovakav nain spajanja zato i naziva -spajanje. 3.2.4 Operacija dijeljenja Dijeljenje se ne moe izvesti sa proizvoljnim relacijama - tabelama. Da bi operacija A podijeljeno sa B (A:B) bila izvodljiva, potrebno je da se svi atributi relacije B nalaze i u relaciji A.
Na primjer, ako imamo dvije relacije A i B: A < x1, x2,....,xn, y1, y2,..., ym > ; B < y1, y2,..., ym >
45
46
(koje zadovoljavaju postavljeni uslov), rezultat dijeljenja e biti relacija C koja ima samo x-atribute, a tijelo joj se sastoji od onih n-torki relacije A za koje se vrijednosti y-atributa pojavljuju u relaciji B. Dakle: A
X# 017 033 077 061 044 Y# a22 a43 a86 a43 a43
C
Y# a43
X# 033 061 044
3.3 Dodatni operatori

Pored navedenih operatora u modernoj relacionoj algebri postoji jo nekoliko dodatnih, izvedenih, operatora koje su definisali autori poslije E.F.Codda jer se pokazalo da osam osnovnih nije uvijek moglo zadovoljiti sve zahtjeve. Tako se danas koriste jo i operatori:
proirenja, agregacije, uoptenog dijeljenja, spoljnjeg spajanja uslovni operator (MAYBE).
Najinteresantniji od njih je operator MAYBE koji se koristi za manipulisanje Null vrijednostima, i predstavlja proirenje klasine logike algebre. Naime, u klasinoj logikoj algebri postoje samo dvije mogue vrijednosti, dva stanja, koje logika varijabla, ili izraz, mogu uzeti. To su:

Uvo enjem Null vrijednosti definisana je jo jedna, trea, mogunost, oznaimo je sa U (unknow - nepoznato) pa logike operacije AND, OR i NOT rezultiraju sada sa tri stanja i to:

46
istina (TRUE) la (FALSE).
T (TRUE), F (FALSE) U (UNKNOWN).
47
Definicija logike tri stanja nije jo opteprihvaena, ali se najee koristi ona koju je predloio E.F.Codd po kojoj operator MAYBE daje rezultat TRUE uvijek onda kada je rezultat neke operacije nepoznat. Priloeni grafiki prikaz daje definiciju najvanijih operatora. AND
T F U T T F U F F F F U U F U
OR
T F U T T T T F U T T F U U U
MAYBE
T F U F T U
NOT
T F U F F T
Unija
Presjek
Razlika A-B Razlika B-A
Restrikcija
Selekcija
Prirodno spajanje
A A A A 1 2 3 4 B B B B 1 2 3 4
B B B B
1 2 3 4
C C C C
1 2 3 4
A A A A
1 2 3 4
B B B B
1 2 3 4
C C C C
1 2 3 4
47
48
48
49
Glava 5
5.0 Sinteza relacionog modela - uvod
Relacioni model baze podataka sastoji se od dva dijela i to:
logikog i fizikog modela.
Logiki model baze podataka nastaje kao rezultat:

analize postojeih i / ili dobijenih novih podataka, definisanja tabela (relacija) i veza me u njima, te dovo enja modela na relacioni oblik,
uz prethodno definisanu:
strukturu i oblik podataka koji e initi sadraj baze..
Fiziki model baze podataka odre uje kako su podaci memorisani na memoriji raunara i kako se njima manipulie - danas najee na disku. Problemu sinteze logikog modela pristupa se na dva naina i to:
49
50
ili
preko modela objekat-veze (MOV, Entity-Relationship Model, skraeno E-R model), postupkom normalizacije tabela,
pri emu treba naglasiti da jedan pristup ne iskljuuje drugi, nego se naprotiv, esto, me usobno i dopunjuju.
5.1 E-R model

Ovaj pristup sintezi relacione baze podataka prikazan je po prvi puta u radu: CHEN, P. P. The Entity Relationship objavljenom 1976. godine. Najkraa definicija ovog postupka bi bila:
dobijanje saznanja o objektima, vezama me u njima, te njihovim svojstvima.
Chen je predloio da se model nazove E-R model (Entity Relation, (entiteti relacije) to jest, objekti i veze me u njima). U naoj literaturi ovaj model se naziva i MOV (skraenica od Model Objekat-Veze). 5.1.1 Osnovne definicije i pojmovi E-R modela U pomenutom radu Chen je uveo nekoliko novih pojmova koji u sutini ne mijenjaju nita u osnovi u Cood-ovog relacionog modela, ali umnogome olakavaju i ubrzavaju njegovu optimalnu sintezu. Objekte opisane atributima Chen je podijelio na:
u uem smislu rijei, te objekte veze, vezne objekte.
5.1.2 Objekti Status objekta u E-R modelu imaju oni entiteti koji pored identifikatora objekta (primarnog kljua) imaju jo i neka svojstva koja se opisuju atributima.
50
51
Atribut je svojstvo objekta koje se opisuje jednim podatkom. Ukoliko je za opisivanje atributa potrebno vie podataka, onda taj atribut predstavlja novi objekat. Na primjer:
Neka je objekat PRODAVNICA opisan atributima: PRODAVNICA < ifraprod#, naziv, djelatnost , grad > Objekat PRODAVNICA, definisan na ovaj nain, je entitet koji ima svoj identifikator - klju (ifraprod#) i tri atributa (koji opisuju njegova svojstva koja su od znaaja za poslovanje). U sljedeem koraku treba utvrditi da li svi atributi zadovoljavaju postavljeni kriterijum. Ako pretpostavimo da je: ifra prodavnice jednoznana (to mora biti), da svaka prodavnica ima samo jedno ime, te da ima definisanu djelatnost,
onda su i atributi naziv i djelatnost atributi. Me utim, ako za atribut grad pored imena postoji i podatak o broju stanovnika u tom gradu (to je sa gledita profitabilnog rada nekog lanca trgovina i te kako vaan podatak), onda grad ne moe biti atribut jer ga opisuju dva podatka (naziv i broj stanovnika). Grad predstavlja stoga objekat koji mora biti definisan, na primjer kao: GRAD < ifragrada#, naziv, brojstan. > a u datoteci PRODAVNICA atribut grad se brie. Na kraju,treba jo ustanoviti i definisati vezu izme u tih objekata (PRODAVNICA, GRAD) o emu e jo biti rijei.
Generalno, objekti u ER-modelu mogu se podijeliti na:

vrste objekte, - objekti u punom smislu te rijei, i slabe objekte koji na neki nain (egzistencijalno ili identifikaciono) zavise od jednog ili vie vrstih objekata.
Pod vrstim objektom smatra se onaj koji se moe potpuno definisati primarnim kljuem i nizom atributa. To su, na primjer, objekti:
STUDENT < brind#, prez, ime, datrodj, adresa, tel, ...... > RAUN < brojrauna#, datum, iznos ......> HOTEL < ifrahotela#, naziv, adresa, tel, ........> .
51
52
Pod slabim, egzistencijalno i/ili identifikaciono zavisnim objektom, smatra se onaj koji egzistencijalno i/ili identifikaciono zavisi od nekog drugog, vrstog, objekta. Na primjer, objekat STAVKA nekog rauna:
STAVKA < brojstavke#, kolicina, cijena, .....>
moe biti prisutan samo onda ako pripada nekom raunu. RAUN je vrst objekat, a STAVKA je slabi objekat koji moe postojati samo ako postoji odgovarajui RAUN (egzistencijalna zavisnost). Na ovaj nain definisan objekat STAVKA nije samo egzistencijalno, nego i identifikaciono zavisan od vrstog objekta RAUN, jer stavke iz raznih rauna mogu imati isti broj (istu ifru), pa ih prema tome ne bi bilo mogue jednoznano identifikovati i me usobno razlikovati bez navo enja i broja rauna kojem ta stavka pripada. Korektno se objekat STAVKA stoga mora definisati uz RAUN kao:
RAUN < brojrauna#, iznos,.........> STAVKA < brojstavke#, brojrauna#, koliina, cijena, ..... >
Zakljuak: Slabi objekti moraju imati sloen primarni klju koji se sastoji od kljua slabog objekta, i kljua jakog kome pripadaju. 5.1.3 Veze Oigledno je da u malopre anjem primjeru datoteke PRODAVNICA i GRAD nisu nezavisne jer se svaka prodavnica odnosi na grad u kojem se ona nalazi. Neophodno je, prema tome, ova dva objekta meusobno povezati. Nazovimo tu vezu me u njima u ovom konkretnom sluaju "lokacija" (vidi sliku 5.1).
ifrapr. naziv
PRODAVNICA
vrsta
ifragr.
ime
GRAD
brojst.
N Lokacija
5.1 E-R model sistema prodavnica

52
53
Vezu izme u GRADA i PRODAVNICE ini "lokacija", nalazi se izme u GRADA i PRODAVNICE a tip uspostavljanja veze (mogue varijante, vidjeli smo, su 1:1, 1:N ili M:N ) mora biti poznat. U konkretnom sluaju, ako u gradu moe biti vie prodavnica, a odreena prodavnica moe biti samo u jednom gradu, tip veze je 1:N.
Ako je veza "lokacija" jo i opcionalna, dakle neobavezna, (svaki grad moe, ali ne mora, imati prodavnicu posmatranog lanca trgovina), onda tu injenicu oznaavamo na strani veze koja je neobavezna kruiem (slika 5.1). Treba ponovo naglasiti da su veze najee rezultat zakonskih propisa, dogovora, ugovora, statuta, raznih internih normi, itd. pa ih u toj oblasti treba i "traiti" a rje e posljedica prirodnih zakona. Vezu, da bi je u ER modelu razlikovali od objekta, predstavljaemo grafiki rombom. Veze tipa 1:1 i 1:N, ne mogu imati i vlastite atribute kojima se poblie opisuju. 5.1.4 Vezni objekti
Da bi se veze tipa N:M u ER-modelu eliminisale, prevode se, pod odre enim uslovima u novi objekat, daju im se svojstva objekta, ime takve veze postaju vezni objekti koji onda mogu imati i sva svojstva objekta, imaju prema tome i identifikator (klju), a mogu, ali i ne moraju, imati i atribute. Definisanje tipa veze je stoga osnovni preduslov da se E-R modelom realno prikae stanje stvari. Kada se pri sintezi ER-modela pokae da su veze tipa N:M neminovne (jer egzistiraju u realnom svijetu), "eliminacija" ovih veza iz modela izvodi se na sljedei nain:
svaka veza tipa N : M zamjenjuje se novim objektom (najee istog naziva kao i veza N : M koja se zamjenjuje) sa sloenim kljuem identifikatorom - koji se sastoji od kljueva objekata koje je veza tipa N:M povezivala. nakon toga se novi objekat povezuje vezama 1 : N sa postojeim.
53
54
Na primjer, objekti NASTAVNIK i STUDENT vezani su N:M jer:

- jedan nastavnik komunicira sa vie (N) studenata, a svaki student komunicira sa vie (M) nastavnika
ER model (slika 5.2) sadri tu vezu (nazovimo je nastava) koju treba eliminisati, tanije zamijeniti vezama tipa 1:N.
nastavnik nastava student
Slika 5.2 ER-model veze N:M
Zamjena veze nastava, veznim objektom NASTAVA, izvodi se uvo enjem dvije nove veze tipa 1:N izme u NASTAVNIKA i NASTAVE (nazovimo je "izvodi") i STUDENT-a i NASTAVE (nazovimo je "slua"). Tako dobijamo nov oblik ER-modela (bez N:M veze) slika 5.3.
nastavnik izvodi nastava slua student
Slika 5.3 Transformisani ER-model veze N:M
Novouvedeni objekat (NASTAVA) mora imati sloen klju koji se sastoji od kljueva objekata koje povezuje. Pored toga, vezni objekat moe, ali ne mora, imati i jo neke atribute koji ga opisuju poblie. Na primjer, objekat NASTAVA moe imati atribut koji daje termin kada se nastava (nastavnika sa ifrom ifran# i studenta sa ifrom broj_indeksa#) izvodi. Prema tome relacioni model moe imati sljedei oblik:
NASTAVNIK < ifran#, ime, prezime, adresa, telefon..........> STUDENT < broj_indeksa#, ime, prezime, adresa, telefon.........> NASTAVA <ifran#, broj_indeksa#, termin_predavanja,.........>
Objektu NASTAVA moe se dodijeliti (po elji) i vlastiti klju, ali dva spoljna kljua moraju i tada ostati kao atributi. Na primjer:
NASTAVA <ifranastave#, ifran, broj_indeksa, termin_predavanja,..>
54
55
5.1.5 Osobine veza Pored tipa veze, svaku vezu karakteriu jo dvije osobine i to:
a. b. Red veze, Nain uspostavljanja veze,
a. Red veze Red veze odre uje broj objekata koji ine neku vezu. U praksi se najee javljaju:
unarne, binarne, trojne veze
(slika 5.4), ali se mogu javiti i veze reda vieg od tri (n > 3) koje se zbog nepreglednosti E-R modela u praksi izbjegavaju uvijek kada je to mogue svo enjem na veze nieg reda.
unarna binarna trojna
Slika 5.4 Unarna, binarna i trojna veza
a1. Unarne (ili unutranje) veze su relativno rijetke u praksi, a uspostavljaju se unutar jedne tabele, jednog objekta. Na primjer:
Neka osoba u optinskoj datoteci GRA ANIN (koja sadri uobiajene podatke kao sto su ime, prezime, godina ro enja, mjesto ro enja, kolska sprema, brano stanje itd.) moe (veza je opcionalna nije obavezna) da se nalazi u branoj vezi sa drugom osobom u istoj datoteci, ili Neki takmiar, u disciplini takmienja parova (na primjer u umjetnikom klizanju, ili tenisu) u datoteci TAKMIAR, nalazi se u unarnoj vezi (ova veza je obavezna jer u parovima ne moe da nastupi jedan takmiar sam) sa partnerom iz iste datoteke.
55
56
a2. Binarna veza je veza izme u dva objekta i najee se susree u praksi. Takva veza postoji, na primjer, izme u objekata:
- GRAD i PRODAVNICA, - NASTAVNIK i PREDMET, - VOZAC i VOZILO itd.
a3. Trojna veza nastaje proirenjem binarne veze. Na primjer, binarna veza NASTAVNIK i PREDMET mora se nekada proiriti i literaturom koju nastavnik koristi na svom predmetu. U tom sluaju potrebno je uvesti i trei objekat LITERATURA. Novonastala trojna veza (nazovimo je DISCIPLINA) iskazana rijeima glasi: Nastavnu DISCIPLINU ine:
PREDMET koji se predaje LITERATURA po kojoj predaje, i NASTAVNIK koji je predaje,
Veze reda veeg od 3 iskazuju na slian nain odnos izme u vie od tri entiteta. Analiza im je identina trojnim vezama, ali zbog nepreglednosti modela u praksi se izbjegavaju. b. Nain uestvovanja u vezi Nain uestvovanja (prisustva) objekata u vezi moe bitidvojak i to:
obavezan, i neobavezan (opcionalan).
b1. Obavezno prisustvo smatramo da postoji onda kada jedan objekat mora biti povezan sa drugim objektom. Na primjer, GRAD se mora nalaziti na nekoj LOKACIJI. b2. Opcionalna, neobavezna, veza postoji onda kada prethodni uslov nije zadovoljen. Na primjer, svaki RADNIK moe biti ZADUEN nekim POSLOM, ali mogu postojati i takvi poslovi za koje trenutno nije ZADUEN nijedan RADNIK. Veza ZADUEN izme u objekata RADNIK i POSAO prema tome bila bi opcionalnog karaktera. Posmatrajmo sada detaljnije ponaanje i karakteristike objekata u binarnim i trojnim vezama.
56
57
Uzmimo za primjer bazu podataka obrazovne ustanove u kojoj treba povezati objekte NASTAVNIK i PREDMET a pod uslovom koji je definisan pravilnikom kole i postojeim statutom koji glasi: - jedan nastavnik moe da predaje vie predmeta (NN moe da predaje matematiku i fiziku) ali, jedan, odre eni predmet (PP) u nekom odre enom odjeljenju moe da predaje samo jedan, odre eni, nastavnik (na primjer fiziku predaje u odjeljenju Vv samo NN iako kola ima vie profesora fizike). Tip veze je 1 : N.
Grafiki se E-R model, moe prikazati na razne naine. Chen je u njegovom radu koristio simbole kako je to pokazano na slici 5.5.
sifpr# godina br(h) sifnas# ime prez. zvanje
Predmet predaje
Nastavnik
Slika 5.5 E-R model dijela informacionog sistema obrazovne ustanove
Dopunimo sada ovaj model i spiskom literature koju na pojedinim predmetima koriste nastavnici, uz uslov da:
jedan udbenik moe da se koristi za vie predmeta, ali na jednom predmetu moe, fakultativno, da se koristi vie razliitih udbenika.
Postojeim datotekama NASTAVNIK i PREDMET, te vezi "predaje" moramo pridodati novu datoteku UDBENIK, kao i novu vezu koja e je povezati sa relacijom PREDMET. Nazovimo tu novu vezu "literatura" i definiimo nova "pravila poslovanja". Neka su to:
1. 2. 3. 4. jedan predmet moe predavati vie nastavnika, jedan nastavnik moe predavati vie predmeta, za jedan predmet moe se koristiti vie udbenika, jedan udbenik moe se koristiti za vie predmeta.
57
58
Veze literatura i predaje su prema tome obje tipa N:M, a grafika interpretacija E-R modela sa takve dvije binarne veze, vidi se na slici 5.6.
sifpr# godina br(h) sifnas# ime prez. zvanje
Predmet predaje literatura Udzbenik sifudz# autor naslov
Nastavnik
Slika 5.6 Proiren model informacionog sistema obrazovne ustanove
Dvjema binarnim vezama N:M nije, naalost, eksplicitno definisan trojni odnos izme u PREDMETA, NASTAVNIKA i UDBENIKA, jer iz premisa: - jedan predmet izvodi vie nastavnika , i
- za jedan predmet koristi se vie udbenika,
ne slijedi obavezno i zakljuak da:

svaki nastavnik koristi za svoj predmet sve udbenike
li negacija te iste tvrdnje, jer se polazne pretpostavke ne baziraju na jednoj trojnoj, nego na dvije binarne veze. Tako odgovor na pitanje: - Koje udbenike za svoj predmet koristi neki nastavnik? ovako koncipiran model ne moe dati. Da bi i ovo postalo mogue binarne veze moraju se predefinisati u trojnu vezu kao to je to predstavljeno na modelu trojne veze KATEDRA (slika 5.7). Rijeima iskazana "Pravila poslovanja" u trojnoj vezi KATEDRA glase:
58
59
1. 2. 3.
jedan predmet prema jednom udbeniku izvodi vie nastavnika, jedan nastavnik za jedan predmet koristi vie udbenika, jedan udbenik, jedan nastavnik, koristi za vie predmeta.
Trojna veza (sve tri veze su tipa 1:N) KATEDRA zamjenjuje dvije binarne veze (tipa M:N) i omoguava da se izrazi svaki odnos izme u objekata i na taj nain dobije i odgovor na svako postavljeno pitanje.
Predmet katedra Nastavnik
Udzbenik
Slika 5.7 Trojna veza KATEDRA me u objektima
Ima autora koji se bave ovom problematikom koji smatraju da trojne, i veze vieg reda, zamagljuju prirodu odnosa me u objektima i time smanjuju preglednost modela. Zbog toga se viestruka veza esto ponovo zamjenjuje sa binarnim vezama. Ovaj postupak zamjene moe se izvesti na sljedei nain: Prvo se:
Viestruka veza (u posljednjem primjeru trojne veze to je veza KATEDRA slika 5.7) predstavlja kao novi objekat kome se pridruuje njegov identifikator klju. Nakon toga se svaki objekat viestruke (trojne) veze binarno povezuje vezom tipa 1:N sa tim novim objektom.
Katedra pripada koristi Udbenik sara uje Nastavnik
Predmet
Slika 5.8 Model sa tri binarne veze
E-R model trojne veze KATEDRA, preveden na E-R model sa tri binarne veze, vidi se na slici 5.8.
59
60
Vezni objekat KATEDRA preveden je u objekat KATEDRA, a uvedene su tri nove veze i to:
- "pripada" - povezuje PREDMET i KATEDRA tipom veze 1:N, - "sara uje" - povezuje NASTAVNIK i KATEDRA, veza 1:N, - "koristi" - povezuje UDBENIK i KATEDRA tip veze 1:N.
Eliminacija veza tipa N:M izvodi se na isti nain i u sloenijim strukturama. Tako, na primer, proiren model informacionog sistema obrazovne ustanove sa slike 5.4, sa eliminisanim vezama tipa N : M, vidi se na slici 5.9.
predmet predaje nastavnik
koristi
udbenik
Slika 5.9 Transformisani ER-model sa slike 5.4 sa dva nova vezna objekta,
Zakljuak: Prilikom sinteze E-R modela sistema u prvoj iteraciji treba uvijek uvesti vezu onoga reda za koju projektant sistema utvrdi da realno postoji me u objektima. Po zavretku izrade modela, veze reda vieg od dva, i veze tipa N:M zamjenjuju se onda binarnim vezama na nain kako je to pokazano. Posmatrajmo, na kraju, jo jedan primjer veze jakog i slabog objekta.
Pretpostavimo da informacioni sistem nekog hotela sadri sistem rezervacija u hotelskom lancu sa objektima: HOTEL, TIP_SOBE i REZERVACIJA, a pravila poslovanja dozvoljavaju da:
60
61
svaki HOTEL moe imati sve tipove soba, svaki TIP_SOBE moe da se nalazi u svakom hotelu, za svaki HOTEL moe se napraviti vie REZERVACIJA istovremeno, a REZERVACIJE mogu da bude izvrene u raznim HOTEL-ima, i jednom REZERVACIJOM rezervie se vie tipova soba, a svaki TIP_SOBE moe biti predmet vie REZERVACIJA.
U pitanju je oito trojna veza, a sva tri tipa veze su M:N. Uvedimo zato, odmah u startu, jo jednu datoteku STAVKA (preskaui postupnu fazu eliminacije trojne veze), a za koju e vaiti da:
STAVKA pripada jednoj REZERVACIJI, dok jedna REZERVACIJA moe imati vie STAVKI, STAVKA rezervie jedan TIP_SOBE, a jedan TIP_SOBE moe biti predmet REZERVACIJE u vie STAVKI, i STAVKOM se rezerviu sobe u HOTEL-u, dok sobe HOTEL-a mogu biti predmet rezervacije u vie STAVKI. Sve tri ovako definisane veze, nazovimo ih: zakup, soba, ispostava su tipa 1:N, a datoteka STAVKA je uz to egzistencijalno i identifikaciono zavisna od datoteke REZERVACIJA. Datoteka STAVKA je slab objekat jer zavisi od REZERVACIJE. E-R model informacionog sistema ima ukupno etiri objekta (jedan od njih STAVKA je slabi), i tri veze "zakup", "soba" i "ispostava" slika 5.10.
hotel stavka tip sobe
zakup ispostava
soba
rezervacija
Slika 5.10 Primjer veze slabog i jakih objekata

61
62
E-R model je prvi korak u projektovanju informacionog sistema. Njegova izrada se uz to odvija, kao to smo to vidjeli na prethodnim primjerima, uvijek po etapama, pri emu se poinje sa definicijom objekata i njihovih svojstava, a zatim definicijom i svojstvima veza. Proces je iterativan, to znai da esto saznanja do kojih do emo u toku sinteze modela zahtijevaju da se poetna koncepcija modela promijeni. Tek nakon konane verzije modela, kao posljednji korak slijedi i prevo enje E-R modela na relacioni oblik.
5.2
Prevo enje E-R modela na relacioni oblik

svaki objekat E-R modela postaje relacija, svaka veza N:M postaje objekat - vezna relacija, ime objekta postaje ime relacije, karakteristike objekta postaju njegovi atributi, identifikatori objekata postaju kljuevi relacija.
Tehnika prevo enja E-R modela na relacioni oblik izvodi se tako to:

Binarne veze su zastupljene u veini informacionih sistema, a tehnika redukcije veza M : N, koja se primjenjuje u binarnim vezama, principijelno se ne razlikuje od tehnike transformacije tih veza koja se koristi u unarnim, trojnim ili vezama vieg reda. Posmatrajmo stoga prvo prevo enje binarnih veza na relacioni oblik. 5.2.1 Prevo enje binarnih veza na relacioni oblik Pri prevo enju binarnih veza na relacioni oblik mogu nastupiti tri karakteristina sluaja slika 5.11. a. Objekat SLUBENIK vezan je vezom tipa 1:1 "rukovodi" sa
objektom ODJELJENJE, i to neobavezno, jer svaki slubenik mora da pripada jednom ODJELJENJU, ali nekom ODJELJENJU moe, ali ne mora, da pripada svaki slubenik. Opcionalnost je prema tome na strani tabele ODJELJENJE slika 5.11a.
62
63
b. Tabela RADNIK vezana je veznim objektom ZADUEN sa tabelom SREDSTVO (pri tome se misli na sredstvo za rad, na alat, itd.) vezom tipa 1:N, i to obostrano neobavezno jer, radnik moe, ali ne mora, biti zaduen sa vie sredstava za rad, i svaka alatka, svako sredstvo za rad moe, ali ne mora, biti kod jednog radnika slika 5.11b.
slubenik rukovodi radnik zaduen student studije profesor sredstvo odjeljenje
Slika 5.11 Primjeri binarnih veza c. Konano tabela STUDENT povezana je vezom "studije" sa tabelom PROFESOR u bazi podataka nekog fakulteta na nain M:N i to obostrano obavezno, jer svaki profesor predaje veem broju studenata, a svaki student slua predavanja kod vie profesora slika 5.11c.
Binarne veze tipa 1:1 prevode se na relacioni jezik tako to se u jednu od tabela koje uestvuju u vezi (teoretski svejedno koju), uvrsti primarni klju druge tabele kao atribut. Veza se prema tome iskazuje spoljnim kljuem. U primjeru (slika 5.11a) model veze 1:1 rezultira dvjema relacijama:
ODJELJENJE < ifraodjelj#, ifrasluz#, ..... > SLUBENIK < ifrasluz#, ......>
Prilikom izbora tabele kojoj treba da dodamo spoljni klju koji ostvaruje vezu me u tabelama treba obratiti panju na to da tabela kojoj dodajemo spoljni klju ima to manje Null vrijednosti. U Prethodnom primjeru vezu bi mogli da izvedemo i ovako:
63
64
ODJELJENJE < ifraodjelj#,.........> SLUBENIK < ifrasluz#, ifraodjelj#, .......>.
Me utim, u tom sluaju, poto je rukovo enje opcionalno, dakle neobavezno, n-torka nekog slubenika koji nema rukovodeu funkciju imala bi Null vrijednost, to u prvom sluaju nije bio sluaj budui da svako odjeljenje obavezno ima i svoga rukovodioca. Binarne veze 1:N prevode se na relacionu formu slino kao i veze tipa 1:1. Veza se ponovo iskazuje spoljnim, stranim, kljuem ali ne u bilo kojoj od relacija, nego u onoj koja u vezi E-R modela predstavlja objekat tipa povezanosti mnogo (N). Drugaije ne moe ni biti, jer bi spoljni klju u relaciji koja predstavlja objekat tipa jedan (1), u svakoj n-torci drugog objekta (mnogo) morao poprimiti onoliko vrijednosti sa koliko se slogova (n-torki) objekta tipa mnogo nalazi u vezi - a to naravno nije mogue. Konano, treba obratiti panju i na opcionalnost veze i mogunost da spoljni klju dobije Null vrijednost[1], to se ne smije dopustiti. U konkretnom sluaju (slika 5.11b) relacioni model imao bi sljedeu formu:
RADNIK < ifrarad#,...... > SREDSTVO < ifrasred#, ifrarad#,...>.
Binarne veze tipa M:N prevode se na relacionu formu uvo enjem nove relacije (vezna relacija). Klju te nove relacije je po pravilu sloen i sastoji se od primarnih kljueva objekata koji uestvuju u vezi, a atributi su svojstva veze. U malopre anjem primjeru (slika 5.11c) rjeenje bi moglo imati slijedei oblik:
STUDENT < brojindexa#, ime, prezime, adresa, ........> PROFESOR < matbroj#, ime, prezime, adresa,.........> STUDIJE <brojindexa#, matbroj#, fakultet, ..........>.
Nova, vezna, relacija je STUDIJE, koja pored sloenog kljua ima i svoj atribut fakultet koji poblie definie STUDIJE, a broj atributa veznog objekta u principu moe biti i vei ako se za tim ukae potreba.
[1]
Za vezne atribute, tj. za strani klju, moe se dopustiti pojava NULL vrijednosti na strani vie ako je veza opcionalna.
64
65
5.2.2
Prevo enje unarnih veza na relacioni oblik
I unarne veze prevode se na relacioni oblik razliito za sluaj tipa veze 1:1, 1:N, odnosno N:M.
takmiar radnik par rukovodi
proizvod
sastav
Slika 5.11 Tipovi unarnih veza
a. Unarne veze tipa 1:1 postoje me u n-torkama unutar jedne tabele a prevode se na relacioni oblik uvo enjem ifre jedne n-torke (koja uestvuje u vezi) kao spoljnjeg kljua u drugu koja je u vezi sa njom. Poto bi ta ifra bila identina prethodnoj (jer su obje u istoj tabeli), ova druga se mora preimenovati. Na primjer, ako tabela TAKMIAR ima oblik:
TAKMIAR < ifratak#, ime, prezime, . .........> veza PAR u datoteci TAKMIAR (takmiar nastupa u kategoriji parova, jer tek sa partnerom svaki od takmiara u toj kategoriji postaje takmiar u punom smislu te rijei), iskazuje se uvo enjem ifre partnera, pa tabela TAKMIAR nakon uvo enja veze ima sljedei oblik: TAKMIAR< ifratak#, ime, prezime, ifrapart,...>.
Napomena: U sistem kojim se obezbje uje integritet podataka mora se ugraditi mehanizam koji e sprijeiti da se ne dogodi da takmiar u kategoriji parova ima partnera, a njegov partner nema a to je mogue da se pri projektovanju sistema grekom desi. b. Unarne veze tipa (1:N) prevode se na relacioni oblik identino kao i u sluaju 1:1 uvo enjem spoljnjeg, preimenovanog kljua. Tabela RADNIK nakon prevo enja u relacionu formu ima slijedei oblik:
RADNIK < ifrad#, ifraruk, ime, prez, adresa, .....>
65
66
Ovakva veza predstavlja u stvari hijerarhijsku strukturu unutar objekta a iskazuje se spoljnim kljuem. Spoljni klju ukazuje na nadre eni objekat u pomenutoj hijerarhiji. U konkretnom sluaju je RADNIK je podre en RUKOVODIOCU. c. Unarna veza tipa N:M prevodi se na relacionu formu uvo enjem nove vezne tabele, vezne relacije, iji klju je sloen - sastavljen od dva atributa. I u ovom sluaju mora se jedan od atributa u veznoj relaciji (SASTAV) preimenovati, jer ne mogu u jednoj relaciji postojati dva atributa sa istim imenom. U primjeru PROIZVOD - SASTAV (slika 5.11c) rjeenje bi moglo da izgleda ovako:
PROIZVOD < ifrapriz#, naziv, datum,........> SASTAV < ifraproiz#, ifra_sastava_proiz#, naziv, .....>
Veze (M:N) unutar jednog objekta, zbog odnosa "mnogo prema mnogo", ne iskazuje hijerarhijsku nego mrenu strukturu. Zato treba obratiti panju da se ne desi sluaj da, na primjer, neki od proizvoda postane sastavni dio samoga sebe, to jest da do e do pojave zatvorenog ciklusa, to moe imati neugodne posljedice (povratna sprega koja moe uticati na nestabilnost rada!) u eksploataciji. 5.2.3 Prevo enje veza reda veeg od dva
N-arne veze (n>2) mogu tvoriti slijedee tipove (slika 5.12.):

povezanost svih objekata je tipa jedan (A), povezanost jednog objekta je tipa mnogo a preostalih tipa jedan (B), povezanost dvaju objekata je tipa mnogo, a preostalih tipa jedan (C), povezanost svih objekata je tipa mnogo (D).
N-tarne veze prevode se na relacioni oblik uvo enjem dodatnih veznih relacija, koje ukljuuju identifikatore objekata koji tvore vezu. Pokaimo to na primjeru trojne veze, a veze vieg reda prevode se analogno postupku koji se primjenjuje kod trojne. U prvom sluaju (slika 5.12) dodatni uslovi koji definiu poslovanje sistema mogu, na primjer, biti:
66
67
jedan nastavnik, za jedan predmet, koristi jednu knjigu, jedan predmet, po jednoj knjizi, predaje jedan nastavnik, i jedan udbenik, koristi jedan nastavnik, za jedan predmet,
PREDME T
(A)
KAT EDRA
NAST AVNIK
PREDME T
(B)
KAT EDRA
NAS AVNIK T
LIT AT ER URA
LIT AT ER URA
PREDME T
(C)
KAT EDRA
NAS AVNIK T
PREDME T
(D)
KAT EDRA
NAS AVNIK T
LIT AT ER URA
LIT AT ER URA
Slika 5.12 Tipovi n-tarnih veza
pa relacioni model moe da ima slijedeu formu:

PREDMET < ifrapred#, naziv,.........> NASTAVNIK < ifranast#, ime, prezime, adresa,.......> LITERATURA < ifralit#, naziv, izdavac,........> .
Vezna relacija KATEDRA, ima tri kandidata za primarni klju tako da moe da poprimi jedan od tri slijedea ravnopravna oblika:
KATEDRA < ifrapred#, ifranast, ifralit,........> KATEDRA < ifrapred, ifranast#, ifralit,........> KATEDRA < ifrapred, ifranast, ifralit#,........>.
U drugom sluaju dodatni uslovi na sistem mogu biti:

jedan nastavnik za jedan predmet koristi jednu knjigu, jedan predmet, uz jednu knjigu, predaje vie nastavnika, i jedan udbenik, koristi jedan nastavnik za jedan predmet.
ema relacionog modela ostaje ista kao i u prethodnom sluaju, vezna relacija KATEDRA ima sada dva kandidata za primarni klju, a s
67
68
obzirom da jedan predmet, uz upotrebu jedne knjige, predaje vie nastavnika, mogu se javiti dvije varijante:
KATEDRA < ifrapred#, ifranast#, ifralit,........> , KATEDRA < ifrapred, ifranast#, ifralit#,........> .
U treem sluaju dodatni uslovi na sistem mogu da glase:

jedan nastavnik za jedan predmet koristi jednu knjigu, jedan predmet, uz jednu knjigu, predaje vie nastavnika, i jedan udbenik, jedan nastavnik, koristi za vie predmeta.
ema relacionog modela je ista samo vezna relacija KATEDRA ima sada, samo jednog kandidata za primarni klju:
KATEDRA < ifrapred#, ifranast#, ifralit,........>
Konano, u etvrtom sluaju dodatni uslovi glase:

jedan nastavnik za jedan predmet koristi vie knjiga, jedan predmet, uz jednu knjigu, predaje vie nastavnika, i jedan udbenik, jedan nastavnik, koristi za vie predmeta.
U model, pored relacija PREDMET, NASTAVNIK i LITERATURA, uvodi se i relacija KATEDRA koja ima samo jednog kandidata za primarni klju a koji se sastoji od tri kljuna atributa relacija koje povezuje:
KATEDRA < ifrapred#, ifranast#, ifralit#,........> .
5.3
Normalizacija
Projektovanju informacionog sistema moe se prii i na drugi nain i to na prvi pogled jednostavnije, prosto skupljanjem i registrovanjem svih raspoloivih atributa. U tom sluaju mora se posebno obratiti panja na to da logiki model ne sadri redundancu podataka. Tabele sa sirovo nabacanim atributima rijetko kada zadovoljavaju ovaj uslov, jer se se pri njihovom koncipiranju nije vodilo rauna o izboru objekata - tabela i njihovih atributa. Optimalan izbor relacija i njihovih atributa naziva se normalizacija sistema.
68
69
Normalizacija je u stvari:
postupak izmjene (najee dekompozicije, rastavljanja na vie relacija) prvo-koncipiranih tabela (relacija).
Dekompozicijom relacije dobija se uvijek dvije ili vie novih, meusobno povezanih relacija, koje se nalaze i u nekoj od normalnih formi. U sluaju kada se projektovanju sistema pristupa preko E-R modela, i ako se isti korektno izvede, onda e i relacije koje iz njega slijede ve biti u nekoj vioj normalnoj formi pa mnogi tako i provjeravaju kvalitet dobijenog E-R modela. Tehniki postupak izvo enja normalizacije svodi se na operacije relacione algebre - projekciju i spajanje, i to:
na dekompoziciju tabela generisanjem vertikalnih podskupova (operacija projekcije), i na generisanje novih relacija iz dvaju ili vie dobijenih vertikalnih podskupova (operacija spajanja).
Ovakav pristup sintezi informacionog sistema naziva se vertikalna normalizacija u kojoj postoji pet normalnih formi. Za praksu su najvanije druga i trea, i na njima se esto proces normalizacije i zaustavlja. Pomenimo da pored vertikalne postoji i horizontalna normalizacija, koja nije teoretski potpuno dora ena do kraja, i vezana je prvenstveno za distribuirane baze podataka. ta je to normalizovana, a ta nenormalizovana forma neke relacije (tabele), najbolje se moe vidjeti na nekoliko primjera:
Pretpostavimo da neka trgovaka firma eli da vodi evidenciju o svome poslovanju. U tu svrhu skuplja i obra uje podatke koji se nalaze u tabeli NARUDBA. To su: ifra kupca ime i prezime kupca, adresa kupca, koliina kupljene robe, ifra robe (artikla) naziv robe, kvalitet, i cijena robe.
69
70
NARUDBA
ifkup# k1 k1 k1 k1 ............ k17 ime Nikola Nikola Nikola Nikola ............ Mitar adresa Beograd Beograd Beograd Beograd ............. Beograd koliina 100 200 50 300 ........... 200 ifart# a1 a2 a3 a4 ........... a2 naziv lak boja gips etke ............ boja kvalitet II I III II ............ I cijena 220 130 20 70 ........ 130
Primjer sa nekoliko podataka ove tabele vide se u tabeli NARUDBA. Bez dubljeg uputanja u analizu problema model poslovanja se moe predstaviti u vidu samo jednog objekta jedne tabele NARUDBA - sa nizom atributa: NARUDBA <k#, imekp., prezkp., kolrb, r#, nazivrb., kv., cijena>
Ovako koncipiran model je lo iz slijedeih razloga:

ifra kupca (k#) i ifra robe (r#) su atributi tabele NARUDBA, iako su u realnom svijetu identifikatori dvaju razliitih objekata (KUPAC, ROBA). Tako, na primjer, kvalitet nije atribut kupca nego nekog drugog objekta koji bi mogao da se zove ROBA. Model sadri redundancu jer se adresa i ime kupca javljaju onoliko puta koliko puta je neki kupac kupovao robu u toj trgovini. Isti zakljuak vrijedi i za artikle. Na primjer: opis artikla sa ifrom a2 (kvalitet, naziv i cijena) javlja se dva puta, jer su dva razliita kupca nabavljala taj isti artikl.
Prisustvo redundance u bazi podataka dovodi do niza problema prvenstveno kod izmjene (auriranja), ali i kod korienja, podataka. Ti problemi se nazivaju anomalije. To su prije svega: a. Anomalije pri upisu podataka Ova anomalija sastoji se u tome da upis podataka o kupcu nije mogu sve dok neki kupac neto ne kupi, iako on kao potencijalni kupac postoji i marketinki je interesantan. Analogno vrijedi i za artikle. Na primjer:
70
71
kupac sa ifrom k2 nema jo nita narueno, i njegovi podaci nisu uneseni u tabelu NARUDBA (iako je moda upravo taj kupac veoma interesantan kao potencijalni kupac), ili podatke o artiklu sa ifrom artikla a5 ne moemo imati u bazi (iako taj artikl postoji) sve dok neko ne izvri porudbinu.
b. Anomalije pri brisanju podataka Brisanjem jedne narudbe iz tabele moe se desiti da se izgube svi podaci o kupcu ili artiklu - robi. U konkretnom primjeru:
brisanjem kupca sa ifrom k17 bie izgubljeni svi podaci o njemu s obzirom da je on izvrio narudbu samo jedanput. Na sreu, sluajno nee biti izgubljeni i podaci o artiklu koji je on kupio, jer postoji jo jedan kupac (sa ifrom k2) koji je kupio isti artikl.
Ali zato, brisanjem nekoliko narudbi i takva greka moe da se desi.
c. Anomalije pri izmjeni podataka

Promjenom imena ili adrese kupca nastaje problem izmjene podataka na onoliko mjesta na koliko je kupac bio upisan. Isti zakljuak odnosi se i na artikle prilikom promjene imena ili svojstva (na primjer cijene) nekog artikla. 5.3.1 Prva, druga i trea normalna forma Svi pobrojani nedostatci mogu biti eliminisani ako se prvobitno koncipirane relacije - tabele normalizuju i dovedu u potrebnu normalnu formu. Pri tome treba samo obratiti panju da tokom postupka normalizacije (koji se, kako rekosmo, svodi na dekompoziciju i ponovo spajanje tabela) ne do e i do gubitka informacija, o emu e jo biti rijei. Prva normalna forma Relacija se nalazi u prvoj normalnoj formi (1NF) ako, i samo ako, je njen domen (podaci u tabeli) skup atomarnih vrijednosti. Budui da je ovo i uslov da bi neka tabela uopte bila relacija, slijedi da se svaka relacija nalazi u prvoj normalnoj formi.
71
72
Pojava redundance koja je u prvoj normalnoj formi praktino skoro uvijek prisutna (kao to smo to vidjeli u posljednjem primjeru), te mogunost svih prateih greaka, ukazuju na to da prva normalna forma nije ni izdaleka dovoljna za sintezu upotrebljive baze podataka. Neki autori stoga ovu formu nazivaju nenormalizovanom formom ili nultom normalnom formom, tako da se kod raznih autora moe nai i razliit ukupan broj normalnih formi. Druga normalna forma Druga normalna forma nema nekog veeg praktinog znaaja, jer je veina pomenutih anomalija i dalje prisutna kod relacija koje su dovedene u drugu normalnu formu. Pomenimo je stoga samo kao prethodnika tree normalne forme koja za praksu ima najvei znaaj. Po definiciji, relacija se nalazi u drugoj normalnoj formi ako svaki atribut, koji nije kljuni, zavisi potpuno (ne djelimino) od kljunog atributa. Posmatrajmo opet prethodni primjer.
Relacija NARUDBA nije u drugoj normalnoj formi (2NF) jer u toj relaciji je jedini mogui kandidat za klju sloeni klju (k#, r#) a atribut kvalitet oigledno zavisi samo od dijela (r#) a ne i cijeloga kljua. Prevedimo stoga relaciju NARUDBA u dvije relacije, od kojih prva R1 sadri podatke o kupcu, a druga R2, o artiklu kojega je taj kupac kupio, i to na slijedei nain: R1 < k#, ime, adresa > R2 <k#, r#, naziv, kvalitet, cijena, koliina > Relacija R1 je u 2NF, ali R2 jo uvijek nije jer ponovo atribut kvalitet zavisi samo od dijela kljua (ifart#) a ne od cijeloga kljua (ifkup#, ifart#). Relaciju R2 moramo stoga opet razbiti na dvije od kojih, prva R21 sadri samo podatke o robi , a druga R22 o kupcu i robi koji je on kupio: R21 < r#, kvalitet, cijena > R22 < k#, r#, koliina >. Sada su sve tri relacije R1, R21 i R22 u 2NF, jer R1 i R21 nemaju sloeni klju, a atribut koliina u R22 zavisi potpuno, a ne djelimino, od sloenog kljua te relacije.
72
73
Trea normalna forma Relacije R1, R21 i R22, u ovom primjeru, zadovoljavaju i uslov tree normalne forme (3NF), to nikako ne znai da je to i u svakom drugom sluaju tako, jer se moe desiti da dekompozicijom 1NF postignemo samo 2NF, a ne i vie od toga. Pokaimo to na drugom primjeru.
Pretpostavimo da unutar informacionog sistema nekog instituta imamo objekat - entitet LABORANT sa atributima: LABORANT < iflab#, ime, prezime, broj_sobe, telefon > Relacija LABORANT je ve u 2NF jer ima samo jedan kljuni atribut (iflab# - ifra laboranta), i niz atributa. Me utim, izme u atributa broj_sobe i telefon moe da postoji me usobna zavisnost (telefon se nalazi u sobi) pa e se stoga neki broj telefona u laboratoriji pojaviti u relaciji onoliko puta koliko laboranata radi u njoj, pod uslovom da koriste isti telefon. Prema tome, iako je relacija LABORANT u 2NF, pojava redundance podataka u toj formi nije otklonjena, a time i sve anomalije pri odravanju kao na primjer: broj jednog od telefona i broj sobe neke laboratorije nije mogue unijeti u informacioni sistem sve dok se ne unesu podaci o bar jednom laborantu koji radi u njoj, brisanjem podatka o posljednjem, laborantu neke laboratorije, gubi se podatak i o broju telefona u njoj (iako laboratorija, prostorija i dalje postoji), te konano, ako laboratorija promijeni broj telefona, izmjenu treba unijeti onoliko puta koliko laboranata radi u njoj.
Navedene slabosti ukazuju da relacija LABORANT mora biti dalje dekomponovana i na taj nain dovedena do 3NF. Dekompozicija se izvodi tako da se nekljuni atributi, koji su u me usobnoj funkcionalnoj vezi, izdvoje u zasebnu relaciju, te da se tako nastala relacija povee sa ostatkom prvobitne preko jednog atributa. Konkretno, u posljednjem primjeru od relacije LABORANT treba napraviti dvije:
LABORATORIJA <broj_sobe#, telefon > LABORANT < iflab#, ime, prezime, broj_sobe >
73
74
U ovom primjeru funkcionalna zavisnost izme u atributa iflab#, broj_sobe i telefon postoji i dalje. Broj telefona naime zavisi od broja sobe u kojoj se telefon nalazi, a broj sobe je u vezi sa laborantom koji sjedi u njoj. Ne bi bilo dobro da smo dekompozicijom tabele izgubili tu zavisnost, jer model sistema ne bi vie bio realna slika stvarnosti. Relacija LABORANT nije prema tome prije dekompozicije bila u treoj normalnoj formi, jer je postojala veza me u atributima. Relacija se nalazi u treoj normalnoj formi ako, i samo ako, nek[1] [2] ljuni atributi nisu ni funkcionalno ni tranzitivno zavisni od kljunog atributa, to znai da se svaka relacija koja se nalazi u treoj normalnoj formi nalazi i u drugoj, dok obrnuto ne vai. 5.3.2 Problem gubitka informacija
Pomenute me usobne zavisnosti atributa (funkcionalna i tranzitivna) nisu vjetake veze me u atributima, nego veze koje postoje i u stvarnosti, i zato se, preslikavaju iz realnog svijeta u informacioni sistem. Dekompozicijom relacije ne smijemo takve veze potpuno raskinuti, jer e model u tom sluaju izgubiti svoju vjerodostojnost. To praktino znai da svaka zavisnost unutar neke relacije mora logiki slijediti i iz relacija koje su generisane dekompozicijom, odnosno iz njih se mora moi dobiti operacijom prirodnog spajanja. U protivnom moe doi do gubitka informacija. Pravilo prilikom dekompozicije kojega se treba drati glasi: Relacija se dekomponuje bez opasnosti gubitaka funkcionalnih zavisnosti samo ako se dekompozicija vri prema funkcionalnoj zavisnosti koja ne ide od kandidata kljua (kao to je ura eno sa relacijama koje povezuju laboratorije i laborante).
[1]
Izme u atributa unutar jedne n-torke moe, slino kao izme u relacija, postojati zavisnost. Ako je zavisnost izme u atributa A i B tipa 1 : 1 onda se ona naziva funkcionalnom zavisnou i oznaava se AB. Ako izme u atributa unutar jedne n-torke postoje sledee funkcionalne zavisnosti: AB, BC i AC, onda se kae da je atribut C tranzitivno i funkcionalno zavistan od atributa A.
[2]
74
75
5.3.3
Ostale normalne forme
Pored pomenutih normalnih formi postoje jo i: Boyse - Codd-ova normalna forma (BCNF) koja je u stvari stroi oblik tree normalne forme i relevantna je za one eme relacija koje imaju vie kandidata kljua, koji se pri tome jo i me usobno prekrivaju. U praksi su ovakvi sluajevi rijetki. etvrta normalna forma eliminie redundancu koja je u treoj normal[3] noj formi mogua ako me u atributima postoji vieznana zavisnost, ime se eliminiu i anomalije pri odravanju. Posmatrajmo, na kraju, jo jedan primjer kako bi i ova definicija postala razumljivijom.
Pretpostavimo da relacija NASTAVA ima tri atributa i to: ifrapredmeta#, ifranastavnika#, ifraudzbenika# NASTAVA < ifrapredmeta#, ifranastavnika#, ifraudzbenika#,.. > te da jedan predmet moe da predaje vie nastavnika, i da se za jedan predmet moe koristiti vie udbenika. Tako u relaciji NASTAVA imamo dvije vieznane zavisnosti jer jednom predmetu (na primjer fizici) pripada vie nastavnika (na primjer Markovi, Pavlovi, Mari) i vie udbenika (na primjer Fizika materijala i Atomska i molekularna fizika). Ovako koncipirana relacija NASTAVA sadri prema tome redundancu, jer se zapis o tome da pojedini nastavnik predaje neki predmet javlja onoliko puta, koliko razliitih udbenika on koristi za taj predmet.
I ova redundanca se moe dekompozicijom izbjei, i tada se kae da je sistem u etvrtoj normalnoj formi. Konkretno, u ovom sluaju relaciju NASTAVA treba predstaviti dvjema relacijama:
[3]
Vieznana zavisnost me u atributima neke relacije R < X, Y, Z > postoji onda kada skup vrijednosti atributa Y zavisi od X a ne zavisi od Z. Rijeima iskazano; X vieznano odre uje Y, odnosno Y vieznano zavisi od X. 75
76
NASTAVA1 < ifrapredmeta#, ifranastavnika#, . > NASTAVA2 < ifrapredmeta#, ifraudzbenika#, .. >
peta normalna forma je posljednji stupanj dekompozicije koja rijeima iskazana glasi:
relacija se nalazi u petoj normalnoj formi ako se ne da dalje, sa nekim smislom, dekomponovati. 5.3.4 Primjeri normalizacije
Pokaimo proces normalizacije na dva konkretna primjera. Primjer 1: Izvor podataka za projektovanje IS-a je formular pomou kojega nabavlja nekog hotela vri narudbe robe potrebne za hotelsko poslovanje. Objekat NARUDBA, koji treba da se modelira za potrebe obrade podataka, ima vei broj atributa.
NARUDBA
Broj Narudbe: 23425142 Datum: 17.03.2007 ifra kupca: K - 302111 Naziv i adresa kupca: Hotel "Jahorina", 71436 Pale Datum isporuke: 23.04.2007 Primjedba: Telefonski razgovor sa gospodinom Tomiem Proizvod Naziv Koliina J.M. Cijena Vrijednost P-122 praak 300 kg 5.3 1590 S-001 sapun 230 kom 2.0 460 D-123 deterdent 200 kg 5.5 1100
Popust 3 2 5
Ukupno:
2790
Prva normalna forma relacije NARUDBA treba da obezbijedi da se u svakom polju relacije nalazi samo jedan podatak, to jest da svaka n-torka relacije bude sastavljena samo od atomarnih vrijednosti. Takva relacija (kreirana na osnovu hotelske narudbe) moe da ima slijedei oblik:
76
77
NARUDBA < br#, dnar, k, nk, disp, pr, p, np, kol, jm, cpr, vp, pop, uc, up, ukv >
br - broj narudbe, k - ifra kupca, disp - datum isporuke, p - ifra proizvoda, jm - jedinica mjere, vp - vrijednost proizvoda, uv - ukupna vrijednost, uc - cijena koju treba platiti.
dnar - datum narudbe, nk - naziv i adresa kupca, pr - primjedba, kol - koliina, cpr - cijena proizvoda, p - popust, up - ukupan popust, np naziv proizvoda
Druga normalna forma treba da eliminie redundancu podataka to drugim rijeima znai da:
podatke koji se ponavljaju treba izdvojiti iz relacije, formirati od svake grupe koja se ponavlja novu relaciju, i konano svakoj tako dobijenoj relaciji dodati novi klju.
Dekompozicijom relacije NARUDBA dobijamo dvije relacije:

REL1 (koja sadri podatke o kupcu) REL1 <brnar#, datnar, ifkp, nazkp, datis, prim, uknar, ukpop, ukvr > i REL2 (sadri podatke o naruenoj robi) REL2 <brnar#, ifpr#, nazpr, kol, jm, cenpr, vrpr, pop > Relacija REL2 ima sloeni klju,i treba utvrditi zavisnost svakog atributa od tog sloenog kljua. Ukoliko postoje zavisnosti, relaciju treba prevesti u viu, treu normalnu formu. U relaciji REL2, koja ima sloeni klju, atributi nazpr, jm i cenpr zavise samo od ifpr#, dakle od dijela kljua, pa ih zato treba ponovo izdvojiti u posebnu relaciju. Ovako dekomponovani sistem, koji je u II normalnoj formi dobija slijedei izgled: REL1 <brnar#, datnar, ifkp, nazkp, datis, prim, uknar, ukpop, ukvr > REL21 <brnar#, ifpr#, kol, vrpr, pop > REL22 < ifpr#, nazpr, jm, cenpr > Trea normalna forma je slijedei korak kojim se uklanjanju i eventualne tranzitivne zavisnosti. U relaciji REL1 atributi ifkp i nazkp zavise tranzitivno od kljunog atributa relacije brnar#, pa e se pojaviti redundanca podataka, to jest ponavljanje podataka o ifri, nazivu i
77
78
adresi kupca prilikom svake narudbe. Izdvajanjem ova dva atributa u zasebnu relaciju dolazi se do optimalne, 3-e normalne forme: REL11 <brnar#, datnar, ifkp, datis, prim, uknar, ukpop, ukvr > REL12 <ifkp#, nazkp > REL21 <brnar#, ifpr#, kol, vrpr, pop > REL22 <ifpr#, nazpr, jm, cenpr >
Primjer 2: Objekat X1 informacionog sistema lanca prodavnica Y ima sljedee atribute - ime, adresu i telefon -, a prodaje vie artikala raznih proizvo aa o kojima se vodi evidencija o broju komada, cijeni i boji.
Prva normalna forma sadri sve raspoloive podatke dakle: X1 < rad#, naziv, adr., tel, art#, nazart, firma, boja, cijena, kom.>. Druga normalna forma treba da eliminie podatke koji se ponavljaju. To su oigledno podaci o prodavnici koji e se ponavljati za sve artikle koji se nalaze u njoj. Izdvojimo stoga podatke o prodavnici u posebnu relaciju X2: X2< rad#, naziv, adresa, tel, > Relacija X1 glasi sada: X1 < rad#, art#, nazart, firma, boja, cijena, kom.>. i ima sloeni klju, ali atribut "nazart" zavisi samo od dijela toga kljua (art#). Izdvojimo ga u posebnu relaciju X3: X3 < art#, nazart > pa se tako dobija 3NF sa slijedeim relacijama: X1< rad#, naziv, adresa, tel, > X3< art#, nazart > X2< rad#, art#, firma, boja, cijena, komada >.
Optimalni normalni oblik (obino 3NF ili vie) na najbolji mogui nain opisuje relevantna znanja o objektima i vezama me u njima. Normalizacija ima i svoju slabu stranu to se manifestuje u smanjenoj efikasnosti modela. Pokazalo se, naime, da kontrolisana prisutnost redundance podataka (to se ER modelom moe ostvariti) ponekad
78
79
moe da bude tolerantna i korisna, a potpunom normalizacijom tabela svaka redudanca se iskljuuje pa model neki puta bude komplikovan. Na primjer, u sluaju sekretarijata za saobraaj u kome se vodi evidencija o VOZA-ima i VOZILIMA, ER-model sadri dva objekta (VOZA i VOZILO) i vezu 1:N me u njima (jer jedan voza moe posjedovati vie vozila). Relacioni model ima prema tome sljedei oblik:
VOZA < JMBG#, ime, prezime, adresa, tel. datum_ro enja...> VOZILO< Reg_br#, marka, tip, boja, br_mot., snaga,... JMBG.....>
i pogodan je za eksploataciju. Ako se problemu sinteze pri e preko normalizacije onda je prva normalna forma skup svih atributa, dakle:
R1<JMBG, ime, prezime, adresa, tel. Reg_br., marka, tip, boja, snaga,.........>
Druga i trea normalna forma razdvaja atribute prema zavisnosti pa dobijamo:

R11< JMBG#, ime, prezime, adresa, tel.,........> R22< Reg_br#, marka, tip, boja, snaga, br_mot., br_as.,.. JMBG.......>
Daljnu dekompoziciju moemo izvesti ako se pokae da se neki podaci ponavljaju. Na primjer, u tabeli R22 pojavljuje se vie puta: "marka" = "Zastava" "boja" = plava "tip" = YUGO45 "snaga" = 42kW
odnosno neke druge vrijednosti za neke druge popularne modele, pa se ovi atributi mogu izdvojiti kao posebna relacija, nazovimo je R221
R221<sifra#, marka, tip, boja, snaga>
koja je u vezi sa relacijom R22 tipa 1:N jer postoji vie vozila razliitih registarskih brojeva sa ovakvim karakteristikama. Relacija R22 glasi sada:
R22 < Reg_br.#, ifra, br_mot, br_asije, JMBG.....>
a ER- model u ovom sluaju ima izgled:

R221 R22 R11
79
80
80
81
Glava 5
5.0 Osnove projektovanja
Projektovanjem informacionog sistema (IS) treba ili:
poboljati postojei informacioni sistem rekonstrukcijom postojeeg unaprijediti njegovo poslovanje.
Da bi se to uspjeno ostvarilo, mora se u oba sluaja upoznati i razumjeti funkcionisanje sistema i definisati nain kako da se raunar upotrebi to je mogue efikasnije. Proces projektovanja grubo se moe podijeliti na tri koraka:
analiza sistema (preliminarna i detaljna istraivanja), projektovanje baze podataka, izrada aplikacija.
a poinje kada se utvrdi da je neophodno prei na moderniji nain poslovanja, ili kada postojei IS mora da se pobolja, jer ne zadovoljava. Analiza sistema predstavlja proces sakupljanja i interpretacije podataka, dijagnosticiranje problema i korienje podataka za unapre enje poslovanja. Taj posao treba da obavlja sistem analitiar.
82
Prvi korak u analizi sistema je odre ivanje domena, odnosno oblasti rada za koju se IS projektuje (raunovodstvo, pravosu e, proces u hemijskoj industriji, itd.). esto analiza sistema mora da obuhvati i procjenu razvoja sistema, tj. da predvidi koje bi se sve situacije mogle pojaviti u blioj pa i daljnoj budunosti. Me utim, sistem analiza ne smije da se pretvori u odre ivanje ta raunar moe, a ta ne moe da uradi. Takoe, modifikacija sistema treba da bude rezultat, a ne cilj analize. Ne treba po svaku cijenu uvoditi atraktivna rjeenja koja ne doprinose efikasnosti sistema. Razlozi uvo enja (ili modernizacije) raunarske opreme pri rekonstrukciji odnosno uvo enju novog informacionog sistema su:
vea brzina rada rauna vea tanost u radu obrada uvijek na isti nain, bri pristup podacima mogunost dobijanja novih informacija, poveanje sigurnosti rada, povezivanje, vie informacionih sistema, smanjenje trokova poslovanja.
Projektovanje informacionog sistema sastoji se od vie faza i to:

definisanje izvora informacija - podataka, izbor metoda i projektovanje sistema, izbor modela sistema, izbor naina izrade dokumentacije, izbor naina odravanja dokumentacije, definisanje naina vo enja projekta, vrednovanje kvaliteta projekta.
83
5.1 Izvori podataka - informacija

Prikupljanje informacija je jedna od najvanijih karika u razvoju informacionog sistema. Informacije se prikupljaju iz vie izvora, a prije svega od:
korisnika, odnosno investitora projekta informacionog sistema, postojee dokumentacije koja krui u poslovnom sistemu, te spoljnih izvora (literatura i eksperti za odre ene oblasti).
Postupak prikupljanja informacija izvodi se:

u fazi analize postojeeg informacionog sistema, u fazi utvr ivanja ciljeva koji se ele postii.
1. Osnovni izvor informacija su korisnici sistema. Od njih se saznaje koje aktivnosti, odnosno koji se procesi i postupci izvode u realnom sistemu, sa posebnim osvrtom na ciljeve koji se ele dostii novim informacionim sistemom. Informacije se od korisnika prikupljaju pomou intervju-a, upitnika i posmatranjem. Intervjui se koriste za sakupljanje podataka u direktnom razgovoru sa korisnicima, postavljanjem odre enih pitanja od strane analitiara. Intervju se moe obavljati grupno ili pojedinano, a najbolje je koristiti ga tek nakon to je iskorien neki drugi metod za analizu, kada se ve imaju neka saznanja o sistemu. Intervju treba da bude razgovor a ne ispitivanje. Projektant IS-a koji namjerava dobiti intervju od korisnika mora se prethodno dobro pripremiti (najbolje unapred spremiti upitnik koji se na licu mjesta popunjava), a predmet intervjua kree se od neformalnog upoznavanja sistema, do detaljne analize kako globalne strukture tako i pojedinanih segmenata i elemenata sistema. Intervjui se odravaju kontinualno i sa raznim osobama a u cilju dobijanja cjelovitog uvida u problem. Ukoliko su odgovori korisnika kvantitativni i preputeni subjektivnom osjeaju korisnika, kao podatak se moe uzeti i aritmetika sredina dobijenih odgovora.
84
Na primjer, ako se od korisnika trai podatak koju temperaturu u prostoriji smatra ugodnom za rad, kao rezultat treba uzeti aritmetiku sredinu dobijenih rezultata
Uspjenost intervjua umnogome zavisi i od izbora sagovornika i naina vo enja intervjua. Izbor sagovornika mora biti takav da garantuje maksimalnu pouzdanost podataka. Zato u prvoj fazi rada treba intervjue provesti sa rukovodeim kadrom jer se u toj fazi obino donose dalekosene odluke o koncepciji informacionog sistema. Od rukovodeeg kadra treba pri tome pokuati dobiti garanciju da e i ostali sagovornici biti spremni na dodatne napore koji obavezno prate razvoj i implementaciju novog informacionog sistema. Intervju mora biti dobro isplaniran. Analitiar koji planira intervju mora znati koje informacije moe i smije traiti od sagovornika. Najbolje je intervju zapoeti kratkim upoznavanjem sagovornika o rezultatima prethodnih razgovora, kao i o do tada steenima saznanjima. Zatim treba sagovorniku precizno definisati problem koji treba da bude rijeen, ali ni na koji nain ne treba nametati rjeenje nego samo sugerisati mogua. Posebno treba izbjegavati raunarsku terminologiju koju sagovornik eventualno ne razumije a nee to javno da kae, pa esto daje neadekvatne i netane odgovore. Sve informacije nije mogue dobiti samo od jedne osobe i u toku jednog intervjua. Zato treba neki put na vrijeme prekinuti intervju i ugovoriti vrijeme nastavka. Isto tako sve informacije koje se dobiju treba pismeno dokumentovati, jer u suprotnom najee dolazi do nesporazuma; ko je kome kada neta rekao, odnosno ta je tada htjeo da kae. Upitnik (anketa) je tehnika koja omoguava da analitiar kontaktira veliki broj ljudi i da uporedi njihove odgovore na ista pitanja. Upitnik moe da bude i anoniman, to ima svojih prednosti. Naravno ima i svojih nedostataka, obino upitnik popuni samo 30-40% ljudi kojima je upitnik upuen. Mnogi ga popune tek toliko da ga ne vrate praznog ne razmiljajui kakve odgovore daju. U upitniku se obino postavljaju pitanja sa ponu enim odgovorima, ali i ona koja zahtijevaju opirne odgovore. Na primjer, ako projektujemo informacioni sistem biblioteke neka od takvih pitanja bi mogla biti:
85
1. Mislite li da se esto deavaju greke prilikom izdavanja knjiga itaocima? Da [ ] Ne [ ] 2. Koje su najee greke?______________________________________ _____________________________________________________________
2. Izvor informacija je i postojea dokumentacija. Osim intervjua i upitnika informacije se mogu dobiti i iz pisane dokumentacije, uglavnom iz ulaznih i izlaznih papira koji cirkuliu u toku radnog procesa. Ovi podaci samo upotpunjuju znanja dobijena intervjuima, i nisu sami za sebe dovoljni za meritorno odluivanje. Svako preduzee ima veliki broj dokumenata koja reguliu njihovu unutranju organizaciju i me usobne odnose. Uvidom u aurnost raznih dokumenata moe se doi i do novih pitanja na koja treba nai odgovore upravo u novom informacionom sistemu. Ukoliko je postojei (stari) informacioni sistem ve implementiran na raunar, onda je dio dokumentacije ve sre en na nain koji se moe iskoristiti za projektovanje novog sistema. Analizom postojeeg softvera, kao i prirunika za njegovo korienje, mogu se stei dragocjena znanja o postojeem sistemu. Pri tome treba paziti da se ne oslonimo i suvie na podatke koje je prikupljao neko drugi, jer se esto deava da se upravo u tim podacima kriju greke koje su dovele do potrebe za izradom novog sistema. Konano u dokumentaciju ulaze svi pisani dokumenti koji se u poslovanju pojavljuju (narudbenice, rauni, magacinske liste, itd). Posmatranje je tehnika koja esto pomae da se otkriju injenice koje se ne mogu utvrditi drugim tehnikama. U preduzeu (radnoj organizaciji) dolazi nekada do niza konfliktnih situacija koje se ne mogu videti kroz dokumente, ili o kojima sagovornici nisu spremni da govore tokom intervjua (na primjer, veliki broj telefonskih poziva izme u prodavnice i skladita da bi se utvrdilo da li neki artikl postoji, i sl.). 3. Spoljni izvori informacija podrazumijevaju spoljnje saradnike, savjetnike, eksperte, literaturu kao i sisteme koji djeluju u blioj ili daljnoj okolini. Spoljni izvori su naroito vani onda kada se informacioni sistem projektuje prvi put, pa korisnici sistema nisu sasvim sigurni ta hoe, i kako bi
86
njihov sistem trebalo da izgleda. Vrlo esto je sistem koji se projektuje podsistem nekog veeg sistema. U tom sluaju je i nadre eni sistem izvor spoljnih korisnih podataka i informacija. U fazi prikupljanja informacija koriste se svi raspoloivi izvori, neki manje neki vie, to prvenstveno zavisi od specifinosti svakog sluaja. Tako na primjer, analitiar moe na osnovu ulazne i izlazne dokumentacije da pripremi intervjue za korisnike, a kada neki korisnik nije u stanju da odgovori jasno i precizno, onda se konsultuje odgovarajui spoljni izvor sa kojim je korisnik u vezi. Metodologija prikupljanja podataka treba konano da nam obezbijedi izbjegavanje redundance u podacima, to jest ponavljanja slinih postupaka, i dobijanje istih podataka na razliite naine. Prikupljanje informacija treba organizovati po tzv. top - down metodi tako da se sistem oblikuje postepeno, poev od osnovnih elemenata i ciljeva, koji onda nakon detaljne razrade pojedinih elemenata oblikuju konane cjeline. Na kraju treba provesti i verifikaciju predloenog modela ime se konano potvr uje da je analitiar detaljno i vjerodostojno upoznao sistem koji projektuje. I optimizacija dobijenog rjeenja je poeljna, ali nije uvijek i mogua. Zato treba odvojiti pojam optimizacije modela informacionog sistema, od optimizacije tehnolokog postupka za koji se informacioni sistem projektuje. Analitiari informacionog sistema vrlo esto prave greku smatrajui svojom dunou da u sklopu projektovanja informacionog sistema poboljaju tehnoloki proces. Ali ako informacioni sistem u eksploataciji poslui inenjerima i tehnolozima za optimizaciju tehnolokog postupka, onda je to najbolji pokazatelj da je projekat informacionog sistema uspio.
87
5.2 Izbor metoda

Izbor metoda za razvoj IS-a (linearni, nelinearni, evolucioni, itd.), kao i izbor odgovarajueg softvera kojim e projektovani sistem biti podran, veoma je vaan faktor pri projektovanju. S obzirom na relativno veliki broj raspoloivog softvera danas, u praksi se sree itav niz razliitih modela, pa je i izbor i odgovarajuih metodologija rada velik. Uobiajeno je da se u okviru jedne radne organizacije ili jednog projektnog tima, koristi jedna detaljno razra ena metodologija, jer se time postie standardizacija procesa projektovanja i dokumentovanja sistema. Uvo enje stalno novih i boljih metodologija ima vie loih nego dobrih efekata na efikasnost i kvalitet rada projektnog tima. Svaki informacioni sistem odre en je sa tri osnovna elementa:
tokovima podataka podacima, procesima u informacionom sistemu,
pa stoga svaka metodologija projektovanja informacionih sistema mora da sadri i sredstva koja omoguavaju definisanje tokova podataka, procesa obrade i organizacije podataka. Redoslijed projektovanja i analize pojedinih elemenata kod raznih metodologija je razliit pa se danas govori o metodologijama:
modela tokova podataka, modela podataka, modela procesa.
U prvom sluaju projekat otpoinje analizom tokova podataka, u drugom dekompozicijom sistema na podsisteme, i konano u treem sluaju - od definicije logikog modela podataka u sistemu. Teko je rei koji je od ova tri pristupa najbolji i danas se smatra je da ne postoji jedan generalni, najbolji metod projektovanja nego se za svaki sluaj trai i optimalno rjeenje.
88
5.3 Izrada modela

Modela se izvodi u dva koraka i to: 1. Izradom logikog modela sa definisanjem logike strukture:
sistema, podsistema, tokova procesa i modela podataka.
Model procesa i model podataka su konani rezultat faze istraivanja, koja najee zapoinje analizom stanja postojeeg sistema. 2. Izradom fizikog modela informacionog sistema sa:
projektovanjem baze podataka (na osnovu modela podataka) izradom aplikacija (na osnovu modela procesa), definisanjem podsistema, tokova, procedura, modela i podataka, te definisanjem zahtjeva koji se postavljaju pred sistem.
5.4
Analiza postojeeg sistema
Uvijek kada je to mogue proces projektovanja novog sistema zapoinjemo analizom postojeeg sistema. Ova analiza moe biti izvedena preciznije (sistem nam stoji na raspolaganju!) nego to e to biti sluaj sa poetnim fazama novog sistema. Zato se analiza logikog modela postojeeg sistema izvodi u vie faza i to:
analiza i prikaz globalne strukture postojeeg sistema, dekompozicija sistema na njegove podsisteme, izrada dijagrama toka podataka za svaki podsistem, te izrada i detaljan opis potrebnih procedura za obradu.
Analiza logikog modela postojeeg sistema nastavlja se analizom i izradom fizikog sistema u kojem su, u posljednjoj fazi, opisane procedure koje se odvijaju u sistemu. Logiki model sistema treba prema tome samo da prikae logiku strukturu pojedinih elemenata ne ulazei u nain izvo enja pojedinih procedura, tako da se moe generalno rei da logiki model istie procese, a zanemaruje postupke.
89
5.5
Projektovanje novog sistema
U toku rada na projektu novog informacionog sistema potrebno je proi tri osnovne faze i to:
1. Definicija problema: definisanje ciljeva i spoljnih ogranienja na sistem, 2. Izrada okvirnog projekta: definicija, izrada i oblik logike strukture novog sistema, izrada i usvajanje prijedloga fizikog modela novog sistema, specifikacija raunarske opreme, 3. Izrada detaljnog projekta: definicija korisnikih procedura, izrada prijedloga logikog modela, te definicija baze podataka i programa obrade podataka.
Ocjena izvodljivosti novog sistema ne moe se odmah precizno definisati u optem sluaju. Prilikom ocjene izvodljivosti sistema treba voditi rauna o tome: kako investitoru predstaviti novi sistem, a tom prilikom treba:
izloiti dinamiku realizacije (bar u okvirnoj formi), koliko e sve to kotati, i to je najvanije, uvjeriti investitora da e sistem funkcionisati.
Da bi se mogli utvrditi svi nabrojani elementi ocjena izvodljivosti treba da sadri:

prikaz strukture informacionog sistema, te blok dijagrame pojedinih podsistema,
a za utvr ivanje visine potrebne investicije mora se (okvirno) utvrditi:

koju i koliku opremu treba nabaviti, procijeniti trokove opreme, te dinamiku nabavke i odravanja.
90
Na osnovu ovako dobijene ocjene izvodljivosti sistema definie se prijedlog novog sistema. Naravno, ne mora svaki prijedlog biti i prihvaen, zapravo, vrlo esto prijedlog bude odbaen. Da ne bismo gubili i suvie mnogo vremena na izradi velikog broja prijedloga, od kojih e veina biti odbaena, u praksi je uobiajeno da se naprave tri okvirna prijedloga koji se razlikuju po intenzitetu tehnolokog i organizacionog zahvata u postojei sistem.
Prvi prijedlog treba da definie moguu ali ostvarivu granicu automatizacije novog sistema. Drugi prijedlog definie minimum zahvata u postojei sistem koji donose kvalitativne novosti. Trei prijedlog treba da bude kompromis elja i mogunosti.
Svi navedeni prijedlozi vrednuju se pomou tri osnovna kriterijuma i to prema:

tehnikoj izvodljivosti, operativno-organizacionoj prihvatljivosti, i ekonomskoj opravdanosti predloene investicije.
Sistem se smatra tehniki izvodljivim i prihvatljivim ako u organizaciji postoji oprema, odnosno ako postoji mogunost nabavke opreme za njegovu realizaciju. Operativno-organizacijski je sistem prihvatljiv onda kada na svom izlazu daje kvalitetne informacije za potrebe tehnolokog procesa i upravljanja radnom organizacijom. Ekonomska opravdanost razvoja i uspostavljanja novog informacionog sistema odre uje se pore enjem trokova za njegovu realizaciju, i dobiti koju taj sistem donosi. Ovo pore enje nije mogue izvesti do u detalje, jer mnogi parametri u startu, kao na primjer trokovi razvoja, rada i odravanja sistema nisu neposredno mjerljivi, dok je dobit u fazi razvoja samo djelimino kvantitativno mjerljiva.
91
Detaljno izvedena analiza postojeeg logikog modela informacionog sistema najbolja je osnova za izradu novog projekta, jer se rad na izradi novog sistema uvijek zapoinje projektovanjem strukture i to:
definisanjem novog logikog modela, i definisanjem fizikog modela novog sistema.
Logiki model novog sistema je po formi uvijek slian logikom modelu koji je generisan u procesu analize postojeeg sistema. Stoga se preporuuje u procesu projektovanja logikog modela novog sistema korienje istih jezika, istih softverskih paketa (po fazama), kao i u procesu analize prethodnog sistema. U fazi izrade fizikog modela novog sistema, donosi se odluka o tome koji e se sistem za upravljanje bazama podataka koristiti u implementaciji, kreira se baza podataka i utvr uju se procesi definisani logikim modelom koji e se obavljati runo, a koji e se automatizovati. U skladu sa tim definie se i potrebna raunarska oprema koja je odre ena prije svega:
brojem podataka, potrebnim vremenom pristupa na diskovima, te frekvencijom i brzinom izvo enja procesa obrade.
Projektovanje novog sistema je sloeniji postupak od analize postojeeg, jer se analizom opisuje postojei sistem, dok se projektom daje neta novo. Ocjena uspjenosti analize postojeeg modela uvijek je mogua, jer se kriterijum zna - koliko vjerno dobijeni model opisuje postojei sistem - dok se za novi sistem to ne moe rei. Postupak projektovanja novog sistema polazi od:
logikog modela postojeeg sistema, ciljeva koji se ele dostii a definisanih u prethodnim fazama,i zahtjeva postavljanih u toku analize postojeeg sistema.
a izvo enje se realizuje obino u dvije faze i to:

izrada okvirnog projekta, izrada detaljnog projekta.
92
Izrada okvirnog projekta poinje definisanjem problema, te ocjenom mogunosti i naina za njegovo rjeavanje. Nain definisanja problema kao i ciljeva novog informacionog sistema nije u poetku precizno odre en, jer se projektovanje radi u vrlo irokom spektru raznih situacija. Me utim, neke preporuke, proizale iz prakse, ipak postoje i sastoje se u slijedeem:
svi ciljevi i problemi treba da budu dokumentovani u pismenoj formi, ciljevi treba da su tako definisani da ne budu neostvarivi (ne smiju biti prosti spisak elja), procjenu realnosti ciljeva treba izvesti uzimajui u obzir opti nivo razvijenosti tehnologije u firmi i organizacije poslovanja, kao najbolja polazna osnova za definisanje ciljeva novog informacionog sistema slue uska grla postojeeg, ciljevi se oblikuju vrlo esto i po uzoru na druge postojee informacione sisteme iz blie ili daljnje okoline.
Izrada detaljnog projekta naslanja se na prijedlog logikog modela novog sistema definisanog u prethodno opisanoj fazi. Projektovanje poinje najee definisanjem korisnikih procedura koje odre uju kako sistem treba da izvede pojedine funkcije, i ta u tom smislu treba korisnik da zna i da uradi. Nakon toga slijedi definisanje fizikog modela baze podataka, koji se naslanja na E-R model cijelog sistema, odnosno na relacioni model izveden iz E-R modela, ili je pak dobijen postupkom normalizacije, a najee njihovom kombinacijom. Na kraju, na osnovu korisnikih procedura i fizikog modela baze podataka, definiu se procesi obrade podataka, to jest projektanti i programeri piu detaljne raunarske programe po pravilima oblikovanja kompleksnih programskih struktura (modularno, koristei tehnike strukturiranog i objektno-orijentisanog programiranja).
93
5.6
Realizacija sistema
Realizacija sistema poinje fizikom realizacijom usvojenog modela baze podataka, a sastoji se od:
inicijalizacije baze podataka, izrade programa i testiranje u realnom okruenju, izrade konane dokumentacije, te uvo enja sistema u eksploataciju.
Unutar navedenih faza treba rijeiti razne probleme koji mogu nastati, jer se tek u ovoj fazi vide pravi rezultati rada u prethodnim fazama. - Inicijalno punjenje projektovane baze podacima je prva faza realizacije. Tek nakon toga, kada imamo odre enu koliinu podataka u sistemu, pristupa se izradi i testiranju programa za realizaciju tokova i procesa obrade podataka. - Izrada i testiranje pojedinih programskih komponenti sistema izvodi se neposredno po realizaciji pojedinih modula programa i to po principu to prije - to bolje, kako bi se sprijeilo prenoenje greaka iz modula u modul. Na kraju slijedi testiranje sistema kao cjeline, konano punjenje baze svim podacima, te probni rad i uhodavanje sistema. Testiranjem IS u realnoj situaciji provjeravaju se programi i naravno model procesa. Najee se paralelno koristi stari i novi informacioni sistem i upore uju se rezultati. Problemi koji se mogu javiti posljedica su greaka u izradi modela procesa, modela podataka ili njihove implementacije. - Izrada i odravanje dokumentacije sistema dijeli se na:
izvjetaje (po fazama rada), i kompleksnu dokumentaciju.
- Izvjetaji su namijenjeni informisanju rukovodstva investitora projekta i treba da sadre slijedee elemente:
specifine podatke o radu i rezultatima za svaku fazu rada, opta saznanja o projektu steena u svakoj fazi rada, preporuke i prijedlog plana nastavka rada, izvjetaj o utroenim sredstvima, i dokumentovan zahtjev za sredstva potrebna za nastavak.
94
- Kompletnu dokumentaciju sistema ine opisi i definicije pojedinih komponenti sistema, a u zavisnosti od metodologije prema kojoj je sistem razvijan. Tu su prije svega:
opis strukture podataka, unutar koga se prikazuju hijerarhijski dijagrami dekompozicije, dijagrami toka podataka, E-R model podataka i odgovarajui logiki model, opis procesa sistema, unutar kojih se detaljno daju dijagrami strukture procesa obrade, dijagrami akcija, te stabla i tabele odluivanja, nekoliko rijei o autoru (autorima) sistema, podatke o osobama ili institucijama od kojih se mogu dobiti dodatne informacije, opis opreme na kojoj sistem radi, ogranienja koja su uvedena u sistem, spisak pretpostavki na kojima se sistem bazira.
- Uvod i osnovne karakteristike sistema sadre:
- Ulaz i izlaz iz sistema treba da sadri:

spisak izlaza iz sistema sa naznakom kako se koriste, spisak ulaza u sistem sa naznakom odakle je sve mogue uvesti informaciju u sistem, nain pokretanja i zaustavljanja sistema, primjer sa korienjem ulaza, izlaza i najvanijih operacija.
- Osnovne funkcije sistema su:

opis svake funkcije u sistemu, namjena (kada i gdje se koristi) svaka funkcija, efekti koji se postiu sa pojedinim funkcijama, mogue jednostavnije greke, njihov opis i nain eliminacije, ilustrativni primjer.
- Detaljan opis instalacije sistema sadri:

detaljan opis instalacije sistema, a sadri opis programa sa opisom procedura i varijabli u njemu.
95
- Korisniki prirunik
Korisniki prirunik, odnosno uputstvo za upotrebu, treba korisnika da uputi u mogunosti i nain korienja informacionog sistema.
5.7
Vo enje i vrednovanje projekta
Poslovi vo enja nekog projekta zavise prvenstveno od opsega rada i pristupa razvoju informacionog sistema. Uspjenost vo enja projekta zavisi od vie faktora od kojih su najvaniji: 1. Sastavljanje projektnog tima to je esto i presudan faktor za uspjenost realizacije svakog, pa i projekta informacionog sistema. Svaki projektni tim treba da se sastoji od:
analitiara, tehnologa, projektanta, korisnika, rukovodioca radne organizacije, i predstavnika investitora.
2. Vrednovanje projekta izvodi se na osnovu niza kriterijuma kao:

- ispravnost, da li sistem daje tane informacije ili su mogue i lane, - potpunost, to jest da li sistem moe da generie sve potrebne informacije, - robusnost, se ogleda u reakcijama sistema na nepredvidivo rukovanje, - pouzdanost, koja je prije svega odre ena kvalitetom angaovane opreme, - optimalnost, da li je sistem mogao biti realizovan i sa manje sredstava, - jednostavnost u korienju, koliko je sistem naklonjen korisniku, - jednostavnost odravanja, upoznavanja, odravanje i izmjena dijelova, - mogunost proirenja i povezivanja sa drugim sistemima, te konano, - prenosivost, koja se ogleda u fleksibilnosti i prenoenju u nove uslove.
Iskustvo je pokazalo da informacioni sistemi nikada u potpunosti ne zadovoljavaju sve postavljene zahtjeve, odnosno nemaju eljene karakteristike. Razlog tome lei u injenici da se podaci i procesi u realnom sistemu stalno mijenjaju i zato informacioni sistemi moraju biti sposobni da se prilago avaju i nadogra uju.
96
209
Glava 8
Primjeri 8.1 Informacioni sistem sekretarijata za saobraaj
matini broj, ime i prezime vozaa, datum ro enja, adresa, broj telefona, broj vozake dozvole, eventualne kazne,..... registarski broj vozila, marka i tip vozila, broj motora, broj asije, snaga motora, boja, vrsta vozila, godina proizvodnje.....
U sekretarijatu za saobraaj vode se slijedei podaci o vozaima:
i vozilima
Objekti u sistemu su prema tome VOZA i VOZILO. Veza me u objektima je tipa 1 : N (jer je dozvoljeno, to dozvoljavaju propisi, da jedan voza posjeduje vie vozila, ali jedno vozilo moe imati samo jednog vlasnika). E-R model je krajnje jednostavan (slika 8.1) a relacioni model, izveden na osnovu ER-modela, ima oblik:
VOZA <matbr#, prez, ime, adresa, tel, brdoz, kazneni bodovi > VOZILO<regbr#, marka, tip, brmot, bras, snaga, god, matbr >.
210
VOZA
VOZILO
Slika 8.1 E-R model informacionog sistema sekretarijata za saobraaj
Upit koji, na primjer, daje spisak svih vlasnika vozila Opel tip Rekord godina proizvodnje 1989, glasi:
SELECT V.ime, V.prez FROM VOZA V, VOZILO VL WHERE V.matbr# = VL.matbr AND VL.marka = opel AND VL.tip = rekord AND VL.god = 1989 ;
Upit kojim saznajemo ime i prezime vlasnika kola iji registarski broj poinje sa REG123 mogao bi da glasi:
SELECT V.prez, V.ime FROM VOZA V, VOZILO VL WHERE V.matbr# = VL.matbr AND VL.regbr# = REG123*;
Spisak vozaa vozila marke Mercedes sa motorom jaim od 100 kW dobili bismo upitom:
SELECT V.prez, V.ime FROM VOZA V WHERE V.matbr# = (SELECT VL. matbr FROM VOZILO VL WHERE VL.marka = Mercedes AND VL.snaga > 100);
211
8.2 Dio informacionog sistema advokatske kancelarije

Poslovanje advokatske kancelarije treba prebaciti na raunar i formirati odgovarajui informacioni sistem. U tu svrhu, za poetak, projektant je nakon prvog intervjua sa advokatom, kada je saznao osnovna pravila vo enja postupka pred sudom, saznao da:
u jednoj parnici moe da uestvuje vie stranki, jedna stranka moe da vodi vie razliitih parnica, a jedan spor moe biti predmet vie roita,
Objekti u sistemu su prema tome STRANKA, PREDMET i ROITE pri emu je PARNICA egzistencijalno i identifikaciono zavisan objekat od STRANKE, i PREDMETA. ER-model (slika 8.2) E-R prikazan na slici 8.2.
stranka uestvuje
roite parnica
predmet vodi
Slika 8.2 E-R model dijela informacionog sistema advokatske kancelarije
S obzirom na vezu N:M me u objektima STRANKA i ROITE relacionom modelu:

STRANKA< mbrs#, ime, prezime, zanimanje, adresa, tel., > PREDMET < ifpar#, vrsta_spora, text, > ROITE < ifpar#, datro#, vrijeme, rezultat, >.
potrebno je dodati i jednu veznu relaciju:

UESTVUJE < mbrs#, ifpar#, datro>.
Ovako koncipiran sistem omoguava praenje aktivnosti u vo enju sporova pred sudom.
212
8.3 Informacioni sistem sportskog saveza

U sportskom savezu grada vodi se evidencija o sportskim drutvima klubovima na njegovoj teritoriji. U cilju formiranja informacionog sistema sportskog saveza, u prvoj fazi, od sekretara sportskog saveza u razgovoru su dobijene prve informacije o organizaciji i nainu poslovanja saveza i klubova u njemu. To su:
Klubovi u gradu imaju svoje prostorije sa telefonima i imaju odre en broj zaposlenih slubenika, Klubovi su interno organizovani po sekcijama (u klubu moe da ih bude vie), a neke od sekcija imaju i svoje posebne prostorije, eventualno i po jednog slubenika domaina, lan kluba moe da bude takmiar ili simpatizer. Prilikom upisa od svakog lana se uzimaju osnovni podaci (ime, prezime, adresa, telefon, status, itd). Pojedinac moe da bude ulanjen u vie sekcija jednog kluba, Klubovi angauju trenere, klub moe imati vie trenera za jednu sekciju (koja ima vie lanova), a dozvoljava se mogunost da jedan trener trenira vie sekcija unutar istog kluba.
Entiteti - objekti odre eni su ifrom (identifikatorom) i nizom atributa koji su od znaaja. Na osnovu dobijenih informacija projektant je uveo sljedee objekte:
KLUB, sa podacima o svim klubovima u savezu, ZAPOSLENI, sa podacima o stalno zaposlenim, SEKCIJA, sa podacima o sekcijama po klubovima, LANOVI, sa podacima o lanovima svih klubova, TRENER, sa osnovnim podacima o trenerima, i DOMAIN, sa osnovnim podacima o domainu sekcije (ukoliko ga sekcija ima).
Izme u entiteta postoje veze definisane uslovima poslovanja.

RADI - povezuje zaposlene (slubenike) u nekom klubu sa odgovarajuim klubom. Nain veze je obavezan, a tip je 1:N jer broj slubenika u klubu moe da bude i vei od jedan.

Zaposleni
213
Radi
Klub
Posjeduje Trenira Trener Sekcija Pripada lanovi
Magazin
Domain
Slika 8.3 E-R model informacionog sistema sportskog saveza POSJEDUJE - povezuje klub sa njegovim sekcijama. Nain veze je obavezan, (klub mora da posjeduje bar jednu sekciju da bi mogao da egzistira), a tip je 1 : N, jer u klubu moe da postoji vie sekcija. TRENIRA - povezuje trenera sa sekcijama koje trenira. Nain veze je obavezan, a tip je N:M jer je dozvoljeno da jedna sekcija ima vie trenera, i da jedan trener priprema vie raznih sekcija, PRIPADA - povezuje lanove sa odgovarajuim sekcijama. Veza je obavezna i tako e tipa N:M jer jedan lan moe biti u vie sekcija, a sekcija moe da ima vie lanova, i
214
MAGACIN - povezuje sekciju sa njenim domainom, veza je opcionalna (sekcija ne mora da ima magacionera), tipa je 1:1 obzirom da jedna sekcija moe da ima samo jednog magacionera.
Relacioni model dobijen je na osnovu E-R modela prikazanog na slici 8.3. Broj atributa u stvarnosti moe biti i vei, a zbog jednostavnosti je ogranien na max. etiri. Relacioni model glasi:
KLUB < ifkluba#, naziv, adresa, telefon > SEKCIJA < ifsekcije#, ifd, naziv, adresa, telefon, ifkluba > TRENER < iftren#, ime, prezime, adresa, telefon > LAN < ifl#, ime, prezime, adresa, telefon > ZAPOSLENI < ifsekcije#, ime, prez., adresa, tel., funkcija, ifkluba> DOMAIN < ifd#, ime, prezime, adresa, telefon > sa dvije vezne relacije kojima se eliminiu veze M:N TRENIRA < iftren#, ifsekcije# > PRIPADA < ifl#, ifsekcije#, status >
Postavimo nekoliko SQL upita: 1. Spisak svih klubova koji imaju sekciju stonog tenisa?
SELECT K.naziv FROM KLUB K, SEKCIJA S WHERE K.ifkluba# = S.ifkluba# AND S.naziv = stoni tenis;
2. Imena i prezimena trenera odbojke dobijamo upitom:

SELECT T.ime, T.prezime, K.naziv FROM TRENER T, TRENIRA TR, SEKCIJA S, KLUB K WHERE S.ifsekcije# = TR.ifsekcije# AND TR.iftren# = T.iftren# AND S.ifkluba# = K.ifkluba# AND S.naziv = odbojka ;
215
ili, drugaije:
SELECT TRENER.ime, TRENER.prezime FROM TRENER WHERE TRENER.iftren# IN (SELECT TRENIRA.iftren# FROM TRENIRA WHERE TRENIRA.ifsekcije# IN (SELECT SEKCIJA.ifsekcije# FROM KLUB WHERE KLUB.ifkluba# = (SELECT SEKCIJA. ifkluba FROM SEKCIJA WHERE SEKCIJA.naziv =odbojka)));
3. Naziv kluba u kome kao blagajnik radi Markovic

SELECT K.naziv FROM KLUB K WHERE K.ifkluba# IN (SELECT Z.ifkluba# FROM ZAPOSLENI Z WHERE Z.funkcija = blagajnik AND Z.prezime = Markovic);
4. Spisak sekcija sa nazivom kluba koje nemaju svoga domaina?

SELECT S.naziv, K.naziv FROM DOMAIN D, SEKCIJA S, KLUB K WHERE D.ime AND D.prezime = Null AND S.ifkluba# = K.ifkluba#;
5. Spisak svih takmiara u koarkakoj sekciji kluba Partizan ?

SELECT C.prezime, C.ime FROM CLAN C WHERE C.sc# IN (SELECT P.sc# FROM PRIPADA P
216
WHERE P.status = takmicar AND P.ifsekcije# IN (SELECT S.ifsekcije# FROM SEKCIJA S WHERE S.naziv =Koarka AND S.ifkluba# IN (SELECT K.ifkluba# FROM KLUB K WHERE K.naziv =Partizan)));
217
8.4
Informacioni sistem kolske biblioteke
U razgovoru sa bibliotekarkom kolske biblioteke, za koju je rukovodstvo kole odluilo da poslovanje i evidenciju prebaci na raunar, projektant informacionog sistema dobio je sljedee podatke:
svaka knjiga u biblioteci dobija, pored broja odgovarajue Narodne biblioteke (UDK klasifikacija), i interni registarski broj, o svakoj knjizi vodi se evidencija o imenu autora, naslovu knjige, broju stranica, nazivu izdavaa, godini izdanja, svaki korisnik (italac) biblioteke mora biti registrovan. Prilikom registracije uzimaju se podaci o njegovom matinom broju, imenu i prezimenu, broju line karte, danu, mjesecu i godini ro enja, mjestu ro enja, adresi i telefonu (ako ga posjeduje), prilikom uzimanja knjige registruje se korisnik, datum uzimanja i vraanja knjige, i datum do kada mora biti vraena.
Daljnim uvidom u poslovanje biblioteke naknadno je utvr eno da poslovnik biblioteke odre uje da se:
jedna knjiga moe nalaziti samo kod jednog itaoca, od istog autora u biblioteci mogu postojati knjige razliitih naslova biblioteka moe posjedovati vie istih knjiga jednoga autora, jedan italac moe istovremeno da bude zaduen sa vie knjiga (maksimalno tri). Na osnovu ovih podataka koncipiran je ER-model slijedee strukture:
Entiteti - objekti u sistemu su:

KNJIGA sa svim podacima o knjizi kao to su ime autora, eventualni koautori, naziv knjige, godina izdanja, itd. , PRIMJERAK sa registracionim podacima biblioteke, ITALAC sa svim podacima o itaocu, NA_ITANJU, egzistencijalno i identifikaciono zavisan objekat od objekata PRIMJERAK i ITALAC, u kome su podaci o datumu uzimanja i vraanja knjige. Ovaj objekat prema tome spada u klasu slabih objekata.
218
Veze definiu uslovi poslovanja.

Veza IZDAJE, izme u objekata PRIMJERAK i NA_ITANJU je opcionalna (knjiga moe, ali ne mora biti na itanju) i tipa je 1:1. Veza UZIMA, izme u ITALAC i NA_ITANJU je obavezna tipa 1:N, jer jedan italac moe imati do tri knjige na itanju. Veza KOMADA, izme u KNJIGA i PRIMJERAK je obavezna i tipa 1:N, jer biblioteka moe posjedovati vie primjeraka iste knjige.
Grafiki prikaz E-R modela vidi se na slici 8.4 a.

KNjIGA ITALAC
KOMADA IZDAJE
UZIMA
PRIMJERAK
NA_ITANjU
8.4 a) E-R model informacionog sistema kolske biblioteke
Relacioni model slijedi direktno iz predloenog E-R modela i glasi :

KNJIGA < udk#, naz, autor, izd., god, mjesto> PRIMJERAK < ifknjige#, udk > ITALAC< ifit#, matbr, ime, prezime, datrod, mjesto, adresa, tel > NA_ITANJU < ifknjige#, ifit#, datuzima, datvraa >.
Me utim, pri realizaciji sistema, tokom unosa podataka o knjigama i testiranja prototipa aplikacije, uoeni su neki nedostatci. Ti nedostatci, koji su morali biti otklonjeni, su slijedei:
219
1. mnoge knjige imaju vie (a ne jednog) autora, 2. za efikasno pronalaenje relevantne literature potrebno je svrstati knjige u odre ene oblasti upotrebom kljunih rei, 3. mogu postojati iste knjige koje su izdali razliiti izdavai, i
Predloeni E-R model mora se prema tome modifikovati, jer novi, stroiji uslovi koje informacioni sistem kolske biblioteke treba da zadovolji glase:
svaka knjiga koja postane vlasnitvo biblioteke mora pored evidencionog broja Narodne biblioteke (UDK klasifikacija) dobiti i interni registarski broj, o svakoj knjizi vodi se evidencija o imenima svih autora (ako ih ima vie), naslovu knjige, broju stranica, nazivu izdavaa, godini izdanja i kljunim rijeima (do maksimalno pet), svaki korisnik (italac) biblioteke mora biti registrovan u biblioteci. Prilikom registracije uzimaju se podaci o matinom broju, imenu i prezimenu, broju line karte, adresi i telefonu, prilikom uzimanja knjige registruje se knjiga i korisnik, datum uzimanja i vraanja knjige te datum do kada mora biti vraena, jedna knjiga moe se nalaziti samo kod jednog itaoca, u biblioteci postoje iste knjige koje su izdali razliiti izdavai, od istog autora mogu postojati knjige razliitih naslova, kao i vie istih knjiga jednoga autora, i jedan italac moe da bude zaduen sa vie knjiga.
E-R model informacionog sistema baziran na ovim uslovima dobija se kao proirenje postojee prve verzije (prednost relacionih modela mogu se dora ivati) tako da trud prilikom sinteze prvog modela nije bio uzaludan. Struktura bi mogla da bude sljedea slika 8.4b. Entiteti u sistemu su sada:
KNJIGA, sa podacima o knjizi, AUTOR, sa podacima o autorima, IZDAVA, sa podacima o izdavau, PRIMJERAK, sa registracionim podacima biblioteke,
220
ITALAC, sa podacima o itaocu, i NA_ITANJU, egzistencijalno i identifikaciono zavisan objekat od objekata PRIMJERAK i ITALAC, sa podacima o datumu uzimanja i vraanja knjige - slabi objekat. NAPISALI povezuje KNJIGU sa AUTORIMA. Tip veze je N : M, IZDALI povezuje KNJIGU sa IZDAVAIMA. Tip veze je N : M, jer knjiga moe biti izdana od vie izdavaa, i veza IZDAJE preimenuje se u POSU UJE a definie vezu izme u objekata PRIMJERAK i NACITANJU. Tip veze je 1:1.
AUTOR ITALAC
Veze su:

NAPISALI
UZIMA
KNJIGA
PRIMJERAK
NA_ITANjU
KOMADA IZDALI
POSU UJE
IZDAVA
Slika 8.4 b) E-R model informacionog sistema kolske biblioteke
Relacioni model slijedi direktno iz E-R modela: Objekti su:

AUTOR < ifautora#, ime, prezime, adresa, zvanje, > KNJIGA < udk#, naz, kr1, kr2, kr3, kr4, kr5, > IZDAVA < ifizd#, naziv, adresa, > PRIMJERAK < ifprim #, udk, > ITALAC< ifit#, ime, prezime, adresa, tel, > NA_ITANJU < ifprim#, ifit#, datuzimanja, datvracanja, >.
221
te vezni objekti IZDALI < ifizd#, udk#, godina, > NAPISALI < ifautora#, udk#, redni_broj_autora, >
1. Upitom:
SELECT K.autor FROM KNJIGA K WHERE K.autor = Marko Markovi;
dobijamo knjige iji je autor Marko Markovi. 2. Ime i prezime itaoca kod kojega je na itanju knjiga Robinson:
SELECT .prezime, .ime FROM ITALAC , PRIMJERAK P, NA_ITANJU N WHERE .ifit# = N. ifit# AND N.ifknjige# = P.ifknjige# AND P.ifknjige# = K.ifknjige# AND K.naziv = Robinson;
3. Poslednji upit se moe postaviti i na drugi nain:

SELECT .prezime, .ime FROM ITALAC WHERE . ifit# IN (SELECT N. ifit# FROM NA_ITANJU N WHERE N.ifknjige# IN (SELECT P.ifknjige# FROM PRIMJERAK P, WHERE P.ifknjige# = (SELECT K.ifknjige# FROM KNJIGA K WHERE K.naziv =Robinson )));
Napomena: Brzina kojom e sistem dati odgovore nije ista. U sluaju (2) zbog tri operacije prirodnog spajanja etiri tabele, ako svaka ima samo po 1000 zapisa kreira se tabela od 1012 redova. Sada se izabiraju oni koji zadovoljavaju uslove iz instrukcije WHERE. Vreme odgovora sistema bie znaajno due nego u sluaju (3) gdje se sukcesivno izdvajaju (selektuju) n-torke koje zadovoljavaju postavljene uslove.
222
8.5

Dio informacionog sistema studentske slube

studentima (brind, prezime, ime, adresa, ), nastavnicima (ifranas, ime, prezime, adresa, tel, ), predmetima (ifrapred, naziv, semestar, ), i ispitima (datum, ocjena, ime kand., ime prof., naziv pred.). jedan predmet moe se polagati vie puta, na jednom ispitu polae se jedan predmet, jedan student moe prijaviti vie ispita, jedan ispit moe polagati vie studenata, jedan nastavnik moe da predaje vie predmeta, jedan predmet moe da predaje samo jedan nastavnik, jedan nastavnik organizuje vie ispita, i jedan ispit organizuje samo jedan nastavnik.
U svakoj studentskoj slubi vode se, izme u ostaloga, i podaci o:
Pretpostavimo da statut fakulteta omoguava da:
Na osnovu ovih podataka ER-model sistema moe imati strukturu koja se vidi na slici 8.5 student
prijave
predmet polae
ispit organizuje
nastavnik
Slika 8.5 E-R model dijela informacionog sistema studentske slube

223
Relacioni model, izveden sa slike 8.5 ima sljedeu strukturu: Objekti su:
NASTAVNIK <ifranast#, prezime, ime, adresa, tel, .> PREDMET < ifrapred#, ifranast, naziv, semestar, > STUDENT < brind#, prezime, ime, adresa, ifrapred, > ISPIT < datispita#, ifrapred#, ifranast#, vrijeme, sala, tip, >. i vezni objekat: PRIJAVE < brind#, datispita#, ifrapred#, ifranast#, ocjena, >
Relacija ISPIT ima sloen klju (ifrapred#, datispita#), jer se ispit iz nekog predmeta moe ponoviti, nekog drugog datuma, pa se samo tako moe jednoznano identifikovati. Vezni objekat PRIJAVE ima tako e sloen klju sastavljen od tri atributa (da bi se znalo koji student polae toga datuma taj ispit) i jedan svoj atribut rezultat ispita, to jest ocjenu. Ako, na primjer, hoemo da dobijemo spisak imena i prezimena svih studenata sa brojem njihovog indeksa a koji su u ispitnom roku april 1990 polagali predmet matematika i dobili ocjenu 8, rezultat se moe se dobiti upitom:
SELECT STUDENT.brind#, STUDENT.prezime, STUDENT.ime FROM STUDENT, PRIJAVE, PREDMET WHERE STUDENT.brind# = PRIJAVE.brind# AND PREDMET.ifrapred# = PRIJAVE.ifrapred# AND PREDMET.naziv = matematika AND PRIJAVE.datispita = april 1990 AND PRIJAVE.ocjena = 8 ;
224
8.6 Dio informacionog sistema klinikog centra

U administraciji klinikog centra vodi se evidencija o:
KLINIKAMA (naziv, adresa, telefon, broj kreveta, ), LJEKARIMA (ime, prezime, specijalnost, klinika, adresa, tel, ), OSOBLJU (ime, prezime, klinika, ljekar, adresa, tel,), PACIJENTIMA (mat.br., ime, prezime, adresa, tel, ), i LABORATORIJAMA (ifra, naziv, specijalnost, tel, ).
Sistem poslovanja omoguava da:

jedna klinika angauje vie ljekara, ali jedan ljekar moe biti angaovan samo na jednoj klinici, na jednoj klinici radi vie osoblja, ali jedan lan osoblja moe da radi samo na jednoj klinici, jednoj klinici moe da pripada vie laboratorija, ali jedna laboratorija pripada samo jednoj klinici, jedna klinika hospitalizuje vie pacijenata, ali jedan pacijent moe biti hospitalozovan vie puta, na raznim klinikama.
OSOBLjE
ZAPOSLENO PRIPADA LABORATORIJA KLINIKA ANGAUJE LjEKAR
HOSPITALIZACIJA
PACIJENT
Slika 8.6 E-R model dijela informacionog sistema klinikog centra

225
ER-model koji prati opisani sistem poslovanja klinike vidi se na slici 8.6 a relacioni model ovog dijela informacionog sistema klinikog centra ima prema tome slijedeu strukturu: Objekti su:
KLINIKA < ifklinike#, naziv, adresa, tel, broj_kreveta, > LJEKAR <lmbr#, ime, prezime, spec., adresa, tel, ifklinike, > PACIJENT < pmbr#, ime, prezime, adresa, tel,.. > LABORATORIJA < iflab#, naziv, specijalnost, adresa, tel, ifklinike, OSOBLJE <ombr#, ime, prezime, funkcija, adresa, tel, ifklinike, > te vezna relacija HOSPITALIZACIJA < brhosp#, pmbr, ifklinike, lmbr, datprijema, anamneza, dijagnoza, terapija, ishod, >.
U tri tabele koristi se isti atribut: mbr matini broj pa je napravljena razlika dodavanjem jo jednog slova i (za ljekare), p (za pacijente) i o (za osoblje). Vezna relacija, HOSPITALIZACIJA ima sloeni klju koji omoguava jednoznaan pristup svakom pacijentu prilikom svakog prijema u bolnicu poto isti pacijent moe vie puta biti hospitalizovan. Ako, na primjer, traimo pacijente (ime i prezime, telefon i naziv klinike na kojoj su bili lijeeni), koji su bili primljeni u klinikom centru u periodu od 01.01.1995. do 01.01.1997., pod dijagnozom "miija groznica", a otputeni sa dijagnozom izlijeen SQL upit bi mogao da ima formu:
SELECT P.ime, P.prezime, P.tel, K.naziv FROM PACIJENT P, HOSPITALIZACIJA H, KLINIKA K WHERE K.ifklinike# = H.ifklinike AND H.pmbr= P.pmbr# AND H.datpr BETWEEN 01.01.1995 AND 01.01.1997 AND H.dijagnoza = miija groznica AND H.ishod = izlijeen;
226
8.7
Informacioni sistem video kluba
Vlasnik video kluba odluio je, u cilju efikasnijeg rada, da svoje poslovanje vodi pomou raunara i tako ubrza proces izdavanja i vraanja kaseta. U video klubu posjeduje veliki broj video kaseta, raznoga anra, a neke filmove ima i u vie primjeraka kaseta (ili CD-ova). Rok vraanja je tri dana. Sistem poslovanja video-kluba dozvoljava da:
jedan lan posudi do tri kasete jednovremeno, ali jedna odre ena kaseta moe biti iznajmljena samo jednom lanu, od istog reisera ima u video klubu vie razliitih filmova, ali jedan film reirao je uvijek samo jedan reiser, od jedne producentske kue u video klubu ima vie filmova, ali jedan film je napravljen samo u jednoj producentskoj kui, jedan glumac-glumica igra u vie razliitih filmova, ali i u filmu moe da igra vie od jednoga glumca-glumice, u video klubu ima vie kaseta sa filmovima od istoga scenariste, ali jedan film ima samo jednoga scenaristu.
Da bi se muterijama u to kraem roku mogao dati odgovor da li u video-klubu postoji film - kaseta koji oni trae, informacioni sistem je koncipiran ovako: Objekti entiteti u sistemu su:
FILM KASETA PRODUKCIJA GLUMAC REISER SCENARISTA LAN
a pobrojani uslovi definiu dodatne veze u sistemu. U ovome sluaju samo jedna veza N:M rezultira veznom relacijom i to:
GLUMI
E-R model ovoga sistema se vidi na slici 8.7:

227
scenarist glumi glumac film produkcija producira reiser reira pie primjerak kaseta posu uje lan
Slika 8.7 E-R model poslovanja video-kluba
Relacioni model izveden iz ER-modela sa slike 8.7 i glasi:

FILM <iffil#, naziv, ifprod, ifre, ifscen, anr, ...> KASETA <ifkasete#, iffil, mbr, datizd, datvra, cijena, ...> PRODUKCIJA < ifprod#, naziv, drzava, ...> GLUMAC <ifgl#, ime_i_ prezime, > REISER <ifre#, ime_i_ prezime, iffil, > SCENARISTA <ifscen#, ime_i_ prezime, iffil, > LAN <mbr#, ime_i_ prezime, adresa, telefon, > sa veznim objektom GLUMI < iffil #, ifgl# >,
1. Odgovor koje sve filmove posjeduje video klub koje je producirao Metro Goldvin Mayer, a u njima igraju Don Vejn ili Din Martin dobijamo:
SELECT F.naziv FROM FILM F, WHERE F.ifprod# = ( SELET P. ifprod # FROM PRODUKCIJA P WHERE P.naziv = Metro Goldvin Mayer ) AND F. iffil# = ( SELET GLUMI. iffil# FROM GLUMI WHERE GLUMI. ifgl# =( SELECT G. ifgl# FROM GLUMAC G WHERE G.ime_i_prezime IN (Din Martin , Don Vejn));
228
8.8 Dio informacionog sistema lanca robnih kua

Direkcija lanca robnih kua odluila je da formira informacioni sistem. Inenjer projektant, u razgovoru sa rukovodiocima i radnicima doao je do prvog modela informacionog sistema. Objekti u njemu bili bi:
PRODAVNICE RADNIK EF LOKACIJA KUPAC ROBA DOBAVLJA
Sistem poslovanja postavlja dodatne uslove:

jedan isporuilac moe da isporuuje raznu robu, ali se jedan artikal moe nabavljati i od vie isporuilaca, jedan kupac kupuje vie artikala, a isti artikal moe biti kupljen od vie kupaca, u prodavnici ima na prodaju vie raznih artikala, a svaki artikal se moe nalaziti u vie prodavnica, u jednoj prodavnici radi vie radnika, ali svaki radnik moe da radi samo u jednoj prodavnici, jedna prodavnica ima jednog efa, i jedan ef moe biti gazda samo u jednoj prodavnici, i na jednoj lokaciji moe biti vie prodavnica, ali jedna prodavnica moe biti samo na jednoj lokaciji.
Uslovi poslovanja rezultiraju prema tome sljedeim dodatnim veznim relacijama:

ISPORUKA UZIMA PRODAJE
229
E-R model sistema vidi se na slici 8.8.

dobavlja radnja
isporuuje
radi
roba prodaje uzima
prodavnica lei efuje
lokacija
kupac
ef
Slika 8.8 E-R model lanca prodavnica neke robne kue
Relacioni model izveden iz ER-modela sa slike 8.8 glasi:

PRODAVNICE < ifprod#, naziv, iflok, mbr, ..> RADNIK < mbrr#, ime, prezime, adresa, tel., .> EF < mbr#, ime, prezime, adresa, telefon,..> LOKACIJA < iflok#, naziv, brojstanov, > KUPAC < mbrk#, ime, prezime, adresa, tel, > ROBA < ifrob#, naziv, cijena, > DOBAVLJA < ifisp#, naziv, adresa, tel., >. uz vezne reacije: ISPORUKA < ifisp#, ifrob#, brojkomada, > UZIMA < mbrk#, ifrob#, brojkomada, datum, > PRODAJE < ifrob#, ifprod#, brojkomada, >.
230
Upit: Kojeg datuma, u kojoj prodavnici je kupac xxx kupio proizvod yyy ? mogao bi da izgleda ovako:
SELECT P.naziv, U.datum, FROM KUPAC K, ROBA R, UZIMA U, PRODAVNICA P, PRODAJE PD WHERE P.ifprod#=PD. ifpord# AND PD. ifrob#= R. ifrob# AND (ROBA R.naziv = yyy AND R. ifrob#= U. ifrob# ) AND (U.mbrk#= K.mbrk# AND K.prezime = xxx);
231
8.9 Organizacija sportskog takmienja

Takmienje u zimskim sportovima treba da se odri na raznim borilitima u mukim i enskim disciplinama. Organizacioni komitet formirao je bazu podataka koja sadri potrebne podatke o:
TAKMIARIMA, BORILITIMA i DISCIPLINAMA.
Propozicije takmienja doputaju da jedan takmiar moe da uestvuje u vie raznih disciplina (na primjer slalom, veleslalom), da u pojedinim disciplinama nastupa vie takmiara, dok u nekima (umjetniko klizanje, na primjer) nastupaju i takmiarski parovi. 1. ER model sistema je:
takmienje
borilite disciplina takmiar
2. Odgovarajui relacioni model glasi: Objekti u sistemu su:

TAKMIAR <st#, ime, prezime, dat_ro .,.........sp> DISCIPLINA < sd#, naziv, sb> BORILITE < sb#, naziv, lokacija> sa veznom relacijom TAKMIENJE < st#, sd#, datum_takmienja, sb > Zadatak: Prikazati ime i prezime partnera koji nastupa u disciplini "klizanje" ako je jedan od partnera AAA. SELECT ime, prezime FROM TAKMIAR T1, DISCIPLINA D WHERE naziv.D = "klizanje" AND T1.ime = "AAA", AND T1.sp IS NOT Null AND T1.st =T1.sp
232
Postaviti dodatno SQL upite koji daju odgovore na sljedea pitanja: 1. spisak takmiarskih disciplina sa datumima kada se takmienje odrava i naznakom na kome borilitu? 2. saznati za disciplinu veleslalom - mukarci kada (datum) i gdje je (lokacija-naziv borilita), kada je odrano to takmienje kao i ime i prezime takmiara koji je postigao najbolji rezultat. 3. spisak svih takmiara (ako ih ima) koji na dan takmienja (neka je to bio datum dd.mm.gggg.) nisu imali punih 18 godina pa treba da budu diskvalifikovani. 4. na osnovu imena i prezimena takmiarke u disciplini klizanje parovi, saznati ime i prezime njenog partnera? 5. spisak svih takmiara koji nastupaju u vie od jedne discipline?
233
8.9 Primjer razvoja aplikacije u dBase IV

Danas se u upotrebi nalazi niz programskih paketa koji su specijalno pripremljeni za instalaciju na personalnim raunarima, a za korienje u oblasti eksploatacije informacionih sistema. Programski paket dBase (verzija III, III+ ili IV) pojavio se me u prvima na tritu, nije zahtijevan u pogledu konfiguracije raunara a mogao se nabaviti u formi interpretera i compilera (Clipper) i zato je dugo vremena bio u upotrebi, pa su se neke aplikacije zadrale i do danas. Ovaj programski paket spada u takozvane kvazi-relacione jezike (to znai da se veze izme u tabela moraju uspostaviti programskom instrukcijom) tako da je program itljiviji za nekoga ko pred sobom ima izvorni kod, ali je programiranje istovremeno komplikovanije. To je razlog zbog kojega je, kao jedan od primjera, prikazana upotreba programskog paketa dBase. Da bi itaocu, koji do sada nije imao kontakta sa paketom dBase, procedura programiranja bila razumljivija, svaka instrukcija e biti komentarisana, to konana verzija takvog programa ne zahtijeva. Kao primjer uzmimo ve analizirani informacioni sistem sekretarijata za saobraaj. Pretpostavimo da su tabele VOZA i VOZILA kreirane i popunjene sa odgovarajuim podacima. Na poetku svakog dBase programa instrukcijom SET mogu se izabrati pogodnosti koje e biti prisutne u tom programu. Program pod nazivom EVIDENCA ima svoje ime sa ekstenzijom PRO. Na primjer:
PROGRAM EVIDENCA.PRO SET TALK OFF SET ECHO OFF SET DATE GERMAIN Komanda SET TALK OFF iskljuuje poruke obavjetenja za vrijeme izvo enja programa. Ukljuivanje te mogunosti (SET TALK ON) preporuljivo je u fazi pisanja programa, ili traenja greaka u ve napisanom programu.
234
Komanda SET ECHO ON ukljuuje prikazivanje instrukcija prilikom izvo enja programa. I ovde vai isto pravilo, suprotnu mogunost (OFF) treba koristiti u fazi testiranja programa. Komanda (GERMAIN)odre uje nani pisanja datuma u programu. Nama je najblii nain pisanja, kao u Njemakoj to jest pisanje datuma u formi dan.mjesec.godina. CLEAR - Instrukcija CLEAR brie ekran @ 0,20 SAY 1. Moguci poslovi @ 5,20 SAY 2. Uvodenje novog vozaca u registar @ 6,20 SAY 3. Brisanje vozaca iz registra @ 7,20 SAY 4. Uvodenje vozila u registar @ 8,20 SAY 5. Brisanje vozila iz registra @ 9,20 SAY 6. Nalazenje vlasnika na osnovu reg.br. @ 11,20 SAY 7. Kraj posla Sve navedene instrukcije slue za ispisivanje poruka (teksta koji je naveden pod navodnim znacima) na ekranu monitora. Brojevi, odvojeni zapetom, su koordinate na ekranu na kojima hoemo da se eljeni tekst pojavi. Prvi broj oznaava red (0 do 24), drugi broj kolonu (0 do 79). ACCEPT Upisite odgovarajuci broj TO xxx CLEAR Instrukcija ACCEPT slui za prihvatanje podatka sa tastature raunara i smjetanje u memoriju raunara na adresu xxx (xxx je memorijska varijabla). Ova instrukcija omoguava jednovremeno i ispisivanje poruka na ekranu monitora. SET PROCEDURE TO EVIDENCA DO CASE CASE xxx = 1 DO alfa CASE xxx = 2 DO beta CASE xxx = 3
235
DO gama CASE xxx = 4 DO delta CASE xxx = 5 DO eta CASE xxx = 6 DO theta CASE xxx = 7 DO kraj OTHERWISE WAIT Pogresno ukucano-pritisnite neki taster ENDCASE CLEAR SET PROCEDURE TO EVIDENCA naznaava da glavni program ima i podprograme - procedure. Instrukcijom DO CASE korisnik dobija mogunost da izborom broja opcije aktivira eljenu proceduru (ALFA, BETA, GAMA...). U sluaju da korisnik otkuca nepostojei broj (7<xxx<1) na ekranu se javlja odgovarajua poruka. Instrukcija WAIT zaustavlja program i ispisuje poruku Procedure ALFA, BETA itd. piu se kao odvojeni programi. Napiimo u ovom sluaju samo proceduru THETA jer koristi dvije datoteke. PROCEDURE THETA CLEAR SELECT 1 USE VOZILA
Instrukcija SELECT USE otvara pozvanu tabelu i daje joj broj. U konkretnom sluaju broj tabele VOZILA e biti 1.
LOCATE FOR regbr = VA-132-345 IF EOF() ? Vozilo sa tim reg. br. Nije u evidenciji CLOSE VOZILA
236
RETURN ELSE yyy = matbr SELECT 2 USE VOZAC LOCATE FOR matbr = yyy CLEAR IF EOF() ? Trazeni vozac nije u evidenciji CLOSE ALL ELSE @SAY 3,15 Podaci o vlasniku vozila @SAY 5,15 Prezime : prez @SAY 6,15 Ime : ime @SAY 7,15 Telefon : tel @SAY 8,15 Adresa : adresa @SAY 9,15 Dozvola br : brdoz ENDIF ENDIF CLOSE ALL RETURN Instrukcija LOCATE odgovara operaciji restrikcije i iz tabele VOZILA izdvaja samo onu n-torku koja ima traenu vrijednost atributa regbr#. Kako je atribut regb# kljuni, to e postojati samo jedna, ili nijedna, takva n-torka.
Ukoliko ne postoji nijedna takva n-torka (nema vozila sa tim registarskim brojem) instrukcija LOCATE e se pozicionirati na kraj - EOF(End Of File ) tabele VOZILA. U tom sluaju treba dati odgovarajuu poruku na ekran (postie se naredbom ? koja odgovara naredbi PRINT), zatvoriti tabelu VOZILA (CLOSE), i vratiti program u glavni program instrukcijom RETURN. Ukoliko u tabeli VOZILA postoji takva n-torka (ELSE):
237
promjenljivoj yyy treba pripisati vrijednost podatka atributa matbr u toj n-torki, oistiti ekran kako bi na ekranu mogla biti ispisana poruka, otvoriti tabelu VOZA (njen broj e biti 2), pronai u njoj n-torku za koju je zadovoljen uslov: matbr = yyy, ako je nema dati odgovarajuu poruku na ekranu, ako je prisutna odtampati sve podatke o vozau iz te n-torke tabele VOZA, zatvoriti obje otvorene tabele (CLOSE ALL), i vratiti se u glavni program.
I preostale procedure se mogu programirati na slian nain. Naravno, ovaj primjer prije svega treba da pokae kako se nekada radilo, kada nisu postojali moni vizuelni softverski alati poput onih koji su ugraeni u Access. Zbog toga emo ovaj isti primjer uraditi i upotrebom Accessovih "arobnjaka".
238
8.10 Primjer razvoja aplikacije u Access 2000

Primjer bi trebalo postupno objasniti. Ja sam, pod pretpostavkom da nita o ovome ne znam, pokuao, sljedei tekst, da napravim ovu aplikaciju pa nisam uspio. Kreiramo prvo tabele koje odgovaraju modelu sa slike 8.1.
Slika 8.9 Definicija tabele VOZA
Slika 8.10 Definicija tabele VOZILA sa nametnutim integritetom za polje matbr
Pri tome moemo u polje Look Up podatka matbr u tabeli VOZILA nametnuti dodatna pravila integriteta: ovo polje je padajua lista (Combo Box) koja moe uzimati samo vrijednosti koje postoje u istoimenom polju u tabeli VOZAC, slika 8.12. I u ovom sluaju imamo ne samo
239
proveru ispravnosti podataka ve pri unosu ne moramo da ukucavamo podatak (i rizikujemo pojavu greke), ve podatak izabiramo iz liste u kojoj moe biti prikazano i ime i prezime vozaa kao dodatna mera provere. To se postie upitom:
SELECT vozac.matbr, vozac.ime, vozac.prezime FROM vozac; U polju granina kolona (Bound Column) upiemo vrednost 1 (prva kolona u upitu je matbr), broj kolona je 3 (Column Count), irina svake kolone je 2 cm, a irina liste 8cm.
Zahvaljujui nametnutom integritetu unos u tabelarnom prikazu (Datasheet) je vrlo bezbedan i lak, slika 8.13.
Slika 8.13 Pri unosu neki podaci se prosto biraju iz ponu ene liste
Za ovako kreiran model koristei Accessove arobnjake, na primjer Autoform bez ikakvog dodatnog truda dobijamo forme za unos podataka u osnovne tabele, prikazane na slici 8.14.
240
Slika 8.14 Sam Access generie obrasce za pregled i unos zapisa
Uoavamo da je zbog veze 1:N izme u tabela VOZA i VOZILA u obrascu za upis novog vozaa u registar odmah data mogunost da upiemo i podatke o vozilu ako su nam ti podaci dostupni. Obrazac vozac ima podobrazac za vozila. Ovi obrasci se dodatno mogu doraditi u Design modu tako da im se dodaju jo neke osobine koji sam Access nije mogao da doda jer mu naravno nije poznata logika aplikacije. Napravimo obrazac regbr za zadavanje registarskog broja vozila preko padajue liste koja uzima podatke iz tabele VOZILA, slika 8.15.
dugme za pokretanje upita parametar na osnovu kojeg se generie obrazac vlasnik vozila
Slika 8.15 Registarski broj se upie ili izabere iz liste
Sada kreiramo jedan parametarski upit koji omoguava da na osnovu unetog registarskog broja vozila, iz prethodnog obrasca, dobijemo podatke i o vlasniku i o vozilu. To je upit parametar:
SELECT vozila.*, vozac.* FROM vozac INNER JOIN vozila ON [vozac].[matbr]=[vozila].[matbr] WHERE ((([vozila].[regbr])=[forms]![regbr]!combo0));
Klikom na dugme na i vlasnika na obrascu regbr pokree se obrazac vlasnik vozila kreiran direktno arobnjakom na osnovu upita parametar. Na ekranu e se pojaviti svi pomenuti podaci, slika 8.16.
241
Slika 8.16 U obrascu vlasnik vozila prikazani su svi podaci o vozilu i vlasniku
Na kraju napravimo glavnu formu, poetni obrazac (slika 6.17.) koji se pojavljuje pri pokretanju aplikacije (postavimo je u Tools / Start Up) na kojoj se nalaze samo komandna dugmad za izbor opcija: na i vlasnika vozila, unos novog vozaa i unos novog vozila.
Slika 8.17 Pri pokretanju aplikacije pojavljuje se glavna forma, a ne radni prozor
Kada kliknemo na dugme na i vlasnika vozila, pokree se obrazac regbr, a preko njega obrazac vlasnik vozila. Klikom na preostala dugmad pokreu se drugi obrasci (aplikacije). To se postie na osnovi Visual Basic koda koji generie sam Access ali te procedure za obradu doga aja (na primjer za obradu doga aja klik()) moemo i sami napisati:
Dugme na i vlasnika vozila Private Sub Command0_Click() On Error GoTo Err_Command0_Click Relacione baze podataka
242
Projektovanje informacionih sistema Dim stDocName As String Dim stLinkCriteria As String stDocName = "regbr" DoCmd.OpenForm stDocName, , , stLinkCriteria Exit_Command0_Click: Exit Sub Err_Command0_Click: MsgBox Err.Description Resume Exit_Command0_Click End Sub
Dugme unos novog vozaa Private Sub Command1_Click() On Error GoTo Err_Command1_Click Dim stDocName As String Dim stLinkCriteria As String stDocName = "noviVozac" DoCmd.OpenForm stDocName, , , stLinkCriteria Exit_Command1_Click: Exit Sub Err_Command1_Click: MsgBox Err.Description Resume Exit_Command1_Click End Sub
Dugme unos novog vozila Private Sub Command2_Click() On Error GoTo Err_Command2_Click Dim stDocName As String Dim stLinkCriteria As String stDocName = "unos vozila" DoCmd.OpenForm stDocName, , , stLinkCriteria Exit_Command2_Click: Exit Sub Err_Command2_Click: MsgBox Err.Description Relacione baze podataka
Projektovanje informacionih sistema Resume Exit_Command2_Click End Sub
243
Obrazac (forma) regbr: Private Sub nadji_vlasnika_Click() On Error GoTo Err_nadi_vlasnika_Click Dim stDocName As String stDocName = "vlasnik vozila" DoCmd.OpenQuery stDocName, acNormal, acEdit Exit_nadji_vlasnika_Click: Exit Sub Err_nadji_vlasnika_Click: MsgBox Err.Description Resume Exit_nadi_vlasnika_Click End Sub
Private Sub Command3_Click() On Error GoTo Err_Command3_Click Dim stDocName As String Dim stLinkCriteria As String stDocName = "vlasnik vozila" DoCmd.OpenForm stDocName, , , stLinkCriteria Exit_Command3_Click: Exit Sub Err_Command3_Click: MsgBox Err.Description Resume Exit_Command3_Click End Sub
Alati koje nudi Access kao relacioni sistem za upravljanje bazama podataka olakavaju rad programera i projektanata, omoguavaju brzo i lako generisanje obrazaca koji imaju vrlo lep izgled, pregledni su i to je vrlo vano, uvek se mogu doraditi ukoliko smo neto ispustili. Pri tome,
244
najee ne moramo menjati ni logiki projekat informacionog sistema (E-R ili relacioni model), ni fiziku implementaciju (bazu podataka).
245
246
255
Literatura:
1. E. F. CoddA Relation Model of Data for Large Shared Data Banks Communications of the ACM, Volume 13, Number 6, (June 1970), pages 377-387.
U ovome radu Codd je prvi definisao principe i strukturu relacionog modela.
2. Chen P.The Entity-Relationship Model: Toward a Unified View of Data ACM Transactions on Database Systems, Volume 1, Number 1, (January 1976), pages 9-36.
U radu su prikazani principi i struktura E-R modela
3. Alagi S. Relacione baze podataka, Svjetlost , Sarajevo, 1984.

Jedna od prvih knjiga iz ove oblasti na naem jeziku. Nedovoljna za dobijanje potpune slike o dananjem stanju.
4. Radovan M. Projektiranje informacijskih sistema Informator, Zagreb 1989.

Sveobuhvatan prilaz projektovanju informacionih sistema bez ulaenja u nain obrade podataka.
5. Marjanovi Z. ORACLE relacioni sistem za upravljanje bazom podataka Breza, Ljig 1990.
Vrijednost knjige je u tome to se u njoj mogu nai i elementi programskog jezika SQL, mnotvo upita i elementi projektovanja baze podataka, kao i niz primjera aplikativnih programa.
6. Simi R. Organizacija podataka Nauna knjiga, Beograd,1990.

Pregledan uvod u tehniku prikupljanja i organizacije podataka.
7. Mii V. Relaciona baza podataka Rdb/VMS Tehnika knjiga, Beograd, 1990

Autor se bavi problemima programiranja i razlikama izme u verzija SQL-a.
256
8. Filipovi M. dBASE III+ prirunik Boris Kidri Vina, Beograd. 1991

U knjizi se mogu nai elementi programskog jezika, elementi projektovanja baze podataka, kao i niz praktinih aplikativnih primjera programa.
9. Bobrowski S. Oracle 7 i obrada podataka po modelu klijent/server Mikro knjiga, Beograd, 1995.
Autor se bavi problemima obrade projektovanja i administriranje baza podataka primenom SQL-a.
10. Vujnovi R. SQL i relacijski model podataka Znak, Zagreb, 1995.

Paralelno se analizira modeliranje podataka i njihova obrada, pomou SQL-a.
11. Wynkoop S. Vodi kroz SQL Server 7.0, CET, Beograd, 1999.
Veoma koristan prirunik kako za poetnike tako i za iskusne projektante, naroito pogodan za administratore Microsoft RDBMS SQL Servera.
12. Obradovi S. i grupa autora MS-Access Projektovanje baza podataka i aplikacija Via elektrotehnika kola, Beograd, 1999.
Knjiga posveena programiranju u Accessu 2000 sa osvrtom na principe projektovanja relacionih baza podataka
13. Grupa autora Access 2000 korak po korak CET, Beograd, 1999.
Knjiga posveena programiranju u Accessu 2000 bez ulaenja u principe projektovanja relacionih baza podataka

Baze Podataka

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Baze Podataka

Uploaded by

Copyright:

Available Formats

dr Pavle Kalu eri

Autori: Recenzenti: Izdava: Lektor Korice: Prelom: Tira: tampa:

Predgovor etvrtom izdanju

Projektovanje informacionih sistema

I DIO - SINTEZA LOGIKOG MODELA

3. Osnove relacione algebre

Relacione baze podataka

Projektovanje informacionih sistema

4. Sinteza relacionog modela

II DIO - SINTEZA FIZIKOG MODELA

Projektovanje informacionih sistema

Zadaci Literatura Indeks

206 199 207

Relacione baze podataka

Projektovanje informacionih sistema

Logiki modeli informacionih sistema

Relacione baze podataka

Projektovanje informacionih sistema

Relacione baze podataka

Projektovanje informacionih sistema

Relacione baze podataka

Projektovanje informacionih sistema

Projektovanje informacionih sistema

Relacione baze podataka

Projektovanje informacionih sistema

Pod pojmovima podatak i informacija, u strunoj literaturi, danas se podrazumijeva:

Relacione baze podataka

Projektovanje informacionih sistema

podatak-1 obrada podataka informacija

Objekat posmatranja - entitet

Projektovanje informacionih sistema

Projektovanje informacionih sistema

Projektovanje informacionih sistema

Duina irina (km) (m)

Slika 1.2 Primjer tabele ULICA

Projektovanje informacionih sistema

Projektovanje informacionih sistema

1.3 Veze me u objektima

Projektovanje informacionih sistema

Projektovanje informacionih sistema

1.4 Modeli informacionih sistema

Projektovanje informacionih sistema

Projektovanje informacionih sistema

NASTAVNICI ifra nastavnika ime ifra polaznika ime

Slika 1.4 Primjer hijerarhijske strukture informacionog sistema

a to je na slici 1.4. jasno vidljivo.

Projektovanje informacionih sistema

Projektovanje informacionih sistema

Relacione baze podataka

Projektovanje informacionih sistema

Slika 1.5 Hijerarhijska struktura informacionog sistema univerziteta

Projektovanje informacionih sistema

Relacione baze podataka

Projektovanje informacionih sistema

Slika 1.6 Primjer mrenog modela

Projektovanje informacionih sistema

Relacione baze podataka

Projektovanje informacionih sistema

Projektovanje informacionih sistema

2.1 Osnovne definicije

Relacione baze podataka

Projektovanje informacionih sistema

a. Sve vrijednosti podataka jednog atributa moraju biti istog tipa.