MODELIRANJE PODATAKA Alempije Veljović Modeliranje podataka je naše apstraktno vidjenje stanja realnog sistema tj. definisanje strukture podataka. Model podataka je pojednostavljeno predstavljanje realnog sistema preko skupa objekata(entiteta), veza izmedju objekata i atributa objekata. Model podataka(u literaturi definisan kao Model Objekti-Veze(MOV) ili E-R(Entity-Relatioship) model ili Entitetni dijagram), preko skupa podataka i njihovih medjusobnih veza, predstavlja stanje sistema u jednom trenutku vremena i sadrži skup informacija o prošlosti i sadašnjosti sistema koja je potrebna da se pod dejstvom budu ćih poznatih ulaza mogu odrediti njegovi budu ći izlazi.
Modeliranje podataka je svojevrstan grafički jezik za predstavljanje strukture podataka. CASE(Computer Aidid Software Engineering) alati kao software-ska podrška modeliranju predstavlja samo alat za definisanje modela podataka realnog sistema, odnosno za opisivanje skupa povezanih objekata realnog sistema i događaja u njemu preko jednog složenog apstraktnog tipa podataka(strukture podataka, ograničenja i operacija). Izbor odgovarajućeg CASE alata sam po sebi je manje ili više formalan, dok postupak modeliranja realnog sistema, zavisi od sposobnosti, znanja i iskustva analitičara. Ne mogu se dati strogo formalna pravila modeliranja koja bi vodila do jedinstvenog modela složenog realnog sistema, bez obzira na to ko modeliranje vrši. Mogu se dati samo opšte metodološke preporuke, opšti metodološki pristupi, kao pomoć u ovom složenom poslu. Modeliranje podataka se oslanja na izvršeno modeliranje procesa o čemu je više bilo reči u predhodnom poglavlju gde je definisan odgovarajući rečnik podataka. Ovde je naš zadatak da izvršimo modeliranje podataka u dva koraka modeliranjem pogleda i modeliranjem zahteva.
Osnova za modeliranje pogleda su definisani dijagrami tokova podataka do kojih se došlo postupkom itervjua sa zaposlenima. Modelirani pogledi zahtevaju integraciju u generalni model podataka tako da ovaj pristup prestavlja tzv. pristup odozgo na dole(top-down). U modeliranju pogleda prvo je potrebno odrediti "oblasti" pogleda gde treba da budu definisane jasne granice. Ove granice su definisane procesom u dijagramima tokova podataka(DTP) i one nesmeju da bude isuviše mala da bi imalo smisla obradjivati ih a ni suviše kompleksne da se nemogu sagledati u celosti. Dakle, modeliranje pogleda počinje sa formiranjem okvirnog modela podataka pa pristupom proširivanja generišemo model podataka pritom vodeći ra čuna o sinonimima(različita imena za iste tipove entiteta), homonimima(ista imena ozna čavaju različite tipove objekte) kao i o tome da isti entiteti na različitim pogledima budu iste vrste(slab, agregacija i dr.), da ista preslikavanja na razli čitim podmodelima imaju iste kardinalnosti pritom treba otkriti da li veze izmedju istih tipova entiteta po različitim putanjama imaju istu semantiku pa neku od tih veza treba prekinuti. O svim ovim elementima kasnije će biti više reči. Na osnovu izmodeliranih pogleda i izvedene njihove integracije pristupa se modeliranju zahteva kojima se precizno definišu atributi na osnovu postoje će dokumentacije(obrasci, kartoteke, fascikle i dr.). Ovo je pristup odozdo na gore (bottum-up). Osnovni zaključak je je da širinu u pristupu nam daje modeliranje pogleda a preciznost omogućuje modeliranje zahteva. Da bi se postupak modeliranja podataka korektno korišćenje CASE alati omogućava nam: Definisanje sistemske dokumentacije koja može biti korišćena od strane baze podataka i osoblja za razvoj aplikacija da definišu sistemske zahteve •
• •
•
Bolju komuniciju medjusobno i sa krajnjim korisnicima. Jasnu sliku o ograni čenjima referencijalnog integrita. Održavanje referencijanog integriteta je bitan u relacionom modelu jer su relacije kodirane implicitno. 'Logičke' sliku baze podataka koja može biti korišćena od strane automatskih alata za generisanje SUBP-specifičnih informacija.
Model podataka je intelektualno sredstvo pomoću koga se prikazuje u kakvom su međusobnom odnosu podaci u nekom realnom sistemu. Neki model podataka p odataka je potpuno određen ako su definisane sledeće tri komponente : STRUKTURU PODATAKA, kojima se definišu stati čke karakteristike sistema(opis entiteta, atributi i veze) odnose se na kreiranje ER modela i Atributi ER modela. OGRANIČENJA-logička ograničenja na podatke(pravila integriteta) koja se ne mogu definisati preko strukture modela podataka(strukturna i vrednosna ograničenja) i odnosi se na definisanje poslovnih pravila . SKUP OPERATORA(OPERACIJE)-definiše dinami čku interpretaciju podataka kroz njihovu obradu(održavanje BP i pretraživanje) ima uticaja na definisanje fizi čkog nivoa modela i verifikaciju finalnog dizajna.
•
•
•
1.
KREIRANJE ER MODELA
ER model definisan je entitetnim dijagramom kojim se definišu odgovaraju ći tipovi entiteta i uspostavljaju veze između njih, kao i definisanje detalja vezanih za opis sadržaja entiteta (atributi i njihove karakteristike). Strukturu podataka definisana je sa tri komponente: •
Entitete koji se se dele u dve grupe i to: Nezavisne entitete, to su entiteti koji imaju vlastitu identifikaciju, tj. nisu zavisni od drugog entiteta. Zavisni entiteti, to su entiteti čija je egzistencija i identifikacija zavisna od drugog ili drugih entiteta Atribute koji se mogu nalaziti u: Oblasti ključeva ili •
•
•
• •
•
Oblasti podataka
Veze koje se dele na: •
Identifikuju će veze koje entitet dete identifikuje kroz njegovu vezu sa entitetom
roditelj. •
Neidentifikuju će veze koje ne identifikuju entitet dete preko identifikatora entiteta
roditelja. • •
Neodređujuće veze koje se smatraju veze više prema više. Veza prema podtipovima uspostavlja vezu između entiteta i njegovih zavisnih,
klasnih entiteta. Entitetni dijagram definiše se entitetima (entities) i pritom svaki entitet ima svoje osobine tj. atribute (attributes) i sve je to povezano relacionim vezama (relationships). Entiteti se definišu i kao generalizovane hijerarhija o čemu će kasnije biti više re či. Atributi imaju domene (domain) koji predstavljaju skup vrednosti ili interval vrednosti koje taj atribut može da primi. Na sledećem nivou definišu se primerci (instance) koje predstavljaju pojedinačne vrednosti entiteta. Svaki entitet se identifikuje preko atributa koji se zove primarni ključ. Relaciona veza povezuje dva entiteta i ona ima svoje osobine koje se nazivaju kardinalnost koja pokazuje “koliko nečega” od dva entiteta može biti uključeno (sadržano). Relaciona veza definisana je prenesenim ključem (foreign key) od roditelja ka detetu. Preneseni ključ može imati i ime uloge (rolenames ) o čemu će kasnije više biti reči. Entitetni dijagram je svojevrsan grafički jezik gde se 'rečenica' sastoji od entiteti koje su imenice, atributi kao pridevi i veze kao kao glagoli. Entiteti i veze veze definišu se se analizom strukture
teksta gde se mogu definisati slede će analogije vezane za razlikovanje entiteta, atributa ili veza: TEKST IMENICA GLAGOL PRIDEV PRILOG GLAGOL.IMENICA RECENICA POGLAVLJE
1.1.
E-R KONCEPT ENTITET VEZA ATRIBUT ENTITETA ATRIBUT VEZE MESOVITI TIP ENTITETA-VEZA OBJEKTI POVEZANI VEZAMA LOKALNI PODMODEL Slika 1
Identifikacija kandidate za entitete
Objekt posmatranja je sve što možemo jednoznačno identifikovati, pa samim tim izolovati iz okoline i opisati. Tako objekt posmatranja je i " entitet". Entitet je osoba, stvar, dogadjaj, pojam(realni ili apstraktni) koji je od trajnog interesa za preduze će tj. nešto što se želi pojedinačno posmatrati. Objekti u sistemu se opisuju preko svojih svojstava, odnosno atributa. Svaki atribut u jednom trenutku vremena ima neku vrednost. Imajući ovu u vidu da bi smo mogli da definišemo šta je entitet posmatraćemo: 1. Sličnost ATRIBUTA koji mogu pripadati entitetu. Ovde se uočava značajna razlika(sli čnost) u atributima što može da ukaže da se radi o različitim(istim) objektima 2. Način identifikovanja entiteta gde za svaki tip entiteta mora da postoji jedan atribut ili
grupa atributa koji jedintveno identifikuje konkretni entitet u okviru tog tipa. 3. Učešće u tipu veze utvrdjuje da li je neki entitet zavistan ili nezavistan entitet ili agregacija dva objekta. 4. Na osnovu pasivne i aktivne uloge moguće je definisati odgovarajući tipovi entiteta: ULOGA VEZE
TIP ENTITETA
RUKOVODI RUKOVODJEN NARUCUJE NARUCEN
RUKOVODILAC ODELENJE KUPAC PROIZVOD
5. Na osnovu atributa na dokumentima je moguće identifikovati entitete i veze kao npr.: ATRIBUT
PITANJE
ODGOVOR
BOJA STAROST DATUM
BOJA CEGA? STAROST CEGA? DATUM CEGA?
PROIZVOD RADNIK NARUDZBE
6. Stvarni fizicki objekti su objekti(entiteti) u modelu. Prikladni kandidati za entitete su: Fizički objekti(vozilo, mašina, jedinica opreme...) Osobe Mesta(adresa, koordinate na karti,...) Organizacije(preduzeća, zavod,...) Grupe/klase/tipovi(tip proizvoda, klasa poslova,...) Ugovori Potraživanja(narudžbe, fakture,...) Prenos/ premeštaj(stvari, vozila, novca,...) • • • • • • • •
• •
Pridruženje(zadatak-osoba, vozila vožnja,...) Pripadnost/članstvo( komponente-sastavi,...)
7. Atribut prelazi u entitet: ako sam atribut ima neko posebno zna čenje u realnom sistemu, atribut u osnovi identifikuje drugi tip entiteta(sifra), atribut je istovremeno atribut drugog entiteta • • •
8. Ako postoji struktura tipa generalizacija pristupa se od vrha na niže gde se definišu prvo neki opšti tipovi entiteta pa zatim definišu podtipovi ovih entiteta(ENTITET-RACUN podtipove TEKUCI RACUN RACUN DUGOVANJA i CEKOVNI RACUN) 1.2.
Identifikacija veze
Veza ili relacija predstavlja interakciju medu objektima tj. predstavlja znanje o njihovoj medjusobnoj povezanosti. Relacijama se definišu zavisnosti izmedju entiteta tj. opisuju na čin povezivanja (uzajamna dejstva) entiteta. Identifikacija veza izvidi se u sledećim koracima: Povezivanje entiteta na osnovu odgovarajućih interesa definisanje zavisnosti entiteta, gde se definišu nezavisni i zavisni entiteti Definisanje značenja zavisnosti definisanjem referencijalnog integriteta Izvodjenjem varijacija zavisnosti nalaženjem optimalne i Izborom entiteta roditelj i entiteta dete • • • • •
Osnovni kriterijumi koji nas opredeljuju kako definisati vezu su: 1.Interakcija izmedju entiteta kao npr.:
RADNIK---------RADI U---------ODELENJU 2. Aktivnosti, procesi, zadaci se mogu definisati kao veze: UCESCE, ODOBRENO OD, STOPA POREZA OD 3. Opisna veza tj. kada neki tipovi entiteta opisuju drugi tip entiteta kao npr.: OSOBA --------SARTIFIKAT--------JEZIK 4. Veza pripadnosti za PODTIP i NADTIP da li se dva entiteta mogu vezati sa iskazom JE-RACUN JE TEKUCI RACUN RACUN DUGOVANJA i CEKOVNI RACUN. Relacije (medju entitetima) predstavljaju veze ili asocijacije. U rečenici to su 'glagoli' koji pokazuju kakav je odnos madju entitetima. Glagolske fraze definišu pravila poslovanja. Premda glagolske fraze ne opisuju pravila precizno, one dozvoljajvaju osobi koja posmatra model da stekne osnovni ose ćaj o povezanosti entiteta. Dobra je praksa osigurati da čitanje modela daje valjane rečenice (iskaze).
U sledećoj tablici dat je predlog mogućih fraza kojima se definisu veze izmendu entiteta.
ODNOSI ZAHTEVA SADRZI DEFINISE SALJE POSEDUJE REALIZUJE UKLJUCUJE 1.3.
VAZI POSLATA POREDI TRAZI ODGOVORA IDENTIFIKUJE PODSTICE IMA
KORISTI POSTIZE ODREDJUJE UPRAVLJA POTVRDJUJE SPECIFICIRA NABAVLJA UPUCUJE Slika 2
IZGRADJUJE POTVRDJUJE PRIHVATA PROVERAVA NALAZI POVEZUJE RAZDVOJA SELEKTUJE
Definisanje entiteti i relacija
Definisanje entiteta Sa gledišta obrade podataka realan svet sastoji se iz objekata(entiteta) posmatranja, koji su ili realni objekti (osoba, mašina, vozilo, ku ća), apstraktni koncept(preduzeće, radno mesto), dogadjaj(prekršaj, prevoz) ili odnosi (student-predmet, muž-žena). Entiteti su obi čno imenovani imenicama, kao 'OSOBA' ,'TELEFON', 'ZAPOSLEN'. Preciznije, možemo razmišljati o nekom entitetu kao o setu ili kolekciji ( skupu) individualnih objekata zvanih primerci( instances). Jedan primerak je jedan pojavni oblik datog entiteta.Svaki primerak mora imati identitet različit od svih ostalih primeraka. Predmet našeg daljeg posmatranja su sledeći tipovi entiteta: Nezavisni entiteti i Zavisni entitete • •
Nezavisni entitet
Nezavisni entitet je objekat koji ima jednu osobinu koja ga može jednozna čno identifikovati. Grafički se nezavisni entiteti prikazuju pravougaonikom u okviru koga se upisuje naziv tipa entiteta u jednini (sl.3).
OSOBA Slika 3 Kao što možemo viseti na slici 1 entitet OSOBA predstavlja skup svih mogu ćih osoba sa kojima se komunicira. Svaki primerak entiteta OSOBA je jedan korisnik. Sa stanovišta relacionih baza, jedan entitet odgovara tabeli čiji se redovi sastoje od mogu ćih primeraka( instance) datog entiteta.
Zavisni entitet
Zavisni entiteti, su entiteti čija je egzistencija i identifikacija zavisna od drugog ili drugih entiteta. Zavisni entiteti se dele u četiri grupe i to: Karakteristi čni entiteti, tj., entitete koji se ponavljaju više puta za određeni nezavisni entitet. Asocijativne entitete koji predstavljaju vezu više entiteta. Projektne entitete koji je sličan asocijativnom entitetu, samo što nema sopstvene atribute. Klasne entitete koji predstavljaju podkategoriju entiteta. •
• •
•
Grafički se zavisni entiteti prikazuju kao zaobljeni pravougaonici u okviru koga se upisuje naziv tipa entiteta u jednini. Razmotrimo svaki od ovako definisanih zavisnih entiteta. Karakteristi čni entitet ili slab entitet prestavlja grupu atributa koji se ponavljaju više puta za jedan entitet i koji se identifikuju preko nezavisnog. Npr. Entiteti OSOBA i ISPLATA. Za entitet ISPLATA se kaže da je karakteristi čan entitet od entiteta OSOBA.To se može videti na slici 4. ISPLATA
je primio prima
OSOBA
Slika 4 Asocijativni entitet su sastavljeni od više relacionih veza izme đu dva ili više entiteta kao što
se može videti na slici 3. Npr. ako OSOBA zna više JEZIKa i jedan JEZIK poznaje više OSOBA, tada je SARTIFIKAT asocijativni entitet koji opisuje veza izme đu entiteta OSOBA i JEZIK. Dakle, asocijativni entiteti nose informaciju o relacionoj vezi. O SO BA
je dat/ poseduje
vazi/ odosise
JEZIK
SARTIFIKAT
Slika 5 Projektni entitet (designative) je sličan asocijativnom entitetu, izuzev što nema sopstvene
atribute.U predhodnom primeru, SERTIFIKAT se može koristiti kao projektni entitet pod uslovom da ne nosi nikakvu informaciju izuzev identifikacionih oznaka za OSOBA i JEZIK. Klasni (category) entitet je zavistan entitet u “pod-klasnoj” (“sub-category”) relacionoj vezi. Ovaj tip ćemo detaljnije kasnije objasniti.
Veze izmedju entiteta Kao što se u realnom svetu uspostavljaju odredjene relacije izmedju objekata, po istoj analogiji definišu se i veze izmedju entiteta. Veza je asocijacija izmedju dva ili više entiteta tj. veza predstavlja odnos koji postoji medju objektima bilo u realnosti ili mislima. Relacija ili veza prikazuje se kao linija koja povezuje dva entiteta, sa tačkom na jednom kraju i glagolskom frazom napisanom duž linije. Entitet od koga je uspostavljena veza zove se roditelj , a entitetu ka kome je uspostavljena veza zove se dete. Drugim rečima, roditelj-dete veza je asocijacija ili veza izmedju entiteta gde svi primerci jednog entiteta, definisani kao roditelj entitet, su asocirani sa nula, jedan ili više primeraka drugog entiteta, definisanog kao dete entitet, i svi primerci dete entiteta su asocirani sa nula ili jedan primerkom entiteta roditelj. Veze (relationships) opisuju pravila poslovanja i obezbjeđivanja referencijalnog integriteta o čemu će više biti reči u sledećem poglavlju.. CASE alat koji koristimo da bi smo opisali modeliranje podataka je ERwin model koji omogućuje uspostavljanje četiri tipa veze i to : Identifikujuće veze koje entitet dete identifikuje kroz njegovu vezu sa entitetom roditelj. Neidentifikujuća veza ne identifikuje dete preko identifikatora roditelja. Neodređujuća veza se smatra vezom više prema više. To je veza u kojoj je jedan entitet povezan sa 0,1 ili više pojava drugog entiteta i i obrnuto. Veza prema podtipovima uspostavlja vezu između entiteta i njegovih zavisnih, klasnih entiteta. Preko ove veze entitet koji se specijalizuje u klase prosleđuje primarni ključ klasnim zavisnim entitetima. Pri toma ERwim simbolički obezbeđuje razlikovanje dve specijalizacije i to: potpuna, u kojoj je sigurno da nema višeklasnih entiteta u koje bi se speciajlizovao odre đeni entitet(dvostruka linija na dnu simbola klase nazna čuje da ne mogu biti uklju čene druge kategorije). nepotpuna, kada nije sigurno da su identifikovani svi klasni entiteti u koje bi se specijalizovao određeni entitet(jednostruka linija na dnu simbola klase nazna čuje da mogu biti uključene druge kategorije). Za ovakvu vezu se definiše atribut diskriminator u entitetu koji se specijalizira koji obezbeđuje ekskluzivnost veze. Ako se diskriminator ne definiše veza se može smatrati neekskluzivnom. CASE alat ERwin definise gore opisane veze preko toolbox-a:
Slika 6
Identifikujuće i ne-identifikujuće veze U dosadašnjim prikazima veze smo definisali u tzv IDEF 1X formatu (Integation DEFinition for Information Modeling) koja se koristi u ERwin CASE alatu. Relacija se zove identifikuju ća zato što ključevi entiteta 'roditelja' su deo identiteta entiteta 'dete' tj. entitet 'dete' je zavistan od entiteta 'roditelja' preko identifikatora. Dakle, ako se primerak entiteta dete identifikuje preko asocijacije sa entitetom roditelj, onda se veza definiše kao identifikujuća veza, i svaki primerak entiteta dete mora biti povezan sa najmanje jednim primerkom ebtiteta roditelj.
Identifikujuće relacije su prikazane punom linijom koja povezuje entitete sa tačkom na kraju. Sve relacije koje smo videli do sada bile su identifikujuće. U identifikujućoj relaciji preneseni ključ prenosi se u oblast ključeva ( iznad linije slika 7). Entitet-A Kljuc atri buta-A Entitetroditelj
Identifikujuca veza N aziv veze
Entitet- B Kljuc atributa-A (FK) Kljuc atri buta-B
Entitetdete
Slika 7 Identifikujuća veza Ako posmatramo primer sa slike 8 definisaćemo rečenicu gde je glagol veza izmedju entiteta OSOBA i TELEFON. OSOBA više TELEFONa U ovom primerku veze izmedju dva entiteta je izabrana tako da ima oblik koji poznat kao 1 prema "više". To znači da jedan (i samo jedan) primerak entiteta osoba(entitet roditelj) je povezan sa više primeraka entitet telefon(entitet dete). Identifikujuća veza nam govori da ne može biti definisan primerak entiteta TELEFON ako ne postoji namanje jeda primerak entiteta OSOBA. Notacije "više" ovde ne znači da je ovde bilo više od jednog primerka 'deteta' povezanog za datog 'roditelja'. Umesto 'više' u 'jedan prema više' kao što je upotrebljeno gore realno zna či da je nijedan, jedan ili više primeraka entiteta-deteta povezano sa jednim roditeljskim entitetom. Na osnovu definisane rečenice korišćenjem glagolske fraze definiše primer relacije izmedju entiteta roditelj OSOBA i entiteta dete TELEFON (Slika 8) koristi
TELEFON
OSOBA
P
Slika 8 Primer relacije Ako svaki primerak entiteta dete može se jedinstveno identifikovati bez znanja veze sa primerkom entiteta roditelj, onda se takva veza definiše kao ne-identifikujuće veze. Ne-identifikujuće veze su prikazane isprekidanom linijom koja povezuju roditelj-entitet i deteentitet sa tačkom na kraju. Jedan ne-prazan podskup prenesenih ključeva prenosi se preko neidentifikujuće relacije postavlja se u oblast podataka ( ispod linije slika 9). Neidentifikujuća ili slaba veza zavisi od načina definisanja ključeve od roditelja ka detetu. Ovo znači da identifikacija detata neće zavisiti od njegovog roditelja. Ovde je slučaj gde entitet na “many” kraju veze može postojati bez roditelja (parent), tj. nije egzistencijalno zavistan. Ako je relaciona veza (relationships) obavezna (No Nulls ili Mandatory) iz perspektive roditelja, onda je dete egzistencijalno zavisno od roditelja.
Entitet-A Kljuc entiteta-A Entitetroditelj
N aziv veze
O bavezna neidentifikujuca veza
Entitet-B Kljuc atri buta-B Kljuc atributa-A (FK)
Entitetdete
Slika 9 Neidentifikujuća obavezna veza
Ako je veza neobavezna(Nulls Allowed ili Optional), tada dete niti je egzistencijalno niti identifikaciono zavisno ali poštuje tu vezu. Entitet-A Kljuc atributa-A Entitetroditelj
Nazi v veze
O pciona neidentifikujuca veza
Entitet-B Kljuc atributa-B Kljuc atributa-A (FK)
Entitetdete
Slika 10 Neidentifikujuća neobavezna veza ERwin koristi romb (diamond) da naznači slučaj egzistencijalne i identifikacione zavisnosti. Romb može postojati samo u slabim vezama (pošto je jaka veza u oviru primarnog klju ča, a primarni ključ ne može da ima NULL vrednost). Kad god su entiteti u ERwin dijagramu povezani preko relacije, relacija prenosi klju č entitetaroditelj ( ili skup ključeva) u entitet-dete. Dakle, preneseni ključni atributi koji su definisani kao primarni klju čni atributi entiteta 'roditelja' preneseni su entitetu 'dete' kroz relaciju. Preneseni(foreign key) ključevi odredjeni su oznakom (FK) i dolaze iza imena atributa(slika 9). U okviru ERwin-a mogu će je definisati i ime uloge(rolename). Ime uloge je novo ime za spoljne ključne atribute koji definisu ulogu koju ti atributi igraju u tom entitetu. Ime uloge deklarise novi atribut čije ime treba da opise poslovno pravilo ugradjeno preko relacije koja zahteva spoljašnji ključ.
1.4.
Izrada ER modela
Izrada entitetnog dijagrama može se definisati sledećim koracima: •
Identifikacija potencijalnih entiteta u sledećem redosledu: formirati listu potencijalnih entiteta odrediti prikladne radne nazive napraviti grupe entiteta(ako ih je više od 15) po grupama tražiti dodatne entitete(posmatraj najvažniji entitet) po potrebi rearanžirati grupe Kreirati radne entitetne dijagrame Pronadji roditelje Identifikuj zavisne entitete Identifikuj posebno pod -tip entitete Verifikuj entitete Izvršiti opštu proveru entiteta(naziv, pojavljivanje, zavisnost...) Provera pitanjem Šta ako.... Revizija sa korisnicima Kreiranje formalnih entitetnih dijagrama Radni prelaze u formalne Kompletiraj dijagrame definisanjem pravog naziva i opisa zavisnosti • • • • •
•
• • •
•
• • •
•
• •
pripada / RADNO MESTO rasporedjen
JEZIK
P
vazi / odosi se SARTIFIKAT
zaposljava / ODELENJE radi prima / je primio
OSOBA je dat / poseduje
rukovodi / je rukovodioc
Pol
MUSKARAC
ISPLATA
Vrsta
ZENA
KONSULTANT
Slika 12
REDOVNI
2. Atributi ER modela
Svaki objekat realnog sveta definisan je osobinama pa po toj analogiji i entiteti imaju atribute kojima se opisuju karakteristična svojstva.
2.1. Lista kandidata za atribute Da bi se definisala lista kandidata za atribute mora se dati odgovor na pitanje što je to interes procesa obrade podataka. Da li će po nekoj osobini objekat biti entitet ili atribut tj. koju će ulogu da ima zavisi od pogleda koji želimo da predstavimo. Ako je osnovni objekat od interesa npr. kuća onda kuća postaje entitet a atribut ulica u suprotnom ako je objekt od interesa ulica onda je ulica entitet a atribut je kuća. Osnivna pravila za definisanje atributa su: Svaki entiteta ima proizvoljan broj atributa Odredjeni atribut pripada jednom i samo jednom entitetu Svako pojavljivanje entiteta ima vrednosti za sve atribute tog enititeta Atribut odredjenog pojavljivanja entiteta može imati samo jednu vrednost Različita pojavljivanja entiteta mogu a nemoraju imati razli čite vrednosti za isti atribut Svaki atribut mora imati samo jedno konsistentno zna čenje • • • • •
•
Svaki atribut predstavlja jednu odredjenu činjenicu pa i svako značenje vrednosti atributa mora imati jedno dosledno značenje.
2.2. Definisanje ključeva u modelu Dakle, svaki entitet ima svoja obeležja koja se nazivaju atributi . Atributi imaju
domene koji prestavljaju skup vrednosti ili interval vrijednosti koje taj atribut može da uzme. Svaki entitet mora imati atribut ili kombinaciju atributa čije vrednosti jedinstveno identifikuju svaki primerak entiteta. Dakle, ovi atributi su posledica činjenice da postoj atributa ili grupe atributa čije vrednosti jednoznačno identifikuju primerke entiteta. Taj atribut ili grupa atributa naziva se peimarni ključ . Ako ključ čini samo jedan atribut onda je on prost ključ , u suprotnom je slož en. Atributi mogu biti definisani u oblasti klju čeva(primarni ključ) ili u oblasti podataka(Slika 13) Kao što se na slici 13. vidi entitet OSOBA je predstavljen crtanjem pravougaonika sa imenom entiteta na vrhu i svim atributima unutar pravougaonika. Kao što smo rekli imena entiteta će uvek biti u jednini: OSOBA a ne OSOBE. Koriš ćenjem jednine imenica dobijamo poboljšanje konzistentnosti standarda imenovanja i omogućava 'čitanje' dijagrama kao seta deklarativnih iskaza o primercima entiteta.
Slika 13 U oblasti ključeva je atribut 'Sifra Osobe' a atributi u oblasi podataka su 'Ime i Prezime', 'Adresa' i dr. Dakle, skup atributa koji identifikuju entitet zovu se klju čevi tj. ključni atribut je atribut koji sam za sebe ili u kombinaciji sa drugim klju čnim atributima formira jedinstven identifikator entiteta. U principu se definišu dve vrste identifikatora: Primarni ključ i alternativni ključ. Osnovno pitanje koje se postavlja ovde je kako izbrati primarni ključ kojim se identifikuje jednoznačno entitet. Izbor ključa nekog entiteta može biti nekoliko atributa ili kombinacija atributa koji bi mogli biti korišćeni kao primarni ključevi. Atributi ili grupe atributa koji mogu biti izabrani kao primarni ključevi nazivaju se 'atributi kandidati za klju č'. Kandidat za ključ mora jedinstveno identifikovati svaki primerak entiteta. Iz toga sledi da nijedan deo primarnog klju ča ne može biti NULL, odnosno prazan ( empty) ili nedostajući (missing). Ako pogledamo entitet OSOBA ona ima sledeće atribute: • • • • • •
Sifra osobe Pezime i Ime Adresa JMBG Datum rodjenja i Pol
Uzmimo da je, prvi kandidat za klju č atribut 'Sifra Osobe' zato što je jedinstven za svaku osobu. Atribut JMBG bi mogao biti kandidat za ključ ako su naše pretpostavke o jedinstvenosti broja korektne, medjutim, verovatan je slučaj da neće sve osobe imati JMBG jer koristi ćemo usluge i stranaca. Mada se na prvi pogled činilo da ovaj atribut može biti kandidat za ključ, ostavićemo ga postrani. Atribut 'Ime i Prezime' ne bi mogao biti dobar kandidat za ključ. Možemo imati dva Zorana Petrovića. Kombinacija 'Ime i Prezime' i 'datum-rodjenja' bi mogao biti kandidat za ključ (osim ako nemamo npr. dva Zorana Petrovića rodjena istog dana ). Premda je to verovatno nekorektno, hajde da uzmemo u obzir za nas primer da će kombinacija 'Ime i Prezime' i 'datum-rodjenja' odredjivati specifičnu osobu. Tako smo našli našeg drugog kandidata za ključ-kombiaciju 'Ime i Prezime' i 'datum-rodjenja'. Dakle, sada imamo dva kandidata za klju č-jedan je 'Sifra Osobe' a drugi je grupa atributa koja sadrži atribute 'Ime i Prezime' i 'datum-rodenja' i potrebno je izabrati primarni ključ. Osnovna pravila za izbor primarnog ključ su: •
•
•
Prvo i najvažnije prilikom izbora primarnog klju ča je naći neki atribut koji neće menjati vrednost za vreme 'života' svakog primerka entiteta, jer, ključ odredjuje identitet primerka entiteta(ako se promeni ključ, to je već drugi primerak). Drugo, tražite razumno male klju čeve. Ako se može naći jedan atribut, imamo generalno gledeno, dobar ključ. Ako je potrebno koristiti ključ koji je kombinacija ključeva iz drugih entiteta obezbedite da svaki deo ključa zadovoljava prva dva principa. Treće, izbegavati upotrebu 'inteligentnih' ključeva, na primer, gde struktura brojeva identifikuje grupisanje, lociranje, klasifikaciju, datume itd. Ovo ćemo obrazložiti kasnije.
Na osnovu ovako obrazloženih elemenata za izbor primarnog ključa bira se za entiteta 'OSOBA' atributa 'Sifra Osobe' kao primarni ključ jer zadovoljava sva tri kriterijuma.
Na slici 14 u ERwin notaciji primarni ključ se nalazi iznad crte u oblasti klju čeva. Medjutim, kandidati za ključ koji nisu izabrani za primarne ključeve mogu se definisati kao alternativni ključevi(Akn). Alternativni ključevi(AKn) je atribut ili grupa atributa koji jedinstveno identifikuju primerke entiteta. ERwin generiše jedinstven indeks za svaki alternativni ključ. O indeksima će kasnije više biti reči. Ako je potrebno definisati indeks nad atributom ili grupom atributa koji ne identifikuju jedinstveno prmerke entiteta definiše se tzv. Inversion Entry(IEn) indeks. Tako naš primer sa slike 5 poprima slede ći izgled ako atribute 'Ime i Prezime' i 'datum-rodjenja' prihvatićemo kao složen alternativni ključ.
Slika 14
2.3. Atributi i normalizacija Prilikom definisanja atributa kao što smo rekli pristupa se modeliranjem podataka odozdo na gore(Bottom Up) i on je veoma prihvatljiv za početnike u ovoj oblasti jer polazi od opipljivih informacija definisanih na dokumentima i u kartotekama. Osnovu za ovaj na čin modeliranja podataka čini analiza funkcionalnih zavisnosti i postupak normalizacije.
Proces normalizacije modela je uklanjanje svih struktura koje stvaraju redundansu podataka. Slogan normalizacije je : Jedna č injenica na jednom mestu.
Da bi se mogao opisati postupak normalizacije, potrebno je prethodno opisati pojam funkcijske zavisnosti.
Ako je svakoj vrednosti atributa A u relaciji R priključena samo jedna vrednost atributa B u istoj relaciji, onda je atribut B funkcijski zavisan od atributa A asocijacijom tipa 1. Funkcijska zavisnost se može definisati izmedju složenog klju č(više atributa) i jednostavnog atributa. Ako je moguće svakom paru vrednosti atributa A i B relacije R priklju čiti tačno jednu vrednost C iste relacije, tada je atribut C funkcijski zavisan od sastavljenog atributa A i B. Na osnovu definicije funkcijske zavisnosti potpuna funkcijska zavisnost se definiše. Atribut B je potpuno funkcijski zavisan od atributa A iste relacije, ako je funkcijski zavisan od atributa A, a ne od nekog sastavnog dela atributa A. Postupak normalizacije podataka ima za cilj pravilno dizajniranje baze podataka koja ima strukturu, kojom osigurava da u radu sa njom ne će biti neželjenih anomalija, kao što su npr.,
uništavanje odredjenih podataka ili neuskladjenost izmedju memorisanih podataka kao posledica ažuriranja baze podataka. Dakle, postupak koji dovodi dizajnera baze podataka do željenog rezultata naziva se "normalizacija" baze podataka. Drugim rečima postupak normalizacije predstavlja transformaciju početnog entiteta u jednu ili
više korektnih entiteta ili veza u kojima su svi atributi potpuno funkcijski zavisni od klju ča, a medjusobno funkcijski nezavisni. Definisanje prve normalne forme( 1NF)
Posmatrajmo entitet OSOBA sa slike 15. Možemo li uočiti grešku?
Slika 15 Entitet OSOBA Prevedimo zbog lakšeg razumevanja entitet OSOBAa u tabelu sa definisanim primerom. OSOBA Sifra Osobe
E1 E2 E3 E4 E5
Ime
Toma Ljubisa Boban Jovan Mirjana
Adresa
Imena dece
Beograd Cacak Prizren Nis Beograd Slika 16
Jana Aleksandar, Vladimir, Stefan Lana -
Problem je u atributu "Imena dece". U predhodnim poglavljuma u vezi entiteta i atributa naglasili smo da sva imena moraju biti u jednom primerku, tj u jedan atribut ne možemo da smestiti više imena dece. Nije nam poznato koliko imena dece treba zapamtiti, koliko je prostora za to potrebno i što onda ako ima više imena nego prostora ? Dakle, ovakva tabela krši prvu normalnu formu. Da bi popravili prethodnu tabelu moramo na neki način ukloniti listu dece OSOBA. Jedan način je da to uradimo je prikazan na slici 17.
Slika 17 OSOBA Sifra Osobe E1
E2 E3 E4 E5
Ime
Adresa
Toma Ljubisa Boban Jovan Mirjana
Beograd Cacak Prizren Nis Beograd
DETE Sifra Osobe E1
E2 E2 E2 E4
rbr C1 C1
Ime deteta
Jana Aleksandar C2 Vladimir C3 Stefan C1 Lana Slika 18. Primer promerka entiteta za Sliku 17.
Otkrili smo grupu podataka koji se ponavljaju i od njih smo stvorili entitet time smo u činili prvi korak prema normalizovanom modelu. Takodje, 1NF nastaje i kod višeznačne upotrebe istog atributa kao što je pokazano na slici 19.
Slika 19 OSOBA Sifra Osobe E1
E2 E3 E4 E5 E6
Ime
Toma Ljubisa Boban Jovan Mirjana Petar
Adresa
Beograd Cacak Prizren Nis Berklej Negotin
Pocetak ili rada 10.01.1998 22.05.1997 15.03.1997 30.09.1998 22.04.1997 15.10.1998
kraj
Slika 20. Primerak entiteta sa Slike 19. Problem je u atributu početak ili kraj rada koji predstavlja jednu od dve činjenice, početak rada u firmi i prestanak rada u firmi. Nismo u mogu ćnosti da otkrijemo što taj datum predstavlja kao što nismo u mogućnosti da zapamtimi oba datuma iako su nam možda oba poznata. Rešenje nije u tome da atribut može da sadrži dve činjenice već da imamo dva atributa koji govore o početku i završetku rada. Potrebno je da ugradimo dva atributa koji nose dve različite informacije. Slika 21 i 22.
Slika 21
OSOBA Sifra Osobe
E1 E2 E3 E4 E5 E6
Ime
Toma Ljubisa Boban Jovan Mirjana Petar
Adresa
Beograd Cacak Prizren Nis Beograd Negotin Slika 22
Pocetak rada
Kraj rad
10.01.1998 22.05.1997 15.03.1997 30.09.1998 22.04.1997 15.10.1998
30.11.1998
Oba pogrešna prethodna rešenja ne zadovoljavaju prvu normalnu formu. Menjajući strukturu možemo biti sigurni da se jedan atribut pojavljuje samo jedanom u entitetu i da nosi samo jednu činjenicu. Dakle, prva normalna forma je ako svaki od njegovih atributa ima jedno zna čenje i ne više od jedne vrednosti za svaki primerak. Ako ste sigurni da svi entiteti i atributi ne nose više činjenica učinili ste veliki korak u tome da model zadovoljava prvu normalnu formu. Drugim re čima entitet zadovoljava prvu normalnu formu ako svi domeni sadrže samo atomaske vrednosti. CASE alat ERwin prihvata bilo koje ime za definiciju entitetat ili atributa ali postoje izuzeci: •
•
•
ERwin će obavestiti o ponovnom korišćenju imena entiteta zavisno o postavci opcije o jedinstvenom imenu. ERwin će obavestiti o ponovnom korišćenju imena atributa osim ako je to ime rolename. Kada je pridruženo rolename za atribut može biti korišćeno u različitim entitetima. Erwin neće dozvoliti ulazak prenesenih ključeva u entitet više nego jednom osim ako mu je dodeljeno rolename svaki put.
Sprečavajući vas u višestrukom koriš ćenju istog imena ERwin vas vodi da svaki podatak smestite tačno na jedno mesto. Druga normalna forma
Entitet A zadovoljava drugu normalnu formu ako zadovoljava prvu i ako svaki atribut koji nije ključ potpuno zavistan od primarnog ključa. Za opis ove definicije posmatrajmo primer višestrukog pojavljivanja istih činjenica. Pokažimo ovu trvrdnju na jednom primeru. Ako bi smo u entitet DETE stavili atribut 'Adresa' uočili bi da ovaj atribut zavisi od dela klju ča entiteta DETE(Sifra Osobe) a ne od celog klju č entiteta DETE. Da bi smo zadovoljili drugu normalnu formu potrebno je prebaciti atribut 'Adresa' u entitet OSOBA. Dakle, entitet krši drugu normalnu formu ako podatak može biti prona đena znajući samo deo ključa entiteta. Može da nastane greška druge normalne forme ako postavite neki atribut nekorektno ali ne postoji algoritam koji bi bez još dodatnih informacija pored onih u modelu otkrio grešku. U entitetnom dijagramu Erwin ne može znati da ime koje ste dodelili atributu može predstavljati listu objekata (primer imena dece ). Stoga ne postoji direktna garancija da model zadovoljava prvu normalnu formu. DBMS šema funkcija od Erwina ne podržava podatak tipa lista jer šema baze je u fizičkom relacionom sistemu tako da se i na ovom nivou mogu sprečiti greške. Sprečavajući višestruko pojavljivanje prenesenih ključeva bez rolenamea Erwin vas podseća da razmisklite o onom što struktura predstavlja. Ako se preneseni klju č pojavljuje dvaput u istom entitetu onda se treba zapitati: Da li mi pamtimo klju čeve dva odvojena primerka(instance) drugog entiteta ili oba ključa predstavljaju istu instancu. Kada preneseni ključevi predstavljaju različite instance odvojen rolname imena su potrebna.
Ako dva uvezena ključa predstavlkjaju istu instancu verovatno negde postiji greška pri normalizaciji. Preneseni klju č koji se dvaput pojavljuje u entitetu bez rolname predstavlja redundantnu vezu u modelu. Treća normalna forma
Entitet A zadovoljava treću normalnu formu, ako zadovoljava drugu normalnu formu, i ako atribut koji nije ključ ne zavisi od drugog atributa koji nije ključ. Ako činjenica može biti pronađena znajući neku vrednost entiteta koja nije ključ narušena je treća normalna forma. Dakle, definicija treće normalne forme je: Entitet zadovoljava treću normalnu formu ako svaki aribut koji nije ključ zavisi o ključu, čitavom ključu i ničemu drugom osim ključa. Na primer, bila bi povređena treća normalna forma ako u entitetu dete ugradimo atribute starosti i datum rođenja kao atribute koji nisu ključevi. Starost je zavisna od datuma ro đenja i možemo je izračunati na osnovu današnjeg datuma i datuma rođenja. Pored ovih formi postoje i četvrta peta i Boyce-Codd-ova forma. Njihova upotreba zavisi od skupa transakcija koje se trebaju izvršiti(vidi Š]).
2.4. Definisanje atributa Definisanje atributa se izvodi u tri koraka: • • •
Identifikacija/ alociranje atributa Izvršenje revizije atributa i Definisanje atributa
Identifikacija atributa definiše se na osnovu zahteva korisnika, poslovne dokumentacije i dokumentacije za razvoj IS. Alociranje atributa se izvodi u zavisnosti da li je atribut zavisan od ključa ili je opisni. Revizijom atributa se eliminiše višestruko nastupanje vrednosti atributa pojedinog entiteta i pritom se za svaki atribut pitamo: •
•
• • • •
Da li je potrebno tražiti višestruke vredosti za isto pojavljivanje entiteta(sifra odelenja, Naziv odelenja) Da li atribut može pripadati nekom drugom entitetu(Npr.Broj, Prezime, Naziv projekta) Da li postoje atributi koji ne nastupaju za neko pojavljivanje entiteta Da li postoje izvedeni atributi(koje treba ili ostraniti ili dodati) Da li postoje atributi bez entiteta Prikladnost identifikatora/ ključa
Mogu se za atribute definisati : Set vrednosti pravila dozvoljenih vrednosti Nill vrednosti Dosledno značenje tj. medjusobno isključivanje Atribut : Pol ; Vrednost: muškarac, žena • • • •
•
2.5. Prikaz logičkog modela Logički nivo modela podataka definiše ER model podataka prikazan na sl.... kojim se definišu entiteti, atributi referencijalni integritet i kardinalnost. RADNO MESTO pripada / OSOBA Sifra osobe Sifrarm rasporedjen Sifra jezika Prezime (IE1) Nazivrm Naziv jezika Ime (IE1) Sifrarm (FK) vazi / J MBG (AK2) odosi se P rukov (FK) Datum zaposlenja SARTIFIKAT Plata Sifra osobe (FK) je dat / Stimulacija Sifra jezika (FK) poseduje Sifra odelenja (FK) Pol Stepen znanja Pol Vrsta
ODELENJE
JEZIK
MUSKARAC
Sifra osobe (FK)
Sluzio vojsku
Prezime devojacko
prima / je primio
Vrsta
KONSULTANT
ZENA
Sifra osobe (FK)
zaposljava / radi
rukovodi / je rukovodioc
Sifra odelenja Naziv odelenja Mesto ISPLATA
Sifra osobe (FK) rbr Datum isplate Iznos
REDOVNI
Sifra osobe (FK)
Sifra osobe (FK)
Broj sati
Vrsta posla
3. Definisanje poslovnih pravila Realni svet, opisan objektima, vezama izmedju njih i osobinama, ograni čen je u nekom prostoru pa je i u modelu podataka potrebno definisati ograničenja vezana za: • •
Strukturu modela objekti-veze i Ograničenja koja se posebno definišu
Definisana ograničenja definišu tzv. poslovna pravila.
Ograničenja definisana strukturom model objekti-veze
Ova ograničenja vezana su za: •
•
•
•
Identifikaciju entiteta -gde je nemoguće da postoje dva primerka entiteta u istom tipu entiteta takva da imaju istu vrednost atributa koji čine identifikator tj. ne postoje dva tipa
entiteta koji imaju isti skup atributa kao identifikator. Ograničenje postojanja(Egzistencijalna zavisnost) jednog tipa objekta u zavisnosti od drugog tipa objekta Ograničenje mogućnosti identifikacije jednog objekta bez poznavanja identifikatora nekog drugog objekta Specijalni tipovi veze kojima se definiše podtipovi o ču će kasnihe više bite reči.
Ograničenja koja se posebno definišu
Ograničenja koja se posebno definišu mogu se podeliti na: •
Ograničenja na vrednost atributa i to: Tip podatka(character, numeric, boolen ) Dužina podatka Opseg dozvoljenih vrednosti i to kao Lista vredosti koji se definišu eksplicitnim navodjenjem svih dozvoljenih vrednosti (Klasa projekta kao IN Š'A,B,C']. sl...). Opseg dozvoljenih vrednosti gde atributi objekata i veza uzimaju vrednosti iz domena ali uz postavljena ograničenja na ove vrednosti tako da atribut može poprimiti samo uži skup vrednosti iz domena( npr. BETWEEN 10 AND 200) • • •
•
•
•
Ograničenja na kardinalnost veza izmedju entiteta roditelja i entiteta deteta i to: Kardinalnost tipa(Zero or OneŠZ]) gde se jedan primerak jednog tipa entiteta pridružuje nijednom ili jednom primerku drugog tipa. Kardinalnost tipa(Zero, One or More) gde se jedan primerak jednog tipa entiteta pridružuje nijednom, jednom ili većem broju primeraka drugog tipa. Kardinalnost tipa(One or MoreŠP]) gde se jedan primerak jednog tipa entiteta pridružuje najmanje jednom ili većem broju primeraka drugog tipa. Kardinalnost tipa konktretne vrednosti(Exactly) gde se jedan primerak jednog tipa entiteta pridružuje tačno definisanom broju drugog tipa entiteta. Sveobuhvatnost objekta u vezi vezana za kardinalnost entiteta dete prema entitetu roditelj:: Totalno učešće gde svi primerci jednog tipa entiteta učestvuju bar u jednoj vezi (No Nulls) PARCIJALNO(delimično) učešće gde pojedini primerci entiteta učestvuju u vezi(Nulls Allowed) •
•
•
•
•
•
•
3.1. Prikaz i verifikacija kardinalnosti veza Veze (relationships) imaju osobinu koja se zove kardinalnost koja definiše “koliko mnogo” instanci entiteta roditelja je povezano sa “koliko mnogo” instanci entiteta deteta. Simbol veze (relationships) u obliku tačke na kraju linije sa strane deteta pokazuje kardinalnost u grafi čkom obliku. Različiti simboli se koriste da označe 'koliko mnogo'. U svakoj definisanoj vezi entitet roditelj prema entitetu dete može biti u vezi: 0,1 ili više (veza nije ozna čena nikakvim simbolom) 1 ili više (označava se sa P sa strane entiteta dete) 0 ili 1 (označava se sa Z sa strane entiteta dete) Tačno n, gde je n broj (označava se definisanim brojem n sa strane entiteta dete). • • • •
Veza roditelj-dete
Veza dete-roditelj
Slika 23
Entitet dete prema entitetu roditelj može biti u vezi: •
•
0 ili 1 (dozvoljena null vrednost stranog ključa i ovakav slu čaj je moguć samo za neidentifikujuće veze, i obeležava se sa strane roditelja). 1 (nije dozvoljena null vrednost stranog ključa, i nema posebni simbol u modelu)
3.2. Definisanje referencijalnog integriteta Budući da neki (ili svi) od prenesenih klju čeva u ne-identifikujućoj vezi nisu deo primarnog ključa 'deteta', dete se ne može identifikovati preko roditelja. Ova razlika je veoma važna kada trebamo podržavati integritet relacija izmedju roditelja i deteta pod operacijama ubacivanje, brisanja i ažuriranja. Ovo je poznato kao problem refrencijalnog integriteta. Dakle sreli smo se sad dva pojam: integritet entiteta i referencijalni integritet. Integritetom entiteta onemogućuje se pojava da se mogu uneti dva entiteta sa istom vrednošću primarnog ključa ili da je ključ NULL podatak i vezan je za identifikujuće veze. Referencijalni integritet entiteta zahteva da unesena vrednost atributa odgovara vrednosti atributa koji je primarni ključ drugog entiteta.Referencijalni integritet opisuje ponašanje modela kada usled operacija održavanja dolazi do narušavanja kardinalnosti veza. Ovo ponašanje modela su tzv. strukturna dinami čka pravila integriteta(SPI) koja se definišu za strukturna ograničenja u bazi podataka.
3.3. Identifikacija poslovnog domena Atributi uzimaju vrednost iz skupa mogućih vrednosti. Ovi skupovi se nazivaju domenima. Pošto je domen skup, u njemu se svaka vrednost javlja samo jednom. Svi elementi skupa se medjusobno razlikuju. Atribut nema svojstvo skupa, jer se odredjene vrednosti mogu ponavljati, pa nije moguća jednoznačna identifikacija pojedinih elemenata. Domen se može definisati kao bazni domen i specijalizovani(tipski). Svaki domen se tretira kao podtip baznog domena, gde se pod baznim domenima podrazumevaju tipovi podataka(po IDEF1X standaru to su Character, Numeric ili Boolen) koji postoje u standardnim programskim jezicima (ceo broj, niz karaktera i sli čno) i samim tim nasleđuje karakteristike i operacije koje se mogu definisati nad ovim domenima. Bazni domen definisan je odgovarajućim domen pravilima(domain rules) kojim se definiše moguće vrednosti u domenu. Definišu se dva osnovna pravila i to lista vredosti i rang domena. Lista vrednosti je skup pojedinačnih vredosti koji se definišu eksplicitnim navodjenjem svih
dozvoljenih vrednosti(IN Š'A,B,C']). Rang domena definiše se tako da vrednosti iz domena se uzimaju iz užeg skupa vrednosti(BETWEEN 10 AND 200). Dakle, specifiraju se dozvoljene vrednosti domena koje se definišu validacionim izrazima pomoću ključnih reči BETWEEN, IN, i preko relacionih operatora (operatora poređenja <,>,=,...) i slično.
Akcije koje se preduzimaju kada je narušeno zadato ograni čenje gotovo uvek su prikazivanje odgovarajuće očigledne poruke ili jedne opšte poruke definisane validacionim nazivom(slika.....).
Specijalizacijom baznih domena(podtip baznog domena) iskazuje se semantika realnog sistema,
pa se oni nazivaju i semanti č ki domeni . Tako na sl.... je prikazan spisak domena i odgovarajućih tipova podataka za definisane domene. U oviru kolone naziv domena(vidi sl....) definiše se default domen() koji se ERwin predifinisani domen koji se automatski setuje i svi ostali domeni nasledjuju osobine ovog domena koji je roditelj. Default specificira vrednosti koje će biti insertovane u kolonu. Validaciono pravilo(validation rule) specificira fiksiranu listu validacionih vrednosti(valid values) Na sl... takodje su prikazane i tzv default vrednosti sa odgovarajušim default nazivima. Default vrednost je specificirana vrednost koja se ubacuje(insert) u kolonu kada se unose podaci. Takođe, pretpostavlja se da svaki domen uklju čuje u sebe i nula vrednost , specijalnu vrednost koja se dodjeljuje nekom atributu objekta kada se njegova vrednost ne poznaje. Da bi smo iskazali da neki atribut ne može da ima nula vrednost uvodi se i specifi čan predikat NOT NULL, preko koga se definiše odgovarajući domen. Osnovna veza izmedju atributa i domena je u tome što se atribut koji je identi čan sa svojim domenom može koristiti kao ključ entiteta.
3.4. Identifikacija operacija Manipulaciju podataka u modelu podataka omogu ćuju operatori koji mogu biti navigacioni i specifikacioni. Operatori omogućuje pristup svakom podatku u modelu podataka koristeći predhodno definisane akcije definiše se tabela SPI za objekte, odnosno za operacije insert (ubacivanje), delete (brisanje) i update (ažuriranje). Referencijalni integritet se definiše za svaki vezu, posebno sa strane entiteta roditelj, a posebno sa strane entiteta dete i to za operacije održavanja: ubacivanje novog sloga, brisanje sloga, ažuriranje sloga(IRD). Operacija insert(ubacivanje) omogućuje sledeća dodavanja podataka: Kreirati objekat ali proveriti da li vrednost je klju ča objekta moguća ili već postoji objekat sa tom vrednošću Kreirati vezu ali proveriti da li postoje objekti sa datim vrednostima klju č Dadati vrednost objektu ili vezi ali proveriti da li je ta vrednost dozvoljena •
• •
Operacija update(ažuriranje) omogućuje sledeća izmene podataka: Izmena vrednosti neključnog atributa objekta Izmeniti vrednost atributa koji je deo ključ znači izmeniti tu vrednost u svim objektima i u svim vezama koji su povezani sa objektom Izmeniti vrednost neključnog atributa u vezi. Ne može se menjati vrednost ključnog atributa veze ako nova vrednost ne postoji kao vrednost ključnog atributa objekta Izmeniti vrednost atributa objekta koji je deo ključa znači izmeniti tu vrednost u svim slabim objektima u kojima je ta vrednost spuštena kao deo ključa. • •
•
•
Operacija delete(brisanje) omogućuje sledeća brisanja podataka: Brisati objekat i veze u kojima se vrednost ključa objekta pojavljuje Brisati veze u tipu veze Brisati objekat i sve objekte u slabim objektima čije postojanje zavisi od datog objekta • • •
Nad ovako definisane dogadjaje moguće je definisati sledeće akcije: 1. RESTRICT (R)-odbijanje operacije; 2. CASCADE(C)-prosleđivanje operacije na vezni entitet;
3. DEFAULT(D)- ukoliko se naruši kardinalnost veza primerak entiteta se povezuje sa definisanim “default” objektom vezanog entiteta;
4.SET NULL (SN)- ukoliko primerak entoteta “visi “ u sistemu, atribut koji uspostavlja vezu setuje se na null vrednost.
Posmatrajmo primer prikazan na slici 25.
Slika 25 U ovom primeru postoji jaka veza između PROJEKTa i ANGAZOVANJE. Primarni klju č entiteta PROJEKTa postaje deo primarnog ključa ANGAZOVANJE . Pravila kardinalnosti govore da za svaku instancu ANGAZOVANJE postoji jedna instanca PROJEKTa. Priroda jake relacione veze specificira da ANGAZOVANJE je egzistencijalno zavistan od PROJEKT-a. Šta se može desiti ako mi obrišemo jednu instancu PROJEKT-a? Mi bismo, takođe, hteli obrisati sve instance ANGAZOVANJE čiji je deo njihovog nasleđenog ključa iz obrisane instance PROJEKT-a. Zašto ? Zbog toga što je deo klju ča postao NULL vrednost, a NULL vrednost nije dozvoljena kao vrednost bilo kog dela primarnog ključa. Pravila brisanja
Mi imamo dva izbora a to je da prvo možemo obrisati svaku instancu ANGAZOVANJE čiji je nasleđeni ključ obrisana instanca PROJEKT-a, ili drugi izbor sprečiti brisanje PROJEKT-a ako postoji bilo koji ANGAZOVANJE čiji bi deo primarnog ključa bio nekompletan. Ove situacije koje su u vezi sa pravilima brisanja nazivaju se CASCADE i RESTRICT i odluka koje se pravilo koristi biće definisano u modelu. CASCADE prikazuje da sve instance ANGAZOVANJE koje će biti obuhvaćene brisanjem instance PROJEKT-a biće takođe obrisane.
Slika 26
RESTRICT prikazuje da PROJEKT prikazuje da instanca PROJEKT-a ne može biti obrisana dok sve instance ANGAZOVANJE koji imaju nasle đeni ključ ne budu obrisane. Ako postoji neki nasleđeni, brisanje je “ograničeno”.
Slika 27 Zašto želimo da ograni čimo brisanje? Jedan rezon može biti da mi želimo da znamo i druge činjenice o ANGAZOVANJE kao što su “Datum Angazovanja” na projektu. Ako mi imamo kaskadno brisanje, izgubićemo ovu dopunsku informaciju. Izuzev ograničenoig brisanja, ako mi odlučimo da ANGAZOVANJE nije egzistencijalno ili identifikaciono zavistan od PROJEKT-a, možemo promeniti referencijalni integritet upotrebom slabe relacione veze između dva entiteta.
Slika 28 Uovom slučaju, IRD situacija je bitno razli čita. Kao što je ve ć poznato, spoljnom ključu koji je “donešen” preko slabe veze su dozvoljene NULL vrednosti. Tako za slabe relacione veze imamo treću opciju koja se zove Set-Null. Set-Null pokazuje da ako je instanca PROJEKT-a obrisana ali je klju č PROJEKT-a zadržan kao
podatak u entitetu ANGAZOVANJE. Brisanje nije kaskadno kao predhodnom primeru i mi ne možemo zabraniti brisanje. Mi postavljamo ključ kao NULL vrednost. Prednost ovog pristupa je da mi možemo sačuvati informacije o ANGAZOVANJE dok je efektivna veza između PROJEKT i ANGAZOVANJE prekinuta.
Slika 29 Pravila za ubacivanje i zamenu
Upotrebom IRD pravila je dodatan način da snimimo pravila poslovanja. Odluka da se upotrebljava kaskada ili set-null odražava se na poslovne odluke o održavanju “istorije” znanja o relacionoj vezi prestavljene preko prenesenih ključeva. Kao što smo videli, pravila brisanja(DELETE) upravljaju šta će se desiti u bazi podata kada se red u tabeli obriše. Pravila za ubacivanje(INSERT) i ažuriranje(UPDATE) upravljaju šta će biti kada je red u tabeli dodat ili ažuriran. Ažuriranje je, u suštini, ubacivanje ali sa nekim dodatnim pravilima Za ubacivanje, red može biti dodat samo ako svi referencirani preneseni klju čevi odgovaraju postojećim redovima u referenciranim tabelama, izuzev ako relaciona veza to dozvoljava(P). Pogledajmo ovo na primeru OSOBA/TELEFON. TELEFON zadržava ključ odgovarajuće OSOBA. Zbog toga, mi ne možemo ubaciti TELEFON za koji ne postoji OSOBA. “P” na relacionoj vezi takođe govori nam da NE možemo ubaciti OSOBU bez ubacivanja TELEFONA.
Slika 30 Prikaz strukturnih pravila integriteta
Način prestavljanja tabele SPI za objekte je data na sledeći način(sl....): ime objekta roditelja-ime objekta deteta-ime veze- događ aj Događaji koji se mogu desiti su: • • • • • •
Ubacivanje roditelja (Parent Insert-PI) Brisanje roditelja (Parent Delet-PD) Izmena roditelja (Parent Update-PU) Ubacivanje deteta (Child Insert-CI) Brisanje deteta (Child Delet-CD) Izmena deteta (Child Update-CU).
Entitet roditelj
Entitet dete
ime veza
UPDATE
RADNIK
ISPLATA
Prima
RADNIK ZNA JEZIK
Rukovod i Zna
ODELENJE
RADNIK
pripada
JEZIK
ZNA JEZIK
govori
U-Cascade I-Restrict D-Cascade CU-Restrict PICDU-Set Null I- Set Null D- Set Null CU- Set Null PICDU-Restrict I-Restrict D-Restrict CUPICDU-Set Null I-Set Null D-Set Null CU-Set Null PICDU-Cascade I-Restrict D-Restrict CU-Restrict PICD-
Crticama su označena SPI koja ne treba definisati. Slika 31
INSERT DELETE D O G A D J A J I
