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

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
So, to reach the third normal form, we just need to drop off the TotalPrice column and compute it
when needed.
Other Normal Forms
226
Derived data is one of the places that you’ll see me “de-normalize” data most often.
Why? Speed! A query that reads WHERE TotalPrice > $100 runs faster than one
that reads WHERE Qty * UnitPrice > 50 — particularly if we are able to index our
computed TotalPrice.
On the other side of this, however, I do sometimes take more of a hybrid approach
by utilizing a computed column and letting SQL Server keep a sum of the other two
columns for us (you may recall us using this idea for our the PreviousSalary example
in the Employees table of the Accounting database in Chapter 5). If this is a very
important column from a performance perspective (you’re running lots of columns
that filter based on the values in this column), then you may want to add an index to
your new computed column. The significance of this is that the index “materializes”
the computed data. What does that mean? Well, it means that even SQL Server doesn’t
have to calculate the computed column on the fly — instead, it calculates it once
when the row is stored in the index, and, thereafter, uses the precalculated column.
It can be very fast indeed, and we’ll examine it further in Chapter 9. That said, there
is a trade off (if there wasn’t, everyone would do it this way all the time, right?) —
space. You’re storing data that doesn’t need to be stored, and if you do that to every
possible piece of derived data, then it can really add up. More space means more
data to read, and that can mean things actually get slower. The point here is to weigh
your options, and make a balanced choice.
There are a few other forms out there that are considered, at least by academics, to be part of the normalization
model. These include:
❑ Boyce-Codd (considered really just to be a variation on third normal form): This one tries to
address situations where you have multiple overlapping candidate keys. This can only happen if:
a. All the candidate keys are composite keys (that is, it takes more than one column
to make up the key).
b. There is more than one candidate key.
c. The candidate keys each have at least one column that is in common with
another candidate key.
This is typically a situation where any number of solutions works, and almost never gets logically
thought of outside the academic community.
❑ Fourth Normal Form: This one tries to deal with issues surrounding multi-valued dependence.
This is the situation where, for an individual row, no column depends on a column other than
the primary key and depends on the whole primary key (meeting third normal form). However,
there can be rather odd situations where one column in the primary key can depend separately
on other columns in the primary key. These are rare, and don’t usually cause any real problem.
As such, they are largely ignored in the database world, and we will not address them here.