Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!zephyr.ens.tek.com!tektronix!sequent!lugnut
From: lugnut@sequent.UUCP (Don Bolton)
Newsgroups: comp.databases
Subject: Re: ER versus dependency normalization methods.
Message-ID: <47315@sequent.UUCP>
Date: 28 Nov 90 00:19:46 GMT
References: <33445@netnews.upenn.edu>
Reply-To: lugnut@sequent.UUCP (Don Bolton)
Organization: Sequent Computer Systems, Inc
Lines: 44

In article <33445@netnews.upenn.edu> aaron@grad1.cis.upenn.edu (Aaron Watters) writes:
>I've always suspected that the notion of designing a 
>database using data dependancies -- ie, the notion
>that you start with a pile of attributes and functional
>(and/or other) dependencies and proceed to slice up
>the database into this or that normal form -- was somewhat
>silly and artificial.
>
>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.
>
>Now I'm not interested in getting into some high level
>shouting match -- but could someone come up with a simple
>compelling example which demonstrates why I'm wrong about
>this?		-aaron.

I'll take a stab at this...

By proper identification of the information of interest and a
proper ER-diorama right off, you substansially reduce the "time
to market" on your project. Other more, ahem "structured" programmers
will find this bothersome, un-dignified, and un-($nationality).

You might well find yourself knifed in your sleep. :-)

Actually, it may take this involved of a process for those that
can only see the "mechanical" side of the data requirements, on 
the other hand if the designer is more attuned to the "human"
use of the data, then steps 2-4 are indeed redundant. A lot really
depends on ones background and understanding how the data is used
by the people.