Projektovanje IS. Fizičko modelovanje Aplikativno modelovanje Softver

Transcription

1 Projektovanje IS Fizičko modelovanje Aplikativno modelovanje Softver Referencijalni integritet Referencijalni integritet obezbjeđuje korektno povezivanje objekata jer objekat koji nije predstavljen u odgovarajućem skupu objekata ne može da učestvuje u nekoj od veza predstavljenih u modelu podataka. Referencijalni integritet je vezan za postojanje prenesenog ključa za neki entitet (npr. "Šifra odjeljenja" u entitetu ). Primarni ključ se može prenijeti i postati preneseni ključ u okviru identifikujuće (kao dio primarnog ključa djeteta čime mu čini sastavni dio integriteta) ili neidentifikujuće veze (kao atribut čime nije dio integriteta). Integritetom entiteta se onemogućuje pojava da unesena vrijednost atributa odgovara vrijednosti atributa koji je primarni ključ drugog entiteta. Referencijalni integritet opisuje ponašanje modela kada usljed operacije održavanja, dolazi do narušavanja kardinalnosti veza. To ponašanje modela ili strukturna pravila integriteta definišu se kao strukturna ograničenja. Referencijalni integritet se definiše za svaku vezu, posebno za 'roditelja' a posebno za 'dijete' i to za operacije: insert (ubacivanje), delete (brisanje) i update (ažuriranje). Sada ćemo opisati referencijalni integritet za sve važne veze u sistemu. 1

2 Referencijalni integritet za veze DIJETE (CHILD) Dijete ključ Roditelj ključ (FK) RODITELJ (PARENT) sadrži/ Roditelj ključ je sadržano Identifikujuća veza. Postoje dva pravila za brisanje CASCADE (može se izbrisati dijete čiji je roditelj izbrisan) i RESTRICT (može se zabraniti brisanje roditelja dok postoji neko dijete koje bi ostalo neidentifikovano). U Erwinu podrazumijevano je dozvoljeno brisanje djeteta (NONE) a brisanje roditelja je RESTRICT. CASCADE briše svu djecu zajedno sa roditeljem (). Za operacije ubacivanja (INSERT) i izmjena (UPDATE) red može biti dodat ili izmjenjen samo ako svi referencirani preneseni ključevi odgovaraju postojećim redovima u referenciranim tabelama. Postoje dvije mogućnosti koje ograničavaju ove operacije: ne može se ažurirati dijete bez korišćenja instance roditelj (RESTRICT) ili za ubačeno/ažuriranog roditelja ubaciti/ažurirati i bilo koje 'dijete' čiiji bi dio primarnog ključa bio ključ 'roditelj' (akcija CASCADE). U Erwin-u podrazumijevano je za ubacivanje/ažuriranje djeteta RESTRICT dok je za ubacivanje roditelj NONE a za ažuriranje RESTRICT. Referencijalni integritet za veze TELEFON Broj telefona Status p I:C Šifra osobe Šifra odjeljenja (FK) Prezime Ime JMBG Plata Stimulacija Datum zaposlenja Primjer označavanja referencijalnog integriteta. P I:C Identifikujuća veza One-to-Zero-One-or-More Ograničenja: Osoba (dijete) Insert - Restrict, Update - Restrict. Odjeljenje (roditelj) Delete - Cascade, Update - Cascade. Identifikujuća veza One-to-One-or-More Ograničenja: Osoba (dijete) Insert - Restrict, Update - Restrict. Odjeljenje (roditelj) Delete - Cascade, Update - Cascade, Insert - Cascade. 2

3 Referencijalni integritet za veze Z Identifikujuća veza One-to-Zero-or-One Ograničenja: Osoba (dijete) Insert - Restrict, Update - Restrict. Odjeljenje (roditelj) Delete - Cascade, Update - Cascade. 4 I:SN Identifikujuća veza One-to-Exactly Ograničenja: Osoba (dijete) Insert - Restrict, Update - Restrict. Odjeljenje (roditelj) Delete - Restrict, Update - Restrict. Neidentifikujuća veza Zero (Nulls Allowed)-or-One-to- Zero-One-or-More Ograničenja: Osoba (dijete) Insert - Set Null. Odjeljenje (roditelj) Delete - Set Null, Update - Cascade. Referencijalni integritet za veze P P One (No Nulls)-to-Zero-One-or-More Ograničenja: Osoba (dijete) Insert - Restrict, Update - Restrict. Odjeljenje (roditelj) Delete - Restrict, Update - Cascade. Neidentifikujuća veza Zero (Nulls Allowed)-or-One -to- One-or-More Ograničenja: Osoba (dijete) Insert - Restrict, Update - Restrict. Odjeljenje (roditelj) Delete - Set Null, Update - Restrict. One-(No Nulls)-to- One-or-More Ograničenja: Osoba (dijete) Insert - Restrict, Update - Restrict. Odjeljenje (roditelj) Delete -Restrict, Update - Restrict. 3

4 Referencijalni integritet za veze I:SN Z Z N N Zero-or-One-(Nulls Allowed)-to- Zero-or-One (Z) Ograničenja: Osoba (dijete) Insert - Set Null. Odjeljenje (roditelj) Delete -Restrict, Update - Restrict. One-(No Nulls)-to- Zero-or-One (Z) Ograničenja: Osoba (dijete) Insert -Restrict, Update - Restrict. Odjeljenje (roditelj) Delete -Restrict, Update - Restrict. Zero (Nulls Allowed)-or-One-to- Exactly N Ograničenja: Osoba (dijete) Insert -Restrict, Update - Set Nulls. Odjeljenje (roditelj) Delete -Set Nulls, Update - Set Nulls. One (No Nulls)-to- Exactly N Ograničenja: Osoba (dijete) Insert - Restrict, Update - Restrict. Odjeljenje (roditelj) Delete -Restrict, Update - Restrict. Referencijalni integritet za veze Šifra osobe Šifra odjeljenja (FK) Prezime Ime JMBG Plata Stimulacija Datum zaposlenja je rukovodilac/ je rukovođen I:SN Referencijalni integritet rekurzije hijerarhijskog tipa je veza entiteta nad samim sobom i definiše se kao neidentifikujuća veza. Referencijalni integritet rekurzivne veze mrežnog tipa je specijalni slučaj 'Many-to-Many' veze nad samim sobom i treba je razbiti na dvije veze 1:M. PROIZVOD Ident broj STRUKTURA Komponenta br. Ident broj (FK) Sastav br. Ident broj (FK) MUŠKARAC Pol ŽENA Referencijalni integritet hijerarhijske veze koja je potpuna. 4

5 Referencijalni integriteti za veze KONSULTANT Vrsta REDOVNI Referencijalni integritet hijerarhijske veze koja nije potpuna. Kod Many-to-Many veze uvodi se obično jedan dodatni asocijativni entitet i dvije 'One-to-Many' veze. zna JEZIK Sifra osobe Sifra Odjeljenja (FK) Prezime Ime JMBG Plata Stimulacija Datum zaposlenja je dat/ posjeduje CERTIFIKAT Šifra jezika (FK) Stepen znanja važi/ odnosi se JEZIK Šifra jezika Naziv jezika Referencijalni integritet za veze CERTIFIKAT Šifra jezika (FK) Stepen znanja CERTIFIKAT Šifra jezika (FK) Stepen znanja CERTIFIKAT Šifra jezika (FK) Stepen znanja Primjer sa ostalim integritetima iz knjige A. Veljović JEZIK Šifra jezika Naziv jezika JEZIK Šifra jezika Naziv jezika JEZIK Šifra jezika Naziv jezika Sifra osobe Sifra Odjeljenja (FK) Prezime Ime JMBG Plata Stimulacija Datum zaposlenja Cascade prilikom brisanja znači brisanjem JEZIK-a brišu se i svi CERTIFIKATI za taj JEZIK, Restrict znači ne može se izbrisati JEZIK dok se ne izbrišu CERTIFIKAT-i. Posljednja varijanta se koristi kada se želi naglasiti da CERTIFIKAT možda može da nastavi život u memoriji i nakon brisanja osnovnog entiteta. Ovdje prilikom brisanja JEZIK-a CERTIFIKAT nastavlja da živi u memoriji ali se ključ JEZIK-a postavlja na NULL. CERTIFIKAT Šifra jezika (FK) je dat/ posjeduje Stepen znanja JEZIK Šifra jezika važi/ odnosi se Naziv jezika 5

6 Referencijalni integritet za veze JEZIK Šifra jezika Naziv jezika CERTIFIKAT Šifra jezika (FK) Stepen znanja MUŠKARAC Služio vojsku RADNO MJESTO Šifrarm Nazivrm P ŽENA Prezime djevojačko Pol Šifra osobe Prezime (IE1) Ime (IE1) Šifrarm (FK) JMBG (AK2) rukov (FK) Datum zaposljenja Plata Stimulacija Šifra odjeljenja (FK) Pol Vrsta KONSULTANT I:SN I:SN Vrsta Šifra odjeljenja Naziv odjeljenja Mjesto ISPLATA rbr Datum isplate Iznos REDOVNI Broj sati Vrsta posla Primjer sistema sa vezama između pojedinih klasa i referencijalnim integritetima. Primjer preuzet iz A. Veljović. Tabelaran prikaz klasa, veza i integriteta - Primjer Entitet 'roditelj' Entitet 'Dijete' ime veze U UPDATE I INSERT D -DELETE ISPLATA Prima U Cascade I Restrict D - Cascade Rukovodi U Set Null I Set Null D Set Null MUŠKARAC is a U Cascade I Restrict D Cascade ŽENA is a U Cascade I Restrict D Cascade REDOVNI is a U Cascade I Restrict D Cascade KONSULTANT is a U Cascade I Restrict D Cascade CERTIFAKAT Zna U Restrict I Restrict D Restrict Zapošljava U Set Null I Set Null D Set Null RADNO MJESTO Pripada U Restrict I Restrict D Restrict JEZIK CERTIFIKAT govori U Restrict I Restrict D Restrict Nakon ovoga potrebno je svakom atributu dodijeliti tip podatka kao i eventualna ograničenja po tipu. Tip može da bude standardni koji je vezan za implementacioni jezik ili platformu a može biti podložan ograničenjima. Prilikom definisanja ograničenja koriste se operatori >, <, >= itd, lista dozvoljenih vrijednosti (IN liste), dozvoljene granice BETWEEN, NULL, NOT NULL, kao i logičke operacije (AND, OR, NOT) itd. Ovo se obično naziva poslovnim domenom. 6

7 Poslovni domen - Primjer Naziv domena Opis domena Tip podataka (Domen) Null Opcija Default naziv Validaciono pravilo (Ograničenje) Validacioni naziv default Text (18) <>IsNull() Obavezan unos Broj Datum Naziv Oznaka Primanja Stimulacija Stepen Domen definiše sve brojeve Opšti datum kome je vrijednost sistemski datum Ovaj domen je definisan za sve atribute koji opisuju nazive Ovaj domen definiše identifikacione oznaka Domen opisuje plate i honorare Domen za definisanje intervala i tipa stimulacije Stepen znanja P piše; G-govori; C čita Integer Date/Time Text(30) Text(6) Currency NOT NULL NOT NULL NOT NULL NOT NULL Današnji datum <=Date() <>IsNull() <>IsNull() Currency BETWEEN 500 AND 1000 Text(3) NOT NULL Obavezan unos Obavezan unos Obavezan unos Obavezan unos Interval stimulacije Stepen IN {'P, G, C'} Stepen Aplikativno modelovanje Ključni elemenat aplikativnog modelianja je kreiranje dizajna za izabrani sistem za upravljanje bazom podataka SUBP (Data Base Management System DBMS). SUBP je skup programa čija je namjena da na zahtjev aplikativnih programa vrši manipulaciju podacima. To je jedan od načina da se korisnicima omogući direktan pristup podacima pohranjenim u Bazi podataka. Baza podataka je po pravilu odvojena od programa koji je koriste. Da bi se podaci mijenjali ili dodavali u bazu moraju se koristiti zajednički i kontrolisani pristupi (tzv. sesije). Podaci u bazi mogu biti redundantni ali redudancija mora biti takva da je relativno mala i strogo nadgledana da se ne bi dogodio problem usklađenosti podataka. Aplikativno modeliranje treba da omogući projektantu kreiranje efekasne aplikacije i odabir načina pristupa podacima. Aplikativno modeliranje ima tri faze: Definisanje fizičkog dizajna (odabir SUBP, definisanje tabela i kolona, indeksa i načina upravljanja podacima); Generisanje šeme baze podataka (kreiranje tabela, kreiranje indeksa, kreiranje poslovnih ograničenja, verifikacija dizajna šeme); Izrada aplikacije (definisanje menija, definisanje izgleda forme, definisanje upita, definisanje izvještaja). 7

8 Fizički dizajn Nakon logičkog dizajna slijedi fizički. ErWin raspolaže sa prilično velikim brojem veza sa poznatim SUBP-ovima koje treba koristiti. Prilikom te transfomacije treba voditi računa o činjenici da svaki SUBP ima svoje tipove podataka odnosno da se pojedini tipovi razlikuju od SUBP-a do SUBP-a. Suštinski ERwin i svi alati za modelovanje su semantički bogatiji od svih SUBP-ova pa postoji uvijek mogućnost da se jedan dio semantike (smisla) modela izgubi prilikom ove transformacije (model SUBP). Osnovna pravila za transformaciju logički u fizički model: entiteti postaju tabele, atributi su kolone (definisane nazivom u jednoj koloni jedna vrsta podataka), instance ili primjerci postaju redovi (redovi se moraju međusobno razlikovati), u presjeku reda i kolone su polja. Tabela se sastoji od kolona i redova koji se mogu sagledati u bilo kom redosljedju bez uticaja na sadržaj tabele. Tabele moraju biti tako sastavljene da se nijedna veza ne gubi. Dužina kolona se određuje automatski na osnovu atributa (u ERwinu) ili je korisnik sam podešava. Više međusobno povezanih tabela čini relacionu bazu podataka. Relaciona baza Codd-ova pravila 1. Struktura SUBP se predstavlja samo tabela. 2. Svaki podatak u bazi podataka dostupan je preko kombinacije imena tabele, vrijednosti primarnog ključa i imena kolone, bez unaprijed zadatih pristupnih puteva i bez rekurzija i iteracija. 3. Specifični indikator različit od "blanka" ("praznog") niza karaktera, nule ili bilo kod broja, koristi se za predstavljanje nula vrijednosti bez obzira na tip podataka. 4. SUBP treba da posjeduje katalog (rječnik) podataka koji se logički predstavlja na isti način kao i sama baza podataka. 5. SUBP mora posjedovati bar jedan jezik čije se naredbe mogu izraziti kao niz karaktera sa dobro definisanom sintaksom i koji podržava: 1. definiciju podataka, 2. definiciju pogleda, 3. manipulaciju podataka, interaktivno i kroz programe, 4. definiciju pravila integriteta, 5. autorizaciju (sigurnost), 6. granice transakcija (BEGIN, COMMIT, ROLLBACK). 6. SUBP treba da posjeduje efikasan algoritam pomoću koga može da odrediti za svaki definisani pogled. U trenutku njegovog definisanja da li se i koje operacije održavanja mogu da primjene na taj pogled. Rezultat takvog algoritma se smješta u katalog baze podataka. 7. I nad tabelama i nad pogledima se mogu izvršavati ne samo operacije pretraživanja već i operacije održavanja baze podataka. 8

9 Relaciona baza Codd-ova pravila 8. Aplikacioni program i interaktivna komunikacija treba da ostanu neizmjenjeni kada se primjeni fizička organizacija baze podataka. 9. Aplikacioni program i interaktivna komunikacija ostaju nepromijenjeni kada se bilo koje promjene koje ne mijenjaju odgovarajući sadržaj tabele unesu u baznu tabelu. 10. Pravila integriteta treba da se definišu u okviru definicije baze podataka i čuvaju se u rječniku podataka (ne implementiraju se kroz aplikacione programe). 11. Sve navedene karakteristike treba da budu nezavisne od distribucije baze podataka. 12. Ako SUBP može da radi sa nekim jezikom treće generacije u kome se obrađuje jedan red tabele u jednom trenutku vremena kroz taj jezik se ne mogu zaobići pravila integriteta zadana preko samog relacionog SUBP. Dvije osnovne funkcije baze podataka su memorisanje/održavanje podataka i manipulacija podacima. SUBP mora da bude u stanju da sinhronizuje simultane zahtjeve više korisnika koji traže ili pristupaju istim podacima. U daljem tekstu nam nije namjera da detaljišemo priču o bazama podataka koja je bila obrađivana u posebnom kursu niti o SUBP-u kojem je ponovo posvećen posebni kurs. O tome u daljem tekstu samo koliko je neophodno za naš kurs. Vrijedi napomenuti da danas procentualno sve više i više obrada se obavlja nad nestrukturiranim podacima kao što su Internet, itd a te operacije su vezane za pojmove knowledge discovery i data mining. Relaciona baza sa SUBP SUBP sa relacionom bazom čini cjelovito softversko rješenje bez namjere da se pravi sistem koji se sastoji od "zakrpica" i pojedinačnih fajlova-datoteka-izvještaja. Samo cjelovito rješenje omogućava pretraživanje, kontrolisanje i generisanje informacija iz podataka, tabela, fajlova, datoteka i izvještaja. Osnovni alat u radu sa bazom je SQL (standardni upitni jezik). To je neproceduralni jezik (za razliku od ostalih koje smo učili) gdje kažemo što treba uraditi a ne i kako. Najvažnije naredbe u radu sa tabelom su CREATE TABLE (kreiranje tabele), CREATE VIEW (kreiranje pogleda), CREATE SYNONIM (kreiranje sinonima), CREATE INDEX (kreiranje indeksa), ALTER TABLE (dodavanje kolona ili redefinisanje tabele), DROP TABLE (brisanje tabele), DROP VIEW (brisanje pogleda), DROP SYNONIM (brisanje sinonima), DROP INDEX (brisanje indeksa). Komande za dodavanje, ažuriranje i brisanje podataka su redom INSERT, UPDATE i DELETE. Veoma važna potreba rada sa bazom podataka/subp-om je podešavanje privilegija i prava pristupa. Neke od naredbi za ove potrebe u Oracle SUBP-ovima su: GRANT CONNECT (dodjeljivanje privilegije), REVOKE (opoziv privilegije), COMMIT (prenos transakcija iz bafera u tabelu), ROLLBACK (poništavanje izmjene u tabelama prije commita), LOCK TABLE (zaključavanje tabele, AUDIT (definisanje ORACLE pregleda). Na sljedećem slajdu prikazan je fizički model podataka za posmatrani sistem u jednom SUBP-u. 9

10 JEZIK Šifraj: Text(2) Nazivj: Text(20) CERTIFIKAT Šifraj: Text(2) Stepen: Text(10) MUŠKARAC Služiov: Text(2) RADNO MJESTO Šifrarm: Text(2) Nazivrm: Text(20) ŽENA Služiov: Text(2) P Pol Prezime: Text(20) (IE1) Ime: Text(20) (IE1) Šifrarm: Text(2) JMBG: Text(13) (AK2) rukov: Text(6) Datumz: Date/Time Plata: Double Stimul: Double Šifrao: Text(2) Pol: Text(1) Vrsta: Text(1) KONSULTANT Vrsta I:SN I:SN Šifrao: Text(2) Nazivo: Text(20) Mjesto: Text(20) ISPLATA rbr: Text(2) REDOVNI Datumis: Date/Time Iznos: Text(18) Brojs: Integer Vrstap: Text(18) Pregled nekih ugrađenih tipova podataka kod SUBP-ova Byte (Podtip od numetičkog tipa podatka Number), Counter (Broj koji se automatski dodjeljuje i ne mijenja se), Currency (Novčani iznos koji predstavlja broj sa četiri decimale); Data/Time (Datum i vrijeme), Double (Podtip numeričkog tipa podatka Number sa pokretnim zarezom duple preciznosti, Integer (Podtip numeričkog tipa podatka Number. Predstavlja cjelobrojnu vrijednost i zauzima dva bajta), Long Integer (Podtip numeričkog tipa podatka Number. Predstavlja cjelobrojnu vrijednost i zauzima četiri bajta.), Memo (Obimni tekst od karaktera), OLE Object (Objekat tipa slika, zvuk, animacija), Single (Podtip numeričkog tipa podatka Number sa pokretnim zarezom obične preciznosti.), Text (Bilo koji tekst dužine do 255 znakova.), Yes/No (Logički tip podatka - True/False). Sada možemo konstatovati da posjedujemo sve elemente koji su potrebni da bi definisali fizički model: Logički model Tipove podataka Pravila za definisanje indeksa Domene, ograničenja i validaciona pravila Referencijalni integritet za veze. 10

11 Dodjela privilegije Sintaksa naredbe za dodjelu privilegije je GRANT <Privilegija> ON <tabela ili pogled> TO <korisnik ili grupa korisnika> [WITH GRANT OPTION]; Privilegije mogu biti: SELECT, UPDATE, INSERT, DELETE INDEX, EXPAND (dodavanje atributa relacije), ALL (važi za sve navedene privilegije), RESOURCE (omogućuje korisniku kreiranje objekata baze podataka, kao što su: tabele, indeksi, klasteri), DBA (obavlja administrativne zadatke, kao što su: CREATE TABLESPACE i CREATE ROLLBACK SEGMENT kao i mnoge druge); WITH GRANT OPTION daje dozvolu davanja privilegije drugom korisniku. Primjeri: GRANT SELECT ON RADNIK TO PERA;. GRANT SELECT ON RADNIK TO VLADA; GRANT UPDATE (PLATA, STIMUL) ON RADNIK TO STEFAN;. Ako neko treba da ima uvid u podatke onda se privilegije mogu odnositi na pogled. Prvo kreiramo pogled: CREATE VIEW ZAPIS AS SELECT SIFRAR, PREZIME, SIFRARM, RUKOV, DATUMZ, SIFRAO FROM RADNIK; pa damo privilegiju: GRANT SELECT ON ZAPS TO ALEKSANDAR;. Sljedeći pogled se definiše za radnike koji rade u istom odjeljenju kao USER: CREATE VIEW IMERAD AS SELECT * FROM RADNIK WHERE SIFRAO IN (SELECT SIFRAO FROM RADNIK WHERE PREZIME = USER);. Nakon definisanja pogleda mogu se dodijeliti odgovarajuće privilegije. Prelaskom nekog zaposlenog u drugo odjeljenje USER gubi privilegiju koju je dobio nad pogledom vezano za tog zaposlenog. Oduzimanje privilegije Sa REVOKE se oduzimaju privilegije. Npr. REVOKE INSERT ON RADNIK FROM ALEMPIJE;. Zaključavanje podataka se vrši prilikom: sintaksne analize, izvršavanja komandi i pristupanja redovima. Prostupak zaključavanja prestaje u dva slučaja: kada se transakcija završi (COMMIT/ROLLBACK) i kada se kursor zatvori (logoff). Postupak zaključavanja tabela i redova je najvažniji dio održavanja konzistentnosti i integriteta baze podataka korisnika. Osnovna podjela zaključavanja je nad: tabelama rječnika podataka DDL (Data Definition Language) i tabelama korisnika podataka DML. DDL način zaključavanja kontroliše pristup bazi podataka i izvodi se automatski nad tabelama rječnika podataka. Ovaj način zaključavanja upravlja sljedećim SQL naredbama: CREATE TABLE,..., ALTER TABLE,..., DROP TABLE... itd DML način zaključavanja upravlja pristupom podacima u korisničnim tabelama. Zaključavanje naročito dolazi do izražaja kada je u pitanju uporedna obrada transakcija (koje se izvršavaju uporedo sa drugim transakcijama u sistemu). Mogu se definisati dva načina zaključavanja i to: zajedničko (shared) i isključivo (exclusive). Shared(s) zaključavanje je istovremeno zajedničko zaključavanje tabela da bi se obezbjedio upit nad konzistentim podacima cijele tabele (bez transakcione obrade) ili reda (sa transakcionom obradom). Ovako zaključavanje može izvesti više korisnika. Ovaj način zaključavanja onemogućuje druge korisnike da vrše promjene nad podacima i stavljaju exlusive zaključavanja ali ih ne ograničava pri tom da vrše upite. Exclusive zaključavanje je isključivo zaključavanje tabela ili redova da bi se omogućilo eksluzivno unošenje promjena podataka tako što se onemogućavaju drugi da istovremeno stave bilo kakvo zaključavanja nad istom tabelom. 11

12 Recovery baze Recovery (oporavak) je dovođenje baze u stanje prije softverskog ili hardverskog otkaza (greške u OS, programu, SUBP-u, mrežnoj i pristupnoj arhitekturi, disku, memoriji, nestanak struje). Tehnike redundantnog pamćenja podataka i oporavka baze podataka su veoma kompleksne: periodično kopiranje (dump) baze podataka na eksternu memoriju; zapisivanje promjene baze podatka u žurnal (tzv. log). Recovery onda radi tako što preuzme staru verziju i izvrši sve transakcije iz log-a ali pazi da ne vrši transakcije koje su možda bile od početka neispravne. Bitna je činjenica i to da li je otkaz zahvatio dio sistema ili čitav sistem, kao i to da li se otkaz dogodio u sred transakcije ili na njenom kraju. U log-ovima se često uspostavljaju checkpointi recimo tačke na kojima možemo tvrditi da su do tog momenta sve transakcije ponovljive i izvršive. Nakon kompletnog logičkog opisa baze podataka pristupa se fizičkom dizajnu koji predstavlja transliranje baze u konkretni SUBP (sa eventualnim ograničenjima koja u njemu postoje). Odličan alat za direktni i inverzni inžinjering iz baze podataka je ErWin. U dostupnoj verziji ErWin podržava 18 različitih tipova baza podataka i SUBP-ova. Fizički dizajn se kreira praktično paralelno logičkom (za izabranu bazu i SUBP) bez obzira da li se radi na modelu ili na uvezenoj bazi podataka. Procedura za rad sa fizičkim dizajnom posjeduje 4 koraka: kreiranje tabela, kreiranje indeksa, definisanje poslovnih ograničenja i verifikacija dizajna šeme. Kreiranje tabela Za vježbu uradite sljedeće kreirajte tabele u Microsoft Accessu sa različitim indeksima, primarnim i spoljnim ključevima, rolename itd i uvezite to u ErWin a zatim odradite inverznu operaciju. Napominjemo da ako ne raspolažete sa nekim SUBP-om a posjedujete neki SQL alat da se kreiranje tabela vrši naredbom CREATE TABLE dok se kreiranje indeksa vrši narednom CREATE INDEX. JEZIK Šifraj: Text(2) Nazivj: Text(20) CERTIFIKAT Šifraj: Text(2) Stepen: Text(10) MUŠKARAC Služiov: Text(2) RADNO MJESTO Šifrarm: Text(2) Nazivrm: Text(20) ŽENA Služiov: Text(2) P Pol Prezime: Text(20) (IE1) Ime: Text(20) (IE1) Šifrarm: Text(2) JMBG: Text(13) (AK2) rukov: Text(6) Datumz: Date/Time Plata: Double Stimul: Double Šifrao: Text(2) Pol: Text(1) Vrsta: Text(1) KONSULTANT Vrsta I:SN I:SN Šifrao: Text(2) Nazivo: Text(20) Mjesto: Text(20) ISPLATA rbr: Text(2) REDOVNI Datumis: Date/Time Iznos: Text(18) Kreirajte ovaj fizički model na osnovu Accessa ili direktno u ErWin-u pa ga izvezite u Access. Brojs: Integer Vrstap: Text(18) 12

13 Kreiranje aplikacije nad bazom Nakon što se kreira baza i nad njom odrade potrebne operacije sljedeći korak je nabacivanje "mesa" nad bazom odnosno kreiranje aplikacije. Osnovne četiri procedure koje se u ovoj aktivnosti provode su: Kreiranje menija Kreiranje formi Kreiranje upita Kreiranje izvještaja Ponekad se ovaj dio IS-a povjerava posebnom timu koji je specijalizovan za GUI. O tome postoje različita mišljenja u literaturi. U svakom slučaju velika pažnja mora biti posvećena ergonomiji programa! Svaka boja, veličina, pozicija, mogućnost, meniji itd moraju biti posebno istraženi i testirani u razvojnom timu i kod korisnika. Omogućite i anonimno izjašnjavanje korisnika o vašem razvoju. Što se tiče upita i izvještaja oni su najsloženiji dio posla (sa stanovišta programiranja) i predstavljaju obično transliranje SQL upita (ili prikrivenih SQL upita) u aplikaciju. Ti upiti mogu biti veoma složeni pa programeri koji rade ovaj dio aplikacije često bježe u više programske jezike kako bi zaobišli složenost i sintaksu SQL-a. Mislim da je to pogrešno na duže staze (ne treba izbjegavati više programske jezika i razvojna okruženja) jer SQL ima više mogućnosti (nešto se uvijek izgubi u naredbama i metodima programskih jezika) i SQL je precizniji. Složenost upita onda treba apstrahovati tako da korisnik nema osjećaj navedene složenosti! Implementacija Nakon prethodno opisanih faza kreće se u Implementaciju. Implementacija je podijeljena na tri dijela koja se nikako ne mogu smatrati linijom jer neke od narednih faza se koriste kao povratna sprega u prethodnim: Uvođenje Vrednovanje softvera Izmjene u toku uvođenja Izrada korisničkih uputsava Izrada plana obuke Testiranje Testiranje modula Testiranje podsistema Testiranje integrisanog sistema Završno testiranje u okruženju korisnika Održavanje Praćenje rada softvera Ispravljanje grešaka Poboljšanje sistema i dodavanje novih funkcija Izmjena hadvera i softvera 13

14 Vrednovanje softvera Dio priče o vrednovanju softvera smo ispričali u dijelu DSM analize. Pored toga treba povjeriti i funkcionalnost softvera i način na koji softver izlazi u susret zahtjevima korisnika. Obično se sve mjere moraju kvantifikovati i prilikom kvantifikovanja mora se voditi računa o odzivima i performansama za realističan broj parametara a ne za mali testni. Vrednovanje softvera je obrađeno u seriji standarda ISO/IEC 9126 Informacione tehnologije Vrednovanje softvera Karakteristike kvaliteta softvera (Software Quality Assurance SQA). Kriterijumi vrednovanja: funkcionalni zahtjevi, definisani listom potrebnih funkcija određenih preko njihovih težina; sadržaj korišćenja softverskog proizvoda; broj zadataka koje proizvod podržava; broj korisnika; profil korisnika (nivo eksperta, iskustvo, obučenost); dodjeljivanje težina svakoj karakteristici kvaliteta Dubina procedura za vrednovanje softvera zavisi od složenosti i važnosti samog sistema. Vrednovanje softvera Proces vrednovanja se može opisati kroz sljedeće procedure: analiza zahtjeva vrednovanja, specifikacija vrednovanja, projektovanje vrednovanja, primjena vrednovanja i izvještavanje o vrednovanju. Za detalje ovih procedura preporučujem knjigu Projektovanje IS (Veljović) i standarde ISO/IEC Od elemenata ocjenjivanja na koje želim da skrenem pažnju je način i stabilnost akvizicije podataka. Naime, prikupiti podatke i prilagoditi ih našoj obradi ili našoj bazi podataka nije teško jer obično implementiramo modul koji vrši akviziciju ali napominjem da mnogi podaci i formati nisu stabilni ako stižu iz eksternih uslova ili sa Interneta tako da postoji česta mogućnost beskonačnih ispravki modula za akviziciju. Prilikom ocjenjivanja treba uvesti težine čime bi pojedini moduli i podsistemi od veće važnosti imali i veće težine. Ocjene mogu biti izražene u različitim metrikama: prirodni brojevi, 0..1 realni, procenat, "odličan", "dobar", "skroman", "loš"; "da", "ne". 14

15 Korisnička uputstva Neki savremeni CASE alati podržavaju i potpomažu inače veoma složenu aktivnost vezanu za vrednovanje softvera. Vrednovanje može da ukaže na potrebne izmjene kako u toku uvođenja tako i kasnije tokom rada sistema. Korisnička uputstva mogu biti uputstva za rad sa aplikacijama, kao i detaljna korisnička uputstva za svaki programski sistem. Pored papira, treba da imaju i dimenzije on-line dokumentacije. Dokumentacija mora da ima sljedeće karakteristike: pri pisanju neophodni su jasni i koncizni izrazi; oslovljavanje korisnika treba da bude u drugom licu, uz korišćenje aktivnih glagola; pri opisu procedure treba upotrebljavati jednostavne glagole; procedure se moraju opisivati logičkim redom; ne treba upotrebljavati izraze iz žargona; treba izbjegavati šale; dati mogućnost jednostavnog izbora i dr. Prilikom izrade plana obuke pretpostavka je da su korisnici kompjuterski opismenjeni (podsjetite se što to podrazumijeva). Za ovu aktivnost se napravi plan obuke po prioritetima uvođenja pojedinih modula i podsistema. Testiranje softvera Proces testiranja softvera se sastoji od sljedećih procedura: Testiranja modula Testiranja podsistema Testiranja integrisanog sistema Testiranja u okruženju korisnika. Prilikom testiranja provjeravaju se tačnost i performanse softvera. Faza testiranja odnosi ponekad i 50% vremena za razvoj softvera (ako je više to ukazuje na loše dizajniran program a ovo opet nije rijetkost). Ako je korisnik dosta uključen u razvoj softvera to će biti slučaj i sa testiranje. Postoje dva koncepta testiranja: validacija (da li proizvod zadovoljava spoljne kriterijume klijenta) verifikacija (da li je proizvod napravljen kako treba). Tehnike testiranja su: tehniku crne kutije ili funkcionalnu tehniku (testiranje funkcionalne specifikacije programa, ne vodeći računa o unutrašnjoj tehnici i strukturi programa. Tehnika crne kutije je vezana za izbor test-primjera i scenarij za što širi dijapazon ulaznih podataka, napominjem da kod složenih programa ovo isto nije jednostavno); tehniku bijele kutije ili strukturno testiranje softvera. 15

16 Testiranje softvera U principu, definišu se četiri strategije testiranja softvera i to: demonstracija, gdje se utvrđuje da li softver radi u skladu sa specifikacijom; destrukcija kada se namjerno ruši program, i to, obično suprotno zahtjevima; evaluacija, gdje se testiranje izvodi u ranim fazama razvoja softvera; prevencija. Nakon testiranja sistem se pušta u promet a počinje faza održavanja. Svi propusti u sistemu zapravo će se pojaviti u ovoj fazi koja se može podijeliti u sljedeće faze: Praćenje rada softvera Ispravljanje grešaka Poboljšanje sistema i dodavanje novih funkcija/funkcionalnosti Izmjene hardvera/softvera. Na nivou održavanja drastično se pokazuju sve manjkavosti vezane za loše urađene prethodno opisane faze. U zavisnosti od korektnosti rada u prethodnim fazama, programer troši u prosjeku 20% do 80% svog radnog vremena za održavanje. Osnovni problemi u održavanju su: nepridržavanje standarda, loša dokumentacija, nedostatak kadra, nepostojanje testova, nekorektno održavanje, odsustvo povratne veze, nepoznavanje troškova održavanja. Održavanje Praćenje softvera se obavlja kontinualno a osnovne aktivnosti su: sati upotrebe, urađeni poslovi i transakcije, informacije o vremenu, učitavanja, registrovanje nedostataka i dr. Na primjer ako se uoči da vremenom brzina obavljanja transakcija pada ili drastično varira mora se upozoriti programer da provjeri razlog. U fazi ispravljanja grešaka pored ispravljanja grešaka vrši se dodatno prilagođavanja softvera korisničkim zaahtjevima i zadacima. Korisnici po pravilu imaju nove zahtjeve kada počnu da se upoznaju sa sistemom. Poboljšanje sistema i dodavanje novih funkcija ne bi smjelo da bude teško ako je projekat i realizacija IS izvršeni kvalitetno. Izmjena hardvera i softvera podrazumjeva softverske izmjene vezane za promjenu SUBP, kao i hardverske izmjene vezane za izgradnju mreže u okviru klijent/server arhitekture. Baza podataka i aplikacije, koje se na njoj temelje, podvrgnute su čestim promjenama. Promjene mogu biti izazvane razvojem opreme (npr. na tržištu se javlja efikasniji tip: memorije, terminala, procesora). Češće promjene su potrebne zbog razvoja korisničkog sistema (aplikacija), promjene uslova i pravila poslovanja, novih zakonskih zahtjeva itd. Korisniku SUBP mora obezbijediti što veću fleksibilnost jer treba da funkcioniše kao posrednik između baze i aplikacije sa podrazumjevanjem da korisnički dio ne mora da bude izmjenen (znatnije) pri izmjeni baze podataka. 16

17 Internet u sistemu Internet je doveo do znatnog povećanja razvoja softvera nezavisnog od platforme. Dalje, ako vam treba aplikacija vezana za Internet postoji mogućnost da u mnogim elementima koristite već gotova rješenja ili barem procedure koje su standardizovane (u trenutku pisanja ovog materijala postoje čarobne riječ Joomla, Apache, MySQL, Wikimedia commons itd kada budete pročitali vjerovatno će se čarobne riječi izmjeniti). Internet ima mnoge pogodnosti u poslovanju (samo poslovni aspekt mreže vjerovatno zahtjeva poseban kurs). Suštinski Internet treba da omogući bolji način da se postignu ciljevi organizacije. Po pravilu lakše je uposliti Internet da smanji troškove nego da poveća prihode i često treba voditi računa o radu u tom smjeru. Ponovo preporučujem vam materijale vezane za Internet i marketing koji mogu da razbiju neke stereotipe koji postoje u ovoj oblasti. Ono na što želim ovdje da ukažem je činjenica da se Internet može koristiti za pretragu po nestrukturiranim podacima (Data Mining, baze se takođe mogu analizirati sredstima koja nisu upitni jezici u procesu otkrivanja znanja - Knowledge discovery) kao i činjenica da ako niste vlasnik informacija koje koristite sa Interneta možete da "patite" od potrebe da često konvertujete podatke zbog promjena u formatu originalne informacije. Dosta se radi na standardizaciji podataka (XML itd) ali činjenica da konverzija podataka je jedan od najvećih postojećih problema. Softverska kriza Prije nego pređemo na objašnjavanje UML-a i objektno-orijentisanih strategija u projektovanju ISa osvrnimo se na događaje koji su doveli do uvođenja objektno-orijentisanih strategija u programiranje kao i projektovanju ISa. Negdje 80tih godina nakon standardizacije naredbi za kontrolu toka podataka kao i nakon sistematizovanja procedura za modularno projektovanje softvera i ISa veoma veliki broj korisnika je došao u dodir sa moćnim računarskim alatkama. Postala je jasna potreba da se svi novi softveri i alati kreiraju za korisnika sa minimumom računarskog znanja. Da stvar bude gora ti korisnici upoznati sa snagom računarskih sistema postavljali su softverskim kućama sve veće i veće zahtjeve. Softverske firme su mogle da prežive samo izdavanjem novih i novih verzija softverskih alata koje će se dobro prodavati na tržištu i koje će izaći u susret korisničkim zahtjevima. 17

18 Softverska kriza Da bi se iz takvog posla profitiralo neophodno je da se program (projekat) završi u kratkom vremenu jer su satnice programera relativno visoke. Kvalitetan softver i kratko vrijeme izrade su kontrodiktorni zahtjevi tako da su se na tržištu pojavljivali paketi prepuni grešaka koji naravno nijesu bili kupovani a zatim su firme koje su uložile novac u njihov razvoj propadale. Ovaj niz događaja se naziva softverskom krizom. Glavni uzrok u softverskoj krizi je modularni (strukturalni) princip u pisanju programa i projektovanju ISa (kojeg smo do sada izučavali). Naime, softverski projekat se sastojao od mnoštva funkcija i od mnoštva strukturalnih tipova podataka koje smo npr. u Erwinu modelovali sa entitetom. Funkcije uglavnom barataju sa entitetima npr. funkcija za obračun plate će vjerovatno morati da komunicira sa entitetom Radnik. Softverska kriza Ako se promijeni entitet moraju se editovati sve funkcije koje sa tim entitetom posredno ili neposredno barataju. Editovanje mnoštva funkcija znači mnoštvo mogućnosti za pogreške. Da bi se izbjegle pogreške u verzijama softvera namijenjenim za tržište bilo je potrebno da se softveri počevši od svake funkcije pojedinačno testiraju. Stoga su 80-tih programeri testirale programe a nijesu ih pisali. Kako je brzina izdavanja softvera bila važna za profit nedovoljno testirane verzije programa su izlazile na tržište. Te verzije su imale previše grešaka i zbog toga su propadale zajedno s softverskim kućama koje su ih izdavale. Zahtjevi korisnika su i dalje rasli pa je postalo očigledno da uskoro nijedna softverska kuća na postojećim strukturnim osnovama neće moći da prizvodi softver uz zaradu. 18

19 OO Projektovanje softvera Izlaz iz softverske krize je ponudio Bjarne Stroustrup koji je 80-tih radio za firmu AT&T Bell. Njegov zadatak je bila prepravka softvera za telefonsku centralu. Uočio je da sa povjerenim ljudstvom, na osnovu datog kompajlera i u datom vremenu nije moguće završiti projekat. Spas je potražio u kreiranju novog kompajlera u koji je ugradio objektno-orjentisane elemente. Objektno-orjentisano programiranje postoji od prije Stroustrupa (npr. jezik Smalltalk) ali nije bilo popularno zbog složenosti. Stroustrup je uočio da je 90% sistemskog softvera u tom trenutku napisano na programskom jeziku C. Stoga je odlučio da ne kreira novi programski jezik već da C nadogradi objektno-orjentisanim elementima. Tako je nastao programski jezik C++ kao rješenje tadašnje softverske krize. C++ kao rješenje softverske krize Osnovni element u rješenju je bilo sakrivanje unutrašnje organizacije entiteta. Ti entiteti su nazvani klasama i funkcije koje njima barataju nijesu znale kako su realizovani. Ako funkcija ne zna unutrašnju organizaciju klase to znači da ne treba mijenjati funkciju ako se promjeni klasa. Pa kako se obavlja onda komunikacija sa unutrašnjim elementima klase (klasinim atributima ili osobinama)? U klasin interfejs su uvedene funkcije koje se koriste za komunikaciju. To znači da ako se mijenja unutrašnja organizacija klase treba promjeniti samo te funkcije koje su ugrađene u njen interfejs a ne i sve ostale funkcije u paketu. Dakle klasa je omogućila lokalizovano prepravljanje softverskih paketa. 19

20 OO dizajn Princip sakrivanja unutrašnje organizacije klase se naziva enkapsulacija (sakrivanje u kapsulu). Vremenom je razvijeno više takvih koncepata koji su značajno usložnili projektovanje OO programa. Znači bogatstvo koncepata usložnilo je optimalno projektovanje softvera. Neoptimalno projektovan softver i pored ugradnje OO koncepata je bilo teško prepravljati. Ovo je vodilo do nove softverske krize (krajem devedesetih XX vijeka). Naučnici su da bi izbjegli pomenute probleme počeli da kreiraju procedure za OO modelovanje, dizajn i projektovanje. Tih procedura je bilo jako puno (preko 50) pa je bilo teško se odlučiti za onu koja je dobra. Tako je nastao UML kao sublimacija nekih od najboljih procedura za OO projektovanje, dizajn i modelovanje. 20