MODELIRANJE PODATAKA

Alempije Veljovi! Modeliranje podataka je nae 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 sadri skup informacija o prolosti i sadanjosti 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 podrka 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 sloenog apstraktnog tipa podataka(strukture podataka, ograni"enja i operacija). Izbor odgovaraju!eg CASE alata sam po sebi je manje ili vie 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 sloenog realnog sistema, bez obzira na to ko modeliranje vri. Mogu se dati samo opte metodoloke preporuke, opti metodoloki pristupi, kao pomo! u ovom sloenom poslu. Modeliranje podataka se oslanja na izvreno modeliranje procesa o "emu je vie bilo re"i u predhodnom poglavlju gde je definisan odgovaraju!i re"nik podataka. Ovde je na zadatak da izvrimo modeliranje podataka u dva koraka modeliranjem pogleda i modeliranjem zahteva. Osnova za modeliranje pogleda su definisani dijagrami tokova podataka do kojih se dolo 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 isuvie mala da bi imalo smisla obradjivati ih a ni suvie kompleksne da se nemogu sagledati u celosti. Dakle, modeliranje pogleda po"inje sa formiranjem okvirnog modela podataka pa pristupom proirivanja generiemo 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 vie re"i. Na osnovu izmodeliranih pogleda i izvedene njihove integracije pristupa se modeliranju zahteva kojima se precizno definiu 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 moe biti kori!ena od strane baze podataka i osoblja za razvoj aplikacija da definiu sistemske zahteve

Bolju komuniciju medjusobno i sa krajnjim korisnicima. Jasnu sliku o ograni"enjima referencijalnog integrita. Odravanje referencijanog integriteta je bitan u relacionom modelu jer su relacije kodirane implicitno. 'Logi"ke' sliku baze podataka koja moe 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 je potpuno odre#en ako su definisane slede!e tri komponente : STRUKTURU PODATAKA, kojima se definiu 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)-definie dinami"ku interpretaciju podataka kroz njihovu obradu(odravanje BP i pretraivanje) ima uticaja na definisanje fizi"kog nivoa modela i verifikaciju finalnog dizajna.

#. KREIRANJE ER MODELA
ER model definisan je entitetnim dijagramom kojim se definiu odgovaraju!i tipovi entiteta i uspostavljaju veze izme#u njih, kao i definisanje detalja vezanih za opis sadraja entiteta (atributi i njihove karakteristike). Strukturu podataka definisana je sa tri komponente: Entitete koji 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 vie prema vie. Veza prema podtipovima uspostavlja vezu izme#u entiteta i njegovih zavisnih, klasnih entiteta. Entitetni dijagram definie se entitetima (entities) i pritom svaki entitet ima svoje osobine tj. atribute (attributes) i sve je to povezano relacionim vezama (relationships). Entiteti se definiu i kao generalizovane hijerarhija o "emu !e kasnije biti vie re"i. Atributi imaju domene (domain) koji predstavljaju skup vrednosti ili interval vrednosti koje taj atribut moe da primi. Na slede!em nivou definiu 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 moe biti uklju"eno (sadrano). Relaciona veza definisana je prenesenim klju"em (foreign key) od roditelja ka detetu. Preneseni klju" moe imati i ime uloge (rolenames ) o "emu !e kasnije vie 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 glagoli. Entiteti i veze definiu 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 E-R KONCEPT ENTITET VEZA ATRIBUT ENTITETA ATRIBUT VEZE MESOVITI TIP ENTITETA-VEZA OBJEKTI POVEZANI VEZAMA LOKALNI PODMODEL Slika %

#.#. Identifikacija kandidate za entitete

Objekt posmatranja je sve to moemo 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. neto 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 definiemo ta je entitet posmatra!emo: %. Sli"nost ATRIBUTA koji mogu pripadati entitetu. Ovde se uo"ava zna"ajna razlika(sli"nost) u atributima to moe da ukae 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 RUKOVODI RUKOVODJEN NARUCUJE NARUCEN TIP ENTITETA RUKOVODILAC ODELENJE KUPAC PROIZVOD

5. Na osnovu atributa na dokumentima je mogu!e identifikovati entitete i veze kao npr.: ATRIBUT BOJA STAROST DATUM PITANJE BOJA CEGA? STAROST CEGA? DATUM CEGA? ODGOVOR PROIZVOD RADNIK NARUDZBE

6. Stvarni

fizicki objekti su objekti(entiteti) u modelu. Prikladni kandidati za entitete su: Fizi"ki objekti(vozilo, maina, jedinica opreme...) Osobe Mesta(adresa, koordinate na karti,...) Organizacije(preduze!a, zavod,...) Grupe/klase/tipovi(tip proizvoda, klasa poslova,...) Ugovori Potraivanja(narudbe, fakture,...) Prenos/ premetaj(stvari, vozila, novca,...)

 7. Atribut

Pridruenje(zadatak-osoba, vozila vonja,...) Pripadnost/"lanstvo( komponente-sastavi,...) 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 nie gde se definiu prvo neki opti tipovi entiteta pa zatim definiu podtipovi ovih entiteta(ENTITET-RACUN podtipove TEKUCI RACUN RACUN DUGOVANJA i CEKOVNI RACUN)

#.2. Identifikacija veze

Veza ili relacija predstavlja interakciju medu objektima tj. predstavlja znanje o njihovoj medjusobnoj povezanosti. Relacijama se definiu 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 definiu nezavisni i zavisni entiteti Definisanje zna"enja zavisnosti definisanjem referencijalnog integriteta Izvodjenjem varijacija zavisnosti nalaenjem optimalne i Izborom entiteta roditelj i entiteta dete Osnovni kriterijumi koji nas opredeljuju kako definisati vezu su: %.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 definiu 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

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

#.3. Definisanje entiteti i relacija Definisanje entiteta

Sa gledita obrade podataka realan svet sastoji se iz objekata(entiteta) posmatranja, koji su ili realni objekti (osoba, maina, vozilo, ku!a), apstraktni koncept(preduze!e, radno mesto), dogadjaj(prekraj, prevoz) ili odnosi (student-predmet, mu-ena). Entiteti su obi"no imenovani imenicama, kao 'OSOBA' ,'TELEFON', 'ZAPOSLEN'. Preciznije, moemo razmiljati 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 naeg daljeg posmatranja su slede!i tipovi entiteta: Nezavisni entiteti i Zavisni entitete Nezavisni entitet Nezavisni entitet je objekat koji ima jednu osobinu koja ga moe 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 moemo viseti na slici % entitet OSOBA predstavlja skup svih mogu!ih osoba sa kojima se komunicira. Svaki primerak entiteta OSOBA je jedan korisnik. Sa stanovita 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 vie puta za odre#eni nezavisni entitet. Asocijativne entitete koji predstavljaju vezu vie 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 vie puta za jedan entitet i koji se identifikuju preko nezavisnog. Npr. Entiteti OSOBA i ISPLATA. Za entitet ISPLATA se kae da je karakteristi"an entitet od entiteta OSOBA.To se moe videti na slici 4.
je primio prima

ISPLATA

OSOBA

Slika 4 Asocijativni entitet su sastavljeni od vie relacionih veza izme#u dva ili vie entiteta kao to se moe videti na slici 3. Npr. ako OSOBA zna vie JEZIKa i jedan JEZIK poznaje vie 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

j e dat/ poseduj e

vaz i/ odosise

JEZI K

SARTI FI KAT
Slika 5 Projektni entitet (designative) je sli"an asocijativnom entitetu, izuzev to nema sopstvene atribute.U predhodnom primeru, SERTIFIKAT se moe 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 definiu se i veze izmedju entiteta. Veza je asocijacija izmedju dva ili vie 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 vie 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 vie 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 vie prema vie. To je veza u kojoj je jedan entitet povezan sa 0,% ili vie 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 vieklasnih 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 definie atribut diskriminator u entitetu koji se specijalizira koji obezbe#uje ekskluzivnost veze. Ako se diskriminator ne definie veza se moe smatrati neekskluzivnom. CASE alat ERwin definise gore opisane veze preko toolbox-a:

Slika 6

Identifikuju!e i ne-identifikuju!e veze

U dosadanjim prikazima veze smo definisali u tzv IDEF%X 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 definie 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). Ent i t etA Kl j uc at r i but aA
Ent i t etr odi t el j

I dent i f i kuj uca vez a N az i v vez e

Ent i t et-B Kl j uc at r i but aA( FK) Kl j uc at r i but aB

Ent i t etdet e

Slika 7 Identifikuju!a veza Ako posmatramo primer sa slike 8 definisa!emo re"enicu gde je glagol <koristi> veza izmedju entiteta OSOBA i TELEFON. OSOBA <koristi> vie TELEFONa U ovom primerku veze izmedju dva entiteta je izabrana tako da ima oblik koji poznat kao % prema "vie". To zna"i da jedan (i samo jedan) primerak entiteta osoba(entitet roditelj) je povezan sa vie primeraka entitet telefon(entitet dete). Identifikuju!a veza nam govori da ne moe biti definisan primerak entiteta TELEFON ako ne postoji namanje jeda primerak entiteta OSOBA. Notacije "vie" ovde ne zna"i da je ovde bilo vie od jednog primerka 'deteta' povezanog za datog 'roditelja'. Umesto 'vie' u 'jedan prema vie' kao to je upotrebljeno gore realno zna"i da je nijedan, jedan ili vie primeraka entiteta-deteta povezano sa jednim roditeljskim entitetom. Na osnovu definisane re"enice kori!enjem glagolske fraze <koristi> definie primer relacije izmedju entiteta roditelj OSOBA i entiteta dete TELEFON (Slika 8) TELEFON koristi OSOBA

P Slika 8 Primer relacije Ako svaki primerak entiteta dete moe se jedinstveno identifikovati bez znanja veze sa primerkom entiteta roditelj, onda se takva veza definie 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 moe 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.

Ent i t et A Kl j uc ent i t et aA Ent i t etr odi t el j

Naz i v vez e

O bavez na nei dent i f i kuj uca vez a

Ent i t et B Kl j uc at r i but aB Kl j uc at r i but aA( FK) Ent i t etdet e

Slika 9 Neidentifikuju!a obavezna veza

Ako je veza neobavezna(Nulls Allowed ili Optional), tada dete niti je egzistencijalno niti identifikaciono zavisno ali potuje tu vezu. Ent i t et A Kl j uc at r i but aA Ent i t etr odi t el j

Naz i v vez e

O pci ona nei dent i f i kuj uca vez a

Ent i t et B Kl j uc at r i but aB Kl j uc at r i but aA( FK) Ent i t etdet e

Slika %0 Neidentifikuju!a neobavezna veza ERwin koristi romb (diamond) da nazna"i slu"aj egzistencijalne i identifikacione zavisnosti. Romb moe postojati samo u slabim vezama (poto je jaka veza u oviru primarnog klju"a, a primarni klju" ne moe 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 spoljanji klju".

#.4. Izrada ER modela

Izrada entitetnog dijagrama moe 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 vie od %5) po grupama traiti dodatne entitete(posmatraj najvaniji entitet) po potrebi rearanirati grupe Kreirati radne entitetne dijagrame Pronadji roditelje Identifikuj zavisne entitete Identifikuj posebno pod -tip entitete Verifikuj entitete Izvriti optu 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

JEZIK

pripada / RADNO MESTO rasporedjen P OSOBA je dat / poseduje

zaposljava / ODELENJE radi prima / je primio rukovodi / je rukovodioc

vazi / odosi se SARTIFIKAT

ISPLATA

Pol

Vrsta

MUSKARAC

ZENA

KONSULTANT

REDOVNI

Slika %2

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.#. 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 moe 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

domene koji prestavljaju skup vrednosti ili interval vrijednosti koje taj atribut moe 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 sloen. Atributi mogu biti definisani u oblasti klju"eva(primarni klju") ili u oblasti podataka(Slika %3) Kao to se na slici %3. 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 poboljanje konzistentnosti standarda imenovanja i omogu!ava '"itanje' dijagrama kao seta deklarativnih iskaza o primercima entiteta.

Dakle, svaki entitet ima svoja obeleja koja se nazivaju atributi. Atributi imaju

Slika %3 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 definiu 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 moe 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 moe 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 nae 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 moe biti kandidat za klju", ostavi!emo ga postrani. Atribut 'Ime i Prezime' ne bi mogao biti dobar kandidat za klju". Moemo 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 nali naeg 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 sadri atribute 'Ime i Prezime' i 'datum-rodenja' i potrebno je izabrati primarni klju". Osnovna pravila za izbor primarnog klju" su: Prvo i najvanije 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, traite razumno male klju"eve. Ako se moe 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 obrazloiti kasnije.

Na osnovu ovako obrazloenih elemenata za izbor primarnog klju"a bira se za entiteta 'OSOBA' atributa 'Sifra Osobe' kao primarni klju" jer zadovoljava sva tri kriterijuma.

Na slici %4 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 generie jedinstven indeks za svaki alternativni klju". O indeksima !e kasnije vie biti re"i. Ako je potrebno definisati indeks nad atributom ili grupom atributa koji ne identifikuju jedinstveno prmerke entiteta definie 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 sloen alternativni klju".

Slika %4

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 %. Funkcijska zavisnost se moe definisati izmedju sloenog klju"(vie 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 definie. 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 neeljenih anomalija, kao to su npr., unitavanje odredjenih podataka ili neuskladjenost izmedju memorisanih podataka kao posledica auriranja 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

vie korektnih entiteta ili veza u kojima su svi atributi potpuno funkcijski zavisni od klju"a, a medjusobno funkcijski nezavisni. Definisanje prve normalne forme("NF) Posmatrajmo entitet OSOBA sa slike %5. Moemo li uo"iti greku?

Slika %5 Entitet OSOBA Prevedimo zbog lakeg razumevanja entitet OSOBAa u tabelu sa definisanim primerom. OSOBA Sifra Osobe Ime Adresa Imena dece E# Toma Beograd Jana E2 Ljubisa Cacak Aleksandar, Vladimir, Stefan E3 Boban Prizren E4 Jovan Nis Lana E5 Mirjana Beograd Slika %6 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 moemo da smestiti vie imena dece. Nije nam poznato koliko imena dece treba zapamtiti, koliko je prostora za to potrebno i to onda ako ima vie imena nego prostora ? Dakle, ovakva tabela kri 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 %7.

Slika %7 OSOBA Sifra Osobe E% E2 E3 E4 E5

Ime Toma Ljubisa Boban Jovan Mirjana

Adresa Beograd Cacak Prizren Nis Beograd

DETE Sifra Osobe E% E2 E2 E2 E4 Slika %8. rbr C% C% C2 C3 C% Primer promerka entiteta Ime deteta Jana Aleksandar Vladimir Stefan Lana za Sliku %7.

Otkrili smo grupu podataka koji se ponavljaju i od njih smo stvorili entitet time smo u"inili prvi korak prema normalizovanom modelu. Takodje, %NF nastaje i kod viezna"ne upotrebe istog atributa kao to je pokazano na slici %9.

Slika %9 OSOBA Sifra Osobe E% E2 E3 E4 E5 E6 Ime Toma Ljubisa Boban Jovan Mirjana Petar Adresa Beograd Cacak Prizren Nis Berklej Negotin Pocetak ili rada %0.0%.%998 22.05.%997 %5.03.%997 30.09.%998 22.04.%997 %5.%0.%998 kraj

Slika 20. Primerak entiteta sa Slike %9. 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 moda oba poznata. Reenje nije u tome da atribut moe da sadri dve "injenice ve! da imamo dva atributa koji govore o po"etku i zavretku rada. Potrebno je da ugradimo dva atributa koji nose dve razli"ite informacije. Slika 2% i 22.

Slika 2%

OSOBA Sifra Osobe E# E2 E3 E4 E5 E6

Ime Toma Ljubisa Boban Jovan Mirjana Petar

Adresa Beograd Cacak Prizren Nis Beograd Negotin Slika 22

Pocetak rada %0.0%.%998 22.05.%997 %5.03.%997 30.09.%998 22.04.%997 %5.%0.%998

Kraj rad 30.%%.%998

Oba pogrena prethodna reenja ne zadovoljavaju prvu normalnu formu. Menjaju!i strukturu moemo 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 vie od jedne vrednosti za svaki primerak. Ako ste sigurni da svi entiteti i atributi ne nose vie "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 sadre 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 pridrueno rolename za atribut moe biti kori!eno u razli"itim entitetima. Erwin ne!e dozvoliti ulazak prenesenih klju"eva u entitet vie nego jednom osim ako mu je dodeljeno rolename svaki put.

Spre"avaju!i vas u viestrukom 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 viestrukog pojavljivanja istih "injenica. Pokaimo 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 kri drugu normalnu formu ako podatak moe biti prona#ena znaju!i samo deo klju"a entiteta. Moe da nastane greka druge normalne forme ako postavite neki atribut nekorektno ali ne postoji algoritam koji bi bez jo dodatnih informacija pored onih u modelu otkrio greku. U entitetnom dijagramu Erwin ne moe znati da ime koje ste dodelili atributu moe predstavljati listu objekata (primer imena dece ). Stoga ne postoji direktna garancija da model zadovoljava prvu normalnu formu. DBMS ema funkcija od Erwina ne podrava podatak tipa lista jer ema baze je u fizi"kom relacionom sistemu tako da se i na ovom nivou mogu spre"iti greke. Spre"avaju!i viestruko 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 greka 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 moe biti prona#ena znaju!i neku vrednost entiteta koja nije klju" naruena 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 moemo je izra"unati na osnovu dananjeg 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 izvriti(vidi ]).

2.4. Definisanje atributa

Definisanje atributa se izvodi u tri koraka: Identifikacija/ alociranje atributa Izvrenje revizije atributa i Definisanje atributa

Identifikacija atributa definie 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 eliminie viestruko nastupanje vrednosti atributa pojedinog entiteta i pritom se za svaki atribut pitamo: Da li je potrebno traiti viestruke vredosti za isto pojavljivanje entiteta(sifra odelenja, Naziv odelenja) Da li atribut moe 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: mukarac, ena

2.5. Prikaz logi"kog modela

Logi"ki nivo modela podataka definie ER model podataka prikazan na sl.... kojim se definiu entiteti, atributi referencijalni integritet i kardinalnost.
JEZIK Sifra jezika RADNO MESTO pripada / OSOBA Sifra osobe Sifrarm rasporedjen Prezime (IE1) Nazivrm Naziv jezika Ime (IE1) Sifrarm (FK) vazi / JMBG (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 MUSKARAC Sifra osobe (FK) Sluzio vojsku ZENA Sifra osobe (FK) Prezime devojacko ODELENJE Sifra odelenja Naziv odelenja Mesto ISPLATA Sifra osobe (FK) rbr Datum isplate Iznos

zaposljava / radi

prima / je primio

Vrsta

rukovodi / je rukovodioc

KONSULTANT Sifra osobe (FK) Broj sati

REDOVNI Sifra osobe (FK) 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 definiu

Definisana ograni"enja definiu 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 definie podtipovi o "u !e kasnihe vie bite re"i.

Ograni"enja koja se posebno definiu Ograni"enja koja se posebno definiu mogu se podeliti na: Ograni"enja na vrednost atributa i to: Tip podatka(character, numeric, boolen ) Duina podatka Opseg dozvoljenih vrednosti i to kao Lista vredosti koji se definiu 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 moe poprimiti samo ui skup vrednosti iz domena( npr. BETWEEN %0 AND 200) Ograni"enja na kardinalnost veza izmedju entiteta roditelja i entiteta deteta i to: Kardinalnost tipa(Zero or OneZ]) gde se jedan primerak jednog tipa entiteta pridruuje nijednom ili jednom primerku drugog tipa. Kardinalnost tipa(Zero, One or More) gde se jedan primerak jednog tipa entiteta pridruuje nijednom, jednom ili ve!em broju primeraka drugog tipa. Kardinalnost tipa(One or MoreP]) gde se jedan primerak jednog tipa entiteta pridruuje najmanje jednom ili ve!em broju primeraka drugog tipa. Kardinalnost tipa konktretne vrednosti(Exactly) gde se jedan primerak jednog tipa entiteta pridruuje 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.#. Prikaz i verifikacija kardinalnosti veza

Veze (relationships) imaju osobinu koja se zove kardinalnost koja definie 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 moe biti u vezi: 0,% ili vie (veza nije ozna"ena nikakvim simbolom) % ili vie (ozna"ava se sa P sa strane entiteta dete) 0 ili % (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 moe biti u vezi: 0 ili % (dozvoljena null vrednost stranog klju"a i ovakav slu"aj je mogu! samo za neidentifikuju!e veze, i obeleava se sa strane roditelja). % (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 moe identifikovati preko roditelja. Ova razlika je veoma vana kada trebamo podravati integritet relacija izmedju roditelja i deteta pod operacijama ubacivanje, brisanja i auriranja. 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 ponaanje modela kada usled operacija odravanja dolazi do naruavanja kardinalnosti veza. Ovo ponaanje modela su tzv. strukturna dinami"ka pravila integriteta(SPI) koja se definiu 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. Poto 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 moe definisati kao bazni domen i specijalizovani(tipski). Svaki domen se tretira kao podtip baznog domena, gde se pod baznim domenima podrazumevaju tipovi podataka(po IDEF%X 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 definie mogu!e vrednosti u domenu. Definiu se dva osnovna pravila i to lista vredosti i rang domena. Lista vrednosti je skup pojedina"nih vredosti koji se definiu eksplicitnim navodjenjem svih dozvoljenih vrednosti(IN 'A,B,C']). Rang domena definie se tako da vrednosti iz domena se uzimaju iz ueg skupa vrednosti(BETWEEN %0 AND 200). Dakle, specifiraju se dozvoljene vrednosti domena koje se definiu 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 narueno zadato ograni"enje gotovo uvek su prikazivanje odgovaraju!e o"igledne poruke ili jedne opte 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....) definie se default domen(<default>) 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 odgovarajuim 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 moe da ima nula vrednost uvodi se i specifi"an predikat NOT NULL, preko koga se definie odgovaraju!i domen. Osnovna veza izmedju atributa i domena je u tome to se atribut koji je identi"an sa svojim domenom moe 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 definie se tabela SPI za objekte, odnosno za operacije insert (ubacivanje), delete (brisanje) i update (auriranje). Referencijalni integritet se definie za svaki vezu, posebno sa strane entiteta roditelj, a posebno sa strane entiteta dete i to za operacije odravanja: ubacivanje novog sloga, brisanje sloga, auriranje 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(auriranje) 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 moe 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 sputena 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: %. RESTRICT (R)-odbijanje operacije; 2. CASCADE(C)-prosle#ivanje operacije na vezni entitet; 3. DEFAULT(D)- ukoliko se narui 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 moe desiti ako mi obriemo 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. Zato ? 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 moemo 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 moe 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 Zato elimo da ograni"imo brisanje? Jedan rezon moe 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, moemo 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 doneen 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 zadran kao podatak u entitetu ANGAZOVANJE. Brisanje nije kaskadno kao predhodnom primeru i mi ne moemo zabraniti brisanje. Mi postavljamo klju" kao NULL vrednost. Prednost ovog pristupa je da mi moemo 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 odraava se na poslovne odluke o odravanju 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 obrie. Pravila za ubacivanje(INSERT) i auriranje(UPDATE) upravljaju ta !e biti kada je red u tabeli dodat ili auriran. Auriranje je, u sutini, ubacivanje ali sa nekim dodatnim pravilima Za ubacivanje, red moe 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 zadrava klju" odgovaraju!e OSOBA. Zbog toga, mi ne moemo ubaciti TELEFON za koji ne postoji OSOBA. P na relacionoj vezi tako#e govori nam da NE moemo 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 RADNIK

Entitet dete ISPLATA RADNIK ZNA JEZIK

ime veza Prima Rukovod i Zna pripada govori

UPDATE U-Cascade CDU-Set Null CDU-Restrict CDU-Set Null CDU-Cascade CD-

INSERT DELETE

DOGADJAJI

I-Restrict D-Cascade CU-Restrict PII- Set Null D- Set Null CU- Set Null PII-Restrict D-Restrict CUPI-

ODELENJE JEZIK

RADNIK ZNA JEZIK

I-Set Null D-Set Null CU-Set Null PII-Restrict D-Restrict CU-Restrict PI-

Crticama su ozna"ena SPI koja ne treba definisati. Slika 3%