pmov, dijagram objekti-veze

Zamolila bih, ukoliko iko ima volje i zelje da pogleda sadrzaj attachment-a, i kaze mi gde gresim... Napravila sam er-model i sad treba to prevesti u odgovarajuci prosireni model objekti-veze...
Radi se o servisu za popravku automobila...

Nisam sigurna kako predstaviti entitet - lista svih izvrsenih intervencija na odredjenom vozilu.. da li kao agregaciju entiteta nalog i popis intervencija... ili nekako drugacije.

zahvaljujem unapred na odgovoru..

p.s. ne znam treba li jos nesto da napisem u cilju boljeg objasnjenja 'problema'....

Uglavnom deluje OK, ali ne potpuno. Dobro: E-R dijagram je malo drukcija slika od MOV dijagrama, to ej OK, oba dijagrama odslikavaju istu situaciju.

Sta verovatno nije dobro:

1) I:{evidencija izvrsenih intervencija} zavisi od V:{evidencija vozila} i od
N:{evidencija naloga} u isto vreme. To mu dodje kao tranzitivna zavisnost, jer {evidencija naloga} vec zavisi od {evidencija vozila}. Ja bih izbacio vezu {Evidencija vozila} na {evidencija izvrsenih intervenicja}. Ako hoces da znas nad kojim je voizlom izvrsena intervenciaj, uradis JOIN izmedju intervencija, naloga i vozila. Ovo je formalna greska i lako se ispravlja.

O logickim greskama, ne moze kazati nista sa 100% puzdanosti, jer ne znamo dovoljno o poslovnom procesu koji modeliras i koja su pravila i ogranicenja. Nije dovoljno znati samo da je u pitanju servis automobila. Ne rade svi servisi na isti nacin. Ako radis sa nekim imaginarnim servisom, ipak treba da se postave nekakvi imaginarni uslovi, na osnovu kojih ce se onda sagraditi model.

Ako nema nekih posebnih uslova, ovo izgleda OK.

Zahvaljujem puno na odgovoru... Zaista mi znaci, jer suludo je kretati sa nekom aplikaciojom ukoliko ovo ne valja...
Sto se veze tice..U pravu ste... Ta veza (izmedju vozila i izvrsenih intervencija) je mozda i suvisna...
Naravno, da postoje pravila.. Mada, i ona su koliko toliko formalna, jer ne treba ovaj informacioni sistem da bude potpun i 100% prezican. Vec jednostavno da opise neku dovoljno opstu/detaljnu sliku nekog realnog informacionog sistema..sto je cilj samog seminarskog rada.
A pravila poslovanja bi bila sledeca (sama sam ih formirala analizirajuci primer servisa iz realnog zivota) :

*za svako vozilo se prati registarski broj, tip, marka, ali i podaci o samom vlasniku vozila
*jedno vozilo moze imati samo jednog vlasnika (onog na koga se vozilo i vodi)
*za svako vozilo, dovezeno u servis, pise se nalog za popravku (sa datumom, i opisom kvara)
*svakom nalogu odgovara spisak svih onih intervencija koje se izvrsavaju na datom vozilu
*za svaku intervenciju se vodi evidencija o listi rezervnih delova neophodnih za izvrsenje te intervencije.

e sad, malo me buni, da nije mozda bolje staviti da {lista izvrsenih intervencija} bude agregacija . Ali opet, sa druge strane, to mi automatski oduzima mogucnost da taj entitet ima svoj identifikacioni kljuc...
ili mozda da malo preuredim MOV, i da organizujem entitete tako da svako vozilo ima svoj nalog, tipa kao neke "clanske karte", odnosno, da na osnovu registracije mozemo otvoriti uvek isti nalog (tog vozila) i dobiti npr. spisak svih intervencija koje su ikada u tom servisu izvrsene na trazenom vozilu... Mozda ce ovako biti bolje?
Zaista nemam neku bolju ideju....

Zaboravi na agregaciju. Agregacija narusava 1NF. Sta god dobijes agregacijom mozes uvek da izracunas kverijem. U ptraksi se ponekad to pravilo prekrsi, ali oovo ej seminarski rad pa treba da bude sve cisto i pravilno. Niakkva agregacija.


Ovo mozes da dobijes iz sadasnje sheme. Kveri koji povezuje tabele o vozilima, intervancijama dace ti ono sto trazis.

Prvo neiskazano pravilo projektovanja baza podataka: struktura baze ne sme da zavisi od upita koji ce se izvrsavati nad bazom. U prevodu, struktura baze (kostur baze, tabele i njihove veze) se pravi tako da opisuje sto tacnije moze odnose izmedju entitetea, realne odnose, koji proizilaze iz skupa pravila koja opisuju poslovni proces. To je vecuradjeno u ovom primeru. Dobro je uradjeno, ne kvari to sto imas.

Pocetnici, a pogotovo ko uci puno Object Oriented stvari, veoma cesto upadnu u tu zamku - pogledamo zeljeni izlaz iz baze i napravimo tabele koje su ogledalna slika tog izlaza. Otud ideje o cuvanju sumarnih podataka (agregacije?) i konstruisanju tabela koje izgledaju kao rezultat nekog kverija. problem je sto izlaza moze biti mnogo, i vremenom se to menja. A baza treba da ostane stabilna sto je moguce duze.

Za prvu fazu, sto je uradjeno, sasvim je OK. Imas pravila, postojeca struktura baze odslikava ta pravila, znaci OK je. U sledecoj fazi mozes da postvljas pitanja na koja baza treba da odgovori i da pises kverije koji to omogucuju.

Za jedan seminarski, vise nego dovoljno.