erwin alat case tool

P6. Prilog

Projektovanje i realizacija studije slucajaputem CASE alata

u klijent-server okruzenju

U okviru ovog priloga prezentuje se postupak projektovanja i realizacije jednogtransakcionog programa u klijent-server okruzenju, uz upotrebu CASE proizvoda. Rec je otransakcionom programu za kreiranje naloga za otpremu, u okviru studije slucaja "Komer-cijalna funkcija", prezentovane u glavama 11. i 12. Za server baze podataka izabran je sis-tem za upravljanje bazama podataka ORACLE V.8.*. Izabrani CASE proizvod za projek-tovanje i generisanje programskog koda je Designer 2000 V.2.1, a ciljno okruzenje za pok-retanje transakcionog programa je Developer 2000 V.2.1.

Bez namere da se umanji vaznost sprovodjenja ostalih faza, u okviru priloga suprikazani rezultati sprovodjenja sledecih glavnih faza izgradnje baze podataka i programskepodrske:• analiza i formalno specificiranje korisnickih zahteva,• konceptualno projektovanje,• implementaciono projektovanje,• opis seme baze podataka putem jezika podataka i mehanizama SUBP i• generisanje i programiranje.

Prezentacija pomenute studije slucaja je organizovana tako da, u okviru ogranice-nog prostora knjige, ilustruje samo najbitnije aktivnosti koje treba sprovesti u cilju realiza-cije jednog transakcionog programa. Detaljno pokrivanje svih elemenata projektovanja iprakticne realizacije jednog dela informacionog sistema izlazi izvan okvira knjige. Treba,takodje, naglasiti da je i sama studija slucaja prilagodjena potrebama ove knjige, sto znaci

636. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka

da je svesno nacinjen odredjeni broj pojednostavljenja, koja u praksi ne bi mogla bitinapravljena. Neka od njih se odnose na izostavljeno pravilo poslovanja po kojem se naloziza otpremu koji imaju makar jednu realizovanu stavku, ili su kompletno realizovani, nesmeju modifikovati niti brisati, ili na pravilo poslovanja po kojem i otpremnica moze imatistatus realizovane ili nerealizovane, tako da se realizovane otpremnice ne mogu brisati ilimodifikovati, vec samo stornirati.

P6.1. Analiza i formalno specificiranje korisnickihzahteva studije slucaja

Faza snimanja, analize i formalnog specificiranja korisnickih zahteva je detaljnijeopisana u tacki 11.3. Na ovom mestu, prezentuju se rezultati sprovodjenja aktivnosti iz ovefaze na studiji slucaja "Komercijalna funkcija", uvedenoj putem primera 11.1. Rec je ozadacima koje, u smislu isporuke robe kupcu po poslatoj porudzbenici, moraju da obavereferent prodaje i skladistar. Na slici P6.1 je prikazana hijerarhijska dekompozicija funkcija- procesa, identifikovanih u okviru studije slucaja.

Slika P6.1.

U okviru navedene specifikacije funkcionalne strukture studije slucaja, funkcijePORUDZBINA, NALOG i IZDROB su proglasene elementarnim, sto znaci da se ocekuje dasvaka od navedenih funkcija reprezentuje jedan ili vise kompletnih transakcionih programa,zasnovanih na istoj ekranskoj ili stampanoj formi. Cinjenica da je za svaku od ovih funkcijazadat parametar Vreme odgovora = trenutno (u terminologiji proizvoda Designer 2000 Re-sponse = Immediate), ukazuje da ce se na osnovu ovih funkcija formirati programi sa ek-ranskim formama, namenjeni za interaktivno azuriranje baze podataka. Posto je IZDROB

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 637.

elementarna funkcija, tada funkcije IZDAVANJE i OTPREMNICA postaju atomarne funk-cije.

Kao sto je vec naglaseno u tacki 11.3, funkcije (procesi) se, saglasno sprovedenompostupku snimanja korisnickih zahteva, opremaju dodatnim tekstuelnim objasnjenjima ikomentarima, koji ce posluziti kao osnov za dalje sprovodjenje ove i narednih faza razvojaprograma. Na slikama P6.2 i P6.3 su prikazani tekstuelni opisi funkcija PORUDZBINA iNALOG.

Na slici P6.4 je prikazan dijagram toka podataka procesa KOMPOS, a na slikamaP6.5 i P6.6 su prikazani dijagrami tokova podataka direktno podredjenih procesa PORNALi IZDROB, saglasno specifikacijama, datim na slikama 11.2 i 11.3. Dijagrami tokovapodataka su oblikovani putem Designer-a 2000. Dijagram na slici P6.4 daje prikaz tokovapodataka na visem nivou apstrakcije, u odnosu na dijagrame sa slika P6.5 i P6.6. Saglasnotome, svaki tok podataka na slici P6.4, prikazan isprekidanom linijom*), reprezentuje jedanili vise tokova podataka sa podredjenih dijagrama i nasledjuje naziv jednog od njih. Takona primer, tok podataka sa slike P6.4 pod nazivom "Izvestaj o bonitetu,..."*) reprezentujetokove podataka sa slike P6.5 pod nazivom "Izvestaj o bonitetu" i "Izvestaj o mogucnostiisporuke".

Slika P6.2.

*) U terminologiji Designer-a 2000, ovakvi tokovi podataka se nazivaju Resolved Flows.*) Simbol "...", uz naziv toka, oznacava da dati tok podataka reprezentuje vise od jednog

toka podataka na nizem nivou apstrakcije.


Slika P6.3.

Slika P6.4.


Slika P6.5.

Slika P6.6.


P6.2. Konceptualno projektovanje studije slucaja

Postupci konceptualnog projektovanja baze podataka su detaljno razmatrani utacki 11.4. Na ovom mestu, kao rezultat konceptualnog projektovanja seme baze podatakastudije slucaja, na slici P6.7 je prikazan odgovarajuci ER dijagram konacnog resenja,izradjen putem Designer-a 2000. ER dijagram je sacinjen prema specifikaciji, zadatojputem slika 11.16, 11.33 i 11.34.

Slika P6.1.

Opsta pravila za tumacenje ovako prikazanog ER dijagrama se mogu pronaci utacki 13.3.5. Pored toga, ovde je potrebno naglasiti da:• simbol "#" uz obelezje oznacava da je rec o obelezju koje je u sastavu primarnog kljuca

tipa entiteta,• simbol "∗∗" uz obelezje oznacava da je rec o obelezju koje je obavezno za unos, odnosno

korespondira ogranicenju Null(N, A) = ⊥,• simbol "οο" uz obelezje oznacava da je rec o obelezju koje nije obavezno za unos, odnos-

no korespondira ogranicenju Null(N, A) = T,• simbol "||" na tipu poveznika oznacava da je tip entiteta na strani gde se nalazi simbol "||"

identifikaciono zavisan od tipa entiteta na drugoj strani, sto znaci da ce u sastav primar-


nog kljuca takvog tipa entiteta uci i sva obelezja primarnog kljuca tipa entiteta na drugojstrani posmatranog tipa poveznika, a

• simbol "� " na tipu poveznika oznacava da se pojave tipa entiteta na strani gde se nalazisimbol "� " ne mogu "prevezivati" za druge pojave tipa entiteta na drugoj strani. To znacida se ne dozvoljava modifikacija kljuca tipa poveznika, odnosno stranog kljuca buduceseme relacije, koja ce od posmatranog tipa entiteta nastati.

Na slici P6.8 je prikazan izvod iz specifikacije integriteta domena, sacinjene premaslici 11.14. Polje "Format" odgovara tipu podataka domena Typ(D), a polje "Max AttLength" odgovara maksimalnoj duzini podataka domena Len(D). Panel "Detail", koji ovdenije prikazan, sadrzi pored ostalog i polje za zadavanje predefinisane vrednosti domenaDef (D), a panel "Values" omogucava zadavanje dozvoljenih vrednosti, ili intervala dozvo-ljenih vrednosti domena, te u potpunosti odgovara specifikaciji uslova Con(D).

Slika P6.2.

Na slikama P6.9 i P6.10 je prikazan izvod iz specifikacije integriteta vrednostiobelezja za tip entiteta ZAGLAVLJE NALOGA. Polje "Domain" odgovara specifikaciji do-mena obelezja A tipa s nazivom N, Dom(N, A), a polje "Opt" (tj. "Optional") specifikacijinula vrednosti Null(N, A). Predefinisana vrednost Def(N, A) se zadaje u okviru panela "AttDetail", pri cemu u Designer-u 2000 postoji ogranicenje po kojem obelezje, vezano za nekidomen, obavezno nasledjuje njegovu predefinisanu vrednost Def(Dom(N, A)), ali je zatoostavljena mogucnost da se obelezje ne poveze ni sa jednim domenom.


Slika P6.3.

Slika P6.4.


Panel "Att Values", ciji je izgled prikazan na slici P6.10, obezbedjuje zadavanjedozvoljenih vrednosti, ili intervala dozvoljenih vrednosti obelezja, cime su samo delimicnopokrivene mogucnosti koje predvidja specifikacija uslova integriteta vrednosti obelezjaCon(N, A). Na slici P6.10 je prikazana deklaracija uslova Con(ZAGLAVLJE NALOGA,STN )∈{'D', 'N ' }, pri cemu skracenica 'D' oznacava realizovani, a 'N ' nerealizovani nalogza otpremu robe. Isto tako, realizovan je i uslov Con(STAVKA NALOGA, STA)∈{'R', 'I ' },pri cemu slovo 'R' oznacava rezervisanu, a 'I ' isporucenu robu sa stavke. Ukoliko se u bilokom redu, u panelu "Att Values", zadaju i vrednost polja "Value" i polja "High Value", pod-razumeva se da je zadat interval dozvoljenih vrednosti, cija je donja granica odredjenavrednoscu polja "Value", a gornja granica vrednoscu polja "High Value".

Na nivou svake eksterne seme, u okviru konceptualnog projekta seme baze poda-taka, predvidjeno je da se za svaki tip T eksterne seme zadaju uloge s obzirom na pravilaupotrebe i namenu posmatrane eksterne seme: Role(T ) ⊆ {r, i, m, d}. Isto tako, zadaje se iskup obelezja tipa, koji se putem programa, napravljenih nad datom eksternom semom,moze modifikovati Mod(T ) ⊆ Q. Koncept koji obezbedjuje realizaciju slicne logike uokviru Designer-a 2000 zasniva se na matricama Funkcije / Tipovi entiteta i Funkcije /Obelezja.

U preseku jedne vrste i jedne kolone matrice Funkcije / Tipovi entiteta zadaju senacini upotrebe tipa entiteta od strane posmatrane funkcije i mogu biti:• Create (C), sa znacenjem da je zadatak funkcije da formira nove pojave posmatranog

tipa entiteta i odgovara ulozi i∈Role(T ),• Retrieve (R), sa znacenjem da je zadatak funkcije da preuzima ("cita") podatke o posto-

jecim pojavama tipa entiteta i odgovara ulozi r∈Role(T ),• Update (U), sa znacenjem da je zadatak funkcije da modifikuje podatke o postojecim

pojavama tipa entiteta i odgovara ulozi m∈Role(T ),• Delete (D), sa znacenjem da je zadatak funkcije da brise pojave tipa entiteta i odgovara

ulozi d∈Role(T ),• Archive (A), sa znacenjem da je zadatak funkcije da, putem posebnih postupaka, arhivira

pojave tipa entiteta i• Other (O), sa znacenjem da funkcija ima, u odnosu na pojave posmatranog tipa entiteta,

zadatke koji nisu pokriveni prethodnim ulogama.U preseku jedne vrste i jedne kolone matrice Funkcije / Obelezja zadaju se nacini

upotrebe obelezja tipova entiteta od strane posmatrane funkcije i mogu biti:• Insert (I ), sa znacenjem da je zadatak funkcije da prvi put zadaje vrednost obelezja tipa

entiteta,• Retrieve (R), sa znacenjem da je zadatak funkcije da preuzme postojecu vrednost obe-

lezja tipa entiteta,• Update (U ), sa znacenjem da je zadatak funkcije da modifikuje prethodno zadatu vred-

nost obelezja tipa entiteta,• Nullify (N ), sa znacenjem da je zadatak funkcije da omoguci zadavanje nula vrednosti za

obelezje tipa entiteta, koje je prethodno imalo zadatu ne-nula vrednost,• Archive (A), sa znacenjem da je zadatak funkcije da omoguci arhiviranje vrednosti obe-

lezja tipa entiteta, putem posebnih postupaka i


• Other (O), sa znacenjem da funkcija ima, u odnosu na vrednosti posmatranog obelezjatipa entiteta, zadatke koji nisu pokriveni prethodnim ulogama.

Skup svih obelezja tipa entiteta, za koji posmatrana funkcija ima naznacenu ulogu Updateili Nullify, treba da odgovara skupu obelezja za modifikaciju Mod(T ).

Matrice Funkcije / Tipovi entiteta i Funkcije / Obelezja se projektuju tako da unjima figuriraju sve elementarne funkcije i, najcesce, ovim matricama su jedino one iobuhvacene, mada se uloge tipova entiteta i obelezja mogu zadavati i za ostale (na primeratomarne) funkcije.

Na slici P6.11 je prikazana matrica Elementarne funkcije / Tipovi entiteta, za stu-diju slucaja, saglasno specifikacijama uloga tipova u eksternim semama, sa slika 11.12 i11.13, kao i 11.17 i 11.18.

Slika P6.5.

Na slikama P6.12, P6.13, P6.14, P6.15, P6.16 i P6.17 su prikazane matrice Ele-mentarne funkcije / Obelezja, za tipove entiteta KUPAC, SKLADISTE, ROBA, ZALIHA,ZAGLAVLJE NALOGA i STAVKA NALOGA, u cilju ilustracije nacina zadavanja skupovaobelezja za modifikaciju u eksternoj semi koja pokriva formiranje naloga za otpremu robe,prema slikama 11.12 i 11.13. U cilju podsecanja, ponovo se navodi da je u eksternoj semiza formiranje naloga zadato Mod(Zaliha) = {RAS}, Mod(Zag_Nal ) = {OSN, STN } iMod(Stav_Nal ) = {KOL}.

Na kraju ovog dela, potrebno je naglasiti da konceptualno projektovanje transakci-onog programa, u smislu zahteva koji se postavljaju u okviru tacke 11.5, za formiranje na-loga za otpremu nije sprovedeno. Razlog zato je da ni sam Designer 2000, na konceptual-nom nivou, ne podrzava tehniku izrade strukturnih dijagrama, ili neku drugu tehniku zaformalno iskazivanje procedure, koju transakcioni program treba da sprovede.


Slika P6.6.

Slika P6.7.

Slika P6.8.


Slika P6.9.

Slika P6.10.

Slika P6.11.


P6.3. Implementaciono projektovanje studije slucaja

U prvom delu ove tacke prezentuju se rezultati projektovanja implementacioneseme baze podataka studije slucaja, a zatim se posvecuje paznja implementacionom pro-jektovanju programa za formiranje naloga za otpremu i implementacionom projektovanjuodgovarajuce podseme. Na ovom mestu, potrebno je naglasiti da CASE proizvod Designer2000 diktira takav redosled koraka, po kojem se prvo mora deklarisati specifikacija prog-rama pa se tek potom oblikuje podsema koja, takodje, pripada specifikaciji programa.

P6.3.1. Implementaciono projektovanje seme baze podatakastudije slucaja

Na slici P6.18 je prikazan dijagram implementacione seme baze podataka studijeslucaja, formiran nakon postupka prevodjenja konceptualne seme baze podataka sa slikeP6.7, u relacioni model podataka i izvrsene normalizacije. Svaki pravougaonik nadijagramu reprezentuje jednu semu relacije, odnosno buducu tabelu baze podataka, doklinije reprezentuju puteve prostiranja primarnog kljuca, odnosno ogranicenja stranog kljuca.Svaka sema relacije je na dijagramu reprezentovana svojim nazivom, u gornjem delu pra-vougaonika, skupom obelezja, u sredini pravougaonika, i nazivom ogranicenja primarnogkljuca, u donjem delu pravougaonika.

P6.3.1.1. Oblikovanje skupa obelezja i integriteta torke seme relacijestudije slucaja

Postupak prevodjenja konceptualne seme u relacioni model je sproveden upotre-bom alata Database Design Transformer, dok je projektovanje konacne verzije implemen-tacione seme baze podataka obavljeno pomocu alata Design Editor / Server Model. Konacniskup sema relacija implementacione seme, prikazan na slici P6.18, odgovara skupu semarelacija iz primera 12.2.

Radi ilustracije razlika izmedju prve verzije implementacione seme, dobijeneprevodjenjem ER seme baze podataka, i konacne verzije, u koju su ukljuceni efektisprovedene normalizacije, navode se sledeci primeri:• U inicijalnoj verziji seme relacije Stav_Nal postojala su dva obelezja: SN_ZG_FK_IDS i

SN_ZL_FK_IDS. Prvo od ova dva obelezja je reprezentovalo obelezje stranog kljucaIDS, prenetog u ovu semu relacije iz seme Zag_Nal, po osnovu veze SN_ZG_FK, dok jedrugo takodje reprezentovalo obelezje stranog kljuca IDS, ali koje je u ovu semu relacijepreneto iz seme Zaliha, po osnovu veze SN_ZL_FK. Preimenovanjem, umesto ova dvaobelezja, formirano je jedno obelezje, pod nazivom IDS, saglasno cinjenici da se nastavci naloga za otpremu moze naci samo roba iz onog skladista za koje se kompletannalog za otpremu formira.

• U inicijalnoj verziji seme relacije Stav_Otp postojalo je obelezje SO_SN_FK_BRN, kojeje reprezentovalo broj naloga za otpremu, kao obelezje stranog kljuca iz seme relacije


Stav_Nal. Saglasno analizi prezentovanoj u primeru 12.2, ovo obelezje je, u cilju zado-voljenja uslova trece normalne forme, uklonjeno iz seme relacije Stav_Otp.

Slika P6.1.

Alat Database Design Transformer, za prevodjenje ER seme baze podataka u rela-cioni model, obezbedjuje i automatizovano prevodjenje specifikacije integriteta tipa uspecifikaciju integriteta torke seme relacije. Na slikama P6.19 i P6.20 je prikazan izvod izspecifikacije integriteta vrednosti obelezja STN iz seme relacije Zag_Nal. Polje "Domain"odgovara specifikaciji domena obelezja A seme relacije N, Dom(N, A), a polje "Mandatory"specifikaciji nula vrednosti Null(N, A). Predefinisana vrednost Def (N, A) se zadaje u okvirupolja "Default value", pri cemu je u Designer-u 2000 moguce za obelezje seme relacije,koje je vezano za neki domen, zadati predefinisanu vrednost Def (N, A), ali je ostavljenamogucnost i da obelezje, ostavljanjem prazne vrednosti polja "Default value", nasledipredefinisanu vrednost domena Def (Dom(N, A)). Dozvoljeno je i da obelezje seme relacijene bude vezano ni za jedan domen.


Slika P6.2.

Slika P6.3.


Slika P6.4.

Slika P6.5.

Panel "Allowable Values", ciji je izgled prikazan na slici P6.20, obezbedjujezadavanje dozvoljenih vrednosti, ili intervala dozvoljenih vrednosti obelezja, cime su, jed-nim delom, pokrivene mogucnosti koje predvidja specifikacija uslova integriteta vrednostiobelezja Con(N, A).


Na slici P6.20 je prikazana deklaracija uslova Con(Zag_Nal, STN )∈{'D', 'N ' },koji je formiran preuzimanjem s konceptualnog nivoa deklaracije uslova Con(ZAGLAVLJENALOGA, STN )∈{'D', 'N ' }.

Uslov ogranicenja torke se u okviru Designer-a 2000 moze deklarisati i putemkoncepta tabelarnog ogranicenja, pod nazivom Check Constraint. Na slikama P6.21 i P6.22su prikazani paneli za definisanje uslova ogranicenja torke putem ovog koncepta, pri cemuje deklarisan uslov Con(Zaliha, RAS ) = RAS ≤ ZAL. Navedeni koncept obezbedjuje moguc-nost implementacije ogranicenja torke ili putem SQL klauzule CHECK, ili putem pozivalogicke, validacione funkcije, definisane na nivou servera baze podataka. U drugom sluca-ju, putem koncepta pod nazivom "Table API ", postoji i mogucnost automatizovanog gene-risanja trigera i procedura baze podataka, koji ce obezbediti poziv navedene logicke funk-cije prilikom pokusaja dodavanja novih, ili modifikacije postojecih podataka. Ako i samoako validaciona funkcija vrati istinitu vrednost (tj. vrednost true), ogranicenje se smatrazadovoljenim.

Koncepti Allowable Values i Check Constraint, na taj nacin, obezbedjuju potpunupokrivenost uslova integriteta vrednosti obelezja Con(N, A), uvedenog u glavi 6. Kada je upitanju specifikacija svih integriteta torki studije slucaja, zadata tabelom na slici 11.1,napominje se da je ona u potpunosti realizovana putem alata Design Editor / Server Model.

P6.3.1.2. Implementaciono projektovanje referencijalnih integritetastudije slucaja

Kada je rec o implementacionom projektovanju skupa medjurelacionih ogranice-nja, alat Database Design Transformer, takodje, obezbedjuje inicijalno formiranje skupareferencijalnih integriteta, saglasno izvrsenom prostiranju primarnih kljuceva. U postupkufinalizacije implementacione seme baze podataka, neophodno je izvrsiti eventualno potreb-na prilagodjavanja dobijenih referencijalnih integriteta i definisati druga medjurelacionaogranicenja, kao sto su prosireni referencijalni integriteti, inverzni referencijalni integriteti islozenija pravila poslovanja.

Dok se referencijalni integriteti u Designer-u 2000 mogu deklarisati upotrebomkoncepta na nivou tabele, pod nazivom Foreign Keys, svi drugi tipovi medjurelacionihogranicenja se projektuju pomocu koncepta trigera baze podataka i PL/SQL programa. Re-ferencijalni integriteti se, u najvecem broju slucajeva, mogu implementirati na nivouservera baze podataka deklarativno, a ostali tipovi medjurelacionih ogranicenja se imple-mentiraju iskljucivo upotrebom proceduralnih mehanizama. Detaljnije informacije o meha-nizmima i nacinima implementacije ogranicenja baze podataka na serveru baze podataka susadrzane u glavama 8 i 9, kao i prilogu P5.

Paneli za definisanje osnovnih podataka o referencijalnom integritetuZag_Nal[IDK] ⊆ Kupac[IDK], putem koncepta Foreign Keys, su prikazani na slikamaP6.23, P6.24, P6.25 i P6.26. Referencijalni integritet se definise na nivou referencirajucetabele, odnosno seme relacije koja se nalazi s leve strane referencijalnog integriteta. Osimnaziva (slika P6.23), svaki referencijalni integritet ukazuje na referenciranu semu relacije(tabelu) i specificira se da li je strani kljuc obavezan, ili opcionalan za unos.


Slika P6.1.

Slika P6.2.


Slika P6.3.

Slika P6.4.

Na sledecem panelu (slika P6.24) definisu se nizovi obelezja leve i desne stranereferencijalnog integriteta. Redosled obelezja u nizu odgovara redosledu vrsta u samom


panelu, a svaka vrsta sadrzi par obelezja, pri cemu je levo obelezje iz referencirajuce, adesno iz referencirane tabele.

Sto se tice vrste referencijalnog integriteta v, Designer 2000, V.2.1 i ORACLEV.8.* omogucavaju samo implementaciju podrazumevanog referencijalnog integriteta (v =b). Parcijalni i potpuni referencijalni integriteti nisu podrzani.

Panel "Cascade Rules" (slika P6.25) omogucava, putem liste izbora "Cascade de-lete rule", definisanje aktivnosti a, koja se sprovodi pri pokusaju brisanja torke iz referenci-rane relacije. Moguce aktivnosti su, kao sto je to vec navedeno i u glavi 7, sprecavanje (a =b), kaskadno brisanje (a = c), svodjenje na nula vrednost (a = n) i svodjenje na predefini-sanu vrednost (a = d).

Referencijalni integriteti za cije aktivnosti vazi a = b ili a = c, mogu seimplementirati putem deklarativnih mehanizama, dok se u ostalim slucajevima morapristupiti implementaciji putem proceduralnih mehanizama. Vec pomenuti "Table API "koncept, omogucava automatizovano generisanje trigera i procedura baze podataka, koji ceobezbediti proceduralnu implementaciju referencijalnih integriteta za koje je a = n ili a = d.

Na panelu "Cascade Rules", specificira se i to da li je dozvoljena modifikacijavrednosti stranog kljuca. Ako jeste, putem liste izbora "Cascade update rule", specificira seaktivnost koja se sprovodi pri pokusaju modifikacije vrednosti kljuca u referenciranoj rela-ciji. Moguce aktivnosti su iste kao i za slucaj pokusaja brisanja iz referencirane tabele, pricemu, ako je modifikacija stranog kljuca zabranjena, podrazumeva se da je aktivnost primodifikaciji sprecavanje.

Na slici P6.26, prikazan je sadrzaj panela "Validation", putem kojeg se zadaje po-datak o mestu validacije ogranicenja. Mesto validacije ogranicenja moze biti: "Server","Klijent", "Server i Klijent" ("Both") i "Nigde" ("None"). Na istom panelu se zadaje iporuka koja se prosledjuje korisniku programa, u slucaju da dodje do narusavanja ogranice-nja. Treba naglasiti da se u Designer-u 2000, iako to na slikama ovog priloga nije pri-kazano, za sva deklarativno zadata ogranicenja, vezana za tabelu, moze zadati i parametar"Defer Status", koji odredjuje trenutak aktiviranja kontrole ogranicenja. Moguce vrednostiovog parametra su: "Inicijalno odlozeno" ("Initially Deferred"), "Inicijalno trenutno" ("Ini-tially Immediate") i "Trenutno" ("Not Deferred") aktiviranje kontrole ogranicenja. Odloze-no aktiviranje podrazumeva da se kontrola ogranicenja sprovodi na samom kraju transak-cije, u postupku njenog potvrdjivanja.

Na slici P6.18 su svi referencijalni integriteti studije slucaja reprezentovani gra-ficki, putem linija. Rec je o referencijalnim integritetima koji pripadaju finalnom skupumedjurelacionih ogranicenja I iz primera 12.6. U nastavku su dati opisi znacenja simbola naovim linijama:• Puna linija oznacava da je rec o stranom kljucu koji je oznacen kao obavezan za unos, a

isprekidana linija oznacava strani kljuc cija se vrednost ne mora zadati.• Strana linije, na kojoj se nalazi simbol " ", oznacava referencirajucu, a druga strana

referenciranu tabelu.• Simbol "� " na liniji oznacava da je modifikacija vrednosti stranog kljuca zabranjena.• Simbol "||" na liniji oznacava da je rec o referencijalnom integritetu sa aktivnoscu pri

brisanju oznacenom kao "sprecavanje" (a = b).


• Simbol "××" na liniji oznacava da je rec o referencijalnom integritetu sa aktivnoscu pribrisanju oznacenom kao "kaskadno brisanje" (a = c).

Linije s nazivima SN_ZG_FK i SO_ZO_FK na slici P6.18 reprezentuju, redom,referencijalne integritete Stav_Nal[(IDS, BRN )] ⊆c Zag_Nal[(IDS, BRN )] i Stav_Otp[(IDS,BRO)] ⊆c Zag_Otp[(IDS, BRO)], izmedju takvih sema relacija koje su povezane i odgo-varajucim inverznim referencijalnim integritetima, redom, Zag_Nal[(IDS, BRN )] ⊆c

Stav_Nal[(IDS, BRN )] i Zag_Otp[(IDS, BRO)] ⊆c Stav_Otp[(IDS, BRO)]. Zbog toga su ovelinije na dijagramu "podebljane" i oznacene drugom (zelenom) bojom. Pri tome, inverznireferencijalni integriteti Zag_Nal[(IDS, BRN )] ⊆c Stav_Nal[(IDS, BRN )] i Zag_Otp[(IDS,BRO)] ⊆c Stav_Otp[(IDS, BRO)] se realizuju putem proceduralnih mehanizama, dok sereferencijalni integriteti Stav_Nal[(IDS, BRN )] ⊆c Zag_Nal[(IDS, BRN )] i Stav_Otp[(IDS,BRO)] ⊆c Zag_Otp[(IDS, BRO)] realizuju deklarativno. Za trenutak aktiviranja kontroleovih referencijalnih integriteta je izabrana vrednost Defer Status = Initially Deferred.

P6.3.1.3. Implementaciono projektovanje ostalih medjurelacionihogranicenja studije slucaja

Ostala medjurelaciona ogranicenja studije slucaja predstavljaju:• inverzni referencijalni integriteti Zag_Nal[(IDS, BRN )] ⊆c Stav_Nal[(IDS, BRN )] i

Zag_Otp[(IDS, BRO)] ⊆c Stav_Otp[(IDS, BRO)],• prosireni referencijalni integritet ><(Stav_Otp, Zag_Otp)[(IDS, BRN, IDR)] ⊆

Stav_Nal[(IDS, BRN, IDR)] i• pravilo poslovanja iz primera 12.6:

(P6.1) p: (∀t∈r(Zaliha))(t[ZAL] = t[RAS] + ∑∈sv

KOLv ][ )∈I,

gde je s = σSTA = rezervisan ∧ IDR = t[IDR](r(Stav_Nal )).Detaljan prikaz nacina realizacije navedenih inverznih referencijalnih integriteta,

prosirenog referencijalnog integriteta i pravila poslovanja p, datog izrazom (P6.1), nalazi seu prilogu P5 i zasnovan je na principima, izlozenim u glavama 8 i 9, te se na ovom mestutom pitanju ne posvecuje vise prostora. U nastavku teksta, daju se samo napomene koje subitne sa stanovista primene proizvoda Designer 2000 pri oblikovanju pomenutih ogranice-nja.

Linija s nazivom SO_SN_FK (slika P6.18) ne reprezentuje "obican" referencijalni,vec prosireni referencijalni integritet ><(Stav_Otp, Zag_Otp)[(IDS, BRN, IDR)] ⊆Stav_Nal[(IDS, BRN, IDR)]. Ovaj prosireni referencijalni integritet je nastao modifikacijomreferencijalnog integriteta Stav_Otp[(IDS, BRN, IDR)] ⊆ Stav_Nal[(IDS, BRN, IDR)]∈Ip, izprimera 12.6, nakon sprovedenog postupka normalizacije, zbog toga sto je iz seme relacijeStav_Otp uklonjeno obelezje BRN (odnosno SO_SN_FK_BRN ). Linija koja reprezentujenavedeni prosireni referencijalni integritet je, takodje, "podebljana" i oznacena drugom(crvenom) bojom. Posto se prosireni referencijalni integritet ne moze realizovati putemdeklarativnih mehanizama, tada se za ogranicenje stranog kljuca SO_SN_FK zadaje Vali-dation Level = None, a umesto ogranicenja stranog kljuca, formiraju se PL/SQL procedure i


trigeri baze podataka za podrsku prosirenog referencijalnog integriteta, onako kako je toopisano u prilogu P5.

Pravilo poslovanja (P6.1) na dijagramu sa slike P6.18 nije posebno prikazano. Onose implementira u drugacijoj formi od one, date putem prikazanog izraza, sto je prikazano uokviru priloga P5. Pri tome, vec pomenuti uslov Con(Zaliha, RAS ) = RAS ≤ ZALpredstavlja jednu od posledica pravila poslovanja p.

U cilju ilustracije, putem slika P6.27, P6.28 i P6.29, prikazan je postupak imple-mentacionog projektovanja jednog trigera baze podataka, u okviru Designer-a 2000. Rec jeo trigeru PP_Stav_Nal_INS, koji je definisan nad semom relacije (tabelom) Stav_Nal.

Na levoj strani slike P6.27, prikazan je hijerarhijski navigator objekata. Vidljivo jeda je triger PP_Stav_Nal_INS direktno podredjen tabeli Stav_Nal. Na desnoj strani isteslike, prikazano je telo trigera, iskazano putem proceduralnog jezika PL/SQL. Celokupanprogramski kod trigera reprezentuje objekat, odnosno PL/SQL program, pod nazivomPP_Stav_Nal_INS, koji je definisan u okviru klase Trigger Definitions. Deklarativni deoovog programa sadrzi definiciju izuzetka, pod nazivom Exc. Izuzetak Exc, zajedno s prog-ramskim kodom za njegovu obradu, definisan je u okviru klase Program Data.

Slika P6.1.


Slika P6.2.

Slika P6.3.

Na slici P6.28 je prikazan panel za zadavanje naziva, opisnog polja "svrha" inaziva PL/SQL programa, pridruzenog trigeru.


Sledeci panel, prikazan na slici P6.29, omogucava definisanje: dogadjaja koji po-krece izvrsenje trigera, trenutka okidanja trigera, kao i to da li je rec o trigeru koji se pokre-ce na nivou iskaza, ili na nivou torke. Ukoliko se za dogadjaj izabere operacija UPDATE,tada se otvara poseban panel, putem kojeg se zadaje skup obelezja tabele, cija modifikacijadovodi do pokretanja trigera. Panel "When" omogucava zadavanje logickog (WHEN)uslova, ukoliko triger treba takav uslov da sadrzi.

P6.3.2. Implementaciono projektovanje programa i podsemestudije slucaja

Ukoliko se upotrebljava CASE proizvod Designer 2000, tada su aktivnosti imple-mentacionog projektovanja programa i podseme medjusobno povezane, jer podsema egzis-tira iskljucivo u okviru specifikacije programa i svodi se na zadavanje upotreba tabela iupotreba kolona tabela, o cemu je bilo reci u tacki 13.5.7. Zato se ove dve aktivnosti, unastavku teksta, razmatraju u okviru jedne celine.

Inicijalno formiranje specifikacije programa, odnosno modula, prema terminolo-giji zastupljenoj u Designer-u 2000, pod nazivom "Izrada naloga za otpremu robe",obavljeno je putem alata Application Design Transformer, na osnovu:• podataka o elementarnoj funkciji NALOG,• konceptualne seme baze podataka, prikazane putem ER dijagrama sa slike P6.7,• delova matrica Elementarne funkcije / Tipovi entiteta i Elementarne funkcije / Obelezja

koji se odnose na kolonu za funkciju NALOG, prikazanih na slikama P6.11, P6.12,P6.13, P6.14, P6.15, P6.16 i P6.17 i

• implementacione seme baze podataka, ciji dijagram je prikazan na slici P6.18.Rezultat, dobijen pomocu alata Application Design Transformer, predstavlja kan-

didat za modul, tj. specifikaciju programa, pod nazivom NALOG0010. Ovaj kandidat semoze odbaciti i izbrisati, ili prihvatiti za nastavak rada. U okviru kandidata NALOG0010,dobijene su upotrebe tabela Kupac, Roba, Skladiste, Zaliha, Zag_Nal i Stav_Nal, s odgo-varajucim upotrebama kolona, odnosno vezanim poljima, saglasno sadrzaju matrica Ele-mentarne funkcije / Tipovi entiteta i Elementarne funkcije / Obelezja. Prihvatanjem za daljirad, kandidat za modul NALOG0010 postaje modul, pod istim nazivom. Nad ovim modu-lom se nadalje sprovode aktivnosti implementacionog projektovanja programa. Izmedjuostalih, u te aktivnosti spadaju:• pregled inicijalne specifikacije, dobijene putem Application Design Transformer-a,• preciziranje uloga sema relacija u podsemi, odnosno upotreba tabela u okviru buduceg

programa,• preciziranje uloga obelezja iz sema relacija podseme, odnosno upotreba kolona tabela,• detaljno oblikovanje izgleda ekranske forme, kao i nacina prikaza polja na formi i lista

vrednosti i• specificiranje nestandardnih postupaka obrade podataka, ili manipulacije podacima

putem programa.


Slika P6.1.

Na slici P6.30 je prikazan definicioni dijagram strukture programskog modulaNALOG0010, koji odslikava i strukturu podseme modula. Unutar pravougaonika kojireprezentuje sam modul, nalaze se dva pravougaonika, pod nazivom Zag_Nal i Stav_Nal,koji reprezentuju komponente modula, odnosno blokove podataka buduce ekranske forme.Prvi blok podataka ce odgovarati zaglavlju naloga za otpremu robe, a drugi stavkama nalo-ga za otpremu robe. Fizicko pozicioniranje komponenata modula na dijagramu odredjuje dace se blok podataka za zaglavlje naloga, na ekranskoj formi, fizicki naci iznad bloka poda-taka sa stavkama naloga.

U okviru prve komponente modula, nalazi se bazna upotreba tabele Zag_Nal iupotrebe tabela za dve liste izbora vrednosti Kupac i Skladiste s odgovarajucim upotrebamakolona, odnosno vezanim poljima. Spajanje podataka iz ovih tabela ce biti izvrseno premareferencijalnim integritetima, reprezentovanim putem ogranicenja implementacione semebaze podataka ZG_KP_FK i ZG_SK_FK. Tako na primer, spajanje torki iz tabela Zag_Nal iKupac se obavlja zbog potrebe prikaza vrednosti obelezja NAK i ADR u zaglavlju naloga i ulisti za izbor zeljene vrednosti obelezja IDK, kao i za validaciju direktno unete vrednostiobelezja IDK, pri unosu ili modifikaciji naloga za otpremu.


U okviru druge komponente modula, nalazi se bazna upotreba tabele Stav_Nal iupotrebe tabela za listu izbora vrednosti Zaliha i Roba. Predvidjeno je da se, prilikom po-zicioniranja kursora na ekransko polje koje odgovara obelezju IDR, moze pozvati listaizbora, koja ce dati prikaz vrednosti obelezja IDR, NAR, JM i RAS, za svu, ili izabranu robuna zalihama u datom skladistu. Isto tako, predvidjeno je da se uz svaku stavku naloga,pored obelezja IDR i KOL, prikazu i odgovarajuce vrednosti obelezja NAR i JM. Spajanjezaglavlja i stavki naloga se vrsi prema referencijalnom integritetu SN_ZG_FK, dok sespajanje stavke naloga sa zalihama obavlja prema referencijalnom integritetu SN_ZL_FK, azalihe s robom prema referencijalnom integritetu ZL_RO_FK.

Specifikacijom se, takodje, predvidja da se za svaku listu izbora vrednosti koristiposebna ekranska forma, sto znaci da je za svaku listu izbora trebalo napraviti i posebanekranski modul. U gornjem desnom delu dijagrama sa slike P6.30 je vidljivo da je modulNALOG0010 pozivajuci modul za tri druga modula: NALOG0010_L1, NALOG0010_L2 iNALOG0010_L3. Prvi od ova tri modula sluzi za prikaz liste izbora saglasno upotrebamatabela Zaliha i Roba. Drugi sluzi za prikaz liste izbora saglasno upotrebi tabele Kupac, atreci se koristi za prikaz liste izbora saglasno upotrebi tabele Skladiste.

Za sam modul, svaku komponentu modula, upotrebu tabele i upotrebu kolone,zadaje se citav niz parametara, koji omogucavaju detaljno implementaciono projektovanjemodula. Zbog izrazito velikog broja takvih parametara, na ovom mestu, ilustruje se ulogasamo nekih od njih.

Na slici P6.31 je prikazan panel "Operations", koji omogucava da se na nivoukomponente modula zadaju osnovne operacije koje se nad baznom tabelom te komponentemodula mogu sprovesti. Ostali paneli komponente modula, uglavnom, omogucavaju defini-sanje detalja nacina prikaza buduceg bloka podataka na formi. Kada je u pitanju kompo-nenta modula Zag_Nal, na slici P6.31 je vidljivo da su dozvoljene operacije: upis, brisanje,modifikacija i selekcija podataka za prikaz.

Slika P6.3 daje prikaz panela "Items" za upotrebu tabele. Na ovom panelu se, zasvaku upotrebu tabele, prebacivanjem iz levog (Available Columns) u desni prozor (Selec-ted Items), biraju obelezja seme relacije koja ulaze u sastav seme relacije podseme, odnosnobiraju se kolone tabele za koje se formiraju polja na formi. Putem indikatora pod nazivom[Disp], odredjuje se, takodje, i koja su polja na formi vidljiva za korisnika i definise seredosled prikaza polja na formi.

Na slici P6.33 je prikazan panel "Operations", putem kojeg se zadaju osnovneoperacije, koje korisnik sme da sprovede nad poljima forme. Tako, na primer, vidljivo je dakorisnik nece moci da modifikuje vrednosti polja kljuca IDS i BRN, seme relacije Zag_Nal,na zaglavlju naloga za otpremu, jer je indikator Update za ova dva polja iskljucen.

Na slici P6.34 je prikazan panel "Display", putem kojeg se zadaju neki, ali ne sviparametri vizuelnog prikaza polja na formi. Pored odredjivanja naslova, nacina prikaza idimenzija polja na formi, projektant je u mogucnosti da definise i format-masku za prikaznumerickih ili datumskih vrednosti, zada predefinisanu vrednost, te da li je polje obaveznoza unos podataka, da li se unos vrednosti ogranicava samo na velika slova, itd.

Projektant je, takodje, za svaku upotrebu tabele za listu izbora, u mogucnosti, daodredi koja polja ce biti vidljiva u listi izbora. Moguce je zadati i dodatni kriterijum selek-cije podataka kako za baznu, tako i za upotrebu tabele za listu vrednosti, cime se krajnjikorisnik pri selektovanju podataka ogranicava samo na podskup skupa torki tabele.


Slika P6.2.

Slika P6.3.


Slika P6.4.

Slika P6.5.

Na slici P6.35 je prikazan vizuelni dijagram modula NALOG0010. U okviru pra-vougaonika koji reprezentuje sam modul, nalazi se pravougaonik koji reprezentuje prozor s


naslovom "Nalog za otpremu" i obuhvata obe komponente modula. To znaci da ce celoku-pan sadrzaj ekranske forme biti rasporedjen na tacno jednom prozoru. U okviru kompone-nata modula, prikazana su samo polja koja su oznacena kao vidljiva za krajnjeg korisnika.Zapaza se da su i komponente modula i polja na ovom dijagramu prikazana putem svojihnaslova, koji se pojavljuju i na ekranskoj formi. Pravougaonici s naslovima Nalog i Zakupca, u okviru prve komponente modula, predstavljaju grupe polja, koje se zajedno prika-zuju.

Slika P6.6.

Simbol " ", koji se na slici P6.30 ili slici P6.35 moze primetiti na nivou poljaIDR, komponenti modula, kao i samog modula, oznacava da je na datom nivou definisanklijentski program, ili klijentski dogadjaj, namenjen za izvrsavanje u okviru modula. Uokviru implementacione specifikacije programskog modula postoji mogucnost definisanjadogadjaja na klijentu i klijentskih programa, putem kojih se mogu specificirati nestandardnipostupci obrade podataka, ili manipulacije podacima. Iako proces izrade klijentskih prog-


rama i definisanja klijentskih dogadjaja spada u aktivnost programiranja, a sam programskikod se oblikuje putem proceduralno orijentisanog jezika PL/SQL, rezultat ovog procesapripada implementacionoj specifikaciji programskog modula. Zbog toga se rezultati pos-tupka izrade klijentskih dogadjaja i programa u okviru ove studije slucaja prezentuju uokviru ove tacke priloga.

Kada je u pitanju programski modul za formiranje naloga za otpremu NA-LOG0010, programskim putem, realizovani su sledeci zahtevi:• da se obezbedi kontrola inverznog referencijalnog integriteta Zag_Nal[(IDS, BRN )] ⊆c

Stav_Nal[(IDS, BRN )], prilikom upisa novog naloga za otpremu u bazu podataka i• da se u listi izbora za prikaz raspolozivog stanja zaliha robe obezbedi selektovanje samo

zaliha robe iz skladista s vrednoscu sifre IDS, koja je specificirana u zaglavlju naloga.Prvi zahtev je nastao kao posledica opredeljenja da se upis torki u relacije

r(Zag_Nal ) i r(Stav_Nal ) sprovodi direktno, putem SQL naredbi oblika INSERT, a ne po-zivom udaljene procedure, pod nazivom Upis_Zag_Stav_Nal, prezentovane u okvirupriloga P5. Do ovog opredeljenja se doslo s ciljem lakse realizacije programskog modulaNALOG0010 putem Designer-a 2000. Da bi se navedeni zahtev ispunio, definisani su sle-deci klijentski dogadjaji:• "PRE-INSERT" klijentski triger, na nivou komponente modula Zag_Nal i• "POST-FORMS-COMMIT" klijentski triger, na nivou modula NALOG0010.

"PRE-INSERT" klijentski triger, na nivou komponente modula Zag_Nal (videtinavigator objekata na levoj strani slike P6.36), pokrece se neposredno pre svakog pokusajaupisa nove torke u relaciju r(Zag_Nal ) i obezbedjuje aktiviranje mogucnosti direktnog izvr-senja SQL INSERT naredbe, time sto se blokira aktivnost trigera baze podatakaUpis_IRI_Zag_Nal, prezentovanog u prilogu P5. Radi podsecanja, navodi se da triger bazepodataka Upis_IRI_Zag_Nal ima zadatak da onemoguci direktan upis novih torki u relacijur(Zag_Nal ).

"POST-FORMS-COMMIT " klijentski triger, na nivou modula NALOG0010, pok-rece se na samom kraju transakcije, ciji je zadatak upis novog naloga za otpremu u bazupodataka, odnosno jedne nove torke u relaciju r(Zag_Nal ) i svih povezanih torki u relacijur(Stav_Nal ). Na levoj strani slike P6.36 je prikazan izvod iz hijerarhije objekata modulaNALOG0010, u kojoj se vidi da navedeni triger pripada potklasi Applicatoin Logic / Events.Na desnoj strani iste slike je prikazan PL/SQL programski kod posmatranog trigera. Zada-tak ovog klijentskog trigera je da deaktivira mogucnost direktnog izvrsenja SQL INSERTnaredbe, time sto se deblokira aktivnost trigera baze podataka Upis_IRI_Zag_Nal, pozivomserverske procedure Izvrsenje_okidaca, opisane u glavi 9. Pored toga, ovaj triger sadrzi ipoziv serverske funkcije Sadrzi_IRI_Zag_Nal, koja za zadatu torku v, odnosno zaglavljenaloga za otpremu, proverava da li u relaciji r(Stav_Nal ) postoji najmanje jedna odgovara-juca stavka naloga za otpremu. Ukoliko uslov nije zadovoljen, transakcija se ponistava.Detaljniji opis funkcije Sadrzi_IRI_Zag_Nal se nalazi u prilogu P5.

Drugi zahtev, da se u listi izbora za prikaz raspolozivog stanja zaliha robeobezbedi selektovanje samo zaliha robe iz skladista s vrednoscu sifre IDS, koja je specifici-rana u zaglavlju naloga, realizuje se programski zbog odluke da se lista izbora prikazujeputem posebne forme i "nesavrsenosti" generatora koda Designer-a 2000 da, u toj situaciji,sam obezbedi automatski prenos vrednosti obelezja IDS, kao parametra u listu vrednosti.Programski kod i dogadjaj, potrebni za podrsku ovakvog zahteva, na ovom mestu nece biti


prezentovani, s tim sto je potrebno napomenuti da je sam programski kod formiran kombi-novanjem drugih segmenata programa, koje je Designer 2000 u stanju da izgenerise i da jesmesten u okviru recnika podataka, tj. pripada specifikaciji modula.

Slika P6.7.

P6.4. Opis seme baze podataka putem jezika podataka imehanizama SUBP za studiju slucaja

U okviru ove tacke priloga, prezentuje se deo opisa seme baze podataka, prikaza-nog putem jezika SQL. Rec je o automatski generisanom kodu, produkovanom pomocugeneratora SQL koda Designer-a 2000 i prilagodjenom za SUBP ORACLE V.8.*. SQLopis seme baze podataka je dobijen na osnovu specifikacije implementacionog projektaseme baze podataka, ciji elementi su razmatrani u delu P6.3.1.

Na slici P6.37 je prikazan izvod iz datoteke koja sadrzi SQL naredbe za kreiranjeodgovarajucih tabela. Na slikama P6.38, P6.39 i P6.40 su prikazani izvodi iz datoteke kojasadrzi SQL naredbe za kreiranje ogranicenja seme baze podataka putem deklarativnih me-hanizama. Slika P6.2 daje prikaz naredbi za kreiranje ogranicenja primarnog kljuca, slika


P6.39 daje prikaz naredbi za kreiranje ogranicenja torki, a slika P6.40 daje prikaz naredbiza kreiranje ogranicenja stranog kljuca. Na slici P6.41 je prikazan tekst trigeraPP_Stav_Nal_INS, opisanog u tacki P6.3.1.3.

CREATE TABLE KUPAC(IDK NUMBER(6) NOT NULL,NAK VARCHAR2(30) NOT NULL,ADR VARCHAR2(60) NOT NULL,BON NUMBER(6) DEFAULT 5 NOT NULL)

/CREATE TABLE SKLADISTE

(IDS NUMBER(6) NOT NULL,NAS VARCHAR2(15) )

/CREATE TABLE ROBA

(IDR NUMBER(6) NOT NULL,JEM VARCHAR2(15) NOT NULL,NAR VARCHAR2(30) NOT NULL)

/CREATE TABLE ZALIHA

(IDS NUMBER(6) NOT NULL,IDR NUMBER(6) NOT NULL,ZAL NUMBER(10,4) DEFAULT 0 NOT NULL,RAS NUMBER(10,4) DEFAULT 0 NOT NULL)

/CREATE TABLE ZAG_NAL

(IDS NUMBER(6) NOT NULL,BRN NUMBER(6) NOT NULL,IDK NUMBER(6) NOT NULL,STN VARCHAR2(15) NOT NULL,OSN VARCHAR2(15))

/CREATE TABLE STAV_NAL

(IDS NUMBER(6) NOT NULL,BRN NUMBER(6) NOT NULL,IDR NUMBER(6) NOT NULL,STA VARCHAR2(15) NOT NULL,KOL NUMBER(10,4) DEFAULT 0 NOT NULL)

Slika P6.1.


ALTER TABLE KUPACADD CONSTRAINT KP_PK PRIMARY KEY (IDK)

/ALTER TABLE ROBA

ADD CONSTRAINT RO_PK PRIMARY KEY (IDR)/ALTER TABLE SKLADISTE

ADD CONSTRAINT SK_PK PRIMARY KEY (IDS)/ALTER TABLE ZALIHA

ADD CONSTRAINT ZL_PK PRIMARY KEY (IDS, IDR)/ALTER TABLE ZAG_NAL

ADD CONSTRAINT ZG_PK PRIMARY KEY (IDS, BRN)/ALTER TABLE STAV_NAL

ADD CONSTRAINT SN_PK PRIMARY KEY (IDS, BRN, IDR)/

Slika P6.2.

ALTER TABLE KUPACADD CONSTRAINT AVCON_KUPAC_IDK_000

CHECK (IDK BETWEEN 100 AND 9999)ADD CONSTRAINT AVCON_KUPAC_BON_000

CHECK (BON BETWEEN 0 AND 5)/ALTER TABLE ZAG_NAL

ADD CONSTRAINT AVCON_ZAG_N_BRN_000CHECK (BRN BETWEEN 100000 AND 199999)

ADD CONSTRAINT AVCON_ZAG_N_STN_000 CHECK (STN IN ('D', 'N'))ADD CONSTRAINT AVCON_ZAG_N_OSN_000 CHECK (OSN IN ('U', 'P'))

/ALTER TABLE STAV_NAL

ADD CONSTRAINT AVCON_STAV__STA_000 CHECK (STA IN ('R', 'I'))ADD CONSTRAINT AVCON_STAV__KOL_000

CHECK (KOL BETWEEN 0 AND 999.99)/ALTER TABLE ZALIHA

ADD CONSTRAINT CHECK_ZAL_RAS CHECK (RAS <= ZAL)ADD CONSTRAINT AVCON_ZALIH_ZAL_000

CHECK (ZAL BETWEEN 0 AND 999999.9999)ADD CONSTRAINT AVCON_ZALIH_RAS_000

CHECK (RAS BETWEEN 0 AND 999999.9999)

Slika P6.3.


ALTER TABLE ZALIHAADD CONSTRAINT ZL_SK_FK FOREIGN KEY (IDS)

REFERENCES SKLADISTE (IDS)ADD CONSTRAINT ZL_RO_FK FOREIGN KEY (IDR)

REFERENCES ROBA (IDR)/ALTER TABLE ZAG_NAL

ADD CONSTRAINT ZG_KP_FK FOREIGN KEY (IDK)REFERENCES KUPAC (IDK)

ADD CONSTRAINT ZG_SK_FK FOREIGN KEY (IDS)REFERENCES SKLADISTE (IDS)

/ALTER TABLE STAV_NAL

ADD CONSTRAINT SN_ZG_FK FOREIGN KEY (IDS, BRN)REFERENCES ZAG_NAL (IDS, BRN)ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED

ADD CONSTRAINT SN_ZL_FK FOREIGN KEY (IDS, IDR)REFERENCES ZALIHA (IDS, IDR)

Slika P6.4.

CREATE OR REPLACE TRIGGER PP_STAV_NAL_INSBEFORE INSERT ON STAV_NALFOR EACH ROW

DECLAREEXC EXCEPTION;

BEGINIF :NEW.STA != 'R' THEN

RAISE exc;END IF;UPDATE Zaliha

SET RAS = RAS - :NEW.KOLWHERE IDS = :NEW.IDS

AND IDR = :NEW.IDR;EXCEPTION

WHEN EXC THENRAISE_APPLICATION_ERROR(-20004,

'Status stavke naloga mora biti "rezervisano".');WHEN OTHERS THEN

RAISE_APPLICATION_ERROR(-20000,'Doslo je do greske pri upisu nove stavke naloga i ' ||'modifikaciji raspolozivog stanja zaliha');

END;/

Slika P6.5.


P6.5. Generisanje i programiranje

Generisanje programa za formiranje naloga za otpremu NALOG0010 jesprovedeno upotrebom generatora Forms modula, za okruzenje Developer 2000 V.2.1. Upostupku generisanja, koji je obicno iterativne prirode, vrse se dodatne modifikacije im-plementacione specifikacije modula, da bi se otklonili eventualno uoceni nedostaci, ili da bise izvrsila poboljsanja izgleda dobijene ekranske forme. Izmedju ostalog, tokomgenerisanja se pojavljuje i potreba izmene predefinisanih vrednosti generatorskihpreferenci. Preference su parametri generatora modula, cije vrednosti dodatno uticu naizgled, nacin generisanja i nacin funkcionisanja izgenerisanog programa. Vrednostigeneratorskih preferenci se mogu zadati na nivou aplikacionog sistema, domena, tabele,kolone tabele, modula, komponente modula, vezanog polja, itd, cime se definise i "opsegdelovanja" vrednosti preference.

Na slici P6.42 je prikazan izgled ekranske forme za formiranje naloga za otpremu,izgenerisanog modula NALOG0010.

Slika P6.1.


Slika P6.2.

Na slici P6.43 je prikazan izgled iste ekranske forme, u trenutku kada se kursornalazio na polju za unos identifikacionog broja kupca (IDK ) i kada je pozvana lista izboravrednosti identifikacionog broja kupca. U okviru ove, kao i svih drugih lista izbora u ovommodulu, korisnik ima mogucnost da zada dodatne kriterijume za prikaz izvoda iz celokupneevidencije.

Slika P6.3 daje prikaz ekranske forme za formiranje naloga za otpremu, u trenutkukada se kursor nalazio na polju za unos identifikacionog broja robe (IDR) i kada je pozvanalista izbora vrednosti identifikacionog broja robe. U ovoj listi vrednosti, mogu se naci samopodaci o robi koja je evidentirana na zalihama onog skladista, ciji je identifikacioni brojnaveden u zaglavlju naloga. U ovom primeru, rec je o skladistu s identifikacionim brojem10.


Slika P6.3.

Osnovna logika izvrsavanja interaktivnog modula NALOG0010 jeste da korisnik,nakon pokretanja programa i prijavljivanja na server baze podataka, moze da selektuje,zadaje, modifikuje, ili brise podatke o nalogu za otpremu, putem prikazane ekranske forme.Ti podaci se smestaju u radnu zonu programa. U slucaju da je putem ekranske forme izvr-seno azuriranje podataka u radnoj zoni programa, korisnik je u obavezi da pokrene postu-pak azuriranja podataka u bazi, izborom funkcije "Sacuvaj" ("Save", na primer pokretanjemopcije menija Action/Save, ili aktiviranjem odgovarajuce ikone), ili da odustane od izmena.Sam postupak azuriranja se sprovodi automatski, putem jedne transakcije, a korisnik ce, nakraju izvodjenja transakcije, biti obavesten o efektima njenog sprovodjenja. Za svaku novo-dodatu torku u radnoj zoni programa, u okviru transakcije ce automatski biti formiranajedna SQL INSERT naredba. Isto tako, za svaku modifikovanu torku u radnoj zoni progra-ma, transakcija ce sadrzati jednu UPDATE naredbu, dok ce za svaku torku u radnoj zoniprograma, koja je oznacena kao izbrisana, transakcija sadrzati jednu DELETE naredbu.


Da bi se dobio prikazani interaktivni program, izvrsena su prilagodjenja vrednostipojedinih generatorskih preferenci, kao i neznatna prilagodjenja sablonske forme i bibliote-ke Developer 2000 Forms objekata, koje generator, pri svom radu, takodje koristi. U praksi,da bi se ostvarila maksimalna efikasnost upotrebe generatora koda Designer-a 2000, pot-rebno je:• propisati standarde za izgled korisnickog interfejsa generisanih aplikacija,• propisati standarde upotrebe ovog CASE proizvoda,• formirati opste komponente modula*), koje se, prema propisanom standardu, ukljucuju u

specifikacije konkretnih programskih modula i• izvrsiti znatna prilagodjenja vrednosti generatorskih preferenci, uvodjenjem imenovanih

skupova preferenci, sablonske forme i biblioteke Developer 2000 Forms objekata.U nastavku teksta, kao ilustracija, navodi se da je izvrseno redefinisanje vrednosti

generatorske preference pod nazivom VLDTPK, kojom se odredjuje trenutak proverevazenja ogranicenja primarnog kljuca putem klijentskog programa. Za ogranicenje primar-nog kljuca se, generalno, u okviru specifikacije implementacione seme baze podataka, na-vodi mesto validacije (provere vazenja) ogranicenja, koje, kao sto je vec napomenuto, mozeimati vrednost: "Server", "Klijent", "Server i Klijent", ili "Nigde". Ukoliko je za mestoprovere vazenja ogranicenja izabrana vrednost "Klijent", ili "Server i Klijent", tada ce gene-rator Forms modula obezbediti generisanje klijentskog programa koji ce proveriti vazenjeogranicenja primarnog kljuca. Inicijalna vrednost preference VLDTPK = B znaci da ce po-ziv takvog klijentskog programa uslediti:• nakon pokusaja zadavanja ili modifikacije vrednosti poslednjeg polja koje odgovara

obelezju primarnog kljuca, sto se naziva validacija na nivou polja i• na pocetku transakcije za azuriranje podataka u bazi, sto se naziva validacija na nivou

transakcije.Obe validacije putem klijentskog programa su, u logickom smislu, suvisne, posto je ograni-cenje primarnog kljuca, putem deklarativnih mehanizama, implementirano na serveru bazepodataka. Validacija na nivou transakcije je u ovom slucaju, medjutim, potpunonepotrebna, jer se sprovodi, sa stanovista krajnjeg korisnika, u isto vreme kao i validacijaogranicenja na nivou servera baze podataka. Zbog toga je promenjena vrednost posmatranepreference, tako da vazi VLDTPK = F. To znaci da ce putem klijentskog programa bitiobezbedjena samo validacija na nivou polja, kako bi korisnik bio, u slucaju narusavanjaogranicenja primarnog kljuca, upozoren da je doslo do greske vec pri pokusaju napustanjaposlednjeg polja koje odgovara obelezju primarnog kljuca, a ne tek u momentu kadapokrene transakciju azuriranja podataka u bazi.

U okviru ovog teksta, bice ilustrovana i motivacija za izmenu vrednosti generator-ske preference LOVVAL. Naime, u okviru implementacionog projekta seme baze podataka,predvidjeno je da se za mesto validacije ogranicenja stranog kljuca ZG_KP_FK izaberevrednost "Server i Klijent", sto znaci da je referencijalni integritet Zag_Nal[IDK ] ⊆ Ku-pac[IDK ] potrebno kontrolisati i putem klijentskog programa, nakon pokusaja zadavanja ilipromene vrednosti polja IDK. Ukoliko se projektant opredeli za prikaz liste izbora vred-nosti putem predefinisanog objekta, pod nazivom Forms LOV objekat, a ne putem posebneekranske forme, tada inicijalna vrednost preference LOVVAL = Y obezbedjuje da se

*) Na engleskom: reusable module components.


kontrola navedenog referencijalnog integriteta izvrsi automatski, bez dodatnog pisanjaklijentskog programa za tu svrhu. Posto je u ovoj studiji slucaja opredeljenje da se sve listeizbora vrednosti prikazu putem posebnih ekranskih formi, tada se ne moze obezbeditiautomatska kontrola validnosti referencijalnog integriteta na klijentu, vec se u te svrhe moraizgenerisati poseban klijentski program i jedan klijentski dogadjaj. Da bi se to postiglo,potrebno je redefinisati vrednost preference LOVVAL, tako da bude LOVVAL = N.

Nakon definisanja vrednosti preference LOVVAL = N, generator Forms modula ceautomatski formirati klijentski triger (dogadjaj) pod nazivom "When-Validate-Item", nanivou polja IDK, u okviru zaglavlja naloga. Na levoj strani slike P6.45 je prikazano mesto uhijerarhiji objekata alata Form Builder iz okruzenja Developer 2000, na kojem je triger"When-Validate-Item" definisan, dok je na desnoj strani iste slike prikazan PL/SQL prog-ramski kod, pridruzen ovom trigeru. Triger ce se pokrenuti neposredno nakon pokusajakorisnika da zada, ili modifikuje vrednost polja IDK, bilo pri napustanju polja, bilo pri za-htevu korisnika da se pokrene transakcija za azuriranje podataka u bazi. Namena trigera jeda spreci takvo zadavanje ili modifikovanje vrednosti polja IDK, koje bi narusilo referen-cijalni integritet Zag_Nal[IDK ] ⊆ Kupac[IDK ].

Slika P6.4.

Centralno mesto u programskom kodu posmatranog trigera, koji se izvrsava naklijentu, zauzima poziv procedure pod nazivom CGFK$CHK_ZAG_NAL_ZG_KP_FK. Onaje, takodje, u potpunosti formirana od strane generatora Forms modula. Sam programski


kod ove klijentske procedure je prikazan na slici P6.46. Njena namena je da se, za zadatuvrednost polja IDK, odnosno parametra P_IDK, proveri da li u bazi podataka, odnosnorelaciji r(Kupac), postoji torka sa zadatom vrednoscu identifikacionog broja kupca. Ukolikotaj uslov nije ispunjen, izaziva se, putem naredbe RAISE, izuzetak NO_DATA_FOUND.Ovaj izuzetak je obradjen u okviru naredbe WHEN NO_DATA_FOUND THEN, trigera"When-Validate-Item", tako sto se, uz odgovarajucu poruku, prekida izvrsenje trigera, akursor ostavlja na poziciji polja IDK.

Slika P6.5.

Treba napomenuti i to da se procedura CGFK$CHK_ZAG_NAL_ZG_KP_FK izvr-sava manjim delom na klijentu, a vecim na serveru baze podataka. Tako, na primer,naredbe za otvaranje kursorskog podrucja (OPEN C ), pristup torki u kursorskom podrucju(FETCH C ), zatvaranje kursorskog podrucja (CLOSE C ) i preuzimanje vrednosti logickepromenljive C%NOTFOUND, koja vraca vrednost true, ako i samo ako je kursorsko pod-rucje prazno, predstavljaju zahteve koji se prosledjuju serveru baze podataka, kako bi ih onrealizovao za potrebe klijentskog programa CGFK$CHK_ZAG_NAL_ZG_KP_FK.

Aktivnost programiranja modula, u pristupu koji namece Designer 2000 V.2.1,treba da se svede na definisanje specificnih klijentskih dogadjaja i programa u samoj speci-


fikaciji programskog modula i, eventualno, predefinisanje vrednosti generatorskih prefe-renci, koje ne podlezu propisanom standardu, o cemu je vec bilo reci u ovom tekstu. Toznaci da se vise ne preporucuje takav pristup razvoju aplikacija, u kojem su neophodnenaknadne dorade izgenerisanih programskih modula izvan okruzenja Designer-a, jer bi setime bitno umanjila efikasnost razvoja i kasnijeg odrzavanja aplikacija informacionog sis-tema. Kako bi se postigao cilj da izgenerisane aplikacije budu prakticno upotrebljive bezdorada izvan okruzenja Designer-a, neophodno je ostvariti i sve preduslove za efikasnokoriscenje CASE proizvoda Designer 2000, koji su u ovom tekstu samo naznaceni.

Documents

erwin alat case tool