Product_Picture1
Product_Name2
Product_Cost2
Product_Picture2
Order_Number
Order_Date
Order_Quantity
Shipper_Name
In Table 5.1, you have several repeating columns. They mostly deal with products. So, according to the
rule, you must eliminate the repeaters and give them their own table. That's easy to do. The resulting
database tables are shown in Table 5.2.
Table 5.2 Eliminating Data Repetition in a Database
Customers Products
Customer_ID Product_Name
Last_Name Product_Cost
First_Name Product_PictureAddress (^)
Order_Number (^)
Order_Date (^)
Order_Quantity (^)
Order_Shipper (^)
Shipper_Name (^)
Now there are two tables. There still is a problem. There is no way currently to relate the data from the
original table to the data in the new table. To do that, a key must be added to the second table to
establish the relationship. To do this, add a primary key to the Products table called Product_ID,
and add a key to Customers table that relates the Products table to the Customers table. The
Product_ID field is an ideal candidate. The resulting tables resemble Table 5.3:
Table 5.3 First Normal Form
Customers Products
Customer_ID Product_ID
Product_ID Product_Name
Last_Name Product_Cost
First_Name Product_Picture
Address
Order_Number (^)
Order_Date
Order_Quantity (^)
Shipper_Name
Now, a one-to-many relationship has been established. This represents what the database will be doing
in real life. The client will have many products to sell, regardless of how many customers there are to
buy them. Also, a customer still needs to have ordered a product to be a customer. You are no longer
obligated to add a new customer every time you add a new product to your inventory.
Bringing a database to First Normal Form solves the multiple column heading problem. Too often,
inexperienced database designers will do something similar to the non-normalized table in today's first
example. They will create many columns representing the same data over and over again. In an electric
company in the Northwest, there was a database that tracked nuclear power plant parts. The table in
their database, which contained the part numbers, had a repeated column that numbered well into the
30s. Every time a new item was stored for this part, they created a new column to store the information.
Obviously, this was a poorly designed database and a programmer's/administrator's nightmare.
Normalization helps to clarify the database and break it down into smaller, more understandable pieces.
Instead of having to understand a huge, monolithic table that has many different aspects, you only have