Re: Peter Chen and Charles Bachman

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

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.

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. Received on Wed May 05 2004 - 21:06:11 CEST