Re: erd to db

"Jan Hidders" <hidders_at_uia.ua.ac.be> wrote in message news:3ca3313c$1_at_news.uia.ac.be...
> "Daniel Guntermann" <guntermann_at_uswest.net> wrote in message
> news:jIxo8.151$pV.127451_at_news.uswest.net...
> >
> > In regards to shivers down your spine when others reference a primay key
> in
> > association with an entity, I defer to section 2.3.1, entitled Primary
> Keys,
> > in Peter Chen's, "The Entity-Relationship Model -- Toward a Unified
Model
> of
> > Data."
>
> A fine reference indeed. :-) But note the sentence just before this
section:
> "In the following, we shall describe how to represent entities and
> relationships." Note the word "represent". What he is actually doing in
> section 2.3 Information Structure (level 2) is showing you how entity sets
> and relationships can be represented as tables.

You certainly make a good point which I understand and agree with you that the author is talking about representation, especially in the context of the relational and entity sets models. But then I see that Mr. Chen also states that "entities at level 1 are conceptual objects in our minds. At level 2, we, we consider representations of conceptual objects."

By the word "represent", I guess I've always interpreted that to mean representation in the form of some model, depiction, picture, diagram, or other means of communication (not necessarily an ERM). I see that you take it to mean a representation in the form of implementation, or more specifically, tables. Perhaps, at least in some cases, either of our interpretations would be appropriate.

It's also interesting to note that in his "Levels of Logical Views" (Figure 1), Mr. Chen shows entity-relationship diagrams and relations at level 2 and actual implementation in the form of tables at level 3. I make these comments without getting into the comparisons delineated by the various model implementation headings at the top of the matrix.

In other words, he is
> showing you how to map the whole thing to the relational model. Not really
> surprising then that he needs the term "primary key", is it? :-)

No, you are right, and it's not surprising; though he also calls this an 'entity key'.

> goes on to explain the representation and indeed (to my great sadness)
does
> not make much distinction between the entity sets and how they are
> represented as relations. This is not completely correct because when
> choosing a primary key you are making a small implementation decision, and
> that has no place in something called the conceptual model.
>

  Though, even if I weren't going implement an entity type or relationship type (or object types) in some system, but still wanted to document or model the information, I'd still want a user or domain expert to express exactly what attribute(s) he or she would use to identify a single instance of that type. I think that is as close to a conceptual level as you can get. The more I think about it though, I do think the term 'primary key' is not very apt; though I can live with the term entity key or candidate key.

In terms of implementation of model elements in a system, there often seems to be a great fondness for slapping meaningless surrogate *primary keys* into tables anyway (though I will admit there often exist perfectly valid technical reasons for doing so), even when valid semantic keys exist. So, in my mind, particularly for any conceptual model, trying to identify a semantically valid entity key would go a long way to ensuring that a distinction between conceptual and implementation layers exists.

> -- Jan Hidders
>
>

Regards,

Daniel Guntermann Received on Fri Mar 29 2002 - 09:37:01 CET