Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!wuarchive!uunet!pmafire!mica.inel.gov!gem-hy!cdm
From: cdm@gem-hy.Berkeley.EDU (Dale Cook)
Newsgroups: comp.databases
Subject: Re: ER versus dependency normalization methods.
Message-ID: <1990Nov28.172605.24669@inel.gov>
Date: 28 Nov 90 17:26:05 GMT
References: <33445@netnews.upenn.edu>
Sender: news@inel.gov
Reply-To: cdm@gem-hy.Berkeley.EDU (Dale Cook)
Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho
Lines: 59

In article <33445@netnews.upenn.edu>, aaron@grad2.cis.upenn.edu (Aaron
Watters) writes:
|> 
|> Personally, it seems to me that the less mathematical
|> methods of drawing Entity-Relationship diagrams (or other,
|> perhaps more advanced conceptual analysis methods) does
|> as well or better as a database design method, with no
|> mumbo-jumbo involved.
|> 
|> Consider the scenario:  To design a database you first
|> 1.	-draw an ER-diagram of the information of interest
|> 2.	-by inspecting the ER-diagram derive a heap of
|> 	dependencies and attributes.
|> 3.	-toss the lot into a normalization procedure.
|> 4.	-if the output doesn't look like the ER-diagram at
|> 	step 1, go back to (2) and figure out what you
|> 	left out.
|> Close analysis will reveal that steps 2-4 are redundant.
|> 

This is it in a nutshell.  It seems to me that you have described the
conceptual (step 1) to logical (steps 2-4) model development cycle.
I might only add 2 things:

1) Step 2 needs to include more than inspection of the E-R diagram.
   One typically gathers attributes and keys through examination
   of existing reports, processes, and any other information you
   have about the system provided by the users/customers.  I was
   always taught to keep the attribution of the E-R diagram to a
   minimum, so as to keep the conceptual model as simple as possible.
   Too many attributes tend to obscure the purpose of the conceptual
   model: to show the existence of entities and their relationships.

This brings up the second point

2) After completion of step 4, it may become apparent that step 1
   is incomplete/wrong.  My point:  you may need to iterate on all
   four steps.

I agree that there is no need for "mumbo jumbo" when simpler methods
which produce reliable results are used.  In fact, if someone uses
"mumbo jumbo" when simpler methods are available, are sabotaging a 
prime benefit of data modeling: clarity.  If more people understood
and followed the method you have outlined, our lives would all be
easier.

--- Dale Cook    cdm@inel.gov
========== long legal disclaimer follows, press n to skip ===========
^L
Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.