Entitet VoziloOprema je slab entitet u odnosu na Vozilo što znači da je egzistenincijalo zavisan od entiteta Vozilo. U realnom sistemu opšte je poznato da neko vozilo poseduje karakterističnu opremu i ona se najčešće deli na opremu koja je standardna i opremu koja je dodatna. Zbog ove činjenice realnog sistema, identifikovan je entitet VoziloOprema, koji u sebi ima, za pojedino vozilo kolekciju opreme koja je definisana posebnim entitetom Oprema, a sa entitetom VrstaOpreme naznačava se da li je oprema standardna ili dodatna ili ima slučajeva po specijalnom zahtevu. Entitet VoziloOprema je takođe mešoviti entitet gde se jedinstvenost n-torke definiše sa dva atributa VoziloID i OpremaID, dok atributi VrstaOpremeID i CijenaOpreme dodatno opisuju n-torku. U praksi (Projekat za Mercedes Srbija), sam imao slučaj da se neka oprema pojavljuje i količinski, recimo DVD displej na prednjim sedištima što znači 2 komada tada bi se morao entitet VoziloOprema proširiti sa dodatnim atributom KoličinaOpreme. Takođe na istom projektu sam imao slučaj da isti model vozila u jednom trenutku ima jednu kolekciju standardne opreme, a u drugom trenutku drugu kolekciju standardne opreme.
Odnos vozila i računa za vozilo reguliše Zakon u Srbiji gde za svako prodato vozilo mora biti račun, što znači da je odnos između računa i vozila 1:1 zbog toga je u ovom modelu prikazan taj odnos.
Što se tiče načina plaćanja ovde je dat više školski primer, gde je uzeta pretpostavka da jedan račun ima jedan način plaćanja. U praksi baš i nije tako, što ukazuje da bi morao postojati mešoviti entitet VoziloNačinPlaćanja što nadalje širi model.
Ovaj model je dat više kao školski primer i kao što vidite opisan je sa 13 entiteta. U realnoj situaciji recimo na gore pomenutom projektu koji još uvek živi i radi ima preko 150 entiteta.
Pomoc oko aplikacije
