Re: Peter Chen and Charles Bachman

"Laconic2" <laconic2_at_comcast.net> wrote in message news:QNqdnfZap9uTywTdRVn-sw_at_comcast.com...
>
> "Leandro Guimarães Faria Corsetti Dutra" > > an ER model is a "data model"
> but it is not a "database
> > > model".
> >
> > Hair splitting.
> >
>
> No, no, a thousand times NO!
>
> Data analysis is much more pervasive than database design.

I agree.

> Data can be tied
> back to a conceptual model regardless of whether it is in one database or
> another, or even different kinds of databases, whether it's in exchange
in
> the form of XML, CSV, of the responses to SQL SELECT, or in forms or
> reports or wherever.

There is truth in that statement, but I would submit that logical data elements and structures, particularly in the relational model, can be tied back to a reconciliation and harmonization of one or more conceptual models (note: plural). Semantics inherently reflect one's view of the world and that one view doesn't necessarily correspond to another's view of the world. In some cases, we can accept a single view of the world, but with enterprise data management mechanisms, we must at least have the capability to accomodate all views of the world (different conceptual models) that are pertinent.

Moreover, semantics are not necessarily time-independent, leading to another dimension of change in terms of conceptual definition.

>
> In particular, an enterprise could commit itself to a single conceptual
> model, for all data other than encapsulated data. And it could adhere to
> this model even if it continued to use products that don't talk to each
> other.
>
> > An ERD is a diagram. A draft. For presentation. Nothing
> > more.
>
> And ERD is a diagram that represents an ER model. The ER model can be
more
> than the diagram.
> But even if it's only the diagram, so what?
> >
> > 'Common key' is referential integrity, not 'relationships'.
>
> The use of foreign keys to represent relationships is one way to represent
> relationships. There are other ways. For example, in CODASYL, you
define
> a set that defines a relationship between the set owner and the set
members.
> Referential integrity is merely a mechanism for keeping foreign keys from
> getting orphaned.

Relying on referential integrity artifacts, even when properly enforced in a DBMS, would seem to be insufficient in determining a true representation of relationships in my view. Any common attribute domain or sets of common attribute domains across relations will indicate potential relationships that might not be necessarily explicit or intuitively obvious. Moreover, trying to list and make sense of them in a conceptually coherent sense (i.e. business termonology) might be more work than its worth if not done in advance. It's even harder today with current implmentations because SQL domains do not give us a robust logical domain unification from a mechanized standpoint.

• Dan

>
> >
> > So it is not a logical model. At most a conceptual one, and
> > incomplete at that.
>
> Incomplete for what?
>
>
Received on Thu May 06 2004 - 00:43:57 CEST