Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!pyramid!voder!blia!billc
From: billc@blia.UUCP
Newsgroups: comp.databases
Subject: Re: Normalized Databases
Message-ID: <2010@blia.BLI.COM>
Date: Thu, 2-Apr-87 16:07:56 EST
Article-I.D.: blia.2010
Posted: Thu Apr  2 16:07:56 1987
Date-Received: Sat, 4-Apr-87 19:47:40 EST
References: <43239@beno.seismo.CSS.GOV>
Distribution: na
Organization: Britton Lee, Los Gatos, CA
Lines: 49
Keywords: normal form, relational
Summary: normalization

In article <43239@beno.seismo.CSS.GOV>, tiberio@seismo.CSS.GOV (Mike Tiberio) writes:
> ... that we redesign our database 
> to a greater or highest normal form. They state we will enjoy the following
> qualities when this is done.
> 
> 1) The ammount of space required to store the data is lowest.

This is true.  However, you pay a performance penalty, which I'll talk 
about below.  It's the old space vs. speed business.

> 2) The ability to update the database is greatest.

I'm not at all sure what is meant by this.  I don't think this makes the
schema any easier to change.  You can build in some better integrity 
checking, but I don't want to go into that now, since there are other
options for those who choose non-normalized schemas (schemae?).

> 3) Explaining the database is simplest.

I also strongly disagree.  Try to write a tutorial using a heavily-normalized
schema as the example database!

Normalization is a religious issue.  I know a number of people who strongly
favor it, and it does indeed have its place.  However, I think there are
some good counter-arguments for CERTAIN situations.  (No, I am not
anti-normalization, but I am also not a normal-form worshipper.)

The biggest disadvantage is in processing time.  Modelling has shown that
the stronger the normalization, the poorer the overall performance
of the database.  More normalization means more joins.  

Another disadvantage is that a heavily normalized database can be 
difficult to tune.  There are many ways of keying together two relations.
SOme of them can get pretty slow.  It takes more adminstrative 
"cleverness" to handle a heavily-normalized schema.

And now, the good stuff.  Don't blindly stash everything in one giant
table, there are many situations where normalization pays off.
A large amount of fairly redundant information that is infrequently 
accessed is clearly a good candidate for spinning off into its own 
relation.  Normalization also gives richer semantics and greater
flexibility -- you can't do one-to-many relationships without 
normalization.

-- 
W.H.Coffin.  billc@blia.BLI.COM
 Or, if you really like source routing, try ucbvax!{mtxinu|ucsfcgl}!blia!billc
 >> the usual disclaimer about my employer and my wretched opinions. <<
 >> the usual witticisms that swell netnews to ridiculous proportions. <<