Re: About Entity Relation Diagram

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Fri, 17 Dec 2004 11:15:15 -0800
Message-ID: <32gpirF3lkrrvU1@individual.net>

Mike MacSween wrote:
> "Gene Wirchenko" <genew_at_mail.ocis.net> wrote in message
> news:nmd3s0tioi7mscglip37208g0u45g5v3tt_at_4ax.com...
>
>
>

>>>I do, however, have another question. What will the primary key of the
>>>entity INTERESTS and APPEARANCE be? I read somewhere that when relating 2
>>>entities with a relation, the relation doesn't have to include the primary
>>>keys of the entities it relates. For example, between member and tape, the
>>>relation RENTAL doesn't have to include MemverID and TapeID, only DateRent
>>>and DateDue.
>>
>>    This is not correct.  You need to have the keys.  What you do not
>>do is show them when at the logical level.  They are implied.  (Think
>>of how you would use that relation.  You need to have the keys.)

>
>
> I believe you are mistaken. They DO have to be shown at the logical, i.e.
> relational level. That is the logical model. Where they don't need to be
> shown is in an ER model.
>
> An ER Model IS NOT the same as a relational model, it is an earlier stage of
> database creation which MAY lead to a relational model, but is
> IMPLEMENTATION INDEPENDENT. In other words an ER model could be implemented
> using a non relational database.
>
>

Keys also need to be shown in the ER model, as well.

Source : Bernhard Thalheim "Entity-Relationship Modeling: Foundations of Database Technology" Springer-Verlag 2000.

They are very important to validate that your model corresponds to the reality.

And because the conceptual model is supposed to capture business rules, if you don't capture key constraints in the E/R model, where will the database schema designer gets his key definition from ?

Of course theres also the possibility of not bothering to create a conceptual model at all, and go directly to logical model. Less diagrams to go out of sync and less hassles, more risk that some stuff may remain undocumented. It's a trade-off based on staffing, bandwidth, priorities.

For some projects ER diagrams is overkill and inefficient investment of time, for others ER diagrams may be critical. Received on Fri Dec 17 2004 - 13:15:15 CST