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 E-R KONCEPT
IMENICA ENTITET
GLAGOL VEZA
PRIDEV ATRIBUT ENTITETA
PRILOG ATRIBUT VEZE
GLAGOL.IMENICA MESOVITI TIP ENTITETA-VEZA
RECENICA OBJEKTI POVEZANI VEZAMA
POGLAVLJE 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 TIP ENTITETA
RUKOVODI RUKOVODILAC
RUKOVODJEN ODELENJE
NARUCUJE KUPAC
NARUCEN PROIZVOD

5. Na osnovu atributa na dokumentima je mogu!e identifikovati entitete i veze kao npr.:

ATRIBUT PITANJE ODGOVOR
BOJA BOJA CEGA? PROIZVOD
STAROST STAROST CEGA? RADNIK
DATUM DATUM CEGA? 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,...)
Pridruenje(zadatak-osoba, vozila vonja,...)
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 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 VAZI KORISTI IZGRADJUJE
ZAHTEVA POSLATA POSTIZE POTVRDJUJE
SADRZI POREDI ODREDJUJE PRIHVATA
DEFINISE TRAZI UPRAVLJA PROVERAVA
SALJE ODGOVORA POTVRDJUJE NALAZI
POSEDUJE IDENTIFIKUJE SPECIFICIRA POVEZUJE
REALIZUJE PODSTICE NABAVLJA RAZDVOJA
UKLJUCUJE IMA UPUCUJE SELEKTUJE
Slika 2
#.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.

ISPLATA
OSOBA
je primio
prima

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.
vazi /
odosi se
je dat /
poseduje
OSOBA JEZIK
SARTIFIKAT

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).
Entitet roditelj
Entitet -A
Kljuc atributa-A
Entitet dete
Kljuc atributa-B
Kljuc atributa-A (FK)
Entitet - B
Naziv veze
Identifikujuca veza


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)

P
TELEFON OSOBA
koristi

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 dete-
entitet sa ta"kom na kraju. Jedan ne-prazan podskup prenesenih klju"eva prenosi se preko ne-
identifikuju!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.
Entitet roditelj
Entitet-A
Entitet dete
Kljuc entiteta-A
Kljuc atributa-B
Kljuc atributa-A (FK)
Entitet-B
Naziv veze
Obavezna neidentifikujuca
veza

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.

Entitet roditelj
Entitet-A
Kljuc atributa-A
Entitet dete
Kljuc atributa-B
Kljuc atributa-A (FK)
Entitet-B
Naziv veze
Opciona neidentifikujuca
veza

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" entiteta-
roditelj ( 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


pripada /
rasporedj en
P
rukovodi /
je rukovodioc
vazi /
odosi se
je dat /
poseduj e
prima /
je primi o
zaposljava /
radi
Vrsta
MUSKARAC ZENA
KONSULTANT
REDOVNI
ISPLATA
ODELENJE
SARTIFIKAT
JEZIK
OSOBA
Pol
RADNO MESTO

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
Dakle, svaki entitet ima svoja obeleja koja se nazivaju atributi. Atributi imaju
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.


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 Ime Adresa
E% Toma Beograd
E2 Ljubisa Cacak
E3 Boban Prizren
E4 Jovan Nis
E5 Mirjana Beograd






DETE
Sifra Osobe rbr Ime deteta
E% C% Jana
E2 C% Aleksandar
E2 C2 Vladimir
E2 C3 Stefan
E4 C% Lana
Slika %8. Primer promerka entiteta 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
Ime Adresa Pocetak ili kraj
rada
E% Toma Beograd %0.0%.%998
E2 Ljubisa Cacak 22.05.%997
E3 Boban Prizren %5.03.%997
E4 Jovan Nis 30.09.%998
E5 Mirjana Berklej 22.04.%997
E6 Petar Negotin %5.%0.%998

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
Ime Adresa Pocetak rada Kraj rad
E# Toma Beograd %0.0%.%998 -
E2 Ljubisa Cacak 22.05.%997 -
E3 Boban Prizren %5.03.%997 -
E4 Jovan Nis 30.09.%998 -
E5 Mirjana Beograd 22.04.%997 -
E6 Petar Negotin %5.%0.%998 30.%%.%998
Slika 22


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.

pripada /
rasporedjen
P
rukovodi /
je rukovodioc
vazi /
odosi se
je dat /
poseduje
prima /
je primio
zaposljava /
radi
Vrsta
MUSKARAC
Sifra osobe (FK)
Sluzio vojsku
ZENA
Sifra osobe (FK)
Prezime devojacko
KONSULTANT
Sifra osobe (FK)
Broj sati
REDOVNI
Sifra osobe (FK)
Vrsta posla
ISPLATA
Sifra osobe (FK)
rbr
Datum isplate
Iznos
ODELENJE
Sifra odelenja
Naziv odelenja
Mesto
SARTIFIKAT
Sifra osobe (FK)
Sifra jezika (FK)
Stepen znanja
JEZIK
Sifra jezika
Naziv jezika
OSOBA
Sifra osobe
Prezime (IE1)
Ime (IE1)
Sifrarm (FK)
J MBG (AK2)
rukov (FK)
Datum zaposlenja
Plata
Stimulacija
Sifra odelenja (FK)
Pol
Vrsta
Pol
RADNO MESTO
Sifrarm
Nazivrm



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
Entitet dete ime
veza
UPDATE INSERT DELETE D O G A D J A J I
RADNIK ISPLATA Prima U-Cascade I-Restrict D-Cascade CU-Restrict PI-
CD-
RADNIK Rukovod
i
U-Set Null I- Set Null D- Set Null CU- Set Null PI-
CD-
ZNA JEZIK Zna U-Restrict I-Restrict D-Restrict CU- PI-
CD-
ODELENJE RADNIK pripada U-Set Null I-Set Null D-Set Null CU-Set Null PI-
CD-
JEZIK ZNA JEZIK govori U-Cascade I-Restrict D-Restrict CU-Restrict PI-
CD-

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