Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!rice!uw-beaver!sumax!polari!6sceng!6sigma!zuker
From: zuker@6sigma.UUCP (Hunter Zuker)
Newsgroups: comp.databases
Subject: Re: ER versus dependency normalization methods.
Message-ID: <358@6sigma.UUCP>
Date: 6 Dec 90 20:25:30 GMT
References: <33445@netnews.upenn.edu> <47315@sequent.UUCP>
Organization: Six Sigma CASE, Inc.
Lines: 35

>In article <33445@netnews.upenn.edu> aaron@grad1.cis.upenn.edu (Aaron Watters) writes:
>>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.

Well my only concern with this is the ability to go from step 2 to step 3.
From what I've seen of ER diagrams there is not enough information to go
to third normal form.  You easily get 1st normal form and might scramble
to 2nd.  But an automized normalization procedure doesn't get enough
information from ER diagrams to go to third normal form.

I know this because we are doing just that right now.  We have a normalization
routine which works with an Extended Relational Analysis like model.  We
are now converting it to work with a couple of ER diagrammers.  In general
there is not enough information about keys.  Like which is the primary key,
or which keys are concatenated.  This makes it difficult to go to 2NF or 
3NF.

Other than that your cycle works just fine.

Hunter Zuker
-- 
Hunter Zuker		Six Sigma CASE, Inc.	 13456 SE 27, Suite 210
zuker@6sigma.UUCP       (206) 643-6911           Bellevue, WA 98005-4211