When creating a database, it is often useful to learn from the mistakes of
others. Within the Relational Database Model, a set of rules has been established
to aid in the design of tables that are meant to be connected through relationships.
This set of rules is known as Normalization.

In this Tutorial we will address the first of five normal forms, and
the ways in which normalizing your database will help prevent problems as you
add to it.

The concept of database normalization is not unique to any particular Relational
Database Management System. It can be applied to any of several implications
of relational databases including Microsoft Access, dBase, Oracle, etc. The
benefits of Normalizing your database include:

• Avoiding repetitive entries</li>
• Reducing required storage space</li>
• Preventing the need to restructure existing tables to accommodate new data.</li>
• Increased speed and flexibility of queries, sorts, and summaries.</li>

There are five normal forms in all, each progressively building on its predecessor.
In order to reach peak efficiency, it is recommended that relational databases
be normalized through at least the third normal form. In order to normalize
a database, each table should have a primary key field that uniquely identifies
each record in that table. A primary key can consist of a single field (an ID
Number field for instance) or a combination of two or more fields that together
make a unique key (called a multiple field primary key).

For a table to be in first normal form, data must be broken up into the smallest
units possible. For example, the following table is not in first normal form.

To conform to first normal form, this table would require additional fields.
The name field should be divided into first and last name and the address should
be divided by street, city state, and zip like this.

In addition to breaking data up into the smallest meaningful values, tables
in first normal form should not contain repetitions groups of fields such as
in the following table.

The problem here is that each representative can have multiple clients not
all will have three. Some may have less as is the case in the second record,
tying up storage space in your database that is not being used, and some may
have more, in which case there are not enough fields. The solution to this is
to add a record for each new piece of information.

Notice the splitting of the first and last name fields again.

This table is now in first normal form. Note that by avoiding repeating groups
of fields, we have created a new problem in that there are identical values
in the primary key field, violating the rules of the primary key. In order to
remedy this, we need to have some other way of identifying each record. This
can be done with the creation of a new key called client ID.

This new field can now be used in conjunction with the Rep ID field to create
a multiple field primary key. This will prevent confusion if ever more than
one Representative were to serve a single client.

This now sets us up for our next installment, the second and third normal forms.