I am developing a database model where I need to capture information about rent contracts for parking places within a parking. I have thus defined an entity called PARKING CONTRACT.
Requirements (r.) say, that each PARKING CONTRACT should be signed for exactly 1 car, which is, in turn, owned by exactly 1 car owner.
To fully define a PARKING CONTRACT, r. say, I need to record various information about car owner and his car. For each car owner: full name, address, passport number, etc. For each car: technical passport number, registration number, brand, etc.
According to the r. (they do not go into such details, here I am judging on the basis of attributes that need to be defined!), a car owner can be uniquely identified by their passport number; a car can be identified by registration number.
I first thought it would be good to model CAR OWNER and CAR as separate entities, and came to this:
.-----------------. .-------. .------------. | PARKING CONTRACT| Is signed for | CAR | Is owned by | CAR OWNER | | |O_____________________| |O________________| | '-----------------' 1 1'-------' 1..* 1'------------'
But then I realized that with this design we may store as much CAR OWNERs as we like without any of them having any PARKING CONTRACTs for any of their CARs. I think it is not good - why a database should be able to store information about people which never had any PARKING CONTRACTs.
Another option I see here is to not extract CARs and CAR OWNERs into separate entities and to keep all information about them in the PARKING CONTRACT table, for each PARKING CONTRACT.
But this option doesn't seem to be too nice as well, as the table for PARKING CONTRACT, imho, becomes a chimera which tries to handle too much different information.
Also, I have read this brochure: https://support.ca.com/cadocs/0/CA%20ERwin%20Data%20Modeler%20r8-ENU/Bookshelf_Files/PDF/ERwin_Methods.pdf
and on the page 38, it tells that when you end up with attribute names like parking-contract-signer-passport-number, then that is a sign of a design problem.
The question is: What is the commonest way to handle situations like this one? Is any of these two approaches preferred? Or, maybe, there's a whole different third approach? And why is that approach preferred? Thanks!