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

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
Let’s start off by saying that there are six normal forms. For those of you who have dealt with databases
and normalization some before, that number may come as a surprise. You are very likely to hear that a
fully normalized database is one that is normalized to the third normal form — doesn’t it then follow
that there must be only three normal forms? Perhaps it will make those same people who thought there
were only three normal forms feel better that in this book we’re only going to be looking to any extent at
the three forms you’ve heard about, as they are the only three that are put to any regular use in the real
world. I will, however, take a brief (very brief) skim over the other three forms just for posterity.
We’ve already looked at how to create a primary key and some of the reasons for using one in our
tables — if we want to be able to act on just one row, then we need to be able to uniquely identify that row.
The concepts of normalization are highly dependent on issues surrounding the definition of the primary
key and what columns are dependent on it. One phrase you might hear frequently in normalization is:
The key, the whole key, and nothing but the key.
The somewhat fun addition to this is:
The key, the whole key, and nothing but the key, so help me Codd!
This is a super-brief summarization of what normalization is about out to the third normal form. When
you can say that all your columns are dependent only on the whole key and nothing more or less, then you
are at the third normal form.
Let’s take a look at the various normal forms and what each does for us.
Before the Beginning
You actually need to begin by getting a few things in place even before you try to get your data into first
normal form. You have to have a thing or two in place before you can even consider the table to be a true
entity in the relational database sense of the word:
❑ The table should describe one and only one entity. (No trying to shortcut and combine things!)
❑ All rows must be unique, and there must be a primary key.
❑ The column and row order must not matter.
The place to start, then, is by identifying the right entities to have. Some of these will be fairly obvious,
others will not. Many of them will be exposed and refined as you go through the normalization process.
At the very least, go through and identify all the obvious entities.
If you’re familiar with object-oriented programming, then you can liken the most logical top-level entities
to objects in an object model.
Let’s think about a hyper-simple model — our sales model again. To begin with, we’re not going to
worry about the different variations possible, or even what columns we’re going to have — instead, we’re
just going to worry about identifying the basic entities of our system.
First, think about the most basic process. What we want to do is create an entity for each atomic unit that
we want to be able to maintain data on in the process. Our process then, looks like this: a customer calls
or comes in and talks to an employee who takes an order.
217