Re: erd to db

Daniel,

I don't take "represent" the way you do. For me, the word "model" covers that concept rather well. And I don't think that "represent" and "implement" mean exactly the same thing.

To give an example of what I take "represent" to mean, consider the number , "1963". Well, I haven't actually shown you the number. I've shown you a representation of the number. Another representation might be "MCMLXIII". Now, all I'm ever going to show you are representations of the number, and not the number itself. That's inherent in numbers and text, and in a lot of other things.

Taken this way, "represent" and "implement" have a lot of overlap, but they don't mean quite the same thing to me.

--
Regards,
    David Cressey
    www.dcressey.com
"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...

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


>
>