Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
So, now you have second normal form. All of our columns depend on the entire key. I’m sure you won’t
be surprised to hear that we still have a problem or two though — we’ll deal with them next.
The Third Normal Form
224
This is the relative end of the line. There are technically levels of normalization beyond this, but none
that get much attention outside of academic circles. We’ll look at those extremely briefly next, but first
we need to finish the business at hand.
I mentioned at the end of our discussion of the second normal form that we still had problems — we still
haven’t reached the third normal form (3NF). The third normal form deals with the issue of having all
the columns in our table not just be dependent on something — but dependent on the right thing. The
third normal form has just three rules to it:
❑ The table must be in 2NF (I told you this was a building block thing).
❑ No column can have any dependency on any other non-key column.
❑ You cannot have derived data.
We already know that we’re in the second normal form, so let’s look at the other two rules.
First, do we have any columns that have dependencies other than the primary key? Yes! Actually, there
are a couple of columns that are dependent on the PartNo as much as, if not more than, the primary key
of this table. Weight and Description are both entirely dependent on the PartNo column — we again
need to split into another table.
Your first tendency here might be to also lump UnitPrice into this category, and you would be partially
right. The Products table that we will create here can and should have a UnitPrice column in it —
but it will be of a slightly different nature. Indeed, perhaps it would be better named ListPrice, as it is
the cost we have set in general for that product. The difference for the UnitPrice in the OrderDetails
table is twofold. First, we may offer discounts that would change the price at time of sale. This means
that the price in the OrderDetails record may be different than the planned price that you will keep
in the Products table. Second, the price we plan to charge will change over time with factors such as
inflation, but changes in future prices will not change what we have charged on our actual orders of the
past. In other words, price is one of those odd circumstances where there are really two flavors of it —
one dependent on the PartNo, and one dependent on the primary key for the OrderDetails table (in
other words OrderID and LineItem).
First, we need to create a new table (we’ll call it Products) to hold our part information. This new table
will hold the information that we had in OrderDetails that was more dependent on PartNo than on
OrderID or LineItem:
PartNo (PK) Description Wt
1A4536 Flange 6
OR2400 Injector .5
OR2403 Injector .5