2.pdf

Goran Nei RAZVOJ I KOMPARATIVNA ANALIZA KLASINE DESKTOP APLIKACIJE I VIESLOJNE KLIJENT/SERVER ARHITEKTURE

FAKULTET ZA POSLOVNU INFORMATIKU

RAZVOJ I KOMPARATIVNA ANALIZA KLASINE DESKTOP

APLIKACIJE I VIESLOJNE KLIJENT/SERVER ARHITEKTURE

- Diplomski rad -

Beograd, 2007.

Mentor: Prof. dr Mladen Veinovi

Student: Goran Nei

Br. indeksa: III-2/2005


FAKULTET ZA POSLOVNU INFORMATIKU

UNIVERZITET SINGIDUNUM FAKULTET ZA POSLOVNU INFORMATIKU Beograd, Danijelova 32 Broj: __________/2007 Kandidat: Goran Nei Broj indeksa: III-2/2005 Smer: Projektovanje i programiranje Tema: RAZVOJ I KOMPARATIVNA ANALIZA KLASINE DESKTOP APLIKACIJE I

VIESLOJNE KLIJENT/SERVER ARHITEKTURE Zadatak: Realizovati bazu podataka za voenje evidencije o sredstvima za rad, opremi i potronom materijalu u jednoj ustanovi ili firmi. Baza treba da omogui voenje precizne i aurne evidencije o tome koja su sredstva, oprema, i druge vrste imovine izdati na korienje svakom od zaposlenih, zatim voenje evidencije o potronom materijalu u smislu koliina koje su izdate i preostalih koliina na lageru, kao i tampanje odgovarajuih vrsta dokumenata i izvetaja. Potrebno je razviti i aplikaciju koja korisnicima omoguava efikasan i intuitivan rad sa bazom, i to u klasinoj, desktop varijanti i u formi vieslojne klijent/server aplikacije. Komparativno analizirati ove dve vrste aplikacija. Datum odobrenja teme: 05.02.2007. Beograd

MENTOR

Prof. dr Mladen Veinovi

DEKAN

Prof. dr Milan Milosavljevi


Saetak Faze u razvoju baze podataka su:

1. Planiranje 2. Definicija sistema 3. Prikupljanje i analiza zahteva 4. Dizajniranje baze 5. Izbor DBMS platforme 6. Dizajniranje aplikacije 7. Implementacija 8. Punjenje baze podacima 9. Testiranje 10. Odravanje

Da bi se obezbedio precizan opis prirode podataka i naina na koji se oni koriste, potrebno je proizvesti jasan model koji nije striktno tehnike prirode. Jedan od najee korienih modela u praksi je Enitiy-Relationship (ER) model. Osnovne koncepte ER modela ine entiteti, veze i atributi. Glavni cilj u procesu razvoja baze podataka je da se kreira sistem koji verno reprezentuje podatke, njihove veze i odnose, kao i ogranienja. Da bi se postigao ovaj cilj, moraju se pravilno uoiti odgovarajue tabele, a metoda koja se za to koristi naziva se normalizacija. Normalizacija omoguava projektantu baze da izvri optimalno grupisanje atributa po tabelama. U metodologiji razvoja baze podataka definisane su tri osnovne faze, i to su:

1. Konceptualni dizajn 2. Logiki dizajn 3. Fiziki dizajn

Baza podataka MAGACIN predstavlja efikasno softversko reenje za voenje evidencije o sredstvima za rad, opremi, potronom materijalu i jo nekim vrstama imovine jedne ustanove ili firme. Baza je originalno razvijena za potrebe ustanove u kojoj se oprema i imovina izdaju zaposlenima na korienje, a oni ih upotrebljavaju u svakodnevnom radu, kao osnovno ili pomono sredstvo. Klijent/server arhitektura je nastala iz potrebe za prevazilaenjem ogranienja kao to su slaba ili nikakva podrka za grafiko korisniko okruenje, limitirani broj korisnika koje je sistem u stanju da podri i otean pristup fiziki razmetenim izvorima podataka. Vieslojna klijent/server arhitektura predstavlja praktinu realizaciju klijent/server arhitekture koja je tokom vremena evoluirala u skladu sa korisnikim zahtevima i kao rezultat tenje ka boljim performansama sistema. Vieslojne klijent/server arhitekture se najee realizuju kao 2-slojne, 3-slojne i n-slojne.


I klasine desktop aplikacije i moderne vieslojne klijent/server arhitekture imaju svoje prednosti i mane. U poslovnim okruenjima u kojima se koriste, za obe vrste aplikacija postoje poslovi za koje je primena jedne ili druge vrste aplikacija jedino logino reenje, pa ih u tom kontekstu ne treba posmatrati kao direktnu konkurenciju.


Abstract The stages of the database application lifecycle are:

1. Database planning 2. System definition 3. Requirements collection and analysis 4. Database design 5. DBMS selection 6. Application design 7. Implementation 8. Data loading 9. Testing 10. Operational maintenance

To ensure a precise understanding of the nature of the data and how it is used by the enterprise, it is necessary to create a non-technical model free of ambiguities. One of the most commonly used models is the Enitiy-Relationship (ER) model. Basic ER concepts are entities, relationships and attributes. In a database design process, the main objective is to create an accurate representation of the data, its relationships, and constraints. To achieve this objective, a suitable set of relations must be identified. Normalization is a technique used for identification such relations. Normalization enables the database designer to identify optimal grouping of attributes for each relation in the schema. There are three main phases in methodology of database design:

1. Conceptual database design 2. Logical database design 3. Physical database design

MAGACIN database is an efficient software solution for keeping track of equipment and other kinds of inventory in an institution or enterprise. Database was originally developed for an institution in which employees are given different kinds of equipment and inventory to use them in their daily activities. As a result of the limitations like bad or no GUI support, limited number of supported users, and complicated access to data sources from geographically dispersed sites, client/server architecture emerged. Multitier client/server architecture represents a practical implementation of the client/server architecture that has evolved according to user requirements and as a result of tendency towards constant improvement of system performances. Multitier client/server architectures are usually implemented as 2-tier, 3-tier, and n-tier.


Both traditional desktop applications and modern multitier client/server architectures have their advantages and weaknesses. They are frequently used in business environments, where is possible to identify jobs perfectly suitable for both types of applications, so in that sense they are not to considered as direct opponents.


SADRAJ Uvod ............................................................................................................................ 1 1. Teorija baza podataka ........................................................................................... 2

FAZE U RAZVOJU BAZE PODATAKA ................................................................................... 3 Planiranje ..................................................................................................................................... 3 Definicija sistema ........................................................................................................................... 3 Prikupljanje i analiza zahteva ........................................................................................................... 4

Prouavanje dokumentacije ......................................................................................................... 4 Intervjuisanje ............................................................................................................................ 4 Posmatranje rada u okruenju za ije potrebe se razvija baza........................................................... 4 Istraivanje ............................................................................................................................... 4 Upitnici .................................................................................................................................... 5

Dizajniranje baze ........................................................................................................................... 5 Faze u dizajniranju baze podataka................................................................................................ 5

Izbor DBMS platforme .................................................................................................................... 5 Dizajniranje aplikacije ..................................................................................................................... 5

Transakcije ............................................................................................................................... 6 Korisniki interfejs ..................................................................................................................... 6

Implementacija ............................................................................................................................. 7 Punjenje baze podacima ................................................................................................................. 7 Testiranje ..................................................................................................................................... 7 Odravanje ................................................................................................................................... 7

ENTITY-RELATIONSHIP MODEL ........................................................................................ 8 Entiteti ......................................................................................................................................... 8 Veze ............................................................................................................................................ 8 Atributi ......................................................................................................................................... 9

Kljuevi .................................................................................................................................... 9 Atributi veza................................................................................................................................ 10 Strukturna ogranienja ................................................................................................................. 10

Jedan-prema-jedan (1:1) veze ................................................................................................... 11 Jedan-prema-vie (1:*) veze ..................................................................................................... 11 Vie-prema-vie (*:*) veze ....................................................................................................... 12 Kardinalnost i participacija (uee) ............................................................................................ 12

NORMALIZACIJA ............................................................................................................. 13 Redundantnost (ponavljanje) podataka i anomalije auriranja ............................................................ 13

Anomalije unosa podataka ........................................................................................................ 13 Anomalije brisanja podataka...................................................................................................... 14 Anomalije promene podataka .................................................................................................... 14

Funkcionalna zavisnost ................................................................................................................. 14 Prva normalna forma (1NF) ........................................................................................................... 14 Druga normalna forma (2NF) ......................................................................................................... 15

Potpuna funkcionalna zavisnost ................................................................................................. 15 Definicija druge normalne forme ................................................................................................ 15

Trea normalna forma (3NF) ......................................................................................................... 15 Tranzitivna zavisnost ................................................................................................................ 15 Definicija tree normalne forme ................................................................................................. 16

Boyce-Codd normalna forma (BCNF) ............................................................................................... 16 etvrta normalna forma (4NF) ....................................................................................................... 16

Zavisnost viestruke vrednosti ................................................................................................... 17 Definicija etvrte normalne forme .............................................................................................. 17

Peta normalna forma (5NF) ........................................................................................................... 18 Postojanost spajanja (lossless-join) ............................................................................................ 18 Definicija pete normalne forme .................................................................................................. 18

METODOLOGIJA DIZAJNIRANJA BAZE PODATAKA ......................................................... 19 Konceptualni dizajn ...................................................................................................................... 19 Logiki dizajn .............................................................................................................................. 19 Fiziki dizajn ............................................................................................................................... 20

2. Baza podataka Magacin ....................................................................................... 21 I faza: PLANIRANJE ..................................................................................................................... 21


II faza: DEFINICIJA SISTEMA ........................................................................................................ 21 III faza: PRIKUPLJANJE I ANALIZA ZAHTEVA ................................................................................... 21

Studija ................................................................................................................................... 22 IV faza: DIZAJNIRANJE BAZE ........................................................................................................ 23

Entiteti ................................................................................................................................... 23 Primarni kljuevi ...................................................................................................................... 24 Veze ...................................................................................................................................... 25

V faza: IZBOR DBMS PLATFORME .................................................................................................. 26 VI faza: DIZAJNIRANJE APLIKACIJE ............................................................................................... 26 VII faza: IMPLEMENTACIJA ........................................................................................................... 27 VIII faza: PUNJENJE BAZE PODACIMA ............................................................................................ 27 IX faza: TESTIRANJE .................................................................................................................... 27 X faza: ODRAVANJE ................................................................................................................... 27

3. Klijent/Server arhitektura................................................................................... 28 4. Vieslojna klijent/server arhitektura ................................................................. 30

2-slojna arhitektura ...................................................................................................................... 30 3-slojna arhitektura ...................................................................................................................... 32 N-slojna arhitektura ..................................................................................................................... 35

Sloj podataka .......................................................................................................................... 35 Sloj poslovnih pravila (business rules) ......................................................................................... 36 Sloj toka podataka (workflow layer) ........................................................................................... 37 Prezentacioni sloj ..................................................................................................................... 37

5. Komparativna analiza klasine desktop aplikacije i vieslojne klijent/server arhitekture ............................................................................................................... 38

Bezbednost i integritet podataka .................................................................................................... 38 Stepen sloenosti razvoja .............................................................................................................. 39 Raspoloivost .............................................................................................................................. 39 Jasnoa/preglednost .................................................................................................................... 40 Upotrebljivost .............................................................................................................................. 40 Brzina reagovanja ........................................................................................................................ 40

Zakljuak.................................................................................................................... 42 Literatura ................................................................................................................... 43

Goran Nei

1

RAZVOJ I KOMPARATIVNA ANALIZA KLASINE DESKTOP APLIKACIJE I VIESLOJNE KLIJENT/SERVER ARHITEKTURE

Uvod U poslednjih desetak godina svedoci smo rapidnog razvoja informacionih tehnologija koje su postale neizbene u svim sferama poslovanja i ivota. Kao jedna od najznaajnijih IT oblasti, aplikavtivno programiranje je takoe pretrpelo mnoge promene i doivelo ekspanziju u mnogo razliitih pravaca. U ne tako dalekoj prolosti, aplikacijom se smatrao program koji se izvrava na pojedinanom desktop raunaru, potpuno izolovano od ostatka sveta. Aplikaciji su na raspolaganju stajali samo resursi raunara na kome se izvrava, dok je deljenje podataka i resursa bilo nezamislivo, a razmena podataka sa drugim korisnicima iz okruenja se obavljala na krajnje primitivan nain, pomou medijuma kao to je flopi disk. Moe se konstatovati da smo daleko odmakli od tog doba. Moderna aplikacija je tipino klijent/server tipa, svi neophodni podaci i resursi u mrei se dele izmeu svih korisnika kojima su potrebni, poslovi se distribuiraju na posveene servere koji raspolau monim resursima koji su u stanju da odgovore na sve postavljene zahteve. Ovaj rad ima za cilj da prikae karakteristike nekih od najee zastupljenih arhitektura kod modernih klijent/server aplikacija i da izvri komparativnu analizu tih arhitektura sa klasinom desktop aplikacijom.

Goran Nei

2


1. U ovom poglavlju su obraene odabrane teme iz teorije baza podataka. Materija je obraena u potpuno opem maniru, tako da se sve spomenute tehnike i metode mogu primeniti u procesu razvoja bilo koje baze podataka. Poglavlje se sastoji iz etiri dela. Najpre se detaljno opisuju faze u razvoju baze podataka da bi se stekao opti pregled celog procesa. Zatim se, u drugom, treem i etvrtom delu respektivno, prikazuju izabrane oblasti teorije baza podataka, i to: Entity-Relationship model, Normalizacija i Metodologija dizajniranja baze podataka.

Teorija baza podataka

Goran Nei

3


FAZE U RAZVOJU BAZE PODATAKA Tabela 1 prikazuje hronoloki redosled faza u razvoju baze podataka, uz kratak opis. Zatim sledi detaljan opis svake faze.

FAZA OPIS

Planiranje Planiranje najefikasnijeg naina za realizciju svih faza u razvoju baze podataka

Definicija sistema Odreivanje opsega baze podataka, njenih korisnika i oblasti primene

Prikupljanje i analiza zahteva Prikupljanje i analiza zahteva od korisnika; prikupljanje i analiza ostalih znaajnih podataka iz okruenja u kome e se baza koristiti

Dizajniranje baze Konceptualni, logiki i fiziki dizajn baze podataka

Izbor DBMS platforme Izbor odgovarajue DBMS platforme (DBMS = Database Management System)

Dizajniranje aplikacije Dizajniranje korisnikog interfejsa i prateih aplikacija

Implementacija Fizika realizacija baze i prateih aplikacija

Punjenje baze podacima Punjenje baze podacima (ako je prethodno postojala starija verzija baze, vri se i migracija na novu verziju, to ponekad zahteva i konverziju podataka)

Testiranje Baza se testira u cilju otkrivanja i otklanjanja greaka; proverava se da li su ispunjeni svi korisniki zahtevi

Odravanje Baza je implementirana u celini; vri se kontinualno kontrolisanje i odravanje; ako je potrebno, implementiraju se novi korisniki zahtevi

Tabela 1 Faze u razvoju baze podataka

Planiranje Najvanija aktivnost tokom faze planiranja je jasno definisanje ciljeva koje baza podataka treba da ispuni. Ovo pomae da se pojasni svrha projekta i da se saini jasan plan za efikasnu realizaciju. Svaki od definisanih ciljeva identifikuje odreeni zadatak koji baza mora da ispuni. Pretpostavlja se da e, ako baza ispunjava sve planirane zadatke, i svi postavljeni ciljevi biti ispunjeni. U ovoj fazi se mogu navesti i neki dodatni podaci, kao na primer tana specifikacija poslova koji treba da se urade, potrebni resursi, novana sredstva potrebna za realizaciju, itd. Planiranje treba da obuhvati i razvoj standarda koji odreuju kako e se sakupljati podaci, format podataka, potrebnu dokumentaciju, kao i metodologiju dizajniranja i implementacije. Definicija sistema Pre nego to se pristupi dizajniranju, neophodno je najpre identifikovati opseg i granice baze podataka, kao i nain na koji e se ona uklopiti u informacioni sistem posmatranog okruenja, ako on ve postoji. Vano je da se unutar opsega i granica baze nau ne samo trenutni korisnici i postojee oblasti primene, ve da se predvidi i mogunost prihvatanja korisnika i oblasti primene koji e se pojaviti u budunosti.

Goran Nei

4


U ovoj fazi se definiu glavni korisnici baze u smislu vrste posla koga obavljaju ili funkcije na kojoj se nalaze (npr. menader ili supervizor), to ujedno odreuje podatke koje e korisnik upotrebljavati i transakcije koje e obavljati nad podacima. Takoe se definiu i zahtevi iz perspektive pojedinih oblasti primene u posmatranom okruenju (npr. marketing, ljudski resursi). Ovo se najee realizuje upotrebom "korisnikih pregleda" (user views) koji se kreiraju za sve glavne korisnike i oblasti primene. Prikupljanje i analiza zahteva Ova faza podrazumeva prikupljanje i analizu informacija o okruenju za ije potrebe se baza razvija. Informacije se prikupljaju za sve glavne funkcije i oblasti primene. Na osnovu analize prikupljenih podataka kreira se dokument koji se naziva specifikacija zahteva i iz njega, zapravo, proizilazi funkcionalnost baze podataka. Postoji nekoliko uobiajenih tehnika za prikupljanje informacija relevantnih za razvoj:

Prouavanje dokumentacije Intervjuisanje Posmatranje rada u okruenju za ije potrebe se razvija baza Istraivanje Upitnici.

Prouavanje dokumentacije Prouavanje dokumentacije moe da prui korisne informacije o tome kako i zato se javila potreba za bazom, o problematinom delu (sektoru, odeljenju) posmatranog okruenja ili o ve postojeem DBMS sistemu. Dokumentacija koja se prouava moe biti vrlo raznolika: interna dokumenta, elektronska pota, razne vrste formulara i izvetaja, dokumentacija o postojeem sistemu, itd. Intervjuisanje Intervjuisanje je najee koriena i najkorisnija tehnika za prikupljanje informacija. Najbolji rezultati se postiu upotrebom tipskih, strukturiranih intervjua sa tano odreenim pitanjima koja se, u zavisnosti od situacije, dopunjuju jo nekim pitanjima koja mogu da daju korisne informacije. Ipak, i ova tehnika ima mane jer zahteva mnogo vremena i u mnogome zavisi od komunikativnosti uesnika i od dobre volje zaposlenih da daju informacije. Posmatranje rada u okruenju za ije potrebe se razvija baza Ovo je jedna od najefikasnijih tehnika za shvatanje sistema zato to podrazumeva direktno uee u radu ili posmatranje osoba u radu. Ova tehnika je posebno korisna u situaciji kada krajnji korisnici nisu u stanju da daju jasna objanjenja o sistemu i/ili procesu rada zbog njihove kompleksnosti. Istraivanje Istraivanje moe da prui korisne podatke o tome da li je i na koji nain neki problem pred kojim se naao razvojni tim ve reen. Takoe se moe doi i do informacije o nekom postojeem softverskom alatu ili aplikaciji koji delimino ili u potpunosti reavaju taj problem.

Goran Nei

5


Upitnici Metoda popunjavanja upitnika je pandan intervjuisanju. Primenjuje se u situacijama kada bi bilo potrebno intervjuisati ogroman auditorijum, a to zbog utroka vremena nije praktino. Kao i kod intervjuisanja, najbolje je koristiti tipske upitnike tano odreenog formata sa ponuenim odgovorima i mogunou izbora jednog ili vie od njih. Dizajniranje baze Postoje dva glavna pristupa dizajniranju baze podataka. Po prvom, dizajniranje poinje na osnovnom nivou nivou atributa (svojstva entiteta i veza) koji se, posle analiziranja, grupiu u tabele (koje predstavljaju tipove entiteta) i veze izmeu entiteta. Proces normalizacije je primer za ovakav pristup koji je pogodan za manje baze sa relativno malim brojem atributa. Drugi pristup je pogodniji za dizajniranje sloenih baza i po njemu se najpre kreira model koji sadri samo nekoliko globalnih entiteta i veza, da bi se zatim prelo na sukcesivno identifikovanje entiteta, veza i njima pripadajuih atributa na niim nivoima. Primer za ovakav pristup je upotreba ER (Entity-Relationship) modela koji zapoinje identifikacijom globalnih entiteta i njihovih meusobnih veza. Faze u dizajniranju baze podataka Razvoj baze podataka se sastoji iz tri faze:

I faza Konceptualni dizajn II faza Logiki dizajn III faza Fiziki dizajn

Detaljni opis svih faza dat je u poglavlju Metodologija dizajniranja baze podataka. Izbor DBMS platforme Ako DBMS platforma jo uvek ne postoji, pravi trenutak za njen izbor je izmeu kreiranja konceptualnog i logikog modela. Zapravo, platforma se moe izabrati u bilo kom trenutku pre kreiranja logikog modela, pod uslovom da se raspolae dovoljnom koliinom informacija po pitanju sistemskih zahteva kao to su performanse, bezbednost i integritet. Takoe, treba uzeti u obzir i eventualna proirenja sistema u budunosti, pa na osnovu svih spomenutih kriterijuma doneti odluku o izboru platforme. Dizajniranje aplikacije Dizajniranje aplikacije podrazumeva kreiranje korisnikog interfejsa i programa (aplikacija) koji e raditi sa bazom. Cilj ove faze je da obezbedi da svi korisniki zahtevi navedeni u specifikaciji zahteva budu implementirani u aplikaciji. To podrazumeva razvoj programa i kreiranje transakcija, tj. metoda (funkcija) koje pristupaju bazi. Aplikacija baze podataka mora da ima takozvani "user-friendly" korisniki interfejs. Dizajneri esto zanemaruju razvoj

Goran Nei

6


korisnikog interfejsa, ali treba napomenuti da je to jedan od najvanijih delova sistema. Ako je lak za uenje, jednostavan za upotrebu i otporan na greke, korisniki interfejs e onome ko ga upotrebljava dati mogunost da podatke koje reprezentuje iskoristi na pravi nain. Transakcije Transakcija se definie kao akcija ili vie sukcesivnih akcija koje vri korisnik, a koje podrazumevaju pristup bazi podataka i/ili promenu podataka u njoj. Transakcija predstavlja dogaaje iz realnog sveta, kao to su na primer prijem novog zaposlenog, izdavanje opreme, itd. Transakcija moe da se sastoji iz nekoliko operacija, kao to je na primer transfer novca sa jednog rauna na drugi. Transakcija prevodi bazu iz jednog konzistentnog stanja u drugo. DBMS mora da obezbedi konzistentnost ak i u sluaju greke. DBMS takoe mora da obezbedi da, po izvrenju transakcije, promene koje su uinjene ostanu trajno sauvane. Ako transakcija iz bilo kog razloga ne moe da se u potpunosti izvri, DBMS mora da obezbedi da se uinjene promene ponite. Kod kreiranja transakcija glavni zadatak je da se definiu i dokumentuju njihova najvanija svojstva, kao to su:

Podaci sa kojima e transakcija raditi Funkcionalne karakteristike transakcije Izlaz transakcije Oekivana frekventnost upotrebe.

Postoje tri glavna tipa transakcija:

1. Transakcije za prezentaciju podataka, koje pristupaju bazi i itaju iz nje odreene podatke koji se zatim prikazuju na ekranu ili u izvetajima.

2. Transakcije za promenu podataka, koje dodaju nove zapise u bazu, briu

nepotrebne zapise ili auriraju postojee zapise.

3. Meovite transakcije, koje slue i za prezentaciju i za promenu podataka. Primer za ovu vrstu transakcije bi bila situacija u kojoj se najpre vri pretraga po nekom kriterijumu, zatim se podaci prikazuju korisniku koji ih onda aurira i na kraju sauva promene.

Korisniki interfejs Prilikom dizajniranja korisnikog interfejsa (formi i izvetaja) korisno je imati na umu sledee smernice:

Dati smislen naziv koji nedvosmisleno identifikuje namenu forme ili izvetaja Ponuditi shvatljive instrukcije, zajedno sa sistemom pomoi, ako je potrebno Logiki grupisati i rasporediti polja Kreirati vizuelno uredne forme i izvetaje Poljima dati lako razumljive nazive Omoguiti kretanje kroz formu/izvetaj ne samo miem, ve i tastaturom Skrenuti korisniku panju na svaku greku koju uini U to je mogue veoj meri predvideti potencijalne greke korisnika i blagovremeno

ih spreiti da ih naine.

Goran Nei

7


Implementacija Implementacija baze se realizuje pomou jezika DDL (Data Definition Language) iz same baze koja je izabrana kao razvojna platforma (npr. Oracle) ili pomou vizuelnih alata za razvoj koji imaju sopstveno grafiko okruenje, a koji mogu biti deo same baze (npr. Access) ili posebna aplikacija (npr. Oracle Designer, Power Designer). Aplikacije se takoe mogu razvijati alatima ugraenim u bazu koja je izabrana kao razvojna platforma ili u nekim standardnim razvojnim okruenjima tipa Visual Basic, Visual C++, JBuilder. U sluaju upotrebe standardnih razvojnih okruenja radi se o primeni nekog od programskih jezika visokog nivoa (Basic, C++, Java) u koje se ugrauju transakcije za rad sa bazom koje su implementirane pomou jezika DML (Data Manipulation Language). Punjenje baze podacima U ovoj fazi nova baza se puni podacima, najbolje automatizovano pomou nekog softverskog alata. U sluaju postojanja starije verzije baze, vri se i migracija na novu verziju, to ponekad zahteva i konverziju podataka (ako je dolo do promene formata). Testiranje Pre konanog putanja u rad baza mora biti temeljito testirana. Testiranje se vri sa dva cilja: da bi se otkrile eventualne greke i/ili nepravilnosti u radu, i da bi se demonstriralo da baza i pratee aplikacije, ako postoje, rade u skladu sa korisnikom specifikacijom zahteva. Testiranje treba obaviti u realnim uslovima, istim onim u kojima e se baza koristiti tokom eksploatacije, uz upotrebu pravih podataka. U testiranje treba ukljuiti korisnike koji e raditi sa bazom. Po mogustvu, testiranje bi trebalo obaviti na posebnoj test platformi, a u nedostatku iste podatke treba zatititi redovnim bekapovanjem. Odravanje Posle faza tokom kojih je implementirana i testirana, baza prelazi u fazu odravanja, koja podrazumeva sledee aktivnosti:

Nadgledanje performansi sistema. Ako performanse padnu ispod prihvatljivog nivoa, pristupa se podeavanju ili reorganizaciji baze.

Odravanje i usavravanje aplikacija. Novi korisniki zahtevi se ugrauju u postojee

aplikacije. Veliki DBMS sistemi tipa Oracle ili SQL Server stavljaju korisniku na raspolaganje mone i efikasne alate za nadgledanje i podeavanje performansi, kao na primer alat za analiziranje indeksa ili alat za analiziranje i optimizaciju SQL naredbi. Upotrebom ovakvih alata administrator ima mogunost da bazu dovede u optimalno stanje i da je u takvom stanju odrava tokom celog ivotnog veka.

Goran Nei

8


ENTITY-RELATIONSHIP MODEL Jedan od najveih problema u procesu razvoja baze podataka je injenica da projektanti, programeri i krajnji korisnici na potpuno razliite naine shvataju podatke i naine njihove upotrebe, kao i procese iz posmatranog okruenja koje treba modelirati. Da bi se obezbedio precizan opis prirode podataka i naina na koji se oni koriste, potrebno je proizvesti jasan model koji nije striktno tehnike prirode. Jedan od najee korienih modela u praksi je Enitiy-Relationship (ER) model. Osnovne koncepte ER modela ine entiteti, veze i atributi. Entiteti Entiteti predstavljaju objekte iz realnog sveta. Entitet egzistira nezavisno i moe predstavljati fiziki, realni objekat (npr. Sredstvo) ili konceptualni, apstraktni objekat (npr. Radno iskustvo). Entitet se identifikuje nazivom i listom svojstava, a grafiki se predstavlja kao pravougaonik u kome se ispisuje naziv entiteta, koji je najee imenica. U bazi MAGACIN, izmeu ostalog, postoje entiteti kao to su Sredstvo, Ulaz/Izlaz, Zaposleni.

Sredstvo

Veze Veze oznaavaju da su odreeni entiteti povezani, odnosno da su ti entiteti u odreenom odnosu. Svakoj vezi se daje naziv koji opisuje njenu funkciju. Na primer, u bazi MAGACIN izmeu entiteta Ulaz/Izlaz-stavke i Sredstvo postoji veza Sadri koja oznaava da ulazno/izlazni dokument sadri listu sredstava koja se unose u magacin (Trebovanje) ili izdaju nekome od zaposlenih na korienje (Revers). Veza se grafiki predstavlja kao linija koja spaja entitete i uz koju se ispisuje naziv, koji je najee glagol. Treba napomenuti da naziv veze uglavnom ima samo jednosmerni smisao, pa je uobiajeno da se pored naziva veze iscrta i strelica koja oznaava pravilan smer, kao na slici.

Ulaz/Izlaz-stavke

Sredstvo

Broj entiteta koji uestvuju u vezi se naziva stepen veze. Veza u kojoj uestvuju dva entiteta se naziva binarna, veza treeg stepena (uestvuju tri entiteta) se naziva ternarna, itd. Veza u kojoj jedan entitet uestvuje vie puta u razliitim ulogama naziva se rekurzivna ili unarna veza. Primer u bazi MAGACIN bila bi veza Izdaje sredstvo, koja stoji uz entitet Zaposleni i oznaavala vezu zaposlenih sa magacionerom, jer i on spada u kategoriju zaposlenih. Drugim reima, enetitet Zaposleni uestvuje dva puta u vezi Izdaje sredstvo: prvi put kao magacioner koji izdaje sredstva drugima, a drugi put kao jedan od zaposlenih kome takoe moe da se izda sredstvo.

Sadri

Goran Nei

9


Zaposleni

Atributi Atributi predstavljaju odreena svojstva entiteta koja ih opisuju. Atributi su na primer Naziv sredstva, Fabriki broj, Ime i prezime, Broj telefona, itd. Glavni deo podataka koji se uvaju u bazi su upravo atributi. Za svaki atribut moe se definisati domen koji predstavlja set dozvoljenih vrednosti koje atribut moe da primi. Na primer, polje Kategorija sredstva u tabeli Sredstvo baze MAGACIN ima tano definisan set naziva kategorija koji mogu da se unesu u to polje. Set naziva kategorija se uva u tabeli Kategorija sredstva. Od svih vrsta atributa najvaniji su kljuevi. Kljuevi Klju kandidat predstavlja minimalni set atributa ije vrednosti jedinstveno identifikuju entitet. Na primer, klju kandidat za tabelu Zaposleni baze MAGACIN bio bi atribut Ime i prezime, jer on jedinstveno identifikuje svakog od zaposlenih. (Strogo uzevi atribut JMBG bi bio najbolji klju kandidat, jer on jedinstveno identifikuje svakog graanina, ali s obzirom na to da u okruenju u kome se baza MAGACIN koristi ima samo oko 50 zaposlenih, mala je verovatnoa da e se pojaviti vie osoba sa istim imenom i prezimenom). Klju kandidat ne sme da ima vrednost null. Primarni klju je klju kandidat koji je izabran da jedinstveno identifikuje entitet. Entitet moe da ima vie kljueva kandidata, pa se primarni klju bira na osnovu kriterijuma kao to su duina atributa, minimalni broj potrebnih atributa i procene da li e atribut i u budunosti biti jedinstven. U prethodnom pasusu uporeeni su atributi JMBG i Ime i prezime i zakljueno je da, sa aspekta zahteva baze MAGACIN, atribut Ime i prezime zadovoljava potrebe jedinstvene identifikacije. Meutim, sa aspekta zahteva za dizajniranje baze koja sadri podatake o svim graanima nae zemlje, atribut Ime i prezime ne bi bio dobar izbor, jer postoji mnogo graana sa istim imenom i prezimenom. Za takvu bazu jedini pravilan izbor za primarni klju bio bi atribut JMBG. Klju kandidat koji nije izabran za primarni klju naziva se alternativni klju. Sloeni klju je klju kandidat koji se sastoji od dva ili vie atributa. U nekim sluajevima klju entiteta se sastoji od nekoliko atributa ije su vrednosti jednistvene ako se posmatraju zajedno, ali pojedinane vrednosti tih atributa nisu jedinstvene. U tabeli Ulaz/Izlaz-stavke baze MAGACIN atributi PKID_Ulaz/Izlaz i PKID_Sredstva ine sloeni klju. Ovakvo reenje je primenjeno zbog toga to je trebalo obezbediti da se jedno sredstvo moe pojaviti samo jedanput u jednom dokumentu (Revers, Trebovanje ili Povratnica). Poto e se atribut PKID_Sredstva sigurno pojaviti vie puta u tabeli Ulaz/Izlaz-stavke, jedini nain da se realizuje spomenuti zahtev je da se formira sloeni klju, poto atributi PKID_Ulaz/Izlaz i PKID_Sredstva u kombinaciji formiraju jedinstvenu vrednost koja jednoznano identifikuje

Izdaje sredstvo

Magacioner

Jedan od zaposlenih

Naziv uloge

Naziv uloge

Goran Nei

10


svaki zapis u tabeli, pod uslovom da se obezbedi da atribut PKID_Ulaz/Izlaz bude jedinstven za svaki dokument koga reprezentuje. Atributi se grafiki predstavljaju tako to se pravougaonik koji predstavlja entitet horizontalno podeli na dva dela, pa se u gornjem delu ispisuje naziv entiteta, a u donjem lista atributa. Prvi u listi se nalazi primarni klju, ako postoji. esto se pored primarnog kljua ispisuje {PK} ili naziv primarnog kljua poinje sa PK.

Zaposleni

Ime i prezime {PK} Organizaciona jedinica Lokal Mobilni

Atributi veza Veze takoe mogu da imaju atribute. Na primer, u bazi podataka neke agencije za prodaju i izdavanje nekretnina mogla bi da postoji veza Oglaava koja spaja entitete Novine i Nekretnina.

Novine Nekretnina Naziv novina IdentBrNekretnine

Datum oglaavanja Cena

Da bi se dokumentovalo da je za nekretninu dat oglas, podaci datum oglaavanja i cena se pridruuju vezi Oglaava, u formi atributa Datum oglaavanja i Cena. Atributi pridrueni vezi se grafiki prikazuju istim simbolom kao za entitet, s tom razlikom to se pravougaonik koji sadri atribute veze sa samom vezom povezuje iscrtavanjem isprekidane linije. Prisustvo jednog ili vie atributa dodeljenih vezi moe da ukazuje na to da veza skriva neidentifikovani entitet. U spomenutom primeru, prisustvo atributa Datum oglaavanja i Cena u vezi Oglaava ukazuje na prisustvo entiteta Oglas. Strukturna ogranienja Entiteti koji uestvuju u vezi mogu imati izvesna ogranienja. Ogranienja treba da se reflektuju na veze tako da verno reprezentuju odnose iz realnog sveta, kao na primer da, u ve spomenutoj u bazi podataka agencije za prodaju i izdavanje nekretnina, svaka nekretnina mora da ima vlasnika. Osnovni tip ogranienja se naziva viestrukost. Viestrukost ograniava nain na koji se entiteti odnose jedan prema drugome i predstavlja poslovna pravila (poslovnu politiku) okruenja koje se modelira. Ve je spomenuto da je najei tip veze binarni. Binarne veze mogu biti: jedan-prema-jedan (1:1), jedan-prema-vie (1:*) ili

Oglaava

Goran Nei

11


vie-prema-vie (*:*). Sva tri tipa veza bie analizirana pomou sledeih ogranienja (poslovnih pravila) koja vae u agenciji za prodaju i izdavanje nekretnina:

Jedan od zaposlenih upravlja ekspoziturom (1:1) Jedan od zaposlenih nadgleda nekretnine (1:*) Novine oglaavaju nekretnine (*:*).

Jedan-prema-jedan (1:1) veze Razmotrimo vezu Upravlja koja spaja entitete Zaposleni i Ekspozitura.

Zaposleni Ekspozitura IdentBrZaposlenog IdentBrEkspoziture

Odreivanje viestrukosti se uglavnom vri prouavanjem veza i odnosa izmeu uzetih uzoraka podataka koji e biti u opticaju u posmatranoj sredini. Analizom navedenog primera moe se zakljuiti da jedan od zaposlenih moe da upravlja nijednom ili jednom ekspoziturom. Poto postoji maksimalno jedna ekspozitura za svakog zaposlenog koji uestvuje u ovoj vezi i maksimalno jedan zaposleni za svaku ekspozituru, ovaj tip veze se naziva jedan-prema-jedan (1:1). Da bi se grafiki prikazalo da jedan od zaposlenih moe sa upravlja nijednom ili jednom ekspoziturom, pored entiteta Ekspozitura se ispisuje 0..1. Da bi se grafiki prikazalo da ekspoziturom uvek upravlja jedan zaposleni, pored entiteta Zaposleni se ispisuje 1..1. Jedan-prema-vie (1:*) veze Razmotrimo vezu Nadgleda koja spaja entitete Zaposleni i Nekretnina.

Zaposleni Nekretnina IdentBrZaposlenog IdentBrNekretnine

Zaposleni moe da nadgleda nula ili vie nekretnina, a nekretninu moe da nadgleda nijedan ili jedan zaposleni. Dakle, za zaposlene koji uestvuju u ovoj vezi postoji vie nekretnina, a za nekretnine koje uestvuju u ovoj vezi postoji maksimalno jedan zaposleni. Ovakav tip veze se naziva jedan-prema-vie (1:*).

Upravlja

1..1 0..1

Svakom ekspoziturom upravlja jedan od zaposlenih

Jedan od zaposlenih moe da upravlja nijednom ili jednom ekspoziturom

Viestrukost

Nadgleda

0..1 0..*

Svaku nekretninu nadgleda nijedan ili jedan zaposleni

Svaki zaposleni nadgleda nula ili vie nekretnina

Goran Nei

12


Da bi se grafiki prikazalo da zaposleni moe da nadgleda nula ili vie nekretnina, pored entiteta Nekretnina se ispisuje 0..*. Da bi se grafiki prikazalo da svaku nekretninu nadgleda nijedan ili jedan zaposleni, pored entiteta Zaposleni se ispisuje 0..1. Ako se zna tana vrednost za viestrukost, umesto * se moe napisati taj broj, na primer (0..100). Vie-prema-vie (*:*) veze Razmotrimo vezu Oglaava koja spaja entitete Novine i Nekretnina.

Novine Nekretnina Naziv novina IdentBrNekretnine

Jedne novine oglaavaju jednu ili vie nekretnina, a jedna nekretnina se oglaava u jednim ili nijednim novinama. Dakle, za novine postoji vie nekretnina, a za svaku nekretninu koja uestvuje u ovoj vezi postoji vie novina. Ovakav tip veze se naziva vie-prema-vie (*:*). Da bi se grafiki prikazalo da svake novine mogu da oglaavaju jednu ili vie nekretnina, pored entiteta Nekretnina se ispisuje 1.. *. Da bi se grafiki prikazalo da svaka nekretnina moe da se oglaava u nula ili vie novina, pored entiteta Novine se ispisuje 0.. *. Kardinalnost i participacija (uee) Viestrukost se zapravo sastoji iz dva zasebna ogranienja poznata kao kardinalnost i participacija (uee). Kardinalnost odreuje maksimalni broj moguih primeraka entiteta za entitet koji uestvuje u datoj vezi. Participacija (uee) odreuje da li u vezi uestvuju svi primerci entiteta ili samo neki od njih. U sluaju da u vezi uestvuju svi primerci entiteta, radi se o obaveznoj participaciji, dok se u sluaju da u vezi uestvuju samo neki od primeraka entiteta radi o opcionoj participaciji.

Kardinalnost

Zaposleni Ekspozitura IdentBrZaposlenog IdentBrEkspoziture

Participacija

Oglaava

0.. * 1..*

Svaka nekretnina se oglaava u nula ili vie novina

Svake novine oglaavaju jednu ili vie nekretnina

Upravlja

1..1 0..1

Jednom ekspoziturom upravlja jedan od zaposlenih

Jedan od zaposlenih upravlja jednom ekspoziturom

Svim ekspoziturama se upravlja (obavezna participacija za ekspozituru)

Ne upravljaju svi zaposleni ekspoziturama (opciona participacija za zaposlene)

Goran Nei

13


NORMALIZACIJA Glavni cilj u procesu razvoja baze podataka je da se kreira sistem koji verno reprezentuje podatke, njihove veze i odnose, kao i ogranienja. Da bi se postigao ovaj cilj, moraju se pravilno uoiti odgovarajue tabele, a metoda koja se za to koristi naziva se normalizacija. Normalizacija je tehnika za kreiranje tabela sa odgovarajuim svojstvima, uzimajui u obzir zahteve okruenja za ije potrebe se projektuje baza. Normalizacija se esto realizuje tako to se vri serija testova nad tabelom da bi se utvrdilo da li ona zadovoljava zahteve odreene normalne forme ili ne. Inicijalno su promovisane tri normalne forme, prva (1NF), druga (2NF) i trea (3NF) normalna forma. Kasnije su R.Boyce i E.F.Codd promovisali strou definiciju tree normalne forme koja se naziva Boyce-Codd normalna forma (BCNF). Sve normalne forme se baziraju na funkcionalnim zavisnostima izmeu atributa tabele. Promovisane su i vie normalne forme koje prevazilaze BCNF, i to su etvrta (4NF) i peta (5NF) normalna forma. Ipak, ove forme se bave situacijama koje su vrlo retke. Normalizacija omoguava projektantu baze da izvri optimalno grupisanje atributa po tabelama. Proces normalizacije identifikuje tabele na osnovu primarnih kljueva ili kljueva kandidata i na osnovu funkcionalnih zavisnosti koje postoje izmeu atributa. Normalizacija sadri pravila koja se mogu upotrebiti za testiranje tabela, tako da baza moe da se normalizuje do bilo kog stepena. Tabela koja ne ispunjava zahteve normalizacije mora se rastaviti na dve ili vie tabela od kojih svaka pojedinano ispunjava zahteve normalizacije. Vano je napomenuti da je za kreiranje tabela u relacionom modelu podataka kritina samo 1NF. Sve ostale forme su opcione. Ipak, da bi se izbegle anomalije auriranja (objanjene u sledeem pasusu), preporuuje se normalizacija najmanje do 3NF. Redundantnost (ponavljanje) podataka i anomalije auriranja Jedan od najvanijih ciljeva prilikom projektovanja relacione baze podataka je pravilno grupisanje atributa po tabelama, to rezultuje minimalnim ponavljanjem podataka i smanjenjem prostora potrebnog za skladitenje fajlova u kojima se uvaju podaci. Ponavljanje podataka je pojava da se isti podaci koji se odnose na neki entitet nepotrebno pojavljuju u dve ili vie tabela. U tabelama koje sadre podatke koji se ponavljaju mogu da se jave problemi poznati kao anomalije auriranja. Anomalije auriranja mogu biti anomalije unosa, anomalije brisanja ili anomalije promene podataka. Anomalije unosa podataka Anomalije unosa se manifestuju na dva naina:

1. Prilikom unosa novih podataka koji se odnose na jedan entitet, u tabelu koja sadri podatke koji se ponavljaju moraju se uneti i podaci koji se odnose na druge entitete iji se podaci nalaze u istoj tabeli, to moe dovesti do nekonzistentnosti ako se naini greka prilikom unosa.

2. Prilikom unosa novih podataka koji se odnose na jedan entitet, u tabelu koja sadri

podatke koji se ponavljaju se u nekim situacijama mora uneti vrednost null u polja za koja ne postoji vrednost. Ako se desi da je ba to polje primarni klju za tu tabelu, unos takvog zapisa mora biti spreen, jer bi inae naruio integritet entiteta.

Goran Nei

14


Anomalije brisanja podataka Brisanje poslednjeg zapisa koji se odnosi na jedan entitet iz tabele koja sadri podatke koji se ponavljaju moe dovesti do kompletnog gubitka podataka o drugom entitetu iji se podaci nalaze u istoj tabeli, u istom zapisu. Anomalije promene podataka Prilikom promene vrednosti atributa koji se odnosi na jedan entitet, u tabeli koja sadri podatke koji se ponavljaju moraju se promeniti i svi zapisi koji sadre taj promenjeni atribut, kao i podaci koji se odnose na druge entitete, a koji stoje u direktnoj vezi sa promenjenim atributom. Ako se ne izvre sve ove promene, baza postaje nekonzistentna. Funkcionalna zavisnost Funkcionalna zavisnost opisuje odnose izmeu atributa u tabeli i predstavlja jedan od glavnih koncepata vezanih za normalizaciju. Osnovni razlog zbog koga se pristupa definisanju funkcionalnih zavisnosti za tabelu je potreba odreivanja ogranienja za ouvanje integriteta (integrity constraints). Verovatno najvanije ogranienje za ouvanje integriteta je uoavanje kljueva kandidata, od kojih se jedan bira za primarni klju tabele. U procesu njihovog definisanja, naroito je znaajno pronai one funkcionalne zavisnosti koje vae za sve mogue vrednosti atributa jedne tabele, jer one predstavljaju tipove ogranienja za ouvanje integriteta. Tipovi ogranienja za ouvanje integriteta definiu vrednosti koje tabela moe legitimno da primi. Takoe je znaajno ignorisati tzv. trivijalne funkcionalne zavisnosti, jer za njih vai da su uvek zadovoljene, pa stoga nisu od znaaja. Prva normalna forma (1NF) Pre diskusije o 1NF, najpre treba definisati stanje pre 1NF. Tabela koja sadri podatke koji se ponavljaju nalazi se u nenormalizovanoj formi (NNF) i naziva se nenormalizovana tabela. Tabela je u 1NF ako presek svakog njenog reda i kolone sadri jednu i samo jednu vrednost. Da bi se nenormalizovana tabela transformisala u 1NF, moraju se identifikovati i ukloniti podaci koji se ponavljaju. Postoje dva uobiajena pristupa za uklanjanje podataka koji se ponavljaju iz nenormalizovanih tabela:

1. Po prvom pristupu, odgovarajui podaci se ubacuju u prazne kolone redova koji sadre podatke koji se ponavljaju. Drugim reima, tamo gde je to potrebno, prazna polja se popunjavaju dupliranim podacima koji se ne ponavljaju. Rezultujua tabela sadri atomine (pojedinane) vrednosti u preseku svakog reda i kolone, pa je stoga u 1NF. Dakle, u ovom postupku se u tabelu namerno unose podaci koji se ponavljaju, a oni se tokom sledeih, viih faza procesa normalizacije uklanjaju iz tabele.

2. Po drugom pristupu, podaci koji se ponavljaju se, zajedno sa kopijom originalne

vrednosti atributa kljua (ili originalne vrednosti vie atributa kljueva), izmetaju u posebnu tabelu. Za novu tabelu se definie primarni klju. Ponekad nenormalizovana tabela sadri vie od jedne grupe podataka koji se ponavljaju ili ak grupe unutar grupe. U takvim sluajevima postupak izmetanja se ponavlja sve dok se ne ukloni i

Goran Nei

15


poslednja grupa podataka koji se ponavljaju. Za grupu tabela se kae da je u 1NF ako ne sadre podatke koji se ponavljaju.

Oba pristupa su ispravna, mada drugi pristup direktno daje tabele koje su u najmanje 1NF. I prvi pristup daje tabele koje su u 1NF, ali koje se tek u kasnijim fazama normalizacije razlau na iste one tabele koje nastaju kao rezultat primene drugog pristupa. Dakle, moe se zakljuiti da je drugi pristup direktniji i praktiniji. Druga normalna forma (2NF) Druga normalna forma se bazira na konceptu potpune funkcionalne zavisnosti, koja e najpre biti definisana. Potpuna funkcionalna zavisnost Funkcionalna zavisnost AB (ita se B je funkcionalno zavisno od A) je potpuna funkcionalna zavisnost ako uklanjanje bilo kog atributa iz A rezultuje time to zavisnost prestaje da vai, pri emu su A i B atributi tabele i A je determinanta od B. Funkcionalna zavisnost AB je delimino zavisna ako postoje neki atributi koji se mogu ukloniti iz A, a zavisnost i dalje vai. Determinanta je atribut ili grupa atributa od kojih je neki drugi atribut potpuno funkcionalno zavisan. Definicija druge normalne forme Druga normalna forma se odnosi na tabele sa sloenim kljuevima, tj. tabele iji se primarni kljuevi sastoje iz dva ili vie atributa. Tabela iji primarni klju sadri samo jedan atribut je automatski u najmanje 2NF. U tabeli koja nije u 2NF mogu da se pojave anomalije auriranja. Tabela je u 2NF ako je u 1NF i ako je svaki atribut koji nije primarni klju potpuno funkcionalno zavisan od primarnog kljua. Normalizacija tabele iz 1NF u 2NF se vri uklanjanjem deliminih zavisnosti, tj. funkcionalno zavisni atributi se izmetaju u novu tabelu zajedno sa kopijom njihovih determinanti (kljueva). Trea normalna forma (3NF) ak iako je u 2NF, u tabeli mogu da se pojave anomalije auriranja zbog tranzitivnih zavisnosti, koje se moraju ukloniti iz tabele postupkom normalizacije do 3NF. Tranzitivna zavisnost Tranzitivna zavisnost je stanje u kome su A, B i C atributi tabele takvi da, ako AB (B je funkcionalno zavisno od A) i BC (C je funkcionalno zavisno od B), onda je C tranzitivno zavisno od A preko B (pod uslovom da A nije funkcionalno zavisno od B ili C).

Goran Nei

16


Definicija tree normalne forme Tabela je u 3NF ako je u 1NF i u 2NF i ako u njoj ne postoje atributi ne-primarni-kljuevi koji su tranzitivno zavisni od primarnog kljua. Normalizacija tabela iz 2NF u 3NF se vri uklanjanjem tranzitivnih zavisnosti, tj. tranzitivno zavisni atributi se izmetaju u novu tabelu zajedno sa kopijom njihovih determinanti (kljueva). Boyce-Codd normalna forma (BCNF) Druga i trea normalna forma eliminiu delimine i tranzitivne zavisnosti za primarne kljueve, ali one ne razmatraju da li takve zavisnosti postoje i za kljueve kandidate, ako ih ima u tabeli. Dakle, i u 3NF mogu da postoje delimine i tranzitivne zavisnosti za kljueve kandidate, pa je stoga promovisana stroa normalna forma poznata kao Boyce-Codd normalna forma (BCNF). BCNF se bazira na funkcionalnim zavisnostima koje uzimaju u obzir sve kljueve kandidate u tabeli, a sadri i jo neka ogranienja u poreenju sa 3NF. Tabela je u BCNF ako i samo ako je svaka determinanta klju kandidat. Da bi se odredilo da li je tabela u BCNF, potrebno je uoiti determinante i proveriti da li su sve one kljuevi kandidati. Potsetiemo se da je determinanta atribut ili grupa atributa od kojih je neki drugi atribut potpuno funkcionalno zavisan. Razlika izmeu 3NF i BCNF je u tome to 3NF dozvoljava funkcionalnu zavisnost AB (B je funkcionalno zavisno od A) ako je B primarni klju a A nije klju kandidat, dok BCNF nalae da A mora biti klju kandidat. Dakle, BCNF je jaa forma od 3NF, pa je svaka tabela koja je u BCNF automatski i u 3NF, a obratno ne vai. Tabela se transformie u BCNF tako to se vri njena dekompozicija na dve ili vie novih tabela. Meutim, ponekad nije poeljno normalizovati tabelu do BCNF. Naime, moe se desiti da se prilikom dekompozicije tabele izgubi jedna ili vie funkcionalnih zavisnosti zbog toga to se determinanta i od nje zavisni atributi izmeste u razliite tabele. U ovakvoj situaciji treba proceniti da li je bolje stati kod 3NF, koja uvek uva sve funkcionalne zavisnosti. Odluku da li normalizovati tabelu do BCNF ili stati kod 3NF treba doneti na osnovu sledee analize:

Da li e znaajni podaci biti izgubljeni u sluaju dekompozicije tabele i gubitka jedne ili vie funkcionalnih zavisnosti

Kolika e biti koliina redundantnih podataka (podataka koji se ponavljaju) u sluaju

da se dekompozicija ne izvri, tj. da se ostane na 3NF. etvrta normalna forma (4NF) Iako BCNF eliminie sve anomalije koje proistiu iz funkcionalnih zavisnosti, dalja istraivanja su dovela do uoavanja jo jednog tipa zavisnosti koji se naziva zavisnost viestruke vrednosti koji takoe moe da prouzrokuje redundatnost podataka.

Goran Nei

17


Zavisnost viestruke vrednosti Pojava zavisnosti viestruke vrednosti u tabeli moe da se desi zbog 1NF koja ne dozvoljava da atribut ima vie vrednosti, tj. da se sastoji iz vie podataka. Zavisnost viestruke vrednosti bie objanjana na primeru tabele EkspozituraZaposleniVlasnik iz baze podataka agencije za prodaju i izdavanje nekretnina.

IdentBrEkspoziture ImeZaposlenog ImeVlasnikaNekretnine

B003 Zoran Petrovi Jelena Jankovi

B003 Miodrag Aleksi Jelena Jankovi

B003 Zoran Petrovi Predrag Stefanovi

B003 Miodrag Aleksi Predrag Stefanovi

Tabela EkspozituraZaposleniVlasnik

U ovom primeru zaposleni Zoran Petrovi i Miodrag Aleksi rade u ekspozituri B003, a vlasnici nekretnina Jelena Jankovi i Predrag Stefanovi su registrovani u istoj ekspozituri, dakle B003. Poto ne postoji direktna veza izmeu zaposlenih i vlasnika u datoj ekspozituri, mora se kreirati zapis za sve kombinacije zaposlenih i vlasnika da bi se obezbedila konzistentnost. Ova situacija predstavlja zavisnost viestruke vrednosti u tabeli EkspozituraZaposleniVlasnik. Drugim reima, zavisnost postoji zato to su u tabeli predstavljene dve nezavisne 1:* veze. Zavisnost viestruke vrednosti predstavlja zavisnost izmeu atributa A, B i C u tabeli, takvu da za svaku vrednost A postoji vie vrednosti B i vie vrednosti C, pri emu su vrednosti B i C nezavisne jedna od druge. Definicija etvrte normalne forme Tabela je u 4NF ako je u BCNF i ako ne sadri zavisnosti viestruke vrednosti. 4NF je jaa normalna forma od BCNF, jer ne dozvoljava da tabele imaju zavisnost viestruke vrednosti, a samim tim i redundantne podatke (podatke koji se ponavljaju). Normalizacija iz BCNF u 4NF se vri dekompozicijom tabele i izmetanjem atributa zajedno sa njihovim determinantama u novu tabelu. Tabela EkspozituraZaposleniVlasnik iz prethodnog pasusa se dekomponuje na tabele EkspozituraZaposleni i EkspozituraVlasnik.

IdentBrEkspoziture ImeZaposlenog

B003 Zoran Petrovi

B003 Miodrag Aleksi

Tabela EkspozituraZaposleni

IdentBrEkspoziture ImeVlasnikaNekretnine B003 Jelena Jankovi B003 Predrag Stefanovi

Tabela EkspozituraVlasnik

4NF eliminie redundantnost podataka (podatke koji se ponavljaju) i mogunost pojave anomalija auriranja.

Goran Nei

18


Peta normalna forma (5NF) Uvek kada se vri dekompozicija tabele na dve nove, rezultujue tabele imaju svojstvo poznato kao postojanost spajanja (lossless-join). Ovo svojstvo se odnosi na injenicu da se tabele nastale dekompozicijom mogu ponovo spojiti u originalnu tabelu. Meutim, postoje sluajevi kada je potrebno izvriti dekompoziciju originalne tabele na vie od dve nove tabele. Iako se u praksi prilino retko sreu, ovakvi sluejevi se reavaju primenom pete normalne forme (5NF). Postojanost spajanja (lossless-join) Postojanost spajanja je svojstvo dekompozicije koje omoguava da se, prilikom ponovnog spajanja tabela, generiu samo originalni podaci. Dakle, postojanost spajanja osigurava da se, prilikom ponovnog spajanja dve tabele u onu ijom su dekompozicijom nastale, generiu samo oni podaci koji su postojali u originalnoj tabeli pre dekompozicije, to znai da je zagarantovana potpuna rekonstrukcija originalne tabele. Definicija pete normalne forme Tabela je u 5NF ako nema zavisnosti spajanja. Normalizacija do 5NF se vri dekompozicijom tabele u kojoj se uoe zavisnosti spajanja na vie od dve nove tabele. Vano je napomenuti da e ponovno spajanje bilo koje dve od novonastalih tabela generisati "lane" podatke, ali e zato ponovno spajanje svih novonastalih tabela verno rekonstruisati originalnu tabelu.

Goran Nei

19


METODOLOGIJA DIZAJNIRANJA BAZE PODATAKA Metodologija dizajniranja je strukturirani pristup koji primenjuje procedure, tehnike, alate i dokumentaciju u procesu razvoja baze podataka. U procesu razvoja baze podataka definisane su tri osnovne faze, od kojih svaka sadri niz koraka. Konceptualni dizajn Konceptualni dizajn predstavlja prvu fazu tokom koje se kreira konceptualni model podataka na osnovu korisnike specifikacije zahteva. Konceptualni dizajn baze je potpuno nezavisan od detalja implementacije kao to su na primer softverska platforma, programski jezici, hardverska platforma ili bilo koji drugi fiziki aspekti. Konceptualni dizajn se sastoji iz sledeih koraka (po hronolokom redosledu):

1. Identifikovati entitete 2. Identifikovati veze 3. Identifikovati atribute i pridruiti ih entitetima i vezama 4. Odrediti domene atributa 5. Odrediti kljueve kandidate i primarne kljueve 6. Proveriti da li u modelu postoji redundansa 7. Proveriti da li model zadovoljava potrebe korisnikih transakcija 8. Po potrebi revidirati model zajedno sa korisnicima.

Logiki dizajn Logiki dizajn predstavlja drugu fazu u dizajniranju baze podataka i podrazumeva kreiranje modela koji se bazira na konceptualnom modelu iz prethodne faze. Model iz prethodne faze se dorauje i prilagoava konanom modelu koji je usvojen za bazu (npr. relacioni model). Dakle, logiki model se kreira namenski, za tano odreeni model podataka koji koristi izabrana DBMS platforma. Kao rezultat se dobija model koji je nezavisan od fizikih detalja DBMS, kao na primer strukture podataka i indeksa. Za testiranje korektnosti logikog modela koristi se tehnika normalizacije koja obezbeuje da podaci budu pravilno rasporeeni po tabelama. Logiki dizajn se sastoji iz sledeih koraka (po hronolokom redosledu):

1. Kreirati tabele 2. Izvriti normalizaciju tabela 3. Proveriti da li tabele zadovoljavaju potrebe korisnikih transakcija 4. Definisati ogranienja za ouvanje integriteta (integrity constraints) 5. Razmotriti ekspanziju sistema u budunosti 6. Po potrebi revidirati model zajedno sa korisnicima.

Goran Nei

20


Fiziki dizajn Fiziki dizajn je trea i poslednja faza u procesu dizajniranja baze podataka. Ova faza podrazumeva kreiranje elemenata baze na tano odreenoj platformi sa svim detaljima i specifinostima vezanim za nju. Treba spomenuti i to, da ova faza moe izazvati povratni efekat na prethodnu, jer neki specifini detalji vezani za fiziki dizajn na izabranoj platformi mogu da izazovu promene u logikom dizajnu. Dakle, fiziki dizajn se odnosi na konkretnu implementaciju na izabranoj DBMS platformi i sastoji se iz sledeih koraka (po hronolokom redosledu):

1. Kreirati tabele 2. Kreirati ogranienja (constraints) koja reprezentuju poslovna pravila (business rules) 3. Analizirati transakcije i njihov uticaj na performanse sistema 4. Izabrati organizaciju fajlova (npr. heap, hash, B+-drvo, klasteri) 5. Kreirati indekse 6. Izvriti procenu potrebnog prostora za skladitenje podataka 7. Kreirati "korisnike preglede" (user views) 8. Realizovati bezbednosne mehanizme 9. Razmotriti uvoenje kontrolisane redundanse u cilju poboljanja performansi sistema.

Goran Nei

21


2. Baza podataka MAGACIN predstavlja efikasno softversko reenje za voenje evidencije o sredstvima za rad, opremi, potronom materijalu i jo nekim vrstama imovine jedne ustanove ili firme. Baza je originalno razvijena za potrebe ustanove u kojoj se oprema i imovina izdaju zaposlenima na korienje, a oni ih upotrebljavaju u svakodnevnom radu, kao osnovno ili pomono sredstvo. Razvoj baze MAGACIN bie predstavljen hronoloki, kroz faze. I faza: PLANIRANJE Zadatak: Glavni zadatak ove faze je definisanje ciljeva koje baza podataka treba da ispuni. Kao to je u uvodu u ovo poglavlje ve spomenuto, baza treba da omogui voenje evidencije o sredstvima za rad, opremi i potronom materijalu u jednoj ustanovi ili firmi. U ustanovi za ije potrebe je baza razvijena javila se potreba za voenjem precizne i aurne evidencije o tome koja su sredstva, oprema, nametaj i druge vrste imovine izdati na korienje svakom od zaposlenih. Takoe je bilo potrebno omoguiti magacioneru voenje evidencije o potronom materijalu u smislu koliina koje su izdate i preostalih koliina na lageru, kao i tampanje odgovarajuih vrsta dokumenata i izvetaja. II faza: DEFINICIJA SISTEMA Zadatak: U okviru druge faze potrebno je identifikovati opseg i granice baze, nain na koji e se ona uklopiti u informacioni sistem posmatranog okruenja, ako on ve postoji, kao i definisati glavne korisnike baze. Pod pojmom opsega i granica baze podrazumeva se definisanje korisnika i vrste podataka sa kojima e baza raditi. Korisnici mogu biti pojedinane osobe ili manje organizacione jedinice okruenja za ije potrebe se razvija baza (odeljenja, odseci, itd.). U sluaju baze MAGACIN realizacija ove faze je bila jednostavna, jer se kao potencijalni korisnik javlja samo magacioner, a vrsta podataka kojima on barata je praktino definisana tokom prve faze, dakle radi se o podacima vazanim za sredstva, opremu i imovinu. III faza: PRIKUPLJANJE I ANALIZA ZAHTEVA Zadatak: Prikupljanje i analiza informacija o okruenju za ije potrebe se baza razvija i izrada specifikacije zahteva iz koje e proistei funkcionalnost baze podataka.

Baza podataka Magacin

Goran Nei

22


Za prikupljanje i analizu zahteva tokom ove faze koriene su tehnike intervjuisanje, posmatranje rada u okruenju za ije potrebe se razvija baza i prouavanje dokumentacije. Intervjuisanje je obavljeno sa magacionerom, od koga su prikupljene informacije o metodologiji rada, najvanijim aktivnostima koje obavlja tokom rada (konkretno o vrstama aktivnosti i njihovom hronolokom redosledu), vrsti podataka kojima barata, eljenom nainu obrade i prezentacije podataka. Posmatranje rada u okruenju za ije potrebe se razvija baza je tehnika koja je primenjena u kombinaciji sa intervjuisanjem i koja je pomogla da se stekne konkretniji uvid u proces rada koga je potrebno modelirati. Prouavanje dokumentacije je tehnika koja je u sluaju baze MAGACIN primenjena kroz prouavanje dokumenata koji se pojavljuju u posmatranom procesu rada. Predmet prouavanja je bila struktura i forma dokumenata koji slue za evidentiranje unosa novih stavki u magacin (Trebovanje), za izdavanje sredstava (Revers) i za povraaj sredstava u magacin (Povratnica). To je pomoglo u uoavanju i definisanju potencijalnih atributa za entitete koji e se nai u bazi. Primenom spomenutih tehnika izraena je studija na osnovu koje se mogu jasno definisati biznis model posmatranog okruenja i specifikacija zahteva. Studija Potrebno je razviti bazu podataka za potrebe ustanove u kojoj se oprema i imovina izdaju zaposlenima na korienje, a oni ih upotrebljavaju u svakodnevnom radu, kao osnovno ili pomono sredstvo. Ustanova ima pedesetak zaposlenih, a ukupan broj komada sredstava, opreme i ostale raspoloive imovine ne prelazi hiljadu. Imovina je podeljena na nekoliko jasno definisanih kategorija, kao to su na primer nametaj, informatika oprema, mobilni telefoni, itd. Postoji samo jedan potencijalni korisnik baze magacioner, koji obavlja i unos sredstava u magacin i izdavanje sredstava i opreme zaposlenima. Pored evidencije u lokalnom magacinu ustanove za ije potrebe se razvija baza, sva sredstva moraju biti evidentirana i u centralnom magacinu, koji je hijerarhijski nadreen lokalnom. Svako sredstvo (osim potronog i kancelarijskog materijala) mora da ima inventarski broj, a za sva sredstva koja imaju fabriki broj i on se evidentira. U lokalni magacin sredstva stiu direktno od dobavljaa, a unos se vri odmah po prijemu, stavku po stavku. U tom trenutku ni jedno sredstvo nema inventarski broj koji se dodeljuje od strane centralnog magacina. Zato se za svaku nabavku formira pisani dokument Trebovanje, koji ima viestruku ulogu: na osnovu njega centralni magacin vri dodelu inventarskog broja svakom sredstvu, za centralni magacin ono predstavlja dokument na osnovu koga se sredstva izdaju lokalnom magacinu, a za lokalni magacin trebovanje predstavlja dokument na osnovu koga sredstva ulaze u magacin. Izdavanje sredstava i opreme zaposlenima od strane lokalnog magacina se vri putem pisanog dokumenta Revers, koji sadri jednu ili vie stavki, za svako sredstvo ili komad opreme koji se izdaje. Svakom zaposlenom moe da se izda neogranien broj reversa. Povraaj sredstava i opreme od strane zaposlenih u magacin se vri pomou pisanog dokumenta Povratnica, koji sadri stavke koje zaposleni razduuje. Mogue situacije su da zaposleni vraa deo zaduenih sredstava ili da se kompletno razduuje. Magacioner je u obavezi da povremeno vri pregled stanja imovine u smislu kod kog zaposlenog se nalazi odreeno sredstvo ili oprema, a jedanput godinje vri popis kompletne imovine sa stanjem. O potronom i kancelarijskom materijalu nije potrebno voditi posebno preciznu evidenciju, osim orijentacionog stanja koliina na lageru.

Goran Nei

23


IV faza: DIZAJNIRANJE BAZE Zadatak: Izrada konceptualnog, logikog i fizikog modela baze podataka. Kao rezultat projektovanja konceptualnog i logikog modela nastao je relacioni dijagram baze prikazan na slici.

Relacioni dijagram baze Magacin Entiteti U okruenju ustanove za ije potrebe se razvija baza uoeni su sledei entiteti: 1. Zaposleni, koji reprezentuje sve radnike zaposlene u posmatranoj ustanovi. 2. Ulaz/Izlaz, koji reprezentuje pisana dokumenta Trebovanje, Revers i Povratnica koja se

izdaju prilikom unosa sredstava u magacin, prilikom izdavanja sredstava i opreme zaposlenima i prilikom povraaja sredstava u magacin, respektivno.

3. Ulaz/Izlaz-stavke, koji reprezentuje stavke dokumenta Ulaz/Izlaz. Entiteti Ulaz/Izlaz i

Ulaz/Izlaz-stavke bi, generalno gledano, mogli da budu objedinjeni u jedan entitet, npr. Dokument, ali bi se u tom entitetu pojavila velika redundansa podataka, tj. entitet bi sadrao mnogo podataka koji se ponavljaju iz razloga to bi bio normalizovan samo do 1NF.

Zaposleni

Ime i prezime {PK} Organizaciona jedinica Lokal Mobilni

Ulaz/Izlaz

PKID {PK} Zaposleni {FK} Datum Tip dokumenta {FK} Broj dokumenta Izdao/Primio

Tip dokumenta

Tip {PK}

Sredstvo

PKID Sredstva {PK} Naziv sredstva ifra sredstva Kategorija sredstva {FK} Inventarski broj Fabriki broj Opis sredstva Jedinica mere Poetno stanje Status

Kategorija sredstva

Kategorija {PK}

Ulaz/Izlaz-stavke

PKID Ulaz/Izlaz {PK, FK} PKID Sredstva {PK, FK} Ulaz Izlaz

Odreuje

Opisuje

Sadri Izdaje se

Prikazuje se

Izdaje sredstvo

0..1 0..*

1..1

1..*

1..1 1..*

0..*

1..1

1..* 1..1

1..1 0..*

Goran Nei

24


4. Sredstvo, koji reprezentuje sredstva za rad, opremu i svu ostalu imovinu ustanove. 5. Tip dokumenta, koji odreuje da li se radi o Trebovanju, Reversu ili Povratnici. U teoriji

baza podataka ovaj entitet bi se svrstao u grupu slabih entiteta. Entiteti ije postojanje zavisi od postojanja drugih entiteta nazivaju se slabim entitetima. Entitet Tip dokumenta zavisi od entiteta Ulaz/Izlaz, jer ako ne postoji ulazno/izlazni dokument, ne postoji ni tip dokumenta.

6. Kategorija sredstva, koji blie opisuje komad imovine tako to ga svrstava u neku od

postojeih kategorija. I Kategorija sredstva spada u grupu slabih entiteta, jer je zavisan od entiteta Sredstvo.

Za svaki od navedenih entiteta definisani su odgovarajui atributi i domeni atributa, gde je to bilo potrebno (npr.Tip dokumenta i Kategorija sredstva). Zatim je izvren izbor primarnih kljueva, pri emu posebno objanjenje zasluuju samo kljuevi entiteta Zaposleni, Sredstvo i Ulaz/Izlaz-stavke. Primarni kljuevi Primarni klju entiteta Zaposleni. Iako, generalno gledano, Ime i prezime nije idealan atribut za primarni klju zbog toga to se mogu pojaviti osobe sa istim imenom i prezimenom, on je ipak odreen za primarni klju zbog toga to u posmatranom okruenju ima samo pedesetak zaposlenih i, u trenutku projektovanja baze, nisu postojale osobe sa istim imenom i prezimenom. Uz malu verovatnou za znaajnije poveanje broja zaposlenih u skorijoj budunosti, izgledi za pojavu osoba sa istim imenom i prezimenom su mali. ak iako se takav problem javi, ne bi bilo isuvie komplikovano dodati srednje slovo i na taj nain zadovoljiti kriterijum jedinstvenosti. Primarni klju entiteta Sredstvo. Za entitet Sredstvo uoeni su kljuevi kandidati Naziv sredstva, Fabriki broj i Inventarski broj. U studiji je spomenuto da se inventarski broj dodeljuje sredstvu naknadno, esto i posle unoenja u bazu. Zbog toga on nije izabran za primarni klju. Intervjuisanjem magacionera dolo se do saznanja da mnoga sredstva nemaju fabriki broj, pa je i on proglaen neodgovarajuim kandidatom. Naziv sredstva takoe nije u potpunosti zadovoljio, jer se moe javiti vie sredstava sa istim nazivom. Taj problem bi se mogao reiti formiranjem sloenog primarnog kljua (npr. Naziv sredstva, Inventarski broj i Fabriki broj) ali se, zbog spomenutih problema sa inventarskim i fabrikim brojem, i od toga odustalo. Konano, kao primarni klju je odreen automatski generisani broj koji obezbeuje jedinstvenost zapisa, bez obzira na to da li u trenutku unoenja u bazu sredstvo ima inventarski i/ili fabriki broj i bez obzira na naziv sredstva. Primarni klju entiteta Ulaz/Izlaz-stavke. Entitet Ulaz/Izlaz-stavke ima sloeni primarni klju koji se sastoji iz dva atributa: PKID_Ulaz/Izlaz i PKID_Sredstva. Ovakvo reenje je primenjeno zbog toga to je trebalo obezbediti da se jedno sredstvo moe pojaviti samo jedanput u jednom dokumentu (Revers, Trebovanje ili Povratnica). Poto e se atribut PKID_Sredstva sigurno pojaviti vie puta u tabeli Ulaz/Izlaz-stavke, a atribut PKID_Ulaz/Izlaz je isti za svaku stavku jednog dokumenta, jedini nain da se realizuje jedinstvenost svakog zapisa u tabeli Ulaz/Izlaz-stavke je da se formira sloeni klju, poto atributi PKID_Ulaz/Izlaz i PKID_Sredstva u kombinaciji formiraju jedinstvenu vrednost koja jednoznano identifikuje svaki zapis u tabeli, pod uslovom da se obezbedi da atribut PKID_Ulaz/Izlaz bude jedinstven za svaki dokument koga reprezentuje.

Goran Nei

25


Veze U modelu baze MAGACIN definisane su sledee veze: 1. Izdaje sredstvo, koja spada u grupu rekurzivnih ili unarnih veza i predstavlja odnos

entiteta Zaposleni sa samim sobom. Veza je tipa 1:*, i u njoj entitet Zaposleni uestvuje u dve uloge: u ulozi magacionera koji izdaje sredstva radnicima ustanove, i u ulozi "obinog" zaposlenog kome se izdaje sredstvo. Sa aspekta magacionera, on izdaje sredstvo nijednom zaposlenom ili vie zaposlenih (0..*), a sa aspekta "obinog" zaposlenog sredstvo se uvek izdaje od strane jednog magacionera (1..1). Dakle, u ulozi magacionera participacija entiteta Zaposleni je opciona (0), jer nije obavezno da se svakom zaposlenom izda neko sredstvo, a kardinalnost je vie (*), jer se sredstva mogu izdati neogranienom broju zaposlenih. Preciznije reeno, umesto * mogao bi se upisati broj zaposlenih (npr. 50), jer je to maksimalni broj osoba kojima se mogu izdavati sredstva. U ulozi "obinog" zaposlenog participacija entiteta Zaposleni je obavezna (1), jer se izdavanje sredstva ne moe obaviti bez magacionera. Kardinalnost u ovom sluaju iznosi 1, jer u ustanovi postoji samo jedan magacioner.

2. Izdaje se, koja predstavlja odnos izmeu entiteta Zaposleni i Ulaz/Izlaz. Veza je tipa

1:* i njome se realizuje poslovno pravilo ustanove da se, prilikom izdavanja ili prijema sredstava, opreme ili neke druge vrste imovine, zaposlenom izdaje odgovarajui ulazno/izlazni dokument (predstavljen entitetom Ulaz/Izlaz) koji opisuje odgovarajuu radnju. Sa aspekta zaposlenog, njemu se izdaje nijedan ili vie dokumenata (0..*), a sa aspekta ulazno/izlaznog dokumenta, on se izdaje nijednom ili jednom zaposlenom, tj. dokument moe da glasi na samo jednog zaposlenog (0..1). Dakle, participacija entiteta Zaposleni je opciona (0), jer nije obavezno da se svakom zaposlenom izda neko sredstvo, a samim tim i dokument. Kardinalnost entiteta Zaposleni je vie (*), jer se zaposlenom moe izdati neogranieno mnogo dokumenata. Participacija entiteta Ulaz/Izlaz je takoe opciona (0), jer se ne mora svakom zaposlenom izdati dokument, a kardinalnost je 1 zato to dokument moe da glasi na samo jednog zaposlenog.

3. Sadri, koja predstavlja odnos izmeu entiteta Ulaz/Izlaz i Ulaz/Izlaz-stavke. Veza je tipa

1:*, i govori o tome da se na jednom ulazno/izlaznom dokumentu moe nai jedna ili vie stavki. Sa aspekta dokumenta, on moe da sadri jednu ili vie stavki (1..*), a sa aspekta stavke, ona se moe pojaviti samo jedanput u jednom dokumentu (1..1). Dakle, participacija entiteta Ulaz/Izlaz je obavezna (1), jer mora postojati dokument koji e sadrati stavke, dok je kardinalnost vie (*), jer jedan dokument moe sadrati vie stavki. Participacija entiteta Ulaz/Izlaz-stavke je obavezna (1), jer na dokumentu mora postojati bar jedna stavka, a kardinalnost je 1, jer se jedna stavka sme pojaviti samo jedanput u jednom dokumentu.

4. Odreuje, koja predstavlja odnos izmeu entiteta Tip dokumenta i Ulaz/Izlaz. Veza je

tipa 1:*, i odreuje tip ulazno/izlaznog dokumenta. Sa aspekta tipa dokumenta, on odreuje jedan ili vie dokumenata (1..*), a sa aspekta ulazno/izlaznog dokumenta, on je uvek odreen samo jednim tipom dokumenta (1..1). Dakle, participacija entiteta Tip dokumenta je obavezna (1), jer za svaki dokument mora da se navede tip, dok je kardinalnost vie (*), jer jedan tip moe da se navede za neogranieno mnogo dokumenata. Participacija entiteta Ulaz/Izlaz je obavezna (1), jer bez ulazno/izlaznog dokumenta tip dokumenta nema nikakav smisao, a kardinalnost je 1, jer jednom dokumentu moe da se dodeli samo jedan tip.

Goran Nei

26


5. Opisuje, koja predstavlja odnos izmeu entiteta Kategorija sredstva i Sredstvo. Veza je tipa 1:*, i oderuje kojoj od postojeih kategorija pripada sredstvo. Sa aspekta kategorije sredstva, ona opisuje jedno ili vie sredstava (1..*), a sa aspekta sredstva, ono je uvek opisano samo jednom kategorijom, tj. pripada samo jednoj kategoriji (1..1). Dakle, participacija entiteta Kategorija sredstva je obavezna (1), jer svako sredstvo mora da pripada jednoj kategoriji, dok je kardinalnost vie (*), jer jedna kategorija moe da se navede za neogranieno mnogo sredstava. Participacija entiteta Sredstvo je obavezna (1), jer bez sredstva kategorija sredstva nema nikakav smisao, a kardinalnost je 1, jer jedno sredstvo moe da pripada samo jednoj kategoriji.

6. Prikazuje se, koja predstavlja odnos izmeu entiteta Sredstvo i Ulaz/Izlaz-stavke. Veza

je tipa 1:*, i prikazuje koja sredstva (navedena kao stavke) se nalaze na datom ulazno/izlaznom dokumentu. Sa aspekta sredstva, ono moe da se prikae na nijednom ili na vie dokumenata, tj. ne mora nikada da se pojavi kao stavka ili moe da se pojavi kao stavka na vie razliitih ulazno/izlaznih dokumenata (0..*), a sa aspekta stavke, ona uvek prikazuje samo jedno sredstvo (1..1). Dakle, participacija entiteta Sredstvo je opciona (0), jer sredstvo ne mora obavezno da bude izdato nekome na korienje, dok je kardinalnost vie (*), jer sredstvo moe da se nae kao stavka na neogranieno mnogo ulazno/izlaznih dokumenata. Participacija entiteta Ulaz/Izlaz-stavke je obavezna (1), jer se sredstvo uvek prikazuje kao stavka dokumenta, a kardinalnost je 1 zato to jedna stavka uvek prikazuje samo jedno sredstvo.

V faza: IZBOR DBMS PLATFORME Zadatak: Izbor DBMS platforme na osnovu sistemskih zahteva kao to su performanse, bezbednost i integritet. Uzimajui u obzir injenicu da okruenje za ije potrebe je baza razvijena ima pedesetak zaposlenih i da ukupan broj komada sredstava, opreme i ostale raspoloive imovine ne prelazi hiljadu, kao DBMS platforma je izabran Microsoft Access. Procenjeno je da, zbog relativno malog optereenja u smislu transakcija i koliine podataka koje e uvati, ova platforma u potpunosti zadovoljava potrebe po pitanju performansi. Sledei kriterijum za izbor bio je kvalitet grafikog okruenja. Access dizajneru stavlja na raspolaganje raznovrsne elemente grafikog interfejsa od kojih se moe kreirati vrlo kvalitetno radno okruenje koje je integrisano u samu bazu, pa ne postoji potreba za izradom posebne aplikacije. Izabrana platforma zadovoljava i kriterijum bezbednosti, naroito ako se uzme u obzir injenica da je broj korisnika baze samo jedan (magacioner) i da baza ne radi u mrenom okruenju. VI faza: DIZAJNIRANJE APLIKACIJE Zadatak: Kreiranje korisnikog interfejsa i programa (aplikacija) koji e raditi sa bazom, kao i transakcija koje pristupaju bazi i rade sa podacima. Korisniki interfejs je realizovan kao sastavni deo baze, i kreiran je tako da pre svega bude lak i intuitivan za upotrebu, da blagovremeno detektuje greke u radu korisnika i da ga upozori na postojanje istih, da poniti efekte nainjene greke i na taj nain bazu konstantno odrava u konzistentnom stanju. Prozori aplikacije su strogo namenski kreirani za tano odreenu operaciju ili nekoliko logiki povezanih operacija i realizovani su kao estetski iste i pregledne forme. Isto vai i za tampane izvetaje.

Goran Nei

27


Korisnike transakcije zajedno sa prateim funkcijama i procedurama implementirane su delom kroz ugraene mehanizme programa Access, a delom kao sastavni deo prozora aplikacije upotrebom programskog jezika Visual Basic. U bazi MAGACIN su zastupljene sve tri vrste transakcija, dakle transakcije za prezentaciju podataka, transakcije za promenu podataka i meovite transakcije. VII faza: IMPLEMENTACIJA Zadatak: Konkretna implementacija, tj. kreiranje elemenata baze podataka na izabranoj platformi. Kompletna baza MAGACIN je implementirana primenom alata integrisanih u samo razvojno okruenje. Naime, izabrana DBMS platforma (Microsoft Access) raspolae kvalitetnim grafiki orijentisanim alatima za kreiranje svih potrebnih elemenata baze, pa je ta pogodnost i iskoriena u procesu implementacije. VIII faza: PUNJENJE BAZE PODACIMA Zadatak: Punjenje novonastale baze podacima i migracija sa prethodne verzije, ako postoji, uz eventualnu konverziju podataka. Baza MAGACIN je manualno napunjena podacima koji su se do tada nalazili u raznim dokumentima u papirnoj formi a, poto prethodna verzija baze nije postojala, nije bilo potrebno vriti ni migraciju ni konverziju podataka. IX faza: TESTIRANJE Zadatak: Otkrivanje eventualnih greaka i/ili nepravilnosti u radu i demonstriranje da baza i pratee aplikacije, ako postoje, rade u skladu sa korisnikom specifikacijom zahteva. Testiranje baze MAGACIN je izvreno posle punjenja, dakle sa realnim podacima, ali pre konanog putanja u rad i nad kopijom originalnog fajla, tako da bezbednost podataka nije bila ugroena. U testiranju su aktivno uestvovali krajnji korisnik i projektant, pa su svi uoeni nedostaci i nepravilnosti u radu brzo i efikasno otklonjeni. X faza: ODRAVANJE Zadatak: Nadgledanje performansi sistema (baze), odravanje i usavravanje aplikacija. S obzirom na jednostavnost baze MAGACIN, ova faza se praktino svela na naknadnu realizaciju jo nekoliko manjih korisnikih zahteva u domenu funkcionalnosti i grafikog interfejsa.

Goran Nei

28


3. Termin klijent/server se po prvi put pojavio tokom 80-tih godina prolog veka i odnosio se na personalne raunare (PC) na mrei. Pravi klijent/server model je poeo da se primenjuje u kasnim 80-tim godinama. Klijent/server softverska arhitektura je fleksibilna, modularna i bazirana na porukama, a u poreenju sa centralizovanom mejnfrejm arhitekturom koja joj je prethodila nudi poboljanu upotrebljivost, prilagodljivost, meuoperativnost i skalabilnost. Klijent se definie kao zahtevalac usluge, a server kao prualac usluge. Jedan raunar moe da bude i klijent i server u zavisnosti od softverske konfiguracije. Klijent/server arhitektura je nastala iz potrebe za prevazilaenjem ogranienja dvaju arhitektura koje su joj prethodile, mejnfrejm i arhitekture bazirane na deljenju fajlova (file sharing). Ogranienja su se ogledala u slaboj ili nikakvoj podrci za grafiko korisniko okruenje, limitiranom broju korisnika koje je sistem u stanju da podri, kao i u oteanom pristupu fiziki razmetenim izvorima podataka. Klijent/server arhitektura uvodi u upotrebu relacione baze podataka i servere baze podataka koji zamenjuju fajl servere, tako da korisniki upiti mogu direktno da se procesiraju. Mreni saobraaj je osetno smanjen upravo zbog toga to se preko mree vie ne prenose celi fajlovi, ve samo korisniki upiti i odgovori na njih. Koncept grafikog korisnikog interfejsa i deljene baze podataka omoguava jednostavan unos i promenu podataka od strane vie korisnika. U klijent/server okruenju, za komunikaciju izmeu klijenta i servera se najee koriste RPC (Remote Procedure Calls) i SQL (Structured Query Language) upiti i odgovori na njih. Prednosti klijent/server arhitekture se ogledaju u sledeem:

Procesiranje se rasporeuje na vie raunara, nekritini podaci i funkcije se obrauju na klijentu, kritine funkcije se obrauju na serveru.

Klijentske radne stanice se optimiziraju za unos i prezentaciju podataka. Radne stanice

treba da imaju kvalitetne grafike podsisteme. Server se optimizira za obradu i skladitenje podataka. Serveri treba da imaju mnogo

RAM memorije i velike hard-diskove. Horizontalno skaliranje optereenje izmeu servera moe ravnomernije da se

rasporedi jednostavnim dodavanjem vie servera u sistem. Vertikalno skaliranje ukoliko je procesorska snaga postojeih raunara nedovoljna,

moe se prei na snanije raunare ili raunarske platforme.

Klijent/Server arhitektura

Goran Nei

29


Smanjuje se redundansa i potreba za replikacijom podataka podaci se uvaju samo na serverima, a ne na svakom klijentu.

Documents

2.pdf