You are on page 1of 72

MODELIRAWE POMO]U ER

DIJAGRAMA

Potrebno je mnogo vremena kako


bi se razumeli i definisali
zahtevi klijenata za izradu
aplikacije koja bi u potpunosti
bila prilago|ena korisnicima.
Neophodno je, kada je u pitawu, na
primer, poruxbina, sagledati slede}e:
prizvode, kupce, ra~une kupaca,
distributere i poruxbine.osobama.
TIPOVI ENTITETA

Termin entitet je veoma {iroko


definisan: to je objekat ili doga|aj
koji ~ini sastavni deo modela nekog
poslovawa.

Entiteti su: proizvod, isporu~ilac, ,


naplata,....
Drugi va`an koncept je pojava
entiteta.
Na primer kupci su entitet, ali
Centromarket nije entitet.
Centromarket je primer pojave
entiteta kupca.
Analogija je slog u datoteci.
ATRIBUTI ENTITETA
Atribut je karakteristika ili
osobina koja opisuje entitet ili
opisuje {ta `elimo da svrstamo u
entitet.
Atributi entitieta kupci mogu
biti:

ime
adresa
grad
dr`ava
telefonski broj
likvidnost
kompanija
kontakt osoba
Neophodno je znati da je model koji se
na ovaj na~in stvara iskqu~ivo
logi~ki model.
Bitna prednost logi~kog modelirawa
je da je odvojeno na~elo fizi~kog
dizajniranja i tehni~kog
kompjuterskog sistema od na~ela
poslovawa.
VEZE - RELACIJE

Kupci odre|uju poruxbinu.


"Odre|ivawe" predstavqa vezu.
Zbog toga se ka`e da je model
podataka dijagram veza entiteta
(ER dijagram).
Modeli podataka mogu tako|e
pokazati kardinalnost veza, tj.
broj dozvoqenih pojava entiteta
izmeu dve veze.
Jedan kupac mo`e imati jednu ili
vi{e poruxbina.
Poruxina odre|uje jednog
isporu~ioca ili vi{e dobavqa~a
(u slu~aju velike raznovrsne
poruxbine), ili ~ak nijednog
isporu~ioca (ukoliko poruxbina
odlazi iz fabrike direktno do
kupca).
Kardinalonost omogu}uje da se iz
modela podataka dobiju detaqne
informacije o tome kako teku
odre|eni procesi u poslovawu.
Pretpostavimo, na primer, da je
politika kompanije takva da se
poruxbina ne mo`e direktno
otpremiti ve} se to mora obaviti
preko posrednika.
Tada je veza izme|u poruxbine prema
otpremnicima jedan na prema jedan
ili jedan na prema vi}{e.
To se ozna~ava i kao 1:1 i 1:N.
U ovom primeru nemogu}a je veza 1:0
zato {to to ne dozvoqava politika
kompanije.
S druge strane, ukoliko kompanija
dozvoli da se jedna poruxbina mo`e
odnositi na vi{e kupaca, tada je
kardinalnost 1:N, tj. veza izme|u
poruxbine i kupaca je 1:N.
Ukoliko kompanija to zabrani,
kardinalnost }e biti 1:1.
Osnovna pravila modelirawa
podataka:

tipovi entiteta – stvari o kojima


prikupqamo i skladi{timo podatke
primeri entiteta – pojedina~ni
tipovi entiteta
atributi entiteta – opisuju osobine
entiteta
atributi primera – ozna~avaju
odre|ene vrednosti
veze i wihova kardinalnost.
NOTACIJA I SIMBOLI ER
DIJAGRAMA

Chen-ova notacija prikazana na slede}oj


slici predstavqa notaciju tvorca ER
dijagrama Peter Chen-a.
Entiteti su predstavqeni
pravougaonicima, veze rombom,
kardinalnost je ispisana dva puta pored
linije koja ozna~ava vezu - jedna za svaki
smer veze.
.
Drugu varijantu predstavqa
Bachman-ov dijagram.
Charles Bachman je tvorac
koncepta sistema upravqawa
datotekama.
Bachman-ova notacija entiteta
predstavqena je pravougaonicima
sa nazna~enim atributima unutar
pravougaonika.
Kardinalnost je prikazana
linijama koje spajaju veze jedne sa
drugima.
.
KAKO MODELIRATI
PODATKE

Modelirawe podataka nije lako


uraditi kao {to to izgleda.
Ponekad je te{ko odrediti {ta je
entitet, a {ta atribut.
Tako|e je te{ko razlikovati
entitet od veze.
Postavqa se pitawe da li je
poruxbina entitet ili veza.
U ve}ini situacija zabele`ena je
informacija da je poruxbina
nezavisna i od proizvoda i od kupca,
{to ukazuje da je poruxbina entitet.
U drugom primeru, pretpostavimo da
`elimo da odvojimo entitet od
atributa.
Da li je kreditna sposobnost entitet
ili atribut kupca. Ukoliko ne
postoji potreba da neka stavka
postoji nezavisno od svog entiteta,
re~ je o atributu.
PREPOZNAVAWE ENTITETA

Zadatak analiti~ara jeste


razotkrivawe skrivenih stvari.
Entiteti su ~esto skriveni.
Celokupan proces otkrivawa entiteta
podeqen je na tri koraka:

kori{}ewe intervjuisawa
odvajawe entiteta od
atributa i veza
dobijawe povratne
informacije
• Kori{}ewe intervjuisawa
funkcioni{e odli~no kada su u
projekat ukqu~eni korisnici i
analiti~ari.
Osnovni ciq intervjuisawa je
stvarawe liste stvari, objekata ili
imenica koje se javqaju u poslovnom
okru`ewu.
Wihov broj mo`e dosti}i cifru 100
kada su u pitawu ve}e aplikacije.
Drugi korak podrazumeva
definisawe entiteta.
U modelirawu podataka
primarni entitet je osnova od
koje treba po}i.
• On kasnije ne mo`e biti
dekomponovan niti izbrisan jer
predstavqa osnovu za
funkcionisawe poslovawa.
• U analizi se koristi i koncept
entitet derivat.
• Kao {to mu ime govori, to je
derivat nekog primarnog
entiteta.
• Moglo bi se re}i da su, na
primer, tro{kovi proizvodwe
entitet.
• Me|utim tro{kovi proizvodwe
su proizvod kalkulacije drugih
entiteta koji sadr`e
informacije o ~asovima rada,
koeficijentima, materijalima i
tro{kovima materijala.
Tro{kovi proizvodwe su zbog toga
izra~unata veli~ina koja predstavqa
entitet derivat.
Po{to ne spadaju u grupu primarnih
entiteta ne mogu se na}i na ER
dijagramu.
Pomo}u testa postojanosti mogu}e je
prona}i primarne entitete i
odvojiti ih od atributa.
Test postojanosti ka`e da ukoliko se
entitet ne pojavquje, svi wegovi
atributi se tako|e ne pojavquju.
Razmotrimo broj poruxbine. Ukoliko
se instanca entiteta poruxbine ne
pojavquje tada }e i broj poruxbine
prestati da postoji {to ukazuje da je
broj poruxbine atribut.
S druge strane mo`e se pomisliti da
je kupac atribut entiteta poruxbina.
Me|utim, ukoliko se poruxbina ne
pojavquje, kupac }e i daqe postojati.
Osta}e sa~uvani podaci o kupcu (ime,
broj telefona i druge neophodne
informacije), jer se zna da je on
nekada bio kupac, a i pretpostavqa se
da je on potencijalni kupac u
budu}nosti.
Postoje tri pitawa koje treba
postaviti da bi se ta~no
napravila razlika izme|u
entiteta, atributa i veza:
Da li je stavka primarna?
Ukoliko nije, poku{aj da
prona|e{ u kom primarnom
entitetu je postoje}i
sadr`an.
Da li je stavka derivat?
Ako jeste, prona|i primarni
entitet.
Da li je objekat atribut ili
entitet?
Primenite test postojawa
kako bi na{li odgovor.
Tre}i korak podrazumeva
sukcesivno crtawe ER
dijagrama koji }e biti
izlo`eni korisnicima i
stajati im na raspolagawu u
smislu davawa kritika i
komentara.
Ovaj proces traje sve dotle
dok se korisnici ne usaglase
sa analiti~arima o
ispravnosti ER dijagrama.
Tre}a faza deluje jednostavno
ali mo`e zahtevati dosta
vremena..
Nekoliko tipi~nih situacija mogu
iskomplikovati rad na modelirawu
podataka. To se de{ava kada je tip
podatka proizvod dva entiteta kao
{to je:
kupac+ra~un->transakcija
student+kurs->diploma
proizvod+kupac->poruxbina
Presek podataka nije toliko
te{ko razumenti koliko je te{ko
analiti~aru utvrditi da je
wihovo pojavqivawe i de{avawe
normanlno i da su to provereni
tipovi entiteta.
Preseci entiteta ne mogu
postojati nezavisno od entiteta
od kojih nastaju i moraju biti
prikazani na ER dijagramu.
Preseci entiteta i derivati
entiteta su razli~iti pojmovi.
Preseci podataka predstavqaju
ne{to novo {to je nastalo od drugih
entiteta.
Derivati entiteta ne sadr`e nove
podtake i zbog toga se ne prikazuju na
ER dijagramu.
Neophodno je ukazati na jo{ jedan
pojam, a to je rekurzivni entitet.
Rekurzivni entitet predstavqa
definisawe ili restruktuirawe
sopstvenih podataka.
NIVOI MODELIRAWA

Modelirawe podataka pomo}u ER


dijagrama i modelirawe procesa
pomo}u DF dijagrama su univerzalni
alati.
Mogu se primeniti u modelirawu
problema koji imaju razli~it
obuhvat, tj. koji zahtevaju razli~it
broj nivoa.
Obuhvat ozna~ava {irinu, tj opseg
modelirawa.
Neke organizacije modelirawem
obuhvataju projekte koji se odnose na
celokupno okru`ewe organizacije.
Ova solucija je dosta skupa i
zahteva mnogo vremena.
Ona ukqu~je ~itave korporacije,
organizacije ili preduze}a.
Drugi korisnici zahtevaju modelirawe
sredweg obuhvata.
Ovo je jeftinija solucija koja obuhvata
poslovnu jeinicu.
Veliki profitni centri i geografski
odvojene operacije su primeri poslovnih
jedinica.
Naju`i obuhvat imaju pojedina~ni
aplikacioni sistemi.
Za koji se obuhvat opredeliti zavisi
prete`no od raspolo`ivih izvora.
Modelirawe podataka i modelirawe
procesa mo`e se obaviti na visokom,
sredwem i niskom nivou.
Ovi nivoi modelirawa su
primenqivi na sva tri obuhvata -
preduze}e, poslovna jedinica,
aplikacija .
.
Visoki nivo modela podataka
konstruisan je pomo}u ER dijagrama.
Visoki nivo modela procesa se
obi~no zove kontekst dijagram i/ili
sistem DF dijagrama.
Sredwi nivo modelirawa je
neophodan zato {to ER dijagram nije
u mogu}nosti da prika`e neophodne
detaqe u vezi strukture podataka.
Sistem analiti~ar mo`e
identifikovati entitet i nazvati ga
"kupac" na ER dijagramu, ali mogu}e
je ovu kategoriju podeliti na
nekoliko tipova kao {to su brokeri,
radnici, maloprodavci, najmodavci, ...
Sredwi nivo modela podataka mo`e
prikazati ove razli~ite tipove
entiteta "kupac". ..
Tehnike i simboli koji se koriste za
modelirawe sredweg nivoa znatno se
razlikuju po metodologiji i CASE alatima.
Modeli niskog nivoa su dosta detaqniji i
~esto se na ovom nivou javqaju neki detaqi
vezani za fizi~ko dizajnirawe.
Ovde je granica izme|u fizi~kog i
logi~kog modelirawa nejasna - zamagqena.
Fizi~ki modeli podataka variraju u
formatu zavisno od razvojne
metodologije sistema koja se koristi.
On uvek prikazuje veli~inu poqa
podataka i tip podataka.
Modeli procesa na ovom nivou su
tako|e fizi~ki po karakteru i
sadr`e detaqne opise o tome kako
izvr{iti neophodne procese.
KORISTI OD
MODELIRAWA

UKQU^EWE KORISNIKA

Iskustva sistem analiti~ra govore da je za


izgradwu jednog uspe{nog sistema
neophodno u projekat ukqu~iti i
korisnike
UKQU^EWE
KORISNIKA

Analiti~ari koji u procesu


dizajnirawa sistema koriste
pomo} korisnika su na pravom
putu za formirawe jednog
kompletnog sistema koji }e
pokriti sve potrebe korisnika.
Kada analiti~ari postave DF i ER
dijagrame, prosle|uju ih korisnicima
~iji je zadatak da nakon pregleda
dijagrama daju svoje primedbe, uka`u
na eventualne gre{ke i uka`u na neke
propuste.
ER i DF dijagrami su lako
~itqivi od strane korisnika,
{to olak{ava proces
ukqu~ivawa korisnika u
projekat, a to sve doprinosi
kvalitietu modelirawa.
Korisnici postaju partneri
analiti~ara.
[EMATSKI PLAN
POSLOVAWA

Veliku prepreku projektu


predstavqaju korisnici i
menaxeri koji nisu tehni~ki
orjentisani i koji ne razumeju
dugoro~ne koristi koje model
stvara.
Sve prepreke koje se na|u na putu
~ine da su tro{kovi rada ve}i, a
potrebno je i vi{e vremena za
izradu projekta.
Analiti~ari treba usko da
sara|uju sa korisnicima pri
razvoju logi~kog modela
podataka i izradi dijagrama
pri modelirawu procesa.
Wihov zajedni~ki ciq je
razotkrivawe osnovnih funkcija
poslovawa i procesa na kojima se
zasniva platni sistem.
Lo{a strana wihovog
zajedni~kog rada je ta {to je
neophodno ulo`iti dosta
vremena i napora, a to va`i i
za analiti~are i za
korisnike.
Ovakav na~in rada zahteva
velike "up'front" tro{kove.
To su tro{kovi koji nastaju u
ranoj fazi modelirawa i ne
prote`u se du` ~itavog
projekta.
Dobra strana jeste ta {to }e model, kada
bude kona~no gotov, obezbediti logi~ku
{emu celokupnog platnog sistema, tako da
}e svaki dodatni sistem koji }e biti u
okviru platnog sistema biti br`e i lak{e
modeliran, a i tro{kovi modelirawa }e
biti mawi, jer }e model platnog sistema
pru`iti osnove za dodatni rad.

You might also like