Re: About Entity Relation Diagram

I guess what you call identifiers (or identifying attributes), can also be called keys, as they are likely to translate into the keys in the relational table.

Different entity types can have several sets of identifying attributes. Also relationships can have identifying components.

For example in the relationship Departure(flight, airport) then component flight is an identifier since the same flight cannot depart from several airports. Different E/R notations may have a graphical way to represent identifying components in a relationship or identifying attributes for an entity type.

Regardless of terminology the essence is that during the conceptual modeling you identify all the *constraints* applicable to the model as a reflection of "business rules" or the rules of the domain being model.

Now if you name those constraints "key constraints" or "entity identifier", I think is largely beside the point. You can talk about constraints in the E/R without refering to tabels and records, but simply to entities, relationships, attributes. Of course "foreign key" is a foreign concept to E/R modeling, I wasn't refering to that when I talked about "keys".

I guess it is just a difference in terminology.

Best,
Costin

Mike MacSween wrote:
> 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.
>
> That's how I was taught on my degree. I'll see if I can find some references
> when I've got time. I expect there will be many different approaches to ER
> modelling, as it doesn't seem that there is a univerally standard modelling
> technique, unlike relational modelling.
>
> Yours, Mike
>
> "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.
>>
>>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.