Click above to get retro games delivered to your door ever month!

  Normalising a database means learning to see the trees in the forest.
  Each invoice as described above in fact contains several different
  types or species of data -- and this is precisely the problem. The
  customer data is combined with the invoice data, which in turn is
  combined with the items data.

  But wait a minute. Aren't the items ordered part of the invoice itself?
  Without them, what point does the invoice serve? Yes, they are part of the
  invoice, in human terms, but viewed as data types they are a separate
  entity. (Even in paper systems, this fact is modeled by the items area,
  which usually appears in printed rows with titles above each column, and
  perhaps surrounded by a box.)

  By separating the data into tables corresponding to the entities
  involved, we make several huge gains. First, all the customer data is
  stored in one place, and never needs to be typed in again. Second, all the
  invoice data is stored in one place, so it's easy to find and takes up very
  little disk space. Finally, all the items are stored in a separate table,
  so we waste no disk space on blanks. Even more important, we can now search
  for individual items very quickly. We could find the water distillers
  sold in a second or two, even if we've sold millions of items.

  Only one problem remains: now that we've pushed Humpty Dumpty off the wall,
  how do we get him back together again? The answer lies in links between
  the tables.

  Normalisation is the systematic replacement of all large redundancies with
  small redundancies. We remove all the customer information from the invoice
  file, leaving only one trace -- a customer number or code, often called
  something like Account Number. Then we remove all the item information
  from the orders file, placing it in a separate table, and adding a new
  column to it -- Order Number.

  Now let's take this one step further. Consider the items section, which
  contains a column for quantity, another for description, another for price,
  and perhaps for tax and extended amount. Here's another redundancy we can
  eliminate. Why should our invoicing staff ever have to type in the product
  description, or for that matter, the price?

  So we normalise this table in turn, breaking it into two: items and
  products. To the product table we push the description and price. To the
  items table we add a column, Product Number. Now the items table is
  considerably smaller, so movement within it will be faster. We also gain in
  that we can now expand the product table to hold such important information
  as quantity in stock and vendor.

  By now, you're probably getting a good feel for this. We'll push the vendor
  information into its own table, leaving only a column for vendor number
  behind in the product table. (After all, most vendors supply products.) By
  separating vendors from products, we also make it easy to produce purchase
  orders for each vendor, listing all the items we need to order.

  So. What began as a single piece of paper has become, through the process
  of normalisation, five distinct tables, linked together in a relational
  tree.