Ja cu ti iz prakse odgovoriti: opcija 2 se pokazala bolje u implementaciji kod ORM (npr EF, Devexpress XPO, NHibernate) alata, jednostavno lakse im je da "sazvacu" i da drze konzistenciju za tu tabelu.

Naravno treba u tom slucaju postaviti constrain da se kombinacija aranzmanId i klijentId ne ponavljaju vise od jednom.

Asocijativni, vezni ili kako ga ti zoveš agregirani entitet (Spisak putnika) je uvek slab entitet. Nastao je kao
posledica nemogućnosti realizacije veze više prema više: jedan klijent koristi više aranžmana, jedan aranžman koristi
više klijenata.
Spisak putnika je po samostalnosti zavisni entitet. Zavisi od putnika (Klijent) i kada i gde putuje (Aranžman).
Kao zavisni ne može da bude jak. Kao slab mora da mu PK bude sastavljen od roditeljskih ključeva.
Slab je jer i egzistencijalno i identifikaciono zavisi od roditeljskih atributa.

Ovako kao je na gornjoj slici, zvali bismo ga projektni jer nema neključne atribute. Ako bismo hteli da mu dodamo neke neključne atribute, recimo: BrojSedišta ili PrijavioIzlet, onda bi bio čist Asocijativni entitet.

Dakle pravilno je ovo na gornjoj slici. Šta je kome lakše i u kom alatu za realizaciju je sasvim druga stvar.

Hvala na odgovorima znace mi puno. Ovo mi je projektni zadatak dakle nemam iskustva na tom polju. Upravo to Getsbi isto i ja tvrdim da to samo moze slab entitet da bude (agregirani, asocijativni...) ali traje rasprava izmedju mene i asistenta koji tvrdi da mi fali kljuc SpisakPutnikaID i da ce AranzmanID i KlijentID biti samo atributi odnosno foreign key sto se kosi sa logikom, barem mojom. Da napomenem radim u Microsoft SQL-u.

<sub>[Ovu poruku je menjao zzz030 dana 13.05.2015. u 15:11 GMT+1]

[Ovu poruku je menjao zzz030 dana 13.05.2015. u 15:56 GMT+1]</sub>

Evo njihovog skolskog MOV-a sto se tice istog zadatka.



gde su za agregacije relacioni model uradili ovako:

SmestajUsluga (SmestajUslugaID, SmestajID, UslugaID, Popust)
ProlaznoMesto (ProlaznoMestoID, GradID, AranzmanID, Pauza)

Znaci opet su primarne kljuceve ubacili. I dalje mi nije jasno zasto. Ostao bih pri svojoj tvrdnji.

Malo je kasno, ali je tema interesantna, svodi se na to kako proceniti koja od ponudjenih opcija je bolja.

Na prvi pogled, cini se da je zzz030 potpuno u pravu. Atribut SpisakPutnikaID nema nikakvog smisla, jer ne predstavlja nikakv podatak. Jedinstvena kombinacija atributa (AranzmanID, KlijentID) je potrebna i dovoljna da nam kaze koji klijent putuje u kom aranzmanu. Ali, muguce je i da asistent bude u pravu, ali samo delimicno, to jest nekompletno. To zavisi od toga sta predstavlja posmatrani entitet. Znamo da se iz entiteta na ER dijagramu grade tabele, iz ER dijagrama slede tabele, i to je OK. A iz cega sledi ER dijagram?

Podsetimo se da ER dijagrami nemaju nikakve veze sa relacionom teorijom, samo su jako zgodni da se prikazu neka ogranicenja i interakcije medju tabeleama. A tabele predstavljaju relacije. Ispada da kad hocemo da od relacije dobijemo tabelu, sluzimo se ER dijagramom, gde relaciju predstavljaju entiteti, a onda entitete prevodimo u tabele. Za praksu, nije lose. Problem je sto na osnovu kazanog, dizajn baze je trostepeni proces:

relacija => entitet => tabela (slika 1)

U praksi se najcesce radi samo entitet => tabela. To je pogresno i stetno. Ako prvo razmotrimo relacije, na abstraktnom nivou, mnogo ce lakse biti crtanje ER dijagrama i konstruisanje tabela. Relacije, po relacionoj teoriji, predstavljaju skup tacnih iskaza koji su svi izvedeni iz nekog logickog predikata. Ove gruba definicija sdrzi pojmove 'skup' i 'logicki predikat'. Setite se price na pocetku svake knjige o bazma: "Relaciona teorije zasniva se na teoriji skupova i predikatskoj logici prvog reda." Onda se kaze da je to sve smislio E. Codd i tu se prica zavrsava. Onda sledi kvazi definicija normalnih formi, da bi se kazalo da je ipak ER modeliranje najbrzi put da se dodje do 'sheme' baze podataka. Tacnija verzija procesa dizajna baze je ova:

logicki predikat => relacija => tabela,
ili ako vam je lakse, onda ovako
logicki predikat => ER dijagram => fizicka tabela

U oba slucaja se pocijne od logickog predikata. Na nasem primeru, pogledajmo kako to izgleda.

Za nas slucaj, za entitet "Spisak Putnika" imamo dve opcije, sa dva ili tri atributa. Koja je bolja opcija? Da bismo odgovorili, probacemo da nadjemo logicki predikat za oba slucaja. Logicki predikat je neka vrsta funkcije, logicke funkcije, koja ima parametre i zamenom parametara dobije se konkretan logicki izkaz (propozicija).

U prvoj opciji, koju zastupa zzz030 logicki predikat glasi:
P1: "Osoba [KlijentID] koristi aranzman [AranzmanID]". ( zzz030 resenje)

Ovo je logicka funkcija, sa dva parametra, [KlijentID] i [AranzmanID] koja kao rezultat daje logicku propoziciju (logicki iskaz) koji je po definiciji TRUE ili FLASE. Ako kazem da "Osoba KlijentID = KL1 koristi aranzmann AranzmanID = A2", i ososba KL1 zaista postoji, i zaista koristi aranzman A2, onda tje to tacna (TRUE) prpopzicija i kao takva, moze da bude deo skupa tacnih propozicija koje predstavljamo relacijom Spisak Putnika. Relacija sdrzi skup tacnih propozicija, i to se moze predstaviti u tabelarnom obliku, ako se odbace reci iz predikata i ostanu samo vrednosti atributa.


Slika 1:
Table: SpisakPutnika:
AranzmanID KlijentID
------------------------
A1 K1
A2 K2
A1 K3
A1 K4
A2 K1
.......

Uocite da sam naziv tabele ne znaci ama bas nista, kao ni sam izgled tabele. Slika 1 moze da predstavlja razne spiskove, spisak putnika koji su rezervisali aranzman, ili spisak onih koji su platili, ili spisak onih koji su otkazali, zalili se, nisu platili. Svaki razliciti spisak moze da predstavlja razliciti logicki predikat, a da tabela izgleda potpuno isto. Nazalost, ni jedan RDBMS nam ne daje opciju da cuvamo logicki. Ima i drasticnijih primera. Sat predstavlaj ova tabela:

Slika 2:
Table: Tezine
ID Tezina
----------------
A-001 120
A-002 35
B-001 101
C-003 62

Tezina rezervnih delova? tezna djaka iz neke skole? tezina zadataka na ispitu? U kojim jedinicama se izrazava tezina?

Znaci, da bi razumeli sta radimo, neophodno je definisati logicke predikate za relacije koje definisemo. Tako cemo da pokusamo da razresimo dilemu - koji je model bolji, zzz030 ili asistentov.

Slucaj 1, resenje po zzz030, logicki predikat P1: Klijent [KlijentID] koristi aranzman [AranzmanID]. Dva atributa su ocigledno dovoljna da pokazu ko je uplatio koji aranzman.

Asistent trazi da dodamo jos jedan atribut, SpisakID. Dodavanjem novog atributa [SpisakPutnikaID] mi menjamo logicki predikat, koji bi sad izgledao ovako:

P2: "Osoba [KlijentID] koristi aranzman [AranzmanID], i to je zavedeno pod brojem [SpisakPutnikaID] u knjizi putnika".

Ako vec volimo da zavodimo stvari pod brojem, onda bi zbog kompletnosti trebalo zavseti i ko je i kada to uradio, pa nam trebaju jos neki atributi:

P3: "Osoba [KlijentID] koristi aranzman [AranzmanID], i to je zavedeno pod brojem [SpisakPutnikaID] u knjizi putnika, i to je zaveo [SluzbenikID] na dan [DatumSklapanjaAranzmana] ".

Poslednji predikat P3, predstavlja slozenu recenicu. Prvi deo kazuje koji klijent koristi koji aranzman, a drugi deo kazuje kada se desila transakcija bukiranja aranzmana, ko je to uradio i pod kojim brojem je zavedeno. Predikate P1 i P3 mogu se predstaviti odgovarajucim relacijama. P2 je nekompletna verzija od P3 pa bih ga odbacio.
Pitaje je samo sta zelite da modelujete - koji predikat. Ako vas zanima samo ko je u kom aranzmanu, P1 je sasvim OK. . P3 je isto tako dobar kao i P2, ukoliko zelimo da zabelezimo i detalje transakcije rezervacije.

Znaci, zavisno od predikata za koji gradimo relaciju, P1 ili P3 ce biti dobri. P2 nije dobar jer uvodjenje novog atributa ne kazuje nam nista vise o tome ko je rezervisao koji aranzman. Mozemo da dodamo deset takvih atributa - oni svejedno ne znace nista. Medjutim, ako zelimo da pratimo kompletnu transakciju, onda je P3 bolji od P1.

Znaci, da bi presudili ko je u pravu, moramo da znamo predikat za entitet SpisakPutnika. resenje po zzz030 je dobro, ukoliko imamo jednostavan predikat. Drugo resenje je nekompletno, pa verujemo da je asistent mislio na resenje P3, sa kompletnim opisom transakcije, sto je isto tako dobro.


Po zvanicnoj relacionoj teoriji (C.J. Date, 2012, database Design and Relational Theory, Normal Forms & All That Jazz", analiza pocinje postavljanjem korektnih logickih predikata koji opisuju ucesnike, objekte i transakcije procesa koji modeliramo. ER dijagrami dolaze tek posle, a nisu ni neophodni, u stvari nisu deo relacione teorije uopste. Entitet iz ER dijagrama predstavlja relaciju, koja je skup tacnih iskaza izvedenih iz nekog logickog predikata. Na nesrecu, ER (MOV) dijagrami se cesto koriste kao jedini element logickog dizajna baze podataka, a to dovodi do propustanja mnogih vaznih stvari, sto daje sakate modele.

Model na slici "Evo njihovog skolskog MOV-a sto se tice istog zadatka." izgleda da je radjen bez postavljanja predikata i njihove analize. Iako globalno nije los dijagram, ipak je nekompletan, ili bar ostavlja nedoumice i dozvoljava svakojaka tumacenja. Da izlistamo predikate, da vidimo da li imamo sve ili nesto nedostaje. Koristicu za nijansu izmenjene nazive atributa, zbog jasnoce:

1: [Lice] ima [adresu] i moze biti tipa [TipLica], pri cemu je TipLica iz skupa ('pravno',fizicko').
2. Ako je lice 'pravno, cuvamo [Naziv] i [PIB]
3. Ako je lice 'fizicko', cuvamo [Ime], [Prezime] i [Broj LK].
4. Vodic je iskljucivo fizicko lice, i ima struku [struka] i licencu [Broj Licence]
5. [Aranzman] ima [Naziv] i datum dogadjanja [Datum], i u sebi sadrzi i druge aranzmane, a vodi nas u [Grad].
6. [Lice] koristi [aranzman]
7. [Ekskurzija] je deo [aranzmana] i prijavilo se [broj ljudi] (ili maximalan broj ljudi je [Broj Ljudi]) i vodi je [Vodic]
8. [Smestaj] zavisi od [aranzmana], i prati se [kategorija], [Opis],[Cena] smestaja u datom aranzmanu i [provizija] (Ko ubira proviziju, vlasnik smestaja ili agencija?)
9. Uz [smestaj] nudi se/ukljucena (?) je i [usluga], ne koju se daje/moze dati [Popust]
10. [Prevoznik] je pravno lice, i ima [Naziv] i naplacuje [Cena po km]
11. [Prevoznik] obezbedjuje [prevoz] za [aranzman] i cuvamo [vrstu prevoza] i [tip prevoza] (sta je sta?)
12. Na putu do ciljnog [grada] [aranzmana] pravice se [pauza] u nekom [gradu] kroz koji prolazimo. (ovo je naopako modelirano na slici. Entitet treba da bude 'Pauza', u mestu 'Grad' u voznji koja odgovara [aranzmanu] dana [dan pauze] u sati [vreme pauze] u trajanju od [trajanje pauze] minuta.

Nisam naveo predikate za entitetet kategorija smastahja i usluga, da skratimo pricu.

Iz liste se vidi da nigde ne belezimo kada je korisnik ugovorio aranzman, ko je potpisoa ugovor u ime agancije, nista o placanju, niti da li se korisnik pojavio na dan polaska, ili mozda otkazao put iz nekih razloga. A mozda je i ceo aranzman otkazan iz nekih razloga, i ljudima treba vratiti novac, ili platiti neko obestecenje.

Hocu da kazem da se izlistavanjem logickih predikata pre ER dijagrama dobije mnogo bolja slika o sistemu, nego samo crtanjem djagrama. Sam naziv entiteta ne znaci mnogo i moze nas navesti na pogresan zakljucak. Na primer, iz dijagrama izgleda da [Prevoznik] nudi [prevoz] za odredjeni [aranzman]. To nije isto sto i [prevoznik] se obavezao da ce obezbediti [Prevoz] za [Aranzman]. U oba slucaja i dijagram i tabela bi izgledali isto, iako su to dve veoma razlicite stvari. Recenice "Korisnik je rezervisao aranzman" i "Korisnik je koristio aranzman" i "Korisnik je otkazao aranzman" sve imaju iste atribute, iako im je znacenje potpuno razlicito.

Hvala druze, pojasnio si mi stvari dosta. Kao neko ko je pocetnik nisam mogao sve to tako da slozim u glavi. Mozda upravo to pitanje budem imao na ispitu jer mi je ostalo nejasno zato sto mi je samo "naredjeno" da to tako stavim bez objasnjenja.

Da, u pravu si, asistent je imao na umu malo slozeniji predikat pa sam korigovao taj entitet dodavsi jos atribute: BrojSedista i PrijavioIzlet. Onda mi je tek bilo malo jasnije. Evo kompletnog dijagrama pa posto sam menjao jos neke entitete na molbu asistenta potrebno mi objasnjenje. Zasto npr. entiteti ProlaznaMestaAranzmana i RaspolozivaVozila nece biti "klasicne" agregacije. Tu sam isto ispravljen, jasno mi je da moze i ovako. Razumem dijagram ali zasto ne bi stavio slozene kljuceve kod oba entiteta odnosno identifikujuce veze prema njima. Meni to vise ne lici na agregaciju i ako mi asistent kaze da to i dalje jeste. Svi atributi: VoziloID, AranzmanID (RaspolozivaVozila) i MestoID, AranzmanID (ProlaznaMestaAranzmana) sam postavio kao not null. Koja bi razlika bila?





_{[Ovu poruku je menjao zzz030 dana 21.06.2015. u 19:54 GMT+1]}

Pravo da ti kazem, ja i ne znam tacno sta to znaci agregacija. Posto se u skoli o tome ozbiljno govori, mora biti da je nesto jako vazno. Verovatno Gesbi tu moze da pomogne.

Sve sto ja mogu da uradim je da uradim 'reverse engineering', umesto da iz predikata dobijemo relacije, iz relacija cemo pokusati da dobijemo predikate, s nadom da ce nam to pomoci da bolje razumemo sta se u stvari desava.

Na primer, mozemo da kazemo da se relacija Vozilo izvodi iz predikata "Vozilo, koje je tipa [TipVozila], moze da vozi [BrojMesta] putnika i registrovano je kao [RegistarskiBroj], a mi ga u nasoj evidenciji vodime pod sifrom [VoziloID]" Ovo moze da prodje, ali nije potpuno cisto. Ovaj predikat se sastoji od dve recenice "Vozilo, koje je tipa [TipVozila], moze da vozi [BrojMesta] putnika i registrovano je kao [RegistarskiBroj]," i "Mi vodion vozilo pod sifrom [VoziloID]". Dok sam ja ziveo tamo, registarski broj je bio jedinstveni podatak o vozilu, Kad vozilo netsan, propadne, slupa se, ne vozi se vise, i njegova registracija odlazi sa njim. Ako je ostalo isto i danas, onda ti VoziloID i ne treba - mozes da koristis RegistarskiBroj kao PK. Ako se ista tablica moze naci na razlicitim vozilima u razlicito vreme, onda zanemari ovo sto sam rekao. Na primer u Kanadi tablca ostaje uz vlasnika, te je moja tablica bila na 5 vozila do sada.

Relacoja za koju asistent kaze da je 'agragacija', RaspolozivaVozila ([VoziloID],[AranzmanID],[DatumServisa], [RaspolozivaVozilaID]) moze da doddje iz ovakvog predikata: "Vozli [VoziloID] je raspolozivao za arnzman [AranzmanID], bilo je na servisu dana [DatumServisa]. a sve to mi vodimo u nasim knjigama pod sifrom [RaspolozivaVozilaID]". A moze i ovako: ""Za aranzman [AranzmanID], koristili smo uslugu (servis) vozala [VoziloID] dana [DatumServisa], i o je zavedeno u nasim knjigama pod sifrom [RaspolozivaVozilaID]". Ona prva varijanta ne deluje razumno, kakve veze ima aranzman i poslednji servis (popravka) vozila. Bice da "servis" znaci nesto drugo, pretpostavlja ma je Servis u stvari usluga koju za agenciju izvrsava dato vozilo na dati dan za dati aranzman. Ova zabuna ilustruje koliko je opasno da se zakljuci o bazi i tabelama izvode na osnovu gledanja u strukturu tabela.

Spisak putnika moza da dodje iz predikata: "Na spisku putnika [SpisalPutnikaID] nalazi se klijent koga vodimo pod brojem [KlijentID], sa rezervisanim sedistem [BrSedista] za aranzman [AranzmanID], i prijavio je izlet [PrijavioIzlet]." Tu je nesto mutno. Sta u stvari govori i znaci ova recenica? Da li predikat opsuje spisak putnika, ili kazuje ko je rezervisao izlet (koji izlet?) moze li isti klijent rezervisati vise izleta. Kad se to razjasni, nova shema ce se pojaviti sama od sebe.

Sto se tice agregacije, i dalje ne znam sta to znaci. Jedva sam naucio sta je specijalizacija a sta generalizacija (ni jedno ni drugo se ne odnose na posmatrani problem).

Ako sam bar malo ponmogao, nije mi zao utrosenog vremena.

Srecno

Agregacija znači spajanje i objedinjavanje podataka. Mislim da se u ovom slučaju pogrešno upotrebljava. Termin se koristi kod OLAP modela gde se oko jedne tabele činjenica vrte povezane tabele dimenzija. Ova tabela činjenica nastaje spajanjem ili pridodavanjem novih skupova podataka koji potiču iz transakcionih OLTP baza podataka i gde se na dnevnom ili periodičnom nivou vrši ažuriranje analitičkih OLAP baza. Procesi koji se pri tom dešavaju su ETL (extraction, transformation and loading).

Kada je u pitanju OLTP model podataka kao što je to ovde slučaj, onda vezne tabele ( često ih zovu asocijativne jer mogu poprimiti naziv oba roditeljska entiteta) nastaju kao potreba materijalizacije veze više prema više, jer se takva veza realno ne može drugačije prikazati.

E sad, jezik je živa stvar. Menjaju se konvencije i dogovori oko imenovanja i označavanja. Najvažnije je da se članovi unutar tima razumeju, mada to za ove spolja može da prouzrokuje problem.

Hvala Getsbiju na objasnjenju. Tacno, menja se jezik i konvencije pa je svasta moguce. Zato Cod nije hteo da cuje za ER model - nema veze sa matematikom. U relacionoj teoriji ne postoje entieteti, postoje atributi i definitivno ne postoje 'relationships'. Ali je na kraju Codd priznao da ER modelovanje brze dovodi do normalizovanih tabela i Dr. peter Chen je otisao da proslavi pobedu uz tekilu na ledu.

U okruženju u kome sam ja radio to se zove složeni primarni ključ i vremenom mi se pokazalo da je to mnogo nepraktično za rad (ali nije pogrešno).

Mnogo je jednostavnije da svaka tabela ima prost primarni ključ, koji i ne mora da ima nikakvo značanje to jest jedina uloga mu je da jednoznačno odredi svaki slog u tabeli.

Osnovno pojednostavljenje je sto svakom slogu prsitupas sa jednom vrednoscu kao klucem. Ako je slozen primarni kljuc onda svaki put moras da se petljas sa nekakvim izrazom koji obuhvata vise vrednosti.

Druga stvar je, da, ako prosiruj4s model tako da tabale dobija m stranu, veza izmedju tih tabela jejednostavna sa prostim PK, a ako korsitis slozen PK to postaje prilicno komplikovano. Zamisli u tvom primeru da je potrebno da u bazu evidentiras neke specificnostsvakog pojedinacnog putnika u aranzmanu (naprimer mesto u autobusu, kakavu sobu je rezervisao ili neke dodatne usluge pa vidi kako bi to izgeldalo u prvoj a akoo u drugoj varijanti.

I na kraju zamisli korisnicki interfejs koji mora da se rve sa slozenim kljucevima.


Usput, ja tu tabelu ne bih zvao spisak putnika nego putnici.

Ljudi hvala puno na objasnjenjima! Razjasnili ste mi neke stvari, a predmet sam polozio veoma uspesno :)