Re: About Entity Relation Diagram

My understanding is this:

1. The ER model, which may be called the Conceptual Domain Model, represents a way of dividing up the data as a preparatory stage to developing a database.
2. We list the entity types and the attributes of those entity types. We also note the IDENTIFIER of each entity type, the thing which uniquely identifies each instance of an entity type.
3. We repesent the relationships between entity types graphically, usually. Though there is no reason that we couldn't do this verbally.
4. So far NOTHING has made it necessary to implement this as a RELATIONAL database. That is why we avoid words like 'table', 'key', 'record'. It is also the reason we DON'T show any intersection relations in an ER model, because unless they have attributes they aren't entity types.
5. As we don't know yet whether this will be a relational database or not we don't talk about foreign keys, that is an implementation issue. We have already represented relationships between entity types. If it comes to relational modelling then we can decide how to implement relationships, which will usually be by some sort of foreign key mechanism.
6. An ER model isn't just a picture. It is also a list of entity types, their attributes and identifiers, a set of constraints and perhaps assumptions.
7. I don't know how to implement anything except as a relational database, so the preceding is largely 'academic', but I find it useful, in a very practical way, NOT to be thinking about tables, keys, etc. when I'm still at the requirements and analysis stage. Customers don't know relational. They have information needs which I try to satisfy. The ER stage is an attempt to do that without presupposing how I'm going to implement it.

[Quoted] "Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:32gpirF3lkrrvU1_at_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.
>

>

>

>

>

>