P6. Prilog Projektovanje i realizacija studije slucaja putem CASE alata u klijent-server okruzenju

P6. Prilog Projektovanje i realizacija studije slucaja putem CASE alata u klijent-server okruzenju U okviru ovog priloga prezentuje se postupak projektovanja i realizacije jednog transakcionog programa u klijent-server okruzenju, uz upotrebu CASE proizvoda. Rec je o transakcionom programu za kreiranje naloga za otpremu, u okviru studije slucaja "Komercijalna funkcija", prezentovane u glavama 11. i 12. Za server baze podataka izabran je sistem za upravljanje bazama podataka ORACLE V.8.*. Izabrani CASE proizvod za projektovanje i generisanje programskog koda je Designer 2000 V.2.1, a ciljno okruzenje za pokretanje transakcionog programa je Developer 2000 V.2.1. Bez namere da se umanji vaznost sprovodjenja ostalih faza, u okviru priloga su prikazani rezultati sprovodjenja sledecih glavnih faza izgradnje baze podataka i programske podrske: 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 ogranicenog prostora knjige, ilustruje samo najbitnije aktivnosti koje treba sprovesti u cilju realizacije jednog transakcionog programa. Detaljno pokrivanje svih elemenata projektovanja i prakticne 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 biti napravljena. Neka od njih se odnose na izostavljeno pravilo poslovanja po kojem se nalozi za otpremu koji imaju makar jednu realizovanu stavku, ili su kompletno realizovani, ne smeju modifikovati niti brisati, ili na pravilo poslovanja po kojem i otpremnica moze imati status realizovane ili nerealizovane, tako da se realizovane otpremnice ne mogu brisati ili modifikovati, vec samo stornirati. P6.1. Analiza i formalno specificiranje korisnickih zahteva studije slucaja Faza snimanja, analize i formalnog specificiranja korisnickih zahteva je detaljnije opisana u tacki 11.3. Na ovom mestu, prezentuju se rezultati sprovodjenja aktivnosti iz ove faze na studiji slucaja "Komercijalna funkcija", uvedenoj putem primera 11.1. Rec je o zadacima koje, u smislu isporuke robe kupcu po poslatoj porudzbenici, moraju da obave referent 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, funkcije PORUDZBINA, NALOG i IZDROB su proglasene elementarnim, sto znaci da se ocekuje da svaka od navedenih funkcija reprezentuje jedan ili vise kompletnih transakcionih programa, zasnovanih na istoj ekranskoj ili stampanoj formi. Cinjenica da je za svaku od ovih funkcija zadat parametar Vreme odgovora = trenutno (u terminologiji proizvoda Designer 2000 Response = Immediate), ukazuje da ce se na osnovu ovih funkcija formirati programi sa ekranskim 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 funkcije. Kao sto je vec naglaseno u tacki 11.3, funkcije (procesi) se, saglasno sprovedenom postupku snimanja korisnickih zahteva, opremaju dodatnim tekstuelnim objasnjenjima i komentarima, koji ce posluziti kao osnov za dalje sprovodjenje ove i narednih faza razvoja programa. Na slikama P6.2 i P6.3 su prikazani tekstuelni opisi funkcija PORUDZBINA i NALOG. Na slici P6.4 je prikazan dijagram toka podataka procesa KOMPOS, a na slikama P6.5 i P6.6 su prikazani dijagrami tokova podataka direktno podredjenih procesa PORNAL i IZDROB, saglasno specifikacijama, datim na slikama 11.2 i 11.3. Dijagrami tokova podataka su oblikovani putem Designer-a 2000. Dijagram na slici P6.4 daje prikaz tokova podataka na visem nivou apstrakcije, u odnosu na dijagrame sa slika P6.5 i P6.6. Saglasno tome, svaki tok podataka na slici P6.4, prikazan isprekidanom linijom *), reprezentuje jedan ili vise tokova podataka sa podredjenih dijagrama i nasledjuje naziv jednog od njih. Tako na primer, tok podataka sa slike P6.4 pod nazivom "Izvestaj o bonitetu,..." *) reprezentuje tokove podataka sa slike P6.5 pod nazivom "Izvestaj o bonitetu" i "Izvestaj o mogucnosti isporuke". 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.

638. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka Slika P6.3. Slika P6.4.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 639. Slika P6.5. Slika P6.6.

640. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka P6.2. Konceptualno projektovanje studije slucaja Postupci konceptualnog projektovanja baze podataka su detaljno razmatrani u tacki 11.4. Na ovom mestu, kao rezultat konceptualnog projektovanja seme baze podataka studije slucaja, na slici P6.7 je prikazan odgovarajuci ER dijagram konacnog resenja, izradjen putem Designer-a 2000. ER dijagram je sacinjen prema specifikaciji, zadatoj putem slika 11.16, 11.33 i 11.34. Slika P6.1. Opsta pravila za tumacenje ovako prikazanog ER dijagrama se mogu pronaci u tacki 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, odnosno 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-

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 641. nog kljuca takvog tipa entiteta uci i sva obelezja primarnog kljuca tipa entiteta na drugoj strani posmatranog tipa poveznika, a simbol " " na tipu poveznika oznacava da se pojave tipa entiteta na strani gde se nalazi simbol " " ne mogu "prevezivati" za druge pojave tipa entiteta na drugoj strani. To znaci da se ne dozvoljava modifikacija kljuca tipa poveznika, odnosno stranog kljuca buduce seme relacije, koja ce od posmatranog tipa entiteta nastati. Na slici P6.8 je prikazan izvod iz specifikacije integriteta domena, sacinjene prema slici 11.14. Polje "Format" odgovara tipu podataka domena Typ(D), a polje "Max Att Length" odgovara maksimalnoj duzini podataka domena Len(D). Panel "Detail", koji ovde nije prikazan, sadrzi pored ostalog i polje za zadavanje predefinisane vrednosti domena Def (D), a panel "Values" omogucava zadavanje dozvoljenih vrednosti, ili intervala dozvoljenih 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 vrednosti obelezja za tip entiteta ZAGLAVLJE NALOGA. Polje "Domain" odgovara specifikaciji domena obelezja A tipa s nazivom N, Dom(N, A), a polje "Opt" (tj. "Optional") specifikaciji nula vrednosti Null(N, A). Predefinisana vrednost Def(N, A) se zadaje u okviru panela "Att Detail", pri cemu u Designer-u 2000 postoji ogranicenje po kojem obelezje, vezano za neki domen, obavezno nasledjuje njegovu predefinisanu vrednost Def(Dom(N, A)), ali je zato ostavljena mogucnost da se obelezje ne poveze ni sa jednim domenom.

642. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka Slika P6.3. Slika P6.4.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 643. Panel "Att Values", ciji je izgled prikazan na slici P6.10, obezbedjuje zadavanje dozvoljenih vrednosti, ili intervala dozvoljenih vrednosti obelezja, cime su samo delimicno pokrivene mogucnosti koje predvidja specifikacija uslova integriteta vrednosti obelezja Con(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 nalog za 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 bilo kom redu, u panelu "Att Values", zadaju i vrednost polja "Value" i polja "High Value", podrazumeva se da je zadat interval dozvoljenih vrednosti, cija je donja granica odredjena vrednoscu polja "Value", a gornja granica vrednoscu polja "High Value". Na nivou svake eksterne seme, u okviru konceptualnog projekta seme baze podataka, predvidjeno je da se za svaki tip T eksterne seme zadaju uloge s obzirom na pravila upotrebe i namenu posmatrane eksterne seme: Role(T ) {r, i, m, d}. Isto tako, zadaje se i skup obelezja tipa, koji se putem programa, napravljenih nad datom eksternom semom, moze modifikovati Mod(T ) Q. Koncept koji obezbedjuje realizaciju slicne logike u okviru 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 se nacini 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 postojecim 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 obelezja tipa entiteta, Update (U ), sa znacenjem da je zadatak funkcije da modifikuje prethodno zadatu vrednost 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 obelezja tipa entiteta, putem posebnih postupaka i

644. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka Other (O), sa znacenjem da funkcija ima, u odnosu na vrednosti posmatranog obelezja tipa entiteta, zadatke koji nisu pokriveni prethodnim ulogama. Skup svih obelezja tipa entiteta, za koji posmatrana funkcija ima naznacenu ulogu Update ili Nullify, treba da odgovara skupu obelezja za modifikaciju Mod(T ). Matrice Funkcije / Tipovi entiteta i Funkcije / Obelezja se projektuju tako da u njima figuriraju sve elementarne funkcije i, najcesce, ovim matricama su jedino one i obuhvacene, mada se uloge tipova entiteta i obelezja mogu zadavati i za ostale (na primer atomarne) funkcije. Na slici P6.11 je prikazana matrica Elementarne funkcije / Tipovi entiteta, za studiju slucaja, saglasno specifikacijama uloga tipova u eksternim semama, sa slika 11.12 i 11.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 Elementarne funkcije / Obelezja, za tipove entiteta KUPAC, SKLADISTE, ROBA, ZALIHA, ZAGLAVLJE NALOGA i STAVKA NALOGA, u cilju ilustracije nacina zadavanja skupova obelezja 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 semi za formiranje naloga zadato Mod(Zaliha) = {RAS}, Mod(Zag_Nal ) = {OSN, STN } i Mod(Stav_Nal ) = {KOL}. Na kraju ovog dela, potrebno je naglasiti da konceptualno projektovanje transakcionog programa, u smislu zahteva koji se postavljaju u okviru tacke 11.5, za formiranje naloga za otpremu nije sprovedeno. Razlog zato je da ni sam Designer 2000, na konceptualnom nivou, ne podrzava tehniku izrade strukturnih dijagrama, ili neku drugu tehniku za formalno iskazivanje procedure, koju transakcioni program treba da sprovede.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 645. Slika P6.6. Slika P6.7. Slika P6.8.

646. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka Slika P6.9. Slika P6.10. Slika P6.11.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 647. P6.3. Implementaciono projektovanje studije slucaja U prvom delu ove tacke prezentuju se rezultati projektovanja implementacione seme baze podataka studije slucaja, a zatim se posvecuje paznja implementacionom projektovanju programa za formiranje naloga za otpremu i implementacionom projektovanju odgovarajuce podseme. Na ovom mestu, potrebno je naglasiti da CASE proizvod Designer 2000 diktira takav redosled koraka, po kojem se prvo mora deklarisati specifikacija programa pa se tek potom oblikuje podsema koja, takodje, pripada specifikaciji programa. P6.3.1. Implementaciono projektovanje seme baze podataka studije slucaja Na slici P6.18 je prikazan dijagram implementacione seme baze podataka studije slucaja, formiran nakon postupka prevodjenja konceptualne seme baze podataka sa slike P6.7, u relacioni model podataka i izvrsene normalizacije. Svaki pravougaonik na dijagramu reprezentuje jednu semu relacije, odnosno buducu tabelu baze podataka, dok linije reprezentuju puteve prostiranja primarnog kljuca, odnosno ogranicenja stranog kljuca. Svaka sema relacije je na dijagramu reprezentovana svojim nazivom, u gornjem delu pravougaonika, skupom obelezja, u sredini pravougaonika, i nazivom ogranicenja primarnog kljuca, u donjem delu pravougaonika. P6.3.1.1. Oblikovanje skupa obelezja i integriteta torke seme relacije studije slucaja Postupak prevodjenja konceptualne seme u relacioni model je sproveden upotrebom alata Database Design Transformer, dok je projektovanje konacne verzije implementacione seme baze podataka obavljeno pomocu alata Design Editor / Server Model. Konacni skup sema relacija implementacione seme, prikazan na slici P6.18, odgovara skupu sema relacija iz primera 12.2. Radi ilustracije razlika izmedju prve verzije implementacione seme, dobijene prevodjenjem ER seme baze podataka, i konacne verzije, u koju su ukljuceni efekti sprovedene 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 kljuca IDS, prenetog u ovu semu relacije iz seme Zag_Nal, po osnovu veze SN_ZG_FK, dok je drugo takodje reprezentovalo obelezje stranog kljuca IDS, ali koje je u ovu semu relacije preneto iz seme Zaliha, po osnovu veze SN_ZL_FK. Preimenovanjem, umesto ova dva obelezja, formirano je jedno obelezje, pod nazivom IDS, saglasno cinjenici da se na stavci naloga za otpremu moze naci samo roba iz onog skladista za koje se kompletan nalog za otpremu formira. U inicijalnoj verziji seme relacije Stav_Otp postojalo je obelezje SO_SN_FK_BRN, koje je reprezentovalo broj naloga za otpremu, kao obelezje stranog kljuca iz seme relacije

648. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka Stav_Nal. Saglasno analizi prezentovanoj u primeru 12.2, ovo obelezje je, u cilju zadovoljenja uslova trece normalne forme, uklonjeno iz seme relacije Stav_Otp. Slika P6.1. Alat Database Design Transformer, za prevodjenje ER seme baze podataka u relacioni model, obezbedjuje i automatizovano prevodjenje specifikacije integriteta tipa u specifikaciju integriteta torke seme relacije. Na slikama P6.19 i P6.20 je prikazan izvod iz specifikacije 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 okviru polja "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 ostavljena mogucnost i da obelezje, ostavljanjem prazne vrednosti polja "Default value", nasledi predefinisanu vrednost domena Def (Dom(N, A)). Dozvoljeno je i da obelezje seme relacije ne bude vezano ni za jedan domen.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 649. Slika P6.2. Slika P6.3.

650. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka Slika P6.4. Slika P6.5. Panel "Allowable Values", ciji je izgled prikazan na slici P6.20, obezbedjuje zadavanje dozvoljenih vrednosti, ili intervala dozvoljenih vrednosti obelezja, cime su, jednim delom, pokrivene mogucnosti koje predvidja specifikacija uslova integriteta vrednosti obelezja Con(N, A).

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 651. Na slici P6.20 je prikazana deklaracija uslova Con(Zag_Nal, STN ) {'D', 'N ' }, koji je formiran preuzimanjem s konceptualnog nivoa deklaracije uslova Con(ZAGLAVLJE NALOGA, STN ) {'D', 'N ' }. Uslov ogranicenja torke se u okviru Designer-a 2000 moze deklarisati i putem koncepta tabelarnog ogranicenja, pod nazivom Check Constraint. Na slikama P6.21 i P6.22 su prikazani paneli za definisanje uslova ogranicenja torke putem ovog koncepta, pri cemu je deklarisan uslov Con(Zaliha, RAS ) = RAS ZAL. Navedeni koncept obezbedjuje mogucnost implementacije ogranicenja torke ili putem SQL klauzule CHECK, ili putem poziva logicke, validacione funkcije, definisane na nivou servera baze podataka. U drugom slucaju, putem koncepta pod nazivom "Table API ", postoji i mogucnost automatizovanog generisanja trigera i procedura baze podataka, koji ce obezbediti poziv navedene logicke funkcije prilikom pokusaja dodavanja novih, ili modifikacije postojecih podataka. Ako i samo ako validaciona funkcija vrati istinitu vrednost (tj. vrednost true), ogranicenje se smatra zadovoljenim. Koncepti Allowable Values i Check Constraint, na taj nacin, obezbedjuju potpunu pokrivenost uslova integriteta vrednosti obelezja Con(N, A), uvedenog u glavi 6. Kada je u pitanju 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 integriteta studije slucaja Kada je rec o implementacionom projektovanju skupa medjurelacionih ogranicenja, alat Database Design Transformer, takodje, obezbedjuje inicijalno formiranje skupa referencijalnih integriteta, saglasno izvrsenom prostiranju primarnih kljuceva. U postupku finalizacije implementacione seme baze podataka, neophodno je izvrsiti eventualno potrebna prilagodjavanja dobijenih referencijalnih integriteta i definisati druga medjurelaciona ogranicenja, kao sto su prosireni referencijalni integriteti, inverzni referencijalni integriteti i slozenija pravila poslovanja. Dok se referencijalni integriteti u Designer-u 2000 mogu deklarisati upotrebom koncepta na nivou tabele, pod nazivom Foreign Keys, svi drugi tipovi medjurelacionih ogranicenja se projektuju pomocu koncepta trigera baze podataka i PL/SQL programa. Referencijalni integriteti se, u najvecem broju slucajeva, mogu implementirati na nivou servera baze podataka deklarativno, a ostali tipovi medjurelacionih ogranicenja se implementiraju iskljucivo upotrebom proceduralnih mehanizama. Detaljnije informacije o mehanizmima i nacinima implementacije ogranicenja baze podataka na serveru baze podataka su sadrzane u glavama 8 i 9, kao i prilogu P5. Paneli za definisanje osnovnih podataka o referencijalnom integritetu Zag_Nal[IDK] Kupac[IDK], putem koncepta Foreign Keys, su prikazani na slikama P6.23, P6.24, P6.25 i P6.26. Referencijalni integritet se definise na nivou referencirajuce tabele, odnosno seme relacije koja se nalazi s leve strane referencijalnog integriteta. Osim naziva (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.

652. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka Slika P6.1. Slika P6.2.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 653. Slika P6.3. Slika P6.4. Na sledecem panelu (slika P6.24) definisu se nizovi obelezja leve i desne strane referencijalnog integriteta. Redosled obelezja u nizu odgovara redosledu vrsta u samom

654. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka panelu, a svaka vrsta sadrzi par obelezja, pri cemu je levo obelezje iz referencirajuce, a desno iz referencirane tabele. Sto se tice vrste referencijalnog integriteta v, Designer 2000, V.2.1 i ORACLE V.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 delete rule", definisanje aktivnosti a, koja se sprovodi pri pokusaju brisanja torke iz referencirane 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 predefinisanu vrednost (a = d). Referencijalni integriteti za cije aktivnosti vazi a = b ili a = c, mogu se implementirati putem deklarativnih mehanizama, dok se u ostalim slucajevima mora pristupiti implementaciji putem proceduralnih mehanizama. Vec pomenuti "Table API " koncept, omogucava automatizovano generisanje trigera i procedura baze podataka, koji ce obezbediti proceduralnu implementaciju referencijalnih integriteta za koje je a = n ili a = d. Na panelu "Cascade Rules", specificira se i to da li je dozvoljena modifikacija vrednosti stranog kljuca. Ako jeste, putem liste izbora "Cascade update rule", specificira se aktivnost koja se sprovodi pri pokusaju modifikacije vrednosti kljuca u referenciranoj relaciji. Moguce aktivnosti su iste kao i za slucaj pokusaja brisanja iz referencirane tabele, pri cemu, ako je modifikacija stranog kljuca zabranjena, podrazumeva se da je aktivnost pri modifikaciji sprecavanje. Na slici P6.26, prikazan je sadrzaj panela "Validation", putem kojeg se zadaje podatak o mestu validacije ogranicenja. Mesto validacije ogranicenja moze biti: "Server", "Klijent", "Server i Klijent" ("Both") i "Nigde" ("None"). Na istom panelu se zadaje i poruka koja se prosledjuje korisniku programa, u slucaju da dodje do narusavanja ogranicenja. Treba naglasiti da se u Designer-u 2000, iako to na slikama ovog priloga nije prikazano, za sva deklarativno zadata ogranicenja, vezana za tabelu, moze zadati i parametar "Defer Status", koji odredjuje trenutak aktiviranja kontrole ogranicenja. Moguce vrednosti ovog parametra su: "Inicijalno odlozeno" ("Initially Deferred"), "Inicijalno trenutno" ("Initially Immediate") i "Trenutno" ("Not Deferred") aktiviranje kontrole ogranicenja. Odlozeno aktiviranje podrazumeva da se kontrola ogranicenja sprovodi na samom kraju transakcije, u postupku njenog potvrdjivanja. Na slici P6.18 su svi referencijalni integriteti studije slucaja reprezentovani graficki, putem linija. Rec je o referencijalnim integritetima koji pripadaju finalnom skupu medjurelacionih ogranicenja I iz primera 12.6. U nastavku su dati opisi znacenja simbola na ovim 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).

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 655. Simbol " " na liniji oznacava da je rec o referencijalnom integritetu sa aktivnoscu pri brisanju 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 odgovarajucim 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 ove linije na dijagramu "podebljane" i oznacene drugom (zelenom) bojom. Pri tome, inverzni referencijalni 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 se referencijalni 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 kontrole ovih referencijalnih integriteta je izabrana vrednost Defer Status = Initially Deferred. P6.3.1.3. Implementaciono projektovanje ostalih medjurelacionih ogranicenja 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] + v [ KOL] ) I, v s 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 se u prilogu P5 i zasnovan je na principima, izlozenim u glavama 8 i 9, te se na ovom mestu tom pitanju ne posvecuje vise prostora. U nastavku teksta, daju se samo napomene koje su bitne sa stanovista primene proizvoda Designer 2000 pri oblikovanju pomenutih ogranicenja. 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 modifikacijom referencijalnog integriteta Stav_Otp[(IDS, BRN, IDR)] Stav_Nal[(IDS, BRN, IDR)] I p, iz primera 12.6, nakon sprovedenog postupka normalizacije, zbog toga sto je iz seme relacije Stav_Otp uklonjeno obelezje BRN (odnosno SO_SN_FK_BRN ). Linija koja reprezentuje navedeni prosireni referencijalni integritet je, takodje, "podebljana" i oznacena drugom (crvenom) bojom. Posto se prosireni referencijalni integritet ne moze realizovati putem deklarativnih mehanizama, tada se za ogranicenje stranog kljuca SO_SN_FK zadaje Validation Level = None, a umesto ogranicenja stranog kljuca, formiraju se PL/SQL procedure i

656. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka trigeri baze podataka za podrsku prosirenog referencijalnog integriteta, onako kako je to opisano u prilogu P5. Pravilo poslovanja (P6.1) na dijagramu sa slike P6.18 nije posebno prikazano. Ono se implementira u drugacijoj formi od one, date putem prikazanog izraza, sto je prikazano u okviru priloga P5. Pri tome, vec pomenuti uslov Con(Zaliha, RAS ) = RAS ZAL predstavlja jednu od posledica pravila poslovanja p. U cilju ilustracije, putem slika P6.27, P6.28 i P6.29, prikazan je postupak implementacionog projektovanja jednog trigera baze podataka, u okviru Designer-a 2000. Rec je o 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 je da je triger PP_Stav_Nal_INS direktno podredjen tabeli Stav_Nal. Na desnoj strani iste slike, prikazano je telo trigera, iskazano putem proceduralnog jezika PL/SQL. Celokupan programski kod trigera reprezentuje objekat, odnosno PL/SQL program, pod nazivom PP_Stav_Nal_INS, koji je definisan u okviru klase Trigger Definitions. Deklarativni deo ovog programa sadrzi definiciju izuzetka, pod nazivom Exc. Izuzetak Exc, zajedno s programskim kodom za njegovu obradu, definisan je u okviru klase Program Data. Slika P6.1.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 657. Slika P6.2. Slika P6.3. Na slici P6.28 je prikazan panel za zadavanje naziva, opisnog polja "svrha" i naziva PL/SQL programa, pridruzenog trigeru.

658. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka Sledeci panel, prikazan na slici P6.29, omogucava definisanje: dogadjaja koji pokrece izvrsenje trigera, trenutka okidanja trigera, kao i to da li je rec o trigeru koji se pokrece 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 modifikacija dovodi do pokretanja trigera. Panel "When" omogucava zadavanje logickog (WHEN) uslova, ukoliko triger treba takav uslov da sadrzi. P6.3.2. Implementaciono projektovanje programa i podseme studije slucaja Ukoliko se upotrebljava CASE proizvod Designer 2000, tada su aktivnosti implementacionog projektovanja programa i podseme medjusobno povezane, jer podsema egzistira iskljucivo u okviru specifikacije programa i svodi se na zadavanje upotreba tabela i upotreba kolona tabela, o cemu je bilo reci u tacki 13.5.7. Zato se ove dve aktivnosti, u nastavku teksta, razmatraju u okviru jedne celine. Inicijalno formiranje specifikacije programa, odnosno modula, prema terminologiji 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 kandidat za modul, tj. specifikaciju programa, pod nazivom NALOG0010. Ovaj kandidat se moze 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 odgovarajucim upotrebama kolona, odnosno vezanim poljima, saglasno sadrzaju matrica Elementarne funkcije / Tipovi entiteta i Elementarne funkcije / Obelezja. Prihvatanjem za dalji rad, kandidat za modul NALOG0010 postaje modul, pod istim nazivom. Nad ovim modulom se nadalje sprovode aktivnosti implementacionog projektovanja programa. Izmedju ostalih, 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.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 659. Slika P6.1. Na slici P6.30 je prikazan definicioni dijagram strukture programskog modula NALOG0010, koji odslikava i strukturu podseme modula. Unutar pravougaonika koji reprezentuje 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 naloga za otpremu robe. Fizicko pozicioniranje komponenata modula na dijagramu odredjuje da ce se blok podataka za zaglavlje naloga, na ekranskoj formi, fizicki naci iznad bloka podataka sa stavkama naloga. U okviru prve komponente modula, nalazi se bazna upotreba tabele Zag_Nal i upotrebe tabela za dve liste izbora vrednosti Kupac i Skladiste s odgovarajucim upotrebama kolona, odnosno vezanim poljima. Spajanje podataka iz ovih tabela ce biti izvrseno prema referencijalnim integritetima, reprezentovanim putem ogranicenja implementacione seme baze podataka ZG_KP_FK i ZG_SK_FK. Tako na primer, spajanje torki iz tabela Zag_Nal i Kupac se obavlja zbog potrebe prikaza vrednosti obelezja NAK i ADR u zaglavlju naloga i u listi za izbor zeljene vrednosti obelezja IDK, kao i za validaciju direktno unete vrednosti obelezja IDK, pri unosu ili modifikaciji naloga za otpremu.

660. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka U okviru druge komponente modula, nalazi se bazna upotreba tabele Stav_Nal i upotrebe tabela za listu izbora vrednosti Zaliha i Roba. Predvidjeno je da se, prilikom pozicioniranja kursora na ekransko polje koje odgovara obelezju IDR, moze pozvati lista izbora, koja ce dati prikaz vrednosti obelezja IDR, NAR, JM i RAS, za svu, ili izabranu robu na 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. Spajanje zaglavlja i stavki naloga se vrsi prema referencijalnom integritetu SN_ZG_FK, dok se spajanje stavke naloga sa zalihama obavlja prema referencijalnom integritetu SN_ZL_FK, a zalihe s robom prema referencijalnom integritetu ZL_RO_FK. Specifikacijom se, takodje, predvidja da se za svaku listu izbora vrednosti koristi posebna ekranska forma, sto znaci da je za svaku listu izbora trebalo napraviti i poseban ekranski modul. U gornjem desnom delu dijagrama sa slike P6.30 je vidljivo da je modul NALOG0010 pozivajuci modul za tri druga modula: NALOG0010_L1, NALOG0010_L2 i NALOG0010_L3. Prvi od ova tri modula sluzi za prikaz liste izbora saglasno upotrebama tabela Zaliha i Roba. Drugi sluzi za prikaz liste izbora saglasno upotrebi tabele Kupac, a treci 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 projektovanje modula. Zbog izrazito velikog broja takvih parametara, na ovom mestu, ilustruje se uloga samo nekih od njih. Na slici P6.31 je prikazan panel "Operations", koji omogucava da se na nivou komponente modula zadaju osnovne operacije koje se nad baznom tabelom te komponente modula mogu sprovesti. Ostali paneli komponente modula, uglavnom, omogucavaju definisanje detalja nacina prikaza buduceg bloka podataka na formi. Kada je u pitanju komponenta 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, za svaku upotrebu tabele, prebacivanjem iz levog (Available Columns) u desni prozor (Selected Items), biraju obelezja seme relacije koja ulaze u sastav seme relacije podseme, odnosno biraju 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 se redosled prikaza polja na formi. Na slici P6.33 je prikazan panel "Operations", putem kojeg se zadaju osnovne operacije, koje korisnik sme da sprovede nad poljima forme. Tako, na primer, vidljivo je da korisnik 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 svi parametri vizuelnog prikaza polja na formi. Pored odredjivanja naslova, nacina prikaza i dimenzija polja na formi, projektant je u mogucnosti da definise i format-masku za prikaz numerickih ili datumskih vrednosti, zada predefinisanu vrednost, te da li je polje obavezno za 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, da odredi koja polja ce biti vidljiva u listi izbora. Moguce je zadati i dodatni kriterijum selekcije podataka kako za baznu, tako i za upotrebu tabele za listu vrednosti, cime se krajnji korisnik pri selektovanju podataka ogranicava samo na podskup skupa torki tabele.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 661. Slika P6.2. Slika P6.3.

662. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka Slika P6.4. Slika P6.5. Na slici P6.35 je prikazan vizuelni dijagram modula NALOG0010. U okviru pravougaonika koji reprezentuje sam modul, nalazi se pravougaonik koji reprezentuje prozor s

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 663. naslovom "Nalog za otpremu" i obuhvata obe komponente modula. To znaci da ce celokupan sadrzaj ekranske forme biti rasporedjen na tacno jednom prozoru. U okviru komponenata 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 svojih naslova, koji se pojavljuju i na ekranskoj formi. Pravougaonici s naslovima Nalog i Za kupca, u okviru prve komponente modula, predstavljaju grupe polja, koje se zajedno prikazuju. Slika P6.6. Simbol " ", koji se na slici P6.30 ili slici P6.35 moze primetiti na nivou polja IDR, komponenti modula, kao i samog modula, oznacava da je na datom nivou definisan klijentski program, ili klijentski dogadjaj, namenjen za izvrsavanje u okviru modula. U okviru implementacione specifikacije programskog modula postoji mogucnost definisanja dogadjaja na klijentu i klijentskih programa, putem kojih se mogu specificirati nestandardni postupci obrade podataka, ili manipulacije podacima. Iako proces izrade klijentskih prog-

664. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka rama i definisanja klijentskih dogadjaja spada u aktivnost programiranja, a sam programski kod se oblikuje putem proceduralno orijentisanog jezika PL/SQL, rezultat ovog procesa pripada implementacionoj specifikaciji programskog modula. Zbog toga se rezultati postupka izrade klijentskih dogadjaja i programa u okviru ove studije slucaja prezentuju u okviru 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 pozivom udaljene procedure, pod nazivom Upis_Zag_Stav_Nal, prezentovane u okviru priloga P5. Do ovog opredeljenja se doslo s ciljem lakse realizacije programskog modula NALOG0010 putem Designer-a 2000. Da bi se navedeni zahtev ispunio, definisani su sledeci 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 (videti navigator objekata na levoj strani slike P6.36), pokrece se neposredno pre svakog pokusaja upisa nove torke u relaciju r(zag_nal ) i obezbedjuje aktiviranje mogucnosti direktnog izvrsenja SQL INSERT naredbe, time sto se blokira aktivnost trigera baze podataka Upis_IRI_Zag_Nal, prezentovanog u prilogu P5. Radi podsecanja, navodi se da triger baze podataka Upis_IRI_Zag_Nal ima zadatak da onemoguci direktan upis novih torki u relaciju r(zag_nal ). "POST-FORMS-COMMIT " klijentski triger, na nivou modula NALOG0010, pokrece se na samom kraju transakcije, ciji je zadatak upis novog naloga za otpremu u bazu podataka, odnosno jedne nove torke u relaciju r(zag_nal ) i svih povezanih torki u relaciju r(stav_nal ). Na levoj strani slike P6.36 je prikazan izvod iz hijerarhije objekata modula NALOG0010, 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. Zadatak ovog klijentskog trigera je da deaktivira mogucnost direktnog izvrsenja SQL INSERT naredbe, time sto se deblokira aktivnost trigera baze podataka Upis_IRI_Zag_Nal, pozivom serverske procedure Izvrsenje_okidaca, opisane u glavi 9. Pored toga, ovaj triger sadrzi i poziv serverske funkcije Sadrzi_IRI_Zag_Nal, koja za zadatu torku v, odnosno zaglavlje naloga za otpremu, proverava da li u relaciji r(stav_nal ) postoji najmanje jedna odgovarajuca 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 robe obezbedi selektovanje samo zaliha robe iz skladista s vrednoscu sifre IDS, koja je specificirana u zaglavlju naloga, realizuje se programski zbog odluke da se lista izbora prikazuje putem 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

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 665. prezentovani, s tim sto je potrebno napomenuti da je sam programski kod formiran kombinovanjem drugih segmenata programa, koje je Designer 2000 u stanju da izgenerise i da je smesten u okviru recnika podataka, tj. pripada specifikaciji modula. Slika P6.7. P6.4. Opis seme baze podataka putem jezika podataka i mehanizama SUBP za studiju slucaja U okviru ove tacke priloga, prezentuje se deo opisa seme baze podataka, prikazanog putem jezika SQL. Rec je o automatski generisanom kodu, produkovanom pomocu generatora SQL koda Designer-a 2000 i prilagodjenom za SUBP ORACLE V.8.*. SQL opis seme baze podataka je dobijen na osnovu specifikacije implementacionog projekta seme 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 kreiranje odgovarajucih tabela. Na slikama P6.38, P6.39 i P6.40 su prikazani izvodi iz datoteke koja sadrzi SQL naredbe za kreiranje ogranicenja seme baze podataka putem deklarativnih mehanizama. Slika P6.2 daje prikaz naredbi za kreiranje ogranicenja primarnog kljuca, slika

666. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka P6.39 daje prikaz naredbi za kreiranje ogranicenja torki, a slika P6.40 daje prikaz naredbi za kreiranje ogranicenja stranog kljuca. Na slici P6.41 je prikazan tekst trigera PP_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.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 667. ALTER TABLE KUPAC ADD 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 KUPAC ADD 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_000 CHECK (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.

668. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka ALTER TABLE ZALIHA ADD 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_INS BEFORE INSERT ON STAV_NAL FOR EACH ROW DECLARE EXC EXCEPTION; BEGIN IF :NEW.STA!= 'R' THEN RAISE exc; END IF; UPDATE Zaliha SET RAS = RAS - :NEW.KOL WHERE IDS = :NEW.IDS AND IDR = :NEW.IDR; EXCEPTION WHEN EXC THEN RAISE_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.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 669. P6.5. Generisanje i programiranje Generisanje programa za formiranje naloga za otpremu NALOG0010 je sprovedeno upotrebom generatora Forms modula, za okruzenje Developer 2000 V.2.1. U postupku generisanja, koji je obicno iterativne prirode, vrse se dodatne modifikacije implementacione specifikacije modula, da bi se otklonili eventualno uoceni nedostaci, ili da bi se izvrsila poboljsanja izgleda dobijene ekranske forme. Izmedju ostalog, tokom generisanja se pojavljuje i potreba izmene predefinisanih vrednosti generatorskih preferenci. Preference su parametri generatora modula, cije vrednosti dodatno uticu na izgled, nacin generisanja i nacin funkcionisanja izgenerisanog programa. Vrednosti generatorskih preferenci se mogu zadati na nivou aplikacionog sistema, domena, tabele, kolone tabele, modula, komponente modula, vezanog polja, itd, cime se definise i "opseg delovanja" vrednosti preference. Na slici P6.42 je prikazan izgled ekranske forme za formiranje naloga za otpremu, izgenerisanog modula NALOG0010. Slika P6.1.

670. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka Slika P6.2. Na slici P6.43 je prikazan izgled iste ekranske forme, u trenutku kada se kursor nalazio na polju za unos identifikacionog broja kupca (IDK ) i kada je pozvana lista izbora vrednosti identifikacionog broja kupca. U okviru ove, kao i svih drugih lista izbora u ovom modulu, korisnik ima mogucnost da zada dodatne kriterijume za prikaz izvoda iz celokupne evidencije. Slika P6.3 daje prikaz ekranske forme za formiranje naloga za otpremu, u trenutku kada se kursor nalazio na polju za unos identifikacionog broja robe (IDR) i kada je pozvana lista izbora vrednosti identifikacionog broja robe. U ovoj listi vrednosti, mogu se naci samo podaci o robi koja je evidentirana na zalihama onog skladista, ciji je identifikacioni broj naveden u zaglavlju naloga. U ovom primeru, rec je o skladistu s identifikacionim brojem 10.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 671. 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 izvrseno azuriranje podataka u radnoj zoni programa, korisnik je u obavezi da pokrene postupak azuriranja podataka u bazi, izborom funkcije "Sacuvaj" ("Save", na primer pokretanjem opcije menija Action/Save, ili aktiviranjem odgovarajuce ikone), ili da odustane od izmena. Sam postupak azuriranja se sprovodi automatski, putem jedne transakcije, a korisnik ce, na kraju izvodjenja transakcije, biti obavesten o efektima njenog sprovodjenja. Za svaku novododatu torku u radnoj zoni programa, u okviru transakcije ce automatski biti formirana jedna SQL INSERT naredba. Isto tako, za svaku modifikovanu torku u radnoj zoni programa, transakcija ce sadrzati jednu UPDATE naredbu, dok ce za svaku torku u radnoj zoni programa, koja je oznacena kao izbrisana, transakcija sadrzati jednu DELETE naredbu.

672. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka Da bi se dobio prikazani interaktivni program, izvrsena su prilagodjenja vrednosti pojedinih generatorskih preferenci, kao i neznatna prilagodjenja sablonske forme i biblioteke 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, potrebno 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 provere vazenja ogranicenja primarnog kljuca putem klijentskog programa. Za ogranicenje primarnog kljuca se, generalno, u okviru specifikacije implementacione seme baze podataka, navodi mesto validacije (provere vazenja) ogranicenja, koje, kao sto je vec napomenuto, moze imati vrednost: "Server", "Klijent", "Server i Klijent", ili "Nigde". Ukoliko je za mesto provere vazenja ogranicenja izabrana vrednost "Klijent", ili "Server i Klijent", tada ce generator Forms modula obezbediti generisanje klijentskog programa koji ce proveriti vazenje ogranicenja primarnog kljuca. Inicijalna vrednost preference VLDTPK = B znaci da ce poziv 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 ogranicenje primarnog kljuca, putem deklarativnih mehanizama, implementirano na serveru baze podataka. Validacija na nivou transakcije je u ovom slucaju, medjutim, potpuno nepotrebna, jer se sprovodi, sa stanovista krajnjeg korisnika, u isto vreme kao i validacija ogranicenja na nivou servera baze podataka. Zbog toga je promenjena vrednost posmatrane preference, tako da vazi VLDTPK = F. To znaci da ce putem klijentskog programa biti obezbedjena samo validacija na nivou polja, kako bi korisnik bio, u slucaju narusavanja ogranicenja primarnog kljuca, upozoren da je doslo do greske vec pri pokusaju napustanja poslednjeg polja koje odgovara obelezju primarnog kljuca, a ne tek u momentu kada pokrene transakciju azuriranja podataka u bazi. U okviru ovog teksta, bice ilustrovana i motivacija za izmenu vrednosti generatorske preference LOVVAL. Naime, u okviru implementacionog projekta seme baze podataka, predvidjeno je da se za mesto validacije ogranicenja stranog kljuca ZG_KP_FK izabere vrednost "Server i Klijent", sto znaci da je referencijalni integritet Zag_Nal[IDK ] Kupac[IDK ] potrebno kontrolisati i putem klijentskog programa, nakon pokusaja zadavanja ili promene vrednosti polja IDK. Ukoliko se projektant opredeli za prikaz liste izbora vrednosti putem predefinisanog objekta, pod nazivom Forms LOV objekat, a ne putem posebne ekranske forme, tada inicijalna vrednost preference LOVVAL = Y obezbedjuje da se *) Na engleskom: reusable module components.

Prilog P6. Projektovanje i realizacija studije slucaja putem CASE alata 673. kontrola navedenog referencijalnog integriteta izvrsi automatski, bez dodatnog pisanja klijentskog programa za tu svrhu. Posto je u ovoj studiji slucaja opredeljenje da se sve liste izbora vrednosti prikazu putem posebnih ekranskih formi, tada se ne moze obezbediti automatska kontrola validnosti referencijalnog integriteta na klijentu, vec se u te svrhe mora izgenerisati 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 ce automatski formirati klijentski triger (dogadjaj) pod nazivom "When-Validate-Item", na nivou polja IDK, u okviru zaglavlja naloga. Na levoj strani slike P6.45 je prikazano mesto u hijerarhiji 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 programski kod, pridruzen ovom trigeru. Triger ce se pokrenuti neposredno nakon pokusaja korisnika da zada, ili modifikuje vrednost polja IDK, bilo pri napustanju polja, bilo pri zahtevu korisnika da se pokrene transakcija za azuriranje podataka u bazi. Namena trigera je da spreci takvo zadavanje ili modifikovanje vrednosti polja IDK, koje bi narusilo referencijalni integritet Zag_Nal[IDK ] Kupac[IDK ]. Slika P6.4. Centralno mesto u programskom kodu posmatranog trigera, koji se izvrsava na klijentu, zauzima poziv procedure pod nazivom CGFK$CHK_ZAG_NAL_ZG_KP_FK. Ona je, takodje, u potpunosti formirana od strane generatora Forms modula. Sam programski

674. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka kod ove klijentske procedure je prikazan na slici P6.46. Njena namena je da se, za zadatu vrednost polja IDK, odnosno parametra P_IDK, proveri da li u bazi podataka, odnosno relaciji r(kupac), postoji torka sa zadatom vrednoscu identifikacionog broja kupca. Ukoliko taj 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, a kursor ostavlja na poziciji polja IDK. Slika P6.5. Treba napomenuti i to da se procedura CGFK$CHK_ZAG_NAL_ZG_KP_FK izvrsava 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 logicke promenljive C%NOTFOUND, koja vraca vrednost true, ako i samo ako je kursorsko podrucje prazno, predstavljaju zahteve koji se prosledjuju serveru baze podataka, kako bi ih on realizovao 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-