Re: Peter Chen and Charles Bachman

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in

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

Agreed. In particular, a correctly expressed relational model will be in 1NF. If I've read your description of PICK correctly, this would be at best "orthogonal" and at worst counterproductive in terms of the later PICK implementation.

Although some ER proponents argue for normalizing data in an ER model, many others do not. I tend to argue against normalizing data in the ER model. In particular an entity, an order, can contain line item data that is multivalued, or in 1NF parlance a "repeating group". If you implement in CODASYL you'll do one thing with it, if you implement in relational (or "tabular") you'll normalize by decomposition, and if you implement in PICK you'll do yet a third thing with it.

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

As I said above, I'm against normalizing during analysis. Normalization belong in the solution domain, not the problem domain, IMO.

The reason, IMO, that UML tends to be directed more towards OO design is that the OO community has not put enough attention into the difference between OOA and OOD.

I don't know what people who don't like ERD's do for analysis. When I first joined this forum, there was a lively debate between the OO enthusiasts and the regulars about the subject of subject matter expertise. The prevailing opinion among the OO enthusiasts seemed to be that there wasn't time for the implementors to learn the subject matter, so the best thing to do was to design data structures that were subject matter independent.

That's even farther from my way of thinking than your way of thinking is. Received on Wed May 05 2004 - 22:52:17 CEST