Professional Documents
Culture Documents
RIS I BP PDF
RIS I BP PDF
2 alempije@beotel.yu
Uvod
U vreme ekspanzije zahteva za što raznovrsnijim podacima sve je potrebnije i dobijanje
kvalitetnih informacija. Ovu potrebu treba da zadovolji razvoj informacionih sistema i
odgovarajućih sistema za upravljanje podacima (SUBP). Oni bi trebalo da integrišu
teoretske postavke vezane za korišćenje metodologije odozgo nadole (Top-Down) sa
implementacijom koja se izvodi metodologijom odozdo nagore (Bottom-Up).
Metodologija odozgo nadole se izvodi sa stanovišta rukovodećeg menadžmenta preduzeća,
korišćenjem metode intervjua. Na taj način se definišu ciljevi, procesi, resursi i dr. Obrnutim
putem, metodologijama odozdo nagore (analizom dokumenata) izvodi se generisanje baza
podataka. Širinu u pristupu daje metodologija odozgo nadole, a preciznost metodologija
odozdo nagore.
Za uspešno izvodenje aktivnosti vezanih za razvoj informacionih sistema potrebno je na
samom početku raskrstiti sa zabludama, definisati ograničenja i dati odgovarajuće
pretpostavke.
Najčešće zablude su:
!" da neko drugi može obaviti ovaj posao, po principu "ključ u ruke";
!" da se naručivanjem projekta može brže završiti posao;
!" da se preslikavanjem postojećih aplikacija u novo hardversko i softversko okruženje
može doći do novog sistema.
Kada se raskrsti sa zabludama, na sledećem koraku javljaju se ograničenja koja, pak, mogu
sa svoje strane usporiti razvoj informacionih sistema, imajući u vidu:
!" stepen organizovanosti sistema koji se analizira i koji zavisi od razrađenosti standardnih
dokumenta i procedura za njihovu obradu i distribuiranje;
!" ograničenja vezana za korisnike, koja su u vezi sa odbojnošću prema ideji uvođenja
novog sistema;
!" znanje projektnog tima, njihovu metodologiju rada i iskustvo za slične sisteme koji mogu
biti od presudnog značaja.
Imajući u vidu ograničenja, treba ispuniti tri osnovne pretpostavke :
!" Prva pretpostavka je vezana za jedinstven sistem označavanja i podrazumeva
definisanje najčešće tzv. paralelnog sistema označavanja. Paralelnim sistemom
označavanja se definišu: jedinstven identifikacioni broj, standardizovan naziv i
odgovarajući klasifikacioni broj. Jedinstven identifikacioni broj ili IDENT BROJ je
neimenovani redni broj (najčešće od šest cifara). Naziv je definisan po standardu JUS
A.A0.006 i ima tačno propisanu strukturu. Klasifikacioni broj definiše grupe PREDMETA
POSLOVANJA i svako mesto ima odgovarajuće značenje (do pet cifara).
!" Druga pretpostavka odnosi se na jedinstvenost modela procesa i podataka, gde se
podrazumeva, obično, primena jedinstvene metodologije vezane za projektovanje
informacionog sistema korišćenjem CASE alata (Computer Aidid Software Engineering).
Korišćenje metodologije projektovanja informacionog sistema IDEF0 i IDEF1X, tj. CASE
alata BPwin i Erwin predmet je razmatranja ove knjige.
alempije@beotel.yu 3
!" Treća pretpostavka je vezana za jedinstvenost sistema za upravljanje bazama podataka
(SUBP). U ovoj knjizi je usvojen, odnosno biće razmatran SUBP MS ACCESS.
Prevazilaženjem zabluda i ograničenja, uz poštovanje definisanih pretpostavki, mogućan je
razvoj informacionog sistema koji će omogućiti definisanje nove strategije vođenja
preduzeća. Ta strategija obezbeđuje integraciju svih informacionih tokova u preduzeću, a na
osnovu toga i upravljanje procesima.
4 alempije@beotel.yu
Modeliranje kao osnova razvoja
informacionog sistema
Razvojem informacionog sistema (IS) treba definisati što objektivniju sliku realnog sveta,
njegovih bivših i sadašnjih stanja, kao podlogu za procenu budućeg ponašanja i naravno,
podlogu za dalji razvoj i primenu informatičke tehnologije.
Za opis rada poslovnog sistema veliki je problem to što ne mogu da se koriste prirodni
jezici, zbog mnogih jezičkih dvosmislenosti. S druge strane, precizan opis preko formalnih
jezika je nerazumljiv za većinu ljudi.
Stoga je potrebna tehnika koja će organizovati prirodne jezike na taj način da eliminiše
dvosmislenost i omogući efikasnu komunikaciju i razumevanje. Pokazalo se da je postupak
modeliranja jedna od najefektivnijih tehnika za razumevanje i jednoznačnu komunikaciju
između projektanata i korisnika.
U procesu modeliranja, eliminišu se detalji, čime se umanjuje vidljiva kompleksnost sistema
koji se proučava. Grafičke prezentacije (uglavnom pravougaonici i linije) koriste se da bi
obezbedile da većina ljudi razmišlja o procesu modeliranja kao o slikovitoj prezentaciji
(jedna slika zamenjuje 1000 reči). Pored grafičkog prikaza, potrebno je dati i precizne
definicije predmeta koji se pojavljuju u modelu, kao i propratni tekst, koji je kritičan prema
modelu koji ima svoju ulogu, kao sredstvo komunikacije.
Ovakav pristup nametnuo je potrebu za apstrakcijom, kojom se izvodi kontrolisano
isključivanje detalja, tj. izvlače se zajedničke karakteristike u opisivanju nekog sistema.
Tako je na višim nivoima apstrakcije sistem opisan jasnije, a na nižim detaljnije.
S druge strane, još uvek u velikim firmama postoje hardverske konfiguracije gde je
korisnički softver razvijen, obično, u jeziku treće generacije (najčešće COBOL), bez
odgovarajuće prateće dokumentacije, mada preduzeća žele da pređu na relativno jeftin i
moćan kompjuterski sistem, obično je to mreža PC, definisana po principima klijent/server
arhitekture.
S obzirom na to, modeliranje treba da:
!" bude "jezik" za komunikaciju između korisnika i analitičara i
!" omogući preciznu i formalizovanu "specifikaciju zahteva".
Treba, dakle, još jednom posebno istaći postupak modeliranja realnog sistema, koji zavisi
od sposobnosti, znanja i iskustva projektnog tima, jer se ne mogu dati stroga formalna
pravila modeliranja koja bi vodila do jedinstvenog modela složenog realnog sistema, bez
obzira na to ko vrši modeliranje. Mogu se dati samo opšte metodološke preporuke, opšti
metodološki pristupi, kao pomoć u tom složenom poslu.
alempije@beotel.yu 5
Standardi
kao podrška modeliranju
Postupak razvoja informacionih sistema opisan u ovoj knjizi ima za osnovu standarde IDEF0
i IDEF1X, koji podržavaju modeliranje. Istorijski gledano, tokom 60-ih i 70-ih godina
Douglas T. Ross je razvio tehniku modeliranja poznatu kao SADT (Structured Analysis &
Design Technique). Prihvatajući SADT tehniku, avijacija SAD razvila je SADT kao deo ICAM
(Integrated Computer Aided Manufacturing) programa tokom kasnih 70-ih, koji je dobilo
naziv IDEF tehnika (Integation DEFinition). Cilj ICAM programa je bio da se poboljša
proizvodna produktivnost primenjivanjem kompjuterske tehnologije. Učesnici u izgradnji
ICAM programa su uvideli sve prednosti korišćenja IDEF tehnike, jer tekstualni opis ne
predstavlja efikasan način za dokumentovanje procesa i podataka.
U ranim 90-im, IDEF Users Group, u kooperaciji sa National Institutes for Standards and
Technology (NIST), preduzela je određene postupke za stvaranje standarda IDEF0 za
funkcionalno modeliranje i IDEF1X (eXtend), kao tehniku za informaciono modeliranje
(semantičko modeliranje podataka), publikujući ih 1993. godine (U.S. Government
standards documents). Ovi standardi su pod pokroviteljstvom Institute of Electrical and
Electronics Engineers (IEEE), a prihvatila ih je i International Organization of Standards
(ISO).
Cilj modeliranja je da se razviju tehnologije koje će omogućiti logičku i fizičku integraciju
mreža hardverski i softverski veoma različitih konfiguracija. Tehnika IDEF modeliranja je
prihvaćena kao osnova za sprovođenje postupka reinženjeringa poslovnih procesa.
Imajući u vidu sve ove činjenice, funkcionalno modeliranje IDEF0 omogućuje:
!" izvršenje funkcionalne dekompozicije i dizajna na svim nivoima, za sistem sastavljen od
ljudi, mašina, materijala, računara i informacija;
!" stvaranje dokumentacije, paralelno sa reinženjeringom poslovnih procesa;
!" bolju komunikaciju između projektnog tima, korisnika i menadžera;
!" diskusiju u projektnom timu da bi se postiglo međusobno razumevanje;
!" upravljanje velikim i složenim projektima;
!" obezbeđenje elemenata potrebnih za informaciono modeliranje (IDEF1X metodologija).
Softverska realizacija IDEF0 standarda je BPwin (Bussines Process windows) firme
LogicWorks (2) koji se koristi u ovoj knjizi.
Drugi standard koji je IDEF Users Group definisala je IDEF1X tehnika za informaciono
modeliranje. Informaciono modeliranje (IDEF1X) predstavlja apstraktno viđenje realnog
sistema, tj. to je pojednostavljeno predstavljanje realnog sistema preko skupa objekata
(entiteta), veza između objekata i atributa objekata. Informaciono modeliranje je pojam koji
je definisan u okviru IDEF1X metodologije i definiše odgovarajući model podataka.
Zapravo, IDEF1X je semantički bogat modelar podataka treće generacije koji je realizovan u
okviru softvera ERwin (Entity Relationships for windows) CASE alata (3). ERwin CASE alat
omogućuje generisanje u neki od sistema za upravljanje bazama podataka (SUBP). Mora se
naglasiti pojam generisanje, a ne programiranje, jer ERwin omogućuje da se direktno
kreiraju tabele, veze, atributi i sva ograničenja koja su se nekada programirala.
6 alempije@beotel.yu
Postupak
razvoja informacionog sistema
RAZVOJ
INFORMACIONOG
SISTEMA
0
alempije@beotel.yu 7
Podaktivnost "1.2. Definisanje zahteva korisnika" treba da omogući da se analizom
dokumenata i sprovođenjem intervjua može identifikovati okvir reinženjeringa
poslovnih procesa. Potrebno je pronaći i dobro osmotriti nepotpune (prekinute,
isprekidane), neperspektivne procese koji guše ostvarivanje planiranih (željenih) rezultata.
Ključ "leži" u odgovoru na pitanje: "Šta treba promeniti?". Drugim rečima, u ovoj fazi se
proučavaju i procenjuju postojeći procesi, analiziraju se rezultati koje daje proces sada i
kakvi se rezultati mogu očekivati u budućnosti. Dakle, snimkom trenutnih procesa
omogućuje da se uoče uska grla (gde se nalaze) i problematične tačke.
Takođe, u ovoj aktivnosti treba predvideti i alternativne prilaze. Kada se definiše problem,
timovi koji sprovode reinženjering ističu novi strateški pravac za realizaciju procesa i
pridružena merila, a ujedno vrše i procenu novih poslovnih alternativa. Dakle, naročita
pažnja se obraća na to da članovi tima treba da razumeju proces, tj . da imaju razjašnjene
odgovore na pitanja šta se želi postići, zašto je potreban redizajn i kako treba da izgleda
proces u budućnosti.
Funkcionalno modeliranje zahteva i odgovarajuće tehničke preduslove koji se definišu
kroz odgovarajući hardver i softver, kadrovske potrebe i dinamiku realizacije, što treba
definisati u okviru podaktivnosti "1.3. Tehnički preduslovi". Rezultat ove faze rada je
"studija " ili "idejni projekat" kao dokument za aktivnost "2. Informaciono modeliranje".
Aktivnost "2. Informaciono modeliranje" je ključni momenat gde do izražaja dolaze
sposobnost i znanje visokostručnog kadra iz oblasti menadžmenta i informatike. U ovoj fazi
poželjno je angažovanje i spoljnih eksperata.
Ova aktivnost se definiše kroz sledeće četiri podaktivnosti:
!" Aktivnost 2.1. Definisanje detaljnih zahteva,
!" Aktivnost 2.2. Kreiranje ER modela,
!" Aktivnost 2.3. Kreiranje atributa i
!" Aktivnost 2.4. Definisanje poslovnih pravila.
U okviru aktivnosti "2.1. Definisanje detaljnih zahteva" definišu se procesi redizajniranja. To
zavisi od kriterijuma važnosti procesa i njene narušenosti, kao i od mogućnosti sprovođenja
izmena. U ovoj fazi treba utvrditi koja stara pravila ostaju i koji se novi procesi pojavljuju,
zatim izvršiti spajanje odgovarajućih operacija ili eliminisati nepotrebne i utvrditi logičan
redosled koraka u procesu. Kao rezultat ovog rada treba da bude definisano detaljno stablo
aktivnosti sa odgovarajućim detaljnim dekompozicionim dijagramima (po IDEF0
metodologiji) i verifikacijom top-menadžmenta preduzeća.
Aktivnost "2.2. Kreiranje ER modela", korišćenjem IDEF1X metodologije, predstavlja
kvalitetno novi skok, jer treba da bude kreacija projektanata informacionog sistema. Do
ovog trenutka, korišćenjem IDEF0 metodologije, opisivana je dinamika rada, što je prisutno
kao iskustvo i tradicija u svakom preduzeću i što je definisano kroz aktivnost
"1.Funkcionalno modeliranje".
Ova aktivnost otvara "crnu kutiju", koja je budućim korisnicima uvek bila nepoznata, jer
nisu mogli da prate razmišljanja projektanata informacionog sistema. Prvi put korisnici
uzimaju aktivno učešće i u ovom delu i prvi put projektanti informacionog sistema crtaju
ono što predstavlja njihovo iskustvo i saznanje o poslovanju konkretnog preduzeća i što su
oni osmislili u svojoj glavi.
Kroz identifikaciju entiteta, odnosno kroz definisanje objekata od interesa za posmatranje i
definisanje veza definiše se ER model, postupkom odozgo nadole, tj. intervjuom sa budućim
korisnicima.
Sledeća aktivnost "2.3. Kreiranje atributa" treba da da opis osobina u prethodno definisanim
entitetima. Osobine entiteta se definišu kroz identifikaciju atributa za svaki entitet,
definisanje odgovarajućih ključeva i sprovođenja postupka normalizacije. Ova aktivnost se
izvodi postupkom odozdo nagore, tj. analizom dokumenata.
Aktivnost "2.4. Definisanje poslovnih pravila" predstavlja sintezu prethodne dve aktivnosti i
treba da definiše poslovna ograničenja i pravila ponašanja.
8 alempije@beotel.yu
Treća aktivnost: "3. Aplikativno modeliranje" posmatra se sa stanovišta izabranog sistema
za upravljanje bazama podataka (SUBP).
Ova aktivnost se posmatra kroz sledeće tri podaktivnosti:
!" Aktivnost 3.1. Definisanje fizičkog dizajna,
!" Aktivnost 3.2. Generisanje šeme baze podataka,
!" Aktivnost 3.3. Izrada aplikacije.
Aktivnost "3.1. Definisanje fizičkog dizajna" razmatra problematiku vezanu za izgradnju
sistema za upravljanje bazama podataka (SUBP).
Aktivnost "3.2. Generisanje šeme baze podataka" definiše se za izabranu ciljnu platformu,
gde se definišu fizičke tabele, kolone i relacije.
Aktivnošću "3.3. Izrada aplikacije" treba da se realizuje korisnički pogled na podatke, tj. da
se definišu meniji, forme, upiti i izveštaji.
I na kraju, aktivnost "4. Implementacija" omogućuje izvođenje promena vezanih za način
rukovođenja i primene informacionih tehnologija.
Ova aktivnost se posmatra kroz sledeće tri podaktivnosti:
!" Aktivnost 4.1. Uvođenje,
!" Aktivnost 4.2. Testiranje,
!" Aktivnost 4.3. Održavanje.
Aktivnost "4.1. Uvođenje" treba da da ocenu urađene korisničke aplikacije, omogući izmene
u toku uvođenja, izradi uputstva za korisnike i obuči same korisnike.
Aktivnost "4.2. Testiranje" treba da omogući testiranje sprovedenih aktivnosti u okviru
postavljenog SUBP gde se ocenjuju performanse tog sistema.
Aktivnost "4.3. Održavanje" se izvodi kad se pređe u fazu eksploatacije novopostavljenog
sistema. Ovde se drastično pokazuju sve manjkavosti i neregularnosti vezane za sprovedeni
reinženjering poslovnih procesa i definišu odgovarajuće korektivne akcije.
Ono što omogućuje fleksibilno izvođenje svih aktivnosti prikazanih na slici 1.1. i što
zaokružuje ceo ovaj posao je CASE alat, kojim se omogućuju automatsko registrovanje svih
izmena i ažurno održavanje projektne dokumentacije.
alempije@beotel.yu 9
Aktivnost
1. Funkcionalno
modeliranje
10 alempije@beotel.yu
Aktivnost "1. Funkcionalno modeliranje" omogućuje dekomponovanje poslovnih funkcija i
planiranje potrebnih resursa za realizaciju funkcija. Funkcionalno modeliranje je vezano za
korišćenje IDEF0 tehnike. IDEF0 je tehnika modeliranja aktivnosti baziranih na kombinaciji
grafike i teksta, koji su predstavljeni na organizovan i sistematičan način da bi se povećala
razumljivost, koja podržava analizu, obezbeđuje logiku za potencijalne izmene, specificira
zahteve, ili, rečeno na drugi način, podržava analizu sistema po nivoima i integriše
aktivnosti.
IDEF0 funkcionalni model se sastoji od hijerarhijskog niza dijagrama koji postepeno
prikazuju sve više detalja o funkcijama i njihovoj međuvezi (interface) sa ostalim delovima
sistema. IDEF0 modeliranje omogućuje analizu osobina određenog poslovnog procesa radi
njegovog maksimalnog unapređenja.
Razlozi koji su motivisali nastanak IDEF0 funkcionalnog modeliranja su:
Prvo, služi kao dokumentacija i uputstvo za opis kompleksnih poslovnih procesa. Poznata je
činjenica da što je dokumentacija veća - to se manje čita. Tačnije, dokument od jedne ili
dve strane sa grafičkim prikazom biće najverovatnije pregledan. Dokument od 30 strana
ima sve izglede da mesecima ne bude pročitan.
Drugo, omogućava brze organizacione promene, jer model procesa dokumentuje važne
aktivnosti i omogućava uvid u kritične aktivnosti koje treba izvesti sa odgovarajućim
resusima, što je bitan element u održavanju reinženjeringom definisanih poslovnih procesa.
Treće, što je i najvažnije, koristi kao prototipski pristup funkcionalnom modeliranju gde se
na brz i jednostavan način proveravaju alternativne ideje. Mnogo je jednostavnije i jeftinije
nacrtati model i proveriti ga na "papiru", nego izvršiti reorganizaciju sektora. To je veoma
bitna osobina, jer brzi razvoj informacionih tehnologija uslovljava potrebu za
reinženjeringom poslovnih procesa.
Na slici 2.1. prikazana je aktivnost "1. Funkcionalno modeliranje" kojom se definišu tri
podređene aktivnosti:
!" Aktivnost 1.1. Funkcionalna dekompozicija,
!" Aktivnost 1.2. Definisanje zahteva korisnika,
!" Aktivnost 1.3. Tehnički preduslovi.
FUNKCIONALNO
MODELIRANJE
1
DEFINISANJE
FUNKCIONALNA TEHNI^KI
ZAHTEVA
DEKOMPOZICIJA PREDUSLOVI
KORISNIKA
1.1 1.2 1.3
alempije@beotel.yu 11
Aktivnost
1.1. Funkcionalna dekompozicija
Aktivnost
1.1.1. Definisanje granica sistema
Aktivnost "1.1.1. Definisanje granica sistema" je vezana za nabrajanje objekata koji će u
sledećem koraku biti po hijerarhiji povezani u stablo aktivnosti.
U okviru utvrđivanja granica sistema treba jasno definisati ciljeve koji moraju da sadrže
sledeće elemente:
!" zašto se proces modelira;
!" šta će proces da prikaže;
!" šta će korisnik modela napraviti sa njim;
!" čemu služi model.
Odgovori na ova pitanja treba da pomognu u fokusiranju postavljene problematike. Sledeća
pitanja na koja treba dati odgovor su:
!" koji su zadaci na datom radnom mestu;
!" koji je redosled izvođenja koraka;
!" kako se izvodi kontrola;
!" koji se resursi koriste.
Dakle, treba identifikovati zadatke svakog zaposlenog i shvatiti odnose između zadataka. Za
izvođenje ovih aktivnosti koristi se grafički jezik IDEF0. IDEF0 tehnika je svojevrsan grafički
jezik koji omogućuje komunikaciju, razumljivu svim učesnicima u postupku reinženjeringa
poslovnih procesa.
Da bi se realizovale naredne aktivnosti, u daljem tekstu detaljno će biti obrazložena
struktura grafičkog jezika IDEF0.
12 alempije@beotel.yu
Struktura grafičkog jezika IDEF0
Grafički jezik IDEF0 opisuje metodu funkcionalne dekompozicije preko skupa dijagrama, od
kojih svaki predstavlja ograničenu količinu detalja definisanih odgovarajućom sintaksom i
semantikom. Dijagrami su međusobno povezani tako da opisuju sistem, hijerarhijski, sa
vrha naniže. Dijagrami se sastoje od pravougaonika koji predstavljaju neki deo celine.
Povezani su međusobno usmerenim linijama koje predstavljaju veze između delova.
Postoje tri vrste IDEF0 prikaza: grafički, tekstualni i rečnik (glossary). Grafički prikaz
definiše funkcije i veze funkcija preko pravougaonika i strelica i odgovarajuće sintakse i
semantike. Tekst i rečnik pružaju dodatne informacije i podržavaju grafičke dijagrame.
Sintaksu grafičkog jezika IDEF0 čine pravougaonici (boxes), strelice (arrows) i pravila
(rules).
Pravougaonik
Pravougaonici predstavljaju aktivnosti, definisane kao funkcije, procesi i transformacije
(slika 2.2). Svaki pravougaonik ima naziv i broj u okviru granica pravougaonika. Za naziv
aktivnosti se koristi aktivan glagol ili glagolska fraza koja opisuje funkciju. Broj se koristi da
bi bio prepoznat predmet opisa pravougaonika u pridruženom tekstu.
NAZIV
AKTIVNOSTI
1
Slika 2.2. Sintaksa pravougaonika (Box)
alempije@beotel.yu 13
Strelice (Arrows)
Strelica se sastoji od jedne ili više linija, sa vrhom strelice na jednom kraju. Strelice mogu
biti pravolinijske ili savijene pod uglom od 90 stepeni i mogu se račvati ili spajati (slika
2.3).
Pravolinijske Strelica Račvanje Spajanje
strelice zakrenuta za 90 strelica strelica
stepeni
90o
Strelice predstavljaju podatke ili objekte vezane za aktivnosti. One ne znače samo tok ili
sekvencu, kao u tradicionalnom modelu dijagrama toka podataka, već prenose podatke ili
objekte vezane za posmatranu aktivnost.
Svaka strelica je definisana nazivom (imenicom). Za opis naziva strelice se definiše i
odgovarajući tekstualni opis.
U daljem tekstu detaljno će biti opisana semantika grafičkog jezika IDEF0.
Kontrola
Mehanizam Poziv
Slika 2.4. Pozicija strelica i uloge
Strelice sa leve strane pravougaonika se definišu kao ulazi (Input). Strelice koje ulaze u
pravougaonik odozgo se definišu kao kontrole (Control). Strelice koje izlaze iz
pravougaonika na desnoj strani predstavljaju izlaze (Output). Izlazi su podaci ili objekti,
odnosno proizvodi aktivnosti.
Dakle, elementi prikazani na slici 2.4. mogu se opisati rečenicom: "Ulazi se preko aktivnosti
transformišu u odgovarajući izlaz, dok kontrole specificiraju uslove pod kojima aktivnost
daje korektan izlaz".
14 alempije@beotel.yu
prema gore identifikuju značenje koje podržava izvršenje aktivnosti. Strelice mehanizma
koje su okrenute nadole definišu se kao strelice poziva (Call arrows).
Imajući u vidu englesku notaciju, dijagrami se zovu i ICAM dijagrami, jer je to skraćenica
od:
!" I - Input, nešto što se upotrebljava u aktivnosti;
!" C - Control, kontrole ili uslovi izvođenja aktivnosti;
!" O - Output, rezultat izvođenja aktivnosti;
!" M - Mehanizam, nešto što se koristi u aktivnosti ali se ne menja.
Imajući u vidu navedene postavke, postavlja se pitanje: koje resurse nose pojedini tipovi
strelica.
Ulazna (Input) strelica predstavlja materijal ili informaciju koja se koristi ili transformiše
radi definisanja izlaza (Output). Dozvoljava se mogućnost da određene aktivnosti ne moraju
imati ulazne strelice.
Kontrole su često u obliku pravila, politika, procedura, ili standarda. One utiču na aktivnost,
ali ne mogu da budu transformisane ili upotrebljene. U slučaju da je cilj aktivnosti da
promeni pravilo, politiku, proceduru ili standard, treba očekivati da će strelice koje sadrže tu
informaciju, u stvari, biti ulaz.
Izlazne (Output) strelice su materijali ili informacije stvorene aktivnošću. Svaka aktivnost
mora imati najmanje jednu izlaznu (Output) strelicu. Ne treba modelirati aktivnost koja ne
stvara izlaz.
Strelice mehanizama su izvori koji izvode aktivnosti, a sami se ne "troše". Mehanizmi mogu
biti ljudi, mašine i/ili oprema, tj. objekti koji obezbeđuju energiju potrebnu za izvođenje
aktivnosti. Po slobodnoj volji projektanta, strelice mehanizama mogu biti i izostavljene iz
aktivnosti.
Strelica poziv (Call) specifični je slučaj strelice mehanizma i ona označava da pozivajući
pravougaonik nema vlastiti detaljniji dijagram, već daje detaljniji prikaz izveden na nekom
drugom pravougaoniku u istom ili nekom drugom modelu. Više pozivajućih pravougaonika
mogu pozivati isti pravougaonik na nekom drugom ili istom modelu. Imenuju se brojem
dekompozicionog dijagrama, koji sadrži pozvani pravougaonik zajedno sa brojem pozivnog
pravougaonika.
Kao školski primer, koji treba da posluži za prikaz IDEF0 metoda modeliranja, definisan je
test-primer dokumenta "Karton isplata", prikazan na slici 2.5.
alempije@beotel.yu 15
Primer dokumenta "Karton isplata"
Na slici 2.5. prikazan je pojednostavljen primer ručnog dokumenta "Karton isplata" koji će
dalje služiti za opisivanje IDEF0 metodologije.
KARTON ISPLATA
SIFRA IME I PREZIME STRANI JEZIK ODELJENJE
RADNIKA
7359 Zoran Starcevic Engleski, Razvoj
Ruski
RADNO MESTO: Tehnolog Francuski
01 150,00 08.12.1996
02 450,00 20.02.1997
03 800,00 30.09.1997
Na primeru dokumenta "Karton isplata" biće prikazane sve aktivnosti definisane na slici 1.1.
Kontekstni dijagram
Prvi korak koji se preporučuje u aktivnosti "1.1.1. Utvrđivanje opštih zahteva" predstavlja
izrada kontekstnog dijagrama. Na taj se način definišu okviri IDEF0 modela.
Kontekstni dijagram je definisan jednim pravougaonikom koji predstavlja granicu modela
koji se proučava. U tom sistemu i van njega teku informacije preko strelica. Kontekstni
dijagram je najviši nivo apstrakcije koji se dekompozicionim dijagramima prevodi u niži nivo
apstrakcije. Na slici 2.6. prikazan je kontekstni dijagram pod imenom "Praćenje isplata" za
dokument "Karton isplata" sa slike 2.5.
Granice modela se definišu da bi se, pre svega, znalo gde treba stati sa modeliranjem.
Ovaj problem se može posmatrati sa aspekta:
!" širine (definisanja elemenata koji se posmatraju) i
16 alempije@beotel.yu
!" dubine (definisanja nivoa detaljnosti).
Širina modela je vezana za definisanje kontekstnog dijagrama (koji se u IDEF0 notaciji
označava sa A0) i prvog nivoa dekompozicije nosi oznaku A1. U okviru kontekstnog
dijagrama mora se voditi računa da treba definisati setove ulaza, kontrola i mehanizama
koji proizvode set izlaza, tj. treba na ovom nivou uopštiti posmatranu problematiku sa
manje detalja.
Dubina modela se definiše nivoima dekomponovanja, gde se definišu nivoi detaljnosti.
Dekompozicija ide do mogućnosti definisanja programskih modula, koji se mogu opisati
dijagramom toka podataka, tzv. Data Flow Diagram (DFD). O tome će biti više reči u opisu
aktivnosti "2.1.3. Definisanje dijagrama toka podataka".
Aktivnost A0, koja se pojavljuje u kontekstnom dijagramu, opisuje okvire modela i mora biti
određena aktivnom glagolskom frazom, kao, npr. "Praćenje isplata" (slika 2.6).
Preporučuje se da treba početi od definisanja izlaznih strelica, pa se pomerati prema
ulazima, mehanizmima i kontrolama. Polazi se od činjenice da svaka aktivnost poseduje
odgovarajuće izlaze koji se mogu identifikovati. Prilikom definisanja izlaza treba voditi
računa i o negativnim izlazima, koji prouzrokuju tzv. povratne (feedback) strelice.
Sledeći elementi koje treba definisati su strelice ulaza, koji se na specifičan način
transformiše (ili troši) radi stvaranja odgovarajućeg izlaza, potpomognut odgovarajućim
mehanizmima i kontrolom.
Na kraju treba proveriti:
!" da li kontekstni dijagram obuhvata aktivnosti koje se modeliraju;
!" da li je kontekstni dijagram konzistentan sa svrhom, uglom posmatranja i granicama;
!" da li strelice uspostavljaju odgovarajući nivo detalja (ne sme ih biti više od šest po tipu
strelice);
!" da li su model prihvatili svi članovi grupe.
Imajući u vidu definisane pretpostavke, u daljem tekstu biće prikazan kontekstni dijagram
za dokument "Karton isplata".
Postupak o Pravilnik o
Postupak o
definisanjuisplatama
izve{tavanju
{ifarnika
Zahtev iz kadrovskog
Izve{taj knjigovo
Zahtev za isplatu
PRA]ENJE
Zahtev za novu {ifru ISPLATA
Nalog za isplatu
Zahtev za izve{taj
0
SUBP Prevodioci
Kao što se na slici 2.6. vidi, sama aktivnost definisana je glagolskom frazom "Praćenje
alempije@beotel.yu 17
isplata", dok su strelice definisane i grupisane kao:
!" ulazni dokumenti:
• "Zahtev iz kadrovskog", kojim se definiše zahtev za otvaranje novog kartona;
• "Zahtev za isplatu", kojim se definiše zahtev za isplate prevodiocima;
• "Zahtev za novu šifru", kojim se u šifarniku definiše nova šifra;
• "Lista isplata", kojom se definiše lista isplata radnika;
• "Zahtev za izveštaj", kojim se definiše tip izveštaja;
!" izlazni dokumenti:
• "Izveštaj knjigovodstvu", gde se knjigovodstveno prate isplate;
• "Nalog za isplatu", kojim se omogućuje isplaćivanje preko žiro-računa.
!" Kontrole su uputstva i postupci i za ovaj primer su:
• postupak o izveštavanju;
• postupak o definisanju šifarnika;
• pravilnik o isplatama.
!" Mehanizmi se definišu kao:
• relacioni sistem za upravljanje bazom podataka (RSUBP);
• prevodioci.
Imajući u vidu ovako postavljeni kontekstni dijagram, u sledećem koraku se definiše stablo
aktivnosti.
18 alempije@beotel.yu
Aktivnost
1.1.2. Definisanje stabla aktivnosti
Na osnovu definisanih granica sistema prelazi se na sledeću aktivnost "1.1.2. Definisanje
stabla aktivnosti", gde se uspostavljaju vertikalne (hijerarhijske) veze između aktivnosti.
Stablo aktivnosti se definiše primenom metode rešavanja problema odozgo nadole (top- -
down), kada se složena aktivnost rastavlja na više podređenih aktivnosti, a zatim se
pristupa rešavanju jednostavnih podređenih aktivnosti.
Drugim rečima, polazna složena aktivnost razvija se u hijerarhiju podređenih aktivnosti, čija
je struktura tipa stabla. Koren stabla (to je najviši čvor stabla) sadrži polaznu aktivnost, dok
listovi, tj. čvorovi koji nemaju potomke, sadrže aktivnosti čije je rešavanje relativno
jednostavno. Rešavanjem svih podređenih aktivnosti iz listova rešena je i polazna složena
aktivnost. Za aktivnost "1.2. Definisanje zahteva korisnika" ide se do trećeg nivoa, dok se
detalji razmatraju u okviru aktivnosti "2.1.1. Izrada detaljnog stabla aktivnosti".
Ovaj pristup je veoma važan kada se uspostavlja okvir reinženjeringa poslovnih procesa koji
mogu doći u razmatranje.
Aktivnost na vrhu (root) uvek je označena sa 0. Brojevi se koriste da bi prikazali koliko
detalja sadrži aktivnost. Aktivnost A0 je dekomponovana (razdvojena) na 1, 2, 3 itd.
Aktivnost 1 je dekomponovana u 11, 12, 13 itd. Nadređena aktivnost se zove 'roditelj'
(parent), a podređene aktivnosti su deca (childs).
Razbijanje aktivnosti 'roditelj' na svoju decu treba da ima od dve do šest podređenih
aktivnosti. Ako je više od šest podređenih aktivnosti, to znači pokušaj da se smesti previše
detalja na jedan nivo.
Na osnovu svega što je dosad rečeno, treba definisati stablo aktivnosti za aktivnost
"Praćenje isplata".
alempije@beotel.yu 19
Stablo aktivnosti za aktivnost "Praćenje isplata"
Za primer dokumenta "Karton isplata" (prikazanog na slici 2.5), odnosno za kontekstni
dijagram sa slike 2.6. prikazano je stablo aktivnosti na slici 2.7.
PRA]ENJE
ISPLATA
0
ODR@AVANJE
ODR@AVANJE IZRADA
PODATAKA O
[IFARNIKA IZVE[TAJA
PREVODIOCIMA
1 2 3
20 alempije@beotel.yu
Aktivnost
1.1.3. Verifikacija stabla aktivnosti
Verifikaciono telo treba stalno da kontroliše rad stručnog tima, uz blagovremeno otklanjanje
eventualnih grešaka i nedoslednosti u njihovom radu. S druge strane, zbog postojanja ovog
tela, nije potreban supervizor projekta, jer je projekat kontrolisan i verifikovan u svim
fazama izrade.
Verifikaciono telo ne mora da bude stalnog sastava; u zavisnosti od sadržaja koji se
verifikuje, ono može da ima uži ili širi sastav.
Drugi veliki kvalitet je učestvovanje dela rukovodstva preduzeća u izradi projekta, od čijeg
angažovanja isključivo zavisi kasnija uspešna realizacija projektovanih rešenja.
Nakon verifikacije stabla aktivnosti od strane top-menadžmenta, pristupa se definisanju
zahteva korisnika koji će da potvrde ili koriguju ovako postavljenu tezu.
alempije@beotel.yu 21
Aktivnost
1.2. Definisanje zahteva korisnika
Aktivnost
1.2.1. Definisanje zahteva iz dokumenata
Aktivnost "1.2.1. Definisanje zahteva iz dokumenata" je pogled odozdo nagore i u
nadređenoj aktivnosti "1.2. Definisanje zahteva korisnika" ima globalni karakter, jer se
prikupljaju dokumenta iz cele firme.
22 alempije@beotel.yu
!" da li se unose tačni podaci;
!" da li se unose kompletni podaci;
!" kako se koriste;
!" koliko često se koriste;
!" koliko je tačan taj izlaz danas;
!" u kom obliku je prikazan;
!" kada se izrađuje i koliko često;
!" koliki su obim i broj kopija;
!" kome se upućuje;
!" šta startuje izlaz;
!" koja se poboljšanja mogu uvesti.
Za postupak rada sa dokumentima definisane su i odgovarajuće procedure i organizacioni
propisi, koje, ako postoje, treba proučiti i inovirati postojećom praksom, a ako ne postoje- -
treba ih napisati, jer to neposredno utiče na postojeću organizaciju rada.
Analiza dokumenata pomaže analitičaru da formira mišljenje o čitkosti tih dokumenata, kao
i da razume korisnikovu terminologiju, da bi u sledećem procesu "1.2.2. Definisanje zahteva
intervjuom" postavio prava pitanja prilikom sprovođenja intervjua.
Na osnovu svega toga u sledećem koraku treba izvršiti analizu dokumenta "Karton isplata".
alempije@beotel.yu 23
Aktivnost
1.2.2. Definisanje zahteva intervjuom
Aktivnost "1.2.2. Definisanje zahteva intervjuom" je pristup odozgo nadole, i treba da
omogući definisanje:
!" potreba za informacijama,
!" ciljeva i
!" problema kako ih vide rukovodioci i neposredni izvršioci.
To je ključni momenat u reinženjeringu poslovnih procesa, jer se ovde rukovodstvo
izjašnjava o pitanju budućnosti, odnosno daljem poslovanju. Ova analiza treba da da i
odgovore vezane za primenu Interneta u preduzeću.
Prvi korak su opšte pripreme za izvođenje intervjua koje su vezane za definisanje:
!" liste rukovodilaca za intervjue,
!" vremenskog rasporeda intervjua,
!" teme za razgovor,
!" potvrde termina,
!" organizacije grupe za intervjue,
!" vođenje zapisnika,
!" priprema panela,
!" opremanje prostorije,
!" izbor opštih pitanja i
!" probni intervju.
Ne sme se zaboraviti da rukovodilac treba da pošalje pismo sa objašnjenjem, svrhom,
temama i pitanjima tako da bi se druga strana mogla pripremiti.
Posebno treba naglasiti organizaciju grupe za intervjue, gde treba definisati:
!" koji će član tima voditi zapisnik,
!" ko će prezentovati dosadašnje rezultate,
!" ko će postavljati pitanja.
Teme treba unapred odrediti, jer se posle lakše sređuju. Preporučuje se izvođenje probnog
intervjua u okviru članova tima, radi bolje pripreme i uvežbanosti.
Cilj svih aktivnosti je razvoj preporuka za buduće akcije. Naime, aktivnosti treba da
omoguće da se za trenutno postojeće objekte poslovanja (organizacione jedinice, procese i
dr.), aplikacije i datoteke identifikuje redundantnost podataka, razjasne odgovornosti i,
uopšte, razume poslovanje.
Da bi se ostvarile ove aktivnosti pristupa se postupku intervjuisanja, počev od najviših
rukovodilaca do neposrednih korisnika.
Treba još jednom naglasiti da intervju zahteva pre svega uključivanje najviših rukovodilaca i
sagledavanje problema u poslovanju sa njihovog stanovišta.
Opšta pitanja za intervjuisanje su:
!" koje su nadležnosti i odgovornosti;
!" šta su osnovni ciljevi i kakve se promene mogu očekivati u određenoj oblasti za sledeću
godinu i dalje;
!" koji su kritični faktori u pogledu odgovornosti upravljanja i odlučivanja;
24 alempije@beotel.yu
!" kakvi su zahtevi za informacijama;
!" koji su najveći problemi bili u poslednje vreme i šta je bilo potrebno za rešavanje tih
problema (koje se informacije i koji efekti mogu očekivati);
!" u kojim procesima se mogu postići poboljšanja i koje su potrebe za podacima;
!" koje su prikupljene informacije najupotrebljivije.
Po završetku intervjua treba odgovore razmotriti, napisati rezime i izdvojiti uočene
probleme.
Jedan od bitnih rezultata intervjua je i uspostavljanje boljih odnosa između članova tima i
najviših rukovodilaca, što ima neposrednog uticaja na podršku koju rukovodioci treba da
pruže u postupku reinženjeringa poslovnih procesa.
Obično se sprovodi pet do deset intervjua sa najvišim rukovodiocima, u trajanju od dva do
tri sata. To je i najduža aktivnost u toku reinženjeringa poslovnih procesa.
Takođe, jedan od bitnih momenata je i analiza problema i njihovo povezivanje sa procesima
poslovanja, jer predstavljaju uvodno uputstvo za postavljanje prioriteta vezanih za redosled
realizacije pojedinih poslovnih funkcija.
Na kraju se definišu odgovarajući zaključci, koji treba da pokažu rukovodiocima da su
njihova gledišta shvaćena i ugrađena u rezultate i zaključke projekta.
Izvršioci ovog procesa su:
!" poseban tim za intervjue koji priprema i obavlja intervju, obrađuje odgovore i daje
analizu intervjua;
!" poseban tim za katalog aplikacija koji snima i radi katalogizaciju postojećih aplikacija;
!" eksperti iz domena podsistema ili procesa koji predlažu organizaciono-informaciona
rešenja pojedinih procesa ili podsistema;
!" korisnici koji daju informacije o informacionim potrebama i zahtevima procesa u koje su
uključeni i koji ocenjuju kritičnost procesa na osnovu dogovorenih merila;
!" koordinacioni odbor koji:
!" koordinira rad posebnih timova,
!" usvaja predložena organizaciono-informaciona rešenja,
!" određuje merila za ocenu kritičnosti procesa,
!" usvaja analize posebnih timova i
!" utvrđuje prioritete razvoja podsistema.
U sledećem koraku biće izvršeno definisanje zahteva intervjuom za dokument "Karton
isplata".
alempije@beotel.yu 25
!" usluge van preduzeća,
!" datum stupanja u preduzeće,
!" neposredno nadređeni rukovodilac.
Dakle, sprovedenim intervjuom definisani su zahtevi koji ne postoje u postojećem ručnom
dokumentu i koje treba ugraditi u buduće rešenje. Ovaj veoma značajan momenat i zahteva
maksimalno angažovanje zaposlenih, a pogotovu vodećeg menadžmenta.
Na osnovu prethodno izvedenih aktivnosti u sledećem koraku treba definisati matricu
odnosa.
26 alempije@beotel.yu
Aktivnost
1.2.3. Definisanje matrice odnosa
Aktivnost "1.2.3.Definisanje matrice odnosa" treba da definiše matricu veza između
aktivnosti i dokumenata koji treba da povežu dokumenta određena kao ulazne ili izlazne
informacije sa aktivnostima iz stabla aktivnosti na gornjem okvirnom nivou. Dokumenta su
definisana odgovarajućim rubrikama, čijom se analizom određuju odgovarajući entiteti.
Entiteti na ovom nivou predstavljaju objekat koji se može opisati nekim osobinama. Za ovu
aktivnost bitni su samo nazivi entiteta, bez ulaženja u definisanje osobina.
Svakom entitetu se pridodaje način na koji aktivnost koristi taj entitet, odnosno šta radi sa
pojedinim instancama tog entiteta preko tzv. CRUD matrice.
Entitet se u okviru neke aktivnosti: i/ili kreira (C-Create), i/ili pretražuje (R-Retrive) i/ili
ažurira (U-Update), i/ili briše ( D-Delete), pa otuda i naziv CRUD matrica (definisana
početna slova engleskog naziva).
Za aktivnost "Praćenje isplata" na slici 2.8. prikazana je CRUD matrica.
alempije@beotel.yu 27
U ovoj aktivnosti se definišu osnovne postavke dok se u okviru aktivnosti "2.1.1.Definisanje
detaljne matrice odnosa", detaljnije specificiraju i atributi korišćenja, tzv. IRUN matrica (o
čemu će kasnije više biti reči).
Na osnovu izvedenih, prethodno opisanih aktivnosti u sledećem koraku pristupa se analizi
zahteva budućeg korisnika softverske aplikacije.
Aktivnost
1.2.4. Analiza zahteva korisnika
Aktivnost "1.2.4. Analiza zahteva korisnika" znači da postavke definisane u prethodnim
koracima treba da verifikuje odgovarajući verifikacioni organ preduzeća.
Zadatak verifikacionog tela je da usvaja rezultate rada stručnog tima u kontrolnim tačkama
koje predstavljaju okončanje pojedinih faza na izradi projekta.
Treba naglasiti da sve navedene aktivnosti i podaktivnosti moraju ići ovim redosledom i da
definisanje tehničkih preduslova tek onda dolazi u razmatranje. U praksi se obično, radi
naopako.
28 alempije@beotel.yu
Aktivnost
1.3. Tehnički preduslovi
Sistem softver čine operativni sistemi, koji mogu biti jednokorisnički (CPM, MS-DOS) i
višekorisnički (UNIX, OPEN/VMS, Windows 2000), zatim, jezički procesori koji se dele na
interpretere (BASIC) i kompajlere (FORTRAN, PASCAL, C++), kao i aplikativni softveri u
koje spadaju tekst-procesori (Word for Windows) i baze podataka.
Imajući sve to u vidu, aktivnost "1.3. Tehnički preduslovi" izvodi se kroz tri podređene
aktivnosti:
!" Aktivnost 1.3.1. Definisanje arhitekture sistema,
!" Aktivnost 1.3.2. Kadrovske potrebe,
!" Aktivnost 1.3.3. Dinamika realizacije i troškovi.
alempije@beotel.yu 29
Aktivnost
1.3.1. Definisanje arhitekture sistema
Aktivnost "1.3.1. Definisanje arhitekture sistema" treba da ukaže na osnovne pretpostavke
koje se moraju ispuniti da bi se mogao sprovoditi postupak reinženjeringa poslovnih
procesa.
Tehnike i tehnologije računarstva, komunikacija, pogotovu razvoj Interneta i Intraneta,
osnova su za pristupanje složenom poslu reinženjeringa poslovnih procesa. Otuda
reinženjering poslovnih procesa treba zasnivati na najnovijim saznanjima, tehnikama i
tehnologijama, kao i principima distribuirane obrade, korišćenja baza podataka, postizanja
kompatibilnosti u mrežama računara i upotrebama uređaja za prikaz informacija. Prilaz
razmatranja tehničko-tehnoloških resursa treba da je u saglasnosti sa otvorenom
arhitekturom referentnog modela organizacije za standarde, gde je definisano sedam nivoa
povezivanja i komuniciranja računarske i druge opreme:
!" NIVO 7. APPLICATION (aplikacijski nivo)
!" NIVO 6. PRESENTATION (prezentacijski nivo)
!" NIVO 5. SESSION (nivo sesije)
!" NIVO 4. TRANSPORT (transportni nivo)
!" NIVO 3. NETWORK (mrežni nivo)
!" NIVO 2. DATA LINK (nivo podaci - veze)
!" NIVO 1. PHISICAL (fizički nivo)
Pri izboru opreme treba imati u vidu tehničko-tehnološke preduslove, koji su sagledavani
prema strukturi arhitekture referentnog modela:
!" kvalitetan komunikacioni sistem,
!" visok stepen kompatibilnosti računarske opreme,
!" otvorenost mrežne arhitekture,
!" modularnost opreme krajnjih korisnika,
!" efikasnost sistema upravljanja podacima,
!" korišćenje softverskih proizvoda za razvoj aplikacije.
30 alempije@beotel.yu
Kompatibilnost računarske opreme
Jedan od osnovnih problema za sprovođenje postupka reinženjeringa poslovnih procesa je
ostvarivanje kompatibilnosti između računarske opreme radi njenog povezivanja i
međusobnog rada.
Kompatibilnost računarske opreme je neophodna da bi mogla da čini distribuirani sistem,
pogotovu kompatibilnost centralizovane opreme sa opremom na mestima krajnjih korisnika
obrade podataka i informacija.
Međutim, kompatibilnost koja mora da postoji za potrebe fizičkog i logičkog povezivanja
različite opreme nije dovoljna, već je neophodna i kompatibilnost i za ostale nivoe
komuniciranja dva korisnika prema OSI (Open System Interconnection) referentnom
modelu, gde je posebno bitna kompatibilnost aplikativnog nivoa i nivoa predstavljanja
podataka i informacija.
Prilikom izbora računarske opreme treba težiti da između opreme postoji što veći stepen
kompatibilnosti rada na svim nivoima posmatranja prema OSI referentnom modelu. U vezi s
tim bitno je naglasiti da se i prilikom izbora softvera, tj. sistema za upravljanje bazama
podataka mora voditi računa da postoji softverski proizvod koji se može instalirati na svim
računarskim platformama. To je strateška odluka rukovodstva preduzeća i od te odluke
može zavisiti tehnološki napredak preduzeća.
alempije@beotel.yu 31
Efikasnost sistema upravljanja podacima
Podaci predstavljaju osnovni resurs, pa je otuda upravljanje podacima u ovakvim sistemima
od izuzetne važnosti, pogotovu kada je reč o korišćenju i upravljanju distribuiranim bazama
podataka, gde sistemska podrška treba da osigura kontrolisanu distribuciju i redundansu
podataka, brzo i precizno lociranje i manipulisanje podacima. Osnovni zahtevi upravljanja
podacima su iskazani kroz potrebu unificiranog organizovanja i integracije podataka, kao i
obezbeđivanja zaštite i pouzdanosti podataka. U okviru tih zahteva ogleda se efikasnost
sistema za upravljanje podacima.
Prilikom realizacije distribuiranih sistema treba težiti da se koristi jedinstvenost sistema
upravljanja podacima, i to pre svega zbog transparentnosti podataka između računara, što
je posebno bitno za složene distribuirane sisteme, kod kojih se koriste distribuirane i
integrisane baze podataka, a procesiranje vrši sa više računara.
Aktivnost
1.3.2. Kadrovske potrebe
Pod kadrovskim potrebama podrazumevaju se broj potrebnog kadra za realizaciju projekta
reinženjeringa poslovnih procesa i potrebna obuka za korišćenje informacionih tehnologija.
Uz obezbeđivanje neophodne računarske opreme, komunikacione i ostale prateće opreme,
od posebnog značaja su i kadrovski resursi, odnosno kvalitetna i u dovoljnoj meri
zastupljena kadrovska podrška.
Saglasno tom prilazu, kao informatičku osnovu u sprovođenju reinženjeringa poslovnih
procesa, treba imati minimum potrebnog kadra. Potrebni su:
!" rukovodilac,
!" vodeći projektant za modeliranje procesa i podataka,
!" vodeći projektant softverskih rešenja,
32 alempije@beotel.yu
!" vodeći projektant baze podataka,
!" sistem inženjer,
!" referent dokumentacije.
Posebno značajnu ulogu treba da imaju kontinuirani proces obrazovanja kadra i
automatizacija njihovog rada, kao i adekvatni oblici funkcionalnog organizovanja. To je
pođednako značajno i za fazu razvoja i za fazu korišćenja. Upravo zato, shodno usvojenoj
metodologiji, treba dati i pregled sledećih kurseva:
!" kompjutersko opismenjavanje (WINDOWS, MS Word),
!" integracija IS i zahteva sistema kvaliteta (modeliranje procesa - BPwin),
!" modeliranje podataka - ERwin,
!" generisanje prototipske aplikacije u MS ACCESS-u,
!" rad sa tabelama - MS EXCEL,
!" mrežni rad i INTERNET I NJEGOVI SERVISI.
alempije@beotel.yu 33
Kompjutersko opismenjavanje
(WINDOWS, MS Word)
Sadržaj kursa:
Računari i računarski sistemi. Sistem hardver. Sistem softver. Sistem dokumentacije. PC
računari, konfiguracija, komponente, štampači.
WINDOWS operativni sistem: Osnovno o WINDOWS okruženju i načinu korišćenja prozora.
Organizacija podataka. Pojam direktorijuma, stabla, navigacija. Rad sa disketom (formati,
kapaciteti, formatizovanje). Tipovi podataka.
Microsoft Office - funkcije i elementi.
WORD for WINDOWS: Pozivanje programa WORD for WINDOWS. Dokument, font, format
stranice, tabulatori, automatski back-up, korišćenje stilova, podešavanje osnovnih
parametara stranice. Navigacija, unos teksta, brisanje, obeležavanje teksta. Operacije sa
blokovima teksta. Ubacivanje prekida stranica, straničenje, heder-futer, fusnota. Ubacivanje
datoteka, okvira i slika. Editor formula. Rad sa makroima. Štampanje dokumenta. Unakrsne
tabele. Baze podataka.
Napomena: Opismenjeni korisnici su korisniji sagovornici, jer imaju više zahteva i prošireni
su im vidici.
Modeliranje podataka-ERwin
Sadržaj kursa:
Šta je to IDEF1X standard? Identifikacija kandidata za entitete. Identifikacija veze.
Definisanje entiteta i relacija. Nezavisni entitet. Zavisni entitet. Asocijativni entitet.
Identifikujuće i neidentifikujuće veze. Izrada ER modela. Atributi ER modela. Lista kandidata
za atribute. Definisanje ključeva u modelu. Atributi i normalizacija. Definisanje poslovnih
pravila. Ograničenja. Prikaz i verifikacija kardinalnosti veza. Definisanje referencijalnog
integriteta. Identifikacija poslovnog domena. Identifikacija operacija.
Napomena: Obučeni korisnici su korisni sagovornici za modeliranje podataka, jer na ovom
nivou, pre nego što se pređe na programiranje, treba razrešiti što više dilema.
34 alempije@beotel.yu
Generisanje prototipske aplikacije
u MS ACCESS-u
Sadržaj kursa:
Prevođenje strukture ERwin-a. Generisanje tabela. Generisanje formata i validacionih
pravila. Korišćenje Wizard-a. Dizajniranje i koršćenje formi. Upravljanje podacima.
Dodeljivanje i oduzimanje privilegija drugim korisnicima. Upoređivanje Access-a 2.0 sa
Access-om 97 i Access-om 2000 i veza sa SQL serverom. Prikaz realizovanog softvera za
definisan model podataka.
Napomena: MS ACCESS je dobra platforma za prototipsko programiranje koje, po izboru
odgovarajućeg SUBP, može da ostane klijent-strana u okviru klijent/server-arhitekture.
MS EXCEL, vrste podataka. Unos numeričkih podataka, natpisa, datuma i vremena, logičkih
izraza, formula. Unos adrese ćelije. Apsolutna i relativna adresa ćelije. Formatizovanje i
poravnavanje podataka. Izbor fonta. Dodavanje okvira tabeli. Prikaz karakteristika tabele.
alempije@beotel.yu 35
Aktivnost
1.3.3. Dinamika realizacije i troškovi
Kada je reč o dinamici realizacije i troškovima, neophodno je korišćenje nekog od softvera
za upravljanje projektima (npr., MS Project).
Troškovi realizacije najčešće se posmatraju u okviru grupa poslova kao:
!" troškovi razvoja aplikacija,
!" troškovi tehničko-tehnoloških resursa,
!" troškovi eksploatacije.
Svaka od ovih grupa poslova se, takođe, sastoji iz posebnih troškova i otuda specifikaciju
troškova treba da čini sledeća struktura:
!" troškovi razvoja:
• obuka projektnog tima,
• razvoj zajedničkih aplikacija,
• stručna pomoć pri razvoju,
• razvoj i dopuna sopstvenih aplikacija,
• softverski proizvodi za razvoj aplikacija;
!" troškovi tehničko-tehnoloških resursa:
• računarska oprema zajedničkih resursa,
• oprema komunikacionog sistema,
• dopuna i kompletiranje računarske opreme,
• prateća oprema i adaptacija prostora;
!" troškovi eksploatacije:
• održavanje opreme,
• potrošnja električne energije,
• korišćenje komunikacionih linija,
• amortizacija opreme,
• plate radnika.
Kao rezultat aktivnosti "1.Funkcionalno modeliranje" trebalo bi da proizađe dokument pod
nazivom "Studija elemenata potrebnih za reinženjering poslovnih procesa" na osnovu koje
se sprovodi sledeća aktivnost: "2. Informaciono modeliranje".
36 alempije@beotel.yu
Aktivnost
2. Informaciono
modeliranje
alempije@beotel.yu 37
Aktivnost "2. Informaciono modeliranje" se izvodi na osnovu definisanih kritičnih funkcija za
prethodno urađenu aktivnost "1. Funkcionalno modeliranje". Kritične funkcije predstavljaju,
svaka za sebe, po jedan glavni projekat koji se razvija u okviru aktivnosti: "2.
Informaciono modeliranje". Informacioni model prikazuje u kakvom su međusobnom odnosu
podaci u nekom realnom sistemu.
Informaciono modeliranje omogućuje:
!" definisanje sistemske dokumentacije koja se može koristiti za bazu podataka i za razvoj
aplikacija da bi osoblje moglo da definiše sistemske zahteve;
!" bolju komunikaciju međusobno i sa krajnjim korisnicima;
!" jasnu sliku o poslovnim pravilima i
!" 'logičku' sliku baze podataka koju mogu koristiti automatski alati za generisanje sistema
za upravljanje bazama podataka (SUBP).
INFORMACIONO
MODELIRANJE
2
DEFINISANJE DEFINISANJE
KREIRANJE KREIRANJE
DETALJNIH POSLOVNIH
ER DIJAGRAMA ATRIBUTA
ZAHTEVA PRAVILA
2.1 2.2 2.3 2.4
38 alempije@beotel.yu
Aktivnost
2.1. Definisanje detaljnih zahteva
C1
Idejni
projekat
IZRADA Detaljni
Stablo
DETALJNOG dekompozicioni
aktivnosti
STABLA dijagram
AKTIVNOSTI
2.1.1
DEFINISANJE
DEFINISANJE
DETALJNE
DEKOMPOZICIONOG CRUD i IRUN matrica
MATRICE
DIJAGRAMA
I1 ODNOSA
Informacije od 2.1.2
2.1.3
korisnika
DEFINISANJE Detaljni
DIJAGRAMA DFD zahtevi
TOKA
PODATAKA
2.1.4
ANALIZA
DETALJNIH
O1
ZAHTEVA
2.1.5
Radna
grupa
M1
alempije@beotel.yu 39
Aktivnost
2.1.1. Izrada detaljnog stabla aktivnosti
Ulaz u aktivnost "2.1.1. Izrada detaljnog stabla aktivnosti" je idejni projekat na osnovu
dobijene informacije od korisnika. Sama aktivnost se izvodi za izabranu kritičnu funkciju,
gde se vrši dekompozicija do nivoa primitivnih procesa za koje se realizuju odgovarajući
scenariji događanja. Izlaz iz ove aktivnosti je detaljno stablo aktivnosti za kritičnu funkciju.
Način izrade stabla aktivnosti opisan je u prethodnom poglavlju. Ovde treba istaći da
primenom BPwin-a CASE alata ovaj pristup ima novu dimenziju, jer omogućuje da se
nastavi projekat na onim mestima gde se završava navedena studija. Ovakav pristup
omogućuje stalnu ažurnost projekta i praćenje vremenske i novčane dinamike, vezane za
sprovođenje reinženjeringa izabrane poslovne funkcije preduzeća.
Na osnovu definisanog detaljnog stabla aktivnosti u sledećem koraku prelazi se na
definisanje dekompozicionog dijagrama.
Aktivnost
2.1.2. Definisanje dekompozicionog dijagrama
40 alempije@beotel.yu
0
A0
A-0
Op{tije
1
2
3 Detaljnije
4
A4
A0
2
A42
3
A4
A42
alempije@beotel.yu 41
Grani~ne strelice
Interne strelice
Grani~ne
strelice
Ulazne granične strelice koje dolaze iz nadređenog dijagrama u podređeni dijagram mogu se
deliti u više specifičnih strelica i obrnuto, izlazne granične strelice iz podređenog
dekompozicionog dijagrama se grupišu i izlaze u nadređeni dijagram.
Strelice u okviru dekompozicionog dijagrama mogu se definisati kao:
!" strelice koje se granaju ili udružuju,
!" povratne strelice i
!" skrivene strelice.
A
Puni skupovi informacija u svim granama.
A A
A A
Podela na pun skup u prvoj i podskup
informacija u drugoj grani
B
A B
Podela na različite podskupove informacija
C
A&B
Integracija strelica
A
B
42 alempije@beotel.yu
Povratne strelice
Povratna (feedback) petlja je pojava kada izlaz iz aktivnosti predstavlja ulaz, kontrolu ili
mehanizam neke ranije aktivnosti u dekompozicionom dijagramu. Ovakvi izlazi su, obično,
neke negativne karakteristike.
1 1
1
2 2
2
U prvom i drugom slučaju prikazanom na slici 3.6. povratna petlja i ulazna povratna petlja
kao kontrola predstavljaju iteraciju ili rekurziju, dok u trećem slučaju povratna petlja
Izlaz - Mehanizam ima ulogu podrške na nivou resursa za izvođenje određene aktivnosti.
Skrivene strelice
Poseban tip strelica su tzv. skrivene (tunneled) strelice koje nastaju ako se želi da strelice
ne budu viđene na nadređenom ili podređenom dekompozicionom dijagramu. To je situacija
kada je dijagram prenatrpan, pa se zbog jasnoće izbegava njegovo prikazivanje. Druga
situacija je ako se želi prikaz budućih događaja.
Može biti i slučaj da strelica predstavlja kontrolu koja se primenjuje na svakoj aktivnosti u
dekompoziciji, a da je bila propuštena radi jasnoće u nižim nivoima. Oznaka da je strelica
sakrivena su zagrade (slika 3.7).
( )
( )
( )
)
( )
I1 O1
(
( )
( )
M1
alempije@beotel.yu 43
C1 C2 C3
Roditeljski roditeljska
aktivnost
dijagram 1
2
A12
3
A1
dijagram
dete Strelica (pozicijaC2)nije
prikazananadijagramudete
C1 C3
I1 1
3 O1
Ovajizlaznije prikazanna
roditeljskojaktivnosti
A12
Da bi se ovo pojasnilo poslužiće primer skrivenih strelica na slici 3.8. Ako su skrivene
strelice nacrtane u 'roditelj'skom dijagramu (pozicija C2) onda se ne pojavljuju u dijagramu
'dete'ta. Ukoliko su, pak, skrivene strelice nacrtane u dijagramu 'dete'ta, onda se ne vide u
dijagramu 'roditelj'.
Ugao posmatranja
Prilikom IDEF0 modeliranja mogu se razmatrati različita gledišta za rešavanje postavljenog
problema. Pri tom se mora usvojiti jedno kompromisno rešenje koje će se dalje koristiti.
Međutim, različita gledišta se mogu predstaviti korišćenjem takozvanih FEO (For Exposition
Only) dijagrama samo za prikazivanje. FEO dijagrami se, obično, koriste za prezentaciju
kada se žele ukloniti neki detalji zbog lakšeg razumevanja problema. Za razliku od IDEF0
grafičkog dijagrama, FEO dijagram ne mora da poštuje IDEF0 pravila. Ovaj prilaz se
najčešće koristi za prezentacije.
44 alempije@beotel.yu
Tekstualni opis
Pored prikazanog grafičkog opisivanja, potrebno je, kao dopunu, i tekstom opisati
aktivnosti. Tekstom se opisuju do detalja namena i funkcionisanje svake aktivnosti u
modelu. Tekstualni opis se često koristi da bi se obezbedio kompletan rezime poslovnog
procesa, tj. opisuju se relevantni detalji do tančina. To je bitno ako se sprovode elementi
vezani za internu standardizaciju i definisani postupci i uputstva vezani za seriju standarda
ISO 9000, jer postupci i uputstva postaju sastavni deo grafičkog opisa.
Imajući sve to u vidu, definisan je dekompozicioni dijagram za Aktivnost "Praćenje isplata".
Dekompozicioni dijagram
za aktivnost "Praćenje isplata"
Na osnovu definisanog kontekstnog dijagrama (prikazanog na slici 2.6) i stabla aktivnosti
(sa slike 2.7) definiše se dekompozicioni dijagram prikazan na slici 3.9. Sa prethodno
definisanog kontekstnog dijagrama (prikazanog na slici 2.6) automatski su prenesene
granične strelice, a na osnovu stabla aktivnosti (slika 2.7) pojavljuju se nepovezane tri
aktivnosti. Potrebno je granične strelice povezati sa odgovarajućim aktivnostima i definisati
interne strelice koje će povezati aktivnosti između sebe.
C3 C2 C1
Izve{taj knjigovod
IZRADA O1
IZVE[TAJA Nalog za isplatu
Zahtev za izve{taj O2
I4 3
Prevodioci
M2
alempije@beotel.yu 45
Aktivnost
2.1.3. Definisanje detaljnih matrica odnosa
Kada se za svaku strelicu definiše, osim načina korišćenja entiteta, i povezanost entiteta sa
atributima, onda se definiše IRUN (slika 3.10) matrica, što je skraćenica od:
!" ubacivanje atributa, što se označava sa I (Insert);
!" pretraživanje atributa, što se označava sa R (Retrive);
!" ažuriranje atributa, što se označava sa U (Update);
!" dodela nula vrednosti, što se označava sa N (Null field).
Dakle, mogu se kreirati dve matrice:
!" CRUD matrica, na kojoj bi sa jedne strane bili entiteti, a sa druge strane aktivnosti koje
koriste te entitete i
!" IRUN matrica, sa definicijom korišćenja svakog atributa u određenom entitetu i
određenoj aktivnosti.
Veza IDEF0 funkcionalnog modela i IDEF1X informacionog modela je omogućena preko
rečnika podataka (data dictionary manager). Na taj način (indirektnom sinhronizacijom)
dozvoljeno je sinhronizovanje jednog modela podataka sa više modela procesa, što se u
praksi ne samo često dešava već i preporučuje. ERwin CASE alat omogućuje importovanje
rečnika podataka iz ERwin-ovog modela podataka u BPwin model procesa i obrnuto.
Kao što se može zaključiti, prebacivanje rečnika podataka je omogućeno u oba smera, tako
da je, sa stanovišta projektanta, nebitno u kom trenutku je uočio potrebe za promenama na
datom modelu. U slučaju da se pojavi potreba da se definiše novi entitet ili atribut, ili da se
izmeni postojeći, to se može uraditi u BPwin-u, a zatim nadograditi rečnik podataka kao
veza sa ERwin-om. Moguće je, takođe, u BPwin-u definisati entitete ili atribute koji za model
podataka ne treba da budu vidljivi. Entiteti i atributi iz rečnika podataka se pridružuju
objektima koji opisuju kretanje podataka kroz procese, kao i način kreiranja, održavanja i
upotrebe podataka.
Kao jedan od važnih momenata je postupak "inverznog inženjerstva" (reverse engineering)
kada se od gotovog softverskog proizvoda, posredstvom ERwin-a, formira njegova
specifikacija (model podataka), pa se importuje u dekompozicioni dijagram BPwin, gde se
opisuju entiteti i atributi za kasniji, tzv. direktni inženjering, tj. modeliranje podataka
korišćenjem ERwin-a (videti "2. Aktivnost Informaciono modeliranje" ).
"Inverzni inženjering" je potreban, jer postoji, npr., skup COBOL-skih programa u kojima su
definisane gomile datoteka koje se još uvek koriste, ali za koje, osim izvornog koda, ne
postoji nikakva dokumentacija. Da bi se ove informacije iskoristile postupkom "inverznog
inženjerstva", treba praviti standardnu specifikaciju dela sistema, pa na osnovu nje
nastavljati razvoj, tj. definisati rečnik podataka u BPwin-u. U 4. delu za aktivnost
"3. Aplikativno modeliranje" o ovom postupku biće više reči. Treba napomenuti da se na
ovaj način ne može dobiti potpuna specifikacija, jer implementacija nekog softvera je
semantički siromašnija od njegove specifikacije, pa se ne može rekonstruisati potpuna
semantika sistema, mada se na taj način ipak pokušava sa korišćenjem onoga što je već
projektovano kao softver i što već radi.
46 alempije@beotel.yu
Imajući sve to u vidu, za primer dokumenta "Karton isplata" biće definisane detaljne CRUD i
IRUN matrice.
alempije@beotel.yu 47
Naziv aktivnosti Naziv entiteta CRUD Naziv atributa IRUN
ODRZAVANJE OSOBA CRUD DATUMZ I UN
PODATAKA O IME IU
PREVODIOCIMA PLATA IU
PREZIME IU
SIFRA ODELJENJA N
SIFRA RM N
SIFRA OSOBE IR
STIMULACIJA I UN
JMBG IU
VRSTA IR
CERTIFIKAT CRUD SIFRA JEZIKA R
SIFRA OSOBE R
STEPEN ZNANJA RU
ISPLATA CRU BROJ ISPLATE IR
SIFRA OSOBE R
DATUM ISPLATE IU
IZNOS IU
ODRZAVANJE JEZIK CRUD NAZIV JEZIKA IU
SIFARNIKA SIFRA JEZIKA IRU
ODELJENJE CRUD MESTO IU
NAZIV ODELJENJA IU
SIFRA ODELJENJA IRU
RAD.MESTO CRUD SIFRA RM IRU
NAZIV RM IU
Aktivnost
2.1.4. Definisanje dijagrama toka podataka
Dijagram toka podataka (DTP) grafički je opis koji povezuje procese, tokove podataka
(dokumenta), skladišta podataka (kartoteke). Drugim rečima, dijagram toka podataka se
koristi za prikaz na onom nivou gde su mogu definisati ulazi, izlazi, tokovi, skladišta i
procesi.
Dijagram toka podataka ili Data Flow Diagram (DFD) ugrađen je u softverski proizvod BPwin
i koristi se pri modeliranju procesa. Dijagram toka podataka fokusira problem tokova
podataka između procesa, a vrši i analizu skladišta podataka radi maksimalnog povećanja
njihove raspoloživosti i smanjenja vremena pretraživanja.
Dijagram toka podataka treba da nadomesti nedostatke koji postoje u IDEF0 metodologiji i
definišu se za niže nivoe dekompozicionog dijagrama.
Dakle, DTP je skup procesa koji se paralelno izvršavaju i ne treba ga mešati sa dijagramom
toka programa (flow chart). Dijagram toka programa je akcioni dijagram, tj. sekvencijalni
proces, dok je dijagram toka podataka-skup paralelnih procesa i veza tokova podataka i
skladišta podataka između njih.
Primer razlika između dijagrama toka podataka i dijagrama toka programa (flow chart)
može se opisati na sledeći način:
"Ako je redosled aktivnosti u jednom preduzeću takav da jedan radnik obrađuje jedan
dokument dok svi ostali ne rade ništa, pa kad završi obradu dokumenta, aktivira se sledeći
radnik a prethodni čeka, onda je dijagram toka programa identičan dijagramu toka
podataka."
Dijagram toka podataka se grafički opisuje preko:
!" procesa (Processes),
48 alempije@beotel.yu
!" toka podataka (Data Flow),
!" skladišta podataka (Data stores),
!" spoljnih objekata (External agents).
Proces (Processes)
Proces je niz operacija kojima se transformišu ulazni podaci u izlazne.
Proces je označen:
!" brojnom oznakom kojom je referenciran proces i
!" nazivom procesa.
alempije@beotel.yu 49
Spoljni objekat (External agents)
Spoljni objekat (External agents ili interface) treba da izvrši povezivanje sa objektima van
konteksta posmatranog sistema i predstavlja ponore i/ili izvore tokova podataka. Inače,
predstavlja se dvostrukim pravougaonikom, u koji se upisuje ime objekta.
Imajući sve to u vidu, za Aktivnost "1. Održavanje podataka o prevodiocima" (sa slike 3.9.)
biće definisan dijagram toka podataka.
Pravilnik o isplatama
1.1
Zahtev iz kadrovskog Osnovni podaci
ODR@AVANJE
OSNOVNIH
PODATAKA Podaci za
kalkulaciju
KARTON
ISPLATA
Stepen
1.2 znanja
[ifarnici jezika
PRA]ENJE
NIVOA ZNANJA Podaci o
JEZIKA stavkama
isplata Lista
1.3
isplata
Zahtev za isplatu OBRA^UN
ISPLATE
Prevodioci
Slika 3.12. Dijagram toka podataka za aktivnost "1. Održavanje podataka o prevodiocima"
50 alempije@beotel.yu
Aktivnost
2.1.5. Analiza detaljnih zahteva
Aktivnost "2.1.5. Analiza detaljnih zahteva" treba da bude svojevrsna rekapitulacija do sada
obavljenih aktivnosti (slika 3.13).
Ativnost "1. Provera prikupljenih informacija" predstavlja proveru prethodne faze, vezane za
postavljanje modela reinženjeringa, jer postoji mogućnost da u međuvremenu dođe do
nekih izmena.
Ulaz je definisana studija iz prethodne faze i zahtev da se izvrši ekspertiza, a izlaz su
izmenjene ili nove činjenice koje zadovoljavaju postavljene ciljeve projekta i koje izvode
odgovarajući eksperti, uz pomoć učesnika u izradi studije.
Sledećom aktivnosti "2. Provera pojedinačnih modela", u svetlu novih činjenica, definisanih
prethodnom aktivnošću učesnika, tj. autora pojedinačnog modela može zahtevati dodatne
informacije, a kao rezultat ove aktivnosti su pojedinačni modeli.
S obzirom na to da se prilikom izvođenja aktivnosti "3. Provera kompletiranog modela"
moraju napraviti pojedini kompromisi i odstupanja, to kao povratna informacija ide
"Komentar radnog materijala ", kao i model za pregled.
Kako su korisnici konačne sudije, to oni u okviru aktivnosti "4. Validacija modela" treba da
prekontrolišu valjanost modela. Izlaz iz ove aktivnosti su komentari korisnika koji
predstavljaju ulaz za prethodnu aktivnost.
Na kraju, potrebno je da odgovarajuće verifikaciono telo izvrši proveru modela u okviru
aktivnosti "5. Verifikacija modela". Ako postoje primedbe, one su kao komentar modela ulaz
u aktivnost "3. Provera kompletiranog modela", a ako je model verifikovan - on se šalje kao
kontrolna informacija u aktivnost "3. Provera kompletiranog modela". Nakon verifikacije kao
izlaz se dobija detaljni IDEF0 model koji je rezultat aktivnosti "2.1. Definisanje detaljnih
aktivnosti".
Dosadašnjim aktivnostima modelirani su procesi, tj. definisana je dinamika sistema, dok će
u sledećem koraku biti izvršeno modeliranje podataka, tj. biće definisana statika sistema.
Informacije
od korisnika PROVERA ^injenice Dodatne
I4 informacije
PRIKUPLJENIH
INFORMACIJA
Detaljni 2.1.5.1
dekompozicioni
dijagram
I3 PROVERA Verifikovan
CRUD i IRUN matrica POJEDINA^NIH Pojedina~ni model
I1
DFD MODELA modeli
I2 Detaljn
2.1.5.2 zahtevi
PROVERA O1
KOMPLETIRANOG Napomena
MODELA
Komentar Model za
2.1.5.3
radnog pregled
materijala
VALIDACIJA
Eksperti MODELA
U~esnici
2.1.5.4
VERIFIKACIJA
Dokumentarista MODELA
Korisnici 2.1.5.5
Radna Komentar modela
grupa
Vrifikaciono te
M1
alempije@beotel.yu 51
Aktivnost
2.2. Kreiranje ER dijagrama
Detaljni
zahtevi IDENTIFIKACIJA Nepotpuna
I1 lista entiteta
KANDIDATA ZA
ENTITETE
2.2.1
Modelirani
IDENTIFIKACIJA entiteti
VEZA
2.2.2
ER model sa
Informacije DEFINISANJE definicijama
od korisnika ER MODELA
I2
2.2.3
Verifikova
VERIFIKACIJA ER model
ER DIJAGRAMA O1
2.2.4
Radna
grupa
M1
52 alempije@beotel.yu
Aktivnost
2.2.1. Identifikacija kandidata za entitete
alempije@beotel.yu 53
ULOGA VEZE TIP ENTITETA
RUKOVODI RUKOVODILAC
RUKOVOĐEN ODELJENJE
NARUCUJE KUPAC
NARUCEN PROIZVOD
!" Na osnovu interesa posmatranja, atribut može biti entitet, a može biti i atribut entiteta,
što zavisi od interesovanja, odnosno od toga koji se deo realnog sveta i koji pogled na
njega želi predstaviti. Npr., ako je osnovni objekt od interesa-kuća, onda je entitet-
kuća, a atribut-ulica, a ako su od interesa-ulice onda su atributi-kuće. Objekti od
interesa posmatranja prikazani su na slici 3.17.
Atributi
kucni broj
broj kuca desno
godina izgradnje
duzina kolovoza
broj spratova
sirina kolovoza
broj stanova
Aktivnost
2.2.2. Identifikacija veza
Veze u rečenici su 'glagolske fraze' koje pokazuju kakav je odnos među entitetima. Premda
glagolske fraze ne opisuju pravila precizno, one dozvoljavaju osobi koja posmatra model da
54 alempije@beotel.yu
stekne osnovni osećaj o povezanosti entiteta. Dobra je praksa ako čitanje modela daje
valjane rečenice (iskaze).
Na slici 3.18. dat je predlog mogućih fraza kojima se definisu veze između entiteta.
Imajući u vidu način definisanja potencijalnih entiteta i njihovih veza, u sledećoj aktivnosti
biće definisani ER modeli.
Aktivnost
2.2.3. Definisanje ER modela
Kao što je u prethodnom poglavlju istaknuto, realan svet se sastoji iz objekata (entiteta)
posmatranja, koji mogu biti ili realni objekti (osoba, mašina, vozilo, kuća), ili apstraktni
koncept (preduzeće, radno mesto), događaj (prekršaj, prevoz) ili odnosi (student- -
predmet, muž-žena). Entiteti su, obično, imenovani imenicama, kao OSOBA, TELEFON,
JEZIK, ISPLATA.
Preciznije, može se razmišljati o nekom entitetu kao o setu ili kolekciji (skupu) individualnih
objekata zvanih primerci ili instance (instances). Jedan primerak je jedan pojavni oblik
datog entiteta. Svaki primerak mora imati identitet različit od svih ostalih primeraka.
Npr., može se reći da entitet OSOBA predstavlja skup svih mogućih osoba definisanih kao
primerci entiteta (slika 3.19.).
alempije@beotel.yu 55
OSOBA
Sifra Stimu- Datum
Prezime Ime JMBG Plata
osobe lacija zaposlenja
827369 STEVIC ZORAN 1411952710331 8000 0 17.12.80
827499 ALAGIC MILAN 2503965345611 1600 3000 20.02.81
0
827521 VUKIC MILOS 1304970554321 1250 5000 22.02.81
0
827566 JOVIC MARA 1511956710343 2975 0 02.04.81
0
827654 MARTIC ZORA 2406965345311 1250 14000 28.09.81
0
827698 BOBIC IVAN 2304950554322 2850 0 01.05.81
0
827782 CEBIC GORAN 2311952710441 2450 0 09.06.81
0
827788 SUSIC ZORAN 1103965345611 3000 0 09.06.86
0
827839 KLJAKIC STEVAN 1404970554321 5000 0 17.11.81
0
827844 TUBIC MIRA 1611956710343 1500 0 08.09.81
0
827876 ALIMPIC PETAR 2706965345311 1100 0 19.09.87
0
827900 JAKIC VLADA 2904950554322 9500 0 03.12.81
827902 FILIPIC DRAGA 1305970554821 3000 0 03.12.81
N 0
OSOBA
Slika 3.20. Grafički prikaz nezavisnog entiteta OSOBA
Kao što se može videti na slici 3.20, entitet OSOBA predstavlja skup svih mogućih osoba sa
kojima se komunicira. Svaki primerak entiteta OSOBA je jedan korisnik. Svaki entitet sastoji
se od odgovarajućih primeraka ili instanci, kao što je prikazano na slici 3.19.
56 alempije@beotel.yu
Grafički se zavisni entiteti prikazuju kao zaobljeni pravougaonici u okviru kojih se upisuje
naziv tipa entiteta u jednini.
Karakteristični entitet ili slab entitet predstavlja grupu atributa koji se ponavljaju više puta
za jedan entitet i koji se identifikuju preko nezavisnog entiteta; npr., entiteti OSOBA i
ISPLATA. Za entitet ISPLATA se kaže da je karakterističan entitet, jer zavisi od entiteta
OSOBA (slika 3.21).
prima / je primio
OSOBA ISPLATA Karakteristi~ni
entitet
Slika 3.21. Veza karakterističnog entiteta ISPLATA i nezavisnog entiteta OSOBA
Asocijativni entiteti su sastavljeni od više veza između dva ili više entiteta, kao što se može
videti na slici 3.22. Npr., ako OSOBA zna više JEZIK-a i jedan JEZIK poznaje više OSOBA,
tada je CERTIFIKAT asocijativni entitet koji opisuje veza između entiteta: OSOBA i JEZIK.
Dakle, asocijativni entiteti nose informaciju o višeznačnoj vezi.
je dat/ vazi/
O SO BA poseduje odnosise JEZIK
Asocijativni
CERTIFIKAT entitet
Projektni entitet (designative) sličan je asocijativnom entitetu, s tim što nema sopstvene
atribute. U prethodnom primeru, CERTIFIKAT se može koristiti kao projektni entitet pod
uslovom da ne nosi nikakvu informaciju, izuzev identifikacionih oznaka za OSOBU i JEZIK.
Entitet kategorija (category) zavisan je entitet koji ima tzv. vezu tipa potkategoriju (sub-
-category). Kod entiteta tipa kategorija definišu se: nadređeni entitet koji ima zajedničke
osobine (npr., entitet OSOBA) i podređeni entiteti (entiteti: KONSULTANT i REDOVNI) koji
se identifikuju ključem nadređenog i poseduju svoje specifične osobine (slika 3.23).
OSOBA Generi~ki
entitet
Vrsta
KONSULTAN REDOVN
Entitet
alempije@beotel.yu 57
Definisanje veza
Za razliku od hijerarhijskih i mrežnih modela, gde se relacije prikazuju na fizičkom nivou
kao pointeri na slogove, relacioni model prikazuje relacije na logičkom nivou i te relacije se
zovu veze.
Kao što se u realnom svetu uspostavljaju određene veze između objekata, po istoj analogiji
se definišu i veze između entiteta. Veza je asocijacija između dva ili više entiteta, tj.
predstavlja odnos koji postoji među objektima, bilo u realnosti, ili u mislima. Veza u IDEF1X
metodologiji se prikazuje kao linija koja povezuje dva entiteta, sa tačkom na jednom kraju i
glagolskom frazom napisanom duž linije.
Entitet od koga je uspostavljena veza zove se 'roditelj' (parent), a entitet ka kome je
uspostavljena veza zove se 'dete' (child).
Veza 'roditelj'-'dete' je asocijacija između entiteta gde su svi primerci entiteta 'roditelj'
asocirani sa nula, jedan ili više primeraka entiteta 'dete', a svi primerci entiteta 'dete' su
asocirani sa nula ili jedan - primerkom entiteta 'roditelj'.
Drugim rečima, način povezivanja dva entiteta ima osobine koje se nazivaju kardinalnost,
koja pokazuje "koliko nečega" od dva entiteta može biti uključeno (sadržano).
Da bi se sve to bolje razumelo, poslužiće primer sa slike 3.24. Prvo treba definisati rečenicu
gde je glagol <koristi> veza između entiteta OSOBA i TELEFON.
koristi
TELEFON OSOBA
P
Slika 3.24. Primer relacije
Identifikujuće veze
Veza se zove identifikujuća zato što ključevi entiteta 'roditelj' predstavljaju deo identiteta
entiteta 'dete', tj. entitet 'dete' zavisi od entiteta 'roditelj' preko identifikatora. Dakle, ako se
primerak entiteta 'dete' identifikuje preko asocijacije sa entitetom 'roditelj', onda se veza
definiše kao identifikujuća veza, i svaki primerak entiteta 'dete' mora biti povezan sa
najmanje jednim primerkom entiteta 'roditelj'.
58 alempije@beotel.yu
Entitet-A
Kljuc atributa-A
Entitetroditelj
Identifikuju}a veza
Naziv veze
Entitet-B
Kljuc atributa-A (FK)
Kljuc atributa-B
Entitetdete
Neidentifikujuće veze
Ako se svaki primerak entiteta 'dete' može jedinstveno identifikovati, bez znanja veze sa
primerkom entiteta 'roditelj', onda se takva veza definiše kao neidentifikujuća veza.
Neidentifikujuće veze su prikazane isprekidanom linijom koja povezuje entitet 'roditelj' i
entitet 'dete' sa tačkom na strani entiteta 'dete'.
Entitet-A
Kljuc entiteta-A
Entitetroditelj
Obavezna neidentifikuju}a
veza
Naziv veze
Entitet-B
Kljuc atributa-B
Kljuc atributa-A (FK) Entitetdete
Neidentifikujuća ili slaba veza zavisi od načina definisanja ključeva od 'roditelj' ka 'dete'tu
na dva načina:
!" kao obavezna neidentifikujuća veza i
!" kao neobavezna (opciona) neidentifikujuća veza.
Ako je veza (relationships) obavezna (No Nulls ili Mandatory) iz perspektive 'roditelj', onda
je 'dete' egzistencijalno zavisno od 'roditelj' (slika 3.26). No nulls ili Mandatory znači da je
obavezan unos prenesenog ključa entiteta 'roditelj' u okviru entiteta 'dete' [Ključ entiteta A
(FK) slika 3.26].
Ako je veza neobavezna (Nulls Allowed ili Optional), tada 'dete' niti je egzistencijalno niti
identifikaciono zavisno, ali poštuje tu vezu. Null Allowed ili Optional znači da nije obavezan
(može biti Null) unos prenesenog ključa entiteta 'roditelj' u okviru entiteta 'dete' [Ključ
entiteta A (FK) slika 3.27].
alempije@beotel.yu 59
Entitet-A
Kljuc atributa-A
Entitetroditelj
Opciona neidentifikuju}a
veza
Naziv veze
Entitet-B
Kljuc atributa-B
Kljuc atributa-A (FK) Entitetdete
Veza kategorije
Veza kategorije je definisana za hijerarhijsku vezu između nadređenog generalizovanog
(generičkog) entiteta koji sadrži zajedničke osobine podređenih entiteta kategorije (slika
3.28).
Ovaj tip veze se deli na:
!" potpunu strukturu (tzv. kompletan set kategoriju) kada je zatvoren skup entiteta
kategorije;
!" nepotpunu strukturu (tzv. nekompletnu set kategoriju) kada nije zatvoren skup entiteta
kategorije.
Entitetikategorije Entitetkategorije
Neodređujuća veza
Neodređujuća veza je nespecificirana, a govori o tome da se jedan entitet (Entitet A)
pridružuje većem broju entiteta drugog tipa (Entitet B) i obrnuto (slika 3.29).
Veza od A prem a B
Entitet-A Entitet-B
Naziv veze/
Naziv veze
Veza od B prem a A
Ovaj tip veze zahteva, prema IDEF1X metodologiji, da se prevede uvođenjem asocijativnog
entiteta između entiteta A i entiteta B.
60 alempije@beotel.yu
Izvođenje prethodnih aktivnosti zahteva i odgovarajuću verifikaciju, što je objašnjeno u
sledećoj aktivnosti.
Aktivnost
2.2.4. Verifikacija ER dijagrama
Verifikacija ER dijagrama zahteva opštu proveru entiteta, i to: naziva, pojavljivanja,
zavisnosti i dr. Provera se izvodi pitanjima: šta ako..., imajući uvek u vidu da se to mora
obavezno izvoditi sa korisnicima. Za verifikaciju treba koristiti analogiju sa strukturom
teksta, kao što je prikazano na slici 3.30.
TEKST ER KONCEPT
IMENICA ENTITET
GLAGOL VEZA
PRIDEV ATRIBUT ENTITETA
PRILOG ATRIBUT VEZE
GLAGOL.IMENICA MESOVITI TIP ENTITETA-VEZA
RECENICA OBJEKTI POVEZANI VEZAMA
POGLAVLJE LOKALNI PODMODEL
Slika 3.30. Analogija teksta i ER koncepta
alempije@beotel.yu 61
(OSOBA je rukovodilac više
OSOBA)
Poslovna pravila 'roditelj' počinju rečenicom u kojoj je naziv entiteta 'roditelj' na početku
rečenice, a naziv entiteta 'dete' na kraju.
62 alempije@beotel.yu
one OSOBA. najmanje jedna i najviše jedna
OSOBA.
(CERTIFIKAT poseduje tačno
jedna OSOBA).
A ZENA is a type of OSOBA. ZENA je tip ili specijalizacija
entiteta OSOBA.
(ZENA je tip OSOBE).
Poslovna pravila 'dete'ta počinju rečenicom u kojoj je naziv entiteta 'dete'ta na početku
rečenice, a naziv entiteta 'roditelj' na kraju.
pripada / zaposljava /
JEZIK RADNO M ESTO ODELJENJE
rasporedjen radi
vazi/ P
odosise prim a /
OSOBA ISPLATA
je prim io
je dat/ rukovodi /
CERTIFIKAT poseduje je rukovodioc
Pol Vrsta
ER dijagram prikazan na slici 3.31. predstavlja rezultat, sa jedne strane, analize dokumenta
"Karton isplata" (prikazanog na slici 2.5. - pogled odozdo) i sa, druge, rezultat želja i
potreba za informacijama, dobijenih na osnovu sprovedenog intervjua (pogled odozgo).
alempije@beotel.yu 63
Aktivnost
2.3. Kreiranje atributa
Svaki objekat realnog sveta je definisan osobinama, pa po toj analogiji i entiteti imaju
atribute kojima se opisuju karakteristična svojstva. U okviru aktivnosti "2.3. Kreiranje
atributa" definisane su sledeće podaktivnosti:
!" Aktivnost 2.3.1. Definisanje lista kandidata za atribute,
!" Aktivnost 2.3.2. Definisanje ključeva,
!" Aktivnost 2.3.3. Postupak normalizacije,
!" Aktivnost 2.3.4. Definisanje atributa.
Na slici 3.32. prikazan je dekompozicioni dijagram za aktivnost "2.3. Kreiranje atributa".
Verifikovani USVAJANJE
ER model sa
ER model LISTA
atributima
I1 KANDIDATA
ZA ATRIBUTE
2.3.1
Klju~evi za
DEFINISANJE ER model
KLJU^EVA
2.3.2
Nomalizovan
POSTUPAK atributivni model
NORMALIZACIJE
2.3.3 Verifikovani
Informacije DEFINISANJE atributivni m
od korisnika ATRIBUTA O1
I2
2.3.4
Radna
grupa
M1
64 alempije@beotel.yu
Aktivnost
2.3.1. Definisanje liste kandidata za
atribute
Ulaz u aktivnost "2.3.1. Definisanje liste kandidata za atribute" je verifikovani ER model,
koji u okviru ove aktivnosti kao izlaz ima ER model sa atributima.
Da bi se definisala lista kandidata za atribute, mora se dati odgovor na pitanje šta je interes
posmatranja. Da li će po nekoj osobini objekat biti entitet ili atribut, tj. koju će ulogu imati,
zavisi od pogleda koji se želi predstaviti.
Osnovna pravila koja se koriste u realizaciji aktivnosti "2.3.1. Definisanje liste kandidata za
atribute" su:
!" Svaki entitet ima proizvoljan broj atributa, što znači da nema ograničenja u broju
atributa.
!" Određeni atribut pripada jednom i samo jednom entitetu, tako da isti atribut ne može
biti opisan u okviru dva ili više entiteta.
!" Svako pojavljivanje entiteta ima vrednosti za sve atribute tog entiteta.
!" Atribut određenog pojavljivanja entiteta može imati samo jednu vrednost, pa primerak
entiteta za određeni atribut ima jednu vrednost.
!" Svaki atribut predstavlja jednu određenu činjenicu, tako da i svako značenje vrednosti
atributa mora imati jedno dosledno značenje.
Na osnovu definisane liste kandidata za atribute u sledećem koraku biće definisani svi tipovi
ključeva.
Aktivnost
2.3.2. Definisanje ključeva
Aktivnost "2.3.2. Definisanje ključeva" ima zadatak da za svaki entitet bude definisan
atribut ili kombinacija atributa, čije vrednosti jedinstveno identifikuju svaki primerak
entiteta.
Taj atribut ili grupa atributa naziva se primarni ključ. Ako ključ čini samo jedan atribut,
onda je prost ključ; u suprotnom je složen. Kao što se vidi na slici 3.33, atributi mogu biti
definisani u oblasti ključeva (primarni ključ) ili u oblasti podataka.
Na primeru prikazanom na slici 3.33. entitet OSOBA je predstavljen crtanjem pravougaonika
sa imenom entiteta na vrhu i svim atributima u okviru pravougaonika. Atribut "Sifra osobe"
je u oblasti ključa, a svi ostali atributi su u oblasti podataka.
alempije@beotel.yu 65
Struktura atributa Primer
Naziv entiteta OSOBA
Naziv atributa Sifra osobe
[Naziv atributa] } Oblast
Prezime
kljuceva
Ime
Naziv atributa] JMBG
[Naziv atributa]
[Naziv atributa]
} Oblast Plata
podataka Stimulacija
Datum zaposlenja
Primarni ključ
Atributi ili grupe atributa koji mogu biti izabrani kao primarni ključevi nazivaju se 'atributi
kandidati za ključ'. Kandidat za ključ mora jedinstveno da identifikuje svaki primerak
entiteta. Iz toga sledi da nijedan deo primarnog ključa ne može biti NULL, odnosno prazan
(empty) ili nedostajući (missing). Od kandidata za ključeve bira se jedan koji se naziva
primarni ključ.
Osnovno pitanje koje se postavlja jeste kako izabrati primarni ključ kojim se identifikuje
jednoznačno entitet. Izbor ključa nekog entiteta može biti jedan atribut kojim se definiše
jednostavni primarni ključ ili kombinacija atributa kojom se definiše složeni primarni ključ.
Ako se pogleda entitet OSOBA sa slike 3.33, atributi su:
!" Sifra osobe !" Plata
!" JMBG !" Stimulacija
!" Prezime !" Datum zaposlenja
!" Ime
Neka je, na primer, atribut 'Sifra osobe' prvi kandidat za ključ, zato što je jedinstven za
svaku osobu. Sledeći atribut JMBG bi mogao da bude kandidat za ključ ako su pretpostavke
o jedinstvenosti broja korektne. Međutim, verovatno je da neće sve osobe imati JMBG, jer
treba koristiti usluge i stranaca. Mada se na prvi pogled čini da ovaj atribut može biti
kandidat za ključ, treba ga ostaviti po strani. Sledeći atributi 'Ime i Prezime' ne bi mogli da
budu dobar kandidat za ključ, jer mogu postojati dva Zorana Petrovića.
Kombinacija 'Ime i Prezime' i 'Datum zaposlenja' mogla bi biti kandidat za ključ (osim ako
ne postoje, npr., dva Zorana Petrovića zaposlena istog dana).
Premda je to nekorektno, neka u ovom primeru kombinacija 'Ime i Prezime' i 'Datum
zaposlenja' određuju specifičnu osobu. Tako je dobijen drugi kandidat za ključ: kombinacija
'Ime i Prezime' i 'Datum zaposlenja'.
Dakle, dobijena su dva kandidata za ključ: jedan je 'Sifra osobe' a drugi je grupa atributa
koja sadrži atribute: 'Ime i Prezime' i 'Datum zaposlenja' i sada treba izabrati primarni ključ.
Koji će od ova dva kandidata biti izabran za primarni ključ zavisi od analize koja se sprovodi
na sledeći način:
!" Prvo i najvažnije prilikom izbora primarnog ključa je naći atribut koji neće menjati
vrednost za vreme 'života' svakog primerka entiteta, jer ključ određuje identitet
primerka entiteta (ako se promeni ključ, to je već drugi primerak). Ovaj uslov
66 alempije@beotel.yu
ispunjavaju i jedan i drugi kandidat za ključ.
!" Drugo, treba tražiti razumno male ključeve. Ako se može naći jedan atribut, generalno
gledano, pronađen je dobar ključ. Taj uslov ispunjava prvi kandidat za ključ.
!" Treće, potrebno je izbegavati upotrebu 'inteligentnih' ključeva (na primer, gde struktura
brojeva identifikuje grupisanje, lociranje, klasifikaciju, datume itd.). Taj uslov ispunjava
prvi kandidat za ključ, jer njegova šifra je neimenovani identifikacioni broj.
Na osnovu ovako obrazloženih elemenata za izbor primarnog ključa za entitet 'OSOBA' bira
se atribut 'Sifra osobe' kao primarni ključ, jer zadovoljava sva tri definisana kriterijuma.
OSOBA
Sifra osobe
Prezime (IE1)
Ime (IE1)
JMBG (AK1)
Plata
Stimulacija
Datum zaposlenja
alempije@beotel.yu 67
Preneseni ključevi
Preneseni ključ je kolekcija atributa koji u posmatranom entitetu nisu ključ, ali su zato ključ
u nekom drugom entitetu. Preneseni ključ (Foreign Key) jeste atribut koji povezuje entitet
'dete' sa entitetom 'roditelj' i određen je oznakom FK, koja dolazi iza imena atributa.
OSOBA
Sifra osobe
Entitetroditelj
M igracija
prim a
Isplata
Sifra osobe(FK)
rednibroj
Entitetdete
(Identifik.zavisnost)
Na slici 3.35. prikazan je postupak migracije primarnog ključa entiteta OSOBA (entitet
'roditelj') u entitet ISPLATA (entitet 'dete'), tj. veza prenosi ključ entiteta 'roditelj' u entitet
'dete'.
Kada se vrši migracija ključeva, tj. povezivanje entiteta, može se dogoditi i situacija
prikazana na slici 3.36, gde se pojavljuje i redundantna veza koju treba izbrisati.
ODELJAK Redundantna
Odeljak br veza
im a
im a
ODELJENJE
Sifra
Odeljak br (FK) im a
OSOBA
Sifra osobe
Sifra (FK)
Odeljak br (FK)
Kao što se na slici 3.37. vidi, migracija ključeva može biti u oblasti opisa i tada je u pitanju
neidentifikujuća veza (označena isprekidanom linijom kao na slici 3.36) ili, pak, u oblasti
ključeva, kada je u pitanju identifikujuća veza (označena punom linijom kao na slici 3.35).
68 alempije@beotel.yu
Migracija u oblasti opisa Migracija u oblasti ključeva
OSOBA ISPLATA
Sifra osobe Sifra osobe (FK)
Prenesenikljuc
rednibroj
Prenesenikljuc Sifra odeljenja (FK) (Foreign Key)
(Foreign Key)
Preneseni ključevi mogu imati i drugo ime, što se definiše kao uloga atributa u entitetu. Ime
uloge (Rolename) predstavlja novo ime za prenesene ključne atribute koji definišu ulogu
koju ti atributi igraju u tom entitetu. Ime uloge deklariše novi atribut, čije ime treba da
opiše poslovno pravilo ugrađeno preko veze koja zahteva preneseni ključ (slika 3.38).
Definisanje imena uloge biće pokazano na primeru definisanja strukture proizvoda.
PRO IZVO D
Identbroj
Kako entitet STRUKTURA ima složeni ključ od istog nadređenog entiteta PROIZVOD, to se
definisanjem uloge definišu različita imena atributa i identifikuje entitet STRUKTURA.
Imajući sve to u vidu, za primer ER modela dokumenta "Karton isplata", u sledećem koraku
biće izvršeno definisanje primarnih ključeva.
alempije@beotel.yu 69
JEZIK RADNO MESTO pripada / zaposljava / ODELJENJE
Sifra jezika Sifrarm rasporedjen P radi Sifra odeljenja
vazi / ISPLATA
OSOBA prima /
odosi se Sifra osobe (FK)
Sifra osobe je primio
rbr
CERTIFIKAT
rukovodi /
Sifra osobe (FK) je dat /
je rukovodilac
Sifra jezika (FK) poseduje
Vrsta
Pol
Aktivnost
2.3.3. Postupak normalizacije
Prilikom definisanja atributa, kao što je rečeno, pristupa se modeliranju podataka odozdo
nagore (Bottom Up). Ovaj pristup veoma je prihvatljiv za početnike u ovoj oblasti, jer polazi
od opipljivih informacija definisanih na dokumentima i u kartotekama. Osnovu za ovaj način
modeliranja podataka čine analiza funkcionalnih zavisnosti i postupak normalizacije.
Ako je svakoj vrednosti atributa A u relaciji R priključena samo jedna vrednost atributa B u
istoj relaciji, onda je atribut B funkcijski zavisan od atributa A asocijacijom tipa 1.
Ako se svakom paru vrednosti atributa A i B relacije R može priključiti tačno jedna vrednost
C iste relacije, tada je atribut C funkcijski zavisan od sastavljenog atributa A i B.
Atribut B je potpuno funkcijski zavisan od atributa A iste relacije, ako je funkcijski zavisan
od atributa A, a ne od nekog sastavnog dela atributa A.
Na osnovu ovako izvedenih definicija na primeru entiteta OSOBA biće pokazan postupak
normalizacije kroz definisanje prve (1NF), druge (2NF) i treće (3NF) normalne forme.
70 alempije@beotel.yu
Definisanje prve normalne forme (1NF)
Može li se na osnovu posmatranja entiteta OSOBA (sa slike 3.40) uočiti greška?
Zbog lakšeg razumevanja, treba prevesti entitet OSOBA u tabelu sa definisanim primercima
(koristi se i termin instance).
OSOBA
Sifra osobe
Prezime(IE1)
Ime (IE1)
JMBG (AK1)
Plata
Stimulacija
Datum zaposlenja
Isplate
OSOBA
Sif.oso Prezime Ime JMBG Plata Stimu Dat.zapos. Isplate
827369 STEVIC ZORAN 141195271033 8000 0 17.12.80 200,300
827499 ALAGIC MILAN 250396534561 16000 3000 20.02.81 400
827521 VUKIC MILOS 130497055432 12500 5000 22.02.81 800,300
827566 JOVIC MARA 151195671034 29750 0 02.04.81
827654 MARTIC ZORA 240696534531 12500 1400 28.09.81 200,100
827698 BOBIC IVAN 230495055432 28500 0 01.05.81
827782 CEBIC GORAN 231195271044 24500 0 09.06.81
827788 SUSIC ZORAN 110396534561 30000 0 09.06.86 3000,20
827839 KLJAKIC STEVA 140497055432 50000 0 17.11.81
827844 TUBIC MIRA 161195671034 15000 0 08.09.81
827876 ALIMPIC PETAR 270696534531 11000 0 19.09.87
827900 JAKIC VLADA 290495055432 9500 0 03.12.81 300,400
827902 FILIPIC DRAGA 130597055482 30000 0 03.12.81
alempije@beotel.yu 71
OSOBA
Sifra osobe ISPLATA
Prezime Sifra osobe (FK)
Ime prima / je primio rbr
JMBG
Datum isplate
Plata
Iznos
Stimulacija
Datum zaposlenja
Prikaz dat na slici 3.42. preveden u tabele OSOBA i ISPLATA sa definisanim instancama
(slika 3.43) izgleda ovako:
OSOBA
Sif oso Prezime Ime JMBG Plata Stim Datum
827369 STEVIC ZORAN 141195271033 8000 0 17.12.80
827499 ALAGIC MILAN 250396534561 1600 300 20.02.81
827521 VUKIC MILOS 130497055432 1250 500 22.02.81
827566 JOVIC MARA 151195671034 2975 0 02.04.81
827654 MARTIC ZORA 240696534531 1250 140 28.09.81
827698 BOBIC IVAN 230495055432 2850 0 01.05.81
827782 CEBIC GORAN 231195271044 2450 0 09.06.81
827788 SUSIC ZORAN 110396534561 3000 0 09.06.86
827839 KLJAKIC STEVA 140497055432 5000 0 17.11.81
827844 TUBIC MIRA 161195671034 1500 0 08.09.81
ISPLATA
Sifra osobe rbr Datum Iznos
7369 1 12.12.97 2.433,00
7369 2 12.11.97 2.322,00
7521 1 10.10.97 212
7521 2 11.11.97 232
7521 3 11.12.97 2.122
Pošto je otkrivena grupa podataka koji se ponavljaju i od njih stvoren novi entitet ISPLATA,
time je učinjen prvi korak prema normalizovanom modelu.
Kao još jedan primer vezan za definisanje prve normalne forme, treba navesti slučaj koji se
najčešće pojavljuje - višeznačna upotreba istog atributa, gde se jednim atributom, npr.,
"Dat_zap ili Dat_odlaska" (slika 3.44) definišu dve činjenice.
OSOBA
Sifra osobe
Prezime
Ime
Dat_zap_ili_dat_odlaska
72 alempije@beotel.yu
OSOBA
Sif osobe Prezime Ime Dat zapos ili dat odlaska
827369 STARCEVI ZORAN 17.12.80; 12.12. 1995
827499 ALAGIC MILAN 20.02.81
827521 VUKIC MILOS 22.02.81
827566 JOVIC MARA 02.04.81
827654 MARTIC ZORA 28.09.81
827698 BOBIC IVAN 01.05.81;13.09.1990
827782 CEBIC GORAN 09.06.81
827788 SUSIC ZORAN 09.06.86
827839 KLJAKIC STEVAN 17.11.81
827844 TUBIC MIRA 08.09.81;14.05.1987
OSOBA
Sifra osobe
Prezime
Ime
Dat_zap_
Dat_odlaska
alempije@beotel.yu 73
mu je dodeljeno ime uloge svaki put.
Sprečavajući da se višestruko koristi isto ime, ERwin vodi korisnika da svaki podatak smesti
tačno na jedno mesto.
Međutim, potrebna je dalja analiza, jer prva normalna forma nije dovoljna pa se prelazi na
definisanje druge normalne forme.
Na primer, bila bi povređena treća normalna forma ako se u entitet ISPLATA ugradi atribut
'Suma isplata'. 'Suma isplata' zavisi od atributa 'Isplata' i može se izračunati.
Pored ovih formi postoje i četvrta i peta i Boyce-Codd-ova forma, a njihova upotreba zavisi
od skupa transakcija koje treba izvršiti i ovde se neće razmatrati.
Na osnovu prethodno izvedenih aktivnosti (slika 3.32) u sledećem koraku treba definisati
atribute.
74 alempije@beotel.yu
Aktivnost
2.3.4. Definisanje atributa
Definisanje atributa se izvodi u tri koraka:
!" identifikacijom atributa,
!" alociranjem atributa i
!" revizijom atributa.
Identifikacija atributa se definiše na osnovu zahteva korisnika i poslovne dokumentacije.
Alociranje atributa se izvodi u zavisnosti od toga da li atribut zavisi od ključa ili je opisni.
Revizijom atributa se eliminiše višestruko nastupanje vrednosti atributa pojedinog entiteta i
pri tom se za svaki atribut postavljaju pitanja:
!" da li je potrebno tražiti višestruke vrednosti za isto pojavljivanje entiteta (Sifra
odeljenja, Naziv odeljenja);
!" da li atribut može pripadati nekom drugom entitetu;
!" da li postoje atributi koji ne nastupaju za neko pojavljivanje entiteta;
!" da li postoje izvedeni atributi (koje treba ili odstraniti ili dodati);
!" da li postoje atributi bez entiteta;
!" da li je prikladan identifikator/ ključ.
Za atribute se mogu definisati :
!" set vrednosti,
!" pravila dozvoljenih vrednosti,
!" null vrednosti,
!" dosledno značenje, tj. međusobno isključivanje (npr., Atribut: Pol; Vrednost: muškarac,
žena).
Pravila za definisanje atributa biće definisana u sledećem poglavlju, kao tzv. poslovna
pravila.
alempije@beotel.yu 75
Aktivnost
2.4. Definisanje poslovnih pravila
Verifikovani
atributivnimodel DEFINISANJE
I1 Verifikovaneardinalnosti
KARDINALNOSTI
VEZA
2.4.1
DEFINISANJE
REFERENCIJALNIH Dodatireferencijalniintegriteti
INTEGRITETA
2.4.2
Glavni
IDENTIFIKACIJA projekat
Informacije Poslovnidomen
POSLOVNOG
odkorisnika O1
DOMENA
I2
2.4.3
Radna
grupa
M1
Definisanje poslovnih pravila vezano je za tzv. strukturna dinamička pravila integriteta koja
se definišu uređenom trojkom:
<Ograničenje, Operacija , Akcija>
Strukturna dinamička pravila integriteta su:
!" ograničenja kojima se definišu dozvoljena stanja baze podataka,
!" operacije koje mogu potencijalno ugroziti ograničenja i
!" akcije koje treba preduzeti ukoliko dođe do narušavanja ograničenja.
Ograničenja
Ograničenja se posmatraju preko:
!" strukturnih ograničenja,
!" ograničenja nad standardnim domenom,
!" ograničenja nad vrednošću domena i
76 alempije@beotel.yu
!" ograničenja na kardinalnost.
Ograničenja su strukturna ukoliko su prikazana strukturom modela podataka, što se, pre
svega, odnosi na:
!" integritet entiteta - gde ne mogu da postoje dva primerka entiteta u istom tipu entiteta
tako da imaju istu vrednost atributa koji čine identifikator, tj. ne postoje dva tipa
entiteta koji imaju isti skup atributa kao identifikator;
!" referencijalni integritet, gde se definišu:
• ograničenje postojanja (egzistencijalna zavisnost) jednog entiteta u zavisnosti od
drugog entiteta;
• ograničenje mogućnosti identifikacije jednog objekta bez poznavanja identifikatora
nekog drugog objekta;
• specijalni tipovi veze kojima se definišu podtipovi egzistencijalno i identifikaciono,
zavisno od nadređenog generalizovanog entiteta.
Ograničenja nad standardnim domenom definišu se, npr, kao:
!" tip podatka (character, numeric, boolen),
!" dužina podatka CHARACTER (30) i dr.
Ograničenja nad vrednošću domena (vrednost atributa) mogu se podeliti na:
!" operatore poređenja (<,>, =, >=, <=);
!" IN listu vrednosti koja formira listu konstanti iz odgovarajućeg domena, eksplicitnim
navođenjem svih dozvoljenih vrednosti (npr., Stepen IN ['G,P,C']);
!" BETWEEN opseg dozvoljenih vrednosti, gde atributi objekata i veza uzimaju vrednosti iz
domena, ali uz postavljena ograničenja na ove vrednosti, tako da atribut može poprimiti
samo uži skup vrednosti iz domena (npr., BETWEEN 10 AND 200);
!" NOT NULL kada dato polje ne može da dobije nula vrednost, tj. mora uvek da ima neku
vrednost.
Ograničenja na kardinalnost veza definišu se između:
!" entiteta 'roditelj' i entiteta 'dete' i to kao:
• kardinalnost tipa Zero, One or More, gde se jedan primerak entiteta 'roditelj'
pridružuje nijednom, jednom ili većem broju primeraka entitetu 'dete';
• kardinalnost tipa One or More (P), gde se jedan primerak entiteta 'roditelj' pridružuje
najmanje jednom ili većem broju primeraka entiteta 'dete';
• kardinalnost tipa Zero or One (Z), gde se jedan primerak entiteta 'roditelj' pridružuje
nijednom ili jednom primerku entiteta 'dete';
• kardinalnost tipa konkretne vrednosti (Exactly), gde se jedan primerak entiteta
'roditelj' pridružuje tačno definisanom broju primeraka entiteta 'dete'.
!" entiteta 'dete' prema entitetu 'roditelj' kao:
• TOTALNO učešće, gde svi primerci entiteta 'dete' učestvuju bar u jednoj vezi (No
Nulls) sa entitetom 'roditelj';
• PARCIJALNO (delimično) učešće, gde samo pojedini primerci entiteta 'dete' učestvuju
u vezi (Nulls Allowed) sa entitetom 'roditelj'.
Operacije
Operacije koje potencijalno ugrožavaju ograničenja su standardne operacije ažuriranja, tzv.
IRD operacije, što je skraćenica od:
!" ubacivanje novog sloga (Insert),
alempije@beotel.yu 77
!" izmena sloga (Replace) i
!" brisanje sloga (Delete).
Operacija ubacivanje (insert) omogućuje sledeća dodavanja podataka:
!" kreira objekat i proverava da li je vrednost ključa objekta moguća ili već postoji objekat
sa tom vrednošću;
!" kreira vezu i proverava da li postoje objekti sa datim vrednostima ključa;
!" dodaje vrednost objektu ili vezi i proverava da li je ta vrednost dozvoljena.
Akcije
Za iskazivanje strukturnih pravila integriteta, tj. za iskazivanje potpune specifikacije buduće
baze podataka, definišu se akcije koje treba preduzeti kada neka operacija ažuriranja baze
podataka naruši definisano ograničenje.
78 alempije@beotel.yu
Aktivnost
2.4.1. Definisanje kardinalnosti veza
S obzirom na to da su u prethodnom poglavlju navedeni tipovi veza, trebalo bi sada izneti
njihove osobine. Naime, veze (relationships) imaju osobinu koja se zove kardinalnost
preslikavanja, koja definiše:
!" kardinalnost preslikavanja 'roditelj'-'dete' i
!" kardinalnost preslikavanja 'dete'-'roditelj'.
Kardinalnost preslikavanja 'roditelj'-'dete' definiše "koliko mnogo" instanci entiteta 'roditelj'
je povezano sa "koliko mnogo" instanci entiteta 'dete'. Po IDEF1X metodologiji, definišu se
četiri načina definisanja kardinalnosti preslikavanja 'roditelj'-'dete':
!" Zero , One or More - bez oznake
• Svaki 'roditelj' povezuje se sa nula, jednom ili više instanci 'dete';
!" One or More - označen slovom "P"
• Svaki 'roditelj' povezuje se sa jednom instancom ili više instanci 'dete';
!" Zero or One - označen slovom "Z"
• Svaki 'roditelj' povezuje se sa nula ili jednom instancom 'dete';
!" Tačno n - gde je n broj
• Svaki 'roditelj' povezuje se sa tačno n instanci 'dete'.
Kardinalnost preslikavanja 'dete'-'roditelj' definiše se kao:
!" kardinalnost preslikavanja gde je dozvoljena null vrednost stranog ključa (Nulls
Allowed), što je moguće samo za neidentifikujuće veze i obeležava se (sa strane
'roditelj') romboidom;
!" kardinalnost preslikavanja gde nije dozvoljena null vrednost stranog ključa (No Nulls).
Na slici 3.50. prikazane su opcije prilikom definisanja kardinalnosti preslikavanja.
U daljem tekstu biće prikazane sve varijante kardinalnosti preslikavanja za sledeće tipove
veza:
!" identifikujuće veze,
!" neidentifikujuća veza ,
!" rekurzivna veza,
!" veza kategorije,
!" neodređujuća veza tipa više prema više i
!" N-arne veze.
alempije@beotel.yu 79
Kardinalnost identifikujućih veza
Kod identifikujućih veza ključevi entiteta 'roditelj' učestvuju u identifikovanju entiteta 'dete',
tj. svaka instanca entiteta 'dete' mora biti povezana sa najmanje jednom instancom entiteta
'roditelj'. Identifikujuće veze su prikazane punom linijom koja povezuje entitet 'roditelj' i
entitet 'dete' sa tačkom na entitetu 'dete' (slika 3.51). Ovakav tip veze govori da je entitet
'dete' identifikujući, zavisno od entiteta 'roditelj'.
DETE(CHILD)
RODITELJ(PARENT)
Dete kljuc
sadrzi / Roditelj kljuc
Roditelj kljuc (FK)
je sadrzano
Sledeće varijante tipova kardinalnosti identifikujućih veza biće prikazane na primeru entiteta
ODELJENJE ('roditelj') i entiteta OSOBA ('dete'), imajući u vidu opcije prikazne na slici 3.50.
gde je fiksirana opcija 'dete'-'roditelj' na No Nulls (ONE).
One-to-Zero-One-or-More
OSOBA
ODELJENJE
Sifra osobe zaposljava /Sifra odeljenja OSOBA radi u jednom(One) ODELJENJU.
Sifra odeljenja (FK) radi ODELJENJE zaposljava nijednu(Zero),
jednu(One) ili vise(More) OSOBA.
Slika 3.52. Kardinalnost veze tipa One-to-Zero-One-or-More
Ova veza govori da Odeljenje nema nijednu zaposlenu Osobu, ili ima jednu ili više
zaposlenih Osoba. Kako je to identifikujuća veza, OSOBA zavisi od ODELJENJA, pa se
OSOBA ne može identifikovati ukoliko identifikator entiteta ODELJENJA nije poznat. Dakle,
entitet OSOBA egzistencijalno zavisi od entiteta ODELJENJE. Ovaj tip identifikujuće veze se
preporučuje za korišćenje, jer je najmanje ograničavajući.
OSOBA ODELJENJE
zaposljava / One-to -One-or-More(P)
Sifra osobe Sifra odeljenja
Sifra odeljenja (FK) radi OSOBA radi u jednom(One) ODELJENJU.
P ODELJENJE zaposljava, jednu(One)
ili vise(More) OSOBA.
Slika 3.53. Kardinalnost veze tipa One-to-One-or-More (P)
Ova veza zahteva da Odeljenje mora (One-P) da zapošljava bar jednu Osobu, a može i više
(More). Kako je to identifikujuća veza, entitet OSOBA je zavisan od entiteta ODELJENJE, pa
se OSOBA ne može identifikovati ukoliko identifikator entiteta ODELJENJE nije poznat.
Dakle, OSOBA zavisi od entiteta ODELJENJE (isključena je opcija Nulls).
80 alempije@beotel.yu
gde OSOBA zavisi od ODELJENJA, kardinalnost je prikazana na slici 3.54.
One-to-Zero-or-One(Z)
OSOBA
ODELJENJE
Sifra osobe zaposljava / OSOBA radi u jednom(One) ODELJENJU.
Sifra odeljenja (FK) radi Sifra odeljenja
ODELJENJE zaposljava nijednu(Zero) ili
Z jednu(One) OSOBA.
Slika 3.54. Kardinalnost veze tipa One-to-Zero-or-One (Z)
Ova veza govori da Odeljenje ne mora (Zero) da zapošljava nijednu osobu ili zapošljava
samo jednu Osobu (One). Kako je to identifikujuća veza, entitet OSOBA je zavisan od
entiteta ODELJENJE, pa se OSOBA ne može identifikovati ukoliko identifikator entiteta
ODELJENJE nije poznat. Dakle, entitet OSOBA je zavisan od entiteta ODELJENJE (isključena
je opcija Nulls).
One-to-Exactly 4
OSOBA
ODELJENJE OSOBA radi u jednom(One) ODELJENJU.
Sifra osobe zaposljava /
Sifra odeljenja ODELJENJE zaposljava tacno(Exactly)
Sifra odeljenja (FK) radi
n OSOBA.
4
Ova veza omogućuje da osoba radi samo u jednom Odeljenju (One), dok u obrnutoj vezi
odeljenje zapošljava tačno n osoba. Kako je to identifikujuća veza, entite OSOBA je zavisan
od entiteta ODELJENJE, pa se OSOBA ne može identifikovati ukoliko identifikator entiteta
ODELJENJE nije poznat. Dakle, entitet OSOBA je zavisan od entiteta ODELJENJE (isključena
je opcija Nulls).
Ako je veza neobavezna (Nulls Allowed), tada 'dete' nije egzistencijalno zavisno, ali poštuje
tu vezu i grafički se predstavlja rombom (slika 3.57).
alempije@beotel.yu 81
DETE (CHILD) RODITELJ (PARENT)
Dete kljuc sadrzi / Roditelj kljuc
Roditelj kljuc (FK) je sadrzano
Ako je svako ODELJENJE (PARENT) povezano sa nula, jednom ili više instanci OSOBA
(CHILD), gde OSOBA može, a ne mora da pripada ODELJENJU, kardinalnost je prikazana na
slici 3.58.
OSOBA
ODELJENJE
Sifra osobe Zero(Nulls Allowed)- or-One-to-Zero-One-or-More
zaposljava /Sifra odejlenja
Sifra odeljenja (FK) radi
OSOBA radi u nijednom(Zero) ili jednom (One)
ODELJENJU.ODELJENJE zaposljava nijednu(Zero),
jednu(One) ili vise(More) OSOBA.
Ova veza dozvoljava da Osoba ne radi u nijednom (Nulls Allowed) Odeljenju ili da radi u
jednom Odeljenju. U Odeljenje može biti neraspoređena (veza zapošljava) nejedna (Zero),
ili raspoređena jedna (One) ili više (More) Osoba. Ova veza je najmanje ograničavajuća, jer
omogućuje definisanje 'roditelj' (ODELJENJE) i 'dete' (OSOBA) bez ograničenja i međusobnih
zavisnosti.
Ako je svako ODELJENJE (PARENT) povezano sa nula, jednom ili više instanci OSOBA
(CHILD), gde OSOBA mora da pripada ODELJENJU, kardinalnost je prikazana na slici 3.59.
Ova veza dozvoljava da Osoba mora da radi u jednom (No Nulls) i samo jednom Odeljenju.
U Odeljenje može biti raspoređena (veza zapošljava) nejedna (Zero), jedna (One) ili više
(More) Osoba.
82 alempije@beotel.yu
OSOBA. ODELJENJE Zero(Nulls Allowed)-or-One-to -One-or-More(P)
Sifra osobe zaposljava Sifra
/ odeljenja, OSOBA radi u nijednom(Zero) ili jednom (One)
Sifra odeljenja, (FK) radi ODELJENJU. ODELJENJE zaposljava,
P jednu(One) ili vise(More) OSOBA.
Slika 3.60. Kardinalnost veze tipa Zero(Nulls Allowed)-or-One-to-One-or-More(P)
Ova veza dozvoljava da Osoba može da ne radi u nijednom (Nulls Allowed) Odeljenju ili da
radi u jednom Odeljenju. U Odeljenje mora biti raspoređena (veza zapošljava) najmanje
jedna (One-P) ili više (More) Osoba. Ova veza je ograničavajuća, jer zahteva da u Odeljenju
mora biti najmanje jedna Osoba, dok definisanje podataka o Osobama ne zavisi od
Odeljenja u kome će biti.
Ova veza zahteva da Osoba mora da radi u jednom (No Nulls) i samo jednom Odeljenju. U
Odeljenje mora biti raspoređena (veza zapošljava) najmanje jedna (One-P) ili više (More)
Osoba. Ova veza je ograničavajuća jer zahteva da u odeljenju mora biti najmanje jedna
Osoba i da ta Osoba radi isključivo u jednom odeljenju. Ova veza zahteva programsko
rešenje vezano za brisanje poslednje Osobe.
Ova veza dozvoljava da Osoba može da radi u nijednom (Nulls Allowed) ili jednom
Odeljenju. U Odeljene može biti raspoređena (veza zapošljava) nijedna (Zero) ili jedna
(One) Osoba.
alempije@beotel.yu 83
Ova veza dozvoljava da Osoba mora da radi u jednom (No Nulls) i samo jednom Odeljenju.
U Odeljenje može biti raspoređena (veza zapošljava) nijedna (Zero) ili jedna (One) Osoba.
Zero(Nulls Allowed)-or-One-to-Exactly 4
OSOBA ODELJENJE OSOBA radi u nijednom ili
Sifra osobe
zaposljava / Sifra odeljenja jednom(One) ODELJENJU.
Sifra odeljenja (FK) radi ODELJENJE zaposljava
4 tacno(Exactly)4 OSOBE.
Ova veza dozvoljava da Osoba može da radi u nijednom (Nuls Allowed) ili jednom
Odeljenju. U Odeljenje može biti raspoređeno (veza zapošljava) tačno n Osoba.
Ova veza dozvoljava da Osoba mora da radi u Odeljenju. U Odeljenje može biti raspoređeno
(veza zapošljava) tačno n Osoba.
84 alempije@beotel.yu
preneseni ključevi mogu biti NULL podatak.
je rukovodjena /
je rukovodilac
Rekurzija nad dve tabele ili rekurzija mrežnog tipa (još se zove i dvotabelarna rekurzija)
predstavlja vezu 'roditelj'-'dete', gde 'roditelj' može imati veći broj dece i 'dete' može imati
veći broj roditelja. To je specijalni slučaj 'Many-to-Many' veze nad samim sobom i treba je
razbiti na dve veze 1:M. Stoga i u tom slučaju treba definisati Rolename da bi se predstavilo
prenošenje ključeva. U tom slučaju definišu se identifikujuće veze i atribut ključevi sa NOT
NULL vrednostima.
Na slici 3.67. prikazana je tipična rekurzija mrežnog tipa, gde se rekurzija definiše nad dva
entiteta PROIZVOD i STRUKTURA. Entitet PROIZVOD sadrži instance vezane za proizvode,
sklopove, podsklopove, delove, materijale i dr. Entitet STRUKTURA povezuje proizvod sa
odgovarajućim podređenim sklopovima, a te sklopove sa podređenim podsklopovima i tako
redom do delova i materijala. To je osnova za definisanje tzv. sastavnica proizvoda.
STRUKTURA
PROIZVOD je komponenta za Komponenta br.Ident broj (FK) Zero(Nulls Alloved)- or-One-to-Zero-One-or-More
Ident broj Sastav br.Ident broj (FK) Nijedna(Zero) ili jedna (One) OSOBA rukovodjena sa
nula(Zero), jednom(One) ili vise(More) OSOBA.
je sastavljena od OSOBA je rukovodilac nijednoj(Zero),
jednoj(One) ili vise(More) OSOBA.
Veza kategorije
Veza kategorije uspostavlja vezu između nadređenih entiteta i njegovih zavisnih, klasnih
entiteta. Preko ove veze entitet koji se specijalizuje u klase prosleđuje primarni ključ
klasnim zavisnim entitetima. Ova veza se definiše postupkom generalizacije, tj. postupkom
apstrakcije podataka, u kome se skup sličnih tipova entiteta predstavlja NADTIPOM, tj.
generičkim (generalizovanim) entitetom (IDEF1X metodologija).
Pod sličnim tipovima objekata podrazumevaju se oni koji imaju JEDAN broj ISTIH
(zajedničkih) atributa, tipova veza i/ili operacija sa drugim objektima.
Kardinalnost veze kategorije od generičkog oblika ka entitetu kategorije je tipa "One-to-
-zero-or-one" i sadrži implicitni izraz 'is a', a čita se na sledeći način:
"Svaka (One) instanca generičkog entiteta može, a ne mora (zero-or-one) da ima instancu
kategorije, dok svaka instanca entiteta kategorije je (is a) instanca generičkog oblika."
Dakle, objekti su hijerarhijski GENERALIZOVANI ako se skup srodnih objekata posmatra kao
jedan objekat. Svi atributi sa nižeg nivoa, koji su zajednički, prenose se na viši nivo, dok se
alempije@beotel.yu 85
na nižem nivou definišu entiteti kategorije koji sadrže atribute koji su svojstveni samo tom
nivou.
U generalizacionoj hijerarhiji objekata (entiteta) važi pravilo nasleđivanja osobina i
nasleđivanja operacija nadtipa.
IDEF1X metodologija simbolički obezbeđuje razlikovanje dva tipa entiteta kategorije, tj.
nepotpune i potpune strukture.
Nepotpune strukture
Nepotpuna struktura se definiše kada nije sigurno da su identifikovani svi oblici entiteta
kategorije (jednostruka linija na dnu simbola klase naznačuje da mogu biti uključene druge
kategorije). Za ovakvu vezu se definiše atribut diskriminator u entitetu koji se specijalizira i
koji obezbeđuje ekskluzivnost veze. Ako se diskriminator ne definiše, veza se može smatrati
neekskluzivnom.
Na primeru prikazanom na slici 3.68. generalizovani entitet OSOBA može imati dva pojavna
oblika: KONSULTANT ili REDOVNI. Diskriminator "Vrsta" omogućuje definisanje oba tipa
angažovanja, ali ne ograničava da može biti više podtipova.
Diskriminator 'kategorije' je atribut koji pokazuje kako razlikovati entitete jedne kategorije
od entiteta druge kategorije. U navedenom primeru atribut 'vrsta' je diskriminator kategorije
i definisan je u entitetu OSOBA.
OSOBA
Sifra osobe
Status
KONSULTANT REDOVNI
TSifra osobe (FK) Sifra osobe (FK)
Potpune strukture
Na slici 3.69. prikazan je primer potpune strukture gde generički entitet OSOBA ima entitete
kategorije MUSKO ili ZENSKO. U IDEF1X formatu potpuna struktura se definiše pod nazivom
"complete category cluster" i ima osobinu da primerak generalizovanog (generičkog)
entiteta ne može postojati bez asocijacije sa primerkom specijalizovanog (kategorisanog)
entiteta. Diskriminator 'Pol' definisan u entitetu OSOBA, isključuje pojavljivanje treće
varijante.
86 alempije@beotel.yu
OSOBA
Sifra osobe
Pol
MUSKARAC ZENA
Sifra osobe (FK) Sifra osobe (FK)
OSOBA
Sifra osobe
Pol Status
Veze 'više prema više' su nacrtane sa tačkama na oba kraja. Prema primeru sa slike 3.71.
veze 'više prema više', OSOBA zna više JEZIKA i svaki JEZIK poznaje više OSOBA. Veze 'više
prema više' se, obično, koriste u preliminarnoj fazi razvoja entitetnog dijagrama.
Ovde ništa nije pogrešno, samo u slučaju da se jednostavno pokušava reći da OSOBA "zna"
više JEZIKA, kao i da JEZIK "poznaje" više OSOBA. 'Many-to-Many' veza (puna linija sa
tačkama na oba kraja) zove se nespecifična veza.
Osnovno pravilo koje se ovde mora poštovati je da se mora izvesti prevođenje 'Many-to- -
Many' veze u 'Zero-to-Many' vezu.
O SO BA zna
JEZIK
alempije@beotel.yu 87
Ovaj problem se rešava tako što se dodaje asocijativni entitet nazvan CERTIFIKAT (slika
3.72) i na taj način prevede 'Many-to-Many' veza u par One-to-Zero-One-or-Many veze. Kao
što je prikazano na slici 3.72, ključ entiteta OSOBA ("Sifra osobe") prelazi u asocijativni
entitet, a, isto tako, i ključ entiteta JEZIK ("Sifra jezika") prelazi u asocijativni entitet tako
da je asocijativni entitet CERTIFIKAT egzistenciono - identifikaciono zavisan od entiteta
JEZIK i OSOBA: egzistencijalno jer fizički ne može da postoji, a identifikaciono jer sadrži
primarne ključeve entiteta JEZIK i OSOBA.
Agregirani entitet se u modelu podataka tretira kao i kod drugih entiteta, tj. on može da ima
svoje atribute i/ili da bude u vezi sa nekim drugim entitetima (moguće agregiranim,
takođe), ili da ima svoje podtipove i slično.
OSOBA
Sifra osobe je dat /
poseduje
Sifra odeljenja (FK) vazi / JEZIK
Prezime odnosi se
Ime CERTIFIKAT Sifra jezika
JMBG Sifra osobe (FK) Naziv jezika
Plata Sifra jezika (FK)
Stimulacija
Datum zaposlenja Stepen znanja
88 alempije@beotel.yu
Kardinalnost N-arne veze
Postavljanje veze između tri ili više entiteta se izvodi na način koji je sličan asocijativnom
entitetu. Na primer, treba posmatrati postupak poslovnog odlučivanja koji je prikazan na
slici 3.73.
PROJEKTANT OSOBA
NARUCILAC POSLA
Sifra projekta Sifra osobe
Sifra firme
Naziv projekta Prezime
Naziv firme Ime
Adresa firme Datum pocetka
JMBG
Plata
definisao Stimul
UGOVOR
Sifra projekta (FK)
narucio
Sifra firme (FK) potpisao
Sifra osobe (FK)
Opis ugovora
Entitet UGOVOR ovde predstavlja trostruku vezu od entiteta NARUCILAC POSLA, PROJEKAT i
ZAPOSLEN. Struktura sa slike 3.73. indicira da više NARUCILACA POSLA naručuje više
PROJEKATA u kojima učestvuje više OSOBA.
Međutim, nameće se pitanje: "kako ponuditi projekat pre nego što je ugovoren"(slika
3.74.).
PROJEKTANT OSOBA
NARUCILAC POSLA
Sifra projekta Sifra osobe
Sifra firme
Naziv projekta Prezime
Naziv firme
Datum pocetka Ime
Adresa firme
JMBG
Plata
trazi nudi Stimul
UGOVOR
PONUDA
Sifra osobe (FK)
Sifra firme (FK)
predhodi Sifra firme (FK) potpisao
Sifra projekta (FK)
Sifra projekta (FK)
Opis ugovora
ERwin CASE alat je zasnovan na IDEF1X metodologiji koja, za razliku od drugih jezika
modeliranja, insistira da sve veze (relationships) budu binarne (da spajaju tačno dva
entiteta). To zaista ne znači da su nepotrebne 3,4 ili "n" veza (relationships), samo u
slučaju da su ove situacije adekvatno adresirane.
alempije@beotel.yu 89
Imajući sve to u vidu, za primer dokumenta "Karton isplata" u sledećem koraku biće
definisan atributivni model.
Na tom nivou, a za dosadašnji primer vezan za "Karton isplata" biće prikazan na slici 3.75.
atributivni model za ER dijagram koji sadrži definisane atribute.
Osnovni entitet je OSOBA i poseduje, kao primarni ključ, atribut " Sifra osobe" i set opisnih
atributa.
KONSULTANT REDOVNI
MUSKARAC ZENA
Sifra osobe (FK) Sifra osobe (FK)
Sifra osobe (FK) Sifra osobe (FK) rukovodi /
je rukovodilac Broj sati Vrsta posla
Sluzio vojsku Prezime devojacko
Čisto opisni atributi u entitetu OSOBA su: "Plata", "Stimul" i "Datum zaposlenja". Atribut
"JMBG (AK1)" alternativni je ključ i po njemu se može izvršiti sekundarno indeksiranje.
Atributi: "Prezime (IE1)" i "Ime (IE2)" atributi su tipa "Inverse Entry" i oni se koriste za
indeksiranje, s tim što indeks nije jednoznačan, tj. vrednosti ključa se mogu ponavljati.
Atribut "Sifra odeljenja (FK)" preneseni je ključ od entiteta ODELJENJE i dozvoljava unos
Null podataka, tj. ne mora se odmah definisati ODELJENJE gde OSOBA radi. Atribut:
"Sifrarm (FK)" preneseni je ključ entiteta RADNO MESTO i ne dozvoljava unos Null
podataka, tj. mora se obavezno uneti radno mesto Osobe.
Atribut: "Pol" diskriminator je kategorije MUSKARAC ili ZENA i automatski zahteva izbor
jedne od opcija. Atribut "Vrsta" je diskriminator kategorija entiteta: KONSULTANT i
REDOVNI i ne zahteva odmah odluku o vrsti, tj. naknadno se može definisati da li je osoba
konsultant ili redovni.
Entitet ODELJENJE, kojim se definiše istoimeni šifarnik, treba da omogući da ne postoji
nijedna Osoba zaposlena u njemu (Zero-One-or-Many). Entitet RADNO MESTO zahteva da
makar jedna Osoba ima odgovarajuće radno mesto (One-or-Many).
Na slici 3.75. definisan je i asocijativni entitet CERTIFIKAT koji je "povukao" ključeve
entiteta OSOBA i entiteta JEZIK i ima složeni ključ (Sifra osobe+Sifra jezika) i opisni atribut:
"Stepen znanja", kojim se definiše stepen znanja jezika.
Entitet ISPLATA je primer slabog entiteta, čiji je složeni ključ povukao ključ jakog (OSOBA)
entiteta "Sifra osobe (FK)" i atribut "rbr" kojim se definiše redni broj isplate. Opisni atributi
entiteta ISPLATA su: "Datum isplate" i "Iznos".
Entiteti kategorije povukli su: primarni ključ "Sifra osobe" iz entiteta OSOBA i imaju svoje
opisne atribute. Tako, entitet MUSKARAC ima opisni atribut: "Sluzio vojsku", a entitet ZENA
ima opisni atribut: "Prezime devojacko". Entitet KONSULTANT ima opisni atribut: "Broj sati"
90 alempije@beotel.yu
i entitet REDOVNI opisni atribut "Vrsta posla".
Na osnovu prethodno izvedenih aktivnosti (slika 3.49) u sledećem koraku biće definisan
referencijalni integritet.
Aktivnost
2.4.2. Definisanje referencijalnog
integriteta
Uprošćeno rečeno, referencijalni integritet obezbeđuje korektno povezivanje objekata, jer
objekat koji nije predstavljen u odgovarajućem skupu objekata ne može da učestvuje u
nekoj od veza predstavljenih u modelu podataka.
Referencijalni integritet je vezan za postojanje prenesenog ključa za neki entitet (npr. "Sifra
odeljenja" u entitetu OSOBA). Entitet gde se nalazi preneseni ključ zove se 'dete' (CHILD), a
entitet gde se definiše primarni ključ je 'roditelj' (PARENT). Primarni ključ se može preneti i
postati preneseni ključ u okviru identifikujuće ili neidentifikujuće veze.
Preneseni ključ u identifikujućoj vezi je sastavni deo primarnog ključa entiteta 'dete', pa se
'dete' identifikuje preko 'roditelj', čime učestvuje u definisanju integriteta entiteta. Kod
neidentifikujuće veze preneseni ključevi nisu deo primarnog ključa ''dete'ta', pa se 'dete' ne
može identifikovati preko 'roditelj'. Ova razlika je veoma važna kada treba podržati vezu
između 'roditelj' i ''dete'ta' kod operacija: ubacivanje (insert), brisanje (delete) i ažuriranje
(update), što čini suštinu referencijalnog integriteta.
Na osnovu toga mogu se definicije integriteta entiteta i referencijalnog integriteta dopuniti
sledećim tvrdnjama.
Integritetom entiteta se onemogućuje pojava da se mogu uneti dva entiteta sa istom
vrednošću primarnog ključa ili da je ključ NULL podatak.
Referencijalni integritet entiteta zahteva da unesena vrednost atributa odgovara vrednosti
atributa koji je primarni ključ drugog entiteta. Referencijalni integritet opisuje ponašanje
modela kada, usled operacija održavanja, dolazi do narušavanja kardinalnosti veza. To
ponašanje modela ili strukturna pravila integriteta (SPI) definišu se kao strukturna
ograničenja.
Referencijalni integritet se definiše za svaku vezu, posebno za stranu entiteta 'roditelj', a
posebno za stranu entiteta 'dete', i to za operacije: insert (ubacivanje), delete (brisanje) i
update (ažuriranje).
U daljem tekstu biće prikazane sve varijante referencijalnog integriteta za sledeće tipove
veza:
!" identifikujuće veze,
!" neidentifikujuća veza,
!" rekurzivne veze,
!" veza kategorije,
!" neodređujuća veza tipa više prema više i
!" N-arne veze.
alempije@beotel.yu 91
koja specificira egzistencijalnu i identifikacionu zavisnost između entiteta 'dete' od 'roditelj'.
DETE(CHILD)
RODITELJ(PARENT)
Dete kljuc
sadrzi / Roditelj kljuc
Roditelj kljuc (FK)
je sadrzano
92 alempije@beotel.yu
OSOBA
Sifra osobe
Sifra odeljenja (FK)
I:C Prezime
TELEFON U:C Ime
Sifra osobe (FK) I:R JMBG
Broj telefona U:R Plata
Stimulacija
Status p Datum zaposlenja
Za kardinalnost gde je svako ODELJENJE (PARENT) povezano sa nula, jednom ili više
instanci OSOBA (CHILD) i gde OSOBA egzistencijalno - identifikaciono zavisi od ODELJENJA,
referencijalni integritet je prikazan na slici 3.78.
I:R D:C
U:R
One-to-Zero-One-or-More
U:C
CHILD PARENT
OSOBA ODELJENJE OSOBA DELETE ___ ODELJENJE DELETE CASCADE
OSOBA INSERT RESTRICT ODELJENJE INSERT ______
OSOBA UPDATE RESTRICT ODELJENJE UPDATE CASCADE
alempije@beotel.yu 93
Referencijalni integritet definisan ovim tipom veze pri izvođenju operacije:
94 alempije@beotel.yu
Referencijalni integritet definisan ovim tipom veze pri izvođenju operacije:
I:R
One-to-Zero-or-One(Z)
D:C
U:R U:C
CHILD PARENT
OSOBA ODELJENJE OSOBA DELETE ___ ODELJENJE DELETE CASCADE
Z OSOBA INSERT RESTRICT ODELJENJE INSERT _____
OSOBA UPDATE RESTRICT ODELJENJE UPDATE CASCADE
alempije@beotel.yu 95
Referencijalni integritet definisan ovim tipom veze pri izvođenju operacije:
One-to-Exactly 4
CHILD PARENT
OSOBA ODELJENJE OSOBA DELETE ___ ODELJENJE DELETE RESTRICT
4 OSOBA INSERT RESTRICT ODELJENJE INSERT _____
OSOBA UPDATE RESTRICT ODELJENJE UPDATE RESTRICT
96 alempije@beotel.yu
Referencijalni integritet definisan ovim tipom veze pri izvođenju operacije:
alempije@beotel.yu 97
deo primarnog ključa bio nekompletan (akcija RESTRICT);
!" treće, za svaku obrisanu instancu 'roditelj' može se instanca entiteta 'dete' postavititi
kao Set Default.
U okviru ERwin CASE alata difoltna vrednost za brisanje entiteta 'dete' ne zahteva izvođenje
prethodne tri akcije (NONE), dok je difoltna vrednost za brisanje 'roditelj' RESTRICT.
CASCADE omogućuje da sve instance ''dete'ta' obuhvaćene brisanjem instance 'roditelj'
budu obrisane, što je definisano rečenicom PARENT DELETE CASCADE (D:C).
RESTRICT definiše ograničenje tako da instanca 'roditelj' ne može biti obrisana dok sve
instance ''dete'ta' koje imaju nasleđeni ključ ne budu prethodno obrisane. Ako postoji neki
nasleđeni, brisanje je zabranjeno.
SET DEFAULT definiše standardnu vrednost instance entiteta 'dete' za izbrisanog 'roditelj'.
Pravila ubacivanja (Insert) i ažuriranja (Update) za egzistencijalno zavisne neidentifikujuće
veze
Pravila za ubacivanje (INSERT) i ažuriranje (UPDATE) upravljaju šta će biti kada je red u
tabeli dodat ili ažuriran. Ažuriranje je, u suštini, ubacivanje, ali sa nekim dodatnim
pravilima.
Za operacije ubacivanje (INSERT) i izmena (UPDATE), red može biti dodat ili izmenjen
samo ako svi referencirani preneseni ključevi odgovaraju postojećim redovima u
referenciranim tabelama.
Pravila ubacivanja/ažuriranja mogu se izvesti korišćenjem triju akcija:
!" prvo, ne može se ubaciti/ažurirati instanca ''dete'ta' bez instance 'roditelj' (akcija
RESTRICT);
!" drugo, alternativno, za ubačenog/ažuriranog 'roditelj' treba ubaciti/ažurirati i bilo koje
'dete', čiji bi deo primarnog ključa bio ključ 'roditelj' (akcija CASCADE);
!" treće, prilikom ubacivanja/ažuriranja instance entiteta 'dete' može se postaviti
standardna vrednost instance entiteta 'dete' za 'roditelj' koji ne postoji.
U okviru ERwin CASE alata difoltna vrednost za ubacivanje/ažuriranje entiteta 'dete' je
RESTRICT, dok je difoltna vrednost za ubacivanje 'roditelj' - NONE a za ažuriranje
RESTRICT.
98 alempije@beotel.yu
!" treće, za svaku obrisanu instancu 'roditelj' može se instanca entiteta 'dete' postaviti kao
Set Default;
!" četvrto, za svaku obrisanu instancu 'roditelj' može se instanca entiteta 'dete' može se
postaviti kao Set Null.
U okviru ERwin CASE alata difoltna vrednost za brisanje entiteta 'dete' ne zahteva izvođenje
prethodne četiri akcije (NONE), dok je difoltna vrednost za brisanje 'roditelj' SET NULL.
CASCADE omogućuje da sve instance ''dete'ta' koje će biti obuhvaćene brisanjem instance
'roditelj' budu obrisane, što je definisano rečenicom PARENT DELETE CASCADE (D:C).
RESTRICT definiše ograničenje tako da instanca 'roditelj' ne može biti obrisana dok sve
instance ''dete'ta' koje imaju nasleđeni ključ ne budu prethodno obrisane. Ako postoji neki
nasleđeni, brisanje je zabranjeno.
Set Null ili Set Default pokazuje da je instanca 'roditelj' obrisana, ali je ključ 'roditelj'
zadržan kao podatak u entitetu 'dete'. Brisanje nije CASCADE, pa se ključ postavlja kao
NULL ili Set Default vrednost. Prednost tog pristupa je da se mogu sačuvati informacije o
''dete'tu' dok je efektivna veza između 'roditelj' i ''dete'ta' prekinuta.
Pravila ubacivanja (Insert) i ažuriranja (Update)
Pravila za ubacivanje (INSERT) i ažuriranje (UPDATE) upravljaju šta će biti kada je red u
tabeli dodat ili ažuriran. Ažuriranje je, u suštini, ubacivanje, ali sa nekim dodatnim
pravilima.
Za operacije ubacivanje (INSERT) i izmena (UPDATE), red može biti dodat ili izmenjen
samo ako svi referencirani preneseni ključevi odgovaraju postojećim redovima u
referenciranim tabelama.
Pravila ubacivanja/ažuriranja mogu se izvesti korišćenjem četiri akcije:
!" prvo, ne može se ubaciti/ažurirati instanca ''dete'ta' bez instance 'roditelj' (akcija
RESTRICT);
!" drugo, alternativno, može se za ubačenog/ažuriranog 'roditelj' ubaciti/ažurirati i bilo koje
'dete' čiji bi deo primarnog ključa bio ključ 'roditelj' (akcija CASCADE);
!" treće, prilikom ubacivanja/ažuriranja instance entiteta 'dete' može se postaviti
standardna vrednost instance entiteta 'dete' za 'roditelj' koji ne postoji;
!" četvrto, prilikom ubacivanja/ažuriranja instance entiteta 'dete' može se postaviti Null
vrednost instance entiteta 'dete' za 'roditelj' koji ne postoji.
U okviru ERwin CASE alata difoltna vrednost za ubacivanje/ažuriranje entiteta 'dete' je Set
Null, dok je difoltna vrednost za ubacivanje 'roditelj' - NONE, a za ažuriranje Set Null.
alempije@beotel.yu 99
Referencijalni integritet definisan ovim tipom veze pri izvođenju operacije:
Za kardinalnost gde je svako ODELJENJE (PARENT) povezano sa nula, jednom ili više
instanci OSOBA (CHILD) i gde OSOBA mora da pripada ODELJENJU, referencijalni integritet
je prikazan na slici 3.85.
100 alempije@beotel.yu
Referencijalni integritet definisan ovim tipom veze pri izvođenju operacije:
Slika 3.86. Referencijalni integritet za tip veze Zero (Nulls Allowed)-or-One-to-One-or-More (P)
alempije@beotel.yu 101
Referencijalni integritet definisan ovim tipom veze pri izvođenju operacije:
Slika 3.87. Referencijalni integritet za tip veze One (No Nulls)-to-One-or-More (P)
102 alempije@beotel.yu
Referencijalni integritet definisan ovim tipom veze pri izvođenju operacije:
Slika 3.88. Referencijalni integritet za tip veze Zero (Nulls Allowed)-or-One-to-Zero-or-One (Z)
alempije@beotel.yu 103
Referencijalni integritet definisan ovim tipom veze pri izvođenju operacije:
One(No Nulls)-to-Zero-or-One(Z)
I:R
CHILD PARENT
U:R
D:R OSOBA DELETE ________ ODELJENJE DELETE RESTRICT
OSOBA
U:R OSOBA INSERT RESTRICT ODELJENJE INSERT ______
Z ODELJENJE
OSOBA UPDATE RESTRICT ODELJENJE UPDATE RESTRICT
Slika 3.89. Referencijalni integritet za tip veze One (No Nulls)-to-Zero-or-One (Z)
104 alempije@beotel.yu
Referencijalni integritet definisan ovim tipom veze pri izvođenju operacije:
Zero(Nulls Allowed)-or-One-to-Exactly 4
I:SN
U:SN D:SN CHILD PARENT
OSOBA OSOBA DELETE ________ ODELJENJE DELETE SET NULL
U:SN
N OSOBA INSERT SET NULL ODELJENJE INSERT ______
ODELJENJE
OSOBA UPDATE SET NULL ODELJENJE UPDATE SET NULL
alempije@beotel.yu 105
Referencijalni integritet definisan ovim tipom veze pri izvođenju operacije:
106 alempije@beotel.yu
Referencijalni integritet definisan ovim tipom veze pri izvođenju operacije:
alempije@beotel.yu 107
OSOBA
Sifra osobe Zero (Nulls Allowed)- or-One-to-Zero-One-or-More
je rukovodilac /
je rukovodjen
108 alempije@beotel.yu
OSOBA
D:C
U:C
Pol
I:R I:R
U:R U:R
MUSKARAC ZENA
Slika 3.94. Referencijalni integritet potpune strukture
alempije@beotel.yu 109
O S O BA
D :C
U :C
V rst a
I:R I:R
U :R U :R
K ON S UL TA NT R E DO VN I
O SO BA zna
JE ZIK
Slika 3.96. Veza 'Many-to-Many'
Ovaj problem se rešava tako što se dodaje asocijativni entitet nazvan CERTIFIKAT i na taj
način prevodi 'Many-to-Many' veza u par One-to-Zero-One-or-Many vezu (slika 3.97).
110 alempije@beotel.yu
OSOBA
Sifra osobe je dat /
poseduje
Sifra odeljenja (FK) vazi / JEZIK
Prezime odnosi se
Ime CERTIFIKAT Sifra jezika
JMBG Sifra osobe (FK) Naziv jezika
Plata Sifra jezika (FK)
Stimulacija
Datum zaposlenja Stepen znanja
Pravila brisanja
Pravila brisanja mogu se izvesti korišćenjem dveju operacija:
!" prvo, može se obrisati svaka instanca CERTIFIKAT čiji je nasleđeni ključ obrisana
instanca entiteta JEZIK (akcija CASCADE), ili
!" drugo, može se sprečiti brisanje JEZIKA ako postoji bilo koji CERTIFIKAT čiji bi deo
primarnog ključa bio nekompletan (akcija RESTRICT).
Ove situacije koje su u vezi sa pravilima brisanja nazivaju se CASCADE i RESTRICT, a
odluka koje pravilo treba da se koristi biće definisana u modelu.
Dakle, CASCADE omogućuje da sve instance CERTIFIKAT obuhvaćene brisanjem instance
JEZIKA budu, takođe, obrisane, što je definisano rečenicom PARENT (JEZIK) DELETE
CASCADE (D:C), tj. ako je u pitanju, npr., instanca "nemački jezik" u entitetu JEZIK, onda
će se izbrisati automatski svi certifikati izdati za "nemački jezik" (slika 3.98).
JEZIK
D:C Sifra jezika
CERTIFIKAT
Sifra osobe (FK) Naziv jezika
Sifra jezika (FK)
Stepen znanja
RESTRICT definiše ograničenje tako da instanca JEZIKA ne može biti obrisana dok sve
instance CERTIFIKAT koje imaju nasleđeni ključ ne budu prethodno obrisane. Ako postoji
neki nasleđeni, brisanje je "ograničeno". U dosadašnjem primeru moraju prethodno biti
izbrisane sve instance entiteta CERTIFIKAT za "nemački jezik", pa tek onda da se pristupi
brisanju instance "nemački jezik" u entitetu JEZIK (slika 3.99).
JEZIK
D:R Sifra jezika
CERTIFIKAT
Sifra osobe (FK) Naziv jezika
Sifra jezika (FK)
Stepen znanja
alempije@beotel.yu 111
Zašto treba ograničiti brisanje?
Jedan od razloga može biti da treba ostaviti instancu "nemački jezik" u entitetu CERTIFIKAT.
Ako dođe do CASCADE brisanja, izgubiće se ova dopunska informacija.
To treba rešiti tako što entitet CERTIFIKAT neće egzistencijalno ili identifikaciono zavisiti od
JEZIKA, tj. biće promenjen referencijalni integritet upotrebom slabe veze između dva
entiteta (slika 3.100).
JEZIK
D:SN
Sifra jezika
CERTIFIKAT
Naziv jezika
Sifra osobe (FK)
Sifra jezika (FK)
Stepen znanja
U navedenom slučaju, situacija je bitno različita. Kao što je već poznato, spoljnom ključu,
koji je "donesen" preko slabe veze, dozvoljene su NULL vrednosti. Tako se za slabe veze
javlja treća opcija koja se zove Set Null.
Set Null pokazuje da ako je instanca JEZIKA obrisana, ali je ključ JEZIKA zadržan kao
podatak u entitetu CERTIFIKAT, brisanje nije CASCADE kao u prethodnom primeru i ne
može se zabraniti brisanje. Stoga se postavlja ključ kao NULL vrednost. Prednost tog
pristupa je da se mogu sačuvati informacije o CERTIFIKATU, dok je efektivna veza između
entiteta JEZIK i entiteta CERTIFIKAT prekinuta.
OSOBA D:C
U:C je dat /
Sifra osobe
poseduje
Sifra odeljenja (FK) vazi / D:R
JEZIK
Prezime odnosi seU:C
Ime I:R CERTIFIKAT Sifra jezika
JMBG U:R Sifra osobe (FK) I:R Naziv jezika
Plata Sifra jezika (FK) U:R
Stimulacija
Datum zaposlenja Stepen znanja
112 alempije@beotel.yu
Referencijalni integritet može se opisati na sledeći način:
Ako se posmatra referencijalni integritet veze OSOBA - CERTIFIKAT, može se uočiti da se
izmenom (UPDATE) ili brisanjem (DELETE) ključa entiteta OSOBA - akcijom CASCADE (D:C,
U:C) - prenose ove operacije i na ključeve entiteta CERTIFIKAT i one se automatski
izvršavaju. S druge strane, ne može se izvršiti operacija ubacivanje (INSERT) ili izmena
(UPDATE) entiteta CERTIFIKAT (I:R, U:R) ako ne postoji OSOBA. Ova zabrana definisana je
akcijom RESTRICT (R).
Kada se se posmatra referencijalni integritet veze JEZIK - CERTIFIKAT, može se uočiti da se
izmenom (UPDATE) ili ubacivanjem (INSERT) ključa entiteta JEZIK - akcijom CASCADE
(D:C, U:C) - prenose ove operacije i na ključeve entiteta CERTIFIKAT i one se automatski
izvršavaju.
Brisanje (DELETE) ključa entiteta JEZIK je onemogućeno akcijom RESTRICT (R).
S druge strane, ne može se izvršiti operacija ubacivanje (INSERT) ili izmena (UPDATE)
entiteta CERTIFIKAT (I:R, U:R) ako ne postoji OSOBA. Ova zabrana definisana je akcijom
RESTRICT (R).
Mada svaka veza agregira dva entiteta, samo binarne veze kojima bi imalo smisla dodati
neke atribute, ili koje bi imalo smisla povezivati sa drugim entitetima, treba tretirati kao
agregirane entitete (agregacije). Ako postoji potreba da se direktno predstavi veza tri ili više
entiteta, tada se i takva veza tretira kao agregacija.
Imajući sve to u vidu za primer dokumenta "Karton isplata", u sledećem koraku biće
definisana strukturna pravila integriteta za dokument "Karton isplata".
alempije@beotel.yu 113
Referencijalni integritet veze RADNO MESTO-OSOBA
Referencijalni integritet definisan tipom veze RADNO MESTO-OSOBA pri izvođenju operacije
ubacivanje (INSERT) ključa entiteta RADNO MESTO ne zahteva nikakvu akciju (NONE) nad
okolinom. Operacije: brisanje (DELETE) i izmena (UPDATE) ključa entiteta RADNO MESTO su
zabranjene (D:R, U:R), sve dok postoji preneseni ključ u entitetu OSOBA. Nad entitetom
OSOBA operacije: izmena (UPDATE) i ubacivanje (INSERT) i brisanje (DELETE) nisu
dozvoljene (U:R, I:R, D:R), jer zavise od postojanja ključa entiteta RADNO MESTO.
114 alempije@beotel.yu
Referencijalni integritet veze OSOBA-KONSULTANT-REDOVNI
Ako se posmatra referencijalni integritet nepotpune strukture može se uočiti da se izmenom
(UPDATE) ili brisanjem (DELETE) ključa entiteta OSOBA - akcijom CASCADE (D:C, U:C) -
prenose ove operacije i na podtipove (KONSULTANT i REDOVNI) i one se automatski
izvršavaju. S druge strane, ne može se izvršti operacija ubacivanje (INSERT) ili izmena
(UPDATE) odgovarajućih podtipova (I:R, U:R) ako ne postoji OSOBA. Ova zabrana je
definisana akcijom RESTRICT (R).
Dakle, referencijalni integritet definisan za dosadašnji navedeni primer, a prikazan na slici
3.102, može imati sledeće događaje ili operacije :
!" ubacivanje 'roditelj' (Parent Insert - PI)
!" brisanje 'roditelj' (Parent Delete - PD)
!" izmena 'roditelj' (Parent Update - PU)
!" ubacivanje 'dete' (Child Insert - CI)
!" brisanje 'dete' (Child Delete - CD)
!" izmenu 'dete' (Child Update - CU).
Način predstavljanja tabele strukturnih pravila integriteta (SP) za primer sa slike 3.102. dat
je na sledeći način:
U - Cascade I - Restrict D -
ISPLATA Prima
Cascade
U - Set Null I - Set Null D - Set
OSOBA Rukovodi
Null
U - Cascade I - Restrict D -
MUSKARAC is a
Cascade
U- Restrict I - Restrict D -
JEZIK CERTIFIKAT govori
Restrict
alempije@beotel.yu 115
Aktivnost
2.4.3. Identifikacija poslovnog domena
Entiteti se, kao što je već rečeno, opisuju preko svojih svojstava, odnosno atributa, od kojih
svaki (atribut) u jednom trenutku vremena ima neku vrednost. Tačnije, atributi uzimaju
vrednost iz skupa mogućih vrednosti koji se zove domen.
Pošto domen predstavlja skup vrednosti, u njemu se svaka vrednost javlja samo jednom.
Svi elementi skupa se međusobno razlikuju. Atribut nema svojstvo skupa, jer se određene
vrednosti mogu ponavljati, pa nije moguća jednoznačna identifikacija pojedinih elemenata.
Domen se može definisati po IDEF1X metodologiji kao bazni i tipski domen.
Bazni domen
Svaki domen se tretira kao podtip baznog domena. Naime, pod baznim domenima se
podrazumevaju tipovi podataka (po IDEF1X standardu to su Character, Numeric ili Boolen),
koji postoje u standardnim programskim jezicima (ceo broj, niz karaktera i slično) i samim
tim nasleđuju karakteristike i operacije koje se mogu definisati nad ovim domenima.
Tipski domen
Tipski domen se definiše preko svog imena, baznog domena i, eventualno, prostih ili
složenih ograničenja datih odgovarajućim domen-pravilima (domain rules) kojima se
definišu moguće vrednosti u domenu.
Definišu se sledeća prosta ograničenja, tj. domen-pravila:
!" relacioni operatori (operatora poređenja <,>,=,...);
!" IN lista vrednosti, kao skup pojedinačnih vrednosti koje se definišu eksplicitnim
navođenjem svih dozvoljenih vrednosti (IN ['A,B,C']);
!" BETWEEN rang domena, koji se definiše tako da se vrednosti iz domena uzimaju iz užeg
skupa vrednosti (BETWEEN 10 AND 200);
!" NOT NULL kada se želi iskazati da neki atribut ne može da ima nula vrednost, pa se
uvodi specifičan predikat NOT NULL, preko koga se definiše odgovarajući domen;
obrnuto, pretpostavlja se da svaki domen uključuje u sebe i nula vrednost (specijalnu
vrednost koja se dodeljuje nekom atributu objekta kada se njegova vrednost ne
poznaje).
Dakle, specifiraju se dozvoljene vrednosti domena koje se definišu validacionim izrazima
pomoću ključnih reči BETWEEN, IN i preko relacionih operatora (operatora poređenja
<,>,=,...) i slično.
Složena ograničenja se sastoje iz prostih, povezanih logičkim operatorima AND, OR i NOT.
Imajući sve to u vidu za primer dokumenta "Karton isplata", u sledećem koraku treba
definisati poslovni domen.
116 alempije@beotel.yu
Poslovni domen na primeru dokumenta
"Kartona isplata"
Poslovni domen za dosadašnji primer "Karton isplata" je prikazan u obliku tabele na slici
3.104.
Tip Validaciono
Naziv Null Default Validacioni
Opis domena podatka pravilo
domena Opcija naziv naziv
(Domen) (Ograničenje)
Obavezan
default Text(18) <>IsNull()
unos
Domen definiše NOT Obavezan
Broj Integer
sve brojeve NULL unos
Opšti datum
kome je Date/ Današnj Datum
Datum <=Date()
vrednost Time i datum zapošljenja
sistemski datum
Ovaj domen je
definisan za sve NOT Obavezan
Naziv Text(30) <>IsNull()
atribute koji NULL unos
opisuju nazive
Ovaj domen
definiše NOT Obavezan
Oznaka Text(6) <>IsNull()
identifikacione NULL unos
oznake
Domen opisuje NOT
Primanja Currency
plate i honorare NULL
Domen za
Stimulaci definisanje BETWEEN Interval
Currency
ja intervala i tipa 500 AND 1000 stimulacije
stimulacije
Stepen znanja
NOT
Stepen P-piše;G-govori; Text(3) Stepen INŠ'P,G,C'Ć Stepen
NULL
C-čita
U tabeli su prikazani:
!" naziv domena za koji se vezuju odgovarajući atributi;
!" domen, definisan kao tip podataka;
!" null opcija, kojom se definiše obaveznost unosa podataka;
!" default vrednost, kao specificirana vrednost koja se ubacuje (insert) u kolonu kada se
unose podaci;
!" default naziv (komentar vezan za default vrednost);
!" ograničenje ili validaciono pravilo kojim se ograničavaju set vrednosti datog domena;
!" validacioni naziv, koji se pojavljuje kada je narušeno zadato ograničenje (validacioni
naziv je očigledna ili neka opšta poruka).
Za primer dokumenta "Karton isplata" definisani su sledeći domeni (slika 3.104):
!" U okviru kolone Naziv domena definiše se default domen (<default>) koji je ERwin
predifinisani domen, koji se automatski setuje, a svi ostali domeni nasleđuju osobine tog
domena koji je 'roditelj'. Definiše se tipom podatka Text (18) i ima obavezan unos.
!" Broj je domen kojim se definišu: svi brojevi, Integer tip podatka i NOT NULL.
!" Datum je domen kojim se definišu atributi tipa datuma i koji, po difoltu, uzima današnji
datum i ima obavezan unos.
!" Naziv je domen za definisanje svih atributa, koji se opisuju tipom podataka Text, dužine
alempije@beotel.yu 117
30 i gde je obavezan unos.
!" Oznaka je domen kojim se definišu: ident brojevi svih šifarnika i tip podataka Text
dužine 6 sa obaveznim unosom (NOT NULL).
!" Primanja su domen kojim se definišu: atribut plata i tip podataka Currency i obavezan je
unos.
!" Stimulacija je domen definisan intervalom između 500 i 1000 dinara.
!" Stepen je domen definisan operatorom IN gde se definišu konkretne vrednosti.
Osnovna veza između atributa i domena je u tome što se atribut, koji je identičan sa svojim
domenom, može koristiti kao ključ entiteta.
Na ovaj način izvršena je i kompletirana aktivnost "2. Informaciono modeliranje" gde su sve
aktivnosti obavljane nezavisno od izabranog sistema za upravljanje bazama podataka
(SUBP). U sledećoj aktivnosti "3. Aplikativno modeliranje" poslovi su vezani za izbor SUBP i
predstavljaju konkretnu realizaciju vezano za izradu korisničke aplikacije.
118 alempije@beotel.yu
Aktivnost
3. Aplikativno
modeliranje
alempije@beotel.yu 119
Aktivnošću "2.Informaciono modeliranje" završen je tzv. logički dizajn, pa sada predstoji da
se izvođenjem aktivnosti "3. Aplikativno modeliranje" izvrši fizički dizajn za izabrani sistem
za upravljanje bazom podataka - SUBP (Data Base Managment System - DBMS).
Sistem za upravljanje bazama podataka (SUBP) softverski je sistem za čuvanje i
pretraživanje podataka i predstavlja skup programa čija je prvenstvena namena da na
zahtev aplikativnih programa vrši manipulaciju podacima. To je i jedan od načina da se
korisnicima (neprogramerima) omogući direktno korišćenje računara, tj. pristup i rukovanje
podacima.
Uopšteno govoreći, baza podataka (BP) predstavlja zbirku uzajamno povezanih podataka,
memorisanih sa kontrolisanom redundansom, da bi optimalno služili različitim aplikacijama.
Podaci su memorisani nezavisno od programa koji ih koriste. Za dodavanje novih podataka i
modificiranje ili pretraživanje postojećih podataka koriste se zajednički i kontrolisani
pristupi.
Redundansa u podacima mora biti reducirana na najmanju moguću meru i strogo
nadgledana, da bi na taj način bila osigurana usklađenost podataka u svakom momentu.
Aktivnost "3. Aplikativno modeliranje" treba da omogući projektantima baze podataka da
fizički kreiraju efikasnu bazu podataka i da pomogne projektantskom timu u razvoju
aplikacije i odabiru načina pristupa podacima.
APLIKATIVNO
MODELIRANJE
3
DEFINISANJE GENERISANJE
IZRADA
FIZI^KOG [EME BAZE
APLIKACIJE
DIZAJNA PODATAKA
3.1 3.2 3.3
Na slici 4.1 prikazano je stablo aktivnosti za aktivnost "3. Aplikativno modeliranje" čine ga
sledeće aktivnosti:
!" Aktivnost 3.1. Definisanje fizičkog dizajna,
!" Aktivnost 3.2. Generisanje sheme baze podataka,
!" Aktivnost 3.3. Izrada aplikacije.
Prve dve aktivnosti se definišu u okviru ERwin CASE alata, dok se treća aktivnost izvodi u
odgovarajućem alatu za izabrani sistem za upravljanje bazom podataka i nije podržana
IDEF1X standardom. Za prikaz izrade aplikacije za test-primer dokumenta "Karton isplata",
biće korišćen MS ACCESS SUBP, jer je njegova upotreba i najčešća.
U daljem tekstu detaljno će biti obrazložene aktivnosti prikazane na slici 4.1.
120 alempije@beotel.yu
Aktivnost
3.1. Definisanje fizičkog dizajna
Aktivnost "3.1. Definisanje fizičkog dizajna" prevodi logički u fizički model, tj. entitet u
tabele, atribute u kolone, kao i odgovarajuća ograničenja. ERwin nudi mogućnost
istovremenog definisanja logičkog i fizičkog nivoa i jednostavno prebacivanje sa logičkog na
fizički pogled na model.
Definisanje fizičkog dizajna se izvodi posredstvom sledećih aktivnosti (slika 4.1):
!" Aktivnost 3.1.1. Izbor SUBP,
!" Aktivnost 3.1.2. Definisanje tabela i kolona,
!" Aktivnost 3.1.3. Definisanje indeksa,
!" Aktivnost 3.1.4. Definisanje načina upravljanja podacima.
Izabrani
IZBOR
SUBP
SUBP
3.1.1
Definisani
DEFINISANJE nazivi tabela i
TABELA kolona
I KOLONA
3.1.2
Definisani
DEFINISANJE indeksi
INDEKSA
I1
3.1.3
Model
podataka DEFINISANJE
Fizi~ki
NA^INA
dizajn
UPRAVLJANJA O1
PODACIMA
3.1.4
alempije@beotel.yu 121
Aktivnost
3.1.1. Izbor SUBP
Aktivnost "3.1.1. Izbor SUBP" treba da definiše SUBP, gde će fizička šema biti kreirana i gde
će se specificirati default tipovi podataka, null opcije i druge default opcije koje se koriste za
generisanje kolona.
ERwin nudi komunikaciju prema sledećim SUBP (slika 4.3): DB2, ORACLE, Ingress, NetWare
SQL, SQL Server, SQLBase, SYBASE, INFORMIX, Rdb, WATCOM, AS/40, Progres, Clipper,
dBase III, dBase IV, Access, FoxPro i Peradox.
Svaki od ovih SUBP podržava određene tipove podataka i određenu sintaksu za definisanje
strukture modela (sintaksa za opis relacija, kolona i domena na fizičkom nivou).
122 alempije@beotel.yu
Strukturirani tipovi podataka su skupovi vrednosti čija struktura ima određeni smisao.
Nosioci strukturiranih podataka su strukturirane promenljive. U okviru SQL SUBP definišu
se, sledeći strukturirani tipovi, imajući u vidu logički model podataka:
!" entiteti postaju tabele,
!" atributi se definišu kao kolone,
!" instance ili primerci postaju redovi,
!" u preseku reda i kolone definišu se polja.
Tabela se sastoji od kolona i redova, koji se mogu sagledavati u bilo kom redosledu, bez
uticaja na sadržaj tabele. Tabelarno prikazivanje je prirodan način prikazivanja veza između
podataka.Tabele moraju biti tako sastavljene da se nijedna veza ne izgubi.
Kolone su definisane nazivom i u jednoj koloni postoji samo jedna vrsta podataka. Ako se
koristi ERwin, kolona se generiše iz atributa logičkog modela, pa se tip i dužina kolone
generišu na osnovu osobina atributa ili ih određuje sam korisnik, dodeljujući im SIMBOLIČKI
naziv.
Red se može definisati kao skup međusobno povezanih polja, koja sadrže osnovne podatke
o nečemu.
Polje je osnovna i najmanja jedinica podatka koja može biti numerička, alfabetska ili
alfanumerička.
Redovi se razlikuju među sobom, pa duplikati redova nisu dozvoljeni.
Kad se posmatra, na primer, tabela ODELJENJE sa kolonama definisanim vertikalno i
redovima definisanim horizantalno:
ODELJENJE
SIFRAO NAZIVO MESTO
10 PRIPREMA PANCEVO
20 RAZVOJ NOVI SAD
30 PRODAJA BEOGRAD
40 PROIZVOD PAZOVA
NJA
Posmatranjem tabele može se videti da je svaki red sastavljen od polja i da svako polje
sadrži vrednost polja na preseku reda i kolone.
Npr. u prvom redu tabele ODELJENJE, vrednost polja:
!" SIFRAO (broj odeljenja) - 10 ,
!" NAZIVO (naziv odeljenja) - PRIPREMA,
!" MESTO (lokacija odeljenja) - PANCEVO.
Više između sebe povezanih tabela čini relacionu bazu podataka. Dakle, relaciona baza
podataka je takav tip strukture koji se koristi za izražavanje odnosa između podataka u
obliku jednostavnih dvodimenzionalnih tabela. Najveće teoretske osnove dao je dr E.F. Codd
koji je objavio prve rezultate svoga istraživanja već 1969. godine.
alempije@beotel.yu 123
Veliki broj SUBP sa atributom "relacioni", koji se pojavio na tržištu sedamdesetih godina, od
trenutka kada je E.F.Codd dao prvu teorijsku definiciju ovoga modela, primorao je njegovog
tvorca da 1981. godine definiše, a kasnije i dopunjava, kriterijume koje neki sistem treba da
zadovolji da bi se mogao zvati relacionim.
Funkcije SUBP
S obzirom na prethodno definisana 12 pravila, sistemi za upravljanje bazama podataka
imaju dve osnovne funkcije. Prva funkcija se koristi za memorisanje i održavanje podataka,
koji izražavaju svojstva tabela (objekata posmatranja). Za izvođenje ove funkcije koriste se
jezik za definisanje podataka i struktura podataka (Data Definition Language ili DDL). O tom
jeziku biće više reči u poglavlju 4.2.
Druga funkcija se koristi za kontrolisan pristup do memorisanih podataka i prikazivanje
podataka (vrednosti svojstava tabela) na zahtev korisnika. Za izvođenje ove funkcije koristi
se jezik za manipulaciju podacima (Data Manipulation Language ili DML). O tom jeziku biće
više reči u poglavlju 4.3.
124 alempije@beotel.yu
Treba istaći da SUBP mora vršiti nadzor nad simultanim korišćenjem baze podataka. U
načelu, svakom je korisniku data mogućnost da vrši manipulaciju sa memorisanim
podacima. Tako, može se dogoditi da više korisnika istovremeno pokuša modifikovanje istih
podataka. Stoga SUBP mora sinhronizovati simultane zahteve više korisnika, da ne bi došlo
do gubljenja podataka.
Kada se to ima u vidu, rad sa SUBP treba da omogući:
!" menjanje postojećih podataka u okviru baze podataka,
!" brisanje postojećih redova,
!" dodavanje novog reda,
!" traženje (izdvajanje) konkretnog reda i
!" pretraživanje baze podataka.
Mora se naglasiti da se sve promene u vezi sa poljem (unošenje novih podataka, menjanje
postojećih i brisanje) moraju sprovoditi u okviru reda.
Postupak menjanja polja je sledeći:
!" red u kome se vrši izmena podataka pronalazi se u memoriji pomoću adrese ili ključa;
!" red se iz eksterne memorije prenosi u operativnu memoriju;
!" vrši se izmena sadržaja datih polja;
!" red se ponovo zapisuje u eksternu memoriju.
Postupak brisanja već postojećih redova zahteva pažnju - da se brišu pravi redovi, tj. da se
poštuju pravila vezana za integritet baze podataka, kao i referencijalni integritet.
Postupak dodavanja novih redova zahteva obezbeđenje potrebnog memorijskog prostora i
poštovanje integriteta baze podataka, kao i referencijalnog integriteta.
Traženje podrazumeva traženje konkretnog reda koje se obavlja preko primarnog ključa.
Traženje je uspelo ako je vrednost primarnog ključa reda identična vrednosti ključa datog u
argumentu.
Pretraživanje se vrši putem argumenta koji je dat kao LOGIČKI izraz. Sastavlja se lista
zahtevanih svojstava i kriterijuma po kojima se vrši pretraživanje tabela i izdvajaju svi oni
redovi koji u potpunosti udovoljavaju zahtevima (videti glavu 4.3).
alempije@beotel.yu 125
programima i prema njima imaju vlasnički odnos. Međutim, nisu prilagođene za upotrebu
kod novih programa, jer oni nisu bili uzeti u obzir pri definisanju datoteke, a mogli bi
uspešno da koriste neke podatke. Ovaj problem se polovično rešava promenom dizajna
datoteke ili definisanjem dodatne datoteke za potrebe novog programa. Međutim, negativna
reakcija je pojava višestrukog memorisanja podataka, ili tzv. redundanse podataka.
Za razliku od rada sa datotekama, korišćenje SUBP omogućuje da neprogrameri mogu
pristupiti podacima i njima manipulisati:
!" direktnim radom sa računarom svakog korisnika,
!" jednostavnim definisanjem obrade (obradu definišu osobe koje se bave fizikom
problema, a ne obradom podataka).
Dakle, SUBP treba da omogući svim ovlašćenim korisnicima korišćenje zajedničkih podataka
(slika 4.5), skladištenje podataka sa minimalnom redundansom, logičku i fizičku nezavisnost
programa od podataka, jedinstveno komuniciranje sa bazom podataka preko jezika bliskih
korisniku. Nezavisnost programa i podataka se postiže kada se može dopunjavati i
modifikovati struktura baze podataka bez posledica po postojeće korisnikove programe.
Jezik blizak korisniku je tzv. SQL upitni jezik.
Baza podataka
Podaci Programi
PLATNI SPISAK PLATNI SPISAK
Podaci Programi
KNJIGOVODSTVO SUBP KNJIGOVODSTVO
Podaci Programi
INVENTAR INVENTAR
126 alempije@beotel.yu
!" jezik za opis baza podataka (videti glavu 4.2),
!" vezivanje SQL sa nekim standardnim jezikom (CURSOR operacija),
!" kontrolne konstrukcije za upravljanje konkurentnom obradom,
!" oporavak baze podataka (videti glavu 4.1),
!" definisanje zaštite baze podataka (videti glavu 4.1),
!" definisanje integriteta baze podataka (videti glavu 4.1).
SQL je jezik za:
• interaktivno definisanje baze podataka (Data Definition Language ili DDL) - jezik kojim
treba da se omoguće kreiranje, dodavanje, brisanje tabela, pogleda, sinonima i indeksa,
pa stoga poseduje sledeće komande (pogledati aktivnost "3.2. Generisanje šeme baze
podataka" ):
CREATE TABLE ! kreiranje tabele,
CREATE VIEW ! kreiranje pogleda,
CREATE SYNONIM ! kreiranje sinonima, *
CREATE INDEX ! kreiranje indeksa,
ALTER TABLE ! dodavanje kolona ili redefinisanje u
tabeli,
DROP TABLE ! brisanje tabele,
DROP VIEW ! brisanje pogleda,*
DROP SYNONYM ! brisanje sinonima,*
DROP INDEX ! brisanje indeksa;
Napomena: Zvezdica (*) znači da su naredbe definisane u okviru ORACLE verzije SQL-a.
Na osnovu izabranog SUBP pristupa se u sledećem koraku - definisanju tabela i kolona.
alempije@beotel.yu 127
Aktivnost
3.1.2. Definisanje tabela i kolona
Implementacija entiteta i njihovih atributa u tabele i kolone nekog SUBP, korišćenjem
ERwin-a, relativno je jednostavan posao. Programski modul ERwin-a za izgradnju fizičkog
modela čita opis entiteta i atributa i formira tabele i polja fizičkog modela (slika 4.6).
Proces implementacije veza i njihovih definicija je mnogo složeniji posao. Radi ilustracije,
sledi razmatranje prevođenja ERwin modela u MS Access dekstop SUBP.
Dakle, ERwin definiše tabele i kolone automatski, tj. nazivi tabela po defaultu dobijaju
imena na osnovu naziva entiteta, a nazivi atributa po defaultu postaju nazivi kolona. I druge
osobine se dodeljuju kao default setovane vrednosti (vrednosti koja će biti insertovana u
kolonu). U Target Server editoru (Erwin) postavljaju se default vrednosti za (slika 4.3):
!" Default Access Datatype kojim se definišu default tip i veličina kolone, npr., text (18);
!" Reset Physical Name kojim se izvodi resetovanje fizičkih imena;
!" Referential Integrity Default kojim se definišu default vrednosti referencijalnog
integriteta.
Na osnovu definisanih default osobina prelazi se na realizaciju fizičkog modela. Na slici
4.6. prikazani su logički i fizički model podataka za primer dokumenta "Karton isplata", gde
se automatski preuzimaju isti nazivi tabela kao nazivi entiteta i u okviru njih nazivi kolona,
a osobine kolona se preuzimaju na osnovu naziva atributa.
RADNOM RADNIK
JEZIK D:R ODELJENJE
Sifrar I:SN D:SN
Sifrarm
Fizički Sifraj U:R U:SN zaposljava Sifrao
U:SN
Nazivrm pripada Prezime (IE1)
Nazivj D:C Nazivo
model
I:R Ime (IE1)
vazi U:C prima Mesto
U:R Sifrarm (FK)
D:R I:SN
podataka I:R JMBG (AK2) I:R
U:R P U:SN
U:R D:R rukov (FK) U:R ISPLATA
za CERTIFIKAT
I:R
U:R Datumz
Plata
Sifrar (FK)
rbr
Sifrar (FK)
primer Sifraj (FK)
U:R je dat D:C
U:C
Stimul
Sifrao (FK)
D:C
U:C Datumis
128 alempije@beotel.yu
!" Validation Rule editor, kojim se definišu validaciona pravila;
!" Valid Value Editor, kojim se definišu validacione vrednosti;
!" Access Default Editor, kojim se definišu default vrednosti.
Na primeru sa slike 4.6. za tabelu RADNIK, korišćenjem editora za kolone, biće izvršene
izmene za default vrednosti (slika 4.7).
Kad je reč o dokumentu "Karton isplata", definisane su osobine kolona za tabelu RADNIK i
prikazane na slici 4.7.
U okviru tipa podataka (Datatype) prikazani su: domen ( npr., IDbroj) i posle dve tačke- tip
i veličina domena ŠText (6)Ć, pa se kompletira sledeći izgled: IDbroj:Text (6).
Ono što je sada interesantno sa slike 4.7. jeste osobina kolone Access Datatype gde se
definiše tip podatka. U tabeli 4.1. prikazani su MS ACCESS tipovi podataka koji su dostupni
u okviru ERwin-a za dodelu pojedinim kolonama.
alempije@beotel.yu 129
Tabela 4.1. MS ACCESS tipovi podataka
Na osnovu definisanih osobina kolona (slika 4.7) na slici 4.8. prikazan je fizički model za
primer dokumenta "Karton isplata" sa definisanim tipovima i veličinama podataka za
odgovarajuće kolone.
RADNOM RADNIK
JEZIK D:R ODELJENJE
Sifrar: Text(6) I:SN D:SN
Sifrarm: Text(2)
Sifraj: Text(2) U:R U:SN U:SN Sifrao: Text(2)
Nazivrm: Text(20) Prezime: Text(20) (IE1)
Nazivj: Text(20) I:R Ime: Text(20) (IE1) D:C Nazivo: Text(20)
U:R Sifrarm: Text(2) U:C Mesto: Text(20)
D:R I:SN
I:R JMBG: Text(13) (AK2) I:R
U:R P U:SN
U:R D:R rukov: Text(6) U:R ISPLATA
CERTIFIKAT U:R Datumz: Date/Time Sifrar: Text(6)
I:R Plata: Double rbr: Text(2)
Sifrar: Text(6) U:R D:C
D:C Stimul: Double
Sifraj: Text(2) U:C Datumis: Date/Time
U:C Sifrao: Text(2)
Pol: Text(1) Iznos: Double
Stepen: Text(10) Vrsta
Pol vrsta: Text(1) I:R
I:R I:R I:R
U:R U:R
U:R U:R D:SN
U:SN KONSULTANT REDOVNI
MUSKARAC ZENA
Sifrar: Text(6) Sifrar: Text(6)
Sifrar: Text(6) Sifrar: Text(6)
Brojs: Integer Vrstap: Text(18)
Sluziov: Text(2) Prezimed: Text(20)
Grafička prezentacija data na slici 4.8. u tablici 4.2. prikazana je za primer dokumenta
"Karton isplata" kao uporedna tabela.
130 alempije@beotel.yu
Tabela br.4.2. Uporedna tabela.
Sifrar Text(6)NOT
Sifra osobe(PK)(FK)
NULL
ISPLATA ISPLATA rbr(PK) rbr Text(2)NOT NULL
Datum isplate Datumis Date/Time
Iznos Double NOT
Iznos
NULL
Sifraj Text(2) NOT
Sifra jezika(PK)
NULL
JEZIK JEZIK
Nazivj Text(20) NOT
Naziv jezika
NULL
Sifrar Text(6) NOT
Sifra osobe(PK)(FK)
NULL
KONSULTANT KONSULTANT
Brojs Integer NOT
Broj sati
NULL
Sifrar Text(6) NOT
Sifra osobe(PK)(FK)
NULL
MUSKARAC MUSKARAC
Sluziov Text(2) NOT
Sluzio vojsku
NULL
Sifrao Text(2) NOT
Sifra deljenja(PK)
NULL
Nazivo Text(20) NOT
ODELJENJE ODELJENJE Naziv odeljenja
NULL
Mesto Text(20) NOT
Mesto
NULL
Sifrar Text(6) NOT
Sifra osobe (PK)
NULL
Prezime Text(20)NOT
Prezime (IE1)
NULL
Ime Text(20) NOT
Ime(IE1)
NULL
Sifrarm Text(2) NOT
Sifrarm(FK)
NULL
JMBG Text(13) NOT
JMBG(AK2)
NULL
OSOBA RADNIK
rukov Text (6) NOT
rukov(FK)
NULL
DatumzDate/TimeNOT
Datum zaposlenja
NULL
Plata Plata Double NOT NULL
Stimul Double NOT
Stimulacija
NULL
Sifra odeljenja(FK) Sifrao Text(2)
Pol Pol Text(1) NOT NULL
Vrsta vrsta Text(1)
Sifrarm Text(2) NOT
Sifrarm(PK)
RADNO NULL
RADNOM
MESTO Nazivrm Text(20) NOT
Nazivrm
NULL
Sifrar Text (6) NOT
Sifra osobe(PK)(FK)
REDOVNI REDOVNI NULL
Vrsta posla Vrstap Text (18)
Sifrar Text(6) NOT
Sifra osobe(PK)(FK)
NULL
Sifraj Text(2) NOT
CERTIFIKAT CERTIFIKAT Sifra Jezika(PK)(FK)
NULL
Stepen Text(10) NOT
Stepen znanja
NULL
Sifrar Text (6) NOT
Sifra osobe(PK) (FK)
NULL
ZENA ZENA
Prezimed Text(20) NOT
Prezime devojacko
NULL
Sledeći korak je da se definišu osobine domena. Pritiskom na tipku Domain... (slika 4.7)
prelazi se u novu formu gde se definišu osobine domena (slika 4.9).
alempije@beotel.yu 131
Definisanje osobina domena
U okviru aktivnosti "2.4.3. Identifikacija poslovnog domena" identifikovani su domeni za
primer dokumenta "Karton isplata", a sada treba pokazati tzv. domen editor pomoću koga
se definišu osobine domena (slika 4.9). Editor omogućuje da se definiše domen, i to: tip
domena, NULL opcija, validaciona pravila, default vrednost kao nasleđivanje hijerarhije
domena (definisanje roditeljskog domena). U ovom editoru definišu se ograničenja nad
standardnim domenom i pri tom određuju: tip podatka (tablica 4.2) i dužina podatka [npr.,
Text (30)].
Dodeljivanjem NULL opcije definiše se Null vrednost polja, tj. ako je NOT NULL polje mora
uvek da ima i neku vrednost; ako je NULL - ne mora.
Na slici 4.10. prikazan je fizički model podataka sa definisanim atributima i njima
definisanim odgovarajućim domenima.
Kao što se može videti na slici 4.10, tabele su opisane kolonom i odgovarajućim nazivima
domena. Može se primetiti da domen može, a ne mora da ima isto ime kao kolona. Domeni
prikazani na slici 4.10. u tablici 4.3. detaljno su opisani.
RADNOM RADNIK
JEZIK ODELJENJE
Sifrarm: Sifarnici pripada Sifrar: IDbroj Sifrao: Sifarnici
Sifraj: Sifarnici zaposljava
Nazivrm: Naziv Prezime: Naziv (IE1)
Nazivj: Naziv Nazivo: Naziv
Ime: Naziv (IE1)
Mesto: Naziv
vazi Sifrarm: Sifarnici
JMBG: Text(13) (AK2)
P
rukov: IDbroj prima ISPLATA
CERTIFIKAT Datumz: Datum Sifrar: IDbroj
Plata: Plata rbr: Text(2)
Sifrar: IDbroj je dat Stimul: Stimulacija
Sifraj: Sifarnici Sifrao: Sifarnici Datumis: Datum
Pol: Pol Iznos: Primanja
Stepen: Text(10) Vrsta
Pol vrsta: vrsta
KONSULTANT REDOVNI
MUSKARAC ZENA
Sifrar: IDbroj Sifrar: IDbroj
Sifrar: IDbroj Sifrar: IDbroj
rukovodi Brojs: Broj Vrstap: <default>
Sluziov: Sluziovojsku Prezimed: Naziv
132 alempije@beotel.yu
Tablica br.4.3. Opis domena za primer "Karton isplata"
TIP I
DOMEN OPIS DOMENA
VELIČINA
<default> Text (18) Default vrednost definisana u ERwin-u
Broj Integer Domenom Broj definišu se svi brojevi
Datum Date/Time Podrazumevajuća vrednost sistemskog datuma
IDbroj Text (6) Jedinstven paralelni sistem označavanja
Naziv Text (20) Definiše atribute koji opisuju nazive
Primanja Double Domen opisuje plate i honorare
Plata Double Poddomen od domena primanja
Domen definisan IN listom vezan za definisanje
Pol Text (1)
potpune strukture (M- Muski Z-Zenski)
Sifarnici Text (2) Domen opisuje sifarnike
Sluziovojsku Text (2) Domen definisan IN listom (DA, NE)
Stepen Text (10) Stepen znanja jezika definisan IN listom (P,G,C)
Stimulacija Double Domen definiše interval i tip stimulacije
Domen definisan IN listom vezan za definisanje
vrsta Text (1)
nepotpune strukture
Pritiskom na dugme Validation... (slika 4.9) prelazi se na sledeći nivo gde se definišu
validaciona pravila (slika 4.11), tj. definiše se ograničenje nad vrednošću domena.
!" IN lista se formira kao lista od konstanti iz odgovarajućeg domena (slika 4.12), tj.
eksplicitnim navođenjem svih dozvoljenih vrednosti. Za validacioni naziv Pol validaciono
pravilo je IN ['M','Z'] i validacioni naziv Vstepen validaciono pravilo je IN
['Govori','Pise','Cita'].
alempije@beotel.yu 133
Slika 4.12. Prikaz IN liste
!" BETWEEN opseg dozvoljenih vrednosti gde atribut može poprimiti samo uži skup
vrednosti iz domena; npr., za validacioni naziv Stimulacija definiše se validaciono pravilo
BETWEEN 500 and 1000 (slika 4.13).
134 alempije@beotel.yu
Definisanje default vrednosti
Ako se pritisne tipka Default... (slika 4.9) prelazi se na definisanje default vrednosti (slika
4.15). U default editoru kreira se default vrednost koja se automatski dodeljuje za izabranu
kolonu. Na slici 4.15. prikazane su definisane default vrednosti za definisan naziv Stepen
default vrednost Cita.
Trigeri i procedure
Trigeri predstavljaju imenovane blokove SQL koda koji su prekompajlirani i memorisani da
bi ubrzali postavljanje upita, brže izvršili validaciju nad podacima ili neku vrlo često
korišćenu operaciju. Najveća prednost je u tome da se jednom programirani blokovi SQL-a
prenose na različite platforme bez modifikacija.
Dakle, trigeri su imenovani skupovi prekompajliranih SQL izraza 'memorisanih na serveru'
koji se izvršavaju kada se pojavi odgovarajući događaj; oni govore SUBP kako da izvrši
ubacivanje, ažuriranje ili brisanje u tabeli, i to onako kako je zamišljeno.
Trigeri referencijalnog integriteta (u daljem tekstu: RI trigeri) posebna su vrsta trigera koji
se koriste da bi se održao integritet između dve tabele između kojih je uspostavljena
relacija, odnosno oni govore SUBP šta da učini sa redom u onoj drugoj tabeli u kojoj je
preneseni ključ jednak primarnom ključu u prvoj tabeli ako se u prvoj tabeli briše, ažurira ili
dodaje novi red.
ERwin kreira RI trigere automatski i automatski dodeljuje podrazumevani RI triger svakom
entitetu u vezi. SQL kod RI trigera se generiše na osnovu tri kriterijuma:
!" vrste pravila referencijalnog integriteta koji se primenjuje na vezu (RESTRICT,
CASCADE, SET NULL,SET DEFAULT ILI NONE)
!" vrste veze, tj. da li je identifikujuća, neidentifikujuća ili podtip veze;
!" vrste uloge entiteta u vezi, tj. da li je tabela 'dete' ili 'roditelj'.
Pritiskom na tipku Referential Integrity Default... (slika 4.3) prelazi se na editor za
definisanje default vrednosti referencijalnog integriteta (slika 4.16).
alempije@beotel.yu 135
Slika 4.16. Default Editor pravila referencijalnog integriteta
136 alempije@beotel.yu
Aktivnost
3.1.3.Definisanje indeksa
U tabelama, podaci se smeštaju po redosledu njihovog unošenja. Postupak pretraživanja
zahtevanog podatka u tabeli može dugo da potraje, pa se za rešavanje problema
pretraživanja koriste specijalni tipovi tabela pod imenom indeksi, u kojima se nalaze adrese
redova.
Npr., za tabelu RADNIK automatski se formira indeksna tabela vezana za primarni ključ (PK)
nad kolonom Sifrar (slika 4.17).
Mogu se kreirati i separatni indeksi za svaku kolonu u tabeli ako je česta potreba za
pretraživanjem pojedinačnih vrednosti memorisanih u koloni.
Takođe, može se formirati i indeks nad više kolona kao, npr., nad kolonama: Prezime i Ime
u tabeli RADNIK.
Kada se generiše fizička šema baze podataka, ERwin automatski kreira pojedine indekse za:
!" primarne ključeve nad svakom tabelom (PK),
!" alternativne ključeve (AKx),
!" prenesene ključeve (IF),
!" inverzne ključeve (IE),
!" kolone koje imaju često pretraživanje.
Korišćenjem Index editora, u okviru naziva indeksa definiše se sledeća struktura oznake:
"X" + "PK" (ili "AK", " IF" ili "IE" + "n") + Naziv tabele entiteta.
alempije@beotel.yu 137
Tablica br.4.4. Indeksi za tabele iz primera "Karton isplata"
Npr., za tabelu RADNIK i odgovarajuću kolonu formira se, po default-u sledeća struktura
indeksa:
!" Sifrar (PK) ima indeks XPKRADNIK;
!" Prezime (AK1)+Ime (AK1) ima indeks XAK1RADNIK;
!" JMBG (AK2) ima indeks XAK2RADNIK;
!" Sifrao (IF1) ima indekS XIF1RADNIK;
!" Rukov (IF6) ima indeks XIF6RADNIK.
Kako su alternativni ključevi, takođe, jednoznačni, a instance kolona: Prezime i Ime se
mogu ponoviti, to isključivanjem opcije "Unique" AK1 prelazi u IE1 (slika 4.17).
Primarni indeks XPKRADNIK ima uključenu opciju "Clustered" koja omogućuje da se podaci
u tabelama fizički smeštaju uz indekse, čime se poboljšavaju performanse upita.
U tablici 4.4. prikazani su formirani indeksi u ERwin-u za primer fizičkog modela podataka
"Karton isplata".
Na osnovu prethodno izvedenih aktivnosti (slika 4.2) u sledećem koraku potrebno je
definisati način upravljanja podacima.
138 alempije@beotel.yu
Aktivost
3.1.4.Definisanje načina upravljanja
podacima
alempije@beotel.yu 139
Rečnik podataka je baza podataka o bazi podataka (meta-baza podataka) i u njoj su opisi
tabela, relacija između tabela, kao i svi objekti tipa formi, izveštaja, upita, makroa i
programa koji se čuvaju u meta-bazi, koja se logički predstavlja kao i sama baza podataka.
U rečnik podataka smeštaju se pravila integriteta koja su definisana pomoću nekog jezika
visokog nivoa. Rečnik podataka je korektan pristup; no, međutim, neki SUBP ne podržavaju
integritet na taj način, jer se podrška prebacuje u aplikacione programe, odnosno ostavlja
se mogućnost da programer, uz pomoć generatora aplikacija, sam vodi računa o integritetu
baze podataka.
Integritet domena je dozvoljeni skup vrednosti, gde svaka vrednost u polju mora da pripada
domenu te kolone. Dakle, red se nalazi u tabeli ako su vrednosti u svim kolonama tog reda
u domenu kolona, a integritet domena kolone je održan ako zapis može biti upisan u tabelu
samo u slučaju da tip podatka u svakoj koloni odgovara dozvoljenom tipu za datu kolonu.
Integritet tabela je ispunjen ako je svaki red u tabeli jedinstven, tj. ako postoji jednoznačna
identifikacija reda koji se definiše primarni ključem, u kojem se može nalaziti jedna ili više
kolona. Kolona čija se vrednost koristi za identifikaciju ostalih kolona naziva se ključem.
Postoje dve vrste ključeva: primarni i sekundarni.
Primarni ključ jednoznačno određuje red; stoga i ne mogu postojati dva reda sa istim
vrednostima ključa. Ako u redu nema kolone koja bi jednoznačno odredila neki red, mogu se
naći dva ili više koji zajedno određuju jednoznačnost. Tada se govori o združenom ključu.
Sekundarni ključ je kolona po kojoj se vrši pretraživanje. Sekundarni ključ ne mora biti
jednoznačan.
Referencijalni integritet ili integritet relacija omogućuje vezu između raznih kolona i tabela.
Vrednosti u jednoj koloni ili grupa kolona referišu se vrednostima u drugoj koloni ili skupu
kolona i pri tom se definiše za tabelu 'dete' preneseni ključ (foreign key), a za tabelu
'roditelj' - primarni ključ (primary key).
Autoreferencijalni integritet je definisan spoljnim i orginalnim ključem u istoj tabeli, gde je
jedna kolona u tabeli povezana sa vrednostima u drugoj koloni iste tabele.
Poslovna pravila ili tzv. korisnička pravila su pravila za očuvanje integriteta podataka koja
zadaje korisnik; npr., zabrana izmene podataka van radnog vremena. Uskladištena
procedura je, takođe, primer za poslovna pravila, gde se definišu pravila za prevođenje
skupa SQL iskaza i programski iskazi za kontrolu toka obrade. Takođe, poslovnim pravilima
se deklarišu promenljive, kao i odgovarajući operatori za dodelu vrednosti. Uskladištena
procedura automatski se "ispaljuje" pod određenim uslovima i nalazi se u serveru baze
podataka, što omogućuje da se saobraćaj u mreži svede na minimum.
Ograničenjima se definiše integritet podataka između tabela; ta ograničenja su vezana za
rang validnih vrednosti.
140 alempije@beotel.yu
Drugim rečima, transakcija predstavlja izvršenje jednog skupa operacija (npr., SELECT,
UPDATE, INSERT i DELETE) nekog programa koji počinje sa prvom izvodljivom DML ili DDL
naredbom (BEGIN TRANSACTION), a završava se:
!" operacijom COMMIT (ako je ceo skup operacija uspešno izvršen),
!" ROLLBACK (ako ceo skup operacija nije uspešno izvršen),
!" DDL naredbom,
!" važećom greškom (slično deadlock),
!" log off,
!" greškom mašine.
Nakom izvršenja jedne transakcije, sledeća SQL naredba automatski startuje drugu po redu
transakciju.
Drugim rečima, na nivou SQL naredbi upravljanje transakcijom se upravlja sa:
!" naredbom COMMIT, kojom se:
• definišu stalne izmene u bazi podataka,
• brišu svi CHECKPOINT u transakciji,
• definiše kraj transakcije,
• realizuje tzv. transakciono zaključavanje i
• omogućuje eksplicitni kraj transakcije;
!" naredbom CHECKPOINT za duge transakcije kojom se deli transakcija u male 'porcije', tj.
čuva rad u transakciji u jednoj tački sa opcijom za kasniji COMMIT;
!" naredbom ROLLBACK, kojom se poništavaju sve izmene u tekućoj transakciji, odnosno
kojom se:
• brišu svi CHECKPOINT u transakciji i
• oslobađaju sva transakciona zaključavanja;
!" naredbom ROLLBACK[WORK] TO CHECKPOINT kojom se poništava samo deo
transakcije.
U radu sa bazom podataka koji se koriste u transakcijama definišu se dve operacije, i to:
!" čitanje (read) sa baze podataka, korišćenjem naredbe SELECT i
!" ispisivanje (write) u bazu podataka, korišćenjem naredbi INSERT, UPDATE i DELETE.
Jednim programom se može predstaviti sekvenca transakcija, iako je najčešće jedan
program jedna transakcija.
Transakcije ne mogu biti "ugnježdene", tj. u jednom programu se operacija BEGIN
TRANSACTION može izvršiti samo ako taj program nema nijednu drugu transakciju u
izvršenju. Naredbe: COMMIT i ROLLBACK se izvršavaju samo ako je neka transakcija u
izvršenju.
Transakcije moraju da prate i odgovarajuće izlazne poruke, koje ne smeju da se prenose
direktno, već tek nakon planiranog završetka transakcije (COMMIT ili ROLLBACK).
Posebna pažnja se poklanja sistemu poruka u postupku oporavka baze podataka.
Poruke se ne prihvataju direktno, već se ulazne poruke stavljaju u ulazni red, a izlazne
poruke u izlazni red. Pri planiranju završetka transakcije (COMMIT ili eksplicitni ROLLBACK)
izvršava se:
!" upisivanje log izlazne poruke,
!" stvarno se prenose izlazne poruke i
!" izbacuju se ulazne poruke iz ulaznog reda.
alempije@beotel.yu 141
Pri neplaniranom ROLLBACK (izvršava se automatski ako dođe do neke greške u programu
tipa "overflow", deljenja sa nulom i slično) dolazi do izbacivanja izlaznih poruka iz izlaznog
reda.
Stoga su u MS ACCESS-u elementi transakcionog rada ugrađeni u okviru ACCESS BASIC,
gde su mogući: definisani početak transakcije (BeginTrans), zapisivanje rezultata rada
transakcije (CommitTrans) i vraćanje na stanje pre početka transakcije (Rollback).
Sigurnost podataka
Sigurnost podataka odnosi se na mehanizam zaštite podataka od neovlašćenog korišćenja,
koji je ugrađen u SUBP. Zaštitom podataka se definiše koji subjekt zaštite (npr., Eremija)
nad kojim tabelama (npr., RADNIK) može da izvede neku operacuju (npr., SELECT, UPDATE,
INSERT i DELETE) i pod kojim uslovima (npr., samo za odeljenje 10).
Polazi se od činjenice da je korisnik vlasnik kreirane tabele i da samo on kao vlasnik može
da je koristi osim ako i drugima ne dozvoli pristup. Za dodeljivanje privilegije korišćenja
drugim korisnicima koristi se GRANT naredba koja se sastoji iz tri osnovne klauzule:
GRANT <Privilegija>
ON <tabele ili pogled>
TO <korisnik ili grupa korisnika>
[WITH GRANT OPTION];
Privilegije mogu biti :
!" SELECT,
!" UPDATE,
!" INSERT,
!" DELETE,
!" INDEX,
!" EXPAND (dodavanje atributa relacije),
!" ALL (važi za sve navedene privilegije),
!" RESOURCE (omogućuje korisniku kreiranje objekata baze podataka, kao što su: tabele,
indeksi, klasteri),
!" DBA (obavlja administrativne zadatke, kao što su: CREATE TABLESPACE i CREATE
ROLLBACK SEGMENT),
!" DBA privilegijom korisnik može definisati:
• SELECT iz bilo koje tabele i pogleda,
• CREATE objekata baze podataka za druge korisnike,
• DROP drugih korisnika objekata baze podataka, uključujući tabele, sinonime i
linkovane baze podataka,
• GRANT varijante privilegija baze podataka,
• CREATE public sinonima i linkovanje baze podataka,
• EXPORT i IMPORT baze podataka.
WITH GRANT OPTION daje dozvolu davanja privilegija drugom korisniku.
Kada se, na primer, uvedu privilegije nad tabelom RADNIK, a onda treba da se nekom
drugom da privilegija nad tom tabelom, i to korisniku PERI, piše se ovako:
GRANT SELECT ON RADNIK TO PERA;
Ako bi trebalo da se da nekom drugom privilegija za samo SELECT nad tabelom RADNIK, i
142 alempije@beotel.yu
to korisniku VLADA piše se ovako:
GRANT SELECT ON RADNIK TO VLADA;
Privilegije se mogu davati i za poglede nad naredbama: SELECT, INSERT, UPDATE i DELETE.
Na primer, ako se ne želi da korisnik ALEMPIJE ima pogled na kolone: PLATA i STIMUL, onda
je bolje da se privilegije ograničavaju na pogled, a ne na tabele.
Prvo se definiše pogled na tabelu RADNIK koja ne sadrži kolone: PLATA I STIMUL.
CREATE VIEW ZAPS AS
SELECT SIFRAR,PREZIME,SIFRARM,RUKOV,DATUMZ,SIFRAO
FROM RADNIK;
Može se definisati, kao primer, i pogled nad tabelom RADNIK koja daje podatke samo o
onim zaposlenima sa istim brojem odeljenja koji ima i osoba koja koristi pogled.
CREATE VIEW IMERAD AS
SELECT *
FROM RADNIK
WHERE SIFRAO IN
(SELECT SIFRAO
FROM RADNIK
WHERE PREZIME = USER);
USER definiše ime prijavljenog korisnika. Ako CEBIC, koji je u odeljenju 10, pristupio
pogledu može videti samo zaposlene u odeljenju 10. Ovim pogledom može se dati korisniku
CEBIC privilegija da vrši, npr., ažuriranje na sledeći način:
GRANT SELECT, UPDATE
ON IMERAD
TO CEBIC;
Ako neki zaposleni pređe u drugo odeljenje (polje SIFRAO se menja), novi rukovodilac
automatski dobija pristup podacima dok ga stari rukovodilac gubi.
Kada treba poništiti privilegije koristi se klauzula REVOKE.
Npr., ako se želi oduzeti privilegija korisniku ALEMPIJE za ubacivanje podataka u tabelu
RADNIK piše se:
REVOKE INSERT
ON RADNIK
FROM ALEMPIJE;
Zaključavanje podataka
Zaključavanje podataka je mehanizam za upravljanje konkurentnim pristupom podacima i
izvodi se kada korisnik pokuša da izvrši izmenu nad podacima u bazi podataka.
Zaključavanje se vrši prilikom:
!" sintaksne analize,
!" izvršavanja komandi i
alempije@beotel.yu 143
!" pristupanja redovima.
Postupak zaključavanja prestaje u dva slučaja:
!" kada se transakcija završi (COMMIT/ROLLBACK) i
!" kada se kursor zatvori (logoff).
Postupak zaključavanja tabela i redova je najvažniji deo održavanja konzistentnosti i
integriteta baze podataka korisnika.
Osnovna podela zaključavanja je nad:
!" tabelama rečnika podataka - DDL (Data Definition Language),
!" tabelama korisnika podataka - DML.
DDL način zaključavanja kontroliše pristup bazi podataka i izvodi se automatski nad
tabelama rečnika podataka. Ovaj način zaključavanja upravlja sledećim SQL naredbama:
144 alempije@beotel.yu
!" ako je došlo do otkaza sistema zato što je:
• sama baza podataka oštećena, kada se izvodi oporavljanje baze podataka na osnovu
arhivske kopije, ili
!" baza dovedena (nije oštećena) u neko nekonzistentno stanje i pomoću log-a se
poništavaju sve nekorektne promene, a same transakcije koje su ih proizvele se ponove.
Da bi se omogućio oporavak baze podataka potrebno je, pre svega, razmotriti koje su to
vrste otkaza:
!" planirani ROLLBACK, tj. narušavanje integriteta u nekoj od transakcija koje program
sam otkriva;
!" otkazi u transakciji (lokalna greška, npr., deljenje nulom);
!" sistemski otkaz koji utiče na sve transakcije, ali ne oštećuje bazu podataka (npr.,
nestanak struje);
!" fizičko oštećenje baze podataka.
Otkazi u transakciji
Ako se transakcija završi pre naredbe COMMIT ili eksplicitni ROLLBACK, neophodno je da se
izvrši automatski ROLLBACK. Proceduru ROLLBACK obavlja Recavery Manager, poništavajući
sve promene unazad kroz log, dok se u log-u ne dostigne slog koji označava početak
transakcije.
U toku poništavanja može doći do otkaza i u tom slučaju ROLLBACK procedura mora
startovati ponovo, pa je i to jedan od uslova da transakcija bude što kraća.
Sadržaj bafera se prenosi tek kad se oni napune. "Checkpoint record" sadrži listu svih
transakcija koje su aktivne u trenutku uzimanja "checkpoint-a" i za svaku transakciju
adresu sloga u log-u kojem je poslednjem pristupio.
Algoritam oporavka izvodi se tako što se prvo formiraju liste: "undo", u kojoj su sve
transakcije zapisane u "checkpoint "-u, i "redo", koja je u početku prazna.
Pretraživanje po log-u počinje od "checkpoint record "-a na sledeći način:
!" svaka transakcija za koju se pronađe BEGIN TRANSACTION stavlja se u "undo" listu;
!" svaka transakcija za koju se izvodi COMMIT smešta se u "redo" listu.
Ovakav način memorisanja omogućuje Recavery Manager-u da unazad izvršava "undo"
transakciju, a potom unapred "redo" odgovarajuću transakciju.
Kako u intervalu upisivanja u samu bazu (Log Write-Ahead) i na log može doći do otkaza, a
da bi se obezbedio oporavak baze podataka, prvo se vrši upisivanje na log.
alempije@beotel.yu 145
Otkaz diska
Ako bi došlo do otkaza diska, baza podataka bi se oporavljala na osnovu arhivske kopije i
log-a, obnavljajući sve transakcije od trenutka uzimanja kopije do otkaza. To je veoma
dugotrajan proces i izvodi se, obično, kada nijedna transakcija nije aktivna.
Može se definisati i tzv. inkrementni dump, odnosno na kopiju se prenose samo oni slogovi
koji su pretrpeli promene poslednjeg uzimanja kopije.
Na osnovu definisanog fizičkog dizajna (slika 4.1) u sledećem koraku pristupa se
generisanju šeme baze podataka.
146 alempije@beotel.yu
Aktivnost
3.2. Generisanje šeme baze podataka
Aktivnost "3.2. Generisanje šeme baze podataka" izvodi se na osnovu prethodno urađene
aktivnosti "3.1. Definisanje fizičkog dizajna", tj. definisanih elemenata za izabrani SUBP.
Šemu baze podataka čine fizičke tabele, kolone i relacije, koje se, kao što je rečeno u
prethodnom poglavlju, u CASE alatu automatski generišu iz logičkog modela. Takođe, u
prethodnom poglavlju pokazani su i automatsko kreiranje default tipova podataka za svaku
generisanu kolonu i način izmene specifikacija kolona (domen i validacija podataka).
Proces generisanja šeme baze podataka može se izvesti na dva načina:
!" direktnim inženjerstvom (forward engineering) i/ili
!" inverznim inženjerstvom (reverse engineering).
Proces generisanja šeme baze podataka iz logičkog modela podataka naziva se direktni
inženjering. Kada se generiše šema baze podataka, entiteti prelaze u tabele, atributi u
kolone, a veze u relacije i definišu se referencijalni integritet, trigeri, procedure, indeksi i
druge osobine koje podržava izabrani SUBP.
Dakle, da bi se generisala baza podataka potrebno je, prvo, izabrati odgovarajuću ciljnu
platformu (SUBP) i potom se logovati na nju (slika 4.3). Kada korisnik loguje na izabranu
platformu, ERwin kreira aktivnu bidirekcionu vezu sa sistemskim katalogom izabranog
servera koja omogućava direktno kreiranje baze podataka. MS ACCESS koristiće kao test
SUBP za generisanje šeme baze podataka za primer dokumenta "Karton isplata".
Na slici.4.18. prikazani su za MS ACCESS bazu podataka elementi šeme koja će se
generisati. Šema je struktura baze podataka definisana DDL (Data Definition Language)
skript-fajlom koji će u sledećem poglavlju biti detaljno objašnjen.
Inverzni inženjering predstavlja proces dobijanja fizičkog i logičkog modela iz postojeće
fizičke baze podataka. Mnogi će se zapitati: "Zašto je to potrebno, kad već postoji kreirana
baza koja odrađuje jedan posao". Mora se istaći da je najteža i najskuplja faza - održavanje
baze podataka (videti aktivnost: "4.3.Održavanje" ). Pod održavanjem se podrazumevaju
dogradnja i proširivanje prema zahtevima korisnika. Obično, po završetku "izgradnje"
aplikacije "zaboravlja" se na dokumentaciju, što za posledicu ima otežan proces održavanja
baze podataka. Odlaskom programera iz firme, održavanje postaje problem. Da bi se to
prevazišlo i da bi se mogla uraditi nadgradnja (uzimajući u obzir i zahteve standarda ISO
9000), postupkom inverznog inženjerstva, od fizičke baze podataka dolazi se do polaznog
fizičkog i logičkog modela, tj. dokumentacije koja nedostaje.
alempije@beotel.yu 147
Slika 4.18. Access šema za generisanje BP
ERwin omogućava inverzni inženjering sa dvanaest SQL SUBP upravljanja bazom podataka
(AS/400, DB2, Informix, Ingres, NetWare SQL, ORACLE, Progress, Rdb, SQL Base, SQL
Server, SYBASE i WATCOM SQL) i šest desktop-sistema za upravljanje bazom podataka
(Microsoft Access, FoxPro, Clipper, dBase III, dBase IV i Paradox, prikazanih na slici 4.3).
Dakle, inverznim inženjerstvom iz postojeće fizičke baze podataka kreiraju se fizički i logički
model i zatim uz pomoć CASE alata i editora redizajnira logički model podataka. Jedan od
proizvoda ovog redizajna je i sistemska dokumentacija. Nakon kreiranja logičkog modela
podataka može se, postupkom reinženjeringa poslovnih procesa, struktura baze prebaciti na
drugu ciljnu platformu (drugi format baze podataka). U ERwin-u se može na dva načina
izvršiti inverzni inženjering fizičke baze podataka:
!" direktnom vezom sa ciljnom platformom i
!" otvaranjem i čitanjem SQL skript-datoteke.
No, bilo koji način da se izabere, automatski se kreira novi fizički model podataka. Ako se
koristi direktna veza sa ciljnom platformom, SQL baza podržava deklaraciju prenesenih
ključeva (FOREIGN KEYS). ERwin prepoznaje jake i slabe veze i podrazumevajuće
"rolename" za generisani model podataka. Za DB2, SQL server i SYBASE, ERwin "izvlači" sve
važne informacije o modelu podataka, izuzev podtipova, koji nisu podržani ni od jednog SQL
sistema za upravljanje bazom podataka.
Ako se izabere opcija SQL skript-datoteke, onda ERwin generiše atribute gde primarni ključ
nije u prvoj koloni. Takođe, može se pratiti čitav postupak inverznog inženjeringa baze, kao
i "on-line" ispravljanje grešaka SQL skrpit-datoteke.
Na slici 4.19. prikazan je dekompozicioni dijagram za aktivnost "3.2. Generisanje šeme baze
podataka" koja se sastoji od sledećih aktivnosti:
!" Aktivnost 3.2.1. Kreiranje tabela,
!" Aktivnost 3.2.2. Kreiranje indeksa,
!" Aktivnost 3.2.3. Generisanje poslovnih pravila,
!" Aktivnost 3.2.4. Verifikacija šeme baze podataka.
148 alempije@beotel.yu
Topologija
mre`e
KREIRANJE Tabele
TABELA
3.2.1
GENERISANJE Poslovna
POSLOVNIH ograni~enja
OGRANI^ENJA
3.2.3
Slika 4.19. Dekompozicioni dijagram za aktivnost "3.2. Generisanje šeme baze podataka"
alempije@beotel.yu 149
Aktivnost
3.2.1. Kreiranje tabela
U okviru aktivnosti "3.2.1. Kreiranje tabela" kreiraju se tabele naredbom CREATE TABLE,
koja definiše "praznu" tabelu sa nazivom i imenima kolona sa fizičkog modela podataka
datog u ERwin-u. Podaci se kasnije unose INSERT naredbom ili iz razvijene korisničke
aplikacije.
Opis tabela podrazumeva definisanje naziva tabele, naziva kolone (tip podatka i
ograničenje), određivanje primarnog ključa i, po potrebi, definisanje indeksa po bilo kojoj
koloni ili grupi kolona u tabeli.
Dakle, imena tabela i kolona se automatski preuzimaju iz fizičkog modela definisanog u
ERwin-u, no ako se direktno u SUBP definišu imena moraju se poštovati sledeća uputstva:
!" koristiti opisna imena za tabele, kolone, indekse i druge objekte;
!" biti dosledan u korišćenju skraćenica;
!" koristiti ista imena za opis istih tabela ili kolona;
!" pisati nazive tabela ili kolona u jednini (predlog).
Sintaksa SQL naredbe za kreranje tabela ima sledeću strukturu:
CREATE TABLE tabela (kolona1 tip [ (velicina)] [index1] [, kolona2 tip [ (velicina)] [index2] [, ...]]
[, indexvisekol [, ...]])
Argument Opis
tabela Naziv tabele
kolona1, kolona2 Nazivi kolone ili kolona kojima se kreira nova
tabela
tip Tip podatka za kolonu u novoj tabeli
velicina Veličina kolone u karakterima (za Text
kolone)
index1, index2 Definisanje ograničenja za pojedine kolone
index
indexvisekol Definisanje ograničenja za više kolona index
Korišćenjem ERwin CASE alata za izabran desktop SUBP MS Access izgenerisana tabela
RADNIK (videti tablice 4.1. i 4.2) ima sledeći izgled:
150 alempije@beotel.yu
U naredbi CREATE TABLE specificiraju se:
!" naziv tabele (npr.RADNIKA);
!" imena kolona tabele RADNIK (sifrar, Prezime,...);
!" tip podatka svake kolone.
Na osnovu generisanih tabela u sledećem koraku biće izvršeno generisanje indeksa.
Aktivnost
3.2.2. Kreiranje indeksa
U okviru aktivnosti "3.2.2. Kreiranje indeksa" definišu se indeksi naredbom CREATE INDEX
za određenu tabelu nad jednom ili više kolona neke tabele. Indeks sadrži po jednu stavku za
svaku različitu vrednost indeksirane kolone (ili kolona) u tabeli. U svakoj stavci indeksa
pamte se fizičke adrese redova koji imaju datu vrednost u indeksiranoj koloni/kolonama.
Indeksi se implicitno koriste u sledećim slučajevima:
!" kada se pretražuju tabele po vrednostima indeksiranih kolona (WHERE uslov) i
!" kada se izdvajaju redovi tabele u redosledu vrednosti indesiranih kolona.
Indeks omogućava direktan pristup redovima i tako smanjuje vreme pristupa. Mogu se
kreirati više indeksa za razne kombinacije kolona u istoj tabeli, ali svaki indeks uvećava
vreme ažuriranja.
Dakle, na performanse baze podataka veoma utiče način na koji su podaci fizički smešteni,
tj. memorisani. Kreiranje indeksa pomaže SUBP da locira specifične redove u bazi na isti
način kao indekse u knjizi koji pomažu da se brzo lociraju specifične informacije.
Sintaksa kojom se kreira indeks je:
CREATE [UNIQUE]‚ INDEX Index_ime
ON tabela (kolona [,<kolona2>‚...])
Argument Opis
Index_ime Naziv indeksa koji se kreira
Tabela Naziv tabele nad kojom se indeks formira
kolona Nazivi kolone ili kolona nad kojima se
indeks pravi
Na taj način se sprečava ubacivanje ili modifikovanje reda u kome vrednost ide u
indeksirano polje, duplicirajući bilo koju vrednost polja.
Indeksa nad tabelom može biti koliko se želi, a može se i eksperimentisati da bi se našlo
najpovoljnije rešenje. Preporučuje se da se male tabele ne indeksiraju, već da se to čini
samo sa velikim tabelama.
alempije@beotel.yu 151
Preporuke u radu sa indeksima su sledeće:
!" tabele preko 200 redova indeksirati zbog poboljšanih performansi;
!" zbog preglednosti, ne raditi više od tri indeksa po tabeli;
!" indeksne kolone najčešće koristiti u WHERE ili JOIN klauzuli.
Za tabelu RADNIK generisani su sledeći indeksi:
CREATE UNIQUE INDEX `PrimaryKey`ON`RADNIK` (`Sifrar`);
CREATE UNIQUE INDEX `XAK2RADNIK` ON `RADNIK` (`JMBG`);
CREATE INDEX `XIF1RADNIK` ON `RADNIK` (`Sifrao`);
CREATE INDEX `XIF13RADNIK` ON `RADNIK` (`Sifrarm`);
CREATE INDEX `XIF6RADNIK` ON `RADNIK` (`rukov`);
Aktivnost
3.2.3. Generisanje poslovnih ograničenja
Kroz aktivnost "3.2.3. Generisanje poslovnih ograničenja" treba sagledati potrebu
prilagođavanja definisanog fizičkog modela za konkretno realizovanu bazu podataka.
Ograničenja mogu biti definisana za tabele ili kolone i specificirana kao deo CREATE ili
ALTER TABLE komande u okviru SQL-a. Svrha ograničenja je da se definiše rang validnih
vrednosti. Svaka INSERT, UPDATE, ili DELETE naredba se proverava važećim ograničenjem.
Ograničenje mora biti zadovoljeno da bi naredba uspela.
Generalno govoreći, ograničenjima se definišu domeni kolona, pravila referencijalnog
integriteta (RI), pravila integriteta tabela, kao i dodatna pravila poslovanja.
Ograničenje se definiše ključnom reči CONSTRAINT i nazivom ime_ogranicenja kojim se
specificira ime ograničenja (da li je u pitanju primarni ili preneseni ključ).
Sintaksa SQL za definisanje ograničenja je za:
CONSTRAINT ime_ogranicenja
{PRIMARY KEY (kolonapk1[, kolonapk2 [, ...]]) |
UNIQUE (kolonau1[, kolonau2 [, ...]]) |
FOREIGN KEY (kolonafk1 [, kolonafk2]...)
REFERENCES tabelafk (kolona1[,kolona2]...)
152 alempije@beotel.yu
Mogu se definisti sledeća ograničenja za kolonu ili grupu kolona:
!" ograničenja nad primarnim ključem,
!" ograničenje UNIQUE,
!" ograničenje NOT NULL,
!" ograničenje nad prenesenim ključem,
!" CHECK ograničenje.
CONSTRAINT ime_ogranicenja
{PRIMARY KEY (kolonapk1[, kolonapk2 [, ...]])}
Ako je u pitanju primarni ključ, definiše se ime ograničenja kao, npr., za tabelu RADNIK,
XPKRADNIK. U nastavku se definiše ključna reč PRIMARY KEY, kojom se određuje naziv
kolone kao primarni ključ (Sifrar) tako da se dobije za primer tabele RADNIK sledeći oblik
ograničenja:
Dakle, primarni ključ je odabran kao jedinstven ključ, čija nijedna kolona ne sme da poprimi
NULL vrednost ni u jednom redu. Kada se ovom klauzulom definiše primarni ključ tabele,
SUBP u pozadini implicitno kreira jedinstven indeks i dodatna NOT NULL ograničenja nad
svakom kolonom primarnog ključa.
Kompletna definicija tabele podrazumeva definisanje primarnog ključa. Mora se imati u vidu
da se vrednosti kolona primarnog ključa nikada ne menjaju (ažuriraju), već postupak
ažuriranja treba posmatrati kao brisanje reda i dodavanje reda sa novom vrednošću
primarnog ključa.
Ograničenje UNIQUE
Ograničenje UNIQUE definiše jedinstven ključ tabele nad jednom ili više kolona, tj. svaki red
mora imati različitu vrednost za kolonu, a svaka kolona mora biti deklarisana kao NOT NULL
i ne mora biti primarni ključ.
alempije@beotel.yu 153
od kojih jedan uvek mora biti ispunjen. Ti uslovi glase:
!" vrednost prenesenog ključa u referencirajućoj tabeli mora postojati kao vrednost ključa
(primarnog ili jedinstvenog) u odgovarajućoj referenciranoj tabeli, ili
!" vrednost neke kolone (ili više njih) prenesenog ključa može biti NULL, jer nije u sastavu
primarnog ključa referencirajuće tabele.
Sintaksa za definisanje prenesenog ključa ima sledeći izgled:
CONSTRAINT ime_ogranicenja
{FOREIGN KEY (kolonafk1 [, kolonafk2]...)
REFERENCES korisnik.tabela (kolona[,kolona]...)}
CHECK ograničenje
U CHECK ograničenju, za kolone, uslovi se moraju pozivati na kolone na koje se ograničenje
već odnosilo. Za CHECK ograničenja tabele uslovi se mogu odnositi na više kolona. Po
ANSI/ISO standardu, CHECK ograničenje je narušeno samo ako je izraz lažan, tj. istinite i
nepoznate vrednosti ne narušavaju ograničenje.
Prikaz ograničenja za Oracle SUBP za primer nad tabelom RADNIK ima sledeći izgled:
154 alempije@beotel.yu
CREATE TABLE "RADNIK" (
"Sifrar" VARCHAR2 (6) NOT NULL,
"Prezime" VARCHAR2 (20) NOT NULL,
"Ime" VARCHAR2 (20) NOT NULL,
"Sifrarm" VARCHAR2 (2) NOT NULL,
"JMBG" VARCHAR2 (13) NOT NULL,
"rukov" VARCHAR2 (6) NOT NULL,
"Datumz" DATE DEFAULT Date () NOT NULL
CHECK (<=Date ()),
"Plata" FLOAT NOT NULL
CHECK (>0),
"Stimul" FLOAT DEFAULT 600 NOT NULL
CHECK (stimul BETWEEN 500 AND 100
"Sifrao" VARCHAR2 (2) NULL,
"Pol" VARCHAR2 (1) DEFAULT M NOT NULL
CHECK (Pol IN ('M', 'Z')),
"vrsta" VARCHAR2 (1) DEFAULT 2,
PRIMARY KEY ("Sifrar"),
FOREIGN KEY ("Sifrarm")
REFERENCES "SIFRARM",
FOREIGN KEY ("rukov")
REFERENCES "RADNIK",
FOREIGN KEY ("Sifrao")
REFERENCES "ODELJENJE");
U sledećem primeru biće generisana ograničenja za dokument "Karton isplata".
Model baze
podataka
primera
dokumenta
"Karton
isplata"
realizovan u
MS ACCESS-
u
Slika 4.20. Fizički model podataka i model baze podataka za dokument "Karton isplata"
Generisanjem fizičkog modela iz ERwin-a u konkretni model baze podataka - MS ACCESS,
automatski se uspostavljaju relacije između polja u selektovanim tabelama prema
indeksima definisanim nad tim tabelama. Relacija se ovde definiše kao odnos između polja u
alempije@beotel.yu 155
različitim tabelama baze podataka. Relacije između polja tabela se uspostavljaju po sličnosti
(jednakosti) naziva, tipa i veličine polja. Na slici 4.21. prikazana je relacija između tabela:
RADNIK i ODELJENJE.
Slika 4.21. MS ACCESS relacija između tabela: RADNIK i ODELJENJE sa slike 4.20.
U okviru relacije se definiše i tip Join (slika 4.21, tipka Join Type...). Postoje tri tipa Join,
između MS ACCESS tabela:
!" biraju se samo redovi koji u veznim poljima imaju iste sadržaje (Iner Join);
!" biraju se svi redovi iz prve tabele i samo oni redovi iz druge tabele čiji je sadržaj veznih
polja jednak sa sadržajem u prvoj tabeli (Left Join);
!" biraju se svi redovi iz druge tabele i samo oni redovi iz prve tabele čiji je sadržaj veznih
polja jednak sadržaju veznih polja druge tabele (Right Join).
156 alempije@beotel.yu
U poglavlju 4.3. u okviru aktivnosti "3.3.3. Definisanje upita" biće razmatrana detaljno
problematika Join-a.
U Odeljenju je zaposleno više Radnika a Radnik radi u nula ili jednom Odeljenju.
ERwin MS ACCESS
I:SN zaposljava
U:SN D:SN
RADNIK U:SN ∞ 1 ODELJENJE
ODELJENJE RADNIK
Na slici 4.22. dat je uporedni prikaz kardinalnosti veza i referencijalnog integriteta u ERwin-
u i generisanih kardinalnosti i relacija u MS ACCESS-u.
Referencijalni integritet fizičkog modela definisanog u ERwin-u ima sledeće operacije:
alempije@beotel.yu 157
u i generisanih kardinalnosti i relacija u MS ACCESS-u.
Referencijalni integritet relacija na nivou MS ACCESS-a (slika 4.23) pokazuje da je opcija
Cascade Update Related Fields uključena, što znači da promena vrednosti polja (Sifrarm) u
tabeli SIFRARM izaziva promenu vrednosti polja (Sifrarm) i u tabeli RADNIK.
Referencijalni integritet fizičkog modela definisanog u ERwin-u ima sledeće operacije:
ERwin MS ACCESS
I:R pripada
U:R D:R
RADNIK ∞ 1
U:R RADNIK RADNOM
P
RADNOM
158 alempije@beotel.yu
Slika 4.24. Uporedni prikaz kardinalnosti i referencijalnog integriteta u ERwin i MS ACCESS-u
alempije@beotel.yu 159
Generisanje relacije RADNIK-MUSKARAC-ZENA
ERwin MS ACCESS
RADNIK
D:C
U:C Pol
1 ∞
I:R I:R RADNIK MUSKARAC
U:R U:R
MUSKARAC ZENA
160 alempije@beotel.yu
Generisanje relacije RADNIK-KONSULTANT-REDOVNI
Kardinalnost veza u ERwin-u i kardinalnost relacija u MS ACCESS-u glasi (slika 4.26):
Radnik može biti REDOVAN, KONSULTANT ili neki drugi tip radnika.
Na slici 4.26. dat je uporedni prikaz kardinalnosti veza i referencijalnog integriteta u ERwin-
u i generisanih kardinalnosti i relacija u MS ACCESS-u.
Referencijalni integritet relacija na nivou MS ACCESS-a (slika 4.25) pokazuje da je opcija
Cascade Update Related Fields uključena, što znači da promena vrednosti polja (Sifrar) u
tabeli RADNIK izaziva promenu vrednosti polja (Sifrar) ili u tabeli KONSULTANT ili REDOVNI,
a uključena opcija Cascade Delete Related Records definiše automatsko brisanje reda tabele
KONSULTANT ili REDOVNI za izbrisan red tabele RADNIK po vrednosti primarnog ključa
Sifrar.
ERwin MS ACCESS
RADNIK
D:C
U:C Vrsta 1 ∞
RADNIK REDOVNI
I:R I:R
U:R U:R
KONSULTANT REDOVNI
alempije@beotel.yu 161
Generisanje relacije RADNIK-CERTIFIKAT
Kardinalnost veza u ERwin-u i kardinalnost relacija u MS ACCESS-u glasi (slika 4.27):
Radnik može posedovati više certifikata, a certifikat poseduje tačno jedan radnik.
Na slici 4.27. dat je uporedni prikaz kardinalnosti veza i referencijalnog integriteta u ERwin-
u i generisanih kardinalnosti i relacija u MS ACCESS-u.
ERwin MS ACCESS
I:R D:R je dat
U:R U:R
1 ∞
CERTIFIKAT RADNIK RADNIK CERTIFIKAT
162 alempije@beotel.yu
ERwin MS ACCESS
I:R D:R je dat
U:R U:R
1 ∞
CERTIFIKAT JEZIK RADNIK ISPLATA
alempije@beotel.yu 163
Referencijalni integritet relacija na nivou MS ACCESS-a (slika 4.28) pokazuje da opcija
CASCADE nije uključena, što znači da se operacije menjanja i brisanja izvode nezavisno.
164 alempije@beotel.yu
Aktivnost
3.2.4. Verifikacija šeme baze podataka
RADNOM RADNIK
JEZIK ODELJENJE
D:R Sifrar: Text(6) I:SN D:SN
Sifrarm: Text(2)
Sifraj: Text(2) U:R U:SN U:SN Sifrao: Text(2)
Nazivrm: Text(20) Prezime: Text(20) (IE1)
Nazivj: Text(20) I:R Ime: Text(20) (IE1) D:C Nazivo: Text(20)
U:R Sifrarm: Text(2) U:C Mesto: Text(20)
D:R I:SN
I:R JMBG: Text(13) (AK2) I:R
U:R P U:SN
U:R D:R rukov: Text(6) U:R ISPLATA
CERTIFIKAT U:R Datumz: Date/Time Sifrar: Text(6)
I:R Plata: Double rbr: Text(2)
Sifrar: Text(6) U:R D:C
D:C Stimul: Double
Sifraj: Text(2) U:C Datumis: Date/Time
U:C Sifrao: Text(2)
Pol: Text(1) Iznos: Double
Stepen: Text(10) Vrsta
Pol vrsta: Text(1) I:R
I:R I:R I:R
U:R U:R
U:R U:R D:SN
U:SN KONSULTANT REDOVNI
MUSKARAC ZENA
Sifrar: Text(6) Sifrar: Text(6)
Sifrar: Text(6) Sifrar: Text(6)
Brojs: Integer Vrstap: Text(18)
Sluziov: Text(2) Prezimed: Text(20)
U sledećim tabelama biće prikazan SQL skript generisanih tabela u MS ACCESS-u, kao i
izvršena verifikacija šeme unošenjem test-podataka. Na slici 4.30. prikazan je fizički model
koji je korišćen da ERwin izgeneriše šeme baze podataka, tj. odgovarajuće tabele.
alempije@beotel.yu 165
U tablici br 4.5. prikazana je kompletna šema za tabele: RADNIK i ODELJENJE.
Tablica 4.5.
RADNIK ODELJENJE
166 alempije@beotel.yu
RADNIK
Sifra Prezime Ime Sifr JMBG: rukov: Datumz Plata Stim Si P Vr
827369 STEVIC ZORAN 01 1411952171033 827902 28/03/98 8000 600 2 M 2
827499 ALAGIC MILAN 02 2503964345612 827698 28/03/98 1600 600 3 M
827521 VUKIC MILOS 02 1130497055432 827698 28/03/98 1250 600 3 M 2
827566 JOVIC MIRA 03 1130497056435 827839 28/04/90 2975 700 2 Z 1
827654 MARTIC ZORA 02 1140496055444 827698 12/06/88 1250 1000 3 Z 1
827698 BOBIC IVAN 03 1405987055455 827839 15/11/89 2850 800 3 M 2
827782 CEBIC GORAN 03 1203970654566 827839 11/06/80 2450 500 1 M 2
827788 SUSIC ZORAN 04 1304954676755 827566 23/10/91 3000 650 2 M 2
827839 KLJAKIC STEVA 05 1312952122344 827839 06/12/87 5000 600 1 M 2
827844 TUBIC MIRA 02 1312954342122 827698 08/03/78 1500 600 3 Z 1
827876 ALIMPIC PETAR 01 2503976343566 827788 09/05/92 1100 780 2 M
827900 JAKIC VLADA 01 1211965457231 827698 28/03/90 9500 900 3 M
827902 FILIPIC DRAGA 04 1210970534221 827566 20/11/96 3000 1000 2 M 2
827934 MILIC DRAGA 01 0706956456465 827782 28/03/93 1300 790 1 M 2
Tablica 4.6.
SIFRARM JEZIK
CREATE TABLE `SIFRARM` CREATE TABLE `JEZIK` (`Sifraj`
(`Sifrarm` TEXT (2), TEXT (2),
`Nazivrm` TEXT (20), `Nazivj` TEXT (20),
CONSTRAINT `XPKSIFRARM` CONSTRAINT `XPKJEZIK`
PRIMARY KEY (`Sifrarm`)); PRIMARY KEY (`Sifraj`));
CREATE UNIQUE INDEX CREATE UNIQUE INDEX
`PrimaryKey` ON `SIFRARM` `PrimaryKey` ON `JEZIK`
(`Sifrarm`); (`Sifraj`);
SIFRARM JEZIK
Sifrarm Nazivrm Sifraj Nazivj
01 PROJEKTANT 01 ENGLESKI
02 REFERENT 02 NEMACKI
03 DIREKTOR 03 RUSKU
04 TEHNOLOG 04 FRANCUSKI
05 GEN DIR
alempije@beotel.yu 167
U tablici 4.7.prikazana je kompletna šema za tabele: CERTIFIKAT i ISPLATA.
Tablica 4.7.
CERTIFIKAT ISPLATA
CREATE TABLE `CERTIFIKAT` ( CREATE TABLE `ISPLATA` (
`Sifrar` TEXT (6), `Sifrar` TEXT (6),
`Sifraj` TEXT (2), `rbr` TEXT (2),
`Stepen` TEXT (10), `Datumis` DATETIME,
CONSTRAINT `XPKZNA JEZIK` `Iznos` FLOAT8,
PRIMARY KEY (`Sifrar`, CONSTRAINT `XPKISPLATA`
`Sifraj`), PRIMARY KEY (`Sifrar`,`rbr`),
CONSTRAINT `vazi` CONSTRAINT `prima`
FOREIGN KEY (`Sifraj`) FOREIGN KEY (s ifrar)
REFERENCES `JEZIK` (`Sifraj`), REFERENCES`RADNIK`
CONSTRAINT `je dat` (`Sifrar`));
FOREIGN KEY (`Sifrar`) CREATE UNIQUE INDEX
REFERENCES `RADNIK` `PrimaryKey` ON `ISPLATA`
(`Sifrar`)); (`Sifrar`,`rbr`);
CREATE UNIQUE INDEX CREATE INDEX `XIF2ISPLATA`
`PrimaryKey` ON `CERTIFIKAT` ON `ISPLATA` (`Sifrar`);
(`Sifrar`,`Sifraj`);
CREATE INDEX `XIF3ZNA JEZIK`
ON `CERTIFIKAT` (`Sifrar`);
CREATE INDEX `XIF4ZNA JEZIK`
ON `CERTIFIKAT` (`Sifraj`);
168 alempije@beotel.yu
Za kreirane tabele: REDOVNI i KONSULTANT verifikacija je izvršena unošenjem sledećih test
primeraka:
KONSULTANT REDOVNI
Sifrar Brojs Sifrar Vrstap
827654 10 827369 01
827698 5 827499 02
827782 15 827521 01
827788 12 827566 03
Na osnovu generisane šeme i verifikovanih tabela za fizički model sa slike 4.29. pristupa se
izradi odgovarajuće aplikacije kroz aktivnost "3.3 Specifikacija aplikacije", što je predmet
daljih razmatranja.
Na osnovu prethodno izvedenih aktivnosti (slika 4.1) u sledećem koraku pristupa se izradi
aplikacije.
alempije@beotel.yu 169
Aktivnost
3.3. Izrada aplikacije
Aktivnost "3.3. Izrada aplikacije" izvodi se na osnovu prethodno urađene šeme baze
podataka, kao i konkretnih zahteva budućih korisnika. Specifikacija forme se izvodi za
sledeće aktivnosti (slika 4.31):
!" Aktivnost 3.3.1. Definisanje menija,
!" Aktivnost 3.3.2. Definisanje izgleda forme,
!" Aktivnost 3.3.3. Definisanje upita i
!" Aktivnost 3.3.4. Definisanje izveštaja.
C1
Topologija
mre`e
Informacije Definisan
od korisnika DEFINISANJE meni
I2 MENIJA
3.3.1
DEFINISANJE Definisane
IZGLEDA forme
FORME
I1 3.3.2
[ema baze
podataka Izvo|a~ki
projekat
DEFINISANJE O1
UPITA Upiti
3.3.3
DEFINISANJE
IZVE[TAJA
3.3.4Izve{taji
170 alempije@beotel.yu
!" odgovarajućeg razvojnog okruženja aplikacije klijent,
!" korisničkog interfejsa u aplikacijama klijent.
Korišćenje aplikacije klijent podrazumeva da korisnici unose, pretražuju i analiziraju
podatke, a administrator koristi servisne programe za održavanje servera i da projektanti
izrađuju aplikacije klijent.
Razvojno okruženje aplikacije klijent obuhvata:
!" unos podataka korišćenjem formi,
!" direktnu transakcionu obradu pomoću formi,
!" izradu upita i
!" izradu izveštaja korišćenjem alata za razvoj aplikacija.
Unos podataka korišćenjem formi treba da omogući automatsku proveru pravila integriteta
i pri tom, ako pravila integriteta nisu ispunjena, treba da ponudi listu dozvoljenih vrednosti,
imajući u vidu i mogućnost multimedijalnog prikaza (npr., uputstva za rad sa formom).
Direktna transakciona obrada ili, kako se još definiše, Online transaction processing-OLTP,
pod transakcijom podrazumeva operaciju za dodavanje ili ažuriranje podataka u bazi, gde
aplikacija šalje zahtev za ažuriranje podataka serveru baze podataka, a server ažurira bazu i
registruje transakciju (videti glavu 4.1).
Upiti i izveštaji su posebne aplikacije gde se može definisati izveštaj od više kolona ili, pak,
jedan zapis na strani ili grafički izveštaji. Izveštaji se najčešće prave kao rezultat AD-HOCK
upita.
Alati za razvoj aplikacija mogu biti jezici treće generacije: C++, ADA, COBOL ili jezici četvrte
generacije: Oracle Forms, Card, Reports i Graphics, MS ACCESS korišćenjem - CASE alata.
Korisnički interfejsi u aplikacijama klijent mogu biti tekstualni korisnički interfejs (CUI -
Character-based User Interface) ili grafički korisnički interfejs (GUI - Graphical User
Interface).
U daljem tekstu detaljno će biti obrazložene aktivnosti prikazane na slici 4.31.
Aktivnost
3.3.1. Definisanje menija
Definisani meniji treba da prate scenario odvijanja aktivnosti budućeg korisnika. Za
definisanje menija moraju se koristiti odgovarajuća pravila za strukturiranje kojima se
definiše mogući redosled pozivanja operacija.
Meniji treba da se definišu na takav način:
!" da svaki meni ima koncizan naslov na vrhu;
!" da meniji koji zauzimaju ceo ekran budu balansirani;
!" da se razdvajaju liste opcija na više celina;
!" da se ograniči broj izbora u meniju na jedan ekran;
!" da se razmisli o selekciji menija;
!" da se omogući napuštanje menija bez izbora bilo koje opcije;
!" da se koriste aktivne imenice za opis opcija menija;
!" da se koriste nedvosmislene ikone;
!" da se izbegava često naglašavanje;
!" da se omogući korišćenje i malih i velikih slova,
!" da se proveri tastatura pre upotrebe;
!" da se izabere jasna, opštepoznata, kratka reč za komande;
alempije@beotel.yu 171
!" da se omogući korisniku da upotrebi više komandi u jednoj liniji;
!" da se omogući korisniku da dobije listu komandi.
Definisanje menija i kretanje kroz aplikaciju treba da odražavaju logičan način rada
korisnika aplikacije, stoga su oni povezani sa sledećom aktivnosti: "3.3.2 Definisanje izgleda
forme" .
Aktivnost
3.3.2. Definisanje izgleda forme
Ekranske forme su osnovni tip objekata u većini SUBP i treba da omoguće korisniku
predstavljanje podataka iz baze i unos podataka u bazu. Forme u sebi mogu imati veliki broj
drugih objekata (kontrola). Većina SUBP, koji za osnovu imaju MS WINDOWS, podržava tzv.
wizard metodologiju za kreiranje formi. Specifičnosti u izradi formi nisu predmet
razmatranja ove knjige, pa se čitaoci upućuju na literaturu, u zavisnosti koji su SUBP
izabrali. Ovde će biti definisane neke opšte postavke koje se moraju poštovati prilikom
definisanja ekranskih formi.
Dakle, ekranske forme treba da ispune sledeće karakteristike:
!" opšte kakrakteristike:
• svaka forma mora imati naslov;
• formi dati samo ono što korisniku treba;
• obezbediti simetriju i balans na ekranu;
• u slučaju pojavljivanja više formi, naznačiti u kojoj se formi korisnik nalazi;
• omogućiti korišćenje malih i velikih slova u tekstu;
• definisati praznu liniju između svakog paragrafa;
• tekst poravnavati na levu stranu;
• biti pažljiv sa skraćenicama i akronimima;
!" tabele i liste:
• redovi i kolone u listama moraju imati imena;
• liste ređati u prepoznatljivom redosledu;
• koristiti vertikalne kolone, jer su preglednije za čitanje;
• tekst u kolonama poravnavati nalevo, a brojeve nadesno;
• svaka peta linija treba da bude prazna linija;
• ostaviti bar dva mesta prazna između kolona;
• numerisati liste počev od 1, a ne od 0;
• razbiti niz slova u kraće podnizove;
!" naglašavanje:
• ne preterivati sa naglašavanjem;
• treptanje i zvuke upotrebljavati samo kao alarm;
• naglašeni tekst treba da bude razumljiv;
• boje birati iz sredine duginog spektra;
• biti dosledan u prikazima i naglašavanju;
!" unos podataka:
172 alempije@beotel.yu
• pri unosu podataka iz formulara kopirati izgled formulara;
• grupisati polja po kategorijama i staviti nazive;
• ne unositi unapred poznate podatke;
• u svakom polju obezbediti memorisanje polja;
• uvesti kad je moguće podrazumevanu (default) vrednost;
• omogućiti help na nivou polja;
• omogućiti slobodno kretanje među poljima za unos podataka;
• forma je jedinica prenosa podataka;
• omogućiti korisniku da odustane od unosa.
Na slici 4.32. prikazan je primer realizovane forme za dokument "Karton isplata". Forma je
podeljena u jednu glavnu formu i dve podforme. U glavnoj formi definišu se ekranska polja
o radnicima, kao što su: SIFRAR, PREZIME, IME, PLATA, STIMUL i DATUMZ koji odgovaraju
definisanim kolonama u okviru tabele RADNIK. Ekransko polje SIFRAR odgovara koloni
Sifrar u tabeli RADNIK koji je definisan kao primarni ključ.
U okviru glavne forme definisana su ekranska polja: SIFRAO i SIFRARM kao tzv. ComboBox
za prenesene ključeve Sifrao i Sifrarm u tabeli RADNIK. ComboBox nudi listu za izbor iz
tabela: SIFRARM i ODELJENJE, gde su Sifrao i Sifrarm primarni ključevi (videti sliku 4.32).
U okviru glavne forme realizovane su specijalizacije Pol i Vrsta. Prva specijalizacija Pol
zahteva obavezan unos podatka o radniku, dok druga specijalizacija Vrsta (Tip zaposlenog
sa slike 4.32) ne zahteva unos, već se ažuriranje radi po potrebi (default NULL opcija).
Definisane su i dve podforme vezane za: isplate radnika i stepen poznavanja jezika (slika
4.32). Podforma sadrži vezu sa glavnom formom. Veza između polja glavne forme i
podforme ostvaruje se preko veznih polja sa glavne forme i veznih polja na podformi. Za
podformu isplate radnika vezno polje je Sifrar koje je definisano u glavnoj formi i podformi a
koje je prikazano i u fizičkom modelu podataka.
Podforma stepen poznavanja jezika, vezana je za glavnu formu preko polja Sifrar sa
tabelom CERTIFIKAT. U okviru ove podforme je definisano ekransko polje JEZIK koji
uspostavlja vezu sa tabelom JEZIK preko ComboBox za polje Sifraj.
RADNOM RADNIK
JEZIK D:R ODELJENJE
Sifrar I:SN D:SN
Fizički
Sifrarm
Sifraj U:R U:SN zaposljava U:SN Sifrao
Nazivrm pripada Prezime (IE1)
D:C Nazivo
model
Nazivj I:R Ime (IE1)
vazi U:C prima Mesto
U:R Sifrarm (FK)
D:R
I:R JMBG (AK2) I:SN I:R
U:R
podataka
P U:SN
U:R D:R rukov (FK) U:R ISPLATA
CERTIFIKAT U:R Datumz Sifrar (FK)
za Sifrar (FK)
I:R
U:R je dat D:C
Plata
Stimul D:C
rbr
Sifraj (FK) U:C Datumis
U:C Sifrao (FK)
primer Stepen
Pol
Pol
vrsta
Vrsta
Iznos
I:R
I:R I:R I:R
U:R
dokumenta U:R U:R D:SN U:R
KONSULTANT REDOVNI
MUSKARAC ZENA U:SN
rukovodi Sifrar (FK)
Sifrar (FK) Sifrar (FK) Sifrar (FK)
"Karton Sluziov Prezimed Brojs
Vrstap
isplata"
alempije@beotel.yu 173
Ekranska
forma za
dokument
"Karton
isplata"
174 alempije@beotel.yu
Aktivnost
3.3.3. Definisanje upita
U okviru aktivnosti "3.3.3. Definisanje upita" pokazan je na dosadašnjem primeru fizički
realizovan model podataka u SUBP. Predmet posmatranja je set zajedničkih komandi i
funkcija definisanih ISO standardom za SQL i realizovanih u različitim SUBP. Upiti su
testirani u okviru MS ACCESS-a. Specifičnosti SQL za MS ACCESS nisu razmatrane već se
čitaoci upućuju na literaturuŠ4Ć.
Za prikaz načina postavljanja upita koristi se deo modela baze podataka sa slike 4.20.
prikazan na slici 4.33.
Pozivanje i dobijanje željenih podataka iz baze podataka su najčešće SQL operacije. Ovaj
postupak se naziva QUERY (query znači pitanje ili upit), a izvršava se SELECT naredbama.
Osnovna podela upita je na:
!" upiti nad jednom tabelom i
!" upiti nad više tabela.
SELECT izvlači redove i kolone iz jedne ili više tabela. U stvari, SELECT naredba je, sama po
sebi, upit, a može biti i podupit kada je klauzula u drugoj naredbi.
SELECT klauzula se uvek prva upisuje i odmah iza nje sledi FROM klauzula i njome se
pretražuju informacije iz baze podataka, implementirajući sve operatore relacione algebre.
Klauzule moraju biti prikazane jedna iznad druge kada su korišćene zajedno.
Očigledno je da SELECT odgovara operaciji projekcije u relacionoj algebri. Iskaz FROM se
može smatrati ekvivalentnim operaciji Dekartovog proizvoda (u relacionoj algebri), a iskaz
WHERE (o čemu će biti više reči kasnije) ekvivalentnim operaciji selekcije u relacionoj
algebri, jer uslov zadovoljavaju selektovane n-torke u rezultatu (videti prilog br. 1).
Prvo treba pogledati podatke u tabeli ODELJENJE, a potom i u tabeli RADNIK.
Ako se izlistaju svi redovi i sve kolone tabele ODELJENJE, upit koji će dati željeni rezultat je:
alempije@beotel.yu 175
SELECT SIFRAO, NAZIVO, MESTO
FROM ODELJENJE
U ovom primeru upita izlistana su imena svih kolona tabele ODELJENJE (SIFRAO, NAZIV,
MESTO) SELECT naredbom.
Međutim, mnogo jednostavnije je da se izlistaju sve kolone neke tabele korišćenjem znaka
"*", odnosno (SELECT *), umesto da se nabrajaju sve kolone tabele pojedinačno.
Na primeru tabele RADNIK to izgleda ovako:
SELECT *
FROM RADNIK
176 alempije@beotel.yu
Rezultat SQL upita je:
SIFRA PREZIM IME SI JMBG RUKO DATUMZ PLAT STIM SI P V
827369 STEVIC ZORAN 0 141195217103 827902 28/03/98 8000 600 2 M 2
827499 ALAGIC MILAN 0 250396434561 827698 28/03/98 1600 600 3 M
827521 VUKIC MILOS 0 113049705543 827698 28/03/98 1250 600 3 M 2
827566 JOVIC MIRA 0 113049705643 827839 28/04/90 2975 700 2 Z 1
827654 MARTIC ZORA 0 114049605544 827698 12/06/88 1250 1000 3 Z 1
827698 BOBIC IVAN 0 140598705545 827839 15/11/89 2850 800 3 M 2
827782 CEBIC GORAN 0 120397065456 827839 11/06/80 2450 500 1 M 2
827788 SUSIC ZORAN 0 130495467675 827566 23/10/91 3000 650 2 M 2
827839 KLJAKIC STEVA 0 131295212234 827839 06/12/87 5000 600 1 M 2
827844 TUBIC MIRA 0 131295434212 827698 08/03/78 1500 600 3 Z 1
827876 ALIMPIC PETAR 0 250397634356 827788 09/05/92 1100 780 2 M
827900 JAKIC VLADA 0 121196545723 827698 28/03/90 9500 900 3 M
827902 FILIPIC DRAGA 0 121097053422 827566 20/11/96 3000 1000 2 M 2
827934 MILIC DRAGA 0 070695645646 827782 28/03/93 1300 790 1 M 2
Ako korisnik ne želi da vidi sve kolone tabele, onda u SELECT klauzulu uključuje imena
samo onih kolona koje želi da vidi, kao što je prikazano sledećim upitom.
SELECT NAZIVO, SIFRAO
FROM ODELJENJE
alempije@beotel.yu 177
Dograđena sintaksa naredbe SELECT ima sledeći izgled:
SELECT [DISTINCT] kolona [,kolona...]
FROM tabela
[WHERE uslov_selekcije]
Treba zatim posmatrati i primer selektovanja kolona: Sifrar, Prezime, Ime, Plata, Sifrao
tabele RADNIK koji NE rade u odeljenju 30, operatorom negacije NOT i operatorom
poređenja "=":
SELECT Sifrar, Prezime, Ime, Plata, Sifrao
FROM RADNIK
WHERE NOT ( SIFRAO = '30')
178 alempije@beotel.yu
Operatori ranga (BETWEEN i NOT BETWEEN)
Operator BETWEEN omogućava da se izaberu redovi koji sadrže vrednosti u nekom rasponu,
a koje je korisnik specificirao.
Na primer, treba videti listu svih zaposlenih Radnika, čija je plata u rasponu 12000 i 14000.
SELECT PREZIME, PLATA
FROM RADNIK
WHERE PLATA BETWEEN 12000 AND 14000
Rezultat SQL upita je:
PREZIM PLATA
VUKIC 12500
MARTIC 12500
MILIC 13000
Operator NOT BETWEEN omogućava da se izaberu redovi koji su van vrednosti u nekom
rasponu, a koje je korisnik specificirao.
Na primer, treba videti listu svih zaposlenih RADNIKa, čija plata NIJE u rasponu 12000 i
14000.
NOT IN operator omogućava da se izaberu redovi koji NE sadrže vrednost koja je jednaka
alempije@beotel.yu 179
jednoj od vrednosti navedene liste.
Na primer, pogledati sva odeljenja čiji broj nije 10 ili 30.
SELECT *
FROM ODELJENJE
WHERE SIFRAO NOT IN ('10', '30')
U ovom primeru korišćen je SQL LIKE operator, da bi se SQL usmerio na pozivanje svih onih
redova iz tabele RADNIK, čija kolona PREZIME sadrži vrednost koja odgovara LIKE klauzuli.
U navedenom uzorku to je ('?U*'). Upitnik (?) označava poziciju jednog karaktera, a znak *
označava bilo koji niz nula ili niz više karaktera.
Rezultat SQL upita je:
PREZIM
VUKIC
SUSIC
TUBIC
Treba, međutim, pokazati NOT LIKE operator i na primeru spiska svih Radnika koji nemaju
"U" kao drugo slovo u prezimenu.
SELECT PREZIME
FROM RADNIK
WHERE PREZIME NOT LIKE '?U*'
180 alempije@beotel.yu
Prezime Ime Vrsta:
ALAGIC MILAN
ALIMPIC PETAR
JAKIC VLADA
Korišćenjem IS NOT NULL operatora mogu se selektirati redovi koji su NOT NULL. U primeru
je dat spisak svih radnika kojima je definisana kolona Vrsta.
SELECT Prezime, Ime, Vrsta
FROM RADNIK
WHERE VRSTA IS NOT NULL;
Višestruki uslovi pretraživanja se vezuju za reč AND (SIFRARM = '03' AND PLATA > 28000).
AND konektor znači da željeni podatak mora da "sretne" sve navedene uslove pretraživanja,
pre nego što SQL da traženi red. U WHERE klauzulu pomoću AND konektora može se dodati
neograničeni broj ovakvih uslova.
Rezultat SQL upita je:
PREZIME SIFRARM PLATA
JOVIC 03 29750
BOBIC 03 28500
Alternativni uslov pretraživanja, tzv. OR konektor selektuje redove koji udovoljavaju bilo
kojem od više datih uslova.
Na primer, pretpostavka je da se u dosadašnjem primeru želi dobiti i lista DIREKTORA (03),
ili svih onih koji zarađuju više od 28000 dinara.
SELECT PREZIME, SIFRARM, PLATA
FROM RADNIK
WHERE SIFRARM ='03'
OR PLATA > 28000
U ovom primeru uslov pretraživanja se povezuje sa rečju OR (SIFRARM = '03' OR PLATA >
28000). OR znači da ako naredni podatak udovoljava jednom od uslova, SQL će izdati
željeni red.
alempije@beotel.yu 181
Rezultat SQL upita je:
PREZIME SIFRAR PLATA
JOVIC 03 29750
BOBIC 03 28500
CEBIC 03 24500
SUSIC 04 30000
KLJAKIC 05 50000
FILIPIC 04 30000
Na primer, treba kreirati tabelu PRIMANJA ako se iz tabele RADNIK selektuju prezime i suma
plate i stimulacije za sve Radnike sa SIFRARM= '02'.
SELECT PREZIME,PLATA+STIMUL AS UKUPNO
INTO PRIMANJA
FROM RADNIK
WHERE SIFRARM = '02'
182 alempije@beotel.yu
Sortiranje redova pomoću ORDER BY klauzule
Korišćenjem klauzule ORDER BY kontroliše se redosled prikazivanja redova. Ova klauzula se
dodaje na kraju SELECT naredbe.
Dograđena sintaksa naredbe SELECT ima sledeći izgled:
SELECT [DISTINCT] kolona [,kolona...]
FROM tabela
[WHERE uslov-selekcije]
ORDER BY (izraz|pozicija)[ASC | DESC]
Na primer, ako se želi prikazati lista zaposlenih u odeljenju 30, ali da odgovarajući redovi
budu prikazani po stavci plate, u rastućem redosledu treba napisati:
SELECT PLATA, SIFRARM, PREZIME
FROM RADNIK
WHERE SIFRAO= '30'
ORDER BY PLATA
alempije@beotel.yu 183
tabelu.
Sintaksa ove klauzule ima sledeći izgled:
Svaki red dobijenog rezultata reprezentuje jednu grupu redova, memorisanu u tabeli
RADNIK, tj. svaki je red tabele RADNIK stavljen u jednu od tri grupe.
Dakle, GROUP BY klauzula omogućuje dobijanje sumarnih informacija za svaku različitu
vrednost kolone po kojoj se vrši grupisanje.
184 alempije@beotel.yu
Sifrarm: AVG
01 10375
02 14000
03 27583
04 30000
05 50000
Treba prikazati šifru odeljenja i srednju aritmetičku vrednost za odeljenje koje ima više od
tri zaposlena radnika u odeljenju korišćenjem HAVING klauzule.
SELECT SIFRAO, AVG (PLATA)
FROM RADNIK
GROUP BY SIFRAO
HAVING COUNT (*) > 3;
Rezultat SQL upita je:
Sifrao AVG (PLATA)
20 18125.2
30 15666.7
Grupni upiti
Grupni upiti vraćaju rezultate koji su karakteristika neke grupe redova umesto jednog reda.
Redovi koji zadovoljavaju uslov selekcije predstavljaju grupu nad kojom se izračunava jedna
ili više grupnih funkcija.
Na primer, korišćenjem COUNT funkcije treba izračunati broj zaposlenih radnika u odeljenju
20:
SELECT COUNT (*)
FROM RADNIK
WHERE SIFRAO = '20'
Pored grupne funkcije COUNT, mogu se definisati i sledeće grupne funkcije nad numeričkim
vrednostima:
!" AVG - izračunava srednju aritmetičku vrednost;
!" SUM - izračunava ukupni zbir;
!" MIN - nalazi minimalnu vrednost;
!" MAX - nalazi maksimalnu vrednost.
Funkcija AVG ([DISTINCT|ALL]‚n) izračunava srednju aritmetičku vrednost ignorišući null
vrednosti.
alempije@beotel.yu 185
Tako, ako se želi izračunati srednja aritmetička vrednost plata radnika, treba pisati:
SELECT AVG (PLATA)AS SREDNJA_ARIT_VRED
FROM RADNIK
MAX (PLATA)
16000
186 alempije@beotel.yu
Podupit sa povratkom jednog reda
Podupit sa povratkom jednog reda treba posmatrati kroz primer definisanja najmanje plate
u tabeli ODELJENJE.
Podupiti se rešavaju u dva koraka.
Prvo se nalazi minimalna plata u tabeli RADNIK:
SELECT MIN (PLATA) FROM RADNIK
Drugi korak je da se nađe ime radnika i posao sa najmanjom platom u tabeli RADNIK
korišćenjem ugnježdenog podupita:
SELECT PREZIME,SIFRARM,PLATA
FROM RADNIK
WHERE PLATA = (SELECT MIN (PLATA)
FROM RADNIK)
Za podupit sa povratkom jednog reda koriste se komparacioni ili logički operatori: =, <, >,
<= i dr.
Skriveni podupit se obrađuje pre glavnog upita, jer je rezultat podupita potreban da bi se
našao rezultat glavnog upita. Druga SELECT naredba u ovom primeru, u okviru skrivenog
podupita, izdvojila je vrednost 03, pošto je to zanimanje radnika JOVIC u tabeli RADNIK.
Rezultat SQL upita je:
PREZIM SIFRAR
JOVIC 03
BOBIC 03
CEBIC 03
Na primer, ako se žele liste svih radnika koji zarađuju više od proseka treba napisati:
SELECT PREZIME,PLATA
FROM RADNIK
WHERE PLATA >
(SELECT AVG (PLATA)
FROM RADNIK)
Rezultat SQL upita je:
alempije@beotel.yu 187
PREZIME PLATA
JOVIC 29750
BOBIC 28500
CEBIC 24500
SUSIC 30000
KLJAKIC 50000
FILIPIC 30000
Kao što se u gornjim primerima vidi, i za podupite sa povratkom više redova mogu se
koristiti komparacioni ili logički operatori: =, <, >, <= i dr.
Podupit sa operatorom IN
Podupit se može upotrebiti i umesto liste vrednosti iza operatora IN. U tom slučaju podupit
može da vraća više redova, od kojih se svaki posmatra kao pojedina vrednost u listi.
Na primer, definisana lista Radnika u odeljenju 10 sa istim SIFRARM u odnosu na odeljenje
30 izgleda ovako:
SELECT PREZIME,SIFRARM
FROM RADNIK
WHERE SIFRAO= '10'
AND SIFRARM IN
(SELECT SIFRARM
FROM RADNIK
WHERE SIFRAO= '30')
188 alempije@beotel.yu
WHERE SIFRAO = '30')
Rezultat SQL upita je:
PREZIME PLATA SIFRAO
ALAGIC 16000 30
VUKIC 12500 30
JOVIC 29750 20
MARTIC 12500 30
BOBIC 28500 30
CEBIC 24500 10
SUSIC 30000 20
KLJAKIC 50000 10
TUBIC 15000 30
ALIMPIC 11000 20
FILIPIC 30000 20
MILIC 13000 10
alempije@beotel.yu 189
Rezultat SQL upita je:
SIFRAO AVG
10 29166,66
20 18125,16
Višestepeni podupiti
Poseban predmet razmatranja u definisanju podupita su višestepeni podupiti kojima se
definiše više uzastopnih upita.
Kao primer višestepenih podupita biće definisani sledeći primeri:
1. Treba izlistati imena radnika koji rade isti posao kao JOVIC ili imaju platu koja je veća od
plate ili jednaka kao plata FILIPIC, i to u rastućem nizu SIFRARM i PLATA:
SELECT PREZIME, SIFRARM, SIFRAO, PLATA
FROM RADNIK
WHERE SIFRARM =
(SELECT SIFRARM
FROM RADNIK
WHERE PREZIME=' JOVIC')
OR PLATA >
(SELECT PLATA
FROM RADNIK
WHERE PREZIME= 'FILIPIC')
ORDER BY SIFRARM, PLATA
Rezultat SQL upita je:
3. Treba Izlistati SVE radnike koji zarađuju više od srednje vrednosti plata u sopstvenom
odeljenju i to prikazati u rastućem redosledu SIFRAO.
SELECT SIFRAO, PREZIME, PLATA
FROM RADNIK X
WHERE PLATA >
(SELECT AVG (PLATA)
FROM RADNIK
WHERE X.SIFRAO= SIFRAO)
ORDER BY SIFRAO
Svakom redu tabele RADNIK dodeljuje se ALIAS X nakon čega se izvodi unutrašnji SELECT
190 alempije@beotel.yu
gde se utvrđuje prosečna plata za odeljenje; ako je manja od plate iz glavnog selecta onda
se prikazuje.
Rezultat SQL upita je:
SIFRAO PREZIME PLATA
10 KLJAKIC 50000
20 FILIPIC 30000
20 SUSIC 30000
30 BOBIC 28500
30 ALAGIC 16000
SELECT PREZIME,MESTO
FROM RADNIK,ODELJENJE
WHERE PREZIME = 'ALAGIC'
AND RADNIK.SIFRAO = ODELJENJE.SIFRAO
Ovaj uslov definiše odnos između tabela: RADNIK i ODELJENJE, tj. broj odeljenja (SIFRAO)
u tabeli RADNIK odgovara broju odeljenja u tabeli ODELJENJE, što je omogućilo spajanje
redova u zajednički.
WHERE klauzula sadrži i uslov PREZIME = 'ALAGIC', koji kaže da iz baze treba dohvatiti
samo podatke za radnika ALAGIC-a. Tako se povezuje ALAGIC-ev red iz tabele RADNIK, koji
sadrži vrednost 30 u polju SIFRAO, sa redom u tabeli ODELJENJE, koja, takođe, sadrži istu
vrednost u polju SIFRAO. Kolone koje su listane SELECT klauzulom pokazuju da se iz baze
uzima samo polje PREZIME iz tabele RADNIK i samo polje MESTO iz tabele ODELJENJE da bi
se dobio željeni rezultat.
alempije@beotel.yu 191
Rezultat SQL upita je:
PREZIME MESTO
ALAGIC BEOGRAD
Mogu se povezivati pojedini redovi kao u prethodnom primeru, delovi tabela ili cele tabele.
Ako se posmatra tzv. spajanje θ (videti prilog br.1) koje je najčešći slučaj, kada se
izjednačavaju vrednosti kolona koje se navode u klauzuli WHERE, mogu se spojiti tabele
RADNIK i ODELJENJE preko zajedničke kolone SIFRAO:
SELECT NAZIVO, PREZIME, SIFRARM,PLATA
FROM RADNIK, ODELJENJE
WHERE RADNIK.SIFRAO = ODELJENJE.SIFRAO
ORDER BY NAZIVO,PLATA DESC
Potpuno isti rezultat kao u prethodnom slučaju dobija se i prilikom definisanja spajanja
korišćenjem opcije INNER JOIN definisane u MS ACCESS-u.
SELECT NAZIVO, PREZIME, SIFRARM, PLATA
FROM RADNIK
INNER JOIN ODELJENJE ON RADNIK.SIFRAO =
ODELJENJE.SIFRAO
192 alempije@beotel.yu
!" COUNT - broji redove (brojač) koji pripadaju svakoj od ovih grupa;
!" AVG - nalazi prosečnu vrednost određenih polja u svakoj grupi.
Na primer, na kom je SIFRARM mestu i koliko je radnika radilo (COUNT) na svakom od
poslova u svakom odeljenju, kao i kolike su suma (SUM) i prosečna plata (AVG) u ovako
formiranim grupama?
SELECT NAZIVO,SIFRARM,SUM (PLATA),COUNT(*),AVG
(PLATA)
FROM RADNIK,ODELJENJE
WHERE RADNIK.SIFRAO = ODELJENJE.SIFRAO
GROUP BY NAZIVO,SIFRARM
Da bi se realizovao ovaj upit, tabeli RADNIK se daju dva sinonima: PODR i NADR. Kada su
potrebni podaci o radniku tabela RADNIK se referencira sinonimom PODR, a kada su
potrebni podaci o neposrednim rukovodiocima - sinonimom NADR. Na taj način, pomoću
navedenih sinonima, praktično, formiraju se dve virtuelne tabele sa identičnim sadržajem.
alempije@beotel.yu 193
Rezultat SQL upita je:
194 alempije@beotel.yu
Rezultat SQL upita je:
Nazivo Prezime Sifrarm Plata:
PRIPREMA CEBIC 03 24500
PRIPREMA KLJAKIC 05 50000
PRIPREMA MILIC 01 13000
RAZVOJ STEVIC 01 8000
RAZVOJ JOVIC 03 29750
RAZVOJ SUSIC 04 30000
RAZVOJ ALIMPIC 01 11000
RAZVOJ FILIPIC 04 30000
PRODAJA ALAGIC 02 16000
PRODAJA VUKIC 02 12500
PRODAJA MARTIC 02 12500
PRODAJA BOBIC 03 28500
PRODAJA TUBIC 02 15000
PRODAJA JAKIC 01 9500
PROIZVODNJ
Može se primetiti da odeljenje 40 PROIZVODNJA nema radnike, ali da je i ono uzeto u
razmatranje, jer je postavljen uslov da se uzimaju svi redovi druge (ODELJENJE) tabele bez
obzira na to da li imaju sprezanje.
Spajanje korišćenjem operatora UNION
Operator UNION nad dva SELECT BLOKA daje sve rezultujuće redove prvog select bloka i
one rezultujuće redove drugog koji nisu među rezultujućim redovima prvog select bloka.
Na primer, u okviru tabele RADNIK , izdvojiti zajednička radna mesta za odeljenje 10 i 30.
SELECT SIFRARM
FROM RADNIK
WHERE Sifrao = '10'
UNION
SELECT SIFRARM
FROM RADNIK
WHERE Sifrao = '30'
alempije@beotel.yu 195
INSERT INTO ODELJENJE
(sIFRAO, NAZIVO, MESTO)
VALUES ('50', 'NABAVKA', 'CACAK')
Druga varijanta omogućuje definisanje samo onih kolona za koje treba uneti podatke (NON
NULL), ali redosled kolona mora da odgovara redosledu iza VALUES.
U INSERT naredbi se imenuje tabela (ODELJENJE), u koju se ubacuju red i lista vrednosti
svih podataka.
Ako se želi dodati istovremeno više slogova, onda naredba INSERT INTO ima sledeću
sintaksu:
Klauzula UPDATE imenuje tabelu koju treba menjati (UPDATE RADNIK). Klauzula SET
izjednačava polje koje korisnik imenuje sa nekom vrednosti (SET PLATA = PLATA + 100). U
klauzuli WHERE specificira se jedan red ili niz redova koje treba promeniti (WHERE SIFRARM
= '04').
Posle izvedenih izmena, tabela RADNIK za radnike na SIFRARM mestu 04 sada izgleda:
196 alempije@beotel.yu
odnosno dodavanjem kolone SIF, prethodno treba kreirati tabelu HPOSAO pomoću komande
CREATE TABLE.
CREATE TABLE HPOSAO (SIF TEXT (3),
NAZIVH TEXT (20),
CENAP FLOAT8);
Ovom naredbom su definisani: tabela koju treba izmeniti (RADNIK), kolona koju treba
dodati (SIF), tip podatka nove kolone (TEXT) i maksimalna dužina polja nove kolone TEXT
(3).
Izlistana tabela RADNIK sa dodatom kolonom SIF izgleda ovako:
SELECT * FROM RADNIK;
Kada je definisana nova kolona naredbom UPDATE treba pridružiti određene radnike koji
imaju honorarni posao i to samo u odeljenju 20, za REFERENTA (02) sa honorarnim poslom
čija je šifra 101.
UPDATE RADNIK
SET SIF = '101'
WHERE SIFRAO = '20'
OR SIFRARM = '02';
alempije@beotel.yu 197
Nova tabela RADNIK pokazuje da li je postignut željeni rezultat.
SELECT * FROM RADNIK;
Ako treba pridružiti honorarni posao 102 svim radnicima koji nemaju nijedan posao (SIF IS
NULL) onda se to piše ovako:
UPDATE RADNIK
SET SIF = '102'
WHERE SIF IS NULL;
Ova promena vezana za nova polja u tabeli RADNIK dozvoljava uspostavljanje relacija
između tabela: RADNIK i HPOSAO.
SELECT PREZIME,SIFRARM,SIFRAO,NAZIVH
FROM RADNIK, HPOSAO
WHERE RADNIK.SIF = HPOSAO.SIF;
198 alempije@beotel.yu
Prezime Sifrar Sifra NAZIV
FILIPIC 04 20 MASIN
ALIMPIC 01 20 MASIN
TUBIC 02 30 MASIN
SUSIC 04 20 MASIN
MARTIC 02 30 MASIN
JOVIC 03 20 MASIN
VUKIC 02 30 MASIN
ALAGIC 02 30 MASIN
STEVIC 01 20 MASIN
MILIC 01 10 ALATI
JAKIC 01 30 ALATI
KLJAKIC 05 10 ALATI
CEBIC 03 10 ALATI
BOBIC 03 30 ALATI
alempije@beotel.yu 199
Aktivnost
3.3.4. Definisanje izveštaja
Kreiranje izveštaja izvodi se korišćenjem već definisanih i standardizovanih formi sa
nadgradnjom.
Za primer izveštaja knjigovodstvu definisan je sledeći QBE upit:
200 alempije@beotel.yu
alempije@beotel.yu 201
Korišćenjem objekta Report definiše se korisnički izveštaj koji može imati sledeći izgled:
Izvestaj knjigovodstvu
15-Jun-98
SIFRA DAT.
ODELJENJE PREZIME PLATA STIM UKUPNO
RAD ZAP
PRIPREMA
DIREKTOR 827782 CEBIC 11.6.80 24500 500 25000
GORAN
GEN_DIR 827839 KLJAKIC 6.12.87 50000 600 50600
STEVAN
PROJEKTAN 827934 MILIC 28.3.93 13000 790 13790
T DRAGAN
PRIPREMA UKUPNO 87500 1890 89390
PRODAJA
DIREKTOR 827698 BOBIC 15.11.8 28500 800 29300
IVAN 9
PROJEKTAN 827900 JAKIC 28.3.90 9500 900 10400
T VLADAN
REFERENT 827499 ALAGIC 28.3.98 16000 600 16600
MILAN
RAZVOJ
DIREKTOR 82756 JOVIC MIRA 28.4.90 29750 700 30450
6
PROJEKTAN 82736 STARCEV.ZORA 28.3.98 8000 700 8700
T 9 N
TEHNOLOG 82778 SUSIC ZORAN 23.10.9 30000 650 30650
8 1
202 alempije@beotel.yu
Aktivnost
4. Implementacija
alempije@beotel.yu 203
Nakon izvedene aktivnosti "3. Aplikativno modeliranje" definisan je tok podataka "Radni IS"
koji predstavlja ulaz u aktivnost "4. Implementacija" (slika 5.1).
Konsultant na ovom nivou treba da pomogne u uvođenju, testiranju i održavanju budućeg
korisničkog softvera.
Na slici 5.1. prikazano je stablo aktivnosti za aktivnost "4. Implementacija", koju čine
sledeće aktivnosti:
!" Aktivnost 4.1. Uvođenje,
!" Aktivnost 4.2. Testiranje,
!" Aktivnost 4.3. Održavanje.
IMPLEMENTACIJA
4
C1
Tehnike testiranja Postupak
implementacije
Korisni~k
Testiran softver softver
O1
TESTIRANJE
Specijani korisni~ki zahtev
4.2
Postupak
Izmene odr`avanja
I2
Informacije
Plan odr`avanja
od korisnika
ODR@AVANJE Tro{kovi odr`avanja
Nove verzije
4.3
Spoljni
konsultant Alati za
M1 M2 testiranje
204 alempije@beotel.yu
Aktivnost "4. Implementacija" izvodi se:
!" na osnovu ulaznih informacija, definisanih kroz Radni JAIS-a (I1) prethodno urađen u
aktivnosti "3. Aplikativno modeliranje" i Informacija od korisnika (I2);
!" pod kontrolom "Postupak implementacije (C1);
!" resursima vezanim za korišćenje alata za testiranje (M2) i uslugama spoljnog
konsultanta (M1);
!" kroz izlaz kao "Korisnički softver" (O1).
Mora se naglasiti da implementacija predstavlja priliku za sprovođenje principa
reinženjeringa poslovnih procesa. Međusobne veze između podaktivnosti prikazane na slici
5.2. biće opisane u daljem tekstu.
alempije@beotel.yu 205
Aktivnost
4.1. Uvođenje
IZMENE
Izmene U TOKU Izmene
I3
UVO\ENJA
I2 4.1.2
Informacije
od korisnika
IZRADA
Korisni~ka uputstv
KORISNI^KIH
O1
UPUTSTAVA
4.1.3
IZRADA
Plan obuke korisni
PLANA
O2
Spoljni OBUKE
konsultant 4.1.4
M1
206 alempije@beotel.yu
Aktivnost
4.1.1. Vrednovanje softvera
Vrednovanje softvera je podskup aktivnosti softverskog inženjerstva i može se smatrati
sistemom, odnosno sistemom vrednovanja.
Da bi se izvršilo vrednovanje, treba specificirati zahteve, tj. definisati osnovne zahteve za
funkcije i performanse i dati potrebna ograničenja i dr. Kao poseban element izdvajaju se
zahtevi za kvalitetom, definisani kvantitativnim i kvalitativnim formulisanim zahtevima. To
uslovljava i formulisanje faktora kvaliteta koji je odlika ili karakteristika određenog
elementa. Kvantitativna mera se izražava preko tzv. metrike kvaliteta. Rezultat vrednovanja
je ocenjivanje kao aktivnost primene određenog dokumentovanog kriterijuma ocenjivanja
softverskog modula, paketa ili softverskog proizvoda radi određivanja prihvatljivosti ili
puštanja u eksploataciju softverskog paketa ili proizvoda.
Osnovu procesa vrednovanja čine zahtevi vrednovanja koji se iskazuju preko:
!" funkcionalnih zahteva, definisanih listom potrebnih funkcija određenih preko
odgovarajućih težina;
!" sadržaja korišćenja softverskog proizvoda;
!" broja zadataka koje proizvod podržava;
!" broja korisnika;
!" profila korisnika (nivo eksperta, iskustvo, obučenost);
!" dodeljivanja težina svakoj karakteristici kvaliteta.
U okviru aktivnosti "4.1.1. Vrednovanje" poštuju se principi definisani serijom standarda
ISO/IEC 9126 Informacione tehnologije (Vrednovanje softvera - Karakteristike kvaliteta i
smernice za njihovu upotrebu) i ISO 9000, vezanih za obezbeđenje kvaliteta softvera
(Software Quality Assurance - SQA) i mogu se posmatrati kroz sledeće složene procese:
!" analiza zahteva vrednovanja,
!" specifikacija vrednovanja,
!" projektovanje vrednovanja,
!" primena vrednovanja i
!" izveštavanje o vrednovanju.
U daljem tekstu detaljno će biti obrazloženi gore definisani složeni procesi.
alempije@beotel.yu 207
Definisanje funkcionalnih zahteva se odnosi na identifikaciju korisnikovih funkcionalnih
potreba, što uključuje izradu liste potrebnih funkcija i ukazivanje na njihovu respektivnu
važnost. To se može uraditi dodeljivanjem težina ili klasa funkcijama.
Definisanje sadržaja korišćenja obuhvata: identifikaciju izvršenog zadatka (prirodu, proizvod
dodeljen jednom zadatku, moguće korišćenje za nekoliko zadataka itd.), okruženje
(trgovina, industrija, prosveta, klasa rizičnih proizvoda itd.), korisnike (jedan ili više,
odeljenje, organizacija...), profil korisnika (nivo eksperta, iskustvo, obučenost itd.).
Definisanje sadržaja korišćenja se koristi za definisanje zahteva kvaliteta primenjivih na
proizvod, ali i za vrstu vrednovanja koja će se koristiti tokom procesa izbora. To može
dovesti i do modifikacije funkcionalnih zahteva proizvoda.
Definisanje zahteva kvaliteta primenjuje se na proizvod koji, uzimajući u obzir ISO/IEC 9126
karakteristike, treba da poseduje:
!" funkcionalnost, tj. da izlazi budu korektni i tačni (treba da radi kako je predviđeno);
!" postojanost, tj. ne sme da pada na greškama koje korisnik napravi;
!" integritet (vezano za integritet baze podataka i referencijalni integritet);
!" pouzdanost , tj. mora da radi svaki put isto prilikom korišćenja;
!" dokumentovanost (vezano za korektno korišćenje CASE alata);
!" prilagodljivost, koja treba da omogući da sami korisnici izvode izmene;
!" preglednost, tj. ne treba da bude pretrpan informacijama;
!" razumljivost (da omogući korisniku da zna šta treba da radi);
!" validnost (vezano za zadovoljenje kriterijuma klijenta);
!" pogodnost za održavanje;
!" fleksibilnost, tj. lake izmene bez ulaganja velikih napora;
!" prenosivost, tj. mogućnost rada sa druge platforme;
!" kompatibilnost sa drugim programima (ODBC drajveri);
!" efikasnost, tj. balansiranje između efikasnosti iskorišćenja resursa računara i čovekovih
resursa;
!" modularnost (zbog lake dogradnje i otklanjanja bagova);
!" upotrebljivost, tj. mogućnost korišćenja delova programa u drugim aplikacijama.
Specifikacija vrednovanja
Specifikacija vrednovanja, kao složeni proces, u sebi sadrži sledeće procese:
!" izbor metrike i indikatora,
!" izbor karakteristika,
!" definisanje nivoa ranga,
!" definisanje kriterijuma ocenjivanja.
Izbor metrike se definiše za svaki zahtev. Metrika je, uopšteno posmatrano, numerička
vrednost na skali. Može se koristiti ceo ili realan broj. Primeri za skale metrika su:
!" 1...10 prirodni brojevi;
!" 0...1 realni;
!" procenat;
!" "odličan, "dobar", "solidan", "loš";
208 alempije@beotel.yu
!" "da", "ne".
Definicija metrike treba da uključi i indikaciju o tome kako treba izvršiti merenje.
Izbor karakteristika uključuje identifikaciju specifičnog značenja karakteristika koje se
primenjuju na proizvod u kontekstu na identifikovanog korisnika. Ako uzete karakteristike
nisu dovoljne za precizan opis zahteva kvaliteta, mogu se koristiti i potkarakteristike.
Rangiranje zahteva kvaliteta može se uraditi dodeljivanjem težine, ili klase.
Definisanje nivoa ranga, prema ISO/IEC 9126, određuje se u okviru četiri nivoa ranga koji
odgovaraju mogućim vrednostima metrike. Ova aktivnost se odnosi na ucrtavanje ranga na
metričku skalu.
Definisanje kriterijuma ocenjivanja se sastoji iz određivanja šta je prihvatljivo za
razmatranje:
!" rangiranje (koje je prethodno definisano),
!" kontekst korišćenja proizvoda,
!" dodatne mogućnosti, kao što su trošak, kašnjenje itd.
Projektovanje vrednovanja
Projektovanje vrednovanja, kao složeni proces, sastoji se iz povezivanja tehnika
vrednovanja za karakteristike i nivoe softvera, kao i povezivanja modula vrednovanja za
tehnike vrednovanja. Ovaj složeni proces kao izlaz daje plan vrednovanja.
Projektovanje vrednovanja čine procesi:
!" specifikacija modula vrednovanja,
!" ugradnja modula vrednovanja u biblioteku.
Specifikacija modula vrednovanja obuhvata sažimanje jedne ili više tehnika vrednovanja.
Aktivnost obuhvata specificiranje zahtevanih informacija o: proizvodu i procesu, tehnikama
vrednovanja, izlazu koji je rezultat primene tehnike, kao i procenjenom trošku primene
modula vrednovanja. Jasno je da su tehnike vrednovanja i moduli vrednovanja u vezi sa
karakteristikama softvera i nivoima vrednovanja. Posle određivanja tehnika vrednovanja, tj.
identifikovanja koje karakteristike softvera treba razmatrati i koliko detaljno, uz tehnička
ograničenja softvera, bira se i skup primenjivih modula vrednovanja iz biblioteke modula
vrednovanja.
Ugradnja modula vrednovanja u biblioteku odnosi se na donošenje odluke o razvijanju
novog modula i njegovo dodavanje u biblioteku.
Primena vrednovanja
Složeni proces Primena vrednovanja daje rezultate vrednovanja dobijenih kao izlazi iz
procesa:
!" merenje pomoću metrika,
!" ocenjivanje poređenjem,
!" izveštavanje merenja ocenjivanja na osnovu plana merenja definisanog u prethodnom
procesu.
alempije@beotel.yu 209
Izveštavanje o vrednovanju
Složeni proces - Izveštavanje o vrednovanju čine procesi:
!" analiza rezultata vrednovanja,
!" generisanje izveštaja.
Na osnovu rezultata dobijenih kao izlaz iz procesa Primena vrednovanja i analize tih
rezultata stvaraju se razne vrste izveštaja koji predstavljaju izlaze iz kompletnog sistema
vrednovanja.
Aktivnost
4.1.2. Izmene u toku uvođenja
Na osnovu definisanih primedbi izvode se izmene koje, ako se koriste CASE alati, ostaju kao
trag aktuelnoj elektronskoj dokumentaciji o sprovedenim izmenama. Ako se izmene naprave
u tabelama baze podataka, automatski se sprovode iste izmene i u modelu podataka.
Aktivnost
4.1.3. Izrada korisničkih uputstava
Korisnička uputstva mogu biti opšta uputstva za rad sa aplikacijom, kao i detaljna korisnička
uputstva za svaki programski sistem. Pored papira, treba da imaju i dimenziju On-line
dokumentacije. Dokumentacija mora da ima sledeće karakteristike:
!" pri pisanju neophodni su jasni i koncizni izrazi;
!" oslovljavanje korisnika treba da bude u drugom licu, uz korišćenje aktivnih glagola;
!" pri opisu procedure treba upotrebljavati jednostavne glagole;
!" procedure se moraju opisivati logičkim redom;
!" ne treba upotrebljavati izraze iz žargona;
!" treba izbegavati šale;
!" dati mogućnost jednostavnog izbora i dr.
Aktivnost
4.1.4. Izrada plana obuke
Pretpostavka za izvođenje aktivnosti "4.1.4. Izrada plana obuke" je da su budući korisnici
kompjuterski opismenjeni, kao što je to opisano u okviru aktivnosti "1.3.2. Kadrovske
potrebe". Za ovu aktivnost se napravi plan obuke po prioritetima uvođenja pojedinih modula
ili podsistema.
Na osnovu prethodno izvedenih aktivnosti (slika 5.2) u sledećem koraku treba izvesti
testiranje.
210 alempije@beotel.yu
Aktivnost
4.2. Testiranje
alempije@beotel.yu 211
!" Aktivnost 4.2.4. Završno testiranje u okruženju korisnika.
Specijani
korisni~ki
zahtev
I2 TESTIRANJE Programski kod
MODULA
4.2.1
TESTIRANJE Podsistemi
PODSISTEMA
4.2.2
TESTIRANJE Integrisani
INTEGRISANOG podsistemi
SISTEMA
I1
Prihva}en 4.2.3
softver ZAVR[NO
TESTIRANJE U Testiran soft
OKRU@ENJU O1
KORISNIKA
4.2.4
212 alempije@beotel.yu
Aktivnost
4.2.1. Testiranje modula
Kako su moduli povezani sa nizom nezavisnih komponenti, to se zahteva provera svih
specifikacija i konstrukcija vezanih za modul.
Aktivnost
4.2.2.Testiranje podsistema
Prilikom testiranja podsistema najčešće se pojavljuju problemi, jer su mnogi softverski
inženjeri uključeni u izgradnju podsistema. Različite interpretacije specifikacija, obično,
rezultiraju problemima, pa ih treba uklopiti. Problematika na ovom nivou se
pojednostavljuje ako su korišćeni CASE alati gde je definisan jedinstven rečnik podataka i
procesa i gde su veze prikazane na grafički način.
Osnovni koraci vezani za ovu aktivnost su:
!" spajanje modula,
!" definisanje internih interfejsa,
!" testiranje rada grupe modula,
!" testiranje veze sa eksternim interfejsima.
Aktivnost
4.2.3. Testiranje integrisanog sistema
Testiranje integrisanog sistema zahteva od budućeg korisnika da pripremi realne podatke za
upotrebu. Pri tom se testiraju: funkcionalnost, performanse, restart, oporavak i
funkcionisanje.
Aktivnost
4.2.4. Završno testiranje u okruženju korisnika
Završno testiranje u okruženju korisnika se, obično, zove alfa-testiranje ako je u pitanju
jedan korisnik, a ako se proizvod distribuira na mnogo mesta ili mnogo pojedinaca tada je
beta-testiranje. Test preuzimanja izvodi se u dva koraka:
!" definisanjem zahteva i specifikacija i
!" ispunjenjem uslova preuzimanja.
Na osnovu prethodno izvedenih aktivnosti (slika 5.2) u sledećem koraku biće izvedena
aktivnost "4.3. Održavanje".
alempije@beotel.yu 213
Aktivnost
4.3. Održavanje
ISPRAVLJANJE
Gre{ke za ispravku
GRE[AKA
4.3.2
Informacije POBOLJ[AVANJE
od korisnika SISTEMA I Tro{kovi odr`avan
I2 DODAVANJE O2
NOVIH FUNKCIJA
4.3.3
IZMENA
HARDVERA I Nove verzije
O3
SOFTVERA
4.3.4
Spoljni
konsultant
M1
214 alempije@beotel.yu
Aktivnost
4.3.1. Praćenje rada
Aktivnost "4.3.1. Praćenje rada" treba izvoditi kontinualno, sve dok ne bude potrebno da se
izvede zamena, jer informacije stečene u toku tog praćenja omogućuju da se odredi vrsta
promena, tj. na taj način se izvodi tzv. kontinualno usavršavanje. Mogu se na osnovnom
nivou pratiti:
!" sati u upotrebi,
!" urađeni poslovi i transakcije,
!" informacije o vremenu,
!" učitavanja,
!" registrovanje nedostataka i dr.
Ovakvo praćenje omogućava oporavak sistema od katastrofalnih grešaka. Stoga je ova
aktivnost neposredno vezana i za sprovođenje korektivnih akcija. Tako, ako se prati vreme i
primete varijacije u vremenu izvođenja transakcija, automatski se izvode korektivne akcije.
Aktivnost
4.3.2. Ispravljanje grešaka
U aktivnosti "4.3.2. Ispravljanje grešaka", pored ispravljanja grešaka, prati se i odstupanje
softvera, i vrši prilagođavanje korisniku i zadatku.
Aktivnost
4.3.3. Poboljšanje sistema i dodavanje
novih funkcija
Aktivnost "4.3.3. Poboljšanje sistema i dodavanje novih funkcija" skoro uvek nastupa, jer
korisnik ubrzo spozna nove mogućnosti sistema, pa ima nove zahteve vezane za poboljšanje
sistema. Dodavanje novih funkcija ne mora da bude teško, ako su ispoštovani prethodno
opisani koraci.
Aktivnost
4.3.4. Izmena hardvera i softvera
Aktivnost "4.3.4. Izmena hardvera i softvera" posmatra se kroz softverske izmene vezane
za promenu SUBP, kao i hardverske izmene vezane za izgradnju mreže u okviru
klijent/server-arhitekture.
alempije@beotel.yu 215
Softverske izmene
Baza podataka i aplikacije, koje se na njoj temelje, podvrgnute su čestim promenama.
Promene mogu biti izazvane razvojem opreme (npr., na tržištu se javlja efikasniji tip:
memorije, terminala, procesora).
Češće promene su potrebne zbog razvoja korisničkog sistema (aplikacija), promena uslova i
pravila poslovanja, novih zakonskih zahteva itd. Korisniku SUBP mora obezbediti što veću
fleksibilnost, tako da funkcioniše kao nekakav štit između aplikacije i baze podataka.
SUBP poznaje fizičku i logičku strukturu baze podataka na jednoj strani i zahteve
korisnikovih programa na drugoj strani, te deluje kao posrednik (interface), koji
korisnikovom programu osigurava uvek isti pogled na podatke, bez obzira na eventualne
promene u fizičkoj ili logičkoj strukturi baze podataka (data indepedence). Time se, sa jedne
strane, postiže imunost korisnikovih programa na promene, koje doživljava baza podataka,
a, sa druge, znatno se olakšava i pojednostavljuje održavanje korisnikovih programa.
Pojavom Interneta i otvorenih sistema omogućen je razvoj softvera, nezavisno od
hardverske platforme, što dalje omogućuje razvoj na personalnim računarima i
implementaciju na nekom drugom hardveru. Slične mogućnosti su i u vezi sa softverom.
Ako je u okviru klijent/server-aplikacije razvijen ceo sistem na strani servera i klijenta, npr.
u MS ACCESS-u, a treba na strani servera instalisati MS SQL SERVER, i ako je ispoštovana
prethodno definisana modularnost, ovakvi poslovi se obavljaju preko vikenda. Ako korisnik u
okviru održavanja sakuplja odgovarajuća iskustva, to će ovaj posao brže i bezbolnije obaviti.
Ceo ovaj posao zaokružuju na početku spomenuti CASE alati, koji treba automatski da
registruju svaku izmenu i omoguće ažurno održavanje dokumentacije.
Hardverske izmene
Harverske izmene se odnose na nadgradnju mreže u okviru klijent/server-arhitekture, gde
je mreža sredstvo za prenos podataka koje omogućuje razmenu poruka između aplikacije
klijent (koja šalje, prima i analizira podatke) i servera baze podataka (koji obrađuje zahteve
za pristup bazi).
Predmet izmena može biti:
!" topologija mreže,
!" hardver i softver za umreženi klijent/server-sistem,
!" aplikacioni posrednik za rad sa bazom podataka,
!" aktivnosti u sistemu klijent/server.
Topologija mreže može biti: zvezdasta (gde istovremena komunikacija zavisi od centralnog
čvora), linijska (gde se izvodi komunikacija jedan po jedan između čvorova) i prstenasta (tj.
istovremena komunikacija bez zavisnosti od centra čvora).
Hardver i softver za umreženi klijent/server-sistem vezani su za:
!" mrežni hardver,
!" mrežni softver i
!" komunikacioni softver.
Mrežni hardver čine: mrežni adapter (koji čine jedna ili više utičnica za priključivanje
kablova preko upletenih parica ili optičkih vlakana), bežični mrežni adapteri
(visokofrekventni radio-signali), modemi i telefonske linije za regionalne mreže (WAN),
spoljni modemi za velike udaljenosti.
Mrežni softver omogućuje: kontrolu pristupa mreži; upravljanje redovima čekanja na
štampaču; dodeljivanje prostora za korisničke datoteke; rad sa elektronskom poštom.
216 alempije@beotel.yu
Komunikacini softver omogućava da razni računari u mreži šalju i primaju pakete programa
preko mreže za koju je definisan komunikacioni protokol, tj. jezik sporazumevanja računara,
i to:
!" TCP/IP - Transmission Control Program / Internet Program (UNIX),
!" SPX/IPX - Sequenced Packet Exchange / Internet Package Exchange (NetWare),
!" mrežna skretnica (komunikacioni most).
Aplikacioni posrednik za rad sa bazom podataka ili softverski sloj (Application middleware)
omogućava komunikaciju između različitih komponenti distribuirane aplikacije; aktivan je i
na klijentu i na serveru i pri tom prevodi poruke koje oni međusobno razmenjuju. Postoji i
konverzacioni posrednik koji, prvo, omogućuje povezivanje, a potom razmenjivanje poruka,
da bi u jednom trenutku poruka išla u jednom smeru (asinhrono), ali nije mnogo efikasan.
Pozivanje udaljenih procedura (RPC-Remote Procedure Call) omogućuje jednostavni poziv
procedura, i to procedura niskog nivoa, koje su jednostavne za upotrebu. API (Application
Programming Interface) predstavlja specifičnu skupinu f-ja koji omogućavaju komunikaciju
između aktivnosti koje se odvijaju na klijentima i onih na serverima vezanim sa ODBC-Open
DataBase Connectivity i IDAPI-Integrated Database Application Programming Interface. API
programski interfejs koristi se za različite tipove servera baze podataka i to je najmanji
zajednički imenitelj.
Aktivnosti u sistemu klijent/server su zadatak čijim izvršenjem upravlja OS, a ako su u
pitanju višeprocesni OS, onda se istovremeno upravlja sa više zadataka. Server baze
podataka u klijent/server-sistemu radi pod višeprocesnim OS (UNIX, NT ili VMS). Aktivnost
klijent izvršava aplikacije klijent koje se povezuju sa serverom baze podataka i pri tom se
definiše zahtev za povezivanje, tj. ime korisnika i lozinka. Aktivnost server obrađuje zahteve
koje šalje Aktivnost klijent i pri tom neposredno obrađuje proces koji ide od klijenta i
upisuje podatke u datoteku sa podacima, tj. vodi datoteku dnevnika transakcija.
alempije@beotel.yu 217
Prilog 1.
Teoretske postavke
relacionih modela
Struktura relacionih modela je jednostavna i prihvatljiva za svakog korisnika, jer relaciona
baza podataka predstavlja skup tabela. Same relacije iz skupa tabela (baze podataka)
generišu izlaz, takođe, u obliku jednostavne i lako prihvatljive tabele.
S druge strane, jednostavna je i formalno matematička interpretacija tabela, tj. tabela se
može definisati kao matematička relacija.
Da bi se pristupilo razmatranju relacionih modela potrebno je dati definicije za:
!" kartenzijanski (Dekartov) proizvod,
!" relacije,
!" domen relacije,
!" stepen relacije,
!" kardinalnost relacije,
!" atribute relacije,
!" ključeve,
!" primarni ključ,
!" spoljne ključeve,
!" bazne relacije,
!" izvedene relacije,
!" šemu relacione baze podataka i
!" null vrednost.
Kartezijanski proizvod od n skupova D1 x D2 x...Dn je skup svih mogućih uređenih n-torki
<d1,d2,....dn> tako da je d1 ∈ D1, d2 ∈ D2 ...dn ∈ Dn
Primer: Data su dva skupa brojeva:
D1 = {1,2,3,4} i D2 = {4,5}
D1 x D2 = {<1,4>,<1,5>,<2,4>,<2,5>,<3,4>,<3,5>,<4,4>,<4,5>
Relacija se definiše kao podskup Dekartovog proizvoda nad n-skupova, tj. podskup sadrži
one n-torke Dekartovog proizvoda koje zadovoljavaju zadatu relaciju.
R ⊆ D1 x D2 x ...x Dn
218 alempije@beotel.yu
Primer: Definisati za prethodni primer nad skupovima D1 i D2 relaciju:
R: A x B ={ <d1,d2>| d1 = d2/2}
R = {<2,4>}
Domen relacije R definisan je okvirima skupova D1, D2,...Dn.
Stepen relacija je definisan brojem domena nad kojima je definisana neka relacija. Razlikuje
se unarni stepen relacije nad jednim domenom, binarni nad dva i n-arni nad n-domena.
Kardinalnost relacije je broj n-torki u relaciji.
Po definiciji, Dekartov proizvod predstavlja skup uređenih n-torki i redosled elemenata u
jednoj n-torki je bitan. Ako bi se vrednostima elemenata n-torki pridružila semantička
imena domena, redosled elemenata u n-torkama postaje beznačajan.
Na primer, za definisane domene:
SIFRAR = {827369,827499,827521}
PREZIME= {STEVIC,ALAGIC,VUKIC}
RUKOV = {827902,827698,}
relacija se definiše ovako:
RADNIK ⊆ SIFRARxPREZIMExRUKOV =
{<827369,STEVIC,827902>,
<827499,ALAGIC,827698>,
<827521,VUKIC,827698>}
Prvi element trojke uzima vrednost iz prvog, drugi iz drugog, a treći iz trećeg skupa.
Ako bi se vrednostima elemenata u n-torkama pridružila imena domena, redosled
elemenata u n-torkama je beznačajan:
RADNIK ⊆ SIFRAR x PREZIME x RUKOV =
{ <SIFRAR:827369,PREZIME:STEVIC, RUKOV:827902>,
<PREZIME:ALAGIC, SIFRAR:827499, RUKOV:827698>,
<RUKOV:827698,SIFRAR:827521,PREZIME:VUKIC>}
alempije@beotel.yu 219
Atributi relacije
Atributi relacije su imenovani domeni sa imenom koje definiše ulogu domena u relaciji.
Atributi relacije RADNIK su SIFRAR, PREZIME, RUKOV i dr.
Ovako definisan koncept atributa omogućuje predstavljanje relacija kao tabela, pa se
relacija RADNIK može predstaviti sa:
SIFRAR PREZIME RUKOV
827369 STEVIC 827902
827499 ALAGIC 827698
827521 VUKIC 827698
Razlika između relacije i tabele je u tome što je relacija skup, a svaka tabela to nije. Stoga
se definišu uslovi koje tabela mora da zadovolji da bi bila relacija:
!" ne mogu postojati duple vrste tabela;
!" redosled vrsta nema značaja;
!" redosled kolona nema značaja;
!" nisu dozvoljeni atributi ili grupe atributa sa ponavljanjem.
Prikazana tabela zadovoljava uslove da jedna tabela bude relacija. Ako je zadovoljen
poslednji uslov, onda se kaže da se tabela nalazi u prvoj normalnoj formi.
220 alempije@beotel.yu
Ključevi
Ključevi se definisu kao jedan ili više atributa čija vrednost jedinstveno identifikuje jednu n-
torku u relaciji, tj. jedan red u tabeli. Ako je ključ definisan samo jednim atributom, onda je
to prost ključ (npr., u relaciji RADNIK ključ je SIFRAR). Ako je ključ definisan sa više
atributa, onda je to složeni ključ (npr., relacija CERTIFIKAT-ključ je SIFRAR, SIFRAJ).
Ako se definiše relacija R, onda se može reći da ključ relacije R predstavlja kolekcija K
njenih atributa koja zadovoljava :
!" osobinu jedinstvenosti i
!" osobinu neredundantnosti.
Osobina jedinstvenosti je vezana za ograničenje da ne postoje bilo koje dve n-torke sa istom
vrednošću K.
Osobina neredundantnosti se odnosi na gubljenje osobina jedinstvenosti ako se bilo koji
atribut izostavi iz K.
U jednoj relaciji može postojati više različitih kolekcija K atributa koje zadovoljavaju
definiciju ključa; sve se one nazivaju kandidati za ključ.
Primarni ključ je jedan od izabranih kandidata za ključ koji služi za identifikaciju n-torke
relacije. Ostali kandidati za ključ postaju alternativni ključevi.
Atributi koji učestvuju u ključevima nazivaju se ključni atributi, dok se ostali nazivaju opisni
atributi.
Spoljni ključ ili preneseni ključ je atribut ili grupa atributa u relaciji R, čija se vrednost
koristi za povezivanje sa vrednošću primarnog ključa u nekoj relaciji R2. Spoljni ključevi i
njima odgovarajući primarni ključevi definisani su nad istim domenom. Dakle, spoljni
ključevi služe da se uspostave veze između relacija u relacionoj bazi podataka. Na primer, u
relaciji RADNIK spoljni ključ SIFRAO vezuje sa relacijom ODELJENJE.
Bazna relacija je relacija koja se ne može izvesti iz ostalih relacija u relacionoj bazi
podataka.
Izvedena relacija je relacija koja se izvodi iz skupa baznih i izvedenih relacija, i to preko
operacija koje se definišu nad relacijama.
Kako se u tekstu koriste termini vezani za relacije, tabele i klasičnu obradu podataka, to se
u sledećoj tabeli definišu njihove veze:
Ekstenzija relacije je skup svih n-torki date relacije, odnosno predstavljanje tabele
navođenjem svih vrsta. Tabela RADNIK predstavlja ekstenziju odgovarajućih relacija.
alempije@beotel.yu 221
Intenzija relacije je generalizacija ekstenzije; ona je vremenski nepromenljiva i označava se
na sledeći način:
RADNIK (#SIFRAR,PREZIME,RUKOV)
(Ispred zagrade je naziv relacije, u zagradi su navedeni atributi, a primarni ključ je obeležen
masnim otiskom.)
222 alempije@beotel.yu
Šema relacione baze podataka
Šema relacione baze podataka je predstavljanje strukture relacione baze kao skupa
intenzija relacija.
RADNIK (#SIFRAR, PREZIME, RUKOV, DATUMZ, PLATA,
STIMUL,*SIFRAO)
ODELJENJE (#SIFRAO, NAZIVO, MESTO)
Null vrednosti
Null vrednosti se koriste da se označe još nepoznate vrednosti za neki atribut ili
neprimenjivo svojstvo za neki objekat ili vezu koju predstavlja tabela (označavaće se
znakom ?).
Relaciona algebra
Relaciona algebra definiše skup operacija pomoću kojih se, na proceduralan način, može
dobiti željena relacija, tj.tabela iz skupa datih relacija.
Relacija se definiše kao podskup Dekartovog proizvoda i može se tretirati kao skup n-torki.
Za nivo relacione algebre operacije: unija, presek i diferencije nad relacijama R1 i R2
moraju zadovoljiti uslov kompatibilnosti (union compatible relations), tj. relacije R1 i R2
moraju imati isti broj atributa (isti stepen), a odgovarajući atributi su definisani nad istim
domenom.
Na nivou relacione algebre, operacije su:
!" unija,
!" diferencija,
!" presek,
!" Dekartov proizvod,
!" projekcija,
alempije@beotel.yu 223
!" selekcija (restrikcija),
!" spajanje (join),
!" deljenje,
!" operacije sa null vrednostima.
Unija
Ako su date relacije R1 i R2 koje zadovoljavaju uslove kompatibilnosti, onda je rezultat
operacije unije
R3 = R1 U R2
relacija R3 koja sadrži sve n-torke koje se pojavljuju bilo u R1, bilo u R2.
Diferencija
Ako su date relacije R1 i R2 koje zadovoljavaju uslov kompatibilnosti, onda rezultat
operacije diferencije
R3 = R1 - R2
predstavljaju n-torke relacije R1, koje nisu istovremeno i n-torke relacije R2.
Presek
Ako su date relacije R1 i R2 koje zadovoljavaju uslov kompatibilnosti, onda je rezultat
operacije preseka
R3 = R1 ∧ R2
Dekartov proizvod
Dekartov proizvod se može primeniti na bilo koje dve relacije. Rezultat je ove operacije
R3 = R1 x R2
relacija R3 čije su n-torke svi "parovi" koje čine jedna n-torka relacije R1 i jedna n-torka
relacije R2.
224 alempije@beotel.yu
Projekcija
Operacija projekcije se definise kao unarna operacija koja iz neke relacije selektuje skup
navedenih atrubuta, odnosno "vadi" vertikalni podskup iz odgovarajuće tabele.
Formalno, projekcija se definiše na sledeći način:
Neka je R (A1,A2,...,An) relacija, a X podskup njenih atributa.
Ako se sa Y označi komplement {A1,A2,...An}-X rezultat operacije projekcije relacije R po
atributima X glasi:
P[X]‚ = {x | tako da postoji y da je <x,y> ∈ R}
Selekcija (Restrikcija)
Selekcija je unarna operacija koja iz date relacije selektuje n-torke koje zadovoljavaju
zadati uslov ( "vadi" horizontalni podskup tabele).
Formalno se definiše na sledeći način:
Dati su relacija R (A1,A2,...An) i predikat P, definisan nad njenim atributima. Rezultat
operacije selekcije glasi:
S[P]R = {x | x ∈ R i P (x)}
Spajanje (Join)
Spajanje je binarna operacija koja spaja dve relacije na taj način da se u rezultatu
pojavljuju oni parovi n-torki jedne i druge relacije koji zadovoljavaju uslov zadat nad
njihovim atributima.
Formalno se definiše na sledeći način:
Date su relacije R1 (A1,A2,...,An) i R2 (B1,B2,...,Bm) i predikat θ, definisan nad njihovim
atributima.
Ako se sa X i Y obeleže skupovi atributa relacija R1 i R2, respektivno, rezultat operacije
spajanja ovih relacija (tzv. θ-spajanje) glasi ovako:
R1[xθ]R2 = {<x,y> | x ∈ R1 AND y ∈ R2 AND θ (x,y)}
alempije@beotel.yu 225
Deljenje
Deljenje je operacija pogodna za upite u kojima se javlja reč "svi".
Formalno se definiše na sledeći način:
Neka su A (X,Y) i B (Z) relacije, gde su X, Y i Z skupovi atributa takvi da su Y i Z
jednakobrojni, a odgovarajući domeni su im jednaki.
Rezultat operacije deljenja je
A[Y ) Z]B = R (X)
gde n-torka X uzima vrednosti iz A.X, a par <x,y> postoji u A za sve vrednosti y koje se
pojavljuju u B (Z).
Operacija deljenja nije primitivna operacija relacione algebre, već se može izvesti na sledeći
način:
A(X,Y)[Y ) Z‚B(Z) = P[X‚A - P[X‚((P[X‚A x B)- A)
Objašnjenje:
P[X]A daje sve n-torke koje mogu da učestvuju u rezultatu.
P[X]A x B daje relaciju u kojoj se za svaku vrednost z iz B pojavljuju parovi <x,z> sa svim
vrednostima x.
P[X]A x B) - A ne sadrži ni u jednom paru <x,z> one vrednosti x za koje u relaciji A, kao
vrednosti y, postoje sve vrednosti z.
Kompletan izraz, prema tome, jeste relacija koja sadrži one n-torke x za koje postoje u paru
<x,y>, kao vrednosti y, sve vrednosti z.
Relaciona algebra je proceduralni jezik. Pomoću operacija relacione algebre sačinjava se
procedura koja dovodi do odgovora na postavljeni upit.
Mada je proceduralni jezik, relaciona algebra je znatno moćnija od klasičnih programskih
jezika, koji su, takođe, proceduralni. Razlog za to je što operand relacione algebre
predstavlja relaciju (cela tabela), a operand operacija sa datotekama u klasičnim jezicima je
rekord (vrsta tabele).
Može se pokazati da se bilo koja relacija (bilo koji upit), izvodljiva iz skupa datih relacija,
može dobiti procedurom (algoritmom) od tri koraka:
1. Dekartov proizvod svih relacija koje se koriste;
2. selekcija n-torki za koje se predikat selekcije sračunava u T;
3. projekcija rezultata po atributima koji se prikazuju.
Ova procedura se može iskazati jednim opštim izrazom relacione algebre:
P[A1, A2, ..., An‚ (S[P‚ (R1 x R2 x ... x Rm))
Međutim, ovakvo izvođenje operacija bilo bi veoma "skupo", jer bi rezultat Dekartovog
proizvoda relacija R1, R2, ..., Rm bio relacija sa k1 x k2 x ... x km n-torki, gde su sa ki
označene kardinalnosti odgovarajućih relacija. Zbog toga se i definiše operacija spajanja,
koja istovremeno obavlja Dekartov proizvod i selekciju, smanjujući na taj način broj n-torki
koji se pretražuje. Pored toga, očigledno je da su znatno efikasniji algoritmi sa više koraka,
u kojima bi se prvo vršile sve selekcije koje se mogu izvesti na pojedinačnim relacijama,
zatim projekcije, pa tek onda spajanja.
226 alempije@beotel.yu
Operacije sa nula vrednostima
Navedene operacije relacione algebre nisu uzimale u obzir nula vrednosti, koje mogu
postojati u relacijama. Podrazumevalo se da se vrednosti predikata sračunavaju na osnovu
standardnih dvovrednosnih tablica istinitosti. Isto tako, bez dvoumljenja je bilo moguće da
se odrede duplikati n-torki, odnosno kardinalnost pojedinih skupova. Pojavljivanje nula
vrednosti u relacionoj bazi podataka zahteva da se proširi skup definisanih operacija koje bi
na neki način uključile i nula vrednosti. Osnovne postavke za operacije sa nula vrednostima
su sledeće:
(1) Tablice istinitosti trovrednosne logike:
AN T ? F O T ? F NOT
D R
T T ? F T T T T T F
? ? ? ? ? T ? ? ? ?
F F F F F T ? F F T
(Znak ? predstavlja nula vrednost, a može se u okviru tablica istinitosti čitati i kao
"možda".)
(2) Sračunavanje aritmetičkih formula. Neka " označava neki od aritmetičkih operatora (+,
-, *, /) i neka su x i y dve numeričke vrednosti. Vrednost aritmetičkog izraza "x " y" je, po
definiciji, nula vrednost, ako bilo x, bilo y, bilo oba dobiju nula vrednost.
(3) Skupovi sa nula vrednostima. Da li kolekcija {1,2,3,?}, predstavlja skup? Ako ? uzme
vrednost 1,2 ili 3, onda nije, ili se može tretirati kao skup sa kardinalnošću 3. Ako ? nije ni
1, ni 2, ni 3, onda gornja kolekcija predstavlja skup sa kardinalnošću 4. To pokazuje da
postoje različite nula vrednosti: nula vrednost koja nije 1, nula vrednost koja nije 2, zatim
nula vrednost koja nije ni 1, ni 2, i tako dalje. Operacije koje bi uzele u obzir različitost nula
vrednosti bile bi veoma složene. Zbog toga se operacije definišu jednom vrstom nula
vrednosti, a ostale nula vrednosti se tretiraju kao duplikati.
Imajući u vidu ove opšte postavke, primeri nekih ranije definisanih operacija na relacijama
koje poseduju nula vrednosti izgledaju ovako:
alempije@beotel.yu 227
UNIJA
R3 = R1 U R2
R A B R A B R A B
1 2 3
a b x y a b
a ? ? b a ?
? b ? ? ? b
? ? ? ?
x y
DIFERENCIJA
R4 = R1 - R2
R A B
4
a b
a ?
DEKARTOV PROIZVOD
Dekartov proizvod ostaje neizmenjen.
SELEKCIJA
Operacija selekcije ostaje neizmenjena, selektuju se one n-torke za koje se odgovarajući
predikat sračunava u T na osnovu trovrednosnih tablica istinitosti. Ova operacija se često
zove i "TRUE SELECTION" (istinita selekcija).
S[A = a‚R1 A B
a b
a ?
PROJEKCIJA
Uzima se u obzir da su nula vrednosti duplikati (jedna vrsta nula vrednosti):
P[A‚R1 A
a
?
SPAJANJE
Operacija spajanja ostaje neizmenjena, jer operacije Dekartovog proizvoda i selekcije ostaju
neizmenjene. U rezultatu se pojavljuju one n-torke za koje se predikat spajanja sračunava u
T na osnovu trovrednosnih tablica istinitosti (TRUE TETA JOIN - istinito θ spajanje).
DODATNE OPERACIJE
Zbog postojanja nula vrednosti u bazi podataka, neophodno je da se definiše logička
funkcija "IS_NULL", čiji argument može da bude neki skalarni izraz, a koja se sračunava u T
ako je vrednost tog argumenta nula vrednost, a inače uzima vrednost F.
MOŽDA SELEKCIJA (MAYBE_SELECT)
Selektuju se one n-torke relacije za koje se predikat selekcije sračunava u nula vrednost na
osnovu trovrednosnih tablica istinitosti.
MAYBE_SELECT[A]R A B
3
? b
? ?
228 alempije@beotel.yu
Ra = Rb[MAYBE_JOIN A = D]Rc
R A B R C D E Ra A B C D E
b c
a1 b c1 ? e1 a1 b c1 ? e1
1 1
a2 b c2 d e2 a1 b c3 ? e3
2 2 1
? b c3 ? e3 a2 b c1 ? e1
3 2
a2 b c3 ? e3
2
? b c1 ? e1
3
? b c2 d e2
3 2
? b c3 ? e3
3
Relacioni račun
alempije@beotel.yu 229
Relacioni račun n-torki
Relacioni račun n-torki je predikatski račun prvog reda u kome domeni promenljivih
predstavljaju n-torke relacija date baze podataka.
Osnovni pojmovi predikatskog računa su:
!" afirmativna rečenica, koja ima smisla i koja je istinita ili neistinita i naziva se sud;
!" afirmativna rečenica, koja ima smisla i koja sadrži jedan ili više promenljivih parametara
i postaje sud uvek kada parametri iz rečenice dobiju konkretnu vrednost, naziva se
predikat; broj parametara u predikatu se naziva dužina predikata (primer predikata je x
+ y # 1);
!" predikatski ili kvantifikatorski račun, kao matematička teorija, čiji su objekti formule
koje predstavljaju predikate; simboli koji se koriste da označe neki sud nazivaju se
atomskim formulama ili atomima. Atomi u relacionom računu n-torki su:
!" A ∈ , R gde je x n-torka promenljiva, a R relacija, odnosno promenljiv x uzima vrednosti
iz skupa n-torki relacije R;
!" x.A θ y.B gde su x i y promenljive (n-torke), A i B su atributi relacija R1 i R2 iz čijih n-
torki, respektivno, promenljive x i y uzimaju vrednosti (x ∈ R1, y ∈ R2), a θ je operacija
poređenja definisana nad domenom atributa A i B (A i B moraju biti definisani nad istim
domenom);
!" x.A θ c gde su x, A i θ kao i u prethodnom stavu, a c je konstanta koja ima isti domen
kao i A.
Formule se formiraju od atoma preko sledećih pravila:
!" atom je formula;
!" ako je P1 formula, tada su formule i NOT P1 i (P1);
!" ako su P1 i P2 formule, tada su formule i P1 AND P2 i P1 OR P2;
!" ako je P1(s) formula koja sadrži neku slobodnu promenljivu s, tada su i ∃ s (P1(s)) i ∀ s
(P1(s), takođe, formule (∃ - "postoji", egzistencijalni kvantifikator, ∀ - "za svako",
univerzalni kvantifikator).
Jedna promenljiva u nekoj formuli se može pojaviti više puta. Promenljive mogu biti
"slobodne" i "vezane". Vezana promenljiva u formuli je neka vrsta "prividne" (dummy)
promenljive i ima ulogu da poveže promenljivu iza kvantifikatora sa promenljivima u zoni
dejstva kvantifikatora. Drugim rečima, vezana promenljiva u je (∃ u), (∀ u) ili (∃ u) A ili (∀
u) A, gde je A formula u kojoj se pojavljuje u. Sve promenljive koje u nekoj formuli nisu
vezane, slobodne su u toj formuli.
Na primer, u formuli: ∃x (x > 3), x je vezana promenljiva, pa je gornja formula ekvivalentna
sa ∃y (y > 3).
U formuli: ∃x (x > 3) AND x < 0, prvo pojavljivanje promenljive x je vezano, a drugo
slobodno, pa je ova formula ekvivalentna sa ∃y (y > 3) AND x < 0.
Neka su R1, R2, ..., Rn relacije u nekoj bazi podataka. Neka su A, B ..., C atributi ovih
relacija, respektivno, i neka je f - formula. Opšti izraz relacionog računa n-torki je tada:
t ∈ R1, u ∈ R2, ..., v ∈ Rn
t.A, u.B, ..., v.C GDE_JE f
(Prikazuju se vrednosti atributa A relacije R1, atributa B relacije R2, ... i atributa C relacije
Rn za one n-torke koje zadovoljavaju uslov definisan formulom f.)
230 alempije@beotel.yu
Relacioni račun domena
U relacionom računu domena promenljive uzimaju vrednosti iz nekih domena definisane
relacione baze podataka. Ovde se, pored navedenih, definiše još jedna atomska formula,
tzv. uslov članstva (membership condition). Uslov članstva ima sledeći oblik:
R (term, term, ...)
gde je R ime neke relacije, a svaki term ima oblik A:v, gde je A neki atribut relacije R, a v je
ili promenljiva ili konstanta.
Uslov članstva se izačunava u T (TRUE) ako postoji n-torka u relaciji R, koja ima zadate
vrednosti navedenih atributa.
Opšti izraz relacionog računa domena je:
x, y, ...,z GDE_JE f
Relaciona baza podataka stvara takav tip strukture koji se koristi za izražavanje odnosa
između podataka u obliku jednostavnih dvodimenzionalnih tabela. Za razliku od većine
drugih baza podataka (hijerarhijskih i mrežnih), relaciona baza podataka ima solidne
teoretske osnove, za koje ima najveće zasluge dr E.F.Codd, koji je objavio prve rezultate
svojih istraživanja već 1969. godine. Budućnost ovog sistema je velika, jer je za korisnika
relacioni sistem znatno jednostavniji od ostalih.
U relacionom sistemu je baza podataka izražena skupom vremenski promenljivih "relacija".
SUBP omogućava sve potrebne operacije sa relacijama i pri tom dozvoljava korišćenje
najrazličitijih kombinacija postojećih relacija, da bi time korisniku omogućio traženje
odgovora na sva pitanja koja imaju smisla s obzirom na sadržaj baze podataka.
Svaka relacija ima sva svojstva skupa. Osnovno svojstvo svakog skupa je da se elementi
koje on sadrži međusobno razlikuju. Tako se i svi redovi relacije međusobno razlikuju. To
znači da u relaciji uvek postoji neki atribut (ili neka kombinacija atributa), koji omogućava
jednoznačnu identifikaciju svakog retka. Takav atribut (odnosno takva kombinacija atributa)
koristi se kao "ključ" relacije.
Kolona (atribut) u relaciji je uvek homogena u tom smislu i sadrži samo vrednosti iz jednog
domena. Redosled redova u relaciji nije važan, jer se redovi ne identifikuju na osnovu svog
položaja već na osnovu ključa. Takođe, ni redosled kolona nije važan, jer smisao kolone nije
određen relativnom pozicijom kolone u relaciji, već imenom atributa.
alempije@beotel.yu 231
Prilog 2.
Alati za projektovanje
informacionih sistema
i SUBP (CASE alati)
Razvoj informacione tehnologije karakteristiše zaostajanje softvera u odnosu na hardver.
Pomenuti nedostatak softvera, koji se često naziva softverska kriza, nastaje zbog niske
produktivnosti i visokih proizvodnih troškova.
Rešenje softverske krize je u iskorišćenju osobina inženjera proverenih u praksi, i to, pre
svega, metodičnosti i operativne discipline. Kao rezultat nastaje softverski inženjering koji u
sebi sadrži sistematizovane i koordinirane aktivnosti potrebne pri projektovanju,
implementaciji, eksploataciji i održavanju softverskih proizvoda.
Dalji razvoj softverskih sistema na današnjem nivou mogućnosti računara i očekivanja
korisnika, zahteva visokostručan rad i programiranje za svoju realizaciju. Pošto je ručno
razvijanje softvera od najnižeg nivoa skupo i dugotrajno i sa ne uvek predvidivim
rezultatima, postoji potreba da se razvoj softvera olakša, zbog čega je, pre više od dvadeset
godina, nastalo softversko inženjerstvo kao disciplina.
Automatizacija softverskog inženjeringa na računaru se izvodi posebnim alatom, čiji je naziv
CASE (Computer Aided Software Engineering).
Definicija CASE
232 alempije@beotel.yu
Zavisno od toga koje faze projektovanja i implementacije CASE alati pokrivaju, oni se dele
na CASE alate na višem i CASE alate na nižem nivou. CASE alati na višem nivou pokrivaju
prve faze u proizvodnji softvera (analizu sistema i projektovanje), a CASE alati na nižem
nivou pružaju pomoć u fazama programiranja.
CASE sistem predstavlja alat koji služi kao pomoć projektantu informacionih sistema. Od
efikasnosti ovog alata može da zavisi kvalitet gotovog proizvoda (informacionog sistema),
tako da je projektantu veoma važno da odabere pravi alat koji će ga zamenjivati u većini
manuelnih poslova vezanih za projektovanje.
Od efikasnosti CASE alata može zavisiti kvalitet gotovog softverskog proizvoda. Uspešnim
korišćenjem pravilno odabranog CASE alata može se:
!" minimizirati vreme i trud (koštanje) razvoja softvera,
!" višestruko povećati produktivnost u pisanju softvera,
!" podići nivo kvaliteta,
!" povećati pouzdanost,
!" standardizovati proizvedeni softver.
Pored navedene podele CASE alata na više (UPPER) i niže (LOWER), koja je ujedno i najšire
prihvaćena, postoje i sledeće dve podele:
1. horizontalna - vremenski:
• viši alati - za više faze životnog ciklusa (korisnički zahtevi i dizajn),
• srednji alati - za srednje faze životnog ciklusa (implementacija - izrada),
• niži alati -z a niže faze životnog ciklusa (podrška eksploataciji);
2. vertikalna - po funkciji:
• alati za upravljanje, planiranje i procene,
• tehnički alati (realizacija),
• alati za podršku pojektu (skladišta, rečnici).
Integrisani CASE alati (Integrated CASE ili I-CASE) čine alate koji pokrivaju više vremenskih
faza i više funkcija. Primer takvog alata je Oracle Designer/2000, koji u sebi sadrži čitav niz
alata baziranih na integrisanom rečniku i koji pokriva sve faze izrade jednog informacionog
sistema.
Alati mogu podržavati različite tehnike modeliranja poslovnih sistema, pa se i po tome mogu
podeliti. Najrasprostanjenije tehnike modeliranja su:
!" ER metodologija (ili proširena ER metodologija) po notaciji Chen-a, Bachman-a...;
!" SSA (sistemska strukturna analiza za modeliranje funkcionalnog aspekta posmatranog
sistema) po notaciji Yourdon/de Marco, Gane/Sarson, Ward/Mellor;
• dijagrami toka programa (flow chart);
• funkcionalne hijerarhije (dekompozicije poslovnih funkcija);
• objektno-orijentisane metodologije, kao OMT i Grady Booch;
alempije@beotel.yu 233
• dijagrami tranzicije stanja.
Kvalitetu CASE alata doprinosi činjenica da mogu podržavati više tehnika modeliranja.
Alati se mogu podeliti i po filozofiji rada sa njima na:
!" alate sa ograničavajućom (restriktivnom) filozofijom, koji najviše pomažu novim
korisnicima, jer ih ograničavaju na stvari koje prvo moraju da urade; npr., da nacrtaju
kontekstni dijagram u SSA metodologiji, što pruža osećaj sigurnosti, mada, možda, malo
guši kreativnost;
!" alate sa vođenom filozofijom, koji su pogodni za korisnike višeg nivoa predznanja i
intelektualne zadatke višeg nivoa, jer samo vode korisnika i asistiraju mu u biranju
operacija;
!" alate sa fleksibilnom filozofijom koji dopuštaju potpunu slobodu korisniku, čak i da
generiše nekorektan dizajn; pogodni su za korisnike koji su već u potpunosti ovladali
metodologijom i hoće da alat prati njihov kreativni proces stvaranja koji ide malo
metodom sa vrha - nadole, a malo metodom sa dna - naviše. Ovakvi alati najviše vrše
sintaksne provere interno i odmah po unosu, a kasnije provere ispravnosti
(konzistentnosti) dizajna, i to isključivo na zahtev korisnika.
Dalje gledano, CASE alati mogu biti:
!" jednokorisnički - projekti se vode na jednom mestu i samo jedan korisnik upotrebljava
alat u jednom momentu;
!" višekorisnički - omogućavaju komunkaciju i koordinaciju velikih timova za razvoj
softvera; svima su dostupni planovi, statusni izveštaji, specifikacije, modifikacije, izvorni
kod i testni podaci.
Postoji još veliki broj načina na koje se CASE alati mogu klasifikovati (na primer, po
hardverskom okruženju i operativnom sistemu u kome rade, po jeziku na kome su razvijani
ili po otvorenosti arhitekture), ali se ne odnose na funkcionalnost i mogućnosti nego pre na
način razvoja samog alata.
234 alempije@beotel.yu
ALAT ZA
G RAFI^KU O BRAD U
ALAT ZA
O BRAD U TEKSTA
AN ALIZATO R
SO FTVERA
Repozitorijum je aktivan rečnik podataka koji podržava definisanje različitih tipova objekata
i njihovih veza. Alati za grafičku obradu omogućavaju razvijanje raznih tipova dijagrama,
kao i ocenu kompletnosti dijagrama na osnovu unapred definisanih pravila.
Alat za obradu teksta omogućava definisanje naziva, sadržaja i detalja pojedinih stavki u
repozitorijumu. Korisnički interfejs je interpreter koji određuje formu podataka koju treba
uzeti (grafika ili tekst). Analizator softvera je ekspertni deo CASE i on analizira ulaze kako u
dijagram tako i u repozitorijum, utvrđujući njihovu leksičku kompletnost, a i proveravajući
kompatibilnost sa ostalim objektima u aplikaciji. Korisnički interfejs obezbeđuje interaktivnu
i off-line obradu preko ekrana i izveštaja.
Idealni CASE treba da omogući potpunu automatizaciju kompletnog životnog ciklusa
projekta informacionog sistema, obuhvatajući početnu inicijativu, nivo analize, rad na
održavanju softverskog proizvoda sve do njegovog povlačenja. Takav CASE postaje žiža za
sve poslove softverskog inženjerstva, pa se rad na razvoju softvera koncentriše na logički
aspekt projektovanja. Upravo zbog toga idealni CASE treba da omogući: izradu arhitekture
procesa organizacije, planiranje i praćenje projekta, grupni rad na razvoju softvera,
aplikativno i ručno definisanje procedura, normalizaciju podataka, generisanje šeme baze
podataka, generisanje koda u korisnički odabranom programskom jeziku, automatsko
testiranje generisanog koda prema specifikaciji aplikacije i ekspertnu procenu savršenosti
proizvoda, kao i način korekcije. Idealni CASE treba već u repozitorijumu da prepozna
komponente koje su za ponovnu analizu, dizajn i kodiranje.
Po pravilu 40-20-40, koje važi za razvoj programskog sistema, 40% projektnog vremena
otpada na analizu i modelovanje, 20% je odvojeno za programiranje, a preostalih 40% za
testiranje. Trend dobavljača je da se eliminiše kodiranje, što čini samo jednu petinu
vremena potrebnu za razvoj softverskog proizvoda. Sadašnji trenutak zahteva postojanje
CASE alata koji će pokriti proces testiranja, a samim tim i skratiti vreme izrade softverskog
proizvoda.
Budući CASE biće u mogućnosti da u ostatku 40% projektnog vremena identifikuje delove
aplikacije koji mogu biti ponovo iskorišćeni. Iz navedenog se može pretpostaviti i put
razvoja CASE alata, a to je efikasnije pokrivanje vremena za analizu i dizajn, kao i vremena
potrebnog za testiranje.
alempije@beotel.yu 235
ORACLE CASE Designer/2000
Odlika ORACLE CASE Designer/2000 alata je da su integrisani i da pokrivaju sve faze u
razvoju sistema. Podržavaju koncept vodopada (Waterfall model), kao i "Spiral model"
razvoja informacioNOg sistema. Svi alati za razvijanje dijagrama napisani su u C++ tako da
je omogućeno korišćenje MS-Windows biblioteka. Koncepcija ORACLE CASE okruženja se
bazira na jakim radnim stanicama u Windows ambijentu i skupu alata (modelera,
dijagramera, utility-ja itd.) preko kojih se pristupa zajedničkom rečniku. Rečnik je baza
podataka koja sadrži informacije potrebne u svim fazama razvoja sistema. Svaki podatak se
u ovu bazu unosi samo jedanput, a onda se, po potrebi, referencira u svim slučajevima kada
je to potrebno.
Karakteristika rečnika je da je višekorisnički i da se njegova konzistentnost stalno prati
procedurama za održavanje referencijalnog integriteta i alatima za konsolidaciju. Različite
klase korisnika mu pristupaju kroz različite alate u pojedinim fazama razvoja sistema.
Sledi prikaz arhitekture Designer/2000.
PL/SQL Modules
Funcion Hierarchy Database triggers logic
Diagrammer
Functions
Triggers
Entity/Attribute Module Structure
Usages Diagrammer
Process Modeller
Application Module/Menus Forms Generator
Design Module Network
Organization Units
Generators Forms and
Proces Steps Wizard
Menus
Flows
Stores Dataflow Diagrammer Module Data
Triggers Diagrammer
Outcomes Functions Modules
Datastores Detailed Table Usages Report Generators
Dataflows (DTU) Generated Reports
Externals Detailed Column Usages
Triggers (DCU)
Entity/Attribute
Usages
Preferences Navigator
Generator Preferences
Repository Administration
Repository Object Navigator, Matrix Diagrammer, Repository Reports
236 alempije@beotel.yu
Entity Relationship Diagrammer (ERD)
Deo Oracle paketa Designer/2000, koji služi za modeliranje podataka, podržava sledeće
koncepte: atribut, entitet, specijalizaciju i generalizaciju (podtipovi i nadtipovi), veze.
Pri kreiranju entiteta ERD zahteva samo njegovo ime, a svi ostali detalji vezani za entitet,
kao i definisanje njegovih atributa, mogu se kasnije obaviti kroz opciju editovanja entiteta.
Po želji se atributi mogu prikazivati u okviru entiteta na dijagramu i tada postoji konvencija
da se: ispred atributa koji ulaze u sastav primarnog ključa stavlja znak "#", ispred atributa
koji su obavezni oznaka "*" i ispred opcionalnih atributa oznaka "o", što doprinosi
preglednosti dijagrama.
Pri modeliranju veza među entitetima zadaju se njihova opcionalnost (obaveznost veze se
predstavlja punom linijom, a neobaveznost veze isprekidanom linijom (sa svake strane veze
ponaosob) i njihova kardinalnost (veza sa gornjom granicom kardinalnosti 1 se predstavlja
jednom tačkom dodira linije, koja predstavlja vezu i odgovarajućeg entiteta, dok se veza sa
gornjom granicom kardinalnosti M predstavlja razgranatom linijom sa tri dodirne tačke).
Posebne vrste veza koje su podržane ovim CASE alatom su: prenosive i neprenosive veze
(transferable i non-transferable), a odnose se na mogućnost prevezivanja jedne pojave
entiteta sa drugom pojavom referentnog entiteta; spušteni ključevi, kada se kroz ovakvu
vezu u ključ zavisnog entiteta uključuje kompletan ključ entiteta od koga egzistencijalno
zavisi; rekurzivne veze, koje modeliraju vezu jedne pojave entiteta sa drugom pojavom
istog entiteta; ekskluzivne veze, koje modeliraju situaciju u kojoj može u jednom trenutku
postojati samo jedna od dve ili više veza koje polaze od jednog entiteta.
alempije@beotel.yu 237
Slika B.4. ERD – primer modela "objekti i veze” u grafičkom editoru
238 alempije@beotel.yu
ERwin
ERwin alat za modeliranje podataka je izgrađen na konceptima koji su postavljeni IDEF1X
standardom.
ERwin/ERX je CASE alat namenjen modeliranju podataka ER (Entity Relationship) metodom,
koja je podržana IDEF1X (Integration DEFinition for information modeling) metoda, a
korisnik može opciono koristiti i IE (Information Engineering) metodu. Modeliranje podataka
obuhvata dva aspekta: logičko definisanje modela i fizički dizajn baze. Korišćenje ovog alata
podrazumeva istovremeni razvoj logičkog modela podataka i fizičko definisanje baze, što
znači da nije potrebno nikakvo dodatno prebacivanje modela iz logičkog nivoa u fizički i
obrnuto.
U bilo kom trenutku definisanja logičkog nivoa baze, pre nego što se počne sa fizičkom
definicijom baze podataka, potrebno je odabrati ciljni server. To je DBMS na kome će model
biti realizovan. Izbor ciljnog servera nije definitivna stvar, što znači da se ciljni server može
menjati. ERwin insistira na nezavisnosti modela od DBMS platforme.
Server FRE (Forward and Reverse Engineering) omogućava živu vezu ERwin-ovog modela i
baze podataka. Konekcija se vrši preko ODBC drivera. Na osnovu definisanog fizičkog
modela podataka može se kreirati baza na odabranoj DBMS platformi. ERwin poseduje i
modul za inverzni inženjering, koji čita sistemske kataloge postojeće baze podataka, pa na
osnovu njih automatski kreira ER dijagram po metodologiji IDEF1X standarda.
Oba smera se svode na sinhronizaciju modela podataka sa bazom podataka i poređenje
modela sa stanjem baze. Osim sa bazom podataka, ERwin može da poredi model sa SQL
šemom ili drugim ERwin modelom. Model može selektivno da se sinhronizuje sa promenama
u bazi podataka u oba smera. Omogućena je postepena nadogradnja baze podataka iz
ERwin-ovog modela podataka, uz kontrolu fizičkih parametara baze podataka. Pri svakoj
sinhronizaciji sa bazom, ERwin pruža detaljan izveštaj o svim promenama nastalim
sinhronizacijom. Isti model podataka se može koristiti za generisanje više baza podataka na
različitim DBMS platformama, ili za konvertovanje aplikacija sa jedne DBMS platforme na
drugu.
ERwin/ModelMart (ili ERwin/AOS) proširen je na ERwin/ERX koji se standardno nalazi od
ERwin ver, 2.6. i predstavlja prvi alat koji omogućava višekorisnički rad na modelima
podataka (Workgroup). U tom slučaju je praćenje razvoja modela podataka znatno
komplikovanije. Korisnici svoje promene na modelu pohranjuju u SQL bazu podataka,
smeštenu na Microsoft SQL, Sybase ili ORACLE server, gde se vodi računa o zaključavanju
modela, verzijama, ovlašćenjima korisnika i sl.
ERwin je razvio set specijalizovanih verzija, kao što su: ERwin for Visual Basic, ERwin for
Power Builder, ERwin for ORACLE, ERwin for SYBASE i sl. U kreiranju specijalizovanih verzija
ide se za tim da se pojača sprega sa proizvodom za koji je verzija specijalizovana. Tako,
ERwin for ORACLE ima detaljniji rad sa ORACLE bazom, kao i interfejs ka ORACLE CASE-u.
Rad sa ostalim DBMS platformama je na nivou ERX verzije. Verzije za Power Builder i Visual
Basic imaju i proširenje koje gradi klijent-stranu aplikacije na navedenom alatu, bez obzira
na DBMS u koji se baza pohranjuje.
Verzija 2.6. ERwin-a obuhvata proširenje na ERwin/OPEN i predstavlja generalizaciju
specijalizovanih verzija ERwin-a koje tretiraju klijent-stranu aplikacije. Osim izbora servera,
korisnik bira i stranu klijenta. Ponuđeni su mu Power Builder i Visual Basic. U zavisnosti od
izbora klijenta, korisnik na modelu može definisati koncepte vezane za klijent-stranu
aplikacije koja se oslanja na bazu podataka koju modelira. Izbor Target Client-a ne zavisi od
izbora Target Servera. Logic works najavljuje i još neka proširenja kada je u pitanju klijent-
strana, npr. interfejs ka Delphi-ju.
ERwin/Navigator je jeftin alat koji pruža korisniku read-only pristup modelima podataka
razvijenim u Modelmart okruženju. Ovi dijagrami se mogu pretraživati i štampati i može se
iz njih kreirati dokumentacija. Uz ista ograničenja je podržana i klijent-strana razvoja
alempije@beotel.yu 239
aplikacije. Promene napravljene na modelu se ne mogu sačuvati.
DataBOT je proširenje za Visual Basic koje omogućava visok nivo rada sa Visual Basic-om.
DataBOT je alat koji ne zavisi od ERwin-a, ali se može nadograditi na ERwin i pojačati
spregu ERwin-a i Visual Basic-a, bez obzira na to da li je u pitanju ERwin/ERX, ERwin for
Visual Basic ili ERwin/Navigator.
Da bi pokrio proces testiranja, Logic Works izbacuje novi proizvod TESTBytes koji
omogućava brzo i lako kreiranje test-podataka, koji su refleksija stvarnih podataka. Na taj
način je uveliko skraćeno vreme testiranja.
SQL DBMSs
- AS/400 -Progress
-DB2/MVS -Red Brick
-DB2/2 -Rdb
ModelMart -Informix -SqlBase
Microsoft SQL Server -Ingres/OpenIngres -SYBASE
Modeli
Klase objekata SYBASE SQL Server -InterBase -Teradata
poslovnih procesa
ORACLE Server -NetWare SQL -Watcom/
-Oracle SQLAnywhere
Desktop DBMSs
-Access
OOwin BPwin -Clipper
-dBase
-Foxpro
-Paradox
240 alempije@beotel.yu
Artist
Artist CASE alat je razvijan da bi se pokrio celokupan razvoj informacionog sistema. Alat
omogućava automatizaciju prve faze u razvoju informacionih sistema, odnosno planiranje
razvoja informacionih sistema, koje se zasniva na BSP (Business System Planning) metodi.
Pored toga, poseduje i model koji podržava modelovanje procesa (SSA).
Modul koji omogućava modelovanje podataka podržava semantički veoma bogat model,
tako da se može modelirati neki skup podataka na veoma efektan i brz način. Artist
podržava sledeće koncepte: jak entitet, slab entitet, agregaciju, specijalizaciju i
generalizaciju (podtipove i nadtipove), vezu, identifikujuću vezu. Deo koncepata prikazan je
na primeru (slika B.6).
Izgled atributa i opis entiteta kroz formu dati su, takođe, na slici B.6. Nema komandi za
dodavanje, brisanje i ispravku atributa na samoj formi za opis entiteta, već se to realizuje
na formi koja se aktivira komandom Attributes, nakon čega se pojavljuje forma za unos.
alempije@beotel.yu 241
MagiCASE
MagiCASE je grafički orijentisan alat za modelovanje podataka. Zasnovan je na sledećim
konceptima: atribut, jak entitet, slab entitet, agregacija, specijalizacija i generalizacija
(podtipovi i nadtipovi), veza, identifikujuća veza.
U samom alatu može se menjati grafička prezentacija koncepata, čime je korisnik donekle
oslobođen krutih stega metodologije, što predstavlja veliki podstrek u kreativnosti korisnika
programa.
242 alempije@beotel.yu
EasyCASE System Designer podržava sledeće koncepte: atributi (za koje se mora naglasiti
da li je neki od njih običan atribut), primarni ključ, spoljni ključ, viševrednosni ili izvedeni
atribut, jak entitet, slab entitet.
Deo koncepata dat je primerom na gornjoj slici.
Na sledećoj slici data je forma za unos entiteta.
Podržava generisanje šeme baze podataka za sledeće server baze: ORACLE7, DB2, Rdb,
Ingres, SQLServer, SQLBase, SYBASE, Progress, kao i sisteme za upravljanje bazama
podataka na personalnim računarima: Clipper, FoxPro, dBASE, Paradox.
alempije@beotel.yu 243
S-Designor
S-Designor je alat za modeliranje podataka, grafički orijentisan, koji radi u okruženju
Microsoft Windows.
Osnovni elementi na kojima počiva su: atributi, entiteti, veze. Deo koncepata koje podržava
S-Designor dat je na slici B.12.
Iako prividno siromašan (poseduje samo jedan koncept od objekata), mogu se iskazati sve
vrste koncepata koje se pojavljuju u modelu objekti-veze. Prilikom definisanja entiteta i
njegovih osobina grafičke prezentacije, rad sa njim je identičan, nezavisno od toga koji se
koncept predstavlja. Naziv, atributi i opisi unose se na identičan način kod svih objekata, a
razlike između njih postaju očigledne tek kada se opredeli za vrste veza kojima se određeni
objekat povezuje sa ostatkom podmodela.
244 alempije@beotel.yu
Platinum
Platinum je integrisan skup alata sa mogućnošću da podrži proces razvoja informacionog
sistema, prateći životni ciklus procesa. Pojedini delovi, odnosno moduli razvijeni su tako da
podrže pojedine faze razvoja, a da, opet, čine jednu čvrstu celinu.
Platinum Proces Continuum pokriva aktivnosti upravljanja projektom razvoja informacionog
sistema, što uključuje izbor metodologija, planiranje i praćenje projekta, kao i praćenje
troškova uz mogućnost izveštavanja iz svih aktivnosti.
Platinum Paradigm Plus je esencijalni deo koji podržava fazu analize i dizajna. Alat je
izgrađen tako da potpuno podrži objektnu analizu i objektno projektovanje. To je grafički
orijentisan alat sa mogućnošću rada na raznim platformama i operativnim sistemima.
Podržava identifikaciju poslovnih zahteva, izgradnju modela i komponenti aplikacije.
Faza konstrukcije podržana je preko sledećih alata:
!" Platinum AionDS
!" Platinum ObjectPro
!" Platinum RuleServer
!" Platinum SQL-Station Tool Suite
Veoma važna faza testiranja pokrivena je modulima:
!" Platinum Final Exam Tool Suite
!" Platinum Final Exam Internet Test
alempije@beotel.yu 245
Literatura
1. dr Alempije Veljović, Integracija zahteva sistema kvaliteta u poslovanju preduzeća,
Savezi inženjera i tehničara Jugoslavije, Beograd, 1996. godina
2. dr Branislav Lazarević: "Projektovanje informacionih sistema", interni materijal, FON,
Beograd, 1990.
3. IT E 04-2-1, Sistemska analiza, podsetnik Intertrade, TOZD zastupništvo IBM,
Izobrazevalni centar, Ljubljana, Ver.1.0, 1984.
4. IT FA 40-2-1, Planiranje informacionih sistema, podsetnik Intertrade, TOZD zastupnistvo
IBM, Izobrazevalni centar, Ljubljana, Ver.1.0, 1984.
5. dr Vladimir R. Milačić, Sistem Analiza, Proizvodni informacioni sistem, Institut Mašinskog
fakulteta, Odeljenje za primenu kompjutera, Beograd, 1974.
6. User Guide for BPwin.
7. User Guide for ERwin.
8. Veljović A. i dr., Projekat revizije po standardu ISO 9000:2000 i veza sa informacionim
sistemom, Sojaprotein, Bečej, 2000.godina
9. Veljović A. i dr., Idejni projekat informacionog sistema programa A-85, interni materijal,
1989.
10. Veljović A. i dr., Detaljni projekat informacionog sistema programa A-85, interni
materijal, 1990.
11. ERwin, Methods Guide, 1995.
12. Veljović A. Razvoj informacionog sistema kvaliteta, materijal za istoimeni seminar,
Savez inžinjera i tehničara Jugoslavije, Beograd.
13. Veljović A. Kako definisati informacije potrebne računaru vezane za postavljanje sistema
kvaliteta serije standarda JUS ISO 9000. Seminar, Jugoslovenska organizacija za
standardizaciju i kvalitet (JUSK), Beograd, 20 - 21. decembar 1994. godine.
14. Veljović A. Gotova rešenja upravljanja kvalitetom za JUS ISO 9004 orjentisanih
računarskoj obradi podataka. Seminar, Jugoslovenska organizacija za standardizaciju i
kvalitet (JUSK), Beograd, 14 - 15. mart 1995. godine.
15. Veljović A. Naučite da kreirate informacioni sistem za upravljanje kvalitetom,
Informativno instruktivni seminar, Savez inžinjera i tehničara Jugoslavije, Beograd, 22 -
23. juna 1995. godine.
16. Veljović A. Elementi osiguranja kvaliteta u ambijentu osvajanja novog proizvoda
korišćenjem CASE alata, 21 JUPITER konferencija sa međunarodnim učešćem, 1.
simpozijim KVALITET, strana 5.97-5.103., Beograd, februar 1995.
17. Veljović A., Dekomponovanje procesa petlje kvaliteta, Časopis za unapređenje kvaliteta
Kvalitet, broj 5-6, strana 31-33, Poslovna politika, Beograd, 1995.
246 alempije@beotel.yu