Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!rpi!crdgw1!uunet!pmafire!mica.inel.gov!gem-hy!cdm
From: cdm@gem-hy.Berkeley.EDU (Dale Cook)
Newsgroups: comp.databases
Subject: Re: Balancing Normalization with Performance
Message-ID: <1990Nov29.225901.11834@inel.gov>
Date: 29 Nov 90 22:59:01 GMT
References: <1092@cortex.med.jhu.edu> <1990Nov20.190315.13505@informix.com> <33265@netnews.upenn.edu> <1990Nov21.204921.11162@inel.gov> <2020@meaddata.meaddata.com>
Sender: news@inel.gov
Reply-To: cdm@gem-hy.Berkeley.EDU (Dale Cook)
Distribution: usa
Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho
Lines: 46

In article <2020@meaddata.meaddata.com>, gordon@meaddata.com (Gordon
Edwards) writes:
|> 
|> IMHO, unjustified normalization refers to normalization for the sake of
|> normalization.  For example, getting a design in 3NF is adequate to account
|> for almost all anomolies.  Knowing that further normalization will lead to 
|> more joins to get any useful work done,  I usually stop at 3NF.  Remember

If what you mean by "normalization for the sake of normalization" is 
"normalization beyond the point of diminishing return", I'll buy that.
But you can do that in going from 2NF to 3NF as well.  It all depends
on understanding your application.  Ensuring 4 or 5NF will probably
only pay off for large, long-lived and/or extremely complex databases.

|> economies of scale, taking a design from 3NF to BCNF will probably take more
|> work that getting the design in 3NF to start with and will almost certainly
|> incurr a greater performance penalty.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is not generally true.  4NF is usually pretty subtle, and involves
improper attribution.  The first half of your sentence really says it.  
It is often not worth the effort to _ensure_ 4NF.  
|> 
|> In fact, most of the design courses that were developed by DBMS vendors (at
|> least that I have seen) only teach normalization to 3NF.
|> 

This is because 3NF *USUALLY* implies 4NF & 5NF.

Remeber:  We normalize to maximize integrity and stability, and minimize
data redundancy.  We denormalize _with caution_ for environmental reasons,
which should be justified through weighing the alternatives and knowing
the possible impacts.

--- 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.