Page Navigation: [ Forms of normalization | Additional normalization tips ]
[ Back to Troubleshooters.Com ]
Other Navigation: [ About Steve Litt | Email Steve Litt | Home Page ]
Steve Litt is the author of the Universal Troubleshooting Process Courseware,
which can be presented either by Steve or by your own trainers.
He is also the author of Troubleshooting Techniques of the Successful Technologist,
Rapid Learning: Secret Weapon of the Successful Technologist, and Samba Unleashed.
Normalization
Well normalized data makes programming (relatively) easy, and works very well in multi-
platform, enterprise wide environments. Non-normalized data leads to heartbreak.
Normalization: The first three forms
First Normal Form:
No repeating groups. As an example, it might be tempting to make an invoice table with
columns for the first, second, and third line item (see above). This violates the first normal form,
and would result in large rows, wasted space (where an invoice had less than the maximum
number of line items), and *horrible* SQL statements with a separate join for each repetition of
the column. First form normalization requires you make a separate line item table, with it's own
key (in this case the combination of invoice number and line number) (See below).
Second Normal Form:
Each column must depend on the *entire* primary key. As an example, the customer
information could be put in the line item table (see above). The trouble with that is that the
customer goes with the invoice, not with each line on the invoice. Putting customer information
in the line item table will cause redundant data, with it's inherant overhead and difficult
modifications. Second form normalization requires you place the customer information in the
invoice table (see below).
Third Normal Form:
Each column must depend on *directly* on the primary key. As an example, the customer
address could go in the invoice table (see above), but this would cause data redundancy if several
invoices were for the same customer. It would also cause an update nightmare when the
customer changes his address, and would require extensive programming to insert the address
every time an existing customer gets a new invoice. Third form normalization requires the
customer address go in a separate customer table with its own key (customer), with only the
customer identifier in the invoice table (see below).
[ Troubleshooters.Com | Top of page | Home page | Email Steve Litt ]
Additional normalization tips
Make a table for each list
Do this right away. It will save a fortune in time. Go through the department or enterprise,
ferreting out all lists. Document them. Each should be a table if their information is needed, and
if practical.
Use non-meaningful primary keys
If employee numbers starting with C mean the person's stationed in Chicago, and the person
moves to Los Angeles, what do you do with his employee number. Making primary keys non-
meaningful means changes in environment or business rules can't render them ineffective.
[ Troubleshooters.Com | Top of page | Home page | Email Steve Litt ]
Copyright (C)1995, 1996 by Steve Litt. See the copyright notice for any restrictions on
access and reuse of information provided in the Litt's Tips web pages.
