1. Pojam informacionog sistema sistem, podatak i informacija.

Informacioni sistem je sistem u kome se veze izmedju objekata i veze sistema sa

okolinom ostvaruju razmenom informacija.
Sistem je skup objekata i njihovih veza.
Podatak je kodirana predstava o nekoj injenici iz realnog sveta.
Informacija je protumaeni podatak o pojavi koju podatak prikazuje.
2. Prouavanje informacionog sistema.
Za uspeno izvodenje aktivnosti vezanih za razvoj informacionih sistema potrebno je na
samom poetku raskrstiti sa zabludama, definisati ogranienja i dati odgovarajue
pretpostavke.
Zablude su: da neko drugi moe obaviti ovaj posao, po principu "u rukeklju"; da se
naruivanjem projekta moe bre zavriti posao; da se preslikavanjem postojeih
aplikacija u novo moe doi do novog sistema.hardversko i softversko okruenje
Ogranienja: stepen organizovanosti dokumenta isistema koji se analizira i koji zavisi od
razraenosti standardnih procedura za njihovu obradu i distribuiranje; ogranienja vezana
za korisnike, novog sistema; znanjekoja su u vezi sa odbojnou prema ideji uvoenja
projektnog tima, njihovu metodologiju rada i iskustvo za sline sisteme koji biti od
presudnog znaaja.mogu
Pretpostavke: jedinstven sistem oznaavanjadefinisanje najee tzv. paralelnog sistemai
podrazumeva oznaavanja, jedinstvenost modela procesa i podataka, jedinstvenost
sistema (SUBP).za upravljanje bazama podataka
3. Planiranje razvoja informacionog sistema.
Aktivnosti u okviru ove faze su:
- Identifikacija i definisanje problema.
- Analiza postojeeg informacionog sistema.
- Treba odgovoriti na pitanje to se promjenama u informacionom sistemu eli postii.
- Treba se odluiti na uvoenje potpuno novog ili modifikovanog informacionog sistema.
- Projektovanje logike strukture baze podataka.
- Definisanje koncepcije tehnike podrke.
- Definisanje modela kadrovske podrke.
- Specifikacija potrebnih ulaganja.
- Analiza izvodljivosti projekta.
- Utvrivanje prioriteta i izbor projektanta.
- Planiranje realizacije projekta.
- Prihvatanje ili odbijanje plana razvoja.
4. ema informacioni sistem realni sistem.
Samu sutinu informacionog sistema predstavlja baza podataka (ili sistem baza podataka)
koja sadri meusobno povezane podatke kojima se modeluju objekti, veze izmeu
objekata (entiteta) kao i odgovarajui atributi (obiljeja - osobine) objekata i veza.

Pored podataka informacioni sistem mora da sadri podatke o procesima (ili model
procesa).
5. Analiza i dizajn informacionih sistema.
Analiza se provodi detaljno na sve automatizovane i neautomatizovane poslove. Osnovno
sredstvo koje se danas koristi za analizu informacionog sistema je sistemska strukturirana
analiza.
Dizajn sistema je specifikacija novog sistema koji e postavljene zahtjeve obaviti na
efikasan nain. Kod dizajna sistema postoje dvije vane faze:
- logiko projektovanje;
- fiziko projektovanje.
Faze analize i dizajna su karakteristine po bogatoj dokumentaciji koja ih prati. Tenja je
da se
danas razviju sistemi koji e na osnovu projekta odraenog u nekom programskom
paketu vriti
automatsko voenje dokumentacije.
6. Implementacija informacionog sistema.
Implementacija" omoguuje izvoenje promena vezanih za nain rukovoenja i primene
informacionih tehnologija. Ova aktivnost se posmatra kroz sledee tri podaktivnosti:
Aktivnost "4.1. Uvoenje" treba da da ocenu uraene korisnike aplikacije, omogui
izmene u toku uvoenja, izradi uputstva za korisnike i obui same korisnike.
Aktivnost "4.2. Testiranje" treba da omogui testiranje sprovedenih aktivnosti u okviru
postavljenog SUBP gde se ocenjuju performanse tog sistema.
Aktivnost "4.3. Odravanje" se izvodi kad se pree u fazu eksploatacije
novopostavljenog sistema. Ovde se drasti no pokazuju sve manjkavosti i neregularnosti
vezane za sprovedeni reinenjering poslovnih procesa i definiu odgovarajue korektivne
akcije.

7. ivotni ciklus predstavlja redosled faza u nastajanju u menjanju informacionog sistema.

Postoje dve metodologije razvoja informacionog sistema:
linearna
evoluciona.
Kod linearne postoje slijedee faze:
Planiranje:
Analiza i dizajn;
Implementacija;
Funkcionisanje i odravanje;
Vrednovanje i kontrola
Nije teko zakljuciti da se ipak prije same realizacije informacionog sistema evolucionim
pristupom moraju izvriti neke operacije na globalnom nivou - linearnim pristupom. Ove
operacije su obicno vezane za definisanje globalnog modela podataka, centralne baze
podataka i pravila pristupa bazama podataka, cesto se definiu i podsistemi i napravi se
dogovor o povezivanju podsistema, raspodjele hardverskh, softverskih i ljudskih resursa.
Zatim se prede na realizaciju pojedinih funkcija pomocu prototipa (metodom uzastopnih
pokuaja).
8. Vrednovanje i kontrola informacionog sistema. Alati za projektovanje
informacionih sistema.
Ova faza nastupa kada informacioni sistem postoji i funkcionie. Da bi se neko
ocjenjivanje informacionoig sistema sprovelo mora biti razvijen objektivan set
kriterijuma. To mogu biti:
Uticaj informacionog sistema na poslovanje u smislu ubzanja pojedinih aktivnosti;
Koliko sam informacioni sistem moe da odradi brzo pojedine operacije i dali moe
bre;
Da li je pogodan za korienje;
Da li je odravanje skupo i na koji je nain rijeeno;
Vano je zapamtiti da projekat informacionog sistema kao i njegova realizacija
predstavlja rezultat
intereakcije rada projektanata koji znaju realizovati informacioni sistem ali ne znaju
konkretne
potrebe organizacije i ljudi iz organizacija koji znaju to im treba ali ne znaju da to
realizuju.
Podrazumjevamo da se informacioni sistem projektuje pomou raunara i da je zasnovan
na
raunarima. U posljednjih nekoliko godina stvoren je veliki broj alata koji se mogu
koristiti za
projektivanje informacionog sistema pomou raunara. Ovi alati se zovu Computer Aided
Software Design (CASE). Ciljevi primjene ovih alata su:
Poveanje produktivnosti projektanata;
Skraivanje vremena izrade projekta (ovo ima i neke negativne efekte na projektanta,
danas vie ljudi moe da se zahvaljujui ovakvim sredstvima ukljui u izradu projekata
to dovodi do znaajnog smanjenja cijene projekta koja se ne moe nadoknaditi veom
produktivnou);
Poveanje kvaliteta dobijenog projekta (ovo je veoma vano).
9. Definisanje granica sistema je vezana za nabrajanje objekata koji e u sledeem koraku

biti po hijerarhiji povezani u stablo aktivnosti. U okviru utvrivanja granica sistema treba
jasno definisati ciljeve koji moraju da e proces da prikae,sadre sledee elemente: zato
se proces modelira, ta e korisnik modela napraviti sa njim, emu slui model.ta
Odgovori na ova pitanja treba da pomognu u fokusiranju postavljene problematike.
Sledea pitanja na koja treba dati odgovor su: koji su zadaci na datom radnom mestu, koji
je redosled izvoenja koraka, kako se izvodi kontrola, koji se resursi koriste.
Grafiki jezik IDEF0 opisuje metodu funkcionalne dekompozicije preko skupa
dijagrama, od
kojih svaki predstavlja ogranienu koliinu detalja definisanih odgovarajuom sintaksom
i
semantikom. Dijagrami su meusobno povezani tako da opisuju sistem, hijerarhijski, sa
vrha nanie. Dijagrami se sastoje od pravougaonika koji predstavljaju neki deo celine.
Povezani su meusobno usmerenim linijama koje predstavljaju veze izmeu delova.
Kontekstni dijagram je definisan jednim pravougaonikom koji predstavlja granicu
modela koji se prouava. U tom sistemu i van njega teku informacije preko strelica.
Kontekstni dijagram je najvii nivo apstrakcije koji se dekompozicionim dijagramima
prevodi u nii nivo apstrakcije.
10. Stablo aktivnosti se definie primenom metode reavanja problema odozgo nadole (top- down), kada se sloena aktivnost rastavlja na vie podreenih aktivnosti, a zatim se
pristupa reavanju jednostavnih podreenih aktivnosti. Dakle, stablo aktivnosti
predstavlja hijerarhiju definisanih aktivnosti, oienu od strelica, i omoguuje
funkcionalnu dekompoziciju i uvid u dubinu odvijanja veza izmeu aktivnosti.
Aktivnost na vrhu (root) uvek je oznaena sa 0. Brojevi se koriste da bi prikazali koliko
detalja sadri aktivnost. Aktivnost A0 je dekomponovana (razdvojena) na 1, 2, 3 itd.
Aktivnost 1 je dekomponovana u 11, 12, 13 itd. Nadreena aktivnost se zove 'roditelj'
(parent), a podreene aktivnosti su deca (childs).
Verifikacija stabla aktivnosti veoma je vana, jer je to strateki momenat, tj. odluka
rukovodstva da li je to ono to se eli postii reinenjeringom poslovnih procesa. Kao
veoma bitna aktivnost, ona prva mora biti usaglaena i verifikovana. Ovaj elemenat se
mora razmatrati prilikom klasinog naina uvoenja dokumenata za obezbeenje
kvaliteta, po standardu ISO 9000.
11. Definisanje zahteva iz dokumenata je pogled odozdo nagore i u nadreenoj aktivnosti.
Veliku pomo u izvoenju ove aktivnosti mogu pruiti i odgovarajue procedure i
uputstva, definisani po standardu kvaliteta ISO 9000, jer sistematizuju klasinu "runu"
izlazne dokumente,dokumentaciju. Dakle, treba prikupiti: ulazne dokumente, uzorke
izvetaja, organizacione propise i dr.
Definisanje zahteva intervjuom je pristup odozgo nadole, i treba da ciljeva I problema
kako ihomogui definisanje: potreba za informacijama, vide rukovodioci i neposredni
izvrioci. To je kljuni momenat u reinenjeringu poslovnih procesa, jer se ovde
rukovodstvo izjanjava o pitanju budunosti, odnosno daljem poslovanju. Ova analiza
treba da da i odgovore vezane za primenu Interneta u preduzeu.
Prvi korak su listeopte pripreme za izvoenje intervjua koje su vezane za definisanje:
teme zarukovodilaca za intervjue, vremenskog rasporeda intervjua, voenjerazgovor,
potvrde termina, organizacije grupe za intervjue, izbor optih pitanjazapisnika, priprema
panela, opremanje prostorije, probni intervju.i
12. Definisanje matrice odnosa treba da definie matricu veza izmeu aktivnosti i

dokumenata koji treba da poveu dokumenta odreena kao ulazne ili izlazne informacije
sa aktivnostima iz stabla aktivnosti na gornjem okvirnom nivou. Dokumenta su
definisana odgovarajuim rubrikama, ijom se analizom odreuju odgovarajui entiteti.
Entiteti na ovom nivou predstavljaju objekat koji se moe opisati nekim osobinama. Za
ovu aktivnost bitni su samo nazivi entiteta, bez ulaenja u definisanje osobina. Entitet se
u okviru neke aktivnosti: i/ili kreira (C-Create), i/ili pretrauje (R- Retrive) i/ili aurira
(U-Update), i/ili brie ( D-Delete), pa otuda i naziv CRUD matrica (definisana poetna
slova engleskog naziva).
Analiza zahteva korisnika znai da postavke definisane u prethodnim koracima treba da
verifikuje odgovarajui verifikacioni organ preduzea.
Zadatak verifikacionog tela je da usvaja rezultate rada strunog tima u kontrolnim takama
koje predstavljaju okonanje pojedinih faza na izradi projekta.
Treba naglasiti da sve navedene aktivnosti i podaktivnosti moraju ii ovim redosledom i da
definisanje tehnikih preduslova tek onda dolazi u razmatranje. U praksi se obino, radi
naopako.

13. Tehniki preduslovi podrazumevaju, pre svega, raunarski sistem sa definisanim:

- Sistemom hardver (nesto opipljivo)
- Sistemom softver (nesto neopipljivo,tj, preneta ljudska znanja i pamet)
- Sistemom dokumentacije (opis za sistem hardver i sistem softver)
Sistem hardver ine: radna memorija, masovna memorija, ulazne jedinice, izlazne
jedinice i centralna procesorska jedinica. Radna memorija sadrzi operativnu (RAM) i
postojanu (ROM,PROM,EPROM) i dr. U masovnu memoriju spadaju: magnetni
diskovi,diskete,opticki diskovi,magnetne trake,kasete,CD. Ulazna jedinica omogucuje da
se u racunar unose instrukcije,programi,podaci;cine je:tastatura,disketna
jedinica,mis,skener,opticki stap i dr. Izlazna jedinica se koristi da se preko nje saopstavaju
rezultati rada racunara;cine je:monitor.stampac,ploter i dr. Centralna procesorska jedinica
izvrsava instrukcije uskladistene u operativnoj memoriji.
Sistem softver ine operativni sistemi, koji mogu biti jednokorisniki (CPM, MS -DOS) i
viekorisniki (UNIX, OPEN/VMS, Windows 2000), zatim, jeziki procesori koji se dele
na interpretere (BASIC) i kompajlere (FORTRAN, PASCAL, C++), kao i aplikativni
softveri u koje spadaju tekst-procesori (Word for Windows) i baze podataka.
Sistem dokumentacije ine dokumentacija za sistem hardver, dokumentacija za sistem
softver i ostala dokumentacija.
Imajuci sve to u vidu,aktivnostTehniki preduslovi" izvodi se kroz tri podreene
aktivnosti: Definisanje arhitekture sistema, Kadrovske potrebe, Dinamika realizacije i
trokovi.
14. Definisanje arhitekture sistema treba da ukae na osnovne pretpostavke koje se moraju
ispuniti da bi se mogao sprovoditi postupak reinenjeringa poslovnih procesa.
Prilaz razmatranja tehniko-tehnolokih resursa treba da je u saglasnosti sa otvorenom
arhitekturom referentnog modela organizacije za standarde, gde je definisano sedam
nivoa povezivanja i komuniciranja raunarske i druge opreme: NIVO 7. APPLICATION
(aplikacijski nivo), NIVO 6. PRESENTATION (prezentacijski nivo), NIVO 5. SESSION
(nivo sesije), NIVO 4. TRANSPORT (transportni nivo) , NIVO 3. NETWORK (mreni
nivo), NIVO 1. PHISICAL (fiziki nivo)2. DATA LINK (nivo podaci - veze), NIVO
Pri izboru opreme treba imati u vidu tehniko-tehnoloke preduslove, koji su sagledavani
prema strukturi arhitekture referentnog modela: korienje softverskih proizvoda za
razvoj aplikacije, visok stepen kompatibilnosti raunarske opreme, otvorenost mrene

arhitekture, modularnost opreme krajnjih korisnika, efikasnost sistema upravljanja

podacima, kvalitetan komunikacioni sistem.
15. Kadrovske potrebe. Dinamika realizacije i trokovi.
Pod kadrovskim potrebama podrazumevaju se broj potrebnog kadra za realizaciju
projekta reinenjeringa poslovnih procesa i potrebna obuka za korienje informacionih
tehnologija.
Kao informatiku osnovu u sprovoenju reinenjeringa poslovnih procesa, treba imati
minimum potrebnog kadra. Potrebni su: rukovodilac, vodei projektant za modeliranje
procesa i podataka, vodei projektant softverskih reenja, vodei sistem inenjer, referent
dokumentacije.projektant baze podataka,
Trokovi realizacije trokovi razvojanajee se posmatraju u okviru grupa poslova kao:
trokovi eksploatacije.aplikacija, trokovi tehniko-tehnolokih resursa,
Svaka od ovih grupa poslova se, takoe, sastoji iz posebnih trokova i otuda specifikaciju
trokova treba da ini sledea struktura:
trokovi razvoja:
obuka projektnog tima,
razvoj zajednikih aplikacija,
struna pomo pri razvoju,
razvoj i dopuna sopstvenih aplikacija,
softverski trokovi tehniko-tehnolokih resursa:proizvodi za razvoj aplikacija;
raunarska oprema zajednikih resursa,
oprema komunikacionog sistema,
dopuna i kompletiranje raunarske opreme,
pratea oprema i adaptacija prostora;
trokovi eksploatacije:
odravanje opreme,
potronja elektrine energije,
korienje komunikacionih linija,
amortizacija opreme,
plate radnika.
16. Definisanje detaljnih zahteva" se izvodi na osnovu definisane studije kojom se odreuju
okviri koji se u ovoj aktivnosti za izabrane podsisteme detaljno razra uju. Definisanje
detaljnih zahteva treba da predstavlja reviziju postavljenih elemenata iz studije, uz dalje
detaljno produbljivanje za izabranu funkciju za koju se sprovodi reinenjering poslovnih
procesa. Definisanje detaljnih zahteva se izvodi posredstvom sledeih akivnosti:
Izrada detaljnog stabla aktivnosti" je idejni projekat na osnovu dobijene informacije od
korisnika.
Definisanje dekompozicionog dijagrama" su dokumenta: "Detaljno stablo aktivnosti" i
"Informacije od korisnika".
Definisanje detaljnih matrica odnosa - Tokovi podataka prikazani strelicama povezuju se
sa entitetima i sa svim ili samo sa pojedinim atributima tih entiteta. Ako se posmatraju
naini na koje strelica koristi entitet, onda se definiu CRUD matrice
Dijagram toka podataka (DTP) grafiki je opis koji povezuje procese, tokove podataka
(dokumenta), skladita podataka (kartoteke).
17.
Definisanje dekompozicionog dijagrama su dokumenta: "Detaljno stablo
aktivnosti" i "Informacije od korisnika". U okviru ove aktivnosti uspostavljaju se

horizontalne veze izmeu podaktivnosti koje su povezane strelicama. Izlaz iz ove

aktivnosti je "Detaljni dekompozicioni dijagram"
U okviru definisanja dekompozicionog dijagrama u daljem tekstu bie razmatrani:
pravougaonici u dekompozicionom dijagramu, strelice u dekompozicionom grananje ili
udruivanje strelica, ugao posmatranja, postojeidijagramu, formiranje trokovnih
centara, tekstualni(as-is) i budui (to-be) model, opis.
Aktivnosti su, kao to je ve reeno, smetene u pravougaonicima koji se crtaju u
dijagonalnom smeru, od gornjeg levog ugla strane ka donjem desnom uglu. Svakoj
aktivnosti mora se dodeliti naziv u obliku glagolske fraze, te mora imati najmanje jednu
kontrolnu i jednu izlaznu strelicu.
Strelice u okviru dekompozicionog dijagrama omoguuju tzv. horizontalno povezivanje
definisanih aktivnosti.
18. Definisanje detaljnih matrica odnosa.
Tokovi podataka prikazani strelicama povezuju se sa entitetima i sa svim ili samo
sa pojedinim atributima tih entiteta. Ako se posmatraju naini na koje strelica
koristi entitet, onda se definiu CRUD matrice (slika 3.10), to je skraenica od:
kreirati entitete, to se oznaava sa C (Create); pretraivati entitete, to se aurirati
entitete, to se oznaava sa Uoznaava sa R (Retrive); brisati entitete, to se
oznaava sa D (Delete).(Update);
Kada se za svaku strelicu definie, osim naina korienja entiteta, i povezanost
entiteta sa atributima, onda se definie IRUN (slika 3.10) matrica, to je
skraenica od: ubacivanje atributa, to se oznaava sa I (Insert); pretraivanje
atributa, to auriranje atributa, to se oznaava sa Use oznaava sa R (Retrive);
Dakle, mogu(Update); dodela nula vrednosti, to se oznaava sa N (Null field). se
kreirati dve matrice: CRUD matrica, na kojoj bi sa jedne strane bili koriste te
entitete ientiteti, a sa druge strane aktivnosti koje
IRUN matrica, sa odreenojdefinicijom korienja svakog atributa u odreenom
entitetu i aktivnosti.
19. Dijagram toka podataka (DTP) grafiki je opis koji povezuje procese, tokove
podataka (dokumenta), skladita podataka (kartoteke). Drugim reima, dijagram
toka podataka se koristi za prikaz na onom nivou gde su mogu definisati ulazi,
izlazi, tokovi, skladita i procesi. Dijagram toka podataka ili Data Flow Diagram
(DFD) ugraen je u softverski proizvod BPwin i koristi se pri modeliranju
procesa. Dijagram toka podataka fokusira problem tokova podataka izmeu
procesa, a vri i analizu skladita podataka radi maksimalnog poveanja njihove
raspoloivosti i smanjenja vremena pretraivanja.
Dijagram toka podataka se grafiki opisuje: Proces je niz operacija kojima se
transformiu ulazni podaci u izlazne; Tok podataka je put (grafiki oznaen
strelicom) kojim protiu grupe podataka (dokumenta, formulari, obrasci), koji
pokazuje izmeu kojih elemenata se odvija tok podataka; Skladite podataka
(kartoteka, fascikla, datoteka) slui za uvanje podataka, odnosno definie se kao
tok podataka u mirovanju; povezano je iskljuivo s procesima sistema preko
tokova podataka.
Analiza detaljnih zahteva treba da bude svojevrsna rekapitulacija do sada obavljenih
aktivnosti: provera prikupljenih informacija" predstavlja proveru prethodne faze, vezane
za postavljanje modela reinenjeringa, jer postoji mogunost da u meuvremenu doe do

nekih izmena; Provera pojedinanih modela", u svetlu novih injenica, definisanih

prethodnom aktivnou uesnika, tj. autora pojedinanog modela moe zahtevati dodatne
informacije, a kao rezultat ove aktivnosti su pojedinani modeli; Provera kompletiranog
modela" moraju napraviti pojedini kompromisi i odstupanja, to kao povratna informacija
ide "Komentar radnog materijala ", kao i model za pregled; Validacija modela" treba da
prekontroliu valjanost modela Izlaz iz ove aktivnosti su komentari korisnika koji
predstavljaju ulaz za prethodnu aktivnost. Verifikacija modela. Ako postoje primedbe, one
su kao komentar modela ulaz u aktivnost "3. Provera kompletiranog modela", a ako je
model verifikovan - on se alje kao kontrolna informacija u aktivnost "3. Provera
kompletiranog modela". Nakon verifikacije kao izlaz se dobija detaljni IDEF0 model koji
je rezultat aktivnosti "2.1. Definisanje detaljnih aktivnosti".
20. Identifikacija kandidata za entitete polazi se od objekata posmatranja. Objekt
posmatranja je sve to se moe jednoznano identifikovati, pa samim tim i izolovati iz
okoline i opisati. Tako je objekt posmatranja i "entitet". Entitet je osoba, stvar, dogaaj,
pojam (realni ili apstraktni) koji je od trajnog interesa za preduzee, tj. neto to se eli
pojedinano posmatrati. Za potrebe definisanja fizikiER dijagrama, na primer, mogu se
posmatrati sledei objekti, i to: objekti (vozilo, maina,...), osobe, mesta (adrese,
koordinate na organizacije (preduzea, zavod,...), grupe/klase/tipovi (tipkarti,...),
ugovori, potraivanja (narudbe,proizvoda, klasa poslova,...), pridruenjefakture,...),
prenos/ premetaj (stvari, vozila, novca,...), (zadatak - osoba, vozila, vonja,...),
pripadnost/lanstvo (komponente - sastavi,...) i dr.
Za navedene mogue entitete treba: odrediti prikladne radne nazive; napraviti 15); po
grupama, traiti dodatne entitetegrupe entiteta (ako ih je vie od (posmatrati najvaniji
entitet); po potrebi, rearanirati grupe.
Kako se entiteti opisuju preko svojih osobina, tj. atributa, to se identifikacija atributa
moe izvesti i na sledei nain.
Treba poi od postavke da svaki atribut u jednom trenutku vremena ima neku vrednost,
zatim analizirati tu vrednost i na osnovu toga proiriti listu entiteta na sledei nain:
Entitet je i atribut koji je istovremeno i atribut drugog entiteta.
Na osnovu prethodne analize strukture teksta, imenicu po analogiji smatrati entitetom.
Na osnovu slinosti ATRIBUTA koji mogu pripadati entitetu, uoava se znaajna razlika
(slinost), to moe da ukae na to da je re o razliitim (istim) objektima.
U toku identifikovanja entiteta, za svaki tip entiteta mora postojati jedan atribut (ili grupa
atributa) koji jedinstveno identifikuje konkretni entitet u okviru tog tipa.
Atribut koji identifikuje drugi tip entiteta je entitet.
21. Identifikacija veza prvi put definiu veze izmeu entiteta. Veza predstavlja
interakciju meu objektima, tj. znanje o njihovoj meusobnoj povezanosti. Vezama se
definiu zavisnosti izmeu entiteta, odnosno opisuju naini povezivanja (uzajamna
dejstva) entiteta.Predmet daljih razmatranja predstavlja identifikacija veza, i to:
povezivanje entiteta na osnovu odgovarajuih interesa; definisanje zavisnosti entiteta
(gde se definiu nezavisni i zavisni izvoenjedefinisanje znaenja zavisnosti
(definisanjem referencijalnog integriteta);entiteti); varijacija zavisnosti (nalaenjem
optimalne); izbor entiteta 'roditelj' i entiteta 'dete'.
Veze u reenici su 'glagolske fraze' koje pokazuju kakav je odnos meu entitetima.
Premda

glagolske fraze ne opisuju pravila precizno, one dozvoljavaju osobi koja posmatra
model da stekne osnovni oseaj o povezanosti entiteta. Dobra je praksa ako itanje
modela daje
valjane reenice (iskaze).
22. Definisanje ER modela sadri sledee korake: definisanje nezavisnih entiteta, tj.
pronalaenje 'roditelj' - Nezavisni entitet je objekat koji ima jednu osobinu koja ga
moe jednoznano identifikovati, tj. nezavisni entiteti imaju vlastitu identifikaciju (ne
zavise od drugih entiteta). Grafiki se nezavisni entiteti prikazuju pravougaonikom u
okviru koga se upisuje naziv tipa entiteta u jednini; definisanje zavisnih entiteta - su
entiteti ije egzistencija i identifikacija zavise od drugog ili drugih entiteta.;
definisanje veza. - Kao to se u realnom svetu uspostavljaju odreene veze izmeu
objekata, po istoj analogiji se definiu i veze izmeu entiteta. Veza je asocijacija
izmeu dva ili vie entiteta.
23. Identifikujue veze, neidentifikujua veza, veza kategorije i neodreujua veza.
Veza se zove identifikujua zato to kljuevi entiteta 'roditelj' predstavljaju deo
identiteta entiteta 'dete', tj. entitet 'dete' zavisi od entiteta 'roditelj' preko identifikatora.
Identifikujua veza je prikazana punom linijom i povezuje entitet 'roditelj' sa
entitetom 'dete' sa takom na strani entiteta 'dete'
Veza kategorije je definisana za hijerarhijsku vezu izmeu nadreenog generalizovanog
(generikog) entiteta koji sadri zajednike osobine podreenih entiteta kategorije. Ovaj
tip se deli na: potpunu strukturu (kada je zatvoren skup entiteta kategorije) i nepotpunu
strukturu (kada nije zatvoren skup entiteta kategorije). Potpuna struktura se definise za
tacno odredjen broj entiteta kategorije i ne moze se vise ni jedan ukljuciti; nepotpuna
struktura ostavlja mogucnost ukljucivanja drugih entiteta kategorije.
Ako se svaki primerak entiteta 'dete' moe jedinstveno identifikovati, bez znanja veze sa
primerkom entiteta 'roditelj', onda se takva veza definie kao neidentifikujua veza.
Neidentifikujue veze su prikazane isprekidanom linijom koja povezuje entitet 'roditelj' i
entitet 'dete' sa takom na strani entiteta 'dete'.
Veza kategorije je definisana za hijerarhijsku vezu izmeu nadreenog generalizovanog
(generikog) entiteta koji sadri zajednike osobine podreenih entiteta kategorije. Ovaj
tip se deli na: potpunu I nepotpunu.
Neodreujua veza je nespecificirana, a govori o tome da se jedan entitet pridruuje
veem broju entiteta drugog tipa i obrnuto
24. Definisanje liste kandidata za atribute je verifikovani ER model, koji u okviru ove
aktivnosti kao izlaz ima ER model sa atributima. Da bi se definisala lista kandidata za
atribute, mora se dati odgovor na pitanje ta je interes posmatranja. Da li e po nekoj
osobini objekat biti entitet ili atribut, tj. koju e ulogu imati, zavisi od pogleda koji se eli
predstaviti. Osnovna pravila koja se koriste u realizaciji aktivnosti:
Svaki entitet ima proizvoljan broj atributa, to znai da nema ogranienja u atributa;
Odreeni atribut pripada jednom i samo jednom entitetu, tako dabroju biti opisan u
okviru dva ili vie entiteta.; Svakoisti atribut ne moe pojavljivanje entiteta ima vrednosti
za sve atribute tog entiteta.; Atribut entitetaodreenog pojavljivanja entiteta moe imati
samo jednu vrednost, pa primerak za odreeni atribut ima jednu vrednost.; Svaki atribut
predstavlja jednu atributa mora imatiinjenicu, tako da i svako znaenje
vrednostiodreenu jedno dosledno znaenje.
25. Definisanje kljueva ima zadatak da za svaki entitet bude definisan atribut ili
kombinacija atributa, ije vrednosti jedinstveno identifikuju svaki primerak entiteta. Taj

atribut ili grupa atributa naziva se primarni klju. Ako klju ini samo jedan atribut, onda
je prost klju; u suprotnom je sloen. Atributi mogu biti definisani u oblasti kljueva
(primarni klju) ili u oblasti podataka. Tipovi kljuceva: Primarni kljuc - Atributi ili grupe
atributa koji mogu biti izabrani kao primarni kljuevi nazivaju se 'atributi kandidati za
klju'.; Kandidati za klju koji nisu izabrani za primarne kljueve mogu se definisati kao
alternativni kljuevi (Akn).+ inverzni; Preneseni klju je kolekcija atributa koji u
posmatranom entitetu nisu klju, ali su zato klju u nekom drugom entitetu.
26. Postupak normalizacije uklanjaju se sve strukture koje stvaraju redundansu podataka,
pa je slogan normalizacije: Jedna injenica na jednom mestu. Pravilno izveden postupak
normalizacije podataka omoguuje korektno izvoenje aktivnosti "3. Aplikativno
modeliranje", koja ima strukturu kojom osigurava da u radu sa njom nee biti neeljenih
anomalija, kao to su, npr., unitavanje odre enih podataka ili neusklaenost izmeu
memorisanih podataka kao posledica auriranja baze podataka. Drugim reima, postupak
normalizacije predstavlja transformaciju poetnog entiteta u jednu ili vie korektnih
entiteta ili veza u kojima su svi atributi potpuno funkcijski zavisni od kljua, a
meusobno funkcijski nezavisni.
27. Definisanje atributa se izvodi u tri revizijomidentifikacijom atributa, alociranjem
atributa ikoraka: atributa.
Identifikacija atributa se definie na osnovu zahteva korisnika i poslovne dokumentacije.
Alociranje atributa se izvodi u zavisnosti od toga da li atribut zavisi od kljua ili je
opisni.
Revizijom atributa se eliminie viestruko nastupanje vrednosti atributa pojedinog
entiteta i pri tom se za svaki atribut postavljaju pitanja: da li je potrebno traiti odeljenja,
Nazivviestruke vrednosti za isto pojavljivanje entiteta (Sifra odeljenja); da li atribut
moe pripadati nekom drugom entitetu; da li postoje da li postojeatributi koji ne
nastupaju za neko pojavljivanje entiteta; izvedeni atributi (koje treba ili odstraniti ili
dodati); da li postoje Za atributeda li je prikladan identifikator/ klju.atributi bez entiteta;
nullse mogu definisati : set vrednosti, pravila dozvoljenih vrednosti, vrednosti, dosledno
znaenje, tj. meusobno iskljuivanje (npr., Atribut: Pol; ena).Vrednost: mukarac,
28.
Definisanje poslovnih pravila potrebne su sledee podaktivnosti: Definisanje
kardinalnosti veza, Definisanje referencijalnog integriteta I Identifikacija poslovnog
domena.. Definisanje poslovnih pravila vezano je za tzv. strukturna dinamika pravila
integriteta koja se definiu ureenom trojkom: <Ogranienje, Operacija , Akcija>.
Strukturna dinamika pravila integriteta su: ogranienja kojima se definiu dozvoljena
stanja baze operacije koje mogu potencijalno ugroziti ogranienja I akcijepodataka, koje
treba preduzeti ukoliko doe do naruavanja ogranienja. Za iskazivanje strukturnih
pravila integriteta, tj. za iskazivanje potpune specifikacije buduebaze podataka, definiu
se akcije koje treba preduzeti kada neka operacija auriranja baze podataka narui
definisano ogranienje.
29. Definisanje kardinalnosti veza - veze (relationships) imaju osobinu koja se zove
kardinalnost preslikavanja, koja kardinalnostdefinie: kardinalnost preslikavanja
'roditelj'-'dete' i preslikavanja 'dete'-'roditelj'.
Kardinalnost preslikavanja 'roditelj'-'dete' definie "koliko mnogo" instanci entiteta
'roditelj' je povezano sa "koliko mnogo" instanci entiteta 'dete'. Po IDEF1X metodologiji,
definiu se etiri naina definisanja kardinalnosti preslikavanja 'roditelj'-'dete': Zero , One
or More - bez oznake

Svaki One or'roditelj' povezuje se sa nula, jednom ili vie instanci 'dete'; More - oznaen
slovom "P" Svaki 'roditelj' povezuje se sa jednom Zero or One - oznaen
slovominstancom ili vie instanci 'dete'; "Z" Svaki 'roditelj' povezuje se sa nula ili
jednom instancom 'dete'; Tano n - gde je n broj Svaki 'roditelj' povezuje se sa tano n
instanci 'dete'
30. Kardinalnost identifikujuih veza. Kod identifikujuih veza kljuevi entiteta 'roditelj'
uestvuju u identifikovanju entiteta 'dete', tj. svaka instanca entiteta 'dete' mora biti
povezana sa najmanje jednom instancom entiteta 'roditelj'. Identifikujue veze su
prikazane punom linijom koja povezuje entitet 'roditelj' i entitet 'dete' sa takom na
entitetu 'dete'.
Kardinalnost veze tipa One-to-Zero-One-or-More - Ako je svako ODELJENJE
(PARENT) povezano sa nula, jednom ili vie instanci OSOBA(CHILD), gde OSOBA
zavisi od ODELJENJA
Kardinalnost veze tipa One-to-One-or-More (P) - Ako je svako ODELJENJE (PARENT)
povezano sa jednom ili vie instanci OSOBA (CHILD),gde OSOBA zavisi od
ODELJENJA
Kardinalnost veze tipa One-to-Zero-or-One (Z) - Ako je svako ODELJENJE (PARENT)
povezano sa nula ili jednom instancom OSOBA (CHILD), gde OSOBA zavisi od
ODELJENJA.
Kardinalnost veze tipa One-to-Exactly n- Ako je svako ODELJENJE (PARENT)
povezano sa tano n instanci OSOBA (CHILD), npr.4, gde OSOBA zavisi od
ODELJENJA
31. Kardinalnost neidentifikujuih veza. Veza je neidentifikujua ako se moe
identifikovati instanca entiteta 'dete' bez znanja veze sa entitetom 'roditelj'. Grafiki se
ova veza predstavlja isprekidanom linijom. U zavisnosti od kardinalnosti 'dete'-'roditelj',
(slika 3.50.), ovaj tip kardinalnosti moe ili ne moe imati egzistencijalnu zavisnost.
Egzistencijalna zavisnost instance entiteta 'dete' od instance entiteta 'roditelj' vezana je za
obaveznost veze (No Nulls)
Kardinalnost veze tipa Zero(Null Allowed)-or-One-to-Zero-One-or-More - Ako je svako
ODELJENJE (PARENT) povezano sa nula, jednom ili vie instanci OSOBA (CHILD),
gde OSOBA moe, a ne mora da pripada ODELJENJU
Kardinalnost veze tipa One(No Nulls)-to-Zero-One-or-More - Ako je svako ODELJENJE
(PARENT) povezano sa nula, jednom ili vie instanci OSOBA (CHILD), gde OSOBA
mora da pripada ODELJENJU
Kardinalnost veze tipa Zero(Nulls Allowed)-or-One-to-One-or-More(P) - Ako je svako
ODELJENJE (PARENT) povezano sa jednom ili vie instanci OSOBA (CHILD), gde
OSOBA moe, a ne mora da zavisi od ODELJENJA
Kardinalnost veze tipa One(No Nulls)-to-One-or-More(P) - Ako je svako ODELJENJE
(PARENT) povezano sa jednom ili vie instanci OSOBA (CHILD),gde OSOBA mora da
pripada ODELJENJU
Kardinalnost veze tipa Zero(Nulls Allowed)-or-One-to-Zero-or-One(Z) - Ako je svako
ODELJENJE (PARENT) povezano sa nula ili jednom instancom OSOBA (CHILD), gde
OSOBA moe, a ne mora da zavisi od ODELJENJA
Kardinalnost veze tipa One(No Nulls)-to-Zero-or-One(Z) - Ako je svako ODELJENJE
(PARENT) povezano sa nula ili jednom instancom OSOBA (CHILD), gde OSOBA mora
da pripada ODELJENJU

Kardinalnost veze tipa Zero(Nulls Allowed)-or-One-to-Exactly n - Ako je svako

ODELJENJE (PARENT) povezano sa tano n (4) instanci OSOBA (CHILD), gde
OSOBA moe, a ne mora da zavisi od ODELJENJA
Kardinalnost veze tipa One(No Nulls)-to-Exactly n - Ako je svako ODELJENJE
(PARENT) povezano sa tano n (4) instanci OSOBA (CHILD), gde OSOBA mora da
pripada ODELJENJU
32. Rekurzivne veze se definiu kao: Rekurzija nad jednom tabelom ili rekurzija
hijerarhijskog tipa definisana je za entitet koji je ujedno i 'roditelj' i 'dete'. esto se
naziva i "udica" (fish hook). Hijerarhijska rekurzija omoguuje da 'roditelj' moe imati
vie dece, ali deca mogu imati samo jednog 'roditelj'. Sve rekurzivne veze hijerarhijskog
tipa moraju biti slabe veze. Kao i sve slabe veze, one ubacuju klju entiteta 'roditelj' u
prostor podataka entiteta 'dete'.; Rekurzija nad dve tabele ili rekurzija mrenog tipa (jo
se zove i dvotabelarna rekurzija) predstavlja vezu 'roditelj'-'dete', gde 'roditelj' moe imati
vei broj dece i 'dete' moe imati vei broj roditelja. To je specijalni sluaj 'Many-toMany' veze nad samim sobom i treba je razbiti na dve veze 1 :M. Stoga i u tom sluaju
treba definisati Rolename da bi se predstavilo prenoenje kljueva. U tom sluaju
definiu se identifikujue veze i atribut kljuevi sa NOT NULL vrednostima.
Veza kategorije uspostavlja vezu izmeu nadreenih entiteta i njegovih zavisnih, klasnih
entiteta. Preko ove veze entitet koji se specijalizuje u klase prosleuje primarni klju
klasnim zavisnim entitetima. Ova veza se definie postupkom generalizacije, tj.
postupkom apstrakcije podataka, u kome se skup slinih tipova entiteta predstavlja
NADTIPOM, tj. generikim (generalizovanim) entitetom (IDEF1X metodologija). Pod
slinim tipovima objekata podrazumevaju se oni koji imaju JEDAN broj ISTIH
(zajednikih) atributa, tipova veza i/ili operacija sa drugim objektima. Nepotpuna
struktura se definie kada nije sigurno da su identifikovani svi oblici entiteta
kategorije (jednostruka linija na dnu simbola klase naznauje da mogu biti ukljuene
druge
kategorije). Za ovakvu vezu se definie atribut diskriminator u entitetu koji se
specijalizira i
koji obezbeuje ekskluzivnost veze. Ako se diskriminator ne definie, veza se moe
smatrati
neekskluzivnom. Potpuna struktura se definie za sluajeve kada je sigurno da nema
vieklasnih entiteta u koje bi se specijalizovao odreeni entitet (dvostruka linija na dnu
simbola klase naznauje da ne mogu biti ukljuene druge kategorije). U literaturi se jo
zove ekskluzivna specijalizacija.
33. Neodreujua veza tipa 'vie prema vie' je tip nespecificirane veze koja
povezuje dva entiteta i u kojoj se primerak jednog entiteta vezuje sa nula, jednim
ili vie primeraka drugog entiteta, a svaki primerak drugog entiteta se povezuje sa
nula, jednim ili vie primeraka prvog entiteta. Osnovno pravilo koje se ovde mora
potovati je da se mora izvesti prevoenje 'Many-to-Many' veze u 'Zero-to-Many'
vezu. Kardinalnost N-arne veze. - Postavljanje veze izmeu tri ili vie entiteta se
izvodi na nain koji je slian asocijativnom entitetu. Da bi se dobio odgovor na
postavljeno pitanje, treba "trostruku" vezu zameniti sa dve "dvostruke".
Odgovarajui na razne vrste ovakvih pitanja, N-arne veze se pretvaraju u seriju
"dvostrukih" veza. Retkost je videti prave trostruke veze u IDEF1X modelu. One
su ak mnogo ree nego "etvorostruka", "petostruka"...

34. Referencijalni integritet obezbeuje korektno povezivanje objekata, jer objekat koji
nije predstavljen u odgovarajuem skupu objekata ne moe da uestvuje u nekoj od
veza predstavljenih u modelu podataka. Referencijalni integritet je vezan za
postojanje prenesenog kljua za neki entitet (npr. "Sifra odeljenja" u entitetu
OSOBA). Entitet gde se nalazi preneseni klju zove se 'dete' (CHILD), a entitet gde
se definie primarni klju je 'roditelj' (PARENT). Primarni klju se moe preneti i
postati preneseni klju u okviru identifikujue ili neidentifikujue veze. varijante
referencijalnog rekurzivne neidentifikujua veza,integriteta: identifikujue veze, Narne veze.veze, veza kategorije, neodreujua veza tipa vie prema vie i
35. Identifikacija poslovnog domena. - Entiteti se, kao to je ve reeno, opisuju
preko svojih svojstava, odnosno atributa, od kojih svaki (atribut) u jednom
trenutku vremena ima neku vrednost. Tanije, atributi uzimaju vrednost iz skupa
moguih vrednosti koji se zove domen. Domen predstavlja skup vrednosti, u
njemu se svaka vrednost javlja samo jednom. Svi elementi skupa se meusobno
razlikuju. Atribut nema svojstvo skupa, jer se odreene vrednosti mogu
ponavljati, pa nije mogua jednoznana identifikacija pojedinih elemenata.
Domen se moe definisati po IDEF1X metodologiji kao bazni - Svaki domen se
tretira kao podtip baznog domena. i tipski domen - Tipski domen se definie preko
svog imena, baznog domena i, eventualno, prostih ili sloenih ogranienja datih
odgovarajuim domen-pravilima (domain rules) kojima se definiu mogue
vrednosti u domenu.
36. Izbor SUBP treba da definie SUBP, gde e fizika ema biti kreirana i gde e se
specificirati default tipovi podataka, null opcije i druge default opcije koje se koriste za
generisanje kolona. Definisano je 12 pravila koji omoguuju da se oceni do kog je nivoa
neki SUBP relacioni. 1. Struktura SUBP se predstavlja samo tabelama. 2.Svaki podatak u
bazi podataka dostupan je preko kombinacije imena tabele, vrednosti primarnog kljua i
imena kolone, bez unapred zadatih pristupnih puteva i bez rekurzije ili iteracije.
3.Specifian indikator, razliit od "blanka" ("praznog") niza karaktera, nule ili bilo kog
broja, koristi se za predstavljanje nula vrednosti, bez obzira na tip podatka. 4.SUBP treba
da poseduje katalog (renik) podataka, koji se logiki predstavlja na isti nain kao i sama
baza podataka. 5.SUBP mora posedovati bar jedan jezik ije se naredbe mogu izraziti kao
niz karaktera sa dobro definisanom sintaksom i koji podrava: (1) definiciju podatka, (2)
definiciju pogleda, (3) manipulaciju podatka, interaktivno i kroz programe, (4) definiciju
pravila integriteta, (5) autorizaciju (sigurnost), (6) granice transakcija (BEGIN,
COMMIT, ROLLBACK). 6.SUBP treba da poseduje efikasan algoritam pomou koga
moe da odredi za svaki definisani pogled, u trenutku njegovog definisanja, da li se i koje
operacije odravanja mogu da primene na taj pogled. Rezultat takvog algoritma se smeta
u katalog baze podataka. 7.I nad tabelama i nad pogledima mogu se izvravati ne samo
operacije pretraivanja ve i operacije odravanja baze podataka. 8.Aplikacioni program i
interaktivna komunikacija treba da ostanu neizmenjeni kada se promeni fizika
organizacija baze podataka. 9.Aplikacioni program i interaktivna komunikacija ostaju
nepromenjeni kada se bilo koje promene, koje ne menjaju odgovarajui sadraj tabele,
unesu u baznu tabelu. 10. Pravila integriteta treba da se definiu u okviru definicije baze
podataka i uvaju se u reniku podataka (Ne implementiraju se kroz aplikacione
programe).11. Sve navedene karakteristike treba da budu nezavisne od distribucije baze
podataka. 12. Ako SUBP moe da radi sa nekim jezikom tree generacije, u kome se

obrauje jedan red tabele u jednom trenutku vremena, kroz taj jezik se ne mogu zaobii
pravila integriteta zadana preko samog relacionog SUBP.
37. Funkcije SUBP. Razlike izmeu SUBP i datoteka. Prva funkcija se koristi za
memorisanje i odravanje podataka, koji izraavaju svojstva tabela (objekata
posmatranja). Za izvoenje ove funkcije koriste se jezik za definisanje podataka i
struktura podataka (Data Definition Language ili DDL). Druga funkcija se koristi za
kontrolisan pristup do memorisanih podataka i prikazivanje podataka (vrednosti svojstava
tabela) na zahtev korisnika. Za izvoenje ove funkcije koristi se jezik za manipulaciju
podacima (Data Manipulation Language ili DML). Za razliku od rada sa datotekama,
korienje SUBP omoguuje da neprogrameri mogu pristupiti podacima radom sa
raunarom svakogi njima manipulisati: direktnim definisanjem obrade (obradu definiu
osobe koje se bavekorisnika,jednostavnim problema, a ne obradom podataka).fizikom
38.
SQL upitni jezik omoguuje da korisnici mogu ad hoc formulisati i postavljati
pitanja i veoma brzo dobijati odgovor, a da pri tom ne zavise od saradnje sa
programerom. Programeri su na taj nain rastereeni i posveuju se izradi kvalitetnih
programa za aplikacije, koje zahtevaju mnogo tehnikog znanja (npr., veoma frekventne
transakcije, kod kojih je vano da se postigne to krae vreme odziva). Neproceduralni
jezik SQL (Structured Query Language) dizajniran je tako da ga sa uspehom mogu
koristiti i ljudi bez tehnikih znanja s podruja obrade podataka, takozvani krajnji
korisnici. SQL jezik je neproceduralan, jer specificira operacije u smislu TA treba
uraditi, a ne KAKO. SQL je jezik za: interaktivno definisanje baze podataka,
pretraivanje podataka gde treba da se omogui izbor redova iz tabele, manipulaciju
podacima, upravljanje podacima.
39. Definisanje naina upravljanja podacima je bitna funkcija organizacije podataka koja
obuhvata: skladitenje,ime se podrazumevaju kontrolapod pristupa i adresiranja
podataka i nainredosleda upisivanja podataka, naini fizikog predstavljanja podataka;
ponovno pristupanje,tj. odreivanje podataka i odreivanjemesta nalaenja podataka
(adresiranje), formiranje redosleda podataka; kontrolu,tj. unutranje regulisanje toka
odvijanja odreivanje prava pristupa podacima, ime osiguravapostupka upravljanja
podacima, podatke da ne doe do gubitaka i obezbeuje aurnost podataka na sistemu.
integritet baze podataka, transakcionuUpravljanje podacima treba da podri:
oporavaksigurnost podataka, zakljuavanje podataka iobradu podataka, baze podataka.
40. Generisanje eme baze podataka izvodi se na osnovu definisanih elemenata za
izabrani SUBP. emu baze podataka ine fizike tabele, kolone i relacije, koje se,
kao to je reeno u prethodnom poglavlju, u CASE alatu automatski generiu iz
logikog modela. Takoe, u prethodnom poglavlju pokazani su i automatsko
kreiranje default tipova podataka za svaku generisanu kolonu i nain izmene
specifikacija kolona (domen i validacija podataka). Proces generisanja eme baze
podataka moe se izvesti na dva naina: direktnim inenjerstvom (forward
engineering) i/ili inverznim inenjerstvom (reverse engineering). Proces
generisanja eme baze podataka iz logikog modela podataka naziva se direktni
inenjering. Kada se generie ema baze podataka, entiteti prelaze u tabele,
atributi u kolone, a veze u relacije i definiu se referencijalni integritet, trigeri,
procedure, indeksi i druge osobine koje podrava izabrani SUBP. Inverzni
inenjering predstavlja proces dobijanja fizikog i logikog modela iz postojee
fizike baze podataka.

41. Kreiranje tabela kreiraju se tabele naredbom CREATE TABLE, koja definie
"praznu" tabelu sa nazivom i imenima kolona sa fizikog modela podataka datog u
ERwin-u. Podaci se kasnije unose INSERT naredbom ili iz razvijene korisnike
aplikacije. Opis tabela podrazumeva definisanje naziva tabele, naziva kolone (tip
podatka i ograni enje), odreivanje primarnog kljua i, po potrebi, definisanje
indeksa po bilo kojoj koloni ili grupi kolona u tabeli. Dakle, imena tabela i kolona se
automatski preuzimaju iz fizikog modela definisanog u ERwin-u, no ako se direktno
u SUBP definiu imena moraju se potovati sledea uputstva: koristiti biti dosledan
uopisna imena za tabele, kolone, indekse i druge objekte; korienju skraenica;
koristiti ista imena za opis istih tabela ili pisati nazive tabela ili kolona u
jednini.kolona;
42. Kreiranje indeksa definiu se indeksi naredbom CREATE INDEX za odreenu tabelu
nad jednom ili vie kolona neke tabele. Indeks sadri po jednu stavku za svaku razliitu
vrednost indeksirane kolone (ili kolona) u tabeli. U svakoj stavci indeksa pamte se fizike
adrese redova koji imaju datu vrednost u indeksiranoj koloni/kolonama. Indeksi se
implicitno koriste u sledeim sluajevima: kada se pretrauju tabele kada se izdvajaju
redovipo vrednostima indeksiranih kolona (WHERE uslov) i tabele u redosledu vrednosti
indesiranih kolona.
Indeks omoguava direktan pristup redovima i tako smanjuje vreme pristupa. Mogu se
kreirati vie indeksa za razne kombinacije kolona u istoj tabeli, ali svaki indeks uveava
vreme auriranja.
43.
Generisanje poslovnih ogranienja treba sagledati potrebu prilagoavanja
definisanog fizikog modela za konkretno realizovanu bazu podataka. Ogranienja mogu
biti definisana za tabele ili kolone i specificirana kao deo CREATE ili ALTER TABLE
komande u okviru SQL-a. Svrha ogranienja je da se definie rang validnih vrednosti.
Svaka INSERT, UPDATE, ili DELETE naredba se proverava vaeim ogranienjem.
Ogranienje mora biti zadovoljeno da bi naredba uspela. Generalno govorei,
ogranienjima se definiu domeni kolona, pravila referencijalnog integriteta (RI), pravila
integriteta tabela, kao i dodatna pravila poslovanja.
Ogranienje se definie kljunom rei CONSTRAINT i nazivom ime_ogranicenja kojim
se specificira ime ogranienja (da li je u pitanju primarni ili preneseni klju).
44. Definisani meniji treba da prate scenario odvijanja aktivnosti budueg korisnika. Za
definisanje menija moraju se koristiti odgovarajua pravila za strukturiranje kojima se
definie mogui redosled pozivanja operacija. Meniji treba da se definiu na takav
nain: da svaki meni ima koncizan naslov na vrhu; da meniji koji zauzimaju ceo
ekran budu balansirani; se razdvajaju liste opcija na vie celina; da se ogranii broj
izbora u meniju na jedan ekran; da se razmisli o selekciji menija; da se omogui
naputanje menija bez izbora bilo koje opcije; se koriste aktivne imenice za opis
opcija menija; se koriste nedvosmislene ikone; da se izbegava esto naglaavanje; da
se omogui korienje i malih i velikih slova, da se proveri tastatura pre upotrebe; da
se izabere jasna, optepoznata, kratka re za komande;
45. Definisanje izgleda forme. Ekranske forme treba da ispune sledee karakteristike: opte
kakrakteristike: svaka forma mora imati naslov; formi dati samo ono to korisniku treba;
obezbediti simetriju i balans na ekranu; u sluaju pojavljivanja vie formi, naznaiti u
kojoj se formi korisnik nalazi; omoguiti korienje malih i velikih slova u
tekstu;definisati praznu liniju izmeu svakog paragrafa;tekst poravnavati na levu

stranu;biti paljiv sa skraenicama i akronimima; tabele i liste: razbiti niz slova u krae
podnizove;liste reati u prepoznatljivom redosledu;koristiti vertikalne kolone, jer su
preglednije za itanje;tekst u kolonama poravnavati nalevo, a brojeve nadesno;svaka peta
linija treba da bude prazna linija;ostaviti bar dva mesta prazna izmeu kolona;numerisati
liste poev od 1, a ne od 0;redovi i kolone u listama moraju imati imena; naglaavanje:
biti dosledan u prikazima i naglaavanju;treptanje i zvuke upotrebljavati samo kao
alarm;naglaeni tekst treba da bude razumljiv;bolje birati iz sredine duginog spektra;ne
preterivati sa naglaavanjem; unos podataka: omoguiti korisniku da odustane od
unosa.grupisati polja po kategorijama i staviti nazive;ne unositi unapred poznate
podatke;u svakom polju obezbediti memorisanje polja;uvesti kad je mogue
podrazumevanu (default) vrednost;omoguiti help na nivou polja;omoguiti slobodno
kretanje meu poljima za unos podataka;forma je jedinica prenosa podataka;pri unosu
podataka iz formulara kopirati izgled formulara;
46. Vrednovanje softvera je podskup aktivnosti softverskog inenjerstva i moe se smatrati
sistemom, odnosno sistemom vrednovanja. Da bi se izvrilo vrednovanje, treba
specificirati zahteve, tj. definisati osnovne zahteve za funkcije i performanse i dati
potrebna ogranienja i dr. Kao poseban element izdvajaju se zahtevi za kvalitetom,
definisani kvantitativnim i kvalitativnim formulisanim zahtevima. To uslovljava i
formulisanje faktora kvaliteta koji je odlika ili karakteristika odreenog elementa.
Kvantitativna mera se izraava preko tzv. metrike kvaliteta. Rezultat vrednovanja je
ocenjivanje kao aktivnost primene odreenog dokumentovanog kriterijuma ocenjivanja
softverskog modula, paketa ili softverskog proizvoda radi odreivanja prihvatljivosti ili
putanja u eksploataciju softverskog paketa ili proizvoda.
47. Izmene u toku uvoenja Na osnovu definisanih primedbi izvode se izmene koje,
ako se koriste CASE alati, ostaju kao trag aktuelnoj elektronskoj dokumentaciji o
sprovedenim izmenama. Ako se izmene naprave u tabelama baze podataka,
automatski se sprovode iste izmene i u modelu podataka.
48. Izrada korisnikih uputstava. Izrada plana obuke. Korisnika uputstva mogu
biti opta uputstva za rad sa aplikacijom, kao i detaljna korisnika uputstva za
svaki programski sistem. Pored papira, treba da imaju i dimenziju On-line
dokumentacije. Dokumentacija mora da ima sledee karakteristike: dati
mogunost jednostavnog izbora i dr. oslovljavanje korisnika treba da bude u
drugom licu, uz korienje aktivnih glagola;pri opisu procedure treba
upotrebljavati jednostavne glagole;procedure se moraju opisivati logikim
redom;ne treba upotrebljavati izraze iz argona;treba izbegavati ale;pri pisanju
neophodni su jasni i koncizni izrazi.
Izrada plana obuke" je da su budui korisnici kompjuterski opismenjeni. Za ovu aktivnost
se napravi plan obuke po prioritetima uvoenja pojedinih modula ili podsistema.
49. Testiranje modula Kako su moduli povezani sa nizom nezavisnih komponenti, to se
zahteva provera svih specifikacija i konstrukcija vezanih za modul.
50. Testiranje podsistema. Razliite interpretacije specifikacija, obino, rezultiraju
problemima, pa ih treba uklopiti. Problematika na ovom nivou se pojednostavljuje ako su
korieni CASE alati gde je definisan jedinstven renik podataka I procesa i gde su veze
prikazane na grafiki nain. Osnovni koraci vezani za ovu aktivnost su:spajanje

modula,definisanje internih interfejsa,testiranje rada grupe modula,testiranje veze sa

eksternim interfejsima.
51. Testiranje integrisanog sistema zahteva od budueg korisnika da pripremi realne
podatke za upotrebu. Pri tom se testiraju: funkcionalnost, performanse, restart,
oporavak I funkcionisanje.
52. Testiranje u okruenju korisnika se, obino, zove alfa-testiranje ako je u pitanju
jedan korisnik, a ako se proizvod distribuira na mnogo mesta ili mnogo
pojedinaca tada je beta-testiranje. Test preuzimanja izvodi se u dva koraka:
definisanjem zahteva i specifikacija i
ispunjenjem uslova preuzimanja.
53. Praenje rada treba izvoditi kontinualno, sve dok ne bude potrebno da se izvede
zamena, jer informacije steene u toku tog praenja omoguuju da se odredi vrsta
promena, tj. na taj nain se izvodi tzv. kontinualno usavravanje. Mogu se na
osnovnom registrovanje nedostataka i dr.uraeni poslovi i transakcije,informacije
o vremenu,uitavanja,sati u upotrebi,nivou pratiti:
54. Ispravljanje greaka, pored ispravljanja greaka, prati se i odstupanje softvera, i
vri prilagoavanje korisniku i zadatku. Poboljanje sistema i dodavanje novih
funkcija" skoro uvek nastupa, jer korisnik ubrzo spozna nove mogunosti
sistema, pa ima nove zahteve vezane za poboljanjesistema. Dodavanje novih
funkcija ne mora da bude teko, ako su ispotovani prethodno opisani koraci.
55. Izmena hardvera i softvera posmatra se kroz softverske izmene vezane za
promenu SUBP, kao i hardverske izmene vezane za izgradnju mree u okviru
klijent/server-arhitekture.
Softverske izmene - Baza podataka i aplikacije, koje se na njoj temelje, podvrgnute su
estim promenama. Promene mogu biti izazvane razvojem opreme (npr., na tritu se
javlja efikasniji tip: memorije, terminala, procesora).
Harverske izmene - se odnose na nadgradnju mree u okviru klijent/server-arhitekture,
gde je mrea sredstvo za prenos podataka koje omoguuje razmenu poruka izmeu
aplikacije klijent (koja alje, prima i analizira podatke) i servera baze podataka (koji
obrauje zahteve za pristup bazi).
56. Struktura UML-a UML se sastoji od razliitih pogleda na arhitekturu (eng.
Architectural Views)
Pogled koritenja (eng. use case view) pokazuje problem i rjeenje onako kako ga vide
oni koji postavljaju problem.
Logiki pogled (eng. logical view) pokazuje strukturnu dimenziju problema i rjeenja.
Pogled paralelnog rada (eng. concurrency view) pokazuje behavioralnu dimenziju,
odnosno dimenziju ponaanja problema i rjeenja te se jo naziva i dinamiki pogled.
Pogled na komponente (eng. component view) pokazuje strukturnu dimenziju realizacije
rjeenja i njeno ponaanje te se jo naziva i pogled na komponente ili razvojni pogled.
Pogled postavljanja (eng. deployment view) pokazuje strukturnu dimenziju domene i
njeno ponaanje u kojoj je rjeenje ostvareno te se jo naziva i fiziki pogled ili pogled na
razmjetaj

59. Strukturalni elementi. Osnovni strukturni tipovi su klasa, interfejs, uesnik, sluaj
koritenja, komponenta I vor.
Klasa predstavlja skup objekata koji dijele iste atribute, operacije,relacije i semantiku.
Interfejs je skup poruka koji se moe poslati klasi i neukljuuje implementaciju tih
operacija.
Uesnik(Actor) je spoljanji krajnji korisnik.
Sluaj koritenja(use case) prikazuje jednu funkciju sistema kako jevidi spoljanji
uesnik.
Komponenta (component) je fiziki dio sistema koji je saglasan saskupom interfejsa i
prua njihovu realizaciju.
vorovisu obino fiziki elementi koji postoje tokom rada sistema(obino raunarski
resursi) koji u optem sluaju posjeduju memoriju.
60. Elementi ponaanja. Ovaj skup elemenata predstavlja dinamiki dio UML modela.
Dva su tipa stvari ponaanja.
Interakcija (interaction) je ponaanje koje obuhvata skup poruka kojese izmjenjuju
izmeu grupe objekata, a u sklopu odreenog konteksta iu cilju izvravanja specifine
svrhe.
Automat stanja(state machine)je ponaanje koje specificira slijedstanja objekta ili
interakcije kroz koje objekt prolazi tokom svog ivotnogvijeka, a kao odgovor na
odreene dogaaje
Grupiui elementi predstavljaju organizacijski dio UML. To su kutije u koje se
moerazloiti UML model. Postoji samo jedan tip grupiuih stvari, a to su paketi.Paket
(package) slui za organizovanje elemenata u grupe.
Elementi oznaavanja odnose se na dio UML za objanjenja. To su komentari
kojiopisuju, rasvjetljavaju i uvode napomene i ogranienja o elementima modela.Osnovni
element je beleka (note) koja se pridruuje elementu ili skupu elemenata.
61. Relacije. UML ima tri osnovne vrste relacija:
Zavisnost ( dependency) je semantika relacija izmeu dva elementa ukojoj promjena
jednog, nezavisnog, elementa moe da utie na semantikudrugog , zavisnog, elementa.
Asocijacijaili pridruivanjeje strukturalna veza koja opisuje vezu izmeu objekata.
Poseban sluaj asocijacije je agregacija, koja predstavlja strukturnu vezu celine i njenih
delova.
Generalizacija (generalizacion) je relacija specijalizacije/generalizacije u kojoj objekti
specijalizovanih elemenata, djeca, mogu da se zamijene objektima generalizovanih
elemenata, roditelja.
62. Dijagram klasa, dijagram objekata i paketni dijagrami.Dijagram klase opisuje
statiku strukturu sistema. Dijagram klasa daje pregled sistemapokazujui njegove klase i
odnose meu tim klasama.
Dijagram paketa - Paket je konstrukcija za grupisanje u UML-u. Paket dozvoljava da se
uzmu bilo kakve konstrukcije UML-a i grupiu u jedinice vieg nivoa. Najee se
koriste za grupisanjeklasa, ali mogu se koristiti za grupisanja ma kakvih elemenata u
UML-u.
Diajgram objekata - Slui za pojanjenje i ilustraciju sloenih dijagrama klasa.
Predstavljen je slikama objekata i njihovim meusobnim vezama u odreenom
vremenskom trenutku. Sastavljenje od objekata i linkova.

63. Razvojni dijagrami, dijagram stanja, dijagram aktivnosti i dijagram

komponenti.
Razvojni dijagrami pokazuju sistemsku fiziku postavku. Oni pokazuju koji delovi
softvera se izvravaju na kojim delovima hrdvera. Glavni elementi ovih dijagrama su
vorovi povezani komunikacionim putevima. vor je neto to moe biti domain
softveru. vor moe biti ureaj hardvera ili neka izvrna okolina (softver) koja opsluuje
drugi softver.
Dijagrami stanja slue za modelovanje dinamikih aspekta sistema.Dijagramima stanja
prikazuju se konani automati. Dijagram aktivnosti je specijalan sluaj dijagrama stanja
u kojem je prisutna veina stanja aktivnosti.
Stanje je situacija u ivotu objekta kada on zadovoljava neki uslov. Objekat ostaje u
nekom stanju u konnom vremenskom intervalu.
Dijagram stanja pokazuje odvijanje upravljanja od stanja do stanja. Obino modeluju
objekte koji reaguju.
Tranzicija pokazuje kretanje od jednog stanja ka drugom.
Dijagrami aktivnosti slue za modelovanje dinamikih aspekata sistema. Oni slue da
prikau: procedurlnu logiku, poslovni proces ili tok posla. Slini su blok-dijagramima za
opis algoritama (dodatno, podravaju paralelno ponaanje).
Dijagram komponenti (Component diagrams) modeluje strukturu softvera sa
zavisnostima izmeu izvormog koda, binarnog koda i izvrnih komponenti.