Re: erd to db

"Daniel Guntermann" <guntermann_at_uswest.net> wrote in message news:LqVo8.394$%Z1.310922_at_news.uswest.net...
> "Jan Hidders" <hidders_at_uia.ua.ac.be> wrote in message
> news:3ca3313c$1_at_news.uia.ac.be...
>
> 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.

Indeed. Although I must admit that I also agree with David Cressey's remarks that what Peter Chen is doing there is probably better described as showing a representation of the abstract concepts as opposed to implementing them. But I still maintain that he introduces the notion of primary key because of his choice of representation, and therefore the notion should not be introduced at the conceptual level.

> > 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'.

True, and although I think I understand why he did it at the time, I still wish he had made a better distinction here. But this is all with the comfort of hindsight, of course.

> 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.

Ah, but wait, I have no problem with the term "key" or "entity key"; I firmly believe that a conceptual model should indicate for every entity type how its entities can be identified. (Although I am not so certain that this should always be possible with just its attributes and the relationships it is directly involved in, but that is another discussion.) What I have a problem with is demanding that one key is indicated as *the* key. I see no reason why at the conceptual level a specific key should be considered as special.

> 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.

Absolutely. But I have the feeling that the primary key terminology actually encourages surrogate keys. This is because it gives many designers the impression that once they have defined a primary key they are done, when actually they still have to determine which other combinations of attributes are keys.

• Jan Hidders