Download pdf - Izrada Baze Podataka

7/27/2019 Izrada Baze Podataka

1/42

Kandidat: Demo Braninovi

Travnik, juli 2010. godine

ZAVRNI RAD

IIZZRRAADDAAIIIIMMPPLLEEMMEENNTTAACCIIJJAA BBAAZZEEPPOODDAATTAAKKAA

ZZAAEEVVIIDDEENNCCIIJJUUIIIIZZVVJJEETTAAJJAAUUTTOOKKOOLLEE

UNIVERZITET U TRAVNIKU

EDUKACIJSKI FAKULTET

ODSJEK: MATEMATIKAIINFORMATIKA


2/42

1

SAETAK

U modernom poslovnom i institucionalnom svijetu upravljaka tijela raspolau sa sve vie

resursa, odnosno sa sve veom koliinom podataka, te je kroz stvaranje baza podataka

neophodno olakati prikupljanje podataka i skratiti put do traenih podataka. U ovom radu

su opisani osnovni pojmovi vezani uz temu zavrnog rada radi lakeg shvaanja tematike

koja obuhvaa izradu i implementaciju baze podataka te problematike na koju nailaze

osobe koje su na direktan nain ukljueni u evidenciju i izvjetaj rada autokola i prateu

dokumentaciju u procesu obuavanja i polaganja vozakih ispita. Ideja za izradu baze

podataka se sama po sebi nametnula zbog obima podataka koji se pohranjuju i obrauju, a

potvrdila se i anketnim ispitivanjem vlasnika autokola i njihovom reakcijom nakon to su

eksperimentalno probali njene mogunosti. Svakako da je na pozitivne reakcije buduih

korisnika ovakve baze podataka ponajvie, zbog nedovoljne informatike pismenosti,

utjecala jednostavnost rukovanja bazom, od samog pokretanja, jednostavnog prelaska iz

forme u formu, upis kandidata i stvoreni izvjetaji koji se jednostavnim klikom na dugme

ispis printaju.

ABSTRACT

The modern business and institutional world has its managing bodies that has at its own

disposal more and more resources, I mean the bigger quantity of data, and out of that

through the creation of the bases of data it is essential to make easier collecting of data

and shorten the path to the needed data. I have described, in this Diploma Paper, the

elementary terms linked to this Paper for easier understanding of the theme that frames

building and implementation of base of data but also other problems that people have got

working directly or indirectly on evidencing and reporting from Driving schools and

following documentation in the process of training and taking driving test. The idea for

building the base of data imposed itself because of the quantity of data that must be saved

and processed, and it was also confirmed by the opinion poll made with the owners of

Driving schools and their reaction after they experimentally tried the abilities of the data

base. Surely that this project had positive reactions on itself from the future users of such

base of data mostly because of simplicity of using it, starting, switching from one form to

another, signing in the candidates and printing of already prepared reports by clicking the

Print button; but also because of insufficient IT education of people.


3/42

2

SADRAJSAETAK ................................ ................................ ................................ ................................ .... 1

ABSTRACT ................................ ................................ ................................ ................................ . 1

SADRAJ................................ ................................ ................................ ................................ ..... 2

1. UVOD ................................ ................................ ................................ ................................ ..... 3

1.1. Osnovni pojmovi vezani uz baze podataka ................................ ................................ ..... 31.2. Baza podataka, DBMS, model podataka ................................ ................................ ......... 3

1.3. Arhitektura baze podataka ................................ ................................ .............................. 4

1.4. Jezici za rad s bazama podataka ................................ ................................ ..................... 5

1.5. Poznati softverski paketi za rad s bazama podataka ............. ............. ...... ............ ............ 7

1.6. Vrste baza podataka ................................ ................................ ................................ ....... 8

1.7. Osnovi baze podataka autokole ................................ ................................ .................. 10

2. PROBLEM I PREDMET ................................ ................................ ................................ .... 11

3. CILJ ................................ ................................ ................................ ................................ ..... 13

3.1. Ciljevi koji se nastoje postii koritenjem baza podataka ............. ............. ...... ............ .. 133.2. Ciljevi koji se postavljaju izradom baze podataka autokole ............. ............. ...... ......... 14

4. OBRAZLOENJE TEME ................................ ................................ ................................ .. 15

4.1. ivotni ciklus baze podataka ................................ ................................ ........................ 15

4.2. Analiza potreba ................................ ................................ ................................ ............ 15

4.3. Modeliranje podataka ................................ ................................ ................................ ... 15

4.4. Implementacija ................................ ................................ ................................ ............ 16

4.5. Testiranje ................................ ................................ ................................ ..................... 16

4.6. Odravanje ................................ ................................ ................................ .................. 16

5. PREGLED PUBLIKACIJA ................................ ................................ ................................ 176. DISKUSIJA ................................ ................................ ................................ ........................ 19

6.1. Modeliranje entiteta i veza ................................ ................................ ........................... 19

6.2. Relacijski model ................................ ................................ ................................ .......... 21

6.3. Normalizacija relacijske sheme ................................ ................................ .................... 23

6.4. Razlozi zbog kojih se moe odustati od normalizacije ............ ............. ....... ............. ..... 26

6.5. Jezici za relacijske baze podataka ................................ ................................ ................. 26

6.6. Fizika graa baze podataka ................................ ................................ ......................... 27

6.7. Pristup na osnovu primarnog kljua................................ ................................ .............. 30

6.8. Implementacija relacijskih operacija ................................ ................................ ............ 31

6.9. Integritet i sigurnost podataka ................................ ................................ ...................... 32

6.10. Izrada baze podataka u MS Access-u ................................ ................................ ........ 34

6.11. Analiza i efekti postignua ................................ ................................ ....................... 39

7. ZAKLJUAK ................................ ................................ ................................ .................... 40

8. LITERATURA ................................ ................................ ................................ ................... 41


4/42

3

1. UVOD

1.1. Osnovni pojmovi vezani uz baze podatakaBaza podataka je skup nekog informacionog sistema. Ona sadri podatke razliitih

objekata poslovnog sistema, kao to su na primjer: poslovni partneri, projekti, proizvodi,

usluge, fakture, narudbe, ugovori itd.Evo nekoliko definicija baza podataka:

Baza podataka je skup meusobno ovisnih podataka, pohranjenih bez redundancije

(preklapanja), koji slue jednoj ili vie aplikacija na optimalan nain, gdje su podaci

neovisni o programimakoji se obrauju i gdje postoji kontroliran pristup podacima (Martin,

1977); Baza podataka je skup operativnih i integriranih podataka obraivanih u jednoj

organizaciji (Date, 1990).

Baze podataka predstavljaju vii nivo rada s podacima u odnosu na klasine

programske jezike. Rije je o tehnologiji koja je nastala s namjerom da se uklone slabosti

tradicionalne automatske obrade podataka iz 60-tih i 70-tih godina 20. vijeka. Ta

tehnologija osigurala je veu produktivnost, kvalitetu i pouzdanost u razvoju aplikacija

koje se svode na pohranjivanje i pretraivanje podataka u raunalu.

1.2. Baza podataka, DBMS, model podatakaBaza podataka je skup meusobno povezanih podataka, pohranjenih u vanjskoj

memoriji raunara. Podaci su istovremeno dostupni raznim korisnicima i aplikacijskim

programima. Ubacivanje, promjena, brisanje i itanje podataka obavlja se posredstvom

zajednikog softvera. Korisnici i aplikacije pritom ne moraju poznavati detalje fizikog

prikaza podataka, ve se referenciraju na logiku strukturu baze.

Sistem za upravljanje bazom podataka (Data Base Management System -

DBMS) je posluitelj (server) baze podataka. On oblikuje fiziki prikaz baze u skladu s

traenom logikom strukturom. Takoer, on obavlja u ime klijenata sve operacije s

podacima. Dalje, on je u stanju podrati razne baze, od kojih svaka moe imati svojulogiku strukturu, no u skladu s istim modelom. Isto tako, brine se za sigurnost podataka,

te automatizira administrativne poslove s bazom. Podaci u bazi su logiki organizirani u

skladu s nekim modelom podataka.


5/42

4

Model podataka je skup pravila koja odreuju kako moe izgledati logika

struktura baze. Model ini osnovu za koncipiranje, projektiranje i implementiranje baze.

Dosadanji DBMS-i obino su podravali neki od sljedeih modela:

Relacijski model. Zasnovan na matematikom pojmu relacije. I podaci i veze

meu podacima prikazuju se pravokutnim tabelama.Mreni model. Baza je predoena usmjerenim grafom. vorovi su tipovi zapisa, a

lukovi definiraju veze meu tipovima zapisa.

Hijerarhijski model. Specijalni sluaj mrenog. Baza je predoena jednim stablom

ili skupom stabala. vorovi su tipovi zapisa, a hijerarhijski odnos nadreeni-podreeni

izraava veze meu tipovima zapisa.

Objektni model. Inspiriran je objektno-orijentiranim programskim jezicima. Baza

je skup trajno pohranjenih objekata koji se sastoje od svojih internih podataka i metoda

(operacija) za rukovanje s tim podacima. Svaki objekt pripada nekoj klasi. Izmeu klasa se

uspostavljaju veze nasljeivanja, agregacije, odnosno meusobnog koritenja operacija.

Hijerarhijski i mreni model bili su u uptrebi u 60-tim i 70-tim godinama 20.

stoljea. Od 80-tih godina pa sve do dananjih dana prevladava relacijski model. Oekivani

prijelaz na objektni model za sada se nije desio, tako da dananje baze podataka uglavnom

jo uvijek moemo poistovjetiti s relacijskim bazama.

1.3. Arhitektura baze podatakaArhitektura baze podataka sastoji se od tri sloja i suelja meu slojevima, kao to

je prikazano na Slici 1. rije je o tri nivoa apstrakcije:

Fiziki nivo odnosi se na fiziki prikaz i raspored podataka na jedinicama vanjske

memorije. To je aspekt kojeg vide samo sistemski programeri (oni koji su razvili DBMS).

Sam fiziki nivo moe se dalje podijeliti na vie pod-nivoa apstrakcije, od sasvim

konkretnih staza i cilindara na disku, do ve donekle apstraktnih pojmova datoteke i zapisa

kakve susreemo u klasinim programskim jezicima.

Globalni logiki nivo odnosi se na logiku strukturu cijele baze. To je aspekt kojeg

vidi projektant baze odnosno njen administrator. Zapis logike definicije naziva se shema

(engleski takoer schema). Shema je tekst ili dijagram koji definira logiku strukturu baze,

i u skladu je sa zadanim modelom. Dakle imenuju se i definiraju svi tipovi podataka i veze

meu tim tipovima, u skladu s pravilima koritenog modela. Takoer, shema uvodi i

ogranienja kojim se uva integritet podataka.


6/42

5

Lokalni logiki nivo odnosi se na logiku predstavu o dijelu baze kojeg koristi

pojedina aplikacija. To je aspekt kojeg vidi korisnik ili aplikacijski programer. Zapis jedne

lokalne logike definicije zove se pogled (engleski view) ili pod-shema. To je tekst ili

dijagram kojim se imenuju i definiraju svi lokalni tipovi podataka i veze meu tim

tipovima, opet u skladu s pravilima koritenog modela. Takoer, pogled zadajepreslikavanje kojim se iz globalnih podataka i veza izvode lokalni.

Za stvaranje baze podataka potrebno je zadati samo shemu i poglede. DBMS tada

automatski generira potrebni raspored pohranjivanja i fiziku bazu. Administrator moe

samo donekle uticati na fiziku grau baze, podeavanjem njemu dostupnih parametara.

Programi i korisnici ne pristupaju izravno fizikoj bazi, ve dobivaju ili pohranjuju

podatke posredstvom DBMS-a. Komunikacija programa odnosno korisnika s DBMS-om

obavlja se na lokalnoj logikom nivou.

1.4. J

ezici za rads

bazama podatakaKomunikacija korisnika odnosno aplikacijskog programa i DBMS-a odvija se

pomou posebnih jezika. Ti jezici tradicionalno se dijele na sljedee kategorije.

Jezik za opis podataka (Data Description Language - DDL). Slui projektantu

baze ili administratoru u svrhu zapisivanja sheme ili pogleda. Dakle tim jezikom

definiramo podatke i veze meu podacima, i to na logikom nivou.

Lokalni

logiki nivo

Globalni

logiki nivo

Fiziki nivo

Aplikacijskiprogram 2

Datoteke

Pogled 2

Datoteke


Pogled 1


Pogled 3

Shema

Rasporedohran ivan a

Slika 1. Arhitektura baze odataka (Demo Braninovi, 2010


7/42

6

U nekim sluajevima postoji posebna varijanta jezika za shemu, a posebna za

poglede. Naredbe DDL obino podsijeaju na naredbe za definiranje sloenih tipova

podataka u jezicima poput COBOL, PL/I, C, Pascal.

Jezik za manipuliranje podacima (Data Manipulation Language - DML). Slui

programeru za uspostavljanje veze izmeu aplikacijskog programa i baze. Naredbe DMLomoguuju manevriranje po bazi, te jednostavne operacije kao to su upis, promjena,

brisanje ili itanje zapisa. U nekim softverskim paketima, DML je zapravo biblioteka

potprograma: naredba u DML svodi se na poziv potprograma. U drugim paketima zaista

se radi o posebnom jeziku: programer tada pie program u kojem su izmijeane naredbe

dvaju jezika, pa takav program treba prevoditi s dva prevodioca (DML-precompiler, obini

compiler).

Jezik za postavljanje upita (Query Language - QL). Slui neposrednom korisniku

za interaktivno pretraivanje baze. To je jezik koji podsijea na govorni (engleski) jezik

Naredbe su neproceduralne, dakle takve da samo specificiraju rezultat kojeg elimo dobiti,

a ne i postupak za dobivanje rezultata.Ovakva podjela na tri jezika danas je veprilino

zastarjela. Naime, kod relacijskih baza postoji tendencija da se sva tri jezika objedine u

jedan sveobuhvatni. Primjer takvog integriranogjezika za relacijske baze je SQL: on slui

za definiranje podataka, manipuliranje i pretraivanje. Integrirani jezik se moe koristiti

interaktivno (preko on-line interpretera) ili se on moe pojavljivati uklopljen u aplikacijske

programe. Naglasimo da gore spomenute vrste jezika nisu programski jezici. Dakle ti jezici

su nam nuni da bi se povezali s bazom, no oni nam nisu dovoljni za razvoj aplikacija koje

e neto raditi s podacima iz baze. Tradicionalni nain razvoja aplikacija koje rade s bazom

je koritenje klasinih programskih jezika (COBOL, PL/I, C, Pascal . . . ) s ugnijedenim

DML-naredbama. U 80-tim godinama 20. stoljea bili su dosta popularni i tzv. jezici 4.

generacije (4-th Generation Languages - 4GL): rije je o jezicima koji su bili namijenjeni

iskljuivo za rad s bazama, te su zato u tom kontekstu bili produktivniji od klasinih

programskih jezika ope namjene. Problem s jezicima 4. generacije je bio u njihovoj

nestandardnosti: svaki od njih je u pravilu bio dio nekog odredenog softverskog paketa za

baze podataka, te se nije mogao koristiti izvan tog paketa (baze). U dananje vrijeme,

aplikacije se najee razvijaju u standardnim objektno orijentiranim programskim

jezicima (Java, C++, . . . ). Za interakcije s bazom koriste se unaprijed pripremljene klase

objekata. Ovakva tehnika je dovoljno produktivna zbog koritenja gotovih klasa, a

rezultirajui program se lako dotjeruje, uklapa u vee sisteme ili prenosi s jedne baze na

drugu.


8/42

7

1.5. Poznati softverski paketi za rad s bazama podatakaBaze podataka se u pravilu realiziraju koritenjem nekog od provjerenih softverskih

paketa. Tabelarni prikaz 1. daje pregled softvera koji u ovom trenutku predstavljaju

tehnoloki vrh te imaju znaajan udjel na svjetskom tritu. Gotovo svi dananji softverskipaketi podravaju relacijski model i SQL. Svaki od njih sadri svoj DBMS, uobiajene

klijente (na primjer interaktivni interpreter SQL), te biblioteke i alate za razvoj aplikacija.

Svaki paket isporuuje se u verzijama za razne raunarske platforme (operacijske sisteme).

Konkurencija meu proizvodaima softvera za baze podataka je izuzetno velika, tako da je

posljednjih godina esto dolazilo do njihovog nestanka, spajanja ili preuzimanja. Lista

relevantnih softverskih paketa zato je svake godine sve kraa. Jedino osvjeenje

predstavlja nedavna pojava public-domain sotvera poput MySQL.

Tabela 1. Poznati softverski paketi za rad s bazama podataka (Manger, 2008)

Proizvoa Proizvod Operacioni sistem Jezici

IBM Corporation DB2Linux, UNIX (razni),MS

Windows NT/2000/XP,VMS,MVS, VM, OS/400

SQL, COBOL,Java, . . .

Oracle Corporation OracleMS Windows (razni),

Mac OS, UNIX (razni),Linux i drugi

SQL,Java i drugi

IBM Corporation(prije : InformixSoftware

Inc.)

Informix UNIX (razni), Linux,

MS Windows NT/2000/XP

SQL,

Java i drugi

MicrosoftMS SQL

ServerMS Windows NT/2000/XP SQL, C++, . . .

MySQL AB MySQL Linux, UNIX (razni),MS Windows (razni), Mac OS

SQL,C, PHP, . . .

Sybase Inc. SybaseSQL Server

MS Windows NT/2000, OS/2,Mac, UNIX (razni),

UNIXWare

SQL, COBOL, . ..

Hewlett Packard Co. Allbase/SQL UNIX (HP-UX) SQL, 4GL, C, . . .

Cincom Systems Inc.Supra

MS Windows NT/2000,Linux,

UNIX (razni), VMS, MVS,VM

SQL,

COBOL, . . .

Microsoft Corporation MS Access MS Windows (razni)Access Basic,

SQL


9/42

8

1.6. Vrste baza podatakaDanas baze podataka sadre podatke razliitih medijskih vrsta, pa se zato govori o

multimedijskim podacima, a baze koje sadre takve podatke nazivaju se multimedijskim

bazama podataka. Pored tekstualnih podataka, tu su i podaci koji opisuju slike (nepokretneili pokretne, kada govorimo o videozapisu) ili zvuk. Ovisno o vrsti i namjeni podataka u

bazi podataka, kao i nainima koritenja podataka, razlikujemo baze: formatiranih

podataka, neformatiranih podataka i baze znanja.

1.6.1. Baze formatiranih podatakaU poslovnim primjenama najee se koriste baze formatiranih podataka.

Tabela 2. prikazuje primjer formatiranih podataka. U tabeli su podaci o

instruktorima: ifra instruktora, naziv instruktora i kategorije koje obuava, registrovani u

jednakim slogovima. Pri tome je format svakog sloga isti, a slog se sastoji od tri polja, od

kojih je prvo numeriko, a druga dva su znakovna, odnosno tekstualna. U svakom slogu su

podaci jednog instruktora.

Tabela 2. Tabela instruktora vonje autokole Turbo (Demo Braninovi, 2010)

ifra instruktora Ime i prezime Kategorije koje obuava

01 Samir Tuholjakovi B1;B; C1;C;C1E;CE;D1;D; D1E;DE

02 Bilal Tulumovi Predava teoretske nastave03 Nurfet Balki B1;B;C1;C;C1E;CE

04 Fehim Mei B1;B

05 Adnan Mukinovi B1;B;C1;C;

06 Nedad Hajdarbegovi B1;B;C1;C;

Ovisno o nainu izgradnje logike i fizike strukture podataka, razlikuju se:

y starije baze podataka, graene po hijerarhijskom ili mrenom modelu, tey savremene baze podataka, graene po relacijskom, objektnom ili dimenzijskommodelu.

Dananje baze podataka su najee relacijske. Podaci ovakvih baza zorno se

prikazuju tabelama. Zbog iroke primjene relacijskih baza podataka, istima e u ovom

poglavlju biti posveena najvea panja.


10/42


11/42

10

1.7. Osnovi baze podataka autokolePoznato nam je da sam pojam kola za sebe vee mnogo dokumentacije u kojoj

se evidentiraju mnogi podaci vezani za samu kolu, vlasnika kole, nastavno osoblje,

pomono osoblje, polaznike kole, objekat kole, osnovna sredstva, sitni iventar, opremu,trokove, prihode, prijave, odjeve, uvjerenja, potvrde, nastavne planove i programe,

planirane asove, odrane asove, . . .i jo mnogo toga, zaista previe za nabrojati, a tek

kada treba neki od dokumenata pronai u arhivi...to je tek problem, ako nismo dobro

organizovali prostor gdje smjetamo svu poterebnu dokumentaciju. Problem postaje vei

kod kola koje imaju mnogo zaposlenih i mnogo polaznika, uenika, kandidata, u

zavisnosti o kakvoj vrsti kole je rije.

U ovom radu pokuavam predstaviti kolika je potreba za organizovanom bazom

podataka u jednoj autokoli, zbog ega je neophodno da svi podaci budu na dohvat ruke usvakom momentu i koliko e to olakati rad administrativnom radniku autokole. to je to

to jedna autokola ima evidentirati, koji su to zakonski i podzakonski akti koji obavezuju

vlasnika autokole da pravovremeno i evidentira odreene radnje, te da za sve to radi u

okviru kole ima spreman izvjetaj nadlenim organima? Za sva ova pitanja pokuati u

dati odgovor u ovom radu, kako bi u budunosti ovakav nain organizacije baze podataka

sve autokole prihvatile kao neto to je potrebno, neto to je obaveza i neto to je

jednostavno za rukovanje i ugodno za rad ak i onim administrativnim radnicima koji

imaju samo elementarno poznavanje informatike tehnike. Ideja za rad na ovom problemuve mi je prisutna proteklih par godina pratei rad autokola i Odsjeka za saobraajnu

edukaciju pri Ministarstvu obrazovanja, nauke, kulture i sporta Tuzlanskog kantona a

sapozicije lana komisije za polaganje vozakih ispita. Obzirom na injenicu, koliko je

meni poznato, da jo do danas niko, na podruju Bosne i Hercegovine, nije uradio bazu

podataka za autokole koja je aktivna i funkcionalna onda nisam u poziciji da pravim

poreenja, odnosno da doraujem nedostatke predhodnih. Bazu u morati testirati na nain

da je pustim u upotrebu u auto koli Turbo, u kojoj sam nekoliko godina radio, i nakon

njene upotrebe saznam dali u potpunosti zadovoljava potrebe autokole. Posebnu panju

privukla mi je ideja da iznaem mogunost povezivanja baza podataka svih autokola koje

su obavezne da svoje izvjetaje alju u Odsjek za saobraajnu edukaciju u ministarstu

obrazovanja sa bazom koja bi primala te izvjetaje grupisala i razvrstavala ih po ispitnim

mjestima i autokolama.


12/42

11

2. PROBLEMIPREDMET

Primjena novog Zakona o osnovama sigurnosti saobraaja na putevima

u Bosni i Hercegovini

Stupanjem na snagu novog ZOBS u BIH u estom mjesecu 2007.godine, lan 179.

tog Zakona je odredio da: Za poslove provoenja i organiziranja polaganja vozakog

ispita odgovorni su organi entiteta, kantona i Brko Distrikta Bosne i Hercegovine,

nadleni za obrazovanje . Time je sa dotadanjeg organizatora i provodioca ispita,

(MUP-a BiH) organiziranja polaganja vozakih ispita, nadzor nad radom autokola i

cjelokupnu edukaciju u osnovnim kolama i autokolama preuzelo tijelo kojemu to nekako

po prirodi i pripada. Osim navedenog u okviru rada Odjeljenja za saobraajnu edukacijuduan je voditi mnogobrojne evidencije o autokolama i kandidatima za polaganje

vozakih ispita, to obavezuje i lanovi 47. i 51.ovog Zakona:

(Voenje evidencije)

(1) Organ entiteta, kantona i Brko Distrikta Bosne i Hercegovine nadlean za

obrazovanje vodi evidenciju o polaganju vozakih ispita i to:

a) Registar polaganja ispita za vozae motornih vozila;b)Registar provjere poznavanja propisa o sigurnosti saobraaja na putevima, za vozae

upuene na provjeru od strane nadlenog organa;c) Registar provjere propisa o sigurnosti saobraaja na putevima za vozae bicikla sa

motorom, traktora, trolejbusa, motokultivatora i radnih maina.

(2) Registri iz prethodnog stava sadre: redni broj, prezime i ime kandidata i ime jednog od

roditelja, datum i mjesto roenja, adresu stanovanja, kategoriju ili podkategoriju za koju

kandidat polae ispit.

(3) Evidencija se vodi na obrascu koji je prilog broj 15. i ini sastavni dio ovog Pravilnika.

(4) Registri se zakljuuju na kraju svake kalendarske godine i uvaju se kao dokument

trajne vrijednosti.Organi entiteta, kantona i Brko Distrikta Bosne i Hercegovine, nadleni za

obrazovanje, vode evidenciju o polaganju ispita i iste objavljuju najmanje jednom

godinje.


13/42

12

Autokole su takoe obavezne ovim Zakonom kroz lan 59.:

(Voenje evidencije u autokolama)

(1) Autokola vodi matinu knjigu koja se uva kao dokument trajne vrijednosti. Matina

knjiga sadri slijedee podatke: 1. redni broj, 2. prezime, ime oca, ime i JMB, 3. datum

roenja, 4. ljekarsko uvjerenje broj i naziv ustanove koja ga je izdala, 5. potvrda ozavrenoj teoretskoj nastavi datum i broj, 6. potvrda o uspjeno zavrenoj nastavi iz

pruanja prve pomoi povrijeenim u saobraajnoj nezgodi datum i broj, 7. potvrda o

zavrenom osposobljavanju iz upravljanja motornim vozilom datum i broj, 8. broj knjiice

kandidata, 9. napomena.

(2) Autokola e voditi evidenciju o prolaznosti kandidata, pojedinano za svakog

instruktora i s tim u vezi arhivira i uva dvije godine:

a) ugovor o osposobljavanju,b) potvrdu o zavrenom programu osposobljavanja i provjeri osposobljenosti,c) probni test,d) dnevnik rada voza-instruktora.

Dakle, Zakon je nametnuo i regulisao ta su obaveze organa za provoenje ispita i

Autokola, a nama ostaje da kroz ovaj struni rad pokaemo da voenje evidencije, ma

koliko ona izgledala kompleksna, nije teko ako se iznae adekvatno softversko rjeenje za

lagano, jednostavno i sveobuhvatno evidentiranje.


14/42

13

3. CILJ

3.1. Ciljevi koji se nastoje postii koritenjem baza podatakaSpomenuli smo da baze podataka predstavljaju vii nivo rada s podacima u odnosu

na klasine programske jezike. Taj vii nivo rada oituje se u tome to tehnologija baza

podataka nastoji (i u velikoj mjeri uspijeva) ispuniti sljedee ciljeve.

3.1.1. Fizika nezavisnost podataka.Razdvaja se logika definicija baze od njene stvarne fizike grae. Znai, ako se

fizika graa promijeni (na primjer, podaci se prepiu u druge datoteke na drugim

diskovima), to nee zahtijevati promjene u postojeim aplikacijama.

3.1.2. Logika nezavisnost podataka.Razdvaja se globalna logika definicija cijele baze podataka od lokalne logike

definicije za jednu aplikaciju. Znai, ako se logika definicija promijeni (na primjer uvede

se novi zapis ili veza), to nee zahtijevati promjene u postojeim aplikacijama. Lokalna

logika definicija obino se svodi na izdvajanje samo nekih elemenata iz globalne

definicije, uz neke jednostavne transformacije tih elemenata.

3.1.3. Fleksibilnost pristupa podacima.U starijim mrenim i hijerarhijskim bazama, staze pristupanja podacima bile su

unaprijed definirane, dakle korisnik je mogao pretraivati podatke jedino onim

redoslijedom koji je bio predvien u vrijeme projektiranja i implementiranja baze. Danasse zahtijeva da korisnik moe slobodno prebirati po podacima, te po svom nahoenju

uspostavljati veze meu podacima. Ovom zahtjevu zaista zadovoljavaju jedino relacijske

baze.

3.1.4. Istovremeni pristup do podataka.Baza mora omoguiti da vei broj korisnika istovremeno koristi iste podatke.

Pritom ti korisnici ne smiju ometati jedan drugoga, te svaki od njih treba imati dojam da

sam radi s bazom.

3.1.5. uvanje integriteta.Nastoji se automatski sauvati korektnost i konzistencija podataka, i to u situaciji

kad postoje greke u aplikacijama, te konfliktne istrovremene aktivnosti korisnika.

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

sistemskog softvera.


15/42

14

3.1.7. Zatita od neovlatenog koritenja.Mora postojati mogunost da se korisnicima ogranie prava koritenja baze, dakle

da se svakom korisniku reguliraju ovlatenja to on smije a to ne smije raditi s podacima.

3.1.8. Zadovoljavajua brzina pristupa.Operacije s podacima moraju se odvijati dovoljno brzo, u skladu s potrebama

odredene aplikacije. Na brzinu pristupa moe se uticati odabirom pogodnih fizikih

struktura podataka, te izborom pogodnih algoritama za pretraivanje.

3.1.9. Mogunost podeavanja i kontrole.Velika baza zahtijeva stalnu brigu: praenje performansi, mijenjanje parametara u

fizikoj grai, rutinsko pohranjivanje rezervnih kopija podataka, reguliranje ovlatenja

korisnika. Takoer, svrha baze se vremenom mijenja, pa povremeno treba podesiti i

logiku strukturu. Ovakvi poslovi moraju se obavljati centralizirano. Odgovorna osoba

zove se administratorbaze podataka. Administratoru trebaju stajati na raspolaganju razni

alati i pomagala.

3.2. C

iljevi kojise po

stavljaju izradom baze podataka autokole

Osim to ima obavezu da vodi evidenciju propisanu Zakonom ( redni broj

kandidata, prezime, ime oca, ime, JMBG, datum roenja, broj ljekarskog uvjerenja i naziv

ustanove koja ga je izdala, potvrda o zavrenoj teoretskoj nastavi datum i broj, potvrda o

uspjeno zavrenoj nastavi iz pruanja prve pomoi povrijeenim u saobraajnoj nezgodi

datum i broj, potvrda o zavrenom osposobljavanju iz upravljanja motornim vozilom

datum i broj, broj knjiice kandidata, evidenciju o prolaznosti kandidata, pojedinano za

svakog instruktora), autokola za svoje potrebe moe u bazu podataka unijeti ne manje

bitne podatke koji omoguuju pravilno praenje procesa obuavanja kandidata, njihov

identitet, fotografija, novane izdatke, uplate i td.


16/42

15

4. OBRAZLOENJE TEME4.1. ivotni ciklus baze podataka

Uvoenje baze podataka u neku autokolu ili ustanovu predstavlja sloeni zadatak

koji zahtijeva timski rad strunjaka raznih profila. To je projekt koji se moe podijeliti u

pet faza: analiza potreba, modeliranje podataka, implementacija, testiranje i odravanje.

4.2. Analiza potrebaProuavaju se tokovi informacija u autokoli. Uoavaju se podaci koje treba

pohranjivati i veze meu njima. U velikom autokolama, gdje postoje razne grupe

korisnika, pojavit e se razni pogledi na podatke. Te poglede treba uskladiti tako da se

eliminira redundancija i nekonzistentnost. Na primjer, treba u raznim pogledima prepoznati

sinonime i homonime, te uskladiti terminologiju. Analiza potreba takoer treba obuhvatiti

analizu transakcija(operacija) koje e se obavljati nad bazom podataka, budui da to moe

isto imati utjecaja na sadraj i konani oblik baze. Vano je procijeniti frekvenciju i opseg

pojedinih transakcija, te zahtjeve na performanse. Rezultat analize je dokument (pisan

neformalno u prirodnom jeziku) koji se zove specifikacija potreba. U specifikaciju potreba

e ui sve ono to jednoj autokoli treba kao finalni dokumenat i podatak u postupku

kontrole ili jednostavnog traenja informacija.

4.3. Modeliranje podatakaRazliiti pogledi na podatke, otkriveni u fazi analize, sintetiziraju se u jednu cjelinu

globalnu shemu. Precizno se utvrduju tipovi podataka. Shema se dalje dotjeruje

(normalizira) tako da zadovolji neke zahtjeve kvalitete. Takoer, shema se prilagoava

ogranienjima koje postavlja zadani model podataka, te se dodatno modificira da bi bolje

mogla udovoljiti zahtjevima na performanse. Na kraju se iz sheme izvode pogledi (pod-

sheme) za pojedine aplikacije (grupe korisnika).


17/42

16

4.4. ImplementacijaNa osnovu sheme i pod-shema, te uz pomo dostupnog DBMS-a, fiziki se realizira

baza podataka na raunalu. U DBMS-u obino postoje parametri kojima se moe utjecati

na fiziku organizaciju baze. Parametri se podeavaju tako da se osigura efikasan radnajvanijih transakcija. Razvija se skup programa koji realiziraju pojedine transakcije te

pokrivaju potrebe raznih aplikacija. Baza se inicijalno puni podacima. U ovom sluaju

koristimo Microsoftov program Access iz jednostavnog razloga to je najprisutniji na

personalnim raunarima koje koriste autokole kao obaveznu opremu u kancelarijama.

4.5. TestiranjeKorisnici (u ovom sluaju autokola Turbo iz ivinica) pokusno rade s bazom i

provjeravaju da li ona zadovoljava svim zahtjevima. Nastoje se otkriti greke koje su se

mogle potkrasti u svakoj od faza razvoja: dakle u analizi potreba, modeliranju podataka,

implementaciji. Greke u ranijim fazama imaju tee posljedice. Na primjer, greka u

analizi potreba uzrokuje da transakcije moda korektno rade, no ne ono to korisnicima

treba ve neto drugo. Dobro bi bilo kad bi takve propuste otkrili prije implementacije.

Zato se u novije vrijeme, prije prave implementacije, razvijaju i priblini prototipovibaze

podataka, te se oni pokazuju korisnicima. Jeftinu izradu prototipova omoguuju jezici 4.

generacije i objektno-orijentirani jezici.

4.6. OdravanjeOdvija se u vrijeme kad je baza ve ula u redovnu upotrebu. Sastoji se od

sljedeeg: popravak greaka koje nisu bile otkrivene u fazi testiranja; uvoenje promjena

zbog novih zahtjeva korisnika; podeavanje parametara u DBMS u svrhu poboljavanja

performansi. Odravanje zahtijeva da se stalno prati rad s bazom, i to tako da to praenje

ne ometa korisnike. Administratoru baze podataka trebaju stajati na raspolaganjuodgovarajui alati (utility programi).Najee greke javljaju se u nepreciznosti prilikom

pravljenja izvjetaja (potvrde o zavrenoj obuci).


18/42

17

5. PREGLED PUBLIKACIJAMartin (1977) navodi da je baza podataka je skup meusobno ovisnh podataka,

pohranjenih bez redundancije (preklapanja), koji slue jednoj ili vie aplikacija na

optimalan nain, gdje su podaci neovisni o programimakoji se obrauju i gdje postojikontroliran pristup podacima.

Date (1990) baza podataka je skup operativnih i integriranih podataka obraivanih

u jednoj organizaciji

Bajkovi-Lazarevi i Zoranovi (2004) u svojim tezama Kome je potrebno

znanje? kau Budui profesionalci u oblasti informacionih tehnologija za projektovanje i

kreiranje baze podataka za administraciju baza DBA, za odravanje i razvoj baza, za

kreiranje aplikacija koje koriste baze, eksperti i ostali zaposleni u pruanju informacija

profesionalcima prilikom razvoja informacionih sistema, moraju imati na umu da buduikorisnici baza podatakasu od domaice do bankovnih slubenika, ve danas je realnostrezervacija avio karata preko Interneta, narudbine knjiga, plaanje rauna... Iza svake od

tih usluga stoji baza podataka. Ova kategorija obuhvata gotovo sve zaposlene.

Jai (2010) kae sljedee: Veliku pomo u kontinuiranoj edukaciji medicinskog

osoblja, zdravstvenih profesionalaca i onih koji se obuavaju za bavljenje ovom

profesijom, nesumnjivo prua informatika kao novija nauna disciplina, koja se danas

impozantno razvila. Primjena informatike u medicini prua ogromne mogunosti.

Unoenje raznih podataka u raunar, kao to su podaci o pacijentima, izvoenje i rezultati

pojedinih pretraga, biljeenje i automatska statistika obrada rezultata za veoma kratko

vrijeme su zaista velika pomo u svakodnevnom radu.

Vlada TK (2009) u svom izvjetaju izmeu ostalog navodi: Kada je u pitanju

Odsjek za saobraajnu edukaciju u proloj godini je na 8 ispitnih mjesta kontinuirano

organizovano polaganje ispita za sticanje vozakih dozvola. Ukupno je oko 15.000

kandidata polagalo vozaki ispit, 4.327 kandidata poloilo ispit iz poznavanja propisa, a

5.286 kandidata je poloilo ispit iz upravljanja motornim vozilom. U ovom segmentu rada

Ministarstva provoene su i redovne aktivnosti na organizovanju ispita za sticanje licenci,

zvanja vozaa instruktora motornih vozila, zatim zamjena dozvola vozaa instruktora te

rjeavanje zahtjeva za utvrivanje uslova rada u autokolama. Ovaj izvjetaj jasno

ukazuje koliko je auriranja podataka potrebno uraditi u toku jedne godine, ukoliko bi

napravili jednu robusniju bazu podataka koja bi uvezivala podatke iz svih autokola na

jednom kantonu i objedinila ih.


19/42

18

Bajgori (2007) kae da je jedan od tipinih problema u savremenom poslovanju

nezadovoljstvo krajnjih korisnika sa programima i izvjetjima. Da bi se to izbjeglo

preporuuje poboljanje efikasnosti i efektivnosti razliitih aktivnosti u poslovanju, od

obrade teksta, raunskih operacija, internog i komuniciranja sa subjektima iz okruenja, pa

sve do stratekog planiranja i donoenja odluka. Govorei o aplikacijama koje imaju za ciljpoboljanje procesa odluivanja u poslovnom sistemu on naglaava ulogu tehnika i

metoda koje omoguavaju otkrivanje skrivenih veza meu varijablama u velikim bazama

podataka. To su metoda za automatsko otkrivanje trendova, nizova, i veza izmeu

akumuliranih podataka, njihova je uloga pronalaenje veza meu podacima koje nisu

oigledne.

Latifagi i Osmanbegovi (2005) govore o mogunostima upravljanja relacionim

bazama uz pomo Microsoft Access-a. Naglaavaju vanost usvajanja praktinih znanja.

Upoznavanje sa tehnikama upravljanja relacionim bazama podataka vre navodei

primjere baza podataka napravljenih uz pomo Microsoft Access-a.

Agarval i Hadlston(2009) govore da je za programiranje baza podataka potrebno

relativno malo znanja o Visual Basicu, ali mnogo znanja o konceptima relacionih baza

podataka i upitnom jeziku SQL. Polaze od pretpostavke da nemate nikakvog iskustva sa

relacionim bazama podataka i objanjavaju, kroz praktine primjere, kako se pomou

SQL-a prave i koriste relacione baze podataka i kako se sa takvim bazama podataka radi u

Visual Basicu.

Joanov i Vesin (2004) naglaavaju vanost izrade projektnog zadatka. U njegovom

kreiranju uestvuje korisnik softvera i to tako to navodi ciljeve koje softverski proizvod

treba da postigne. Na osnovu postavljenih ciljeva definiu se informacioni zahtjevi, model

podataka i dijagram konteksta. Tek tada se pristupa izradi projekta baze podataka, koristei

neki od ponuenih programskih paketa za dizajniranje baza podataka.

Bonacin (2008) kae kako projektiranju raunalno poduprtih informacijskih sustava

treba prii kao krajnje ozbiljnoj zadai koja e imati viestruke reperkusije na razne

dimenzije ljudske egzistencije, i kao mogunost ostvarenja profita, i kao mogunost

donoenja odluka, i kao mogunost efikasnog, od veeg broja pogreaka osloboenog

operativnog djelovanja, ali i kao mogunost distribucije informacija, i kao sredstvo

neviene dimenzionalnosti edukacije, i kao sredstvo interne i eksterne komunikacije, bilo

to poslovne bilo to ma kakve druge, ba kao i sredstvo za osiguranje vie slobodnog

vremena ili lakeg ostvarenja poslovnih i drugih zadaa bilo koje razine.


20/42

19

6. DISKUSIJA6.1. Modeliranje entiteta i veza

Bavimo se pitanjem: kako oblikovati shemu za bazu podataka, usklaenu s

pravilima relacijskog modela. U stvarnim situacijama dosta je teko direktno pogoditi

relacijsku shemu. Zato se sluimo jednom pomonom fazom koja se zove modeliranje

entiteta i veza (Entity-Relationship Modelling). Rije je o oblikovanju jedne manje

precizne, konceptualne sheme, koja predstavlja apstrakciju realnog svijeta. Ta tzv. ER-

shema se dalje, vie-manje automatski, pretvara u relacijsku. Modeliranje entiteta i veza

zahtijeva da se svijet promatra preko tri kategorije:

entiteti: objekti ili dogadaji koji su nam od interesa;

veze: odnosi medu entitetima koji su nam od interesa;

atributi: svojstva entiteta i veza koja su nam od interesa.

6.1.1. Entiteti i atributiEntitet je neto o emu elimo spremati podatke, neto to je u stanju postojati ili

ne postojati, te se moe identificirati. Entitet moe biti objekt ili bie (na primjer kandidat,

student, auto), odnosno dogadaj ili pojava (na primjer nogometna utakmica, praznik,

servisiranje auta). Entitet je opisan atributima (na primjer atributi kandidata su: adresa,

datum roenja, dimenzije, . . . ).

Ukoliko neki atribut i sam zahtijeva svoje atribute, tada ga radije treba smatrati

novim entitetom (na primjer model auta). Isto pravilo vrijedi i ako atribut moe

istovremeno imati vie vrijedenosti (na primjer kvar koji je popravljen pri servisiranju

auta). Ime entiteta, zajedno sa pripadnim atributima, zapravo odreuje tipentiteta. Moe

postojati mnogo primjeraka (pojava) entiteta zadanog tipa (na primjerKANDIDATje tip

iji primjerci su Mujkanovi Mujo, Markovi Marko, . . . ).

Kandidat za kljuje atribut, ili skup atributa, ije vrijednosti jednoznano odreuju

primjerak entiteta zadanog tipa. Dakle, ne mogu postojati dva razliita primjerka entiteta

istog tipa s istim vrijednostima kandidata za klju. (Na primjer za tip entiteta AUTO,

kandidat za klju je atribut REG BROJ). Ukoliko jedan tip entiteta ima vie kandidata za

klju, tada biramo jednog od njih i proglaavamo ga primarnim kljuem. (Na primjer

primarni klju za tip entitetaKANDIDATmogao bi biti atributBROJ UPISA.


21/42

20

6.1.2. VezeVeze se uspostavljaju izmeu dva ili vie tipova entiteta (na primjer vezaRADI ZA

izmeu tipova entiteta INSTRUKTOR i KOLA ). Zapravo je rije o imenovanoj binarnoj

ili k-narnoj relaciji izmeu primjeraka entiteta zadanih tipova. Za sada emo se ograniitina veze izmeu tono dva tipa entiteta. Funkcionalnost veze moe biti:

Jedan-naprama-jedan (1 : 1). Jedan primjerak prvog tipa entiteta moe biti u vezi

s najvie jednim primjerkom drugog tipa entiteta, te takoer jedan primjerak drugog tipa

moe biti u vezi s najvie jednim primjerkom prvog tipa. Na primjer veza JE VLASNIK

izmeu tipova entitetaINSTRUKTOR iAUTOKOLA.

Jedan-naprama-mnogo (1 : N). Jedan primjerak prvog tipa entiteta moe biti u

vezi s 0, 1 ili vie primjeraka drugog tipa entiteta, no jedan primjerak drugog tipa moe biti

u vezi s najvie jednim primjerkog prvog tipa. Na primjer veza OBUAVA izmeu tipovaentitetaINSTRUKTOR iKANDIDAT.

Mnogo-naprama-mnogo (M :N). Jedan primjerak prvog tipa entiteta moe biti u

vezi s 0, 1 ili vie primjeraka drugog tipa entiteta, te takoer jedan primjerak drugog tipa

moe biti u vezi s 0, 1 ili vie primjeraka prvog tipa. Na primjer veza UPISAO izmeu

tipova entiteta KANDIDAT i AUTOKOLA. Veza moe imati i svoje atribute koje ne

moemo pripisati ni jednom od tipova entiteta (na primjer veza UPISAO moe imati atribut

DATUMUPISA). Ako svaki primjerak entiteta nekog tipa mora sudjelovati u zadanoj vezi,

tada kaemo da tip entiteta ima obavezno lanstvo u toj vezi. Inae tip entiteta imaneobavezno lanstvo. (Na primjer izmedu tipova entitetaISPITiPROPISIzadana je veza

IZ, koja ima funkcionalnost (N: 1).ISPITima obavezno lanstvo u veziIZ, jer svaki ispit

mora biti iz nekog dijela,propisi,upravljanje i prva pomo.) Odluka da li je lanstvo

obavezno ili neobavezno koji put je stvar dogovora odnosno projektantove odluke (na

primjer lanstvo zaISPITu veziPREDAJE).

6.1.3. Sloenije vezeU stvarnim situacijama pojavljuju se i sloenije veze od onih koje smo do sada

promatrali. Navest emo neke od njih.

Involuirana veza povezuje jedan tip entiteta s tim istim tipom. Dakle rije je o

binarnoj relaciji izmeu raznih primjeraka entiteta istog tipa.

Ternarne veze uspostavljaju se izmeu tri tipa entiteta. Znai rije je o ternarnoj

relaciji izmedu primjeraka triju tipova entiteta.


22/42

21

6.2. Relacijski modelRelacijski modelbio je teoretski zasnovan jo krajem 60-tih godina 20. stoljea, u

radovima E.F. Codd-a. Model se dugo pojavljivao samo u akademskim raspravama iknjigama. Prve realizacije na raunalu bile su suvie spore i neefikasne. Zahvaljujui

intenzivnom istraivanju, te napretku samih raunala, efikasnost relacijskih baza postepeno

se poboljavala. Sredinom 80-tih godina 20. Stoljea relacijski model je postao

prevladavajui. I danas veina DBMS koristi taj model.

6.2.1. Relacija, atribut, n-torka, kljuRelacijski model zahtijeva da se baza podataka sastoji od skupa pravokutnih tabela

- tzv. relacija. Svaka relacija ima svoje ime po kojem je razlikujemo od ostalih u istoj bazi.

Jedan stupac relacije obino sadri vrijednost jednog atributa (za entitet ili vezu) - zato

stupac poistovjeujemo s atributom i obratno. Atribut ima svoje ime po kojem ga

razlikujemo od ostalih u istoj relaciji. Vrijednosti jednog atributa su podaci istog tipa.

Dakle, definiran je skup dozvoljenih vrijednosti za atribut, koji se zove domenaatributa.

Vrijednost atributa mora biti jednostruka i jednostavna (ne da se rastaviti na dijelove). Pod

nekim uvjetima toleriramo situaciju da vrijednost atributa nedostaje (nije upisana). Jedan

redak relacije obino predstavlja jedan primjerak entiteta, ili biljei vezu izmeu dva ili

vie primjeraka. Redak nazivamo n-torka. U jednoj relaciji ne smiju postojati dvije jednake

n-torke. Broj atributa je stupanj relacije, a broj n-torki je kardinalnost relacije.

6.2.2. Pretvaranje ER-sheme u relacijskuU nastavku objanjavamo kako se pojedini elementi ER-sheme pretvaraju u

relacije. Na taj nain pokazat emo kako se iz cijele ER-sheme dobiva relacijska shema.

Pretvorba tipova entiteta. Svaki tip entiteta prikazuje se jednom relacijom. Atributi tipa

postaju atributi relacije. Jedan primjerak entiteta prikazan je jednom n-torkom. Primarniklju entiteta postaje primarni klju relacije.


23/42

22

6.2.3. Usporedba relacijskog modela s mrenim i hijerarhijskimMreni i hijerarhijski model su prilino slini. Ustvari, hijerarhijski model moemo

smatrati specijalnom vrstom mrenog. S druge strane, relacijski model se po svom pristupu

bitno razlikuje od ostala dva. Osnovna razlika je u nainu prikazivanja veza meduentitetima, te nainu koritenja tih veza.

U mrenom ili hijerarhijskom modelu mogue je izravno prikazati vezu. Dodue,

postoje ograni enja na funkcionalnost veze, te na konfiguraciju svih veza u shemi. Veza se

materijalizira pomou pointera, tj. u jednom zapisu pie adresa drugog (vezanog) zapisa.

Mreni odnosno hijerarhijski DML omoguuje samo jednostavne operacije s jednim

zapisom (upis, promjena, brisanje, itanje), te manevrisanje kroz shemu putem veza

(dohvat prvog zapisa, koji je u zadanoj vezi sa zadanim zapisom, dohvat idueg zapisa,... ).

Ovakav pristup ima svoje prednosti i mane. Prednost je da je rad s bazom u tehnikompogledu brz i efikasan. Mana je da korisnik moe upotrijebiti samo one veze koje su

predviene shemom pa su u skladu s time i materijalizirane.

U relacijskom modelu veze su samo implicitno naznaene time to se isti ili slian

atribut pojavljuje u vie relacija. Veza nije materijalizirana, ve se dinamiki uspostavlja za

vrijeme rada s podacima, usporedbom vrijednosti atributa u n-torkama raznih relacija.

Relacijski DML, osim jednostavnih operacija s jednom relacijom, mora omoguiti

slobodno kombiniranje podataka iz raznih relacija. I ovaj pristup ima svoje prednosti i

mane. Mana je da se veza svaki put mora iznova uspostavljati; potrebno je pretraivanjepodataka, a to troi vrijeme. Prednost je da korisnik moe uspostaviti i one veze koje nisu

bile predviene u fazi modeliranja podataka. tovie, kao kriterij za povezivanje, osim

jednakosti za vrijednost atributa, mogu posluiti i razni drugi (sloeniji) kriteriji. To jo

vie poveava fleksibilnost koritenja baze. Iz upravo reenog vidi se da je u relacijskom

modelu teite baeno na dinamiki aspekt (manje pohranjivanja a vie manipuliranja).

Zato upotrebljivost relacijskog DBMS bitno ovisi o izraajnim mogunostima njegovog

jezika za rad s podacima. Poeljno je takoer da taj jezik bude u to veoj mjeri

neproceduralan i razumljiv neposrednim korisnicima. U Poglavlju 3 upoznat emo neke

relacijske jezike. Njih treba smatrati sastavnim dijelom relacijskog modela.


24/42

23

6.3. Normalizacija relacijske shemeRelacijska shema, dobivena iz ER-sheme na osnovu prethodnih uputa, moe

sadravati nedoreenosti koje treba otkloniti prije implementacije. Proces daljnjeg

dotjerivanja sheme zove se normalizacija. Teorija normalizacije zasnovana je na pojmunormalnih formi. Relacije dobivene u skladu s potpoglavljem 2.2 morale bi u najmanju

ruku biti u prvoj normalnoj formi(1NF). Naime, relacija je u 1NF ako je vrijednost svakog

atributa jednostruka i nedjeljiva - to svojstvo ve je bilo ukljueno u nau definiciju

relacije. U svojim radovima (1970-1974. godina) E.F. Codd je najprije definirao drugu i

treu normalnu formu (2NF, 3NF), a zatim i poboljanu varijantu 3NF koja se zove Boyce-

Coddova normalna forma (BCNF). R. Fagin je 1977. i 1979. uveo etvrtu i petu normalnu

formu (4NF, 5NF). U praksi je lako naii na relacije koje odstupaju od 2NF, 3NF, BCNF,

no vrlo rijetko se susreu relacije u BCNF koje nisu u 4NF i 5NF. Zato su vie normalneforme prvenstveno od teorijskog znaaja. Teorija normalizacije nije nita drugo nego

formalizacija nekih intuitivno prihvatljivih principa o zdravom oblikovanju sheme.

Ukoliko ve na poetku dobro uoimo sve potrebne entitete, atribute i veze, tada nam

nikakva daljnja normalizacija nee biti potrebna. No ako je polazna relacijska shema bila

loe oblikovana, tada e postupak normalizacije ispraviti te greke.

6.3.1. Funkcionalna ovisnostZa zadanu relaciju R, atribut B od R je funkcionalno ovisan o atributu A od R

(oznaka: AB) ako vrijednost od A jednoznano odreuje vrijednost odB. Dakle ako u

isto vrijeme postoje uR dvije n-torke s jednakom vrijednou A, tada te n-torke moraju

imati jednaku vrijednost B. Analogna definicija primjenjuje se i za sluaj kad su A i B

sloeni atributi (dakle skupovi atributa).

6.3.2. Druga normalna formaRelacija je u drugoj normalnoj formi(2NF) ako je u 1NF i ako je svaki ne-primarni

atribut potpuno funkcionalno ovisan o primarnom kljuu. Malo prije definirana relacija

IZVJETAJnije u 2NF, i to dovodi do anomalija.

6.3.3. Trea normalna formaRelacija je u treoj normalnoj formi(3NF) ako je u 2NF i ako ne sadri tranzitivne

ovisnosti. Preciznije, relacija R je u 3NF ako za svaku funkcionalnu ovisnostX ! A u R,

takvu daA nije uX, vrijedi:Xsadri klju zaR ili jeAprimarni atribut.


25/42

24

6.3.4. Boyce-Codd-ova normalna formaDeterminantaje atribut (ili kombinacija atributa) o kojem je neki drugi atribut

potpuno funkcionalno ovisan. Relacija je u Boyce-Codd-ovoj normalnoj formi (BCNF)

ako je svaka njezina determinanta ujedno i kandidat za klju. Oito je relacija koja je u

BCNF takoer i u 2NF i 3NF. No postoje relacije koje su u 3NF, no nisu u BCNF. Primjerza to moemo konstruirati tako da gledamo relaciju u kojoj postoje dva kandidata za klju,

oba kljua su sloena, i preklapaju se u bar jednom atributu.

6.3.5. Vieznana ovisnost i etvrta normalna formaetvrtu normalnu formu najlake je opisati pomou primjera. Promatrajmo relaciju

koja prikazuje vezu izmeu instruktora, kategorije i kandidata: OBUKA ( INSTRUKTOR,

KATEGORIJA, KANDIDAT ). Jedna n-torka oznaava da zadani instruktor zadanu

kategoriju obuava sa zadanim kandidatom. Relacija moe u jednom trenutku izgledati kao

na tabelarnom prikazu 3. lagano je provjeriti da je relacija u BCNF.

Tabela 3. Relacija koja nije u etvrtoj normalnoj formi. (Demo Braninovi,2010.)

OBUKA

INSTRUKTOR KATEGORIJA KANDIDAT

Samir Tuholjakovi C1E Ramo Rami

Bilal Tulumovi teoretska nastave B Salko Salki

Bilal Tulumovi teoretska nastave B Jozo Jozi

Bilal Tulumovi teoretska nastave B Ivo Ivi

Bilal Tulumovi teoretska nastave B Ramo Rami

Bilal Tulumovi teoretska nastave C Ramo Rami

Nurfet Balki B Jozo Jozi

Fehim Mei B Ivo Ivi

Adnan Mukinovi B Ramo Rami

Nedad Hajdarbegovi C1 Salko Salki

Nedad Hajdarbegovi C1 Ramo Rami

U nastavku uzimamo da vrijedi pravilo: im instruktor obuava u nekog kandidata,

on odmah obuava sve svoje kategorije tog kandidata. Tada relacija oito sadri veliku

dozu redundancije. Na primjer, da bi dodali novu kategoriju, moramo upisati n-torku za

svakog kandidata kojeg taj instruktor obuava. Slino, ako novi instruktor pone obuavati

tog kandidata, morat e se ubaciti posebna n-torka za svaku njegovu kategoriju.


26/42

25

Redundancija e se eliminirati ako zamijenimo polaznu relaciju OBUKA s dvije

manje relacije RADI i PRODAJE: OBUAVA ( INSTRUKTOR, KATEGORIJA ) ,

OBUIO (INSTRUKTOR, KANDIDAT) .Podacima iz prethodnog Tabelarnog prikaza 3.

tada odgovaraju podaci iz Tabelarnog prikaza 4.

Tabela 4. Svodenje na etvrtu normalnu formu. (Demo Braninovi,2010.)OBUAVA OBUIO

INSTRUKTOR KATEGORIJA INSTRUKTOR KANDIDAT

Samir Tuholjakovi C1E Samir Tuholjakovi Ramo Rami

Bilal Tulumovi teoretska nastava B Bilal Tulumovi Jozo Jozi

Bilal Tulumovi teoretska nastava C Nurfet Balki Salko Salki

Nurfet Balki B Bilal Tulumovi Ivo Ivi

Fehim Mei B Nurfet Balki Ramo RamiAdnan Mukinovi B Fehim Mei Ramo Rami

Nurfet Balki C1 Adnan Mukinovi Salko Salki

Nedad Hajdarbegovi B Nedad Hajdarbegovi Jozo Jozi

Dosadanja pravila normalizacije nam ne pomau da eliminiramo redundanciju u

relaciji OBUKA . To je zato to redundancija nije bila uzrokovana funkcionalnim

ovisnostima, ve tzv. vieznanim ovisnostima. U naoj relaciji OBUKA , ni jedna od

uoenih vieznanih ovisnosti nije funkcionalna ovisnost. Znai, OBUKA nije u 4NF i zato

je treba rastaviti na OBUAVA i OBUIO (koje jesu u 4NF). Odstupanje od 4NF opet

moemo tumaiti kao greku u modeliranju entiteta i veza. Promatrana relacija OBUKA

nastala je zbog pokuaja da se odnos triju tipova entiteta INSTRUKTOR, KATEGORIJA,

KANDIDAT tretira kao ternarna veza. Zapravo se ovdje radi o dvije nezavisne binarne

veze. Postoje, naravno, i prave ternarne veze. Na primjer ako skup proizvoda koje zadani

instruktor obuava varira od kandidata do kandidata, tada prije uoene vieznane

ovisnosti ne vrijede, relacija OBUKA je u 4NF i ne moemo je rastaviti na dvije manjerelacije.


27/42

26

6.4. Razlozi zbog kojih se moe odustati od normalizacijeZa veinu praktinih primjera dovoljno je relacije normalizirati do 3NF. Koji put je

potrebno neku relaciju i dalje normalizirati do BCNF ili 4NF. Peta normalna forma, koja se

takoer navodi u literaturi, nije od praktinog znaaja. Postoje razlozi zbog kojih iznimnomoemo odustati od pune normalizacije. Navesti emo dva takva razloga.

Sloeni atribut. Deava se da nekoliko atributa u relaciji ine cjelinu koja se u

aplikacijama nikad ne rastavlja na sastavne dijelove. Na primjer, promatrajmo relaciju

KANDIDAT( PREZIME IME, IME OCA, JMBG, POTANSKI BROJ, GRAD, ULICA ) .

Strogo govorei, GRAD je funkcionalno ovisan o POTANSKI BROJ, pa relacija nije u

3NF. No mi znamo da POTANSKI BROJ, GRAD i ULICA ine cjelinu koja se zove

adresa. Budui da se podaci iz adrese koriste i auriraju u paketu, ne moe doi do prije

spominjanih anomalija. Nije preporuljivo razbijati ovu relaciju na dvije.Efikasno itanje podataka. Normalizacijom se velike relacije razbijaju na mnogo

manjih. Kod itanja je esto potrebno podatke iz malih relacija ponovo sastaviti u vee n-

torke. Uspostavljanje veza medu podacima u manjim relacijama traje znatno dulje nego

itanje podataka koji su ve povezani i upisani u jednu veliku relaciju. Projektant baze

podataka treba procijeniti kada treba provesti normalizaciju do kraja a kada ne. Za tu

procjenu je vano razumijevanje znaenja podataka i naina kako e se oni koristiti.

6.5. Jezici za relacijske baze podataka6.5.1. Relacijska algebra

Relacijsku algebru uveo je E.F. Codd u svojim radovima iz 70-tih godina 20.

stoljea. Rije je o teorijskoj (matematikoj) notaciji, a ne o praktinom jeziku kojeg bi

ljudi zaista neposredno koristili. Zato niti ne postoji standardna sintaksa. Relacijska algebra

se svodi na izvrednjavanje algebarskih izraza, gradenih od relacija te unarnih i binarnih

operatora (iji operandi su relacija a rezultat je opet relacija). Svaki algebarski izraz

predstavlja jedan upit (pretraivanje).


28/42

27

6.5.2. Prirodni spojPrirodni spoj (natural join) je binarni operator primjenjiv na dvije relacijeR i Skoje

imaju bar jedan zajedniki atribut. R joinSsastoji se od svih n-torki dobivenih spajanjem

jedne n-torke izR s jednom n-torkom iz Skoja ima iste vrijednosti zajednikih atributa. Urezultirajuoj relaciji zajedniki atribut se pojavljuje samo jednom. Prirodni spoj

omoguuje nam da u naoj fakultetskoj bazi podataka odgovorimo na sloenije upite koji

zahtijevaju uspostavljanje veza izmeu podataka u raznim tablicama.

6.5.3. Optimizacija upitaJezici za relacijske baze podataka daju korisniku veliku slobodu u postavljanju

upita. Teret efikasnog odgovaranja na te raznolike upite prebaen je na DBMS. Naime,

odgovor na jedan te isti upit obino se moe dobiti na razne naine, a zadatak DBMS-a je

da odabere najefikasniji nain. Odabir dobrog postupka za odgovaranje zove se

optimizacija upita. Moderni DBMS provodi optimizaciju na dvije razine:

via (logika) razina : preformuliranje algebarskog izraza u oblik koji je

ekvivalentan polaznom, ali je pogodniji sa stanovita izvrednjavanja;

nia (fizika) razina : odabir dobrog algoritma za izvrednjavanje svake od

osnovnih operacija u algebarskom izrazu. Pritom se nastoji iskoristiti eventualno prisustvo

pomonih struktura podataka (indeksi i slino).

6.6. Fizika graa baze podataka6.6.1. Elementi fizike grade

Baza podataka se u fizikom smislu svodi na gomilu bitova pohranjenih na

magnetskim diskovima. Takav doslovni nain gledanja je bez sumnje istinit, no on ne

omoguuje da stvarno razumijemo fiziku grau baze. Umjesto toga, bolje je promatrati

malo apstraktnije objekte, kao to su zapisi, datoteke i pointeri. Rije je o prvom, sasvim

niskom nivou apstrakcije koji je vrlo blizak fizikoj stvarnosti.


29/42

28

6.6.2. Vanjska memorija raunalaOperacijski sistem raunala dijeli vanjsku memoriju u jednako velike blokove.

Veliina bloka je konstanta operacijskog sistema, i ona moe iznositi na primjer 512 byte

ili 4096 byte. Svaki blok jednoznano je zadan svojom adresom. Osnovna operacija svanjskom memorijom je prijenos bloka sa zadanom adresom iz vanjske memorije u

glavnu, ili obratno. Dio glavne memorije koji sudjeluje u prijenosu (i ima jednaku veliinu

kao i sam blok) zove se buffer. Blok je najmanja koliina podataka koja se moe prenijeti;

na primjer ako elimo proitati samo jedan byte iz vanjske memorije, tada moramo

prenijeti cijeli odgovarajui blok, pretraiti buffer u glavnoj memoriji i izdvojiti traeni

byte. Vrijeme potrebno za prijenos bloka nije konstantno ve ovisi o trenutnom poloaju

glave diska. Ipak, to vrijeme (mjereno u milisekundama) neusporedivo je vee od vremena

potrebnog za bilo koju manipulaciju u glavnoj memoriji (mjereno u mikro- inanosekundama). Zato je brzina nekog algoritma za rad s vanjskom memorijom odredena

brojem blokova koje algoritam mora prenijeti, a vrijeme potrebno za raunanje i

manipuliranje u glavnoj memoriji je zanemarivo.

6.6.3. DatotekeOsnovni problem fizikog prikazivanja baze podataka je organizacija datoteke.

Datoteka je konani niz zapisa istog tipa pohranjenih u vanjskoj memoriji. Tip zapisa

zadaje se kao uredena n-torka osnovnih podataka (komponenti), gdje je svaki osnovnipodatak opisan svojim imenom i tipom (int, float, character string, . . . ). Primijetimo da je

tip zapisa definiran neto ue nego na primjer u C-u, naime nije dozvoljena hijerarhijska ni

varijabilna grada zapisa. Sam zapis sastoji se od konkretnih vrijednosti osnovnih podataka.

Smatramo da su zapisi fiksne duljine, dakle jedan zapis ima tono jednu vrijednost svakog

od osnovnih podataka i ta vrijednost je prikazana fiksiranim brojem byte-ova.

Tipine operacije koje se obavljaju nad datotekom su: ubaciti novi zapis,

promijeniti zapis, izbaciti zapis, nai zapis ili zapise gdje zadani podaci imaju zadane

vrijednosti. Sloenost grae datoteke ovisi o tome koliko efikasno elimo obavljatipojedine od ovih operacija. (Kandidat za) kljuje osnovni podatak, ili kombinacija

osnovnih podataka, ija vrijednost jednoznano odreuje zapis. Ukoliko ima vie kandidata

za klju, tada odabiremo jednog od njih da bude primarni klju. Ne mora svaka datoteka

imati klju, jer mogu postojati zapisi-duplikati.


30/42

29

6.6.4. Smjetaj datoteke u vanjskoj memorijiZapis je obino znatno manji od bloka. Stoga se vie zapisa sprema u jedan blok.

Uzimamo da je u bloku smjeten cijeli broj zapisa, to znai da je dio bloka moda

neiskoriten. Adresazapisa gradi se kao uredeni par (adresa bloka, pomak unutar bloka).

Kod nekih organizacija datoteki mogu neka mjesta za zapise u bloku ostati prazna. Kakoda razlikujemo puna i prazna mjesta? Jedno rjeenje je: proiriti zapis s jednim bitom koji

oznaava da li je mjesto puno ili prazno. Koji put je potrebno ponititi zapis (uiniti

ga nevaeim), ali tako da njegovo mjesto i dalje bude zauzeto. Kako da razlikujemo

vaee i nevaee zapise? Opet proirimo zapis jednim bitom koji oznaava da li zapis

vai ili ne vai. Cijela datoteka obino zauzima vie blokova. Nain kako se odreuju

adrese tih blokova ovisi o organizaciji datoteke. U svakom sluaju, ne mora se raditi o nizu

uzastopnih adresa. Naime, zbog pisanja i brisanja podataka, vanjska memorija se prije ili

kasnije isparcelira, pa smo prisiljeni koristiti njene nepovezane dijelove.

6.6.5. PointeriPointer je vrijednost unutar jednog zapisa koja pokazuje na neki drugi zapis (u istoj

ili drugoj datoteci). Pointer moe biti: adresa zapisa (fiziki pointer), vrijednost

primarnog kljua (logiki pointer). Postoje i prijelazni oblici izmeu fizikog i logikog

pointera, na primjer redni broj zapisa; no smisao takvih vrijednosti ovisi o konkretnoj

organizaciji datoteke i mi ih neemo razmatrati. Pointeri omoguuju uspostavljanje veze

izmeu zapisa, dakle oni omoguuju da iz jednog zapisa pristupimo drugom. Pointer-

adresa omoguuje brzi pristup. Pointer-klju je spor - on samo implicitno odreuje zapis

kojeg tek treba pronai nekim mehanizmom za traenje na osnovu kljua. Prisustvo

pointera-adrese moe uzrokovati probleme kod auriranja ili reorganiziranja datoteke. Ako

na zapis pokazuje pointer-adresa, kaemo da je zapis prikovan(pinned) - zapis se naime ne

smije fiziki pomicati sa svog mjesta jer bi nakon pomaka pointer krivo pokazivao. Jedini

nain da pomaknemo prikovani zapis je da takoer auriramo i pointer, no problem je da

za zadani zapis obino ne znamo gdje se sve mogu nalaziti pointeri koji na njega pokazuju.

Prisustvo pointera-kljua ne uzrokuje nikakve probleme kod auriranja ili reorganizacije

datoteke. To je i razlog zato koristimo takve pointere, unato njihovoj sporosti.


31/42

30

6.6.6. Fizika grada cijele bazeCijela baza je gradena kao skup datoteki. Zapisi u datotekama mogu biti

medusobno povezani pointerima. Sve operacije s bazom svode se na osnovne operacije s

datotekama. Ukoliko imamo posla s relacijskim bazama, tada se svaka relacija prikazuje

jednom datotekom. Atributi relacije odgovaraju osnovnim podacima u zapisu. Jedna n-

torka relacije prikazana je jednim zapisom. Primarni klju relacije odreuje primarni klju

datoteke. Primijetimo da se ovakvim fizikim prikazom uvodi umjetni redoslijed medu

atributima relacije, te umjetni redoslijed n-torki. No, relacijski DBMS u stanju je

promijeniti taj redoslijed prilikom rada s relacijom. Osim osnovnih datoteki koje

odgovaraju pojedinim relacijama, fizika grada relacijske baze moe sadravati i dodatne

pomone datoteke koje ubrzavaju pretraivanje i uspostavljanje veza medu podacima.

Tipini primjeri takvih datoteki su indeksi.

6.7. Pristup na osnovu primarnog kljuaVana operacija u radu s datotekama je pristup na osnovu primarnog kljua. Dakle,

za zadanu vrijednost primarnog kljua treba odrediti adresu (najvie jednog) zapisa koji

sadri tu vrijednost kljua. Prouit emo razne organizacije datoteki i naine kako da se za

njih realizira pristup na osnovu primarnog kljua.

6.7.1. J

ednostavna datoteka

Zapravo se radi o odsustvu bilo kakve organizacije. Zapise datoteke poredamo u

onoliko blokova koliko je potrebno. Blokovi koji ine datoteku mogu biti povezani u

vezanu listu (svaki blok sadri adresu idueg bloka) ili moe postojati tablica adresa svih

blokova (koja zauzima prvi ili prvih nekoliko blokova). Traenje zapisa sa zadanom

vrijednou kljua zahtijeva sekvencijalno itanje cijele datoteke (ili bar pola datoteke u

prosjeku), sve dok ne naidemo na traeni zapis. Ako je datoteka velika, morat emo uitati

mnogo blokova, pa pristup traje dugo. Da bi ubacili novi zapis, stavljamo ga na prvo

slobodno mjesto u prvom nepopunjenom bloku, ili prikljuujemo novi blok ukoliko su svi

postojei blokovi popunjeni. Ako su zapisi prikovani, tada ne smijemo zaista izbacivati

zapise, ve ih samo moemo proglasiti nevaeima. No ako zapisi nisu prikovani, tada ih

smijemo izbacivati, pa e se time ispranjena mjesta koristiti kod buduih ubacivanja.

Promjena zapisa obavlja se bez ogranienja.


32/42

31

6.7.2. Pristup na osnovu drugih podatakaOsim pristupa na osnovu primarnog kljua, u radu s datotekama javlja se i potreba

za pristupom na osnovu drugih podataka. Dakle, trae se zapisi u kojima zadani podatak

(koji nije klju) ima zadanu vrijednost. Takvih zapisa moe biti i vie. Openitije, mogu se

traiti zapisi u kojima istovremeno podatakA1 ima zadanu vrijednost v1, podatakA2 ima

vrijednost v2, . . . , podatakAr ima vrijednost vr . Problem se uvijek moe rijeiti

sekvencijalnim pregledom cijele datoteke. No ukoliko elimo da se pristup obavlja brzo,

potrebne su posebne organizacije datoteke.

6.8. Implementacija relacijskih operacijaImplementacija prirodnog spoja

Prethodno izloeno uglavnom predstavlja statiki aspekt fizike organizacije baze

podataka. No, kod relacijskih baza teite je baeno na dinamiki aspekt, koji se svodi na

izvrednjavanje izraza u relacijskoj algebri. Stoga, da bi bolje razumjeli to se sve deava

unutar jednog relacijskog DBMS-a, potrebno je prouiti kako se fiziki odvija

izvrednjavanje algebarskog izraza. Osnovni korak je izvrednjavanje pojedine algebarske

operacije. Raspravljat emo o implementaciji triju najvanijih operacija: prirodnog spoja

(ovo potpoglavlje), te selekcije i projekcije (idue potpoglavlje). U zadnjem potpoglavlju

rei emo neto o optimalnom izvrednjavanju cijelog izraza. Promatramo relacijeR1(A,B) i

R2(B,C) sa zajednikim atributom B. Oznaimo sa S(A,B, C) prirodni spoj od R1 i R2.

Svaka od ovih triju relacija fiziki se prikazuje jednom (istoimenom) datotekom; n-torke se

pretvaraju u zapise, a atributi u istoimene osnovne podatke. Razmotrit emo nekoliko

naina kako da se pomou datotekiR1 iR2 generira datoteka S.


33/42

32

6.9. Integritet i sigurnost podataka6.9.1. uvanje integriteta

Rije je o problemima ije rjeavanje je nuno da bi velika viekorisnika baza

podataka mogla uspjeno funkcionirati. U ovom dijelu bavimo se uvanjem integritetabaze. Pod time se misli na uvanje korektnosti i konzistentnosti podataka.

Integritet se lako moe naruiti na primjer pogrenim upisom neopeznih korisnika

ili pogrenim radom aplikacijskog programa. Voljeli bismo kad bi se baza podataka mogla

sama braniti od naruavanja integriteta. U tu svrhu, suvremeni DBMS-i dozvoljavaju

projektantu baze da definira tzv. ogranienja(constraints). Rije je o uvjetima (pravilima)

koje korektni i konzistentni podaci moraju zadovoljavati. Kod svake promjene podataka

DBMS e automatski provjeravati da li su sva ogranienja zadovoljena. Ako neko

ogranienje nije zadovoljeno, tada DBMS nee izvriti traenu promjenu, ve e poslatiporuku o greki.

6.9.2. Ogranienja kojima se uva integritet domeneIzraavaju injenicu da vrijednost atributa mora biti iz zadane domene. Zahtjev da

vrijednost primarnog atributa ne smije biti prazna takoer spada u ovu kategoriju. U veini

DBMS-a orijentiranih na SQL, ogranienje na integritet domene prvenstveno se izraava

time to se u naredbi CREATE atributu pridrui tip (uz eventualnu klauzulu NOT NULL).

Popis podranih tipova obino nije velik (standardno to su char-stringovi fiksirane duljine,

brojevi s fiksnom tokom, cijeli brojevi, brojevi s plivajuom tokom, datumi, . . . ). Zato

na taj nain obino neemo biti u mogunosti da precizno izrazimo nae ogranienje.

6.9.3. Ogranienja kojima se uva integritet unutar relacijeuva se korektnost veza izmeu atributa unutar relacije (na primjer funkcionalne

ovisnosti). Najvaniji primjer takvog ogranienja je ono koje trai da dvije n-torke unutar

iste relacije ne smiju imati jednaku vrijednost kljua. Izbor ogranienja u dananjim

DBMS-ima ipak nije dovoljan da izrazi sva mogua pravila integriteta. Takoer,

mogunosti pojedinih DBMS-a se razlikuju. Ipak, dananji DBMS-i u tom pogledu su

znatno napredniji od onih prije 15-tak godina. Treba biti svjestan da svako ogranienje

predstavlja teret prilikom auriranja podataka (troi se vrijeme na provjeru). Zato prilikom

zadavanja ogranienja ne treba pretjerivati.


34/42

33

6.9.4. Istovremeni pristupVeina baza podataka po svojoj prirodi je viekorisnika. Znai jedan te isti

podatak, pohranjen na jednom mjestu, potreban je raznim osobama i raznim aplikacijama,

moda ak u isto vrijeme. Na primjer, broj prodanih avionskih karata za isti let trebasimultano biti dostupan raznim poslovnicama avionske kompanije. Od DBMS-a se zato

trai da korisnicima omogui istovremeni pristupdo podataka. Obino je rije o prividnoj

istovremenosti (dijeljenje vremena istog raunala). Ipak, DBMS i u tom sluaju mora

paljivo koordinirati konfliktne radnje. Svaki korisnik treba imati dojam da sam radi s

bazom.

6.9.5. Lokoti i zakljuavanjeLokoti su pomoni podaci koji slue za koordinaciju konfliktnih radnji. Baza je

podijeljena na vie dijelova, tako da jednom dijelu odgovara tono jedan lokot. Transakcija

koja eli pristupiti nekom podatku najprije mora uzeti odgovarajui lokot i time

zakljuati dotini dio baze. im je obavila svoju operaciju, transakcija treba vratiti lokot

i time otkljuatipodatke. Kad transakcija naide na podatke koji su ve zakljuani, ona

mora ekati dok ih prethodna transakcija ne otkljua. Time se zapravo izbjegava (sasvim)

istovremeni pristup istom podatku. Ovaj mehanizam dovoljan je da otkloni probleme iz

prolog primjera.

6.9.6. Rezervna kopija bazeDobiva se snimanjem cijele baze na drugi medij (magnetska traka ili drugi disk), i

to u trenutku kad smatramo da je baza u konzistentnom stanju. Za vrijeme kopiranja ne

smije se obavljati nikakva transakcija koja mijenja podatke. Stvaranje rezervne kopije je

dugotrajna operacija koja ometa redovni rad korisnika. Zato se kopiranje ne obavlja suvie

esto, ve periodiki u unaprijed predvidenim terminima (na primjer jednom tjedno).

6.9.7. Ponovno uspostavljanje bazeRije je o izvanrednoj i opsenoj operaciji koja se pokree na zahtjev

administratora. Primjenjuje se nakon znatnijeg oteenja baze ili u sluaju njenog potpunog

unitenja. Svodi se na ponovni upis svih podataka. Uobiajeni postupak naziva se

odmotavanje prema naprijed(roll-forward).


35/42

34

6.9.8. Zatita od neovlatenog pristupaBaza podataka mora biti zatiena od nedoputenih ili ak zlonamjernih radnji.

Osnovni vid zatite je fiziko ogranienje pristupa do samog raunala. Dalje, ograniava se

udaljeni pristup do raunala kroz mreu. No nas ovdje prvenstveno zanima finiji softverskivid zatite, koji je ugraden u DBMS. Njime se ljudima koji imaju mogunost rada na

dotinom raunalu ograniavaju mogunosti rada s bazom.

6.9.9. Identifikacija korisnikaUobiajeno je da svaki korisnik baze ima svoje korisniko ime (username) i lozinku

(password). Da bi smio raditi s bazom, korisnik se mora predstaviti DBMS-u navodenjem

imena, te mora dokazati svoj identitet navodenjem lozinke. DBMS raspolae popisom

korisnikih imena i pripadnih lozinki. Ukoliko korisnik navede ime i lozinku koji ne

odgovaraju popisu, DBMS mu ne doputa rad. Zatita se zasniva na tajnosti lozinke.

DBMS se moe osloniti na imena i lozinke koji ve postoje u operacijskom sistemu

raunala, ili se moe sluiti vlastitim popisom.

6.10. Izrada baze podataka u MSAccess-u6.10.1. Vanost planiranja

Koliko smo se puta za vrijeme rada uhvatili u razmiljanu da ne znamo to zapravo

radimo? Na prvi pokuaj nam otkriva da nam je znanje bilo slabo, na raunar lo ili smo

neke stvari previdjeli. Meutim, za vrijeme rada smo uglavnom biljeili to to emo

sljedei put uraditi drugaije, da bi bili bri i efikasniji. Neto poput baze podataka ne

dozvoljava puno eksperimenata niti greaka u radu. Dok radimo bazu podataka mi moramo

prihvatiti osnovne principe planiranja ako neemo da uimo na tei nain. Prije nego

zaponemo sa stvaranjem baze podataka postavljamo sebi nekoliko pitanja: Koje podatke

elim spremiti i kako ih je najbolje organizirati? Koje akcije unosa podatka elim ovisno oovom poslu za koji radimo? Koje informacije elim znati o statusu posla? Odgovorom na

ovo pitanje olakat emo izbor izvjetaja i upita. Dakle, kada naemo odgovore na ova

pitanja prelazimo na odabir programa za upravljanje bazom podataka.


36/42

35

6.10.2. MSAccessAccess je Microsoftov program za upravljanje bazama podataka. MS Access sadri

sve to je potrebno za rad s bazama podataka. U Accessu je najprije potrebno stvoriti

datoteku baze podataka. Tako stvorena datoteka uva sve to emo uraditi za tu bazu

podataka, ne samo sve podatke ve i forme, izvjetaje i upite. Ako radimo vie poslovaistovremeno, moemo uraditi odvojene baze podataka za svaki posao. MS Access kao

sistem za upravljanje bazom podataka izvrava nekoliko zadataka: Organizovanje baze

podataka- stvaranje tabela, njihovo meusobno povezivanje itd.,rad s podacima- itanje,

unos, brisanje, promjena podataka te itav niz ostalih operacija potrebnih za dobijanje

traenih informacija (npr. pretraivanje, izdvajanje, stvaranje izvjetaja i sl.), zatita

podataka- nadgledanje ispravnosti podataka (npr. kod pogrenog upisa) i zatita od

neovlatenog koritenja, nadgledanje istovremenog pristupa podacima- primjenjuje se

kada bazu istovremeno koristi vie korisnika, obnavljanje baze podataka u sluaju njenogoteenja- obnavljanje sadraja koji je bio oteen i vraanje na prijanje stanje.

Accessovi objekti:

y Tables: glavna komponenta Accessove baze sadre podatkey Queries: upiti za pregledavanje, pronalaenje, odabir i kombinovanje podatka iz jedne

ili vie tabela

y Forms: obrasci za laki pristup i rad s podacimay Reports: izvjetaji za prikaz podataka u obliku dokumenatay Pages: web-stranice za dostup do podataka (Data Access Pages)y Macros: makro naredbey Modules: samostalni VBA programski moduliy Favorites: preice do esto koritenih baza podataka

Tabela je osnovni dio za organizovano spremanje podataka unutar baze podataka.

U tabelu se upisuju podaci o subjektima ili objektima koji imaju slina svojstva i mogu se

vrlo precizno opisati.Opis se vri navoenje odgovarajuih svojstava, tzv. atributa. Jedna

kolona tabele sadri vrijednost jednog atributa, zato kolonu poistovjeujemo sa atributom i

obratno. Atribut ima svoje ime po kojem ga razlikujemo od ostalih u istoj relaciji.

Definisan je skup dozvoljenih vrijednosti za atribut, koji se zove domena atributa.Polje

(Field) je podatak kojim se opisuje odreeno svojstvo (atribut) subjekata ili objekata

upisanih u tabeli podataka. U bazama podataka redove nazivamo slog. Slog (Record, n-

torka) je red u tabeli baze podataka u koji se upisuje pojedini subjekt ili objekt.

Objedinjuje sva njegova svojstva (atribute) opisana poljima tabele.


37/42

36

6.10.3. Izbor tabelaTehni i za st aranje baze podataka trebamo st oritijednu tabli u. No,naj ea

greka je u tome to mnogi ljudi ujednu tabli u unesu mnogorazli itih informacija.

Accessje program koji uva odnoseu bazi podataka, to znai dajednostavno uva mnogo

tablica i stvara vezuizmeunjih. Na primjer, ako elimo stvoriti bazu podataka koja uvainformacije o kandidatima, ujednoj autokoli, stvorimo narednetablice:tabela podataka o

autokoli,upisanih kandidata, dokumentacijiitabela o izvrenim uplatama.

Jojedna greka je pokuaj da tablica izgleda poput izvjetaja. Jednostavnijeje

stvoritiizvjetajiliformu koja ukljuujeteinformacije kad god su potrebne, a prikazane su

u samo jednoj tablici. Za nau bazu podataka autokole koristimo est tabela, mada je

mogue i reducirati a i dodatijo onih koje sadre potrebne podatke o predsjednicima

komisija, ispitivaima, Odsjeku za saobraajnu edukaciju, obavljenim pregledima vozila,

servisima, itd

6.10.4. Izbor upitaDa bismo stvorili odgovarajueupite, moramo znatitajeto to moemo izvuiiz

baze kao podatak i koja je svrha tog podatka, odnosnokoje informacije su najee

potrebne pri korienju ove baze. Najee informacije koje se trae od strane vlasnika

kole, kandidata, ovlatenih osoba i inspekcije za nadzor rada autokola su: koliko imate

upisanih kandidata za neki vremenski period, koji su datumi upisa, datumi izdavanja

priloenih dokumenata, broj upisanih kandidata za vremenski period razvrstanih po

odreenim kategorijama/podkategorijama, izvreneuplate, dugovanja, i sl.

Slika 2. Izgled nekoliko tabela (Demo Braninovi,2010.)


38/42

37

6.10.5. Izbor izvjetajaIzvjetaj (reports) sujako vani sastavni dijelovi baze podataka i vrlo esto su

razlog da se baza iuradi. Izvjetaji seu principu pravena osnovu postavljenihupita, pa

emo iskoristititeupite za izvjetaje s tim da emo dodati joiizvjetaje koji odgovaraju

odgovarajuim potvrdama kojeizdaje autokola, kao to su potvrda o odsluanojteoretskoj

nastavi i zavrenoj obuci iz praktinog upravljanja vozilom odgovarajue kategorije,

karton kandidata (koji sadri sve podatke o kandidatu).

Slika 3. Primjer kreiranja upita po kriterijuime kandidata [Ime:](Demo Braninovi,2010.)

Slika 4. Primjer dva izvjetaja, (Demo Braninovi,2010.)


39/42

38

6.10.6. Izbor formeForma je zavrni rad na bazi podataka i biramo samo nekoliko formi koje e biti

jedine dostupne korisniku baze.

Ulazna forma, sastoji se od naslovnog izgleda baze (logo autokole, slika po

izboruvlasnika kole koja odraava neke karakteristike autokole, tipke koje slue za ulaz

u ostaleforme:upis novog kandidata, instruktori, vozila itipke za zatvaranje baze.

Forma za upis kandidata, forma koja sadri polja za upis novog kandidata: redni

brojupisa (kojijeujedno i primarni klju za sve tabele), prezime, ime oca, ime i JMB ,

datum roenja, ljekarsko uvjerenje broj i naziv ustanove koja ga je izdala, potvrda o

zavrenojteoretskojnastavi datum i broj, potvrda o uspjeno zavrenojnastaviiz pruanja

prve pomoi povrijeenim u saobraajnoj nezgodi datum i broj, potvrda o zavrenom

osposobljavanju iz upravljanja motornim vozilom datum i broj, broj knjiice kandidata,fotografija kandidata. Takoe, pored polja za upis na ovoj formi se nalaze i tipke za

izvjetaje (o uplati, o zavrenim nastavama, karton kandidata), ulaz u ostale forme i za

izlaz iz forme.

Forma instruktori, sadri imena instruktora sa slikama istih, kako bi kandidati

ukoliko sevenisu odluili ko eih obuavati mogli da videizborinstruktora, tetipke za

ulaz u ostaleformeiizlaz iz forme. Osim tipki koje smo ranijenaveli ova forma sadrijo

itipku za ulaz uformu za promjene podataka o instruktorima, u kojoj sevri prijava novog

instruktora, promjena podataka postojeihi odjava onih koji su prestali raditi.

Slika 5. Izgled formi za ulaz iupis podataka kandidata (Demo B. 2010)


40/42

39

6.11. Analiza i efekti postignuaAnalizirajui sve do sada navedeno u ovom radu neupitno je da se baza podataka u

autokolama i Odsjeku za saobraajnu edukaciju treba uvesti kao obaveza, meutim,

svakako treba navesti i razloge koji tu tvrdnju potkrepljuju. Podsjetimo se zakonske

obaveze: Autokola e voditi evidenciju o prolaznosti kandidata, pojedinano za svakog

instruktora i s tim u vezi arhivira ih i uva. Ovakvu vrstu evidencije autokole uglavnom ne

vode jer je mnogo subjektivnih i objektivnih faktora koji utiu na prolaznost kandidata,

meutim, to bi svakako u ovoj bazi podataka bio vaan detalj koji bi jasno pokazivao na

jednogodinjem ili ak viegodinjem uzorku dali neki od instruktora zaista kvalitetno

odrauje svoj posao ili je to na nekom nezadovoljavajuem nivou. O doprinosu

izraunavanja procenta prolaznosti kandidata moglo bi se priati sa vie aspekata, ali

najbitniji je porast kvaliteta obuke a time i prolaznosti isigurno

sti u

saobraaju to je

najvaniji cilj cijelog procesa obuavanja i ispitivanja.

Sada se samo namee pitanje, a zato ne proiriti ovu evidenciju i na cijelu

autokolu, ispitno mjesto, sva ispitna mjesta skupa i svakako neizostavno i na ispitivae iz

oblasti upravljanja motornim vozilom. Jo dugoronije rjeenje statistiki gledano je

uvezivanje ovih podataka sa bazom podataka MUP-a, kroz evidenciju o prekrajima u

saobraaju, ime bi se na neki nain zaokruio i proces selekcije od instruktora preko

ispitivaa do samih kandidata, odnosno vozaa motornih vozila, rezultiralo bi da selekcija

bude neminovna a time bi i cijeli proces iao ka kvalitetu. Mada se moe primjetiti da isami kandidati poinju birati autokole, odnosno instruktore koje imaju bolju prolaznost, a

kao proizvod objektivnog ocjenjivanja na ispitima kandidata za vozae, to opet, za

rezultat ima zatvaranje pojedinih autokola zbog nedostatka kandidata. Uzmimo za primjer

kandidat koji sluajno ulazi u autokolu da sklopi ugovor o uslugama obuke, a da ne

poznaje nikoga u toj autokoli, jednostavno moe zatraiti od vlasnika da iz baze podataka

iznese podatak koji pokazuje koji od instruktora ima najbolju prolaznost i tako se odredi za

kvalitetniju obuku. Protok podataka na ovaj nain bi se drastino ubrzao, tako sama

provjera u MUP-a da kandidat nije pod nekim sankcijama koje bi ga sprijeile da polaeispit bila bi mogua automatski.


41/42

40

7. ZAKLJUAKUvoenje baze podataka u neku autokolu ili ustanovu predstavlja sloeni zadatak

koji zahtijeva timski rad strunjaka raznih profila. To je projekt koji dijelimo u pet faza:

analiza potreba, modeliranje podataka, implementacija, testiranje i odravanje. Potrebe su

dijelom utvrene zakonskim i podzakonskim aktima a drugi dio su stvarne potrebe

evidentiranja podataka, koje omoguavaju da se u dananjicom nametnutim tempom ivota

skrati put od potrebe za informacijom do same informacije koja sa lakoom biva

pretvorena u dokument. Microsoft Access omoguuje relativno laganu izradu aplikacije za

rad s bazama podataka, jer sadri podosta arobnjaka koji e na temelju samo nekoliko

vaih odgovora izraditi jednostvne objekte koje kasnije moete po volji nadograivati

pomou brojnih alata. Daje potpunu slobodu odreivanja tipova podataka, naina njihove

pohrane i izgleda prilikom prikaza i ispisa, te omoguuje lako povezivanje srodnih

informacija. Dakle, prednosti su grafiko okruenje koje omoguuje izradu aplikacije bez

pisanja sloenog koda, te spremanje svih podataka u jednu datoteku to olakava prijenos

baze na druge raunare. Nedostatak mu je sporiji mreni rad, mada je i to u verziji 2007

poboljano. Baze podataka u mnogome nam olakavaju rad. to bolje opiemo podatke i

to je taj opis detaljniji i precizniji, to e raunar lake pronai ono to traimo. to su

podaci u raunaru bolje organizovani, lake emo na osnovu jednog podatka pronai drugi.

Zato je potrebno podatke u raunaru organizovati u obliku baze podataka. Uzimajui u

obzir pokazatelje koji su navedeni u ovom radu, da je recimo samo potvrda o poloenimispitima izdato 9613, u 2009.godini, na Tuzlanskom kantonu, koliko onda prijava, potvrda

i uvjerenja, opravdava ovaj trud oko izrade baza podataka. Ostali elementi nimalo

zanemarujui, kao to su eliminacija greaka u ispisivanju sve te dokumentacije, laki

protok podataka, uteda u vremenu, svakako e pomoi prihvatanju ovog programa od

strane vlasnika autokola. Nadograivanjem na ovakvu bazu ostalih pogodnosti kao to su:

uvezivanje