Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!cert!netnews.upenn.edu!grad2.cis.upenn.edu!aaron
From: aaron@grad2.cis.upenn.edu (Aaron Watters)
Newsgroups: comp.databases
Subject: ER versus dependency normalization methods.
Message-ID: <33445@netnews.upenn.edu>
Date: 26 Nov 90 19:48:39 GMT
Sender: news@netnews.upenn.edu
Reply-To: aaron@grad1.cis.upenn.edu (Aaron Watters)
Organization: University of Pennsylvania
Lines: 27

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.