U vasem slucaju kada imate kolekciju n-torki magacionera koji su takodje fizicko lice i smesteni u posebnom entitetu MAGACIONER i kolekciju n-torki dobavljaca fizickih lica smestenih u entitetu DOBAVLJAC, postavlja se pitanje? Da li neki od magacionera mogu biti i dobavljaci? Sigurno je u realnom svetu to moguce. Ali u realnom svetu ne postoje samo magacioneri vec postoje i drugi. Karakteristika specijalizacija se zasniva na operatoru koji je iskljucivo "ili", sto znaci da iskljucuje jednu od druge mogucnosti.

Znaci ako bi generalizovali magacionere i dobavljace recimo s entitetom "FizickoLice" to bi tada znacilo da ako je neko magacioner ne bi mogao da bude dobavljac sto je u suprotnosti sa realnim svetom. Tako da ova dva entietata MAGACIONER i DOBAVLJAC ukoliko bi bili u vezi tipa specijalizacije ne bi realno oslikavali realni sistem.

Moj predlog bi vam bio da definisete entitet PoslovniPartner koji bi bio generalizovani u odnosu na entitete PravnoLice i entitet FizickoLice, a entitet Magacioner kao dete bi bio u identifikujucoj vezi sa entitetim FizickoLice 0-1, a entitet Dobavljac kao dete bi bio u vezi sa entitetom PoslovniPartner takodje u identifikujucoj vezi 0-1


<sub>[Ovu poruku je menjao Zoran.Eremija dana 08.03.2010. u 00:23 GMT+1]


[Ovu poruku je menjao Zoran.Eremija dana 08.03.2010. u 18:29 GMT+1]</sub>

Zorane, veliko Vam hvala na odgovoru. Zaista korektno objasnjenje i model.

Medjutim, interesuje me kako bi ovaj model funkcionisao za dobavljaca koji je fizicko lice. Verovatno bi trebao da u tom slucaju povezem DOBAVLJACA sa fizickim licem na isti nacin kako je MAGACIONER povezan ili gresim? Mislim u ovom modelu koji ste prikazali, DOBAVLJAC nema atribute fizickog lica, cak ni kao slab objekat POSLOVNOG PARTNERA u kome nema atributa fizickog lica.

Sobzirom da vidim da se razumete, a ja sam pocetnik u celoj prici, zeleo bih da Vas zamolim da mi pomognete oko jos jedne nedoumice.

Interesuje me, ukoliko bih zeleo da ovaj konceptualni model prevedem u logicki model(gde je, koliko shvatam, svaka vrsta veze izmedju entiteta svedena na 'jezik' spoljnih kljuceva tj. veze One-to-Many), a kasnije i fizicki, kako bih mogao da realizujem npr. labavu vezu jakog i slabog(identifikujuceg) objekta ili npr. ekskluzivnu specijalizaciju i slicno? Jel se to radi kontrolisanjem onih ogranicenja i referencijalnog integriteta ili...?

Ovo pitanje sam Vam postavio jer me poprilicno buni odnos konceptualnog modela i mogucnost i korist njegove prakticne realizacije.

Jednostavno se u odredjenom trenutku zapitam, zasto jednostavno ne napravim posebne tabele DOBAVLJAC i MAGACIONER sa njihovim atributima, jer prosto nevidim svrhu 'komplikovanja' stukture same baze.

Oprostite na duzini i jos jednom hvala.

Da bi vam stvar bila jasnija prvo da odredim metodologiju. Metodologija koja je koriscena na primeru koji je prikazan je IDEF1X (www.idef.com). Ovu metodologiju koristim primenom CASE alata (AllFusion® ERwin® Data Modeler 4.1.4 SP5) koji u sebi ima implementirana pravila IDEF1X metodologije. Ova metodologija je orjentisana prema relacionim modelima, za razliku od drugih. Bazira se na logickom i fizickom dizajnu. Detaljnije cete naci u knjizi prof. dr Alempija Veljovica (http://www.cafe022.com/mybb/ra...lempije-veljovic-246-t-37.html).

Primer modela koji je dat je na logickom nivou, koji donekle odgovara konceptualnom, iako IDEF1X metodologija ne pominje konceptualni model (koji se koristi u UML metodologiji).

Iz logickog modela koji je dat, poznavalac IDEF1X metodologije uocice da je dominantan entitet Partner, koji je generalizovan i ujedno specijalizovan na entitet PravnoLice i entitet FizickoLice, kao njegove specijalizacije. Specijalizacija kao oblik veze medju entitetima koja se definise uz pomoc Diskriminatora koji je matematicki operator "ILI". Entiteti PravnoLice i FizickoLice su egzistencijalno zavisni preko diskriminatora od entiteta Partner, sto znaci da na fizickom nivou u buducoj tabeli FizickoLice ne moze biti n-torka jedinstveno identifikovana atributom FizickoLiceID, a da ne postoji n-torka u tabeli Partner koja je jedinstveno identifikovana atributom PartnerID i u toj n-torci u atributu TipPartneraID mora postojati jednoznacna oznaka koja ukazuje da je to tip partnera fizicko lice. Takodje ova veza znaci da u tabeli PravnoLice ne moze da se nadje n-torka kojoj je jedinstvena identifikacija PravnoLiceID jednaka bilo kojoj n-torci iz tabele FizickoLice. Upravo ova definicija opisuje realni sistem. Neko lice ili je Pravno ili fizicko ne moze biti i jedno i drugo.
Postavlja se pitanje, zasto smo ovo komplikovali na ovakav nacin. iz jednostavnog razloga. Da bi recimo nesto uslo u magacin morate to dokumentovati. u tom dokumentu (otpremnica, dostavnica, zapisnik o prijemu...) moze se naci u jednom slucaju neko ko dostavlja ko je pravno lice ili neko ko je fizicko lice. Zbog toga su ta dva entiteta generalizovana i prikazana jednim entitetom Partner (pogledajet u prilogu model) i takav entitet u sebi sadrzi sve one osobine i pravnog i fizickog lica koje su zajednicke.

Imajuci u vidu prethodno objasnjenje, entitet Magacioner je entitet koji je vezan s entitetom FizickoLice u obliku veze 0:1 i predstavlja slab entitet od entiteta FizickoLice, sto znaci da je egzistencionalno zavisan od entiteta FizickoLice, a posto je entitet FizickoLice egzistencionalno zavisan od entiteta Partner onda je i magacioner egzistencionalno zavisan od entiteta Partner. U datom modelu dobavljaci su prikazani entitetom Dobavljac koji je direktno egzistencionalno zavisan od entiteta Partner u istoj vezi kao sto je entitet Magacioner prema entitetu FizickoLice 0:1. Ovo znaci da dabavljac moze biti bilo koji Partner i to nijednom ili jednom a to znaci ili pravnolice ili fizicko lice, a ako je fizicko lice moze biti i magacioner.

Posto je dat primer uradjen u ERwin CASE alatu definisanjem i fizickog modela i sve ono sto podrazumeva u definiciji fizickog modela, dovoljno je opredeliti se koji ce vam biti fizicki relacioni model i da tada izgenerisete sve u taj model uz ogranicenej koje zavisi od samog CASE alata i njegove podrske kao i njegove verzije (poslednja verzija je 7.3 imam je ali imam problema s njom prilikom generisanja).



<sub>[Ovu poruku je menjao Zoran.Eremija dana 10.03.2010. u 12:13 GMT+1]

[Ovu poruku je menjao Zoran.Eremija dana 10.03.2010. u 19:34 GMT+1]</sub>

Zorane, ja nemam reci. Ne znam kako da Vam se zahvalim sto nesebicno delite Vase dragoceno i vredno iskustvo i znanje.

Takvi ljudi kao Vi cine ovakve zajednice neprocenjivo vrednim.

Jos jednom veliko HVALA na detaljnom objasnjenju.

Sjajno!!!

Nema potrebe za zahvaljivanjem. Ima jos kolega koji znaju mnogo vise od mene i veoma su mnogima pomogli. Srecno i samo napred...