Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!well!mjr
From: mjr@well.UUCP
Newsgroups: comp.databases
Subject: Re: Normalized Databases
Message-ID: <2869@well.UUCP>
Date: Sun, 5-Apr-87 10:28:11 EST
Article-I.D.: well.2869
Posted: Sun Apr  5 10:28:11 1987
Date-Received: Wed, 8-Apr-87 04:04:04 EST
References: <43239@beno.seismo.CSS.GOV>
Reply-To: mjr@well.UUCP (Matthew Rapaport)
Distribution: na
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 27
Keywords: normal form, relational

In article <43239@beno.seismo.CSS.GOV> tiberio@seismo.CSS.GOV (Mike Tiberio) writes:
>At our facility we have a certain large investment in a relational database
>design that is not in the highest normal form. We have some folks proposing
>that we redesign our database (and no doubt out database interface software)
>to a greater or highest normal form. They state we will enjoy the following
>qualities when this is done.
> *** etc. ***

Normal form is better for many of the reasons you state, AND because
when you update an attribute, you only have to do it ONCE as it only
appears in ONE table and not in many...   Also, each "thing" you are
describing in the real world, while it may appear in several tables
(say invoices in one table, and invoice lines in another), there is
a clear cut way to distinguish the rows (tuples) that belong to a
(represent) particular thing in the real world.

The two main justifications for NOT normalizing are 1) Performance
(something you query a hundred times a day say may take too long
if parts of it are scattered across many tables), and 2) recoverability
(if you loose your only copy what happens...).  For an excellent
discussion of these and other aspects of data-base design, see
Daniel Martin's ADVANCED DATABASE TECHNIQUES.  This book is about
Entity-Relationship modeling generally, but it does have several
chapters devoted to general issues such as those mentioned above!
(that's MIT Press, 1986) Or, I happen to be writing a column
on the subject of DBMSs generally in Computer Language Magazine.
Feel free to write to mjr@well or ptsfa!well!mjr, etc...