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

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
Tables
This is going to seem beyond basic, but let’s briefly review what exactly a table is. We’re obviously not
talking about the kind that sits in your kitchen, but, rather, the central object of any database.
A table is a collection of instances of data that have the same general attributes. These instances of data are
organized into rows and columns of data. A table should represent a “real-world” collection of data (often
referred to as an entity), and will have relationships with information in other tables. A drawing of the various
entities (tables) and relationships (how they work together) is usually referred to as an Entity-Relationship
Diagram — or ER Diagram. Sometimes the term “ER Diagram” will even be shortened further down to ERD.
By connecting two or more tables through their various relationships, you are able to temporarily create
other tables as needed from the combination of the data in both tables (you’ve already seen this to some
degree in Chapters 4 and 5). A collection of related entities are then grouped together into a database.
Keeping Your Data “Nor mal”
216
Normalization is something of the cornerstone model of modern OLTP database design. Normalization
first originated along with the concept of relational databases. Both came from the work of E. F. Codd
(IBM) in 1969. Codd put forth the notion that a database “consists of a series of unordered tables that can
be manipulated using non-procedural operations that return tables.”
Several things are key about this:
❑ Order must be unimportant.
❑ The tables would be able to “relate” to each other in a non-procedural way (indeed, Codd called
tables “relations”).
❑ That, by relating these base tables, you would be able to create a virtual table to meet a new need.
Normalization was a natural offshoot of the design of a database of “relations.”
The concept of normalization has to be one of most over-referenced and yet misunderstood concepts in
programming. Everyone thinks they understand it, and many do in at least its academic form. Unfortunately,
it also tends to be one of those things that many database designers wear like a cross — it is
somehow their symbol that they are “real” database architects. What it really is, however, is a symbol
that they know what the normal forms are — and that’s all. Normalization is really just one piece of a
larger database design picture. Sometimes you need to normalize your data — then again, sometimes
you need to deliberately de-normalize your data. Even within the normalization process, there are often
many ways to achieve what is technically a normalized database.
My point in this latest soapbox diatribe is that normalization is a theory, and that’s all it is. Once you
choose whether to implement a normalized strategy or not, what you have is a database — hopefully the
best one you could possibly design. Don’t get stuck on what the books (including this one) say you’re
supposed to do — do what’s right for the situation that you’re in. As the author of this book, all I can do
is relate concepts to you — I can’t implement them for you, and neither can any other author (at least
not with the written word). You need to pick and choose between these concepts in order to achieve the
best fit and the best solution. Now, excuse me while I put that soapbox away, and we’ll get on to talking
about the normal forms and what they purportedly do for us.