Re: Peter Chen and Charles Bachman

"Laconic2" <laconic2_at_comcast.net> wrote in message news:9ZGdnXjm_856pwTdRVn-ug_at_comcast.com...
> > That should be qualified by 'all logical or conceptual
> > aspects, that is apart of actual data and physical details; perhaps
> > what is commonly called the "structure" of the database'.
>
> Now we're getting somewhere. I can accept this. In this context. let me
> say this: an ER model is a "data model" but it is not a "database
model".
> That is to say, all the relationships in the data that are inherent in
the
> composition of the data, whether it's adjacency, navigational, or by
common
> key data, are omitted from this model.

agreed.

> To me, that's precisely what makes it valuable. A discussion between
SMEs
> and DB designers concening an ER model will focus on whether the data
values
> "make sense" in terms of the entities, relationships and attributes
> presented in that model. Questions about whether to model relationships
> using key data, CODASYL style networks, trees, or PICK structures can be
> left out of the discussion, because these things are not in the model.

Yes, an ERD can help communication among participants before any discussion of implementation. A relational model really targets a relational implementation, even though others will disagree. A COMPLETE relational model with all constraints and recognition of where there are parent-child relationships, in particular, could be implemented in many different databases (even those that are not relational) but it is not a good starting point for a discussion of the high level entities being discussed during the analysis phase of a project.

> That means that once you have an ER model that is satisfactory to both the
> SMEs and the designers, you are still free to choose an implementation,
> without having to "undo" decisions made in the ER model. As has been
said
> before in this forum, it's the difference between analysis and design.

Yup exactly! UML diagrams can do similarly, but tend to be more directed to OO design so I find using simple ER diagrams to "model" the data at a high level is one of the best ways of facilitating understanding of a subject area. But I'll admit that I honestly don't know what the relational model has to offer during the analysis phase of a project. Is there any reason why such topics as normalization would be needed or even useful during the analysis phase of a software project? What do those who don't like ERDs do instead in the early analysis phase?
--dawn Received on Wed May 05 2004 - 21:35:17 CEST