A lekovi se izdaju u vazduh, tj. niko ih ne pije? Ja iz ovoga ne vidim kako ćeš uspeti da pronađeš recimo kojim je sve pacijentima prepisan Palitrex.

Profesor je u pravu. Svuda gde je relacija više prema više kao u pomenutom slučaju Lekovi-Pregled neophodno je uvesti dodatni entitet, jer je realizacija kardinalnosti više prema više neizvodljiva bez dodatnog, asocijativnog entiteta.

Situacija:"Jedan lek može da bude prepisan na više pregleda i na jednom pregledu može da bude prepisano više lekova" se prevazilazi, recimo dodatnim entitetom LekPregled. Ovaj novi entitet sadrži najmanje dva atributa Lek_Id i Pregled _Id, koji čine njegov složeni PK (primarni ključ). Postojeći entiteti: Lekovi i Pregled, vezani su prema ovom dodatnom LekPregled, vezom jedan prema više. Tako se jedino može razlučiti na kojem pregledu je koji lek prepisan. Ovaj entitet LekPregled možeš slobodno da nazoveš i Terapija. Ja sam ga samo generički krstio kako bi ti bilo jasno.

Tako će jedan Pacijent, koji ima jedan Karton, moći u tom kartonu da ima više pregleda i svaki pregled će po pitanju prepisanih lekova da bude definisan.

BTW. Mislim da još neke veze nisu korektne. Razmišljaj o kardinalnosti odnosno koliko čega jednog entiteta učestvuje u drugom entitetu i korektno koristi program za grafičko-tekstualnu dokumentaciju.

Pa i ja sam mislio da treba da se samo doda jos jedan entitet izmedju.

Ali kada se ovaj ovakav konceptualni model pretvori u fizicki svuda gde je relacija N:M ce se pojaviti jos jedan entitet kao sto je i ovde slucaj, ili ja moram u konceptualnom modelu da na svakom mestu gde imam N:M relaciju da dodam jedan entitet koji ce stajati izmedju i biti u vezi 1:N sa ostala dva entiteta.

Ja ovde nisam prikazao kompletnu sliku ali reci mi sta mislis da jos nije dobro na ovom delu dijagrama koji vidis.

Mislim da to moraš da uradiš u konceptualnom modelu. Doduše ne znam koji alat tačno koristiš (neki predlažu vezne entitete tamo gde zateknu vezu N:M). Ipak profesor hoće tvoje razumevanje poslovnog procesa na konceptualnom nivou.

Inače vidim isto što i ti. Tamo gde je N:M treba da se doradi model po pomenutom principu.

Ovo mi je logično: "Jedan doktor vrši više pregleda, jedan pregled mogu da obave više doktora" (konzilijum). Tu bi trebao dodatni entitet.

Nisam siguran za drugi deo iskaza: "Jedna ordinacija ima više doktora, jedan doktor može da radi u više ordinacija"

Takođe nisam siguran za drugi deo iskaza: "Jedna ordinacija ima više kartona, jedan karton može da se nalazi u više ordinacija"
Ja na primer imam poseban karton u zubnoj ordinaciji, poseban u medicini rada. Kod ovh drugih nisam na sreću odlazio.

Ukoliko su ove dve zadnje tvrdnje istinite onda postupiti kao u slučaju Lekovi-Pregled.

OK

Ipak mi je cudno sto je on meni na ceo dijagram rekao da je greska jedino ovde kod lekova i pregleda.

Hvala puno na pomoci.

Pošto se radi o konceptualnom modelu nemora svaka N:M relalcija da se pretvara u entitet, ali... Ovde je relacija nazvana imenicom "terapija" i tu vidim problem, jer se imenicama nazivaju entiteti! Zato po meni taj deo modela treba da se realizuje upotrebom enititeta već u konceptualnom dizajnu.

Relacija "izvršio" koju takođe vidimo je nazvana glagolom i zato tu nema konceptualnih problema. Kasnije se u fizičkom modelu ova relacija pretvara u tabelu koju bih ja nazvao imenicom "izvrseni_pregledi".

Nece se pojaviti entitet nego tabela - u fizickom modelu nema entiteta.

Slažem se tvrdnjom i u skladu je sa pravilima notacije na konceptualnom nivou. Ja ponekad preterujem sa detaljnošću na logičkom nivou jer ljudi zaboravljaju da kasnije dodaju vezne tabele kad je generisanje završeno. Alati koji na fizičkom nivou predlažu vezne tabele tamo gde zateknu vezu N:M na konceptualnom, su dobro rešenje. Međutim još uvek su u upotrebi i alati koji to ne rade. Dosta njih crta i u MS Visio. U svakom slučaju tvrdnja je korektna.

Najvaznije je da smo se mi razumeli.

Naravno da nedostaje - to je entitet RECEPT!