Projektovanje Informacionih Sistema - Odabrana Poglavlja

UNIVERZITET U NOVOM SADU
TEHNIKI FAKULTET "MIHAJLO PUPIN"

ZRENJANIN
ODABRANA POGLAVLJA
PROJEKTOVANJA INFORMACIONIH
SISTEMA
Autori:
Doc. dr Biljana Radulovi

Ljubica Eremi
Zoltan Kazi
Zrenjanin, jun 2002.

Radulovi dr B., Eremi Lj., Kazi Z. Odabrana poglavlja Projektovanja informacionih sistema
SADRAJ:
1. UVOD U INFORMACIONE SISTEME
1.1. DEFINICIJE OSNOVNIH POJMOVA
1.2. OSNOVNI ZAKONI OPTE TEORIJE SISTEMA
1.3. KLASIFIKACIJE SISTEMA
1.4. SISTEMSKI MODEL
1.5. METODA MODELOVANJA
1.6. MODEL UPRAVLJANJA KOMPLEKSNIM SISTEMIMA
1.7. SISTEMSKA ANALIZA
2. UPRAVLJANJE PROJEKTIMA - PROJECT MANAGEMENT

2.1. O PROJEKTIMA
2.2. PROBLEMI U PROJEKTOVANJU INFORMACIONIH SISTEMA
2.3. PODELA RAZVOJA INFORMACIONIH SISTEMA NA FAZE
2.4. PRINCIPI PROJEKTOVANJA IINFORMACIONIH SISTEMA
2.5. PROJEKTOVANJE INFORMACIONIH SISTEMA I BAZA PODATAKA
3. STRUKTURNA SISTEM ANALIZA

3.1. OSNOVNI KONCEPTI STRUKTURNE SISTEM ANALIZE
3.2. DIJAGRAMI TOKA PODATAKA
3.3. FUNKCIONALNA DEKOMPOZICIJA
3.4. RENIK PODATAKA
3.5. PSEUDO KOD
3.6. PRAVILA SSA
3.8. HEURISTIKE STRUKTURNE SISTEM ANALIZE
3.7. KREIRANJE IZVETAJA
4. PROJEKTOVANJE BAZE PODATAKA

4.1. MODEL PODATAKA

4.2. ALAT: DATA ARCHITECT
4.3. KLJUEVI ENTITETA
4.4. NORMALNE FORME I NORMALIZACIJA BAZE PODATAKA
4.5. USPOSTAVLJANJE VEZA IZMEU ENTITETA
4.6. PRAVILA KOD PREVOENJA E-R-A (MOV) MODELA U RELACIONI MODEL
PODATAKA
4.7. PODMODELI U KONCEPTUALNOM MODELU
4.8. POSTUPAK PREVOENJA LOGIKOG U FIZIKI MODEL PODATAKA
4.9. OGRANIENJA NAD BAZOM PODATAKA
4.10. GENERISANJE BAZE PODATAKA
5. PROGRAMIRANJE
5.1. DIZAJN APLIKACIJE
5.2. PROGRAMSKI JEZICI I ALATI
5.3. DIZAJNIRANJE KORISNIKOG INTERFEJSA
5.4. OSNOVNE FUNKCIJE U SOFTVERU INFORMACIONIH SISTEMA
5.5. ELEMENTI KORISNIKOG INTERFEJSA
6. PRILOG
PRIMENA UML dijagrama na primeru Projekta Galerija slika Zrenjanin
7. LITERATURA
1. UVOD U INFORMACIONE SISTEME
1.1. DEFINICIJE OSNOVNIH POJMOVA

SISTEM jasno izdvojen skup na odreen nain meusobno povezanih elemenata, koji po
nekoj zajednikoj odrednici ine sa svojim okruenjem skladnu celinu. [LN1]
OKRUENJE ine drugi sistemi koji sa datog aspekta ispoljavaju ili mogu da ispolje odreena
dejstva na posmatrani sistem ili su to sistemi na koje posmatrani sistem utie.
ELEMENT SISTEMA materijalni i idejni objekti koji pripadaju sistemu, od kojih zavise
osobine i ponaanja sistema. Granice sistema, delovi ili kriterijumi pripadanja odreuju
SISTEM.
STRUKTURA SISTEMA skup svih relacija meu elementima sistema. Kae se da relacija
snabdeva skup ili skupove strukturom.
INTERAKCIJA SISTEMA I OKRUENJA ostvaruje se dejstvom okruenja na sistem i

sistema na njegovo okruenje.
ULAZ SISTEMA uticaj okruenja na sistem, dejstvo (smer) prema posmatranom sistemu
(obeleja, vrednosti).
IZLAZ SISTEMA uticaj sistema na okruenje, dejstvo je od sistema ka okruenju.
OBELEJA svojstva, osobine, atributi (opisuju stanja sistema i procese koji se u njemu
odvijaju), parametri (opisuju sistem kao celinu konstante). Obeleja identifikaciona,
kvalitativna, kvantitativna, poziciona.
STANJE SISTEMA skup vrednosti obeleja sistema u odreenom trenutku.
VEZE statike i dinamike (promena u vremenu). Mogu biti izmeu elemenata, izmeu celine
i elemenata (kriterijum agregacije agregacija (grupisanje) po nivoima (komponovanje/
dekomponovanje)). Dinamike veze - aktivna dejstva, uticaji, tok: energetski, materijalni,
informacioni. Veze se prikazuju strelicom, smer dejstva (uzrok posledica).
PONAANJE (celine) niz vremenski uzastopnih stanja sistema. Ponaanje je ono to se

deava, to se deavalo i to e se desiti (to se moe i ne moe desiti). Ukupno ponaanje
sistema se manifestuje realizacijom funkcija, koje su meusobno zavisne, uslovljene (u relaciji
su zavisnosti). Ponaanje celine je odreeno ponaanjem elemenata i strukturom. Ponaanje
celine je odreeno prostorom funkcija koji sadi dva skupa skup funkcija i skup relacija meu
funkcijama.
FUNKCIJE su ishodi u deavanju. One su odreene: dinamikom, ishodom deavanja,

svrsishodnou, ulogom i strukturom. Bit funkcije je svrsishodnost, ispunjenje odreenih uloga.
Tri su osnovne globalne funkcije: bazina, f-ja razvoja i f-ja upravljanja. Funkcije realizuju
procesi, oni su samo deavanje prostora funkcija (skup, relacije).
PROCES posredno/neposredno opisuju ponaanje sistema, odrava dinamiku i funkcionisanje

sistema (osnovni zbog kojih postoji sistem, upravljaki i razvojni).
Osnovni procesi
- pripoda, osnovne uloge i funkcija objekta posmatranja
- ne menjaju strukturu
Razvojni procesi
- prevode sistem iz jednog razvojnog stanja u drugo
- promena strukture
- ostvaruju povoljnije uslove za izvoenje osnovnih procesa
Upravljaki procesi
- obezbeuju uslove za osnovne i razvojne procese, opstanak, stabilnost i usmeravanje na
postizanje nekog rezultata, stanja, ciljeva itd.
AKTIVNOST Prostor aktivnosti realizuje proces. Element sistema izvodi aktivnost. Prostor
aktivnosti (skup, relacije). Neophodno je identifikovati svaki resurs i svaku relaciju neophodnu
za izvrenje aktivnosti. Relacije meu aktivnostima vremenske i redosledne uslovljenosti.
OPERATORI pomou skupa operatora i skupa relacija meu njima realizuje se aktivnost.
TROKOVI angaovanje resursa za odreeno ponaanje ili promenu ponaanja sistema.
RESURSI SISTEMA pokretaka sila, osnovni inilac i preduslov za pokretanje i izvoenje

svih vrsta procesa u sistemu (energija, sredstva, predmeti, izvori...). Resursi mogu biti
materijalni, informacioni, finansijski, intelektualni itd. i troe se za odreeno ponaanje.
TRANSFORMACIJA SISTEMA niz prelaza stanja sistema pod dejstvom istog operatora.
Prikazujemo ta se deava a ne zato. Prikazujemo ponaanje bilo koji pojave.
RAVNOTENI PROSTOR skup stanja koja se cikliki ponavljaju.
OSNOVNE POSTAVKE TEORIJE SISTEMA:

Slinost razliitost sistema na odreenom nivou apstrakcije
- opta svojstva, ponaanje, opti odnosi
- sistemski zakoni i teorije (opti zakoni koji vae za razliite sisteme)
Posmatranje celine
- globalne karakteristike
- ukupnost svih razliitih aspekata (relevantnih) ...vreme, izvesnost
- sistemski pristup posmatranje objekta istraivanja sa svih relevantnih aspekata
Reavanje kompleksnih problema
- komunikacija razliitih nauka
- pojmovi, metode, instrumenti za ...
Izuavanje sistema
- struktura (statika) i ponaanje (dinamika)
- nastanak, razvoj, stagnacija, degradacija, prestanak, uzrok promena, nain
deavanja i posledice
KIBERNETIKA nauka o upravljanju sloenim dinamikim sistemima.
POSTUPCI (METODE):
Sveobuhvatnost (logike suprotnosti)
Apstrakcija (selekcija, kriterijum bitnosti, nivoi apstrakcije-obuhvat, detalji)
Uoptavanje (slinost, diferencijacija, uporeivanje)

Analiza (izdvajanje delova, rastavljanje)
Sinteza (integracija)
Modelovanje (preslikavanje osobina...)
Crna kutija
Idealizacija (hipoteze idealne osobine, vrsta apstrakcije, zanemarivanje realnih
ogrnienja, osobine i procesa)
Redukcija (zanemarivanje manje bitnih elemenata...)
Komponovanje
Dekomponovanje
PONAANJE promena (u vremenu) stanja sistema, neprekinuti niz stanja
STRUKTURA elementi, odnosi (relacije), ureenost i organizovanost
APSTRAKCIJA misaoni postupak, izdvajanje bitnog u skladu sa odreenim kriterijumima i

odbacivanja nebitnog, a zbog postizanja odreenog cilja (obrada odreenog dela stvarnosti ...)
MODEL pojednostavljena predstava o relevantnim karakteristikama sistema (svaka naa

predstava o sistemu). Izraava slinost.
Informacioni sistem je model realnog sistema u kojem deluje.

Projektovanje IS je modelovanje realnog sistema. [LN1]
MODELOVANJE proces apstrakcije putem kojeg se razvija model pri emu se izdvajaju
relevantni objekti i relacije a zatim se svakom elementu i relaciji pridruuju relevantna
obeleja.
IS je sistem u kojem se veze izmeu objekata (elemenata) i veze sistema sa

okolinom osvaruju razmenom informacija. IS postoji uvek, nezavisno od nivoa
tehnologije. [LN1]
METOD CRNE KUTIJE na osnovu istraivanja rezultata (izlaza) koji nastaju na osnovu
razliitih ulaza, upoznajemo sistem (nizom eksperimenata) i uoavamo pravilnost
zakonitost (ne ulazei u strukturu sistema posmatranje sistema kao celine).
OSOBINE SISTEMA:
skup elemenata
relacije izmeu elemenata (interakcija, odnos, zavisnost, uticaj, veza, sprega)
interakcije sa okruenjem (interne i eksterne)
hijerarhijska graa
ureenost red
organizovanost uloga elemenata u doprinosu ciljevima celine
atributi
integralne karakteristike (statike i / ili dinamike karakteristike)
celina, uloga elemenata u funkcionsanju celine
izdvojena od okruenja
moe da samostalno funkcionie
funkcionisanje (pravila, funkcija, zakon)
ponaanje niz stanja
stanje
procesi
ulaz / izlaz
cilj
OKRUENJE (sve to se nalazi izvan granica sistema):

- neposredno pod njegovim dejstvom sistem formira i putem njega manifestuje svoja
ponaanja
- posredno
KLASIFIKACIJA SISTEMA po Kenet Boulding-u:

1) nivo statikih struktura (skeleta) anatomija, struktura elementi i relacije (pasivni)
2) nivo satnih mehanizama - maine jedinstvani dinamiki sistemi sa determinisanim
ponaanjem, vreme
3) nivo termostata termostat informacije, sistemi sa upravljakim mehanizmima
4) nivo elija ivi organizmi razmena materije i energije, reprodukcija, odrava svoju
strukturu
5) nivo genetskih drutava biljke prilagodljivost, specijalizacija elemenata (elija) za
odreenu funkciju
6) nivo ivotinjskog sveta pokretljivost, znanje o sebi, obrada informacija
7) nivo oveka kao jedinke svest, apstrakcija, snalaenje, znanje
8) nivo drutva (organizacija) ovek u relaciji sa drugim ljudima u nekoj zajednici,
organizaciji
9) nivo transcedentalnih sistema hipoteze, nepotpuna znanja o njima
1.2. OSNOVNI ZAKONI OPTE TEORIJE SISTEMA

su zakoni koji vae za sve sisteme:
1) ZAKON ZAVISNOSTI TJ. RELATIVNE NEZAVISNOSTI
Svaki sistem je u statikoj ili dinamikoj zavisnosti od drugih sistema. U sluaju da je

nezavistan od bilo kog drugog sistema s jednog aspekta, od drugog nije (postoji bar jedan od
kog jeste). Zavisnost je apsolutna, nezavisnost relativna. Funkcionalna zavisnost elemenata
(obeleja) jednog sistema prema drugom.
STATIKE
STRUKTURE
DINAMIKE
NEZASVISNI SISTEMI sa jednog aspekta, sa drugog ne

ZATVORENI SISTEMI rast entropije, zakon odranja
2) ZAKON RAZLIKE (relativne jednakosti)
Razlike meu sistemima su apsolutne, jednakost je relativna.

Poveanje irine, smanjenje dubine Sve vie slinih sistema
Velik broj slinih sistema zajedniko obeleje raspodela po Gausu
3) ZAKON PROMENE (relativna stalnost)
- Stalnost je relativna, promena je apsolutna.

- Stalnost zahteva odravanje.
4) ZAKON NEPREKIDNIH PROMENA
1.3. KLASIFIKACIJE SISTEMA

PREMA FUNKCIONISANJU:
a) nain ispoljavanja pasivno, aktivno
b) trajanje konano , beskonano
c) izvesnost deterministiko, stohastiko, neizvesno
d) stabilnost stabilan, nestabilan, indiferentan
PREMA NAINU NASTANKA: prirodni, vetaki
PREMA POJAVNOM OBLIKU: realni, apstraktni
PREMA STEPENU SLOENOSTI: prosti, sloeni, veoma sloeni, kompleksni
PREMA POVEZANOSTI SA OKRUENJEM: otvoreni, zatvoreni,poluzatvoreni
PREMA KOMPLEKSNOSTI PONAANJA: samoreguliui (kompenzacija), adaptivni

(prilagoavanje), samoobuavajui (ui da pobolja budua dejstva), samorazvojni (sposobnost
poveanja efikasnosti prilagoavanja)
1.4. SISTEMSKI MODEL

1) Skup aspekata posmatranja
2) Globalna obeleja originala
obeleja celine
obeleja okruenja
obeleja interakcija celine i okruenja (ulaz / izlaz / resursi)
3) Za svaki nivo razlaganja (celina delovi)
- interes (misija, svrhe, ciljevi)
- izgraenost (podsistemi, elementi, statike strukture)
- ponaanje (funkcije, procesi, algoritmi, operatori)
osnovne, razvojne, upravljake
odravanje, razvoj, upravljanje, ponaanje
promena strukture
1.5. METODA MODELOVANJA

Slui za istraivanje sistema (pomoni objekat za eksperimente), obezbeivanje novih
informacija za prikazivanje znanja o sistemu.
pomoni objekat i subjekt modelovanja (SM)
slian realnom, apstrskcija
aspekt i kriterijum slinosti bitnost za 1) subjekt modelovanja, 2) za realan sistem
Def: Model je materijalni ili idejni sistem koji je usled aktivnosti i delovanja subjekta
modelovanja u nekoj realizaciji sa nekim originalnim sistemom i zamenjuje ga u ispitivanjima, u
saoptavanju znanja ili u reavanju problema. Relacije izmeu modela i originala su mogue po
spoljanjim osobinama, strukturi, ponaanju, funkcijama itd. []
1.6. MODEL UPRAVLJANJA KOMPLEKSNIM SISTEMIMA
I
Postavljanje cilja
Obezbeivanje sistema
za ostvarenje cilja
Aktiviranje i voenje
sistema do cilja
S
OBJEKAT
UPRAVLJANJA
1) Informacioni sistem
2) Postavljanje cilja u saglasnosti sa okruenjem i sa granicama
3) Obezbeivanje sistema za ostvarivanje cilja ili izbor raspoloivih sistema koji bi bili sposobni
da realizuju postavljeni cilj
4) Aktiviranje i voenje sistema do cilja pokrenuti sistem i voditi ga ka postavljenom cilju,
obezbediti stabilno ponaanje po projektu koji vodi od poetnog do ciljnog stanja.
METOD CRNE KUTIJE - za istraivanje sistema

posmatranje ulaza i izlaza ( serija ulaza praenje)
bez poznavanja strukture (ne moe se otvoriti)
saznati ponaanje, zakonitost (funkciju) ponaanja
1.7. SISTEMSKA ANALIZA

Sistemi se mogu posmatrati sa dva aspekta:
Statike (elementi, veze izmeu elemenata, struktura sistema)
Dinamike (funkcionisanje, ponaanje sistema, osnovne funkcije, procesi, aktivnosti,
operacije, stanja, resursi sistema)
Postavlja se pitanje "ta je sistemska analiza?"

Definicija sistema - jasno izdvojeni skup meusobno povezanih elemenata, koji po nekoj
zajednikoj odrednici ine sa svojim okruenjem skladnu celinu.
Definicija analize - misaoni postupak kojim se sistem rastavlja na elemente sa ciljem

izuavanja pojedinanih elemenata sistema.
Definicija sinteze - kreiranje celine od jednostavnih koncepata i ta novokreirana celina
poseduje nove generike osobine (ne samo zbir pojedinanih
karakteristika elemenata).
Spoj sistemska analiza je misaoni postupak analize sistema sa sledeim koracima:

1. Izbor objekta istraivanja
2. Odreivanje aspekata istraivanja objekta
3. Definisanje objekta istraivanja
4. Globalno ispitivanje objekta istraivanja
5. Razlaganje definisanog objekta istraivanja na elemente
6. Generisanje strukture definisanog objekta istraivanja
7. Definisanje kriterijuma istraivanja strukture
8. Istraivanje strukture
9. Istraivanje elemenata
10. Generisanje sistemskog modela
11. Ispitivanje i eksperimentisanje sa sistemskim modelom
12. Verifikovanje rezultata istraivanja
13. Odluka o ishodu procesa analize sistema
14. Primena sistemskog modela
U informacionim sistemima i teoriji sistema u postupku analize sistema posmatramo objekte i

sisteme preko procesa koji se u njima deavaju u vremenu sa postojeom organizacijom i sa
odreenom tehnologijom.
Primer: Posmatramo realan sistem u vremenu (student - prijava ispita - studentska sluba).
Student predaje ispitnu prijavu, dokument koji ima odgovarajui sadraj i strukturu, a u sutini
on hoe da prijavi ispit postojeom tehnologijom i organizacijom rada. Meutim postoji
mogunost promene organizacione strukture, promene rasporeda radnih mesta i preraspodele
slubi i promena tehnologije prijavljivanja ispita (prijava, pota, e-mail, web i sl.). Tei se
apstrakciji - izdvajanju procesa koji se deavaju u sistemu, a koji su nepromenljivi u vremenu.
Ove procese zovemo sutinskim procesima - to su procesi koji bi se odvijali u nekoj idealnoj
tehnologiji, tj. oni koji ne bi imali prostorna i vremenska ogranienja i ne bi bili vezani za neku
konkretnu tehnologiju i organizaciju. Sutinski procesi izraavaju svrhu postojanja sistema.
Takoe je bitno izdvojiti fizike od informacionih procesa. Primer - pregled pacijenta na
kod lekara (fiziki proces) i evidentiranje rezultata pregleda (informacioni proces).
Svaki proces se sastoji u izvravanju odreenog skupa aktivnosti koje se mogu desiti pre, u toku
i nakon izvravanja nekih aktivnosti.
u toku
pre posle
priprema evidentiranje i
izvetavanje
obrada
Za izvravanje procesa su potrebni neki podaci koje aktiviraju proces, zatim on vri odreenu
obradu podataka i izdaje rezultate obrade podataka. U ovakvoj analizi se procesi posmatraju
kao crne kutije poto ne ulazimo u strukturu procesa. Prilikom analize sistema vano je uoiti
kako su procesi meusobno povezani, kako utiu jedan na drugog, koji je redosled izvravanja
procesa i na koji nain jedan proces predstavlja osnovu za rad drugog procesa.
2. UPRAVLJANJE PROJEKTIMA (Project Management)
2.1. O PROJEKTIMA
Govori se o projektima, pa se postavlja logino pitanje TA JE PROJEKAT?
Projekat je:
nacrt (plan)
spisak aktivnosti (niz, red, resursi, sredina)
cilj (da bi se uradio neki posao, reio problem i sl.)
U literaturi se javljaju 3 vrste projekata:
1. IDEJNI
2. GLAVNI
3. IZVOAKI (DETALJNI)
IDEJNI projekat Sutina idejnog projekta je u predstavljanju postojeih problema trenutno
aktivnog informacionog sistema (IS) i naelni prikaz moguih reenja. Sledi odreivanje u kojoj
meri e novi raunarski podrani IS poboljati postojei IS. To se izraava kroz odnos:
T R O K O V I (za razvoj Is-a)
D O B I T (uteda, korist uvoenjem IS-a)
Glavni i izvoaki projekti su skupi i troe puno resursa, pa je zbog toga veoma visoka cena
njihovog realizovanja.
GLAVNI projekat - Sutina glavnog projekta je u detaljnom prikazu postojeeg stanja, analizi i
predlogu novog IS-a, koncept novog reenja i plan realizacije IS-a.
U informacionim sistemima razlikujemo 2 nivoa projektovanja: LOGIKO i FIZIKO. Idejni i

glavni projekti su na nivou logikog a izvoaki, tj. detaljni projekti na nivou fizikog
projektovanja.
IZVOAKI projekat Bavi se implementacijom (primenom, uvoenjem i korienjem) novog

IS-a, bavi se konkretno alatima za razvoj IS-a, kadrovima, organizacijom, programskim
zahtevima (strukturom programa, pravima pristupa, izgledom maski, radom sa maskama,
nainom izrade, bazom podataka, izvetajima i sl.)
Za upravljanje projektima se koriste posebni programi alati koji se jednim imenom zovu CASE
alati alati za softversko inenjerstvo. Naziv potie od poetnih slova sledeih rei:
Computer
Aided
Software
Engineering
CASE alati su najee metodoloki nezavisni - podravaju samo modele (Strukturna Sistem
Analiza, Model Objekti Veze, UML) i neke transformacije iz jednog modela u drugi, a mogu se
koristiti u razliitim metodologijama:
metodologije I generacije (metode funkcionalne dekompozicije, strukturno
projektovanje i strukturno programiranje),
metodologije II generacije (metode funkcionalne dekompozicije, Model Objekti Veze
(ER model), dvoslojna klijent server arhitektura, relacione baze podataka, jezici IV
generacije),
metodologije III generacije (objektni pristup, objektno orijentisani modeli, alati i
pristupi, troslojna (vieslojna) arhitektura distribuiranih softverskih komponenti, objektni jezici, i
objektno relacione baze podataka). [LN1]

Primeri CASE alata: ARTIST (Fakultet organizacionih nauka - Beograd), BPWIN (SSA) i ERWIN
(MOV , E-R-A), POWER DESIGNER, Oracle CASE, Rational Rose, Paradigm i sl.
Postavlja se pitanje: ta je informacioni sistem?
Definicija: IS je sistem u kome su elementi sistema povezani informacijama, tj. veze izmeu
elemenata sistema i veze sistema sa okruenjem se ostvaruju razmenom informacija.
PODATAK kodirana, zapisana injenica (zapis je niz simbola) o dogaaju, o nekoj

osobini objekta, o nekim pojavama i sl. Ta injenica je kodirana u nekom
skupu simbola sa nekim pravilima (azbukom). Na primer, 39,2 C.
INFORMACIJA - nastaje u glavi oveka, to je znaenje i vrednovanje podataka.
Informacija je protumaeni i vrednovani podatak sa ciljem da se preduzmu
upravljake akcije u sistemu. Na primer, 39,2 C vrednost obeleja
temperatura bolesnika i preduzima se akcija - terapija u ambulanti, bolnici
za izleenje pacijenta .
ZNANJE skup informacija doprinosi znanju, a najvanija osobina znanja je trajnost
informacije kod oveka.
Raunarski podran IS i aplikacije koje rade sa podacima nisu samo baza podataka i programi
koji opsluuju tu bazu, ve je neophodno da se podaci obrauju od strane korisnika, koji u
svojoj glavi stvaraju informaciju i koriste je za odluivanje!
S obzirom da postoje dva niova projektovanja IS-a (logiko i fiziko) i da je informacioni sistem
model nekog realnog sistema, realni sistemi se opisuju kroz:
STATIKU opisana je bazom podataka i modelom podataka. Jednoj logikoj strukturi

odgovara vie fizikih realizacija.
DINAMIKU opisana je funkcijama i procesima realnog sistema, tj. modelom procesa IS.
Razvoj informacionog sistema je ustvari prevoenje jednog nivoa informacionog sistema u novi
informacioni sistem, a tim razvojem se mora upravljati. Pri tome se mora voditi rauna o
injenici da se Project Management za informacione tehnologije u svetu veoma brzo razvija.
2.2. PROBLEMI U PROJEKTOVANJU INFORMACIONIH SISTEMA

Koji se problemi javljaju u razvoju informacionih sistema(IS)?
1. Problem SLOENOSTI POSTOJEIH SISTEMA (sektori, organizacione jedinice, slube i
sl.). Reava se na dva naina: podelom sistema na podsisteme (podceline) i podelom
razvoja informacionog sistema na faze u postupku projektovanja.
2. Problem KOMUNIKACIJE SA KORISNIKOM (poznaje problematiku poslovnog i
organizacionog sistema). Korisnik definie svoje potrebe i zahteve, a projektanti definiu
nain na koji e se potrebe korisnika zadovoljiti. Ovaj problem reava se korienjem
zajednikog, jednostavnog jezika simbola i grafikih oblika koji su dovoljno jednostavni i
razumljivi korisniku.
3. Problem OGRANIENJA (novac, vreme). Reava se tako to se za informacioni sistem
utvrdi logika struktura celog sistema (model) a implementacija (uvoenje i primena)
zatim sledi deo po deo (definiu se podsistemi za koje se odreuju prioriteti

implementacije).
4. Problem UPRAVLJANJA RAZVOJEM. U projektovanje informacionog sistema, kao deo
projektantskog tima je ukljueno najvie rukovodstvo organizacije, koje mora da da
podrku za uvoenje novog informacionog sistema. Problem se javlja u sluaju kada je
projekat uraen, projektantski tim je krenuo u realizaciju pojedinanih zadataka a
rukovodstvo organizacije se promeni ili se u toku vremena promeni organizaciona
struktura organizacije. Time se menjaju poetni uslovi koji utiu na zavretak posla.
Problem se reava postojanjem pisanog traga o zahtevima korisnika SPECIFIKACIJA
SISTEMA (Dokumenat kojim korisnik izraava svoje zahteve). Meutim kako korisnik ne
poznaje nove mogunosti informacionog sistema, specifikacija ne mora biti
nepromenljiva i konana jer korisnik ne mora da zna ta eli!
2.3. PODELA RAZVOJA INFORMACIONIH SISTEMA NA FAZE

Postoje razliiti pristupi razvoju informacionih sistema odnosno definisanju faza ivotnog
ciklusa softvera [MD]. Na ovom mestu se daje kratak prikaz metodologija projektovanja
informacionih sistema.
I GRUPA PRISTUPA RAZVOJU IS-a

a) LINEARAN (ivotni ciklus)
Sukcesivan sled faza u razvoju IS-a.

Nema povratka na prethodne faze.
Vrednovanje se deava na kraju razvoja.
Korisnik na poetku ne zna nove mogunosti IS-a.
Faze su sledee:
1. Planiranje razvoja
2. Analiza i specifikacija zahteva
3. Projektovanje
4. Implementacija
5. Odravanje
Linearnim - konvencionalnim modelom ivotnog ciklusa se razvoj informacionog sistema deli na

faze: planiranja razvoja (za ovo je poznata BSP - Business System Planning metoda kompanije
IBM), analiza zahteva i specifikacija informacionog sistema, projektovanje baze podataka i
projektovanje programa, implementacija (kodiranje, testiranje, uvodenje sistema u rad),
odravanje sistema i na kraju prestanak upotrebe. Ova metodologija razvoja informacionog
sistema je dola u krizu zbog haosa koji se stvara prilikom dvostrukog odravanja sistema
(paralelno odravanje sistema i dokumentacije), kao i zbog predugog ciklusa razvoja
informacionih sistema. Njen najvei nedostatak je to je korisnik upoznat sa informacionim
sistemom tek na kraju njegove realizacije (fizike implementacije), te su mogua velika
odstupanja kreiranog informacionog sistema u odnosu na realni sistem i oekivanja njihovih
korisnika.
b) PROTOTIPSKI
U ranoj fazi razvoja IS-a tei se razvoju
prototipa (poetne verzija koja se menja u
skladu sa korisnikovim zahtevima).
Postoji mogunost povratka na prethodne
faze u razvoju IS-a.
Javlja se problem uvoenja dokumantacije.
Javlja se problem integracije delova u
jedinstven IS.
Faze kod protipskog razvoja IS-a:

1. Planiranje razvoja
2. Analiza i specifikacija zahteva
3. Izrada prototipa
4. Implementacija
5. Odravanje
Zbog nedostataka konvencijalnog modela ivotnog ciklusa informacionog sistema, prelo se na

korienje takozvanog prototipskog razvoja. Osnova ove metodologije je da se napravi to je
mogue bre prototip softvera, da bi se na osnovu njega utvrdile potrebe korisnika. U
zavisnosti od toga da li se prototip nadgraduje ili ne, postoje odbacivi i nadgradivi prototipi.
Odbacivi prototip slui samo za utvrivanje potreba korisnika, odnosno za specificiranje zahteva.
Kada se ove potrebe utvrde, prototip se odbacuje, a na osnovu njega se ponovo izrauje ceo
informacioni sistem.
Ovakvi prototipi se obino rade koristei jednostavne, all ne i efikasne generatore aplikacija ili
jezike etvrte generacije kojima je lako opisati sistem i brzo napraviti prototip koji priblino radi
ono to je zahtevano. Na osnovu odbacivog prototipa se vri projektovanje sistema koristei
konkretne alate, klasine programske jezike ili neki od sistema za upravljanje bazom podataka.
Za razliku od odbacivog prototipa nadgradivi prototipi se usavravaju i koriguju i u nekoliko
iteracija dovodei do konanog reenja. Nedostatak prototipa je manjak dokumentacije, jer se
esto dokumentacija ne pie prilikom razvoja prototipa. Takode, prototip celog sistema se ne
moe napraviti, pa se zbog toga pravi vie manjih prototipa (prototipi podsistema), koji mogu
dovesti do haosa. Reenje se nalazi u prvobitnom projektovanju zajednike baze podataka za
sve prototipe koja obezbeuje koordinirani razvoj sistema. Ovakav nain izrade prototipa je
poznat kao DATA DRIVEN (voen podacima) prototip.
Takoe, korisnici se aktivno ukljuuju u sam proces izrade prototipa, pa su i manje greke u
projektovanju i realizaciji sistema. Od korisnika se, u ovom sluaju, zahteva poznavanje
metodologije projektovanja IS-a, i uopte, osnovni pojmovi o informacionim sistemima i
informaciono-komunikacionim tehnologijama.
c) TRANSFORMACIONI
Ukljuuje u sebe dobre osobine linearnog i prototipskog pristupa u razvoju IS.
Zasnova se na postojanju alata za brzi razvoj IS-a.
Specifikacija zahteva je na jeziku koji je blizak korisniku, a sam alat generie
programski kod.
1 2 5
4
Faze su sledee:
1. Analiza zahteva
2. Formalna specifikacija
3. Validacija specifikacije
4. Odravanje
5. Automatska optimizacija
Prototipski razvoj informacionih sistema nije bez mana, mada u mnogome smanjuje vreme
potrebno za izradu informacionog sistema a time i poveava produktivnost softvera. Ipak,
postoji metoda kojom se to ini jo bolje. Ova metoda je poznata kao operacioni, ili transfor-
macioni razvoj informacionog sistema, a i softvera, uopte. Sutina ovog naina razvoja softvera
je u korienju alata koji na osnovu specifikacije problema sami generiu reenje, odnosno
program u odreenom programskom jeziku. Takvi alati se nazivaju CASE (Computer Aided
Software Engineering). Ceo proces se svodi na postavljanje analize zahteva na osnovu koje
se izrauje formalna, izvriva specifikacija, odnosno prototip koji se pomenutim alatima
transformie u radni kod, odnosno program. Prepravke, tanije validacija i odravanje modela
se vre nad formalnom izvrivom specifikacijom (prototipom), a zatim se, da bi se dobio radni
kod (koji je mogue izvriti na raunaru) vri ponovna transformacija.
II GRUPA PRISTUPA RAZVOJU IS-a

TOP DOWN (od vrha ka dnu) i BOTTOM-UP (od dna ka vrhu) sastoje se u odluci
kako da se krene u razvoj informacionog sistema. Predlog je da se kao dobar pristup
koristi top-down kod analize i projektovanja informacionog sistema (svrha postojanja
sistema, cilj, celine itd.) a bottom-up da se koristi kod implementacije (uvoenje IS-a
deo po deo, celina po celina).
III GRUPA PRISTUPA RAZVOJU IS-a
Zasniva se na sledee dve podele:

1. STRUKTURNO - projektovanje, dizajn i programiranje. Definiu se procesi i
funkcije koje vri sistem.
2. OBJEKTNO atributi (osobine) i metode (procedure i funkcije). Pri razvoju IS-a
treba definisati objekte u sistemu (elemente, veze izmeu elemenata i sl.) i
procedure i funkcije koje se deavaju nad tim objektima, koje su veze izmeu
objekata. Realizacija funkcija i procedura se ostvaruje preko poziva odgovarajuih
metoda.
IV GRUPA PRISTUPA RAZVOJU IS-a
1. SISTEMSKI (totalni) svi podsistemi se istovremeno razvijaju i implementiraju.

Zahteva izuzetno mnogo vremena i novca.
2. PARCIJALNI (ad hoc) ne vodi rauna o sistemskom pristupu jer se razvija i
implementira samo jedna sluba, sektor ili organizaciona jedinica. Komunikacija sa
ostalim delovima IS-a i integracija sa globalnom bazom podataka se ostvaruje kad se
ukae potreba.
3. MODULARNI udruuje oba ova pristupa. Definiu se MODEL PODATAKA I MODEL
PROCESA na nivou cele organizacije.
1 2
BP
3 4
2.4. PRINCIPI PROJEKTOVANJA IS-a

1. VREME potrebno je posmatrati promene u realnom sistemu u vremenu i omoguiti
stabilnost IS-a postie se ADAPTIBILNOU, tj. parametrizovanjem aplikacija,
uoptavanjem realnih objekata, ifarnicima u bazi podataka.
2. KORISNIK cilj projektovanja i implementacije IS-a su ZADOVOLJENJE SPECIFIKACIJE
ZAHTEVA KORISNIKA koji zna ta eli a ne zna da to realizuje. Zadovoljenje ovog
principa se postie kroz odgovarajui pristup u projektovanju, kroz uee rukovodstva u
projektovanju i kroz obuku korisnika za rad u novom sistemu.
3. PROJEKTOVANJE ODOZGO A IMPLEMENTACIJA SA DNA sistem se sagleda kao
celina, podeli se na podsisteme, projektuje i zatim se implementira jedan po jedan
podsistem sa uvaavanjem injenice da podsistem nije izolovan, ve pripada celini.
4. EKONOMINOST obezbediti IS-u da zahteva minimum utroka vremena i novca u
fazi PROJEKTOVANJA, IMPLEMENTACIJE I KORIENJA. Ovaj princip podrazumeva
USER FRIENDLY korisniki interfejs, ime se poveava produktivnost rada korisnika
sistema.
5. STANDARDI meunarodni sistem standarda ISO 9000 - 3 Razvoj softvera u praksi
ISO/IEC 12207 Faze i aktivnosti ivotnog ciklusa razvoja softvera, Objektno orijentisani
dizajn softvera i ISO/IEC 9126, Information Technology Software Product Evaluation
Quality Characteristics and Guideline for their Use. Ovaj princip podrazumeva i
definisanje standarda i propisa u konkretnoj oblasti primene sistema. Softveri IS-a
trebaju da imaju podrku za standarde, a da nisu promenljivi u vremenu, trebaju da
poseduju standardizovane maske, ekrane, izvetaje i sl.
DEKOMPOZICIJA SISTEMA vri se na vie naina:

a) funkcijama (procesima)
b) postojeom organizacionom strukturom
c) objektima
d) strukturom podataka
Udruivanjem a) i d) dobijamo logiku strukturu IS-a. Formira se matrica SUTINSKIH

PROCESA (sortiranih prema ivotnom ciklusu osnovnog objekta obrade) i KLASA
PODATAKA (objekti). Grupisanjem preseka u ovoj matrici dobijaju se podsistemi
postojeeg IS-a koji su sutinski za njegovo izvravanje.
2.5. PROJEKTOVANJE INFORMACIONIH SISTEMA

I BAZA PODATAKA
Baza podataka je statika slika modela podataka jednog informacionog sistema. Tano je da je
model podataka a pogotovo njegov deo koji se odnosi na bazu podataka vrlo bitan za ceo
informacioni sistem. Tano je da bez dobro projektovane baze podataka informacioni sistem
nikako ne moe biti dobro projektovan, ali projektovanjem baze podataka jo uvek nije reen
ceo problem. Baza podataka je statika slika modela podataka, odnosno slika informacionog
sistema u jednom trenutku. Bazom podataka se ne mogu izraziti ogranienja modela podataka
(bar ne kod klasinih modela, kao to su hijerarhijski, mreni i klasini relacioni), tako da je njih
potrebno implementirati aplikacijom.
Konzistentnost baze podataka obezbeuju posebni mehanizmi u okviru sistema za upravljanje

bazom podataka. Postoje dve grupe mehanizama za kontrolu konzistentnosti baze podataka. To
su:
pasivni mehanizmi, koji samo spreavaju takve promene sadraja baze podataka, koje
bi naruile uslove integriteta i
aktivni mehanizmi, koji odravaju propisane odnose izmeu podataka o razliitim
entitetima tako, to menjaju podatke o jednim entitetima, kada se menjaju podaci o
drugim. [ML]
Ovakva ogranienja su vaila do poetka 90-tih godina, sve do uvoenja aktivnih sistema baza
podataka. Prvi pristupi ukljuivanja aktivnih komponenti sreu se dosta rano i u razliitim
oblastima. U programskim jezicima je to obrada izuzetaka (exceptions), a u sistemima vetake
inteligencije to su demoni (daemons). CODASYL (mreni) model podataka podrava procedure,
koje su memorisane u bazi podataka, a pozivaju se na sledei nain:
ON STORE CALL <procedura>;

ON ERROR DURING MODIFY CALL <procedura>.
Relacioni sistemi omoguuju definisanje iskaza I trigera (Standardi SQL2-1992. i SQL3-1999.),

definisanje pravila (INGRES Knowledge Management System) ili deliminu podrku transakcija
(Sybase Transact SQL Enhancements). [MZ]
Aktivnu bazu podataka ine baza podataka i skup aktivnih mehanizama za praenje stanja
baze podataka. Aktivni mehanizmi reaguju na nedozvoljene promene stanja, bilo na takve
promene, koje trae neku akciju. [ML]
U SQL-92 standardu (ISO/IEC 9075:1992, Information Technology Database Languages

SQL ili ANSI X3.135-1992, Database Language SQL definiu se naredbe za:
deklarisanje integriteta domena putem opisa domena (naredba CREATE DOMAIN),
deklarisanje ogranienja u okviru opisa eme relacije (naredba CREATE TABLE), i
deklarianje optih ogranienja (naredba CREATE ASSERTION).
U standardu SQL3 se iskazi i trigeri definiu na sledei nain:
CREATE ASSERTION <naziv_iskaza>

{BEFORE COMMIT
AFTER {INSERT DELETE UPDATE [OF <lista_kolona>]}
ON <tabela>
CHECK <predikat> [FOR EACH ROW]
CREATE TRIGER <naziv_trigera>

{BEFORE AFTER} {INSERT
DELETE
UPDATE [OF <lista_kolona>]} ON <tabela>
[REFERENCING OLD AS <staro_ime>
NEW AS <novo_ime>]
[WHEN <predikat>]
<lista_naredbi> [FOR EACH ROW OF <tabela>]
Na osnovu sintakse navedenih naredbi moe se zakljuiti da se dogaaji odnose iskljuivo na

operacije nad bazom podataka, da uslovi proveravaju vrednosti atributa u bazi podataka i da su
akcije iskazane u terminima operacija nad bazom. Takoe, mogue je naredbom CREATE
TRIGGER referenciranje i starih i novih vrednosti u bazi, a opcija FOR EACH ROW omoguuje
obradu cele tabele, a ne samo jedne torke.
INGRES DBMS poseduje komponentu za upravljanje znanjem INGRES Knowledge

Management, koja omoguuje definisanje pravila:
CREATE RULE <naziv_pravila>

AFTER {INSERT
DELETE
UPDATE [<naziv_kolone>]} [,]
[ON OF FROM INTO] <tabela>
[REFERENCING [OLD AS <staro_ime>]
[NEW AS <novo_ime>]]
[WHERE <predikat>]
EXECUTE PROCEDURE <naziv_proc>
[(<parameter>=<vrednost>[,])]
Najpoznatiji objektno orijentisani sistem za upravljanje bazom podataka, koji podrava Event
Condition Action pravila je HiPAC (CCA/XAIT, Univ. Wisconsin). Pored njega tu su i: CPLEX
(Harvard Univ.), ODE (AT&T Bell Labs).
Najpoznatiji predstavnici aktivnih sistema, koji se razvijaju kao nadgradnja relacionih sistema
su: POSTGRES (Univ. Ca Berkley) i Starburst (IBM Almaden).
Implementacija standarda za deklarativno definisanje ogranienja zavisi od konkretnog

proizvoaa sistema za upravljanje bazom podataka. U samom standardu definisana su tri nivoa
pokrivenosti standarda od strane konkretnog SRBP-a:
prvi nivo entry SQL,
drugi nivo intermediate SQL,
trei nivo full SQL.
Najvei broj komercijalnih SRBP-a podrava samo prvi nivo implementacije SQL standarda sa
nekim elementima drugog ili treeg nivoa. Sistemi za upravljanje bazom podataka, koji ne
podravaju u potpunosti ni prvi nivo implementacije SQL standarda, deklaraciju uslova
integriteta ograniavaju na proveru duine i tipa podatka odreenog obeleja, proveru da li
domen obeleja moe ili ne moe da sadri nula vrednosti i proveru jedinstvenoti kljua eme
relacije.
S obzirom da veina komercijalnih SRBP-a ne podrava vei deo deklarativne implementacije

ogranienja u bazi podataka, to je potrebno omoguiti njihovu proceduralnu specifikaciju
(pisanje procedura i funkcija i trigera). Procedure baze podataka su programi, koji se uvaju u
bazi podataka, i oni su po pravilu, kompleksni, kompilirani i optimizovani. Zato je bolje koristiti
okidae (trigere). Izvrni deo okidaa je korektan blok PL/SQL naredbi sa ugraenom logikom
provere ogranienja. SRBP-i ne uvaju telo okidaa u prevedenom obliku, kao to je to sluaj sa
procedurama i funkcijama. Kada se okida pokrene, SRBP uita deklaraciju okidaa, prevede je,
smesti u zajedniku radnu memoriju i izvri.
Procesi i postupci koji se odvijaju u realnom sistemu (dinamika sistema) koji treba predstaviti
modelom, informacionim sistemom, se opisuju modelom procesa. Model procesa je, u stvari,
onaj deo informacionog sistema koji predstavlja skup aplikacija, programa koji operiu bazom
podataka. Projektovanje informacionog sistema nije nimalo jednostavan posao. Pod
projektovanjem informacionog sistema ne podrazumeva izrada nekih ad-hoc softvera, kao to je
voenje evldencije video kaseta i korisnika u jednom video klubu, mada i programeri koji su ra-
dili ovakve poslove znaju do kakvih problema moe doi prilikom definisanja korisnikog
zahteva. Vrlo esto se po izradi programa utvrdi da to u stvari nije ono to je korisnik
zahtevao?!. U svetu su ak razraene metode kojima se od korisnika izvlae podaci potrebni
za definisanje zahteva, pa i realizaciju informacionog sistema. Osim problema koji se odnose na
definisanje zahteva, u projektovanju informacionog sistema javlja se i problem sloenosti
sistema. Da bi problem postao savladiv, mora se razloiti na vie jednostavnijih. To se moe
uraditi na dva naina. Jedan od njih je podela razvoja informacionog sistema na faze.
Drugi nain savladavanja sloenosti je dekomponovanje sistema u manje podsisteme. I ovo

dekomponovanje se moe izvriti na vie naina. Posmatrajui preduzee kao sistem za koji se
najee i pravi informacioni sistem, dekompoziciju sistema je mogue uraditi na tri naina:
1. Dekompozicijom slstema na osnovu organizacione strukture
2. Funkcionalnom dekompozicijom
3. Objektnom dekompozicijom
Prvi nain dekomponovanja sistema se vri prema ve postojeoj organizacionoj strukturi

preduzea. Na ovaj nain se pravi vei broj podsistema i to na primer, za svako odeljenje
preduzea ili neku drugu funkcionalnu ili teritorijalnu celinu, zavisno od vrste organizacione
strukture. Na alost, ovakav nain projektovanja informacionog sistema je vrlo nestabilan, iz
jednog vrlo jednostavnog razloga - organizaciona struktura u preduzeu nije neto to se
projektuje jednom zauvek i nikada vie. Organizaciona sturktura preduzea se, naprotiv, vrlo
esto menja. U tom sluaju dolazi i do potrebe preprojektovanja celog informacionog sistema.
Bolji nain dekomponovanja sistema je onaj po funkcionalnoj osnovi. Funkcije u preduzeu

(planiranje, nabavka, proizvodnja (pruanje usluge), realizacija (prodaja gotovog proizvoda),
kadrovi, sistem kvaliteta) su znatno stabilnije od njegove organizacione stukture, all ipak
dovoljno nestabilne. I one se vrlo esto menjaju kao posledica razvoja tehnologije, a pogotovo
njihov nain izvravanja. Funkcionalna dekompozicija sistema se odlino uklapa i u koncept
klasinog programiranja jer je celokupan nain razmiljanja algoritamski, ali se na taj nain,
ipak, ne otkriva sutina sistema.
Najstabilnija dekompozicija sistema je ona koja je bazirana na objektima u sistemu i njihovim

medusobnim vezama. Objekti u sistemu su vrlo stabilni i veze medu njima, kao i operacije koje
se nad njima obavljaju su, takode, veoma stabilne. Praktino, menjaju se samo spoljni naini
komponovanja, odnosno funkcije u ststemu. Ovaj nain dekomponovanja se odlino uklapa i u
objektno programiranje koje omoguava (izmeu ostalog) i koncept nasleivanja kojim se
postie mogunost ponovnog korlenja ve projektovanih stvari (reusability) a time se znatno
poveava i produktivnost softvera - smanjuje se vreme potrebno za njegovu izradu. Najpoznatlji
nain za objektno dekomponovanje sistema je ERA model (Entity Relationship Atribute), ili ER
model, a kod nas esto pominjan kao MOV (model objekti-veze) ili ak PMOV (proireni model
objekti-veze) [LN1].
U sadanjim trenucima najbolji nain razvoja informacionih sistema te softvera, uopte, je

objektno orijentisana transformaciona metoda razvoja, dakle kombinacija operacione,
transformacione metode i objektne dekompozicije sistema. Iz svega se moe izvesti zakljuak
da ustvari, oblast baza podataka nije oblast koja postoji sama za sebe, ve da je ona deo jedne
ire problematike, problematike projektovanja informacionih sistema. Baza podataka je samo
osnova za izgradnju informacionog sistema, drugim reima, njegov temelj. Koliko je slab temelj,
toliko e biti slaba i cela konstrukcija (a moda i slabija). Zato baza podataka mora biti dobro
projektovana da bi na osnovu nje moglo da bude izgradeno i sve ostalo. Ukoliko je model
podataka korektno projektovan, na osnovu njega se moe izgraditi i dobar model procesa, ali
ako je model podataka slab, i sve ostalo e biti slabo, bez obzira na to koliko je konaan
proizvod aren, skladno obojen, sa zvunim efektima ili bez njih, i da li radi u Windows
okruenju ili van njega.
3. STRUKTURNA SISTEM ANALIZA
3.1. OSNOVNI KONCEPTI STRUKTURNE SISTEM ANALIZE

Strukturna sistem analiza (SSA) je najzastupljenija i najpopularnija metoda za modeliranje
procesa u projektovanju IS-a. Autori su ordan (E. Yourdon) i Konstantin (L. Constantine) sa
saradnicima, '70 tih godina, ali je pretrpela izmene do danas - DeMarko (T. DeMarco),
MakMenamin (S. McMenamin), Palmer (J. Palmer, Ros (D. Ross) i drugi.
Slui za definisanje specifikacije zahteva korisnika prikazuje ta IS treba da radi, a ne kako i

bazira se na funkcionalnoj dekompoziciji procesa uoenih u sistemu koji se analizira. Sadri
dokumentaciju i grafike elemente koji treba da budu jasni i korisniku i projektantu.
Osnovni elementi SSA:

1. Dijagram toka podataka - DTP
2. Renik podataka - RP
3. Opis logike primitivnih procesa (Pseudo kod, Stabla i tabele odluivanja, Dijagrami
akcija)
3.2. DIJAGRAMI TOKA PODATAKA - DTP

Osnova je grafiki prikaz koji sadri sledee elemente:
Interfejs kao elemenat predstavlja neki sistem iz okruenja sa

kojim posmatrani sistem razmenjuje podatke i to putem tokova
podataka (izvor i uvir podataka).
Proces (obrade podataka) su sutinski procesi nekog realnog

sistema i mogu se grupisati u 4 vrste procesa:
1. Osnovni ili sutinski procesi
2. Upravljaki procesi
3. Razvojni procesi
4. Procesi za odravanje
Obeleava se sa dva broja (prvi je broj procesa, a dugi o
redosledu izvravanja procesa).
Tok podataka predstavlja apstaktni kanal putem kojeg teku

podaci u kontinuiranom vremenu. Treba da je nezavistan od
tehnologije i organizacije. Smisao tokova podataka je da
omogue rad procesa i nezavisni su od medija i tehnologije.
Skladite podataka je tok podataka u mirovanju, i predstavlja

apstrakciju koja slui za smetanje podataka radi njegovog
ponovnog koritenja. Procesi su zadueni za smetanje podataka
u skladita. Svi elementi SSA se moraju imenovati. To ime je
neprekidan niz simbola. Poeljna su duga imena.
Konektor - spaja dva ili vie tokova podataka u jedan ili

razdvaja jedan tok podataka u nekoliko pojedinanih.
Prvi korak u kreiranju novog modela procesa jeste pokretanje alata ProcessAnalyst koji
inicijalno otvara nov model, kreira prvi prazan DTP i otvara paletu alata za modeliranje
procesa:
Proccess Analyst je alat Power Designer CASE alata namenjen izradi modela jednom od 4
ponuene metodologije:
Object Modeling Technique (OMT) functional model
Yourdon/DeMarco
Gane & Sarson
Structured System Analysis and Design Methodology (SSADM)
Izabrati File Model Options:

Na kartici General izabrati Method: Yourdon/DeMarco za klasinu SSA i otkaiti Context model u
sluaju da je dijagram koji elimo nacrtati kontekst dijagram, kako bi njegova oznaka bila 0.
Postaviti, takoe, Auto fill svojstvo na True, kako bi CASE alat automatski punio skladita
podataka elementarnim podacima.
Sledei korak jeste podeavanje osobina celog modela procesa, izborom sledee opcije iz
glavnog menija ProccessAnalyst-a:
Dictionary Model Properties
Na ovom ekranu se unose podaci o:

Nazivu i identifikatoru projekta (Project Name & Code)
Nazivu i identifikatoru modela (Model Name & Code)
Autoru (Author)
Verziji (Version)
Opisu dijagrama/modela (Label)
Datumu kreiranja modela (odreuje sam CASE alat na osnovu sistemskog datuma)
Paleta sa osnovnim objektima (Tools) za crtanje DTP-a ima sledee opcije, tj. alate:
lupa selektovanje objekata
osobine objekata zumiranje dijagrama
proces prevlaenje objekata
skladite podataka dekompozicija
konektor interfejs
grafiki objekti tok podataka

CRTANJE DIJAGRAMA
Dijagrami tokova podataka se crtaju jednostavnim nanoenjem objekata sa palete alata (Tools)
na radnu povrinu dijagrama. Sledi definisanje osobina objekta (engl. properties) preko dijaloga
kao na slici ispod, koji se otvara dvostrukim klikom na izabrani objekat ili primenom alata
Properties sa palete alata.
Bira se kartica Definition i upisuju sledee osobine:
1. Ime objekta (Name) - Imena su u ovom kontekstu naslovi ali ne identifikuju objekte,
jer u modelu procesa, tj. njegovom reniku podataka mogu postojati razliiti objekti sa
istim imenom. Ova injenica je, naravno, u suprotnosti sa pravilom SSA da svaki objekat
mora imati raziliit naziv. Inicijalno je maksimalna duina naziva objekta 80 karaktera,
ukljuujui velika, mala slova te karaktere ... Korisnik CASE alata moe promeniti ove
dozvoljene simbole ...
2. Kod objekta (Code) kodna imena objekata jesu zapravo jedinstveni identifikatori
svih objekata u projektu, modelu i reniku podataka. Inicijalno, kodna imena imaju 80
karaktera maksimalno i ukljuuju samo velika slova.
3. Oznaka objekta (Label) - Oznaka opisuje model ili objekt i obezbeuje neto vie
informacija nego ime ili kod. Labele su opcione, tako da polje moe ostati nepopunjeno.
U kartici Description se unose opisi modela, procesa, interfejsa ... Opis obezbeuje detaljne
informacije o modelu ili objektima koje model sadri. Na primer, opis spoljneg objekta Student u
modelu Studentska sluba glasi: Osoba koja se u pocetku javlja studentskoj sluzbi samo kao
kandidat za upis na nekom od smerova fakulteta. Oni koji steknu uslove, postaju studenti.
Zatim pohadjaju nastavu, polazu ispite i u toku svog skolovanja postavljaju odredjene zahteve
studentskoj sluzbi. Opis je slobodan tekst.
Napomena Anotation sadri napomene koje se tiu objekata na koje se odnosi. Napomena je,
takoe, proizvoljan tekst od nekoliko redova.
Osobine procesa:
Prozor koji odreuje osobine tokova podataka, za razliku od interfejsa i procesa, ima karticu
Data Items u koju se unose elementarni podaci koji ine taj tok.
U zavisnosti od tipa toka podataka, proces moe uraditi sledee operacije (Operations) na
objektima u skladitu podataka:
C - Kreiranje podataka u skladitu podataka (Create).
R - itanje podatka iz skladita podataka (Read). Inicijalno za tokove koji izlaze iz skladita
podataka.
U - Auriranje podataka u skladitu (Update). Inicijalno za tokove koji ulaze u skladite
podataka.
D - Brisanje podataka iz skladita podataka (Delete).
Nakon definisanja naziva, koda i oznake toka podataka, pristupa se unosu elementarnih
podataka koji su pored imena i koda odreeni i tipom podatka (kolona Type):
Tip podatka se odreuje tako to se klikne na taster u polju Type, nakon ega se otvara sledei
prozor na kome se preko Option Button-a bira tip podatka, a za neke tipove unose i duina
(Length) i preciznost (Precision):
Pregled tipova podataka:
Numeriki tipovi podataka

Integer Celobrojni
Short Integer - Celobrojni (manjeg opsega)
Long Integer - Celobrojni (veeg opsega)
Byte Celobrojni (nenegativni, najmanjeg opsega)
Number - Brojevi sa fiksnim decimalnim zarezom
Decimal - Brojevi sa fiksnim decimalnim zarezom
Float - Brojevi sa pokretnim zarezom
Short Float - Brojevi sa pokretnim zarezom (manjeg opsega)
Long Float - Brojevi sa pokretnim zarezom (veeg opsega)
Money - Brojevi sa fiksnim decimalnim zarezom novani tip podatka
Serial - Brojevi sa automatskim inkrementiranjem
Boolean Logiki tip podatka (true/false; yes/no; 1/0)
Karkter tip podataka

Characters - Karakter string
Variable Characters - Karakter string
Long Characters - Karakter string
Long Var Characters - Karakter string
Text - Karakter string (Memo)
Multibyte - Multibajt karakter stringovi
Variable Mulitbyte - Multibajt karakter stringovi
Vremenski tip podatka

Date - Datumski (Dan, mesec, godina)
Time Vreme (as, minut, i sekunda)
Date & Time - Datum i vreme
Timestamp - Sistemski datum i vreme
Ostali tipovi podataka

Binary - Binarni stringovi
Long Binary - Binarni stringovi
Image Slike
Bitmap - Slike u bitmap formatu (BMP)
OLE - OLE linkovi
Drugo (Other) - Korisniki definisani tipovi
Nedefinisani (Undefined) - Jo nedefinisani tipovi podataka
Definisanje domena
Domeni identifikujete tipove informacija u projektu. U PAM-u, je mogue pridruiti sledee

informacije domenu:
Generiki tip podatka, duinu, i preciznost
Parametre provere (Check)
Poslovna pravila (Bussines Rules)
Duina i preciznost su osobine koje se ne primenjuju na sve tipove podataka. ta vie, u

zavisnosti od tipa podatka, duina moe da oznaava maksimalan ili fiksni broj karaktera.
Za kreiranje korisniki definisanih (semantikih) domena je potrebno izabrati opciju:

DictionaryList of Domains.
Pojavie se lista domena (slika ispod).
Klikom na dugme New se pojavljuje nova linije u koju unosimo ime i kod novog domena, a
zatim se bira tip podatka, eventualno duina i preciznost, te ogranienja nad njim (Check).
Za uvoenje ogranienja nad elementarnim podacima usled specifinosti realnog sistema koji se
modelira ili zahteva korisnika se bira taster Check za selektovano polje, tj. elementarni podatak
iz renika i otvara ekran (Check Parameters) kao na slici dole.
Na ovom ekranu mogue je definisati:

Vrednosti koje e elementarni podatak uzimati (Value).
Oznake (Label) tih vrednosti.
Minimalnu i maksimalnu vrednost opsega.

Inicajlnu (Default) vrednost.
Velika ili mala slova tekstualnih tipova podataka (Lowercase mala Uppercase velika
slova) itd.
Brisanje objekata
Ostvaruje se selektovanjem objekta i jednostavnim pritiskom tastera Delete na tastaturi ili

izborom stavke iskaueg menija na izabranom objektu:
Kada se brie simbol objekta, mora se naznaiti da li se jednostavno brie samo simbol iz
grafikog prikaza modela dijagrama toka podataka ili se brie objekat iz renika. Ako je simbol
samo grafiki brisanje se vri bez potvrde, ali ukoliko je simbol asociran (povezan) sa objektom
u reniku bira se izmeu brisanja simbola vizuelno ili brisanje celokupnog objekta iz renika
podataka.
Kopiranje objekata - Postoje dva nana kopiranja objekata:
1. Dupliranje kreiran je potpuno novi objekt u reniku podataka koji ima identine osobine
originalu, jedino se razlikuje kodno ime koje mora biti jedinstveno za sve objekte u svim
dijagramima, pomodelima i modelu. Na primer, ako dupliramo entitet Student, novi entitet
imae ime, tj. kod Student2. Postupak dupliranja se sastoji u izboru objekta na dijagramu i
zatim:
Edit Duplicate (ili CTRL+U)
2. Sinonimi - kreiranje dodatnih vizuelnih simbola za postojei objekt ime se na razliitim

mestima u modelu, moemo poboljati itljivost i preglednost modela. Pri prikazivanju, simboli
sinonima su razliiti u zavisnosti od metode i tipa objekta:
1
Entt_4 Stor_3 : 2
Prcs_2
Za kreiranje sinonima objekta je potrebno odaberati objekat a zatim izabrati opciju:
Edit Create a Synonym.
3.3. FUNKCIONALNA DEKOMPOZICIJA

Funkcionalna dekompozicija se zasniva na principu "od vrha prema dnu" (top-down) po
kojem rad na razvoju projekta IS treba zapoeti od identifikovanja funkcija sistema. Na funkcije
sistema se gleda kao na grupu aktivnosti koje se konstantno obavljaju radi ispunjenja odredene
svrhe postojanja realnog sistema koji se analizira.
Identifikovanjem funkcija odreduju se granice razvoja, tj. definie se ta e iz realnog sistema

biti obuhvaeno projektom IS, a ta ne. Rezultat analize je model realnog sistema kojim se
grafiki, na dijagramu toka podataka (DTP), prikazuje ta sistem treba da radi. Sutina metode
Strukturne Sistem Analize je da realni sistem posmatra kao proces, koji transformie ulazne
informacije u izlazne informacije. Taj globalni proces (proces 0-og niova) se dalje dekomponuje
na prostije (jednostavnije) procese, i postupak dekompozicije se odvija sve dok se ne doe do
niova primitivnih procesa procesa ija se logika (tok odvijanja) moe opisati na jednoj stranici
A4 formata. Procese (obrade informacija) treba razlikovati od sutinskih procesa u jednom
realnom sistemu (odvijanje nabavke, proizvodni proces, pruanje usluge, nain realizacije
gotovih proizvoda, planiranje strategije razvoja, implementacija sistema kvaliteta i dr.).
S obzirom da je IS sloen sistem, prikaz svih informacionih procesa na jednom DTP bio bi
veoma nepregledan. Iz tog razloga, opisivanje analiziranog sistema se ostvaruje skupom
hijerarhijski povezanih DTP-a. Na vrhu ove hijerarhije nalazi se tzv. dijagram konteksta kojim
se prikazuje veza sistema sa okolinom (spoljnim objektima).
Dijagram konteksta je DTP sa najviim stepenom apstrakcije u opisivanju sistema i uobiajeno

je da se na njemu nalazi samo jedan globalni proces, kojim se prikazuje IS koji se razvija.
Zatim se u opisivanju analiziranog sistema pristupa postepenom uvodenju detalja, tako to se

svaki globalni proces predstavlja (dekomponuje) novim dijagramom toka podataka na niem
nivou.
Veze izmedu svih komponenti DTP se uspostavljaju imenovanim tokovima podataka. Pri tome, u
dekompoziciji se mora potovati osnovno pravilo - pravilo balansa tokova, po kojem svaki tok
koji ulazi ili izlazi iz procesa na DTP vieg nivoa mora biti jednak sumi ulaznih ili izlaznih tokova
sa DTP nieg nivoa (tj. suma dekomponovanih tokova na niem nivou hijerahije mora biti
jednaka toku, sa vieg nivoa, koji se dekomponuje). Sutina ovog pravila je da se
dekompozicijom tokova podataka ne izgube podaci na niim nivoima dijagrama, kao i da se ne
doda neki novi tok podataka, koji nije bio zastupljen na viim nivoima hijerahije Dijagrama
Tokova Podataka.
Radi lakeg praenja, vrlo je poeljno ispotovati i pravilo 7 2 po kome na jednom DTP-u
treba da bude prikazano od 5 do 9 procesa.
Za dekompoziciju procesa potrebno je odabrati dekompoziciju sa Tools palete i kliknuti na

proces koji se eli dekomponovati ili prvo selektovati proces, otvoriti desnim tasterom mia
iskaui meni i izabrati Decompose opciju:
Pojavljuje se novi prozor za podprocese koji se crtaju i definiu na identian nain kao i
nadreeni. Dekompozicija procesa se moe izvriti onoliko puta koliko to eli sistem analitiar.
Prelazak u vii nivo po hijerarhiji moe se vriti izborom:
Dictionary Up One Level (ili Ctrl+A)
Za dostizanje osnovnog (korenog) procesa, ponoviti ovu operaciju onoliko puta koliko je
potrebno sve dok se osnovni proces ne pojavi.
Identifikovanje dekomponovanog i nedekomponovanog procesa
Kada se koriste OMT ili Yourdon/DeMarco and Gane & Sarson metodologije, znak plus (+)
oznaava da je proces dekomponovan, u suprotnom radi se o elementarnom, primitivnom
procesu koji se ne moe dalje dekomponovati:
Prcs_1
Oznaavanje primitivnog procesa se ostvaruje otvaranjem osobina tog procesa postavljanjem

svojstva Lowest level (Najnii nivo) na vrednost True:
Svi procesi moraju pored naziva nositi i brojnu oznaku. U okviru istog hijerarhijskog nivoa
brojne oznake se dodeljuju procesima po redosledu odvijanja. Procesi nieg nivoa nasleuju
brojnu oznaku procesa koji se dekomponuje, proirenu s desne strane za redni broj procesa u
okviru svog hijerarhijskog nivoa (tj. u okviru konkretnog DTP-a). Tako e oznake procesa
nastalih dekompozicijom dijagrama konteksta biti po redosledu ukljuivanja: 1., 2., 3, ...,
oznake procesa nastalih dekompozicijom procesa 1. bie 1.1., 1.2., 1.3., ..., oznake procesa
nastalih dekompozicijom procesa 1.1.. bie 1.1.1., 1.1.2., 1.1.3., ... itd.
Dekompozicija se moe obavljati sve do nivoa na kojem dalja dekompozicija procesa nije vie
mogua ili potrebna. Procesi koji se ne mogu dalje dekomponovati se nazivaju primitivnim ili
elementarnim. Karakteristika primitivnih procesa je da se oni odvijaju sekvencijalno i sa
poznatim redosledom aktivnosti.
Za opis logike ovih procesa, tj. opis aktivnosti koje ine jedan proces, moraju se koristiti neki od
specijalizovanih alata: dijagram toka programa, stabla odluivanja, Nassi-Shneiderman-ov
dijagram, pseudokod i drugi. Ipak, kao alat za opis procesa najee se koristi pseudokod, u
kojem se logika procesa opisuje korienjem kljunih rei programskog jezika u kojem e se
realizovati aplikacije.
3.4. RENIK PODATAKA RP

Sastoji se iz tri vrste opisa:
1. Opis strukture i sadraja svih tokova podataka i skladita.
{a, b, c} - unija komponenti - odgovarajua struktura komponenata moe da pojavi vie
puta.
[a, b, c] - ekskluzivna specifikacija komponenti meusobno se iskljuuju strukture.
<a, b, c> - agregacija komponenti - koje se obavezno pojavljuju tano jedanput u
strukturi.
/a, b, c/ - neekskluzivna specijalizacija - oznaava da se u odgovarajuoj srtukturi
pojavljuje bilo samo jedna, komponenta, bilo dve, bilo sve.
2. Opis elementarnih podataka (Data Items).

3. Opis domena (Domen je skup ispravnih vrednosti iz kojih elementarni podaci uzimaju
vrednost semantika vrednost (definiu je korisnici)).
Primeri: OCENA_STUD: BYTE, >=5,<=10
OCENA: INT(2) IN (1,2,3,4,5)
SEMESTAR: INTEGER (2) BETWEEN 1,10
Primer strukture toka podataka Dokumenta za upis:
DOKUMENTA_ZA_UPIS:
< PREZIME,
IME,
IMERODITELJA,
POL,
DATUMRODJENJA,
MESTORODJENJA,
NAZIVMESTARODJENJA,
NAZIVZEMLJERODJENJA,
ULICAIBROJ,
MESTO,
NAZIVMESTA,
NAZIVZEMLJE,
TELEFON,
DRZAVLJANSTVO,
NACIONALNOST,
[
<
BROJLICNEKARTE,
JMBG
>,
BROJPASOSA
],
VRSTASKOLE,
NAZIVSKOLE,
GODINAZAVRSETKA,
PROSEK,
DATUMUPISA,
VRSTASTUDIJA,
NAZIVSMERA,
GODINA,
SEMESTAR,
RBRUPISA,
NACINSTUDIRANJA
>;
3.5. PSEUDO KOD

Pseudo kod je zapis koji koristi neke rei programskih jezika, ali je vei deo rei na prirodnom
jeziku. Opisuju se primitivni procesi, i opisuje se ta taj proces radi.
Naini zapisa domena, je korienje logikih uslova (sadre neke logike operatore i konstante).
Drugi nain je nabrajanje (navoenje iz nekog skupa CHAR M , c , N)
3.6. PRAVILA SSA:

1. Vie razliitih elemenata postoji na jednom dijagramu.
2. Svi elementi dijagrama (DTP-a) moraju biti povezani.
3. Imenovanje elemenata (procesi imaju i broj) je obavezno.

4. Pravilo balansa (automatski podran u CASE alatu, ali treba ga znati jer i pored toga to
imate automatizam moe se naruiti).
- Ukupno svi podaci koji ulaze i izlaze iz procesa moraju biti zastupljeni na dekompoziciji
- Svaki od ovih tokova podataka ima svoju strukturu
- Ovi tokovi podataka moraju da negde postoje na dekompoziciji
Lake shvatiti: Pravilo je narueno ako na dekompoziciji dodamo tok koji je povezan sa
interfejsom (internih tokova podataka moe bii proizvoljno mnogo).
5. Pravila za crtanje dijagrama:

Ispravne veze izmeu objekata
Neispravne veze izmeu objekata
6. Svaki proces mora da ima bar jedan ulazni i bar jedan izlazni tok podataka.
7. Po pravilu, svako skladite takoe treba da ima barem jedan ulazni i barem jedan izlazni tok.
Meutim, dozvoljava se da skladite nema ulazni tok, podrazumevajui da se formira i
aurira u nekom drugom sistemu (mada bi ga tada, moda, loginije bilo prikazati kao tok
od nekog interfejsa), odnosno da nema izlazni tok, podrazumevajui da posmatrani sistem
formira i aurira skladite koje se koristi u nekom drugom sistemu.
Ispravnost dijagrama i globalnog modela
Provera ispravnosti nacrtanih dijagrama ne vri sistem analitiar runo, ve to radi CASE alat,
pomou opcije:
Dictionary Check Model (F4)
Vano je primetiti da se ovakva automatska provera korektnosti nacrtanih dijagrama vri za
trenutno otvoreni, a da bi se izvrila provera celog modela, mora se otvoriti kontekst dijagram.
U sluaju je model procesa korektan i u skladu sa pravilima SSA dobie se ekran kao na
prethodnoj slici, u protivnom se ispisuju greke i upozorenja.
Ako postoje greke, one se otklanjaju izmenom dijagrama, njihovim elementima i renika
podataka:
Dictionary Objects
i/ili:
Dictionary List of Data Items
3.7. HEURISTIKE STRUKTURNE SISTEM ANALIZE

U tekstu koji sledi navode se heuristike za metodu Strukturne Sistem Analize, koje su rezultat
viegodinjeg rada autora u nastavi kursa Projektovanje informacionih sistema, kao i izrade
seminarskih radova studenata (http://www.tf.zr.ac.yu/predmeti/informacioni/default.html).
Ove heuristike su date u vidu sinonima, ili ireg objanjenja pojmova sa elemenata SSA:
dijagrama toka podataka, procesa i renika podataka.
1. ELEMENTARNI PODACI relevantni podaci, jednina u nazivu, poptun skup neophodnih

podataka; mora se znati kome pripada elementarni podatak,
struKture se sastoje od elementarnih podataka
2. DOMEN ZA ELEMENTARNE PODATKE mora biti precizno definisan; moe biti standardni
(predefinisani) i korisniki; mnoina u nazivu
3. STRUKTURA TOKA PODATAKA I SKLADITA odgovarajui (brojni) odnosi. Sintaksa: ;
, : < >, { }, //, [ ]
4. STABLO PROCESA ne: orijentisano na dokumente
- ne: orijentisano na spoljne entitete
- ne: orijentisano na poslove iste vrste (npr. sva prijavljivanja ispita, jer
nije svejedno koje su vrste ispiti: prijemni, na osnovnim studijama,
poslediplomskim i sl.)
- da: udruiti sve poslove po logikoj pripadnosti
- da: svrha postojanja sistema i sve aktivnosti da se ona ostvari
- da: ivotni ciklus osnovnog objekta obrade
- da: ta je sve neophodno uraditi da bi se ostvario cilj procesa.
5. PROCES KAO CRNA KUTIJA ta je izlaz (proizvod, usluga)
- ta nam je neophodno da bi realizovali taj izlaz
6. INTERFEJSI ne samo jedan interfejs na dijagramu, bar dva
7. Izvoai aktivnosti (zaposleni) su deo sistema, nisu interfejs
8. Dva ili vie procesa na istom nivou (ne moe postojati nepovezan izolovan proces)
9. Ne: dekomponovati proces na samo jedan podproces

10. Da: svi elementi DTP-a (tokovi podataka, elementarni podaci) imaju svoju svrhu postojanja,
zna se njihov izvor postojanja, gde se koristi i gde uvire
11. POVRATNA VEZA (uzrono posledina veza) Na spoljanji impuls odgovaramo
informacijom o naoj aktivnosti (proizvodnji, pruanju usluge i sl.) i pokreemo dalje aktivnosti
u sistemu. Kao odgovor na spoljni stimulans, elementi realnog sisema reaguju aktivnostima i
slanjem informacija objektu iz okruenja.
12. Dogaaji kao odgovor na dogaaje iz okruenja realni sistem (sistem koga modelujemo,
na sistem) ima interne procese kojima reaguje na spoljne dogaaje.
13. PROVERA PODATAKA Na osnovu ega radi proces? Koji proces puni skladite
podataka? Odakle podaci u skladitu podataka?
14. SKLADITE PODATAKA obrada vie podataka istog tipa u jednom procesu
15. PODACI U SKLADITU injenice (o objektima i dogaajima), znanje (i pravila o
osobinama objekata), parametri iz sistema, opti podaci
16. SKLADITE BEZ ULAZNOG TOKA PODATAKA deljeno skladite koje se puni u nekom
drugom sistemu (vetaki proces preuzimanja spolja)
17. NEBITAN NAZIV I BROJ SKLADITA vano je da naziv skladita odslikava sutinu
podataka, odn. da je naziv mnemoniki
18. SPISAK PROCESA izdvojiti ta je osnovni proces realnog sistema koga modelujemo, a
koji su procesi iz okruenja (interakcija sa sistemom)
19. INTERPRETACIJA (transformacija) i dopunjavanje procesa i tokova podataka
20. Razdvojiti fizike i informacione procese. Prikazati sutinske procese u realnom sistemu koji
realizuju svrhu postojanja sistema.
21. Pre-u toku-posle fizikog procesa (proizvodnja, pruanje usluge) deavaju se informacioni
procesi.
22. PRINCIPI: Potpunost; Fleksibilnost; Adektvatnost; Usklaenost sa standardima i
zakonskom regulativom u datoj oblasti.
23. SVRHA SSA: predstavljanje znanja o realnom sistemu
a) uoptavanje slini sistemi sutina funkcionisanja nezavisno od
postojee tehnologije / organizacije
b) relevantni elementi specifikacija informacionih potreba realnog
sistema
24. Prazan obrazac ili kopija nekog dokumenta nije tok podataka
25. Ne: uopteni nazivi elemenata (npr. umesto naziva Prijem treba konkretnije Prijem_robe
26. Vie dokumenata koji se obrauju jednim procesom ine jedan tok podataka
27. PRAVILO BALANSA
28. PRAVILO 7+(-)2
29. Pravilo povezivanja elemenata
30. DUBINA DEKOMPOZICIJE (ta je primitivni proces?)
- procesi koji se mogu paralelno i nezavisno izvravati
- procesi koji imaju jedan ulaz i jedan izlaz
- jedan primitivni proces je najee jedan ekran
- logiku primitivnog procesa moemo opisati na jednoj strani A4 formata
- kada bi se njegovom dekompozicijom dobili trivijalni procesi
- kada bi se daljom dekompozicijom dobile naredbe programskog jezika
- ako bi se dobili sekvencijalni procesi koji se moraju izvriti jedan za
drugim, nezavisno
- vremenski prekid ako postoji, onda to nije primitivni proces
- kada bi dekompozicijom zali u nivo implementacije
31. Ako proces ima vie od 1 ulaznog i 1 izlaznog toka podatka, onda se moe dalje
dekomponovati
32. Interfejs jedan oblik (forma) ekrana a da je prisutan u svim pojavnim oblicima u raznim
ivotnim fazama (npr. kandidat za studenta, student, apsolvent, diplomac, podnosilac molbe,
zaposleni na fakultetu i slino)
33. Potpun ivotni ciklus osnovnog objekta obrade
34. Mogue je da postoji vie osnovnih objekata obrade
35. GRANICE POSMATRANJA u seminarskim radovima studenata svesno se ide na
ogranienje (jedna organizaciona jedinica, podsistem, modul), a inae: zaokruen skup
aktivnosti koji ini celinu, bez obzira na organizacionu strukturu realnog sistema (preduzea,
ustanove, optine itd.)
36. Brojevi procesa u skladu sa logikim sledom aktivnosti u ivotnom ciklusu
37. Precizan opis realnog sistema daje za rezulat dobro definisanu SSA
38. POTPUNOST PROCESA postoje vie vrsta procesa: SUTINSKI (svrha postojanja),
PRATEI (odravanje sistema, odluivanje, upravljanje dokumentacijom, kontrola kvaliteta...),
UPRAVLJAKI, RAZVOJNI procesi
39. Pravila ugraena u CASE alat pravilo BALANSA
- INTEGRITET SKLADITA (ne moe imati elementarne podatke, koje nije
dobio putem ulaznog toka podataka),
- 7+(-)2
40. Podaci koji ulaze u sistem moraju imati svrhu
41. DELJENO SKLADITE PODATAKA na prvom i daljim nivoima to je veza meu
procesima, ili sluaj kada jedan proces svoj rezultat smeta u takvo skladite podataka, da bi
sluilo drugim procesima u sistemu
42. Skladite podataka nalazi se na onom nivou gde se i koristi. Ne: skladite podataka na
nivou gde bi ga koristio samo jedan proces, a ne i drugi procesi. U tom sluaju, takvo skladite
podataka je interno za taj proces.
43. Ne: vetaki procesi evidentiranja dokumenata ili, identifikacije objekata..., jer su oni
sadrani u svakom procesu
44. Da: identifikovati sutinske realne procese i podatke, koji su neophodni za njihovu
realizaciju
45. U sistem ulaze: materija, energija i podaci, ali i podaci o materiji i energiji i to u obliku
parametara ili deskriptivno (opisno)
46. Tenja je da se prikae ta sistem treba da radi, a ne ta radi (u odnosu na praksu
nerazvijenih i neorganizovanih sistema koji ne rade po standardima, propisima, regulativi za
datu oblast)
47. Na Dijagramima Toka Podataka je dozvoljena redundansa, a na Modelu Objekti Veze teimo
njenoj minimizaciji. To znai, da se jedan elementarni podatak moe pojaviti u razliitim
skladitima DTP-a, ali, naravno, ne i u okviru istog.
48. IMENOVANE STRUKTURE mogue je koristiti pozivom imena unutar neke druge
strukture, ali mora da se definie od kojih elementarnih podataka se sastoji. Ako je ostavljen
elementarni podatak, koji bi po nazivu mogao biti struktura, onda se mora napraviti vie
elementarnih podataka.
49. INTERFEJS je sutinski izvor/uvir podataka, a ne posrednik (npr, sva komunikacija u
nekom preduzeu se odvija preko tehnikog sekretara, ali nije sekretar izvor podataka
(INTERFEJS) ve npr. dobavlja, kupac, ministarstvo za finansije, banke i sl.)
50. PRAVILA POVEZIVANJA za svako skladite i svaki proces mora postojati ulazni i izlazni
tok podataka
- skladite podataka moe da puni samo proces; ne smeju biti direktno
povezani interfejs i skladite podataka,
- na 0-om nivou ne bi trebalo da se pojave skladita podataka,
- procesi se povezuju samo preko skladita podataka, a ne direktno.
51. Ako se neke aktivnosti istovremeno odvijaju to moe biti jedan proces.
52. Ne moraju svi procesi biti dekomponovani do istog nivoa.
53. SSA opisuje procese kao odgovor na pitanje TA?, a ne KAKO? Na taj nain i treba opisati
aktivnosti u sistemu, pre zalaenja u detalje implementacije.
54. esto se zaboravljaju datumi na toku podataka i podaci o uspenosti izvrene aktivnosti.
55. Trebalo bi razlikovati datum kada je trebalo da se izvri aktivnost od datuma stvarne
realizacije ili promene vrednosti osobine (atributa) nekog objekta u sistemu.
56. Broj procesa oznaava mesto u STABLU (dubinu i pripadnost). to se tie procesa na istom
nivou (procesi koji su nastali kao rezultat dekompozicije istog procesa), poslednji broj oznaava
redosled u nizu (redosled izvravanja).
57. Poeljna su dua imena (a ne skraenice) u nazivima elemenata DTP-a (rei odvojene sa
_).
58. esta greka je to se postavljaju ravnopravnim procesi, koji su u odnosu nadreen
podreen (npr. prijem robe i kontrola pristigle robe).
59. esto se zaboravi evidencija podataka u skladitu podataka i to onih, koji se alju van
sistema - kao izlazni tok podataka (npr. narudbenica koristi se kasnije kod prijema robe).
60. Pravilo odrediti granice sistema. U odnosu na promenu granica menjaju se i interfejsi. Ne
zaboraviti da za podsistem jedne organizacije i drugi podsistemi predstavljaju interfejs.
61. Usmena razmena podataka takoe je tok podataka. Za tok podataka nebitan je medijum.
62. Vremenski odvojeni procesi su zasebni, ne mogu biti i primitivni procesi.
63. Procesi su nezavisni od organizacione strukture realnog sistema i sistematizacije radnih
mesta.
64. ta je skladite podataka? svaki dosije, kartoteka, knjiga...
- znanje
- vremenski prekid izmeu dva procesa za smetanje podataka
- sredstvo za smetanje podataka iste vrste, da bi se odjednom obradili
- tok podataka u mirovanju
65. Homonimi/sinonimi kod naziva elementarnih podataka: definisati jedinstvene nazive, ili,
reiti problem u Modelu Objekti Veze.
66. Moraju biti imenovani tokovi podataka, kojima razmenjujemo podatke sa interfejsima. Ne
moraju biti imenovani interni tokovi podataka (idu od ili ka skladitu), ukoliko nose sve
podatke kao i u strukturi tog skladita.
67. Bitno je da procese, koje posmatramo, stavljamo u iri kontekst i sistem koga modelujemo
je podsistem nekog ireg sistema (okruenja).
68. U SSA se ne posmatra interakcija izmeu dva ili vie interfejsa. To je domen njihovog
odnosa i informacionog sistema kome pripadaju. U projektovanju putem SSA bitna je samo
interakcija (razmena informacija) interfejsa sa datim, konkretnim realnim sistemom.
69. Voditi rauna da se tokovi podataka ne nazivaju kao procesi (npr. nije dobro da tok
podataka bude Prijavljivanje_ispita, ve Prijava_ispita, ili Podaci_o_prijav_ispita.
3.8. KREIRANJE IZVETAJA

tampanje dijagrama tokova podataka
Ova opcija podrazumeva da je prethodno, u Windows-u, ispravno instaliran i podeen drajver za

tampa. Samo tampanje dijagrama zapoinje ozborom sledee opcije:
FilePrint Graph
Pojavie se dijalog prozor (slika ispod).

Kreiranje izvetaja CASE alata
ProcessAnalyst omoguava kreiranje celokupnog izvetaja o modelu koji smo uneli. Pri tome u
izvetaj ulaze dijagrami tokova, opisi objekata, specifikacije primitivnih procesa, struktura
skladita i tokova podataka, detaljan opis elementarnih podataka. ta e se sve nalaziti u
izvetaju zavisi od toga koji tip izvetaja emo odabrati (standardni, potpuni, i liste) ili emo
kreirati svoj sopstveni ablon za izvetaj.
Kreiranje izvetaja se vri na sledei nain:
FileCreate Report
Pojavie se dijalog prozor izgleda kao to je prikazano na narednoj slici:
Potrebno je odabrati jedan od ponuenih ablona za izvetaje koji se razlikuju po obimu

podataka koje uzmaju iz renika podataka.
Pregled funkcija tastera za kreiranje izvetaja ProccessAnalyst-a:
Print - tampa izvetaj.

Save RTF - Snima izvetaj u Reach Text Format-u.
Preview - Mogunost pregleda izvetaja.
Create - Kreiranje sopstvenog, u sluaju da smo upisali ime u polje Report Name.
Delete - Brisanje izvetaja.
Cancel - Odustajenje od akcije generisanja izvetaja.
4. PROJEKTOVANJE BAZE PODATAKA
4.1. MODEL PODATAKA

Da bi se podaci, koji treba da uu u bazu podataka, a prikupljaju se strukturnom sistemskom
analizom realnog sistema, sredili i sistematizovano prikazali na nain pogodan za realizaciju
baze podataka koristi se informacioni model podataka. Model podataka je formalna
apstrakcija, putem koje se realni svet preslikava u bazu podataka [ML]. Modelom podataka se,
preko skupa podataka i njihovih veza, prikazuje stanje realnog sistema u jednom odreenom
trenutku.
Najpoznatiji nain za prikazivanje modela podataka je E-R-A model (Entity-Relationship-

Atribute) ili kod nas MOV (Model Objekti Veze obeleja). Autor je Chen, sa Univerziteta MIT u
Bostonu, 1978. godine.
GENERACIJE MODELA PODATAKA
Baza podataka predstavlja strukturu modela podataka, statiki model sistema koji se eli
predstaviti na raunaru, odnosno podatke o objektima u sistemu i vezama izmeu njih.
U istoriji razvoja modela podataka razlikuju se tri generacije modela podataka:

I GENERACIJA: Klasini programski jezici, sa relativno jednostavnim tipovima podataka i
siromanom semantikom. Ne mogu predstaviti realan sistem.
II GENERACIJA: Modeli konvencionalnih sistema za upravljanje bazom podataka
hijerarhijski, mreni i relacioni. Poseduju znatno bogatiju semantiku od I
generacije, strukture podataka i sloenije tipove podataka. Nepotpuno
opisuju realan sistem.
III GENERACIJA: Semantiki bogati modeli E-R-A ili MOV (Model objekti veze obeleja),
SDM (Semantic Data Model) i drugi. Poseduju specifine koncepte za
detaljan opis realnog sistema. Nedostatak je u tome to nisu potpuno
realizovani na raunaru (CASE alati).
OBJEKTNI MODEL PODATAKA Nastao je poetkom 90-tih godina XX veka, kao
implementacija struktura podataka iz objektno orijentisanih programskih
jezika (C++, SmallTalk) u sisteme za rukovanje bazama podataka, u oblasti
inenjerskog projektovanja (CAD sistemi), ili kao implementacija ugnjedenih
tabela u okviru klasinog relacionog modela podataka ([ML] kao i [UHW]).
Reenje koje se danas koristi u projektovanju baze podataka jeste da se specifikacija sistema
uradi korienjem alata tree generacije (npr. Data Architect u Power Designer-u), a zatim sledi
prevoenje u relacioni model koji pripada drugoj generaciji i za koji postoji veliki broj sistema za
upravljanje bazom podataka (ORACLE, DB2, INGRES, PROGRESS, SyBase, DBase, Paradox, SQL
Server, FoxPro, Access i sl.).
OSNOVNI ELEMENTI MODELA PODATAKA:

1. Entiteti jedinice posmatranja, to su objekti realnog sistema, mogu biti konkretni
ali i apstraktni i vezani su za interes korisnika. Entiteti mogu biti: iva bia, predmeti,
dogaaji iz realno sistema. Entiteti poseduju neka svojstva (osobine, obeleja) i
mogu se postaviti u razliite odnose sa drugim entitetima, a takoe, mogue je
ustanoviti i hijerahiju nasleivanja (IS-A hijerarhiju) u klasama tipova entiteta.
2. Atributi obeleja, svojstva nekog objekta (entiteta) iste vrste. Vrednosti atributa
odnosno obeleja su podaci.
3. Atributi u svakom trenutku imaju odreenu, konkretnu vrednost, koju uzimaju iz
odreenog domena skupa dozvoljenih vrednosti. Atributi se identifikuju na
osnovu:
- zahteva korisnika,
- dokumentacije.
4. Atributi koji se navode za jednu klasu objekata treba da obezbede da jedan ili vie
atributa jednoznano identifikuju svaki objekat u skupu pojava te klase objekata i
zove(u) se klju te klase objekata.
Definicija 2.4. Neka je P={pi i=1,...,k} skup pojava tipa entiteta N(A1,...,An), a p[X]
restrikcija pojave p na obeleje X. Obeleje X predstavlja klju tipa entiteta N(A1,...,An),
ako, za svaki skup P pojava tipa entiteta N, vae sledea dva uslova:
1 ( pi,pj P) (pi,pj pi [X] pj [X] ) i
2 ( X ' X ) (1). [ML]
Prvi uslov se zove uslov jedinstvenosti, i kae da u skupu pojava tipa entieta N ne mogu
postojati dve iste pojave tipa entiteta (dve pojave sa istom vrednou kljua). Drugi
uslov se zove uslov minimalnosti, i njegova sutina je da ako je klju tipa entiteta sloen
tj. sastoji se iz vie obeleja, onda nijedno od tih obeleja ne sme na sebe da preuzme
ulogu primarnog kljua.
Klju mora biti jednoznaan, nepromenljiv i raspoloiv. Kriterijum za izbor kljua izmeu
vie kandidata jeste da je kratak, lak za pamenje i prihvatljiv od strane korisnika.
5. Za realizaciju baze podataka nije dovoljno samo definisati entitete, atribute i njihove
domene, te kljueve, ve moramo prikazati i veze izmeu entiteta, tj. objekata.
Osnovni tipovi veze izmeu klasa objekata:
- 1 : 1 jedan prema jedan - za svaki objekat iz jedne klase postoji samo
jedan povezani objekat iz druge klase.
- 1 : M jedan prema vie - svaki objekat iz jedne klase postoji vie
povezanih objekata iz druge klase, a iz te druge klase se svaki objekat moe
povezati samo sa jednim objektom ove druge klase.
- M : M vie prema vie - svaki objekat iz jedne klase postoji vie
povezanih objekata iz druge klase, a iz te druge klase se svaki objekat moe
povezati opet sa vie objekata ove druge klase.
Formalni nain prikazivanja entiteta: E (a1, a2, ..., an)

gde je: E ime klase entiteta (skup svih slinih objekata je klasa)
a1, a2, ..., an - atributi
Grafiki simboli za prikaz entiteta u modelu objekti veze obeleja:
Entitet (jak tip ebjekta)
Slab tip objekta
Obeleje (atribut)
Jak (fundamentalni) entitet je onaj koji ima odredenu osobinu ili skup osobina koje
omoguavaju njegovo jednoznano identifikovanje. Takva osobina (ili skup osobina) se naziva
primarni klju entiteta. Slabi objekat je objekat koji nasleuje klju objekta s kojim je povezan i
proiruje ga nekom svojom osobinom. Podtip je entitet koji nasleduje primarni klju i sve
nekljune atribute jakog entiteta s kojim je povezan. U model podataka se uvodi zbog
postojanja odredenih specifinih osobina koje se definiu posebno za svaki uvedeni podtip ili
zbog izdvajanja onih osobina koje se ree koriste. Agregacija je entitet koji poseduje sloeni
klju, sastavljen od kljueva entiteta s kojima je on povezan.
Agregacija (Meoviti Tip Entitet Poveznik) uvodi se u sluaju kada je potrebno uspostaviti vezu
izmeu veza, odnosno, kada su (ne nuno sve) pojave jednog tipa entiteta poveznika povezane
sa pojavama nekog drugog tipa poveznika. Tada se povezani tipovi poveznika prevode u
gerunde (odn. meoviti tip entitet poveznik). Ovaj koncept ER modela se koristi za
modeliranje sledeih situacija kao na primer:
ako je student upisao neki smer, onda on moe prijavti polaganje ispita iz onih
predmeta, koji se na tom smeru sluaju po nastavnom planu, ili
radnik je osposobljen da radi na maini, na maini se moe proizvesti deo, pa sledi-
radnik na maini, za koju je osposobljen, izrauje one delove, koji se na toj maini mogu
proizvesti.
Osim svojim nazivom, entiteti se u posmatranom sistemu opisuju i preko svojih atributa. Atributi
su imenovana svojstva entiteta u sistemu. Obino definiu na osnovu pregleda interne i
eksterne dokumentacije, upitnika, pregleda postojeeg softvera. Na dijagramima se grafiki
predstavaljaju kao ovali sa nazivom, koji su povezani s entitetom. Skup vrednosti koje neki
atribut moe da ima se zove domen atributa. Domen moe biti unapred predefinisan tipom
podatka koji konkretni programski jezik podrava i duinom podatka, ali moe biti i
"semantiki". Semantiki domen je skup dozvoljenih vrednosti i odgovarajuih (potrebnih)
ogranienja koje definie sam projektant.
NEKA HEURISTIKA UPUTSTVA

ZA PROJEKTOVANJE BAZE PODATAKA
CILJEVI:
1. Minimum redundanse.
2. Optimalno prema programskoj podrci - minimum utroka vremena za izdvajanje podataka i
memorije. Funkcionalnost.
3. Optimalno prema promenama u vremenu - pogodnost kasnijeg odravanja i intervencija.
Fleksibilnost. Sistem treba da ivi u vremenu uz minimalne ili nikakve intervencije nad bazom.
4. Ugraivanje semantikih odnosa realnog sveta - adekvatnost
5. Ugraivanje ogranienja (integriteta) u bazu podataka odnosno, ako je implementirano u
samom SRBP-u, koristiti to vie DEKLARATIVNOST SQL naredbi, ili mehanizme zatite
integriteta baze podataka (integritet domena, integritet torke relacije, referencijalni integritet)
- da baza podataka sama sebe titi od greaka (unosa), a ne da zavisi od programa
- ugraivanje lokalnih pravila u vidu kardinaliteta ili uopte u odnosima, tj. ugraivanje
poslovnih pravila (loklanih pravila koja vae u odreenoj organizaciji)
6. Potpunost modela podataka, tako da pokriva podacima sve procese koji su definisani u SSA,
a pre svega primitivne procese, tj, da su sve informacione potrebe pokrivene, tj. svaki
elementarni podatak iz SSA da ima adekvatan atribut u MOV, tj CDM-u. Dakle, pokrivenost
potreba realnog sistema.
7. Smanjenje broja tabela, radi lake manipulacije i fleksibilnijeg reenja
8. Uvoenje "reda", zbog anomalija auriranja
MATERIJAL KOJI KORISTIMO:

1. TEKST OPISA POSLA
2. STRUKTURNU SISTEM ANALIZU
a. Elementarni podaci - na osnovu njih dobijamo atribute za entitete
b. Odnosi elementarnih podataka (sintaksa pomou zagrada) - elementarni podaci koji se
javljaju u jednoj celini najee pripadaju jednom entitetu, {} govori o ponavljanju
c. Skladita - razbijaju se na tabele
d. Primitivni procesi - osnov za podeme BP
e. Poslovna pravila - tabele sa parametrima
f. Domeni - ifarnike tabele - entiteti
POSTUPAK:
Postupak nije linearan. Opisan je kao niz koraka koje treba uraditi jednom ili vie puta i
iteracijama.
1. Kreiranje preliminarnog skupa entiteta i dodeljivanje atributa
a. Transformacija elementarnih podataka koji su preuzeti iz SSA, ukoliko u SSA nije izvrena
korekcija
- Elementarni podaci koji su mnoina postaju jednina
- Elementarni podaci koji se nazivaju kao struktura i mogu se dalje dekomponovati na
elementarne podatke, vri se kreiranje novih elementarnih podataka koji ine tu strukturu.
- Nepotpuno imenovani elementarni podaci se dopunjuju dovoljno preciznim imenom.
- Neophodno je imati, za nedovoljno jasno imenovane elementarne podatke detaljniji opis (npr.
u Annotation delu u CASE alatu), kako bi se poptuno razumelo znaenje kako bi se moglo
pravilno odrediti njegovo mesto.
b. Primena heuristika ([ML], str. 51):

- ANALIZA TEKSTA OPISA POSLA: Imenice (subjekti, objekti) iz opisa posla postaju kandidati za
entitete
- IJI ELEMENTARNI PODATAK: Na osnovu imena elementarnog podatka, odreuje se koji je
entitet kojem pripada, pa se kreira odgovarajui entitet i njemu dodeljuje ovaj i ostali atributi
koji mu odgovaraju.
- DEKOMPOZICIJA SKLADITA PODATAKA: Sva skladita podataka se preuzimaju iz DTP-a
(SSA) i vri se njihova dekompozicija na entitete, tako to se uoavaju odnosi izmeu
elementarnih podataka na nivou svakog skladita ponaosob (brojni odnosi, odnosi
meuzavisnosti) i koriste se odnosi izraeni u navoenju strukture skladita pomou zagrada.
2. Transformacija preliminarnog skupa entiteta i atributa

a. Eliminisanje redundanse - atributi koji se ponavljaju u vie entiteta se izdvajaju u posebnu
tabelu. Jedan elementarni podatak bi trebalo da se memorie samo u jednoj tabeli.
b. Transformacija elementarnih podataka - bitno je da se svaki elementarni podatak koji je
preuzet iz SSA bude pokriven nekim oblikom.
- Izraunljivi elementarni podaci se ne memoriu, ve se od ostalih elementarnih podataka trai

da li se moe pokriti njihovo izraunavanje, ukoliko je trivijalno njihovo izraunavanje, a ukoliko
ne moe, dodaju se elementarni podaci koji su sirovi za ovaj izraunljivi podatak. Primeri:
prosena ocena studenta, prosena plata radnika, broj studenata po smerovima,...
- Reavanje problema sinonima i homonima - potrebno je da ostane samo jedan termin za
istovetno znaenje. HOMONIMI- isti naziv a razliito znaenje (semantika). Na primer, Obeleje
DATUM, moe da znai Datum roenja Radnika, ali i Datum zaposlenja Radnika, pa jedan naziv
DATUM ima razliito znaenje.
c. Dodavanje elementarnih podataka
- Dodavanje identifikacionih obeleja - Zgodno je da se identifikaciono obeleje zove ID_xxx, ili
samo XXX, npr, Id_pacijenta, ili samo Pacijent (zgodno kasnije kada se vri migracija polja u
drugu tabelu). Zaista, to polje je tamo u toj tabeli predstavnik pacijenta, tj, njegov zastupnik,
pa je lake zbog razumevanja
- Dodavanje jo nekih atributa za odreene entitete, ukoliko se ukae potreba, a nije definisana
u SSA.
d. Apstrakcija
- Uoptavanje vie slinih entiteta u jedan opti. Pri tome se kreiraju novi, opti atributi. Ovi
konkretni slulajevi postaju vrste tog entiteta i kao takvi se javljaju u konkretnim slogovima, kao
pojavni oblici. Potrebno je dodati jo jednu kolonu u tom optem entitetu, kojim se omoguuje
razlikovanje objekata razliite vrste.
Mora se voditi rauna o tome da se tim uoptavanjem ne izgubi neki potreban podatak. Npr. ne
mogu se svi datumi uoptiti u jedan elementarni podatak DATUM, jer nije svejedno da li je u
pitanju DATUM IZDAVANJA ili DATUM VRACANJA u nekoj biblioteci.
Uoptavanje (generalizacija) se uglavnom vri na nivou vie entiteta. Moe se vriti i na nivou
atributa, u situacijama kada je dozvoljeno i omogueno da se svi pojedinani sluajevi
adekvatno pokriju. Npr. OCENA_MATEMATIKA i OCENA_SRPSKI se MORA apstrahovati u
OCENA, NAZIV_PREDMETA ... kako bismo dobili fleksibilnije reenje.
Postoji vie REENJA kao projekta baze podataka, u zavisnosti od NIVOA APSTRAKCIJE.
e. Uoavanje odnosa (brojnih npr. 1:M i identifikacionih (funkcionalnih) zavisnosti) izmeu
elementarnih podataka i izdvajanje grupa elementarnih podataka iz entiteta u poseban entitet
- uoavanje odnosa prema identifikacionom obeleju
- uoavanje meusobnih odnosa elementarnih podataka
f-a. Uoavanje i imenovanje odnosa izmeu entiteta
- odnosi celina - deo (npr. zaglavlje - stavke)
- odnosi opte - specifino
- odnosi stalno - promenljivo
- odnosi statino- dinamino
- odnosi potencijalno - stvarno
- odnosi prolo - sadanje- budue
- odnosi jedan -vie
- odnosi pre- posle
- odnosi sirovo- izraunljivo
- stanja jednog objekta se menjaju u vremenu.
Bitno je:
- Uloge jednog entiteta se ostvaruju relacijama ka drugim entitetima.
Primer: Moe se na jednom mestu memorisati tabela Mesto, a ona ima ulogu mesta roenja,
mesta stanovanja, mesta kao sedita neke firme itd. i sve to u istoj tabeli.
f-b. Izdvajanje tipova entiteta:
Razlikovati:
- Entitet koji opisuje dokument.
- Entitet koji opisuje injenice o nekom objektu ili dogaaju.
Na je cilj fleksibilno reenje, tako da ne treba da teimo da memoriemo podatke pod nazivima
dokumenata, jer je to promenljiva kategorija. Bolje je memorisati podatke o injenicama o
dogaajima ili objektima, ukoliko nije potrebno da se realizuje deo za evidenciju dokumenata,
pored osnovne evidencije dogaaja i objekata.
Razlikovati:
- tabelu ifarnik
- tabelu znanje
- tabelu poveziva
- tabelu koja opisuje osnovnu dinamiku redovnog rada (pokriva obradu, tj. primitivne procese iz
SSA).
g. Kreiranje ifarnika
- Transformacija nabrojivog domena u ifarniku tabelu
- Izdvajanje elementarnog podatka koji ima nabrojivi domen vrednosti koji se pri unosu esto
ponavlja - elementarni podatak koji ima nabrojiv skup vrednosti koji se esto unosi u originalnoj
tabeli se izdvaja u posebnu tabelu ifarnik - memorie se ifra i naziv te vrste podatka. Unosi se
samo jednom, a koristi vie puta, kad god treba, pozivom preko ifre se memorie, tako da
ukoliko se podatak iz ifarnika menja, menja se automatski svako njegovo pojavljivanje u
tabelama gde je njegova ifra strani klju.
- Jedan podatak je opti i koristie se na vie mesta, ako se izdvoji kao posebna tabela. Npr.
tabela MESTO nastaje na osnovu polja: mesto roenja i mesto stanovanja.
g. Odreivanje kardinaliteta relacije
- odreivanje kardinaliteta svakog od preslikavanja
- voditi rauna da se odreivanje vri u 2 koraka:
- 1. Odnosi izmeu elemenata realnog sistema (vee ograniavanje)
- 2. Odnosi izmeu tabela u bazi podataka (manje ograniavanje, ukoliko se moe)
h. Odreivanje primarnog kljua za svaku buduu tabelu BP
Kriterijum:
- Jednoznanost
- Potpunost
- Minimalnost
Postoje 3 varijante:
- Prost broja od 1 polja za svaki entitet, koji slui samo za ostvarivanje relacija u prevoenju
irelacioni model (jednostavnije je da se prenosi samo jedno polje, a ne sloeni primarni klju).
Obavezno je kasnije u PDM-u (modelu relacione baze podataka) da se za svaku tabelu odredi
unique index kojim se definiu alternativni kljuevi, tj. kombinacije polja koje se ne smeju
ponoviti.
- Sloeni primarni klju (najee se sastoji od polja koja nose neko znaenje). Obezbeuje
semantiku jednostvenost sloga, a nedostatak je pri migraciji polja.
- Tzv. govoree ifre - jedan elementarni podatak iji delovi imaju znaenje. Npr. Broj indeksa ili
JMBG.
i. Odreivanje identifikacionih zavisnosti izmeu entiteta. Odreivanje tipova entiteta.
3. Zavrna optimizacija
Vri se u odnosu na:
- performanse celokupnog sistema, zajedno sa programom. Npr. dozvoljavaju se izraunljiva
polja, ukoliko se time postie skraenje vremena odziva sistema, na zadatu komandu.
- lakou odravanja. Napraviti takvu organizaciju tabela koja zahteva kasnije to manje
popravke i intervencije. Npr. sve to je mogue se uoptava i saima, tako da se dobija
fleksibilno i upravljivo reenje.
Primeri:
- Mogu se podaci o ulazu ili izlazu neke materije objediniti da se uvaju u jednoj tabeli, sa
bulovim poljem (.T. ili .F.) koji opisuje da li je ulaz ili izlaz.
- Mogu se svi ifarnici objediniti da se uvaju u jednoj tabeli. Potrebna je pored ifre i naziva jo
i kolona tip ifarnika.
4. Kreiranje podmodela
- Kreiranje podmodela se radi kao izdvajanje podeme celokupne eme baze podataka, i to za
svaki od primitivnih procesa se radi po jedna podema baze podataka.
- Podmodeli se rade iz 2 razloga:
- Proveravanje da li su svi primitivni procesi pokriveni podacima (dakle, pomou tih
entiteta, tj. tabela e biti realizovan taj proces,
po pitanju unosa i pregleda podataka)
- Da li su na podmodelu svi entiteti meusobno povezani. Ako nisu, povezani su preko
nekog drugog, pa i njega treba ukljuiti u
podmodel, ili da se doda direktna veza izmeu entiteta na celokupnoj emi.
5. Kreiranje fizikog modela podataka (PDM, odgovara relacionom modelu)

Fiziki model se u CASE alatu kreira automatski. U sutini se svodi na prevoenje MOV u RM, pri
emu se RM koji se dobije dodaju osobine koje su vezane za konkretni SUBP za koji se uradio
fiziki model. Kada je kreiran, proverava se:
- Da li su elementarni podaci odgovarajueg tipa podatka? Voditi rauna da neko polje ne
postane memo, a trebalo bi da je string!
- Da li je dobro izvrena migracija primarnog kljua? Da li je dobijen eljeni relacioni model.
- Da li elementarni podaci imaju jasni naziv? Preimenovanje elementarnih podataka u jasnije i
potpunije nazive.
- Da li primarni klju obezbeuje semantiku jedinstvenost podataka u datoj tabeli? Najee je
primrni klju "obian" broja i ne obezbeuje ouvanje semantike jedinstvenosti sloga, u
smislu da se moe pod nekim drugim brojem uneti dati slog, tj, ostali nekljuni podaci. Da bi se
to spreilo, radi se kreiranje Unique index-a nad svakom od tabela, gde je to mogue!
- Da li je obezbeen integritet podataka, pre svega referencijalni integritet putem pravila za
ouvanje referencijalnog integriteta?
PRAVILA
1. Normalne forme
Koriste se:
1. PRVA NORMALNA FORMA
- svaki elementarni podatak treba da memorie atomarne vrednosti (npr. tabela sa poljem
OCENE nije u 1NF. To su tzv. ponavljajue grupe ond. u okviru jedne grupe obeleja (BRIND,
IME, PRZ, DATUM i dr.) javlja se vie grupa obeleja (ocena iz matematike, ocena iz fizike,
ocena iz programiranja za tog studenta).
- u svakoj tabeli treba da su elementarni podaci, ali ne istog tipa da se ponavljaju (npr. tabela
sa poljima OCENA_1, OCENA_2 nije u 1NF)
2. DRUGA NORMALNA FORMA
- svaki nekljuni elementarni podatak treba da potpuno funkcionalno zavisi od primarnog kljua.
Ako relacija ima za klju prosto (elementarno) obeleje, onda je ona sigurno u 2NF. Meutim,
za relaciju:
ISPIT(BRIND, SIF_PR, NAZIV_PRED, DATUM, OCENA)
gde je klju sloen, postoji nepotpuna funkcionalna zavisnost nekljunog obeleja
(NAZIV_PRED) od dela kandidata za klju (SIF_PR).
3. TREA NORMALNA FORMA
- Tabela nije u 3NF ako postoje tranzitivne funkcionalne zavisnosti izmeu nekljunih obeleja i
kljua eme relacije.
- Tabela nije u 3NF ako postoje izraunljiva polja u odnosu na ostala polja to su sloena
obeleja dobijena primenom nekog algoritma na vrednosti ostalih obeleja u relaciji npr.
procena ocena studenta. Ovaj zahtev se moe naruiti zbog sloene formule za izraunavanje
ili zbog performansi sistema - lake je da se ima na jednom mestu ve izraunata vrednost - pri
tome se oslanjamo na program da e redovno aurirati ovu vrednost, kad god se desi neka
promena.
2. OGRANIENJA
a. Vrednosna ogranienja
- Ogranienja domena - ogranienje elementarnog podatka na odreen domen vrednosti
- Sloena ogranienja - dozvoljeni odnosi izmeu vrednosti razliitih atributa (npr. starost manja
od 30g na moe biti direktor)
b. Strukturna ogranienja
- Referencijalni integritet - odnos primarnog i njemu odgovarajueg spoljnog kljua (mora
svakom spoljnom kljuu odgovarati jedan slog sa odgovarajuim primarnim kljuem).
- Integritet kljua
- Not null
- Unique
POSEBNI OBLICI OBJEKATA I ODNOSA:

1. AGREGACIJA
- objekat- veza: kada veza ima neke atribute
- realizuje vezu M:M. Kada je ve tako, zapitajte se da li moda takav entitet moda ima vlastita
obeleja.
2. IFARNIK - Kada se neki podaci koriste u vie procesa, oni se jedinstveno izdvajaju i
povezuju sa okolnim tabelama sa onoliko relacija, koliko uloga ta tabela ima.
3. ODNOS 1:1 - Kada se radi o tabelama 1:1, treba se zapitati da li je to mogue objediniti u
jednu tabelu. Najee se to preporuuje, osim u nekim sluajevima, npr:
- Kada je potrebno razlikovati potencijalno i stvarno, to je u odnosima 1:1 (npr. zahtev za
lanstvom i podaci o lanu)
- Kada ne treba optereivati jednu tabelu koja bi se ee koristila u odnosu na ovu drugu, iji
se podaci ree koriste.
- Kada se jedan isti slog poseuje 2 ili vie puta, i edituje.
Jedna je tabela, kada se u sutini podaci unose u jednom trenutku. (npr. podaci o poslu i
ugovoru).
Pri situaciji kada su 2 tabele u odnosu 1:1, treba izabrati onu koja e drugoj predati primarni
klju, kada se prevodi u realcioni model. To je ona tabela koja je starija u vremenu, tj. tabela u
koju se najpre unose podaci, a zaim tek u ovu drugu tabelu.
4. Odnos 1:M - Primer: odnos celina -deo i zaglavlje - stavke.
5. Ne izdvajati ifarnik - Kada nije relevantno za dati sistem i mala je verovatnoa da e se
pojaviti ista vrednost elementarnog podatka, tj. ima isuvie mnogo vrednosti elementarnog
podatka. Primer: Naziv kole u tabeli sa podacima za kandidata za upis na Fakultet, na
prijemnom ispitu. Moglo bi se posebno uvati tabela KOLA, gde bi se uvala ifra, naziv,
adresa itd, ali to npr. za Informacioni sistem Fakulteta nije relevantno i to pogotovo ako se
retko (mala je verovatnoa ponavljanja) javljaju studenti iz iste kole. Dovoljno je svakome
upisati u originalnoj tabeli u polju naziv kole odgovarajuu vrednost. Meutim, ukoliko bi bila
vea verovatnoa ponavljanja, onda se izvlai napolje u poseban entitet.
6. Potreba da se pamte stanja i promene u vremenu zahtevaju posebne tabele, koje su prema
originalnoj u odnosu 1:M. Primer: Roba- Cenovnik, a ne da se polje cena nalazi u tabeli roba.
ESTO SE GREI:
Uoavanje elementarnih podataka koji su strukture
Uoavanje izraunljivih podataka
Odreivanje primarnog kljua
Veze 1:M izmedju elementarnih podataka

Domen postaje entitet ili ne, sifarnici i korisnicki svakodnevni podaci.
Preslikavanje u relacijama, kardinalitet, dependent.
Odredjivanje koji elementarni podaci idu zajedno, a koji ne
Potpunost opisivanja entiteta elementarnim podacima
Domen-posebni entitet matinih podataka
Primarni klju je naziv, a ne neki sistemski generisani broja
Iz naziva elementarnog podatka se ne moe saznati ta je to zapravo
Uoiti da neto moe da ima domen, tj. da je neto za posebnu tabelu matinih podataka.
Dobro uoiti stvarne veze izmedju entiteta. Ne popravlja se vozilo, ve kvar i to prema
radnom nalogu. Dakle, veze idu: vozilo-kvar-radni nalog-podaci o popravci.
Vremenski sled zavisnosti.
Homonimi i sinonimi
1:1 odnosi
ta je atribut, a ta entitet?
Izdvajanje ifarnika iz polja tabele - ima domenske vrednosti.
4.2. DATA ARCHITECT

Grafiki prikaz entiteta u CASE alatu Power Designer (Data Architect):
Naziv entiteta
Klju entiteta
Obeleja - atributi
Domen atributa
Prvi korak u kreiranju modela podataka jeste kreiranje novog modela u alatu DataArchitect i
uitavanje modela procesa, kao rezultata rada u alatu ProcessAnalyst (.PAM) i to izborom
opcije:
File Import PowerDesigner ProcessAnalyst
Zatim se otvara prozor, koji nas pita da izaberemo elemente modela procesa koji e biti uitani
u DataArchitect. Celokupan renik podataka bie uitan, te svi elementarni podaci, ve jednom
definisani, domeni elementarnih podataka, skladita i interna poslovna pravila, bie raspoloivi
za dalje projektovanje baze podataka, na logikom nivou.
Drugi korak u modeliranju podataka, je identifikovanje entiteta i odreivanje koji e atribut (ili
vie njih) biti kandidat za klju budue eme relacije (tabele u bazi podataka).
Heuristike za formiranje entiteta modela objekti veze obeleja:

1. Normalizacija skladita - Izabrana ili sva skladita se u ProcessAnalyst-u mogu
proglasiti entitetima. Potrebno je na kartici Definition osobina odreenog skladita
otkaiti (postaviti na logiku vrednost TRUE) opciju Is Entity. Prilikom uitavanja
modela u DataArchitect, CASE alat e automatski generisati enititete od izabranih
skladita. Zatim je potrebno uoavati odnose izmeu samih atributa i vriti normalizaciju
modela podataka.
2. Pripadnost elementarnog podatka Postavlja se pitanje: iji je elementarni

podatak? Ako je isti ispravno uoen, definisan i imenovan (npr. ImeRadnika,
PrezimeRadnika, AdresaRadnika, DatumRodjenjaRadnika i sl.), mogue je i formirati
odgovarajue entitete (u primeru - RADNIK).
3. Renik podataka pravilno definisana struktura tokova podataka (pomou {}, [], // i
<>) i skladita omoguava uoavanje klasa entiteta i veza izmeu tih entiteta. Npr.
Ispitni spisak se sastoji od 2 celine (2 entiteta): zaglavlje i telo (stavke) i sl.
ISPITNI_SPISAK:
< ISPITNIROK,
NAZIVSMERA,
GODINA,
SEMESTAR,
PREDMET,
NAZIVPREDMETA,
DATUMPOLAGANJA,
NACINPOLAGANJA,
PREZIMENASTAVNIKA,
IMENASTAVNIKA,
PREZIMEISPITIVACA,
IMEISPITIVACA,
{< REDNIBROJ,
BROJINDEKSA,
PREZIME,
IME,
NACINSTUDIRANJA,
KOJIPUT
>}
>;
4. Analizom opisa posla itanjem opisa posla, se uoavaju entiteti kao imenice ovog
opisa, a glagoli kao veze izmeu entiteta.
Prikaz ekrana za definisanje atributa entiteta:
Dodavanje novog svojstva, tj. atributa u entitet, se vri izborom opcije Add, pri emu se otvara
prozor sa listom svih elementarnih podataka i preuzima se jedno ili vie podataka koja postaju
atributi.
Znaenje osobina atributa: Mandatory obavezan podatak, isto to i Not Null vrednost
atributa. Ako je postavljeno na TRUE, znai da konkretna vrednost (podatak) atributa ne moe
biti nedefinisana (Null). Identifier je atirbut koji se proglaava za kandidata za primarni klju
entiteta. Uvek se nalazi na vrhu liste atributa entiteta. Display svojstvo, koje odreuje, da li e
atribut biti prikazan na ekranu ili ne.
4.3. KLJUEVI ENTITETA

Jedan atribut, ill grupa njih mora igrati ulogu identifikatora entiteta, tj. budue eme relacije
tabele u bazi podataka. Ovaj identifikator obezbeuje jedinstvenost reda tabele i ni u jednom
redu tabele njegova vrednost ne sme bitl izostavljena.
ldentifikator relacije se drugaije zove KLJU RELACIJE i predstavlja prost ili sloen atribut koji
poseduje osobine jedtnstvenosti i neredundantnosti. Osobina jedinstvenosti se odnosi na
injenicu da u relaciji (tabeli) ne smeju postojati dve iste n-torke (reda). To je omogueno
upravo uvoenjem kljua, ija se vrednost u relaciji pojavljuje samo jednom, pa se samim tim i
svi redovi razlikuju, ako ni po emu drugom, onda bar po vrednostima kljua. Osobina neredun-
dantnosti podrazumeva da nijedan atribut iz grupe atributa ne sme da se izostavi, a da ova
grupa ne izgubi osobinu jedinstvenosti. Prema tome, klju relacije je najmanja mogua
kombinacija atributa u relaciji koja poseduje osobinu jedinstvenosti. Sloeni atribut (grupa
atributa) koja poseduje osobinu jedinstvenosti, ali ne i osobinu neredundantnosti se naziva
SUPERKLJU relacije.
U relaciji moe postojati vie atributa koji zadovoljavaju osobine kljua. Svi oni se zovu
KANDIDATI ZA KLJU. Atribut koji se izabere da bude klju relacije se naziva PRIMARNI KLJU,
a ostali kandidati se nazivaju ALTERNATIVNI KLJUEVI. SPOLJNI KLJU relacije je atribut koji u
posmatranoj relaciji ne igra ulogu primarnog kljua, ali je zato u nekoj drugoj relaciji primarni
klju.
Napomena: Ako je prvi korak u kreiranju modela podataka u DataArchitect-u, bio uitavanje
modela procesa, kao rezultata rada u alatu ProcessAnalyst (.PAM), treba voditi rauna da se
atributi koji se proglase identifikatorom, tj. kljuem, MORAJU prvo obrisati iz svih drugih
entiteta, u kojima se nalaze.
4.4. NORMALNE FORME I NORMALIZACIJA BAZE PODATAKA

Baza podataka je statika slika realnog sistema, odnosno skup podataka o objektima u sistemu i
nainu na koji su oni meusobno povezani. Relaciona baza podataka predstavlja takvu bazu
podataka u kojoj su podaci organizovani u relacije (odnosno tabele). Meutim, sam nain
organizovanja podataka u relacije nije tako jednostavan i nikako ne moe biti proizvoljan.
Pitanje organizacije podataka u relacije je problem logikog projektiovanja baze podataka.
Relacija je, po matematikoj definiciji podskup skupa Dekartovog proizvoda domena obelea
odnosno skup n-torki: R (a1, a2. .... an) gde su a1, a2. ..., an atributi relacije. Atributi relacije
ne mogu biti proizvoljno izabrani, jer u sluaju njihovog loeg izbora moe doi do velikih
problema prilikom implementacije aplikacija za auriranje same baze podataka. Da ne bi dolazilo
do takvih problema relacije se projektuju saglasno NORMALNIM FORMAMA. Normalne forme
predstavljaju pravila o grupisanju atributa u relacije pri emu se vodi rauna o logikim vezama
i zavisnostima izmedu atributa.
Normalizacija podataka je proces podeavanja strukture baze podataka kako bi se izbegle
anomalije dodavanja, brisanja i izmene u relacionoj bazi podataka.
Napomena: S obzirom da se projektovanje baze podataka odvija u CASE alatu, Power

Designer, u 2 nivoa: logikom (CONCEPTUAL DATA MODEL CDM: odgovara E-R-A modelu, tj.
MOV-u) i fizikom (PHYSICAL DATA MODEL PDM: odgovara relacionom modelu, tj. tabelama
budue baze), normalizacija se moe vriti u relacionom modelu, ali je mnogo praktinije,
poznavajui pravila za prevoenje MOV u relacioni model, izvriti normalizaciju na logikom
(konceptualnom) nivou. Razlog je u tome to, naknadne izmene u logikom modelu mogu
izazvati velike promene u fizikom, te se moe desiti, da se normalizacija mora vriti ponovo, na
fizikom nivou.
Prva normalna forma

Svi atributi relacije moraju biti iz prostih domena, tj. domeni svih atributa moraju
biti atomarne vrednosti. Tanije, atribut relacije ne moe biti iz sloenog domena, odnosno
ne moe i on sam biti relacija. Ukoliko je atribut iz sloenog domena, vie nije re o relacionom
modelu, ve o objektnom. Ako je ovaj uslov zadovoljen, relacija je u PRVOJ NORMALNOJ
FORMI.
Meutim, objekti u realnom sistemu vrlo esto imaju atribute iz sloenih domena. Tanije, vrlo
esto se kao atribut pojavljuje grupa sa ponavljanjem, odnosno niz nekih elementa.
Reprezentativni primer je faktura koja sadri neke osnovne atribute, kao to su: datum, kupac,
mesto, adresa, telefon (i druge atribute koji opisuju fakturu u celini) i nekoliko stavki fakture
koje se sastoje iz atributa kao to su: artikl, koliina, jedinica mere, jedinina cena, ukupna
cena. Stavke fakture se ponavljaju vie puta, a osnovni atributi samo jednom. Ovakve tabele su
nenormalizovane. Faktura, npr. se, ovakva kakva je, ne moe predstaviti relacionim modelom.
Reenje se nalazi u ponavljanju osnovnih atributa za svaki red grupe sa ponavljanjem. Tako bi
se faktura predstavila relacijom koja bi imala sve pomenute atribute. Osnovni atributi bi se
nepotrebno ponavljali, ali bi se u ovom sluaju faktura bar mogla predstaviti relacijom. Reenje
nije optimalno, all zato postoje druga, trea, ... normalna forma.
Druga normalna forma

Dok se prva normalna forma bavi definicijom relacije i domenima atributa, druga, a i sve ostale
normalne forme, se bavi odnosom i meuzavisnostima atributa, tj. zavisnostima atributa.
Primer: Ako postoji relacija (u MOV-u entitet) STUDENT (BRINDEKSA, IME, POSTA, MESTO,
ADRESA, PREDMET, OCENA) iz nje moemo izdvojiti za primer dve funkcionalne zavisnosti:
Atribut BRINDEKSA odreuje atribut IME, a sloeni atribut BRINDEKSA, POSTA odreuje atribut
ADRESA. Naravno, ove dve zavisnosti nisu jedine u ovoj relaciji, ali su samo ove dve uzete za
primer. Prva zavisnost je potpuna funkcionalna zavisnost, jer atribut IME zavisi od atributa
BRINDEKSA, ali ne i od njegovih delova (jer je atribut BRINDEKSA prost). Iz ovoga se moe
izvesti zakljuak da su sve funkcionalne zavisnosti od prostog atributa ujedno i potpune funkci-
onalne zavisnosti. Sa druge strane, zavisnost atributa ADRESA nije potpuno funkcionaina, jer
atribut ADRESA zavisi funkcionalno i od samog atributa BROJINDEKSA koji je deo sloenog
atributa BRINDEKSA, POSTA. Na osnovu potpune funkcionalne zavisnosti definie se i druga
normalna forma. Relacija je u drugoj normalnoj formi ako je u prvoj i ako su svi njeni nekljuni
atributi potpuno tunkcionalno zavisni od primarnog kljua te relacije.
Da li relacija STUDENT zadovoljava uslove postavljene definicijom druge normalne forme? U
ovoj relaciji samo sloeni atribut BRINDEKSA, PREDMET odreduje sve ostale atribute u relaciji.
Dakle, on igra ulogu primarnog kljua, ali nisu svi atributi POTPUNO funkcionalno zavisni od
njega. Atributi IME, POSTA, MESTO i ADRESA su zavisni samo od aiributa BRINDEKSA, koji je
deo primarnog kljua. U emu je reenje? Relacija koja nije u drugoj normalnoj formi (ali je u
prvoj) se dekomponuje u dve ili vie relacija koje jesu u drugoj normalnoj formi, iz kojih se
operacijom prirodnog spajanja moe rekonstruisati poetna relacija, i to tako da se sve

nepotpune funkcionalne zavisnosti odvoje u posebne relacije. Tako bi se, primenom definicije
druge normalne forme, relacija STUDENT dekomponovala u relacije:
STUDENT (BRINDEKSA, IME, POSTA, MESTO, ADRESA)
OCENA (BRINDEKSA, PREDMET, OCENA)
Ove dve relacije jesu u drugoj normalnoj formi jer su svi atributi u njima potpuno
funkcionalno zavisni od svojih primarnih kljueva.
Relacija je sigurno u drugoj normalnoj formi, ako je kandidat za njen primarni klju prosto
(elementarno) obeleje (na primer, JMBG, ili PTT, ili SIF_RADNIKA).
Relacije koje su u drugoj normalnoj formi jo uvek nisu optimalne i kod njih jo uvek mogu
postojati anomalije auriranja (unos, brisanje i izmena) podataka.
Trea normalna forma

Konkretan primer se moe videti u jednom od prethodnih redova. Primenom definicije druge
normalne forme, dobijena je relacija STUDENT (BRINDEKSA, IME, POSTA, MESTO, ADRESA).
Atribut BRINDEKSA je primarni klju relacije STUDENT i, logino, funkcionalno odreuje sve
ostale atribute u relaciji. Meutim, ovaj atribut nije jedini koji odreuje neto u relaciji. Atribut
POSTA funkcionalno odreduje atribut MESTO.
Trea normalna forma ne dozvoljava tranzitivne zavsnosti. ta je loe u tranzitivnoj zavisnosti?
Ukoliko postoje tranzitivne zavisnosti, postoje i anomalije u auriranju. Na primer, zamislite se i
odgovorite na pitanje: "ta je potrebno uraditi da bi se u bazu podataka uneo podatak o nekom
mestu?". Podaci o mestu, u ovom sluaju, su zavisni od podataka o studentu, to ne bi smelo
da se desi. Dakle, relacija je u treoj normalnoj formi, ako je u drugoj normalnoj formi
i u njoj ne postoje tranzitivne zavisnosti nekljunih atributa od kljua (primarnog ili
alternativnog).
Relacija koja nije u treoj normalnoj formi (all jeste u drugoj) se dekomponuje u relacije koje
jesu u treoj normalnoj formi, a iz kojih se operacijom prirodnog spajanja moe dobiti polazna
relacija, i to tako da se odvoje tranzitivne zavisnosti. Tako bi se pomenuta relaclja STUDENT
(BRINDEKSA, IME, POSTA, MESTO, ADRESA) dekomponovala na relacije: STUDENT
(BRINDEKSA, IME, POSTA, ADRESA) i MESTO (POSTA, MESTO). Ove dve relacije jesu u treoj
normalnoj formi i iz njih se operacijom prirodnog spajanja preko atributa POSTA moe
rekonstruisati polazna relacija. Primena definicije tree normalne forme i normalizacija relacija
saglasno njoj nije kraj - iako trea normalna forma ne dozvoljava tranzitivne zavisnosti
nekljunih atributa od kljua. Tranzitivne zavisnosti se i dalje mogu pojaviti izmedu samih
kljunih atributa. Zbog toga se uvodi pojam Boye-Codd ove normalne forme, ali o ovoj
normalno formi detaljnije videti u [MLG].
U prethodnom tekstu opisana je metoda normalizacije vertikalna dekompozicija. Ona

vertikalno deli relacije na osnovu operacije relacione algebre projekcije. Da bi se ouvao
princip dekompozicije bez gubitka informacije uvode se i pojmovi 4 Normalne Forme, koja se
zasniva na vieznanim zavisnostima atributa u emi relacije, kao i 5 Normalne Forme, koja se,
upravo, zasniva na zavisnostima spoja. Zavisnost spoja, kao to samo ime kae, obezbeuje
rekonstrukciju polazne relacije na osnovu spoja dobijenih dekomponovanih relacija.
Osim metode dekompozicije, postoji i metoda sinteze [MLG]. Ova metoda se zasniva na
generisanju skupa ema relacija poev od polaznog skupa obeleja i skupa ogranienja (zadatog
skupa zavisnosti: funkcionalnih, zavisnosti spoja, vieznanih zavisnosti, koje zadaje projektant
informacionog sistema). U svakom narednom koraku ovog postupka, eme relacija se
sintetizuju u odnosu na postavljena ogranienja.
4.5. USPOSTAVLJANJE VEZA IZMEU ENTITETA

Grafiki simbol za prikazivanje veze izmeu entiteta u modelu objekti-veze:
ENTITET1 (DGK,GGK) (DGK,GGK) ENTITET2

VEZA
Kardinalnost veze predstavlja broj pojavljivanja entiteta s druge strane veze, s kojim je
posmatrani entitet povezan. Prvi broj je najmanje mogui broj pojavljivanja drugog entiteta (tj.
donja granica kardinalnosti i oznaava se sa DGK), a drugi najvii (tj. gornja granica
kardinalnosti i oznaava se sa GGK), pri emu oznaka "M" predstavlja nepoznat broj
pojavljivanja.
U Power Designeru se veza izmeu 2 entiteta uspostavlja jednostavnim izborom opcije

Relationship sa palete alata (Tools) i prevlaenjem iz povrine jednog entiteta u povrinu
drugog entiteta, koji su u meusobnoj vezi:
Sledi odreivanje naziva veze (glagol, glagoslka konstrukcija koja proistie iz prirode same
veze), vrste veze izmeu entiteta (1:1, 1:M, M:M) i kardinaliteta preslikavanja preko ekrana
Relationship Properties, koji se otvara izborom opcije Properties na tri naina ravnopravno
(dvostruki klik na grafikom prikazu veze, jednostruki klik koji daje iskaui meni ili izborom
opcije sa palete alata).
Naziv veze se upisuje u polje Name, dok polje Code predstavlja jedinstveni identifikator
objekta u celokupnom modelu podataka, analogno radu u Process Analystu.
Tip veze se odreuje preko polja (option button-a) Cardinality. Gornja granica kardinaliteta je
odreena tipom (vrstom) veze i moe biti: 1,1 (veza jedan prema jedan); 1,n i n,1 (veza jedan
prema vie); n,n (veza vie prema vie).
Donju granicu kardinaliteta odreuje polje Mandatory i to u 2 smera, posebno. U primeru kao
na slici, postavljaju se uvek 2 pitanja koja odreuju donju granicu kardinaliteta:
1. SMER MESTO PREMA STUDENTU: Da li za bilo koju pojavu prvog entiteta (levi na slici)
mora postojati (u evidenciji u BP, a ne i u fizikom, realnom sistemu) njemu zavisna pojava
u drugom entitetu? Ako je odgovor potvrdan bira se Mandatory (True) u protivnom, ne.
2. SMER STUDENT PREMA MESTU: Da li za bilo koju pojavu drugog entiteta (desni na slici)
mora postojati njemu zavisna pojava u prvomom entitetu? Ako je odgovor potvrdan bira se
Mandatory (True) u protivnom, ne.
Primer: Zemlja ima mesto, mesto pripada zemlji (misli se na dravu). Kada se pitamo za
kardinalitet veze, tada se ne posmatra da li zemlja fiziki mora da IMA grad (mesto) da bi
postojala, nego da li je za evidenciju u tabeli zemalja neophodno da postoji i u tabeli mesta bar
1 mesto koje odgovara toj zemlji. Odgovor je Ne, tako da je za vezu Zemlje prema Mesta
Mandatory=False.
Dependent znai identifikacionu zavisnost entiteta od entiteta, a prikazuje se na

odgovarajuem preslikavanju. To se javlja kod slabih objekata i agregacija. To znai da e onaj
entitet koji je dependent (identifikaciono zavistan) dobiti primarni klju ovog drugog entiteta ali
u funkciji dela njegovog primarnog kljua (entitet ima svoj klju + dobijeni, koji zajedno ine
sloeni primarni klju u sluaju JAK-SLAB objekat ili bez svog kljua ako je u pitanju
AGREGACIJA).
Dominant se ukljuuje samo ako je veza 1:1. Dominantan je onaj koji je stariji u vremenu
(opet u u evidenciji u BP, a ne i u fizikom, realnom sistemu).
Polje Generate se odnosi na to da li e od izabranog entiteta nastati tabela ili ne.
Napomena: U Power Designeru se kod svake relacije (1:M) ubacuje na strani M klju iz strane
1, tako da nije potrebno ubacivati polje(a) koje uestvuje u relaciji. To ubacivanje se vri kada
se sa Konceptualnog prelazi na Fiziki model (Generate Physical Model).
Konvencija: Primarni klju treba u navoenju u tabeli unositi na prvom mestu (najvia pozicija
u tabeli definicija). Ako smo uneli negde dole, pomera se navie strelicama sa strane.
4.6. PRAVILA KOD PREVOENJA E-R-A (MOV) MODELA U

RELACIONI MODEL PODATAKA
Relacija 1:1 se obino prevodi u jednu tabelu koja ih obe sadri; izuzetak je da su to dve tabele
kada je tabela izuzetno optereena kolonama (poljima) i podacima i kada se jedan deo tabele
(kolona) znatno frekventnije koristi od drugih delova. Tada moe dve ili vie tabela.
Veza M:M se prevodi u 1:M i 1:M sa agregacijom izmedju ili ako veza ima vlastite osobine, onda
je to objekat veza ili agregacija. Npr. student-predmet veza je M:M, ali ako bismo prepustili
CASE alatu da rei ovu vezu, ne bismo mogli da postavimo vlastite osobine ove veze kao to je
datum polaganja i ocena na tom ispitu. Agregacija se realizuje tako to se posebna tabela
formira koja sadri primarne kljueve od obe tabele koje agregira (npr. STUDENT-ISPITI), i ima
jo neka svoja obeleja, atribute koji su nekljuna.
PREVOENJE MODELA PODATAKA U RELACIONI MODEL
U okviru dijagrama (MOV), definiu se:

atributi entiteta, tipovi podataka, odgovarajua ogranienja. Po kreiranju MOV-a moe se
pristupiti prevodenju strukture MOV-a u odgovarajui relacioni model. Za to postoji definisani
skup pravila po kojima:
- svaki entitet postaje ema relacije (tj. tabela),
- atributi posmatranog entiteta postaju atributi relacija,
- atributi posmatranog entiteta postaju i identifikatori povezanih entiteta prema kojima je
donja i gornja granica kardinalnosti preslikavanja jednaka 1,
- klju relacije nastale od jakog entiteta je njegov identifikator,
- klju relacije nastale od slabog entiteta je identifikator nadreenog jakog entiteta
proiren sa jednim ili vie atributa slabog entiteta,

- klju relacije nastale od agregacije je sloeni klju koji se sastoji od identifikatora eniteta
koji ine agregaciju.
Primena ovih pravila se moe obaviti runo, ali zahvaljujui savremenim CASE alatima ovaj
postupak se sada obavlja automatizovano. Dobijena relaciona ema je potpuno normalizovana.
Ona ispunjava sve zahteve tzv. tree normalne forme i sadri sve integritete koje konkretan
sistem za upravljenje bazom podataka (SUBP) podrava, tj. referencijalni integritet, integritet
kljua, integritet domena, integritet za operacije nad bazom podataka i sl.
Pre prevoenja E-R-A (MOV) modela u relacioni, potrebno je uraditi po jedan podmodel za svaki
primitivni proces iz Strukturne Sistem Analize i to iz sledeih razloga:
- Kontrola ispravnosti projektovanja globalnog Modela Podataka koji bi nastao integracijom
ovih podmodela.
- Priprema i odreivanje potrebnih podataka programeru koji e iskodirati odgovarajue
maske (ekrane) za auriranje, prikaz, pregled i pretragu podataka, te ekrane za izvetaje
i sl.
U fizikom modelu podataka (Physical Data Model ili PDM) se vri dodavanje i definisanje
alternativnih (semantikih) kljueva u buduim tabelama, koji treba da obezbede eliminisanje
redundanse i nedozvoljenih unosa podataka, a potom i ogranienja nad podacima u vidu
Referencijalnog integriteta.
Nakon generisanja relacione eme pristupa se kreiranju baze podataka u izabranom SUBP, sledi
definisanje aplikacije(a) u vidu projekta aplikacije, a zatim i izradi, testiranju primeni programa,
odnosno njegovom odravanju.
4.7. PODMODELI U KONCEPTUALNOM MODELU

Kao to je ve napomenuto, potrebno je uraditi po jedan podmodel za svaki primitivni proces iz
strukturne sistem analize i to iz sledeih razloga:
- Kontrola ispravnosti projektovanja globalnog modela podataka koji bi nastao integracijom
ovih podmodela.
- Priprema i odreivanje potrebnih podataka programeru koji e iskodirati odgovarajue
maske (ekrane) za auriranje, prikaz, pregled i pretragu podataka, te ekrane za izvetaje
i sl.
U meniju Dictionary, se za svaki primitivan proces bira opcija:
Dictionary -> Submodel -> New
Nakon otvaranja podmodela se dodaju, izborom (selektovanjem), entiteti potrebni za

izvravanje (rad, funkionisanje) tog primitivnog procesa. Prebacivanje izabranih entiteta u
podmodel, vri se tasterom Add.
Kako se entiteti pojavljuju u prozoru Selected objects, automatski CASE alat dodaje i veze
koje postoje izmeu tih entiteta. Ukoliko se ne otvara automatski ovaj prozor (bio je selektovan
neki entitet npr.), potrebno je pokrenuti opciju
Dictionary -> Submodel -> Add/Remove Objects
te e se otvoriti gore prikazani ekran.
Imena podmodela su nazivi primitivnih procesa, a nakon izbora opcije
Dictionary -> Submodel -> List of Submodels
gde se odreuju ime - Name i jedinstveni identifikator Code, za odreeni podmodel sa liste
postojeih podmodela.
4.8. POSTUPAK PREVOENJA LOGIKOG U FIZIKI

MODEL PODATAKA
Kod prevoenja logikog u fiziki model podataka:
Dictionary -> Generate Physical Model
prvo se otvara prozor koji nas pita da li elimo da snimimo model ili ne, te se pojavljuje ekran
koji prethodi postupku prevoenje. Tu se bira sledee:
- Format budue baze podataka (Database Name),
- Putanja fizikog modela (PDM File Name),

- Elementi fikog modela (Options),
- Stil naziva indeksnih fajlova (Index) i
- Referencijalni integritet (Reference).
4.9. OGRANIENJA NAD BAZOM PODATAKA

Baza podataka mora u svakom trenutku zadovoljavati odreeni skup zadatih uslova integriteta,
odnosno ogranienja. Ta ogranienja su posledica: zakonske regulative u datoj oblasti, internih
pravila poslovanja, uobiajenih normi ponaanja i slino. Ukoliko su svi uslovi ispunjeni, tada je
baza podataka u konzistentnom stanju. Drugim reima, za bazu podataka, koja je usaglaena sa
promenama u realnom sistemu kae se da je konzistentna [ML].
Osim strukture, model podataka poseduje i neka ogranienja, kao i operacije koje se vre u
sluaju naruavanja istih, da bi se baza podataka vratila u konzistentno, ispravno stanje.
Ogranienja modela podataka se mogu podeliti u dve velike grupe:

- vrednosna ogranienja
- stukturna ogranienja
Pod vrednosnim ogranienjima se podrazumevaju jednostavna ogranienja (ogranienja

domena) i sloena vrednosna ogranienja. Ogranienja domena su ona koja se tiu skupa
(domena) iz kojih atribut uzima vrednosti. Na primer, atribut OCENA moe uzimati vrednosti iz
zatvorenog skupa celih brojeva (5, 6, 7, 8, 9, 10). Atribut BRINDEKSA moe biti definisan ka
broj (koji oznaava redni broj studenta u godini u kojoj se upisao na fakultet) iza koga sledi
znak /, godina upisa fakulteta, a potom jo jedan dvocigren broj (koji oznaava smer i status
studenta). Tako bi podaci: 123/90-011, 101/97-022 bili regularni brojevi indeksa, a podaci kao:
PERA/93-021, 12C/90-POT nikako ne bi smeli biti uneti u bazu podataka. Ova ogranienja su
jednostavna i mogue je napraviti mehanizme provere za svaki od njih. Na alost, veina
relacionih ststema za upravljanje bazom podataka nemaju implementirane ovakve mehanizme.
Sloena vrednosna ogranienja se tiu odnosa izmeu vrednosti razliitlh atributa. Na primer, u
modelu podataka moe postojati ogranienje da ukoliko radnik ima manje od 30 godina, onda
njegova funkcija u preduzeu ne moe biti diirektor, takoe, ukoliko ukupna vrednost rauna
prelazi odredenu sumu (na primer 2000 dinara), onda ona mora biti odobrena od strane
finansijskog dfrektora. Primera za sloena vrednosna ogranienja ima mnogo u realnim

sistemima i ona se nikako ne mogu izbei. Ali, u klasinim relacionim sistemima za upravljanje
bazom podataka, ova ogranienja se ne mogu predstavlti bazom podataka. Kada bi bila jedina,
vrednosna ogranienja i ne bi predstavljala veliki problem.
Ali, osim vrednosnih postoje i strukturna ogranienja. Ova ogranienja se odnose na veze
izmeu objekata u sistemu. Na primer, svaki radnik u preduzeu mora raditi u jednom i samo
jednom odeljenju, a odeljenje moe imati 0, 1 ili vie radnika. Faktura mora imati bar jednu
stavku, a stavka mora imati samo jednu fakturu kojoj pripada.
Kod sturkturnih ogranienja obavezno je pomenuti dva pravila integriteta:
- integritet entiteta (integritet kljua)
- referencijalni integritet.
Integritet kljua je pravilo po kome primarni klju relacije obavezno mora imati vrednost, to
znai da ne moe biti definisan kao polje u koje se moe, ali i ne mora upisati vrednost. Dakle,
primarni klju uvek mora imati konkretnu vrednost, i ta vrednost mora biti jedinstvena u
posmatranoj relaciji. Znai da se u relaciji STUDENT (BRINDEKSA, IME ...) ne sme pojaviti vie
od jedne n-torke sa odreenom vrednou primarnog kljua (u ovom sluaju je to atribut BRIN-
DEKSA).
Semantiki kljuevi se u fizikom modelu podataka, u DATA ARCHITECT-u dodaju iz razloga

to je primarni klju u vudi brojaa (Sifra ili ID) dovoljan da se uspostavi veza izmeu 2 entiteta
i minimalan u pogledu duine polja koja se prenosi u druge tabele (izbegava se nagomilavanje
sloenih primarnih kljueva), ali ne spreava redundansu i viestruko memorisanje istih
podataka. Ovo je veoma opasno za integritet podataka u bazi i moe dovesti do greaka koje se
kasnije izuzetno teko otkrivaju i ispravljaju. Postupak dodavanja semantikih-alternativnih
kljueva je sledei:
Dvostruki klik levim tasterom mia na entitetu, ili jednostruki desni, pa potom opcija
Properties otvara osobine tog entiteta:
Sledi otvaranje dijaloga za definisanje indeksa, gde se opcijom Insert dodaje novi indeks koji
e biti sastavljen iz nekoliko polja i koji e imati osobinu jedinstvenosti Unique = True, a nee
biti primaran:
Izbor polja (kolona) budue tabele, koja ine semantiki indeks, se vri pomou tastera <Ctrl>
+ Levi klik na ponuene atribute entiteta:
Referencijalni integritet se tie odnosa izmedu spoljnog kljua u relaciji i primarnog kljua u
nekoj drugoj relaciji, a koji uzima vrednosti iz istog domena kao i posmatrani spoljni klju. Ovo
pravilo integriteta nalae da se svaka vrednost spoljnog kljua u tabeli mora pojaviti i kao
vrednost primarnog kljua u tabeli gde je odredeni atribut primarni klju. Ako, na primer,
postoje relacije RADNIK (SIFRAD, IME, SIFODEL) i ODELJENJE (SIFODEL, NAZIV), onda u rela-
ciji radnik svaka ifra odeljenja (SIFODEL) mora imati pojavljivanje u relaciji ODELJENJE, u
atributu SIFODEL. Drugim reima, radnik ne moe raditi u nepostojeem odeljenju. Ukoliko je
za radika uneta ifra odeljenja 1234, onda u relaciji ODELJENJE mora postojati odeljenje sa is-
tom ifrom. To znai, da se pri unosu novih podataka mora voditi rauna o vrednosti spoljnog
kljua, odnosno, mora se paziti da se ne ubaci radnik koji radi u nepostojeem odeljenju. Ali, to
nije dovoljno. Pri brisanju podataka iz relacije ODELJENJE, mora se voditi rauna o tome da se
ne obrie odeljenje u kome rade neki radnici, jer e isti ostati vezani za nepostojee odeljenje
(jer je obrisano).
U Data Architect-u se ouvanje referencijalnog integriteta odreuje za svaku vezu izmeu tabela
pojedinano:
1. Za operaciju UPDATE (dodavanje novih i izmena postojeih podataka u tabeli). Mogua

su tri sluaja:
None Ne postoji ouvanje referencijalnog ontegriteta. Ukoliko se u tabeli roditelja
(strana 1) promeni vrednost primarnog kljua (slog, n-torka), ostaju visei podaci u
tabeli dete (strana M - vie). Tim slogovima se vie ne moe pristupiti, jer imaju staru
vrednost prim. kljua. NIKAKO NIJE DOBAR IZBOR.
Restrict Restriktivno ouvanje referencijalnog ontegriteta. Ukoliko se u tabeli na
strani 1 promeni vrednost primarnog kljua, a postoje na strana vie vezani slogovi, BP
ne dozvoljava promenu te vrednosti primarnog kljua. Samo u sluaju da ne postoji
upotrebljen prim. klju na strani vie, mogue e biti promeniti vrednost prim. kljua.
Cascade Kaskadno ouvanje referencijalnog ontegriteta. Ukoliko se u tabeli na strani
1 promeni vrednost primarnog kljua, a postoje na strana vie vezani slogovi, BP
automatski vri promenu te vrednosti na strani vie.
2. Za operaciju DELETE (brisanje nepotrebnih podataka iz tabele). Takoe su mogua tri

sluaja:
None Ukoliko se u tabeli na strani 1 obrie podatak, ostaju visei podaci u tabeli na
strani M-vie. Tim slogovima se vie ne moe pristupiti, jer imaju staru vrednost prim.
kljua. TAKOE, NIKAKO NIJE DOBAR IZBOR.
Restrict Ukoliko se u tabeli na strani 1 obrie podatak, a postoje na strana vie vezani
slogovi, BP ne dozvoljava ovo brisanje jer je primarni klju upotrebljen. Samo u sluaju da
ne postoji upotrebljen primarni klju na strani vie, mogue je brisati podatak.
Cascade Ukoliko se u tabeli na strani 1 brie vrednost primarnog kljua, a postoje na
strana vie vezani slogovi, BP automatski vri brisanje svih slogova sa tom vrednou i
mnogo podataka na strani vie moe biti izgubljeno.
4.10. GENERISANJE BAZE PODATAKA

Fiziki model podataka mora biti potpuno tehniki (sintaksno) ispravan, jer se u protivnom nee
izvriti generisanje baze. Ako se pojave greke, neophodno je prvo ih ispraviti i tek tada
pristupiti generisanju baze podataka vri na jednom nekoliko naina:
1. Kreiranjem prazne baze podataka u nekom sistemu za upravljanje bazom podataka -
SUBP (npr. Access, SQLServer), koja ne sadri nijednu tabelu, pa se zatim iz Data
Architect-a konektujemo na tu bazu opcijom:
Database -> Connect
i potom izaberemo:
Database -> Generate Database;
2. Snimanjem script fajla, koji u sebi sadri SQL kod (sadri naredbe za kreiranje polja,
njihovih domena, indeksa, relacija meu tabelama i sl.) i koji se zatim pokree u
nekom od SUBP-a (npr. FoxPro, DBase);
3. Direktnim kreiranjem baze podataka (npr. Paradox, Delphi i sl.).
Napomena: U kartici Options podesiti, neposredno pre generisanja baze podataka sledee:
ODBC (Open Database Connectivity mehanizam za otvoreno povezivanje baza
podataka razliitih formata) Syntax = True
Character Set = Windows
Nakon generisanja baze podataka u izabranom SUBP, sledi definisanje aplikacije(a) u vidu
projekta aplikacije, a zatim i izradi, testiranju, primeni programa, odnosno njegovom
odravanju i dokumentovanju.
5. PROGRAMIRANJE
5.1. DIZAJN APLIKACIJE

Struni tim koji uestvuju u izradi aplikacije sastoji se:
1. Bussiness analitiar - intervjuie domenske strunjake, klijente i zadatak mu je da razume
problematiku domenske oblasti, potrebe (procesi, podaci) realnog sistema i zahteve korisnika i
da to predstavi kroz odgovarajuu dokumentaciju. Takoe, radi i sa ininjerima na
implementaciji, praenjem pokrivenosti uoenih potreba realnog sistema.
2. Sistem analitiar - modelira realan sistem na osnovu dokumentacije od strane bussiness
analitiara
3. Dizajner baze podataka radi MOV i BP
4. Dizajner ekrana - osmiljava izgled i funkcionisanje svih ekrana (user friendly)
5. Programer (Engineering staff)
6. Strunjak za hardver (Engineering staff)
7. Strunjak za mree
5.2. PROGRAMSKI JEZICI I ALATI

Za seminarski rad, osobine koje treba da imaju alati za programiranje:
- objektno orjentisani (biblioteke gotovih klasa i mogunost pravljenja vlastitih)
- event driven (programiranje dogaaja)
- GUI okruenje za razvoj i izgled aplikacije
Visual Basic
- podeavanja radnog okruenja (JET-DAO, ADO, OCX)
- osnovne operacije u korienju alata
- osnovne opcije menija i struktura alata
Korisniki interfejs za rad sa bazama podataka

- kontrole za rad sa bazama podataka i podeavanja osobina
- tipovi formi: a)1:1, 1:M, b) ifrnici, procesi iz SSA, c) auriranje, pregled, pretraga, tampa
- user friendly osobine
- standardni (lokalni standardi na nivou aplikacije ili opti standardi) izgled i ponaanja
programa (raspored kontrola, stanja ekrana itd.)
- opredeljenja za vrste KI:
a) navike korisnika ili standardi
b) orijentacija na procese i dogaaje ili orijentacija na entitete i objekte
Osmiljavanje glavnog menija
Strukturu menija aplikacije:
ifarnici, Ogranienja, Obrada, Izvetaji, Upiti, Servis
ifarnici - ekrani za unoenje optih podataka, koji se jednom unose, a kasnije koriste na
ekranima Obrada.
Ogranienja - ekrani za unos odluka koje predstavljaju ogranienja i pravila za rad.
Obrada - ekrani koji odgovaraju primitivnim procesima iz strukturne sistem analize, a stavke
menija procesima vieg nivoa. Dakle, kompletan meni Obrada odgovara stablu procesa iz SSA, a
ekrani koji se pokreu odgovaraju primitivnim procesima.
Izvetaji - ekrani za unoenje parametara za prikaz podataka i tampu standardnih ili lokalno
potrebnih dokumenata (zvanini obrasci, pojedinani podaci) i izvetaja (statistiki podaci,
podaci za period). Ovde se prikazuju izlazni tokovi podataka iz sistema prikazani u strukturnoj
sistem analizi.
Upiti - ekrani za unos parametara (jedan ili vie kriterijuma istovremeno) za pretragu i prikaz
podataka. Ovde je potrebno da se osmisle potrebni upiti sistemu, najfrekventniji
Servis - Help, About, Servis baze podataka (backup, brisanje, reindeksiranje, uitavanje starih
podataka), Korisnik programa
PRIMER: IS studentska sluba

ifarnici - Mesto, Vrsta finansiranja, Obrazovni profil, Nastavnik, Predmet ...
Ogranienja - Upis (broj studenata koji je odobren za svaki profil za neku kolsku godinu, broj
ispita za upis u narednu godinu studija, nazivi ispita za uslov za upis u narednu godinu),
Nastava (max i min broj studenata u jednoj nastavnoj grupi, max broj nastavnih asova u bloku
jednog nastavnog predmeta), ...
Obrada - Upis studenata: Evidentiranje prijava za prijemni, Formiranje spiska za polaganje
prijemnih, Evidentiranje rezultata prijemnih ispita ...
Izvetaji - Dokumenti (Uverenje o poloenim ispitima, Spisak za prijemni ispit), Statistika
(Prolaznost na ispitima u X ispitnom roku po predmentima....)
Upiti - Unapred ureeni upiti npr. Student - jedan ili vie (Kriterijum pretrage: X prezime, X ime,
X broj indeksa ili JMBG, Traeni podaci: godina studija, prosek ocena ...) ili "custom " upiti
(prikai sve kandidate na prijemnom ispitu koji su iz Gimnazije u X ispitnom roku)
Servis - npr. za Korisnika programa (ime, prezime, korisniko ime, lozinka, status - privilegije)
5.3. DIZAJNIRANJE KORISNIKOG INTERFEJSA (KI)

Pre poetka postupka dizajniranja softvera potrebno je utvrditi ciljeve IS kao i ciljeve softvera
(koncepcijski utvrditi unapred ciljeve i principe).
Primer principa koji se postavljaju pre poetka dizajniranja softvera: razvojnost, funkcionalnost,
fleksibilnost (oprema, matini podaci), ekonominost, efikasnost, adekvatnost, pouzdanost,
ergonomska usklaenost, jednostavnost, jezik komunikacije, informisanost, korektnost,
unificiranost.
TEORIJSKE OSNOVE - TA JE KORISNIKI INTERFEJS?
Komunikacija korisnik-raunar treba da bude slika realnih potreba korisnika i njegovog posla, a
ne slika vizije projektanta. Korisnici treba da urade neki posao, a raunar treba da im u tome
pomogne. Korisnik eli da koristi raunarski sistem u svom poslu kao i svaki drugi alat, sa
privikavanjem, ali da povea efikasnost i ne remeti dotadanji proces rada.
Interakcija je stil upravljanja. Korisniki interfejs je softver koji posreduje izmeu oveka i
programa oblikujui raunar u alat specifine namene.
Detaljnije o korisnikom interfejsu videti u [MD].
TIPOVI DIJALOGA
Korisniki interfejs obezbeuje komunikaciju korisnika sa raunarom putem dijaloga. Razlikuju

se generalno dva tipa dijaloga:
SEKVENCIJALAN - korisnik unosi (obino putem tastature) komandu raunaru ta sledee

treba da uradi. To je zahtev-odgovor komunikacija na nekom komandnom jeziku, koji ima
strogu sintaksu (komande u obliku glagol-imenica). Dijalozi su funkcionalno orijentisani
(funkcije sistema su u prvom planu). Jednostavniji su za projektovanje. Problemi: kruta
sintaksa, sekvencijalnost...
ASINHRON - omoguava korisniku da u jednom trenutku izda bilo koju od dozvoljenih
komandi. Pojavom mia, grafikog prikaza i ikone se javlja kao dominantan. Pojam dijaloga
sa direktnom manipulacijom je ustanovljen i zasnovan je na principu pokai i pritisni.
Objektno je koncipiran. Problemi: sloeniji za projektovanje, ikone esto ne daju dobru
asocijaciju korisniku i pretrpanost interfejsa ikonama koje mogu da zbune korisnika.
U praksi, asinhroni dijalozi preovladavaju, ali ima elemenata i sekvencijalnosti.
KORISNIKI INTERFEJS I IVOTNI CIKLUS SOFTVERA
Zahvaljujui promeni stava projektanata da treba vie panje obratiti na korisniki interfejs
(program je proizvod, namenjen korisniku i tritu), korisnik se vie ukljuuje u proces izrade
programa, tj. menja se ivotni ciklus softvera.
U praksi specifikacija zahteva se vri tako da se najpre evidentiraju zahtevi za funkcionalnou

sistema, a zatim zahtevi za korisnikim interfejsom. Analiza rezultata ostalih faza vri se kada
se uradi poetni prototip. Analiziraju se estetski izgled, stepen potrebnog memorisanja od
strane krajnjeg korisnika, lakoa rada, ergonominost, funkcionalnost, stepen fizike aktivnosti
korisnika da bi se izvrio zadatak najfrekventnijeg posla, lokalnost (delovi interfejsa koji podleu
kulturnim specifinostima korisnike grupe) i internacionalnost, vernost realnom sistemu.
Razvoj prototipa je iterativni proces. Pri tome se analiziraju razna stanja interfejsa i
potrebno je postii to veu nezavisnost interfejsa od funkcionalnog dela. Potrebna je real-time
povratna veza sa korisnikom-kada korisnik aktivira neku akciju treba da dobije indikaciju da li je
zahtev prihvaen i da eka na odgovor.
IMPLEMENTACIJA KORISNIKOG INTERFEJSA
Implementacija interfejsa se sprovodi u praksi pomou:

- toolkit - skup elemenata interfejsa su implementirani u programskoj biblioteci. Ukljuuju se u
interfejs pomou programskih poziva. Za iskusne.
- interface builder - gotovi elementi interfejsa-pokai i pritisni. Posle se definie njihovo
ponaanje. Za manje iskusne.
- user interface management system (Delphi, C++).
Trend (1997, Szekely) je ka automatizaciji svih faza razvoja korisnikog interfejsa-na osnovu
modela zadataka, objekata rada, stilova prezentacije i dijaloga se generie optimalni interfejs.
Modeli se grade na osnovu specifikacije zahteva korisnika. U praksi je pokazano da ipak ovek
formira izgled interfejsa na osnovu predloenih solucija.
Tako je u Visual Basic 5.0 prisutan ADD-In Manger kojim se ukljuuju dodatni alati za brzo i
standardizovano pravljenje aplikacije. Tako se ukljuuju razni alati tipa Tools i Wizards, koji
omoguuju brzo kreiranje formi uz neophodne manje prepravke, tj. prilagoavanja na
konkretne zahteve korisnika. Jedan od njih je i Application Wizard koji kreira celu aplikaciju. Tu
je i Data Form Wizard, koji kreira forme vezane za bazu: pojedinani unos, tabela, pojedinani+
tabela (master+detail->za povezivanje dveju tabela koje su vezane kljuem).
PRINCIPI IZRADE KORISNIKOG INTERFEJSA

Na ovom mestu se navode principi do kojih su autori doli u izradi seminarskih radova na kursu
Informacioni sistemi . Inae, o optim principima korisnikog interfejsa videti u [MD].
1. Razdvojiti funkcionalnost (svrha rada programa) i korisniki interfejs

2. Osnovna dva aspekta KI su upravljaki (upravljaki pult programa) i estetski (izgled, zvuk i
sl.)
3. U svakom trenutku korisnik treba da jasno zna stanje programa (aktivne opcije, ekanje zbog
snimanja i sl.)
4. Ekran ne sme biti pretrpan informacijama, funkcijama i bojama
5. Ekran treba da sadri to vie informacija
6. Put do informacija treba da je to krai
7. Put do aktiviranja funkcija treba da je to krai
8. Poruke i upozorenja uvek da su na istom mestu na ekranu
9. Program mora da ima help sistem
10. KI treba da bude podeljiv
11. Princip upravljanjem miem - koristiti razliite pokazivae mia (standardne Windows) za
odreena stanja i pozicije u programu.
12. Princip upravljanja ekranom - prikaz u uklanjanje ekrana i osveavanje monitora u skladu sa
potrebama
13. Principi rukovanja bojom - poslovne aplikacije ne smeju biti arene, boja slui da odreeni
deo ekrana (u odreenim stanjima programa) istakne (crvena-alarm; uta-informacija,
upozorenje), blink jo vie privlai panju, iste vrste poruka uvek istom bojom.
14. Principi rukovanja zvukom - zvuk se koristi u 2 smisla: 1 - kao alarm (u kombinaciji sa
crvenom i blink), 2 afirmativno (a- nakon dueg posla koji raunar radi samostalno, b- kod
interaktivnog posla nakon segmenta koji raunar radi samostalno)
15. Za isti posao koji KI treba da omogui postoji vie realizacija. Kreativnost je i umetnost
proceniti koja varijanta najvie odgovara buduem korisniku. (Primer: da li brisanje podatka
raditi sa tasterom: Brii, sa tasterom sa ikonicom "kanta za otpatke", ili da se vri prevlaenje:
"drag and drop" sistem: korisnik uzme podatak i prevue ga u kantu za otpatke). Pri izboru
varijante rukovodimo se sledeim faktorima korisnika: navike u radu (vrsta posla) i ivotu
(lokalni obiaji), znanje (struno i o raunarima), metodologija rada (standardna i lokalna),
zamor (da je lako za korienje, to manje napora da bi se neki efekat sproveo) jezik
komunikacije programa sa korisnikom.
TIPINI PROCESI U (AOP I UPRAVLJAKIM) INFORMACIONIM SISTEMIMA
- auriranje podataka (tekstualnih, slika) ->AOP

- periodina statistika (sumiranje, procenti i sl.) -> AOP
- periodino arhiviranje podataka -> AOP
- periodino generisanje izve{taja -> AOP
- pregled podataka radi donoenja odluka (statistika, izvetaja, na ekranu -> dijagrami,
tabelarno, upiti, pretraivanje) -> UPRAVLJAKI
FORMAT PODATAKA U INFORMACIONIM SISTEMIMA

- alfanumeriki
- grafiki (mape, dijagrami, slike)
- zvuk
5.4. OSNOVNE FUNKCIJE U SOFTVERU INFORMACIONIH SISTEMA

1 - Prijavljivanje korisnika
2 - Auriranje sadraja neke tabele ili pogleda (1 tabela ili vie, 1:M unos) kao realizacija unosa
ifarnika ili pokrivanje procesa - dogadjaja realnog sistema
3 - Prikaz alfanumerikih podataka: tabelarno (Data Grid)
4 - Prikaz/unos slika (ukoliko ih ima)
5 - Arhiviranje podataka i manipulaciju sa fajlovima
6 - Pretraivanje i prikaz podataka (sort, filter, upiti: jednostavni po kljunoj rei ili deo rei, po
svim obelejima ili sloeni koji ukljuuju vie kriterijuma)
7 - Izvetavanje (izvetaji) i unos veeg teksta
8 - Prikaz statistikih i pojedinanih podataka dijagramima (Chart)
9 - Rad sa mapama
NAJEE PRATEE OPCIJE U SOFTVERU
1. upozorenja, obavetenja
2. "help" sistem za pomo
3 "about" programa : autori, godina proizvodnje, registracija i sl.
4. forma za podeavanje rada programa options
5.5. ELEMENTI KORISNIKOG INTERFEJSA

U VB elementi korisnikog interfejsa se nazivaju kontrole (control).
U grafikom okruenju, osnovni elementi korisnikog interfejsa su (terminologija VB-a):
- radna povrina (desktop), horizontalni meni, vertikalni meni, statusna linija, prozor, pozicione
trake (scroll bar), softverski tasteri (komandni (Command), opcijski (Option), za podeavanje
(Check, Toggle...)), Okviri (za poruke - Message box, za reakciju - Message box, za unos - Input
box, sa istorijom interakcije - history box, za spiskove - list box, za promenu direktorijuma -
directory tree), Text box (linija unosa teksta), Combo box, List box, Grid, Tab Strip, Tree View,
Timer, Picture box... i drugi. Generalno, elementi se mogu podeliti na kontejnere (oni koji
sadre druge) i jednostavne elemente.
U radu posebno sa bazama podataka, najee se koriste sledei elementi korisnikog interfejsa
(VB):
- element za pristup bazi podataka (Data control),
- Combo Box sa listom koja ita podatke iz baze podataka, a pri izboru upisuje u bazu
podataka (DBCombo),
- List Box sa vezom sa bazom podataka (DBList),
- DBgrid (za tabelarno prikazivanje podataka iz baze podataka),
- Crystal Report kontrola (za omoguavanje veze sa izvetajima).
PODEAVANJA VEZANA ZA BILO KOJU FORMU
- font, pokaziva mia

- pozicija forme
- kreiranje, uitavanje i iitavanje formi
- aktiviranje i osveavanje formi
- postavljanje osobina na inicajlne (default) vrednosti nakon zavretka rada sa nekom formom
- redosled aktiviranja elemenata KI (Tab, Enter, strelica na dole)
- vizuelno predstavljanje aktivnog elementa (promena boje kada je u fokusu)
- vidljivost/nevidljivost pojedinih elemenata KI (npr. tastera)
TIPOVI FORMI PREMA MEUZAVISNOSTI PONAANJA

1. MDI (multiple document interface) i MDI-child forme

2. Modalne forme
3. Obine SDI (single document interface)
ZNAENJA FORMI I ELEMENTI REALIZACIJE
1. Forma za podeavanje rada programa

Slui: za podeavanje ponaanja programa (font, pojavljivanje poruka, statusna linija i sl.).
Elementi: TabStrip, PictureBox, Frame, ChechBox, OptionButton, Komandni tasteri.
2. About forma
Slui: za obavetavanje o autoru i sl.
Sadri podatke:
1. Naziv aplikacije
2. Verzija
3. Platforma (namena)-for 32bit Windows Development
4. Copyright
5. Licenced to & Serial Number
6. Upozorenje o zatienosti zakonima...
7. System info
Elementi: PictureBox, labele, kommandni taster, linija.
3. MDI forma
Slui: sadri druge forme, sadri horizontalni padajui meni aplikacije.
Elementi: meni, pozadinska slika.

Tehnike: Kreiranje MDI forme, a ostale su MDI child=true. Modalne i nemodalne forme je
neto drugo. Modalna forma znai da korisnik mora neto da uradi pre nego napusti tu formu, a
nemodalna da ne mora. Kreiranje menija (& ispred znaka znai alt+taj znak->shortcut, - tj.
minus je caption kada se eli odvojiti delove padajueg menija linijom. Isto vai i za komandne
tastere: Prvo slovo je veliko, ostala mala, ispred slova koje je shortcut (sa alt) se stavlja znak
& i ono automatski biva podvueno).
4. Forma za meni sa komandnim tasterima

Slui: alternativno je za padajue menije. Bolje je padajue menije koristiti jer se odmah vidi
struktura celog programa, a i svojevrstan je standard.
Elementi: komandni tasteri sa skraenicama
Tehnike: postavljanje fokusa, promena boje, grafiki tasteri, postavljanje skraenica na tastere
5. Upozorenja, obavetenja
Slui: za alarme da je neto pogreno uraeno, za obavetenja npr. o tampau i upozorenja
npr. da se naglasi da je neto takvo i takvo, ili da treba neto uraditi na neki nain.
Elementi: labela, komandni tasteri,(option button kod ekrana za kraj)
Tehnike: isticanje bojom, zvukom i blinkovanjem; javljaju se nakon to je izvrena neka akcija
ili pre neke akcije-> provera uslova i nakon uslova treba prikazati poruku; koristi se MSGBOX,
INPUTBOX ili obina forma.
6. Forma za prijavljivanje korisnika

Slui: za unos korisnikog imena i ifre, po kojoj se tome korisniku dodeljuju odreena prava
za korienje programa.
Elementi: labele, TextBox, komandni tasteri.
Tehnike: korienje niza labela (labela(0), labela(1)...), korienje globalnih promenjivih (na
nivou modula (forme)->Public, korienje api funkcije za oitavanje username, Korienje
Space$ funkcije za pravljenje praznog stringa od fiksnog broja karaktera,Len, Left$, SetFocus
na text box, Hide, unoenje ifre kao niz zvezdica (password char), Automatsko selektovanje
teksta (Textbox1.Selstart=0, Textbox1.SetLength=Len(Textbox1.text))
-> odakle se ita ifra: iz baze, pa se poredi sa bilokojim od korisnika u bazi, ili sa ifrom u .exe
(kodu), ili sa ifrom u registry, ili se smesti na disketu, pa samo dok je inicijalna disketa u drajvu
moe da se koristi program.
-> da li e postojati Cancel dugme zavisi od toga da li postoji neki skup aktivnosti koje se mogu
sprovoditi nad programom bezopasno.
7. Forma za auriranje sadraja neke tabele ili pogleda (1 tabela ili vie, 1:M unos)
Slui: za auriranje tabela iz baze, to znai unos (dodavanje novog sloga), brisanje
(postojeeg sloga) i izmena podataka (postojeeg sloga).
Elementi: labele, text box, Combo, DBCombo, List, DBList, Option, Check, Komandni tasteri
Tehnike:
- Pre svega, razlikuju se forme za auriranje matinih podataka i tzv. korisnike forme koje slue
osnovnoj svrsi informacionog sistema: za evidenciju rauna, prijemnice, otpremnice i sl. jer
korisnike forme koriste matine podatke u svojim DBCombovima.
-Za brisanje i izmenu prvo pronai traeni slog, pa ga zatim izmeniti/obrisati. (koristiti bookmark
ili ifru)
- Prilikom brisanja voditi rauna da li je kaskadno brisanje podeeno u bazi ili nije-da li postaviti
pitanje korisniku ili automatski izvriti aktivnost. U svakom sluaju, za sve akcije je potrebno da
se korisnik obavesti.
- Prilikom unosa i izmene ifre, voditi rauna da ne postoji ve slog sa istom ifrom u tabeli
(kontrola u kodu ili prepustiti da SUBP tu reaguje).
- Kontrolisati vrednosti polja (domen) ve pri unosu toga (svakog) polja, recimo pri naputanju
tog polja i prelasku na sledee ili u toku kucanja (unosa), a ne na kraju kada se potvruje unos
da se prijave sve greke!
- Pri kontroli kod neispravnog unosa ne sme da stane program ("pukne"), ve samo da se
obavesti korisnik o greci, postavi fokus na pogreno mesto (oboji drukije, alarmira zvukom!!!)
- Kod unosa novog sloga, nakon potvrde unosa treba da je poslednje uneti slog zapravo i onaj
koji se po potvrivanju vidi kao tekui. (koristiti Bookmark=Lastmodified)
- Zgodno je prebacivati se sa kontrole na kontrolu sa tab-om, a pri unosu sa ENTER, da
redosled bude u skladu sa redosledom unoenja, da bi se to bre unosilo, bez gledanja!!!
- Zgodno je da kontrola koja ima fokus bude drugaije obojena.
- Lepo je i korisno da se pri unoenju nove ifre matinog podatke ovaj upie automatski u text
box, sa mogunou izmene, a da to bude automatski prvi sledei nezauzeti broj (poslednji po
veliini +1 ili moe i manji, koji nije bio zauzet. To moe da bira korisnik, a ako ima takvih
nejasnih situacija, svakako da se obavesti).
- Potrebno je umesto text boxova na korisnikim tabelama (NE matinim podacima) koristiti
Combo ili DBCombo boxove gde korisnik bira ime, a ne unosi (i pamti) ifru koja se zapravo
unosi u korisniku tabelu.
- Potrebno je ukoliko, nedostaje neki podatak u kombo boxu, dodati ga u matinim podacima, a
zatim se vratiti na ovu formu i osveiti je da bi se ponovo napunila lista combo boxa i da bi se
ovaj novi podatak mogao iskoristiti.Zato je potrebno da su sve forme MDIchild prema nekoj MDI
koja objedinjuje celu aplikaciju. Na taj nain je mogue pozivati vie formi odjednom.
- Potrebno je podatke koji se odnose kao 1:M (zaglavlje dokumenta i stavke dokumenta) unositi
na jednoj formi. Pri tome treba omoguiti da se ova strana M vie puta unosi, bez unoenja
zaglavlja svaki put (jednom se unese, zadri na ekranu i podrazumeva se da se unos na strani
M odnosi na to zaglavlje.
1. direktno tabela baze vezana na tekst boxove(baza proverava ispravnost za svaki tekst box i
daje upozorenja-> prekida program sa radom): Text boxovi su vezani za Data kontrolu i
odgovarajue polje tabele
2. a) nije tabela vezana za tekst boxove, nego oni slue za unos vrednosti, a pritiskom na taster
"Potvrdi" se deava provera ispravnosti(poruke) i unos/izmena;
b) nije tabela vezana za tekst boxove, nego oni slue za unos vrednosti, ali se nakon svakog
unosa(svakog tastera) proverava da li je to polje ispravno uneto.
3. SQL upitom se aurira tabela baze (brie, dodaje, menja).
Tehnike dodavanja sloga, editovanje, osveavanje tabele, kretanje kroz tabelu (prvi, sledei,
zadnji), ponitavanje akcije dodavanja, izmene, brisanja (u zavisnosti od stanja u kojem se
nalazi forma), ispitivanje da li je prvi slog, poslednji, jedini, da li je prazna tabela, korienje
promenljive kao instance objekta forme (dim f as NEw frmDataGrid, gde je frmDataGrid zapravo
naziv forme, koja je univerzalna za tabelarni prikaz), korienje klasa i univerzalnih formi, a
prosleivanje samo podataka, korienje dogaaja kao to su data error, reposition,korienje
promenljive screen, promena mouse pointera:default i hourglass, korienje defaultnih
vrednosti (imenovanih konstanti-VBDefault), redni broj sloga kao apsolutna pozicija
(absoluteposition), kolekcija slogova: Recordset, korienje case strukture, Validacija nakon to
je korisnik izazvao neku akciju, a pre nego to se ona zaista izvrila (Validate), i nakon to se
izvrila (Reposition), korienje with ... end with strukture.
8. Forma za tabelarni prikaz podataka

Slui: za prikaz svih ili veine podataka iz neke tabele ili upita, sortirano/ili filterisano ili ba po
redosledu unosa.
Elementi: DBGrid, Combo za unos kolone po kojoj treba da je sortirano, Combo (polje, znak)
za unos kriterijuma za filtriranje (izdvajanje bitnih po nekom kriterijumu) i text box za unos
vrednosti za odreeno polje, komandni tasteri (za potvrdi i sl.), Combo za veze (and, or, not ...)
Tehnike: omoguiti sortiranje, filtriranje, osveavanje, history sa vraanjem, sloene

kriterijume za filter, Filter kao osobina recordseta (RS.filter=string_filtera, gde je string filtera
slino kao iz WHERE za SQL), bre radi SQL, princip da sve to se radi i menja moe i da se
vrati (zapamti u promenljivima, kolekcijama (listi, bazi), requery (ponovo puni pokretanjem
upita na kojem se zasniva), Sort kao osobina recordseta (uzima za vrednosti stringove),
korienje picture boxa ili frejma da bi se sa veim brojem kontrola koje su na njih unesene
zajedniki manipulisalo, korienje rei a ne slika za komandne tastere, relativno pozicioniranje
kontrola u odnosu na ekran, formu i sl. (Me.Height, Screen.Height...), dbgrid omoguava
brisanje/izmenu sloga, ali prvo se pita (Msgbox), Before Delete i cancel,pozivanje jednog
dogaaja automatski kodom iz nekog drugog dogaaja (CMD1_click, na poetku reda, bez call),
Sortiranje tabele klikom na dbgrid, na zaglavlje (sortira kada se primeni kod za headclick)->
ASC obian click, DESC kada je click+CTRL.
9. Forma za rad sa slikama

Slui: za unos slika, za pregled slika i sl.
Elementi: Picture Box, Image Control, text box, komandni tasteri
Tehnike: Picture Box nema, a Image Box ima skaliranje (proporcionalno smenjenje i uveanje
slike koja se uita). Unos slika se moe vriti skeniranjem, pri emu se dobije fajl koji se snima
negde. Slike su potrebne u nekim informacionim sistemima radi identifikacije korisnika,
muterija, dobavljaa, grafiki rezultati nekih testova (snimci u medicini ) i sl. Sliku treba vezati
za neke tekstualne podatke, pa se naziv fajla i putanja do slike memoriu u bazi (u nekoj tabeli,
uz ifru koja predstavlja vezu ka tekstualnim podacima) kao stringovi. Najbolje bi bilo sve
fajlove (dokumente, slike i sl.) vezane za jednu osobu, organizaciju i sl. stavljati u jedan
direktorijum. Zato bi bilo dobro da ove direktorijume pravi program, automatski sa pojavom
novog partnera mu otvara vlastiti direktorijum koji bi imao naziv slino kao i ifra tog partnera.
Ponekad je potrebno uveanje slike ili delova slike; zato je potrebno odmah pri skeniranju da se
slika uvelia i to pod visokom rezolucijom i takva snimi. Pogodno je koristiti MDI formu
kaopodlogu za uveliavanje (jer ima klizae).
10. Forma za arhiviranje podataka i manipulaciju sa fajlovima

Slui: za smetanje backup podataka, statistikih podataka, manipulaciju svim radnim fajlovima
Elementi: Drive list, DirList, File List
Tehnike: povezati ove kontrole u funkcionalnu celinu. Da bi se fajlovi koji su u vezi sa nekim
entitetom iz okruenja s njime povezali, treba da se smetaju uvek u isti direktorijum. Najbolje
bi bilo sve fajlove (dokumente, slike i sl.) vezane za jednu osobu, organizaciju i sl. stavljati u
jedan direktorijum. Zato bi bilo dobro da ove direktorijume pravi program, automatski sa
pojavom novog partnera mu otvara vlastiti direktorijum koji bi imao naziv slino kao i ifra tog
partnera.Ipak, ta veza treba da je upisana u bazi kao naziv direktorijuma i apsolutna putanja.
Svakako, pri svakom pokretanju programa treba proveriti da li su fajlovi koji su evidentirani u
bazi nazivom i putanjom zaista tamo, da ne bi "pukao" program. Ukoliko nisu, omoguiti
korisniku da ih pretrauje po medijima za memorisanje (diskete, hard disk, CD i sl.) iz vaeg
programa. Backup treba raditi periodino, u pravilnim periodima. Najbolje je vezati backup uz
izradu statistikih izvetaja.
11. Forma za pretraivanje i prikaz podataka

Slui: za pronalaenje eljenig podataka (pojedinanog ili grupa podataka).
Elementi: ZA UNOS KRITERIJUMA: combo, text box, list box, komandni taster, ZA PRIKAZ
GRUPE: dbgrid, ZA PRIKAZ POJEDINANIH PODATAKA: text boxovi, ZA SUMARNE PODATKE:
grafikoni, pie slice.
Tehnike: SQL, sort, filter, kljuna re ili deo rei, po svim obelejima.
12. Forma za izvetavanje (izvetaji) i unos veeg teksta

Slui: za prikaz i tampu izvetaja, i veeg teksta
Elementi: Crystal report, Rich text
Tehnike: Crystal report je kontrola koja je veza korisnikog interfejsa i *.rpt fajla, koji se
generie u okviru editora za izvetaje, a vezuje se za odreene tabele baze. Bitno je postii
relativnost putanje rpt fajla, kao i relativnost putanje rpt fajla prema fajlu baze. Potrebno je
kreirati najfrekventnije izvetaje, koji e se u realnim situacijama puniti realnim podacima iz
baze. Takoe je poeljno postii univerzalnost izvetaja, tako da se mogu koristiti i praviti
izvetaji po elji. Takoe, nekad je potrebno da se unosi tekst veeg obima. Zato nam slui Rich
text , pomou kojeg se moe unositi i snimati kao txt ili rtf fajl.
13. Forma za dijagrame

Slui: za prikaz vee koliine podataka iste vrste, za prikaz statistiki obraenih podataka.
Elementi: MSChart.
Tehnike: forma sa ovom kontrolom se moe upotrebljavati kao univerzalna forma. Takoe,
oblici koji se mogu dobiti su razliiti (dijagrami, pie slice i sl.).
14. Forma za upite

Slui: da se dobiju traeni podaci, po razliitim kriterijumima.
Elementi: DbGrid, DBCombo, DbList, TextBox i sl.
Tehnike: mogu se unositi upiti (loe), treba da se pamte najfrekventniji (za svaki poziv istog
upita da se pamti koliko puta je pokretan), ili da postoji spisak upita (i to je loe). Bolja
varijanta je da se napravi forma koja je korisniki orijentisana gde e biti mogue postavljati
uslove upita tako to se radi formiranja kriterrijuma pretrage izabere: polje iz cele baze (svih
tabela), znak, vrednost iz skupa svih unetih vrednosti za to polje, (ovaj postupak se moe
ponavljati, a izmeu tih ureenih trojki se moe stavljati bulov znak: and, or, not i slino) i
izabere se traeni podatak (podaci) koji se trai po tom kriterijumu. Rezultat bi bio u DBGridu:
kolone koje su izabrane i vrednosti (slogovi ili rezultati sloenog upita).
15. Help
Slui: za pomo o korienju programa, kao i obavetenje o trenutnom stanju programa
Elementi: Statusna linija, trake iznad prozora, tooltip svake kontrole, komandni taster sa
Msgbox-om, *.hlp fajl, DBlist box sa svim pojmovima iz tabele sa objanjenjima.
Tehnike: On-line help: statusna linija, trake iznad prozora, tooltip: u svakom trenutku da se
zna koja kontrola emu slui, u kom stanju je program, koji prozor je aktivan i emu slui. Off-
line help: komandni taster sa MSGBox-om, Hlp fajl, DBList box na posebnoj formi za help.
Najbolji off-line help je ako se napravi .hlp fajl (standardni Windows help fajl, koji u sebi sadri i
Word index-> listu nepoznatih pojmova, kao i procesno uputstvo u smislu: ta ako?). Da bismo
sa svakog ekrana mogli dobiti pomo, treba da imamo vezu sa delom .hlp fajla koji se na ba
taj ekran odnosi.
7. LITERATURA
[J] Jaukovi Mihajlo, Uvod u informacione sisteme, Tehnika knjiga, Beograd, 1992.
[LJV] Lazarevi Branislav, Jovanovi Vladan, Vukovi Milica, Projektovanje informacionih

sistema I deo, Nauna knjiga, Beograd, 1988.
[LN1] Lazarevi Branislav, Nekovi Sinia, Objektno orijentisani transformacioni razvoj

informacionih sistema, Skripte, Fakultet organizacionih nauka, Beograd, 1993.
[LN2] Lazarevi Branislav, Nekovi Sinia, Sistemsko teorijska kritika objektno

orijentisanih pristupa razvoju softvera, INFO TEH, Vrnjaka Banja, 1997, str. 89-95
[LN3] Lazarevi Branislav, Nekovi Sinia, Nove arhitekture i pristupi objektno orijentisanom
razvoju softvera, asopis INFO SCIENCE 2-3/99. str. 21-26
[MD] Malbaki Duan, Odabrana poglavlja Metoda programiranja, Tehniki fakultet Mihajlo
Pupin, Zrenjanin, 2001.
[MR] Marinkovi Rade, Razvojni koncept metodologije projektovanja informacionog sistema za

upravljanje proizvodnjom - Magistarski rad, Tehniki fakultet Mihajlo Pupin, Zrenjanin,
1998.
[MZ] Marjanovi Zoran, Aktivni sistemi baza podataka, SYMOPIS 1993, str. 103-106
[M] Mihajlovi Dragan, Informacioni sistemi, Univerzitet u Novom Sadu, Fakultet tehnikih
nauka, Novi Sad, 1993.
[ML] Mogin Pavle, Lukovi Ivan, Principi baza podataka, Univerzitet u Novom Sadu, Fakultet
tehnikih nauka, Novi Sad, 1996.
[MLG] Mogin Pavle, Lukovi Ivan, Govedarica Miro, Principi projektovanja baza podataka,
Univerzitet u Novom Sadu, Edicija Univerzitetski udbenik, 2000.
[UHW] Ullman Jeffrey, Garcia Molina Hector, Widom Jennifer, Database Systems: The
Complete Book, Department of Computer Science, Stanford University, Prentice Hall,
New Jersey, 2002.
[] erniek Itvan,Teorija sistema, Tehniki fakultet Mihajlo Pupin, Zrenjanin, 2000.
[IP] asopis IP, NIP TV Novosti, Beograd, broj. 6-10, 1994-1995.
ISO 9000 - 3 Smernice za primenu ISO 9001 u razvoju, isporuci i odravanju softvera, 1993.

Projektovanje Informacionih Sistema - Odabrana Poglavlja

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Projektovanje Informacionih Sistema - Odabrana Poglavlja

Uploaded by

Copyright:

Available Formats

UNIVERZITET U NOVOM SADU

TEHNIKI FAKULTET "MIHAJLO PUPIN"

Doc. dr Biljana Radulovi

Zrenjanin, jun 2002.

2. UPRAVLJANJE PROJEKTIMA - PROJECT MANAGEMENT

3. STRUKTURNA SISTEM ANALIZA

4. PROJEKTOVANJE BAZE PODATAKA

4.1. MODEL PODATAKA

1. UVOD U INFORMACIONE SISTEME

1.1. DEFINICIJE OSNOVNIH POJMOVA

INTERAKCIJA SISTEMA I OKRUENJA ostvaruje se dejstvom okruenja na sistem i

IZLAZ SISTEMA uticaj sistema na okruenje, dejstvo je od sistema ka okruenju.

STANJE SISTEMA skup vrednosti obeleja sistema u odreenom trenutku.

PONAANJE (celine) niz vremenski uzastopnih stanja sistema. Ponaanje je ono to se

FUNKCIJE su ishodi u deavanju. One su odreene: dinamikom, ishodom deavanja,

PROCES posredno/neposredno opisuju ponaanje sistema, odrava dinamiku i funkcionisanje

TROKOVI angaovanje resursa za odreeno ponaanje ili promenu ponaanja sistema.

RESURSI SISTEMA pokretaka sila, osnovni inilac i preduslov za pokretanje i izvoenje

RAVNOTENI PROSTOR skup stanja koja se cikliki ponavljaju.

OSNOVNE POSTAVKE TEORIJE SISTEMA:

KIBERNETIKA nauka o upravljanju sloenim dinamikim sistemima.

Uoptavanje (slinost, diferencijacija, uporeivanje)

PONAANJE promena (u vremenu) stanja sistema, neprekinuti niz stanja

STRUKTURA elementi, odnosi (relacije), ureenost i organizovanost

APSTRAKCIJA misaoni postupak, izdvajanje bitnog u skladu sa odreenim kriterijumima i

MODEL pojednostavljena predstava o relevantnim karakteristikama sistema (svaka naa

Informacioni sistem je model realnog sistema u kojem deluje.

IS je sistem u kojem se veze izmeu objekata (elemenata) i veze sistema sa

OKRUENJE (sve to se nalazi izvan granica sistema):

KLASIFIKACIJA SISTEMA po Kenet Boulding-u:

1.2. OSNOVNI ZAKONI OPTE TEORIJE SISTEMA

1) ZAKON ZAVISNOSTI TJ. RELATIVNE NEZAVISNOSTI

Svaki sistem je u statikoj ili dinamikoj zavisnosti od drugih sistema. U sluaju da je

NEZASVISNI SISTEMI sa jednog aspekta, sa drugog ne

2) ZAKON RAZLIKE (relativne jednakosti)

Razlike meu sistemima su apsolutne, jednakost je relativna.

3) ZAKON PROMENE (relativna stalnost)

- Stalnost je relativna, promena je apsolutna.

- Stalnost zahteva odravanje.

4) ZAKON NEPREKIDNIH PROMENA

1.3. KLASIFIKACIJE SISTEMA

PREMA NAINU NASTANKA: prirodni, vetaki

PREMA POJAVNOM OBLIKU: realni, apstraktni

PREMA STEPENU SLOENOSTI: prosti, sloeni, veoma sloeni, kompleksni

PREMA POVEZANOSTI SA OKRUENJEM: otvoreni, zatvoreni,poluzatvoreni

PREMA KOMPLEKSNOSTI PONAANJA: samoreguliui (kompenzacija), adaptivni

1.4. SISTEMSKI MODEL

1.5. METODA MODELOVANJA

1.6. MODEL UPRAVLJANJA KOMPLEKSNIM SISTEMIMA

METOD CRNE KUTIJE - za istraivanje sistema

1.7. SISTEMSKA ANALIZA

Postavlja se pitanje "ta je sistemska analiza?"

Definicija analize - misaoni postupak kojim se sistem rastavlja na elemente sa ciljem

Spoj sistemska analiza je misaoni postupak analize sistema sa sledeim koracima:

U informacionim sistemima i teoriji sistema u postupku analize sistema posmatramo objekte i

2. UPRAVLJANJE PROJEKTIMA (Project Management)

U informacionim sistemima razlikujemo 2 nivoa projektovanja: LOGIKO i FIZIKO. Idejni i

IZVOAKI projekat Bavi se implementacijom (primenom, uvoenjem i korienjem) novog

objektno relacione baze podataka). [LN1]

Postavlja se pitanje: ta je informacioni sistem?

PODATAK kodirana, zapisana injenica (zapis je niz simbola) o dogaaju, o nekoj

STATIKU opisana je bazom podataka i modelom podataka. Jednoj logikoj strukturi

2.2. PROBLEMI U PROJEKTOVANJU INFORMACIONIH SISTEMA

zatim sledi deo po deo (definiu se podsistemi za koje se odreuju prioriteti