Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!metro!usage.csd.unsw.oz.au!ccadfa!ghm
From: ghm@ccadfa.adfa.oz.au (Geoff Miller)
Newsgroups: comp.databases
Subject: Re: ER versus dependency normalization methods.
Message-ID: <2105@ccadfa.adfa.oz.au>
Date: 30 Nov 90 03:34:29 GMT
References: <33445@netnews.upenn.edu> <2095@ccadfa.adfa.oz.au> <1990Nov29.032532.23631@informix.com> <33684@netnews.upenn.edu>
Organization: Computer Centre, University College, UNSW, ADFA, Canberra, Australia
Lines: 40

aaron@grad2.cis.upenn.edu (Aaron Watters) writes:

>In article <1990Nov29.032532.23631@informix.com> randall@informix.com (Randall Rhea) writes:
>>
>> I have
>>a lot of respect for Codd, DeMarco et al., but in a real project, under
>>a real budget, a real computer, and real deadlines, you can't always follow 
>>them to the letter. 
>>Randall Rhea                                          Informix Software, Inc. 

>Issues of respect aside, how does one `follow' them at all?
>I still don't see how one extracts functional dependencies
>from the customer without getting the customer to draw something
>like an ER diagram first.  And once the ER-diagram is drawn,
>why bother with the notion of dependency based normalization
>at all?  I'm purposely adopting a strong position in the hopes
>of extracting a good example from someone (and maybe learning
>something).		-aaron.

But you don't *start* with the final ER diagram.

Before you get to see an ER diagram somone has (hopefully) done a hell of a
lot of work with the customer, helping them to specify their requirements.
ER diagrams, DFDs (Data Flow Diagrams) and other techniques are tools to 
assist in this process, which normally involves a lot of iterations.  One 
of the biggest problems I have found is persuading even willing customers to
accept just how much of *their* time will be involved in going over the 
diagrams and documentation with me to make sure *I* haven't missed something.

In many ways you can regard Data Dictionaries, ER diagrams and other tools
as alternative representations of the same data.  Each form of representation
emphasises something different, and each contains information that the 
others do not, but the better CASE tools will let you transform from one
to the other.  In the process of getting to a final ER diagram I have
effectively done the dependency-based normalisation on the way, because you
don't work exclusively with one form of data representation, be it ER, DFD 
or whatever.

Geoff Miller  (ghm@cc.adfa.oz.au)
Computer Centre, Australian Defence Force Academy