Re: By The Dawn's Normal Light

"Laconic2" <laconic2_at_comcast.net> wrote in message news:lPGdneIrXNEeD-fcRVn-1Q_at_comcast.com...
>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message
> news:cldvjl$hj9$1_at_news.netins.net...
>
> > On these two points I am in complete agreement. It sounds like Laconic2
> is
> > there too (at least on 1NF).
>
> I am with you as far as terminology is concerned. Not necessarily as far
as
> the value of concepts is concerned.
>
> I did go through a brief period when I tried to talk to non technical
people
> in terms of tables in 1NF. I quickly gave up, especially when I noted
that
> you can talk to people about data in an ER model without ever getting
> involved in normalization.
>
> There are people for whom an invoice is an invoice header, and a bunch of
> invoice items. Talking to these people about repeating groups,
subentities,
> or 1NF is a complete waste of their time and mine. ER is my way of
avoiding
> that pitfall. Your way is different.

I'm definitely a fan of ERDs. In fact, in trying to teach OOAD right now with UML 2.0 diagrams, I had to figure out how to handle my two favorite tools -- DFDs and ERDs. Class diagrams really did work quite well for ERDs, with the relationships on lines instead of triangles, for example.

As an aside, DFD's in general can be handled with UML activity diagrams, but there is nothing that corresponds to a DFD context diagram. I ended up using a Use Case diagram and putting data flow type information on the lines that shouldn't have such info. It worked-ish. For completeness, I briefly showed off a "real" context diagram and ERD.

> The good news is that converting an ER model into an SQL model is so
> straightforward that an engine like DA can do it automatically. And even
if
> you don't have a tool like DA, it's still a simple exercise.

And that is where we differ. Yes, we can discuss the business with uses and an ERD up until the point where we want to show them how to get their information back out of the system. With systems that have more than, say, 400 tables, I have never seen a satisfactory implementation of a set of views that satisfies the users with both data and performance. It makes them think differently than the ERD does. If the logical model and the language for managing that data can all work with the data the way that makes sense to human beings, then the computer can decide whether to put the data in a relational structure or whatever. I'm interested in the interface between the data and the person -- that is, the logical model and the tools that work with it.

--dawn Received on Sat Oct 23 2004 - 19:59:13 CEST