Re: erd to db

"David Cressey" <david_at_dcressey.com> wrote in message news:wm0p8.51$3B.4265_at_petpeeve.ziplink.net...
> 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.

Couldn't a model be defined as a representation of some concept or idea, or even an aggregation of concepts?
>
> 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.

Agreed. I'd like to add that having had time to consider the subtleties of the term representation in the context of a data model in more detail, I'd have to amend my previous assertion from the term "represent" as a notational depiction, to a term more in line with the identification or representation of an "instance" of the conceptual object in our minds. I still don't think that the word 'represent' necessarily means tables, though Mr. Chen was well on his way of explaining a mapping from ERMs to the relational model, as well as entitiy sets.

Your example is right on, though one could take it a step further in considering the representation of entities rather than individual data elements, and thus back to the circular argument on how keys play a role, especially in reference to representation.

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

I think one of difficulties in discussing the ERM is that from the very beginning many suggested that the ERD was especially valuable as a *design* tool for relational models. Even if a conceptual model is developed using the ERM and with the intention of purposely avoiding a commitment to some type of system, the relative ease in mapping an entity to a table (relation is my preference) along with the iterative steps of conducting functional dependency analysis and normalization will produce "models" closer and closer to the implementation level. These iteratively deeper models can be expressed exactly in the same way as the original conceptual model, but will possess more characteristics reflecting implementation. So I guess someone has to make an explicit distinction since there seems to be a lot of grey area.

> --
> Regards,
> David Cressey

Regards,

Daniel Guntermann Received on Fri Mar 29 2002 - 18:43:34 CET