Re: One-To-One Relationships

From: David Cressey <>
Date: Thu, 06 Dec 2007 15:20:56 GMT
Message-ID: <srU5j.11052$Uy.7153_at_trndny07>

"Cimode" <> wrote in message

>> The more elaborate answer is that the best thing is that which comes
>> closest to how this is done in the UoD that you are trying to
>> describe.
>Thank you for your answer. Are you saying that E/R main criteria
>distinguishness of entities depends in fact on context ?
>Can we assume that if *UoD* or context changes the initial criteria
>for distinguishing entities may also change ?


The UoD is the HR department of a company. There is an attribute called "Date of Birth".
The answer is, an employee.

Some time we see a system with a relvar titled "Employees" where each tuple descibes an employee. One of the attributes is "Date-of-Birth". Nothing could be less remarkable.

This time the UoD is a birthing center. There is an attribute called "Date of Birth". The question is, "who or what (entity) does data-of-birth describe". This time the answer is,
Date of Birth describes a birth. Each birth is an event, which we record in the database. One of the attributes of a birth is the date it happened on.

Some time later, see a system with relvars for "Births", "Babies", "Mothers", and "Attending health care workers". Date-of-Birth is an attribute under "Births". We look under "Babies" and we find that there is not Attribute called "Date-of-Birth". We ask the designer why this is so.

"It would be harmful redundancy. See that foreign key, named 'BirthId'? We need that foreign key anyway, to be able to relate the baby to the birth, and so on to the mother, the doctors and the midwives. If we stored Date of Birth in the babies relvar as well as in the births relvar, we would have the same fact in two places."

Are either of these designers wrong? I don't think so. Note that, at least in this case, the UoD bias is reflected in both the ER model (if there is one) and also in the relational model that is reflected in the relvars. Received on Thu Dec 06 2007 - 16:20:56 CET

Original text of this message