Database Reference
In-Depth Information
A table should have a field that uniquely identifies each of its re-
cords, and each field in the table should describe the subject that
the table represents.
The process I used to formulate this definition is the same one I used to develop my entire
design methodology.
Normalization
Back inthe late 1980s,it occurred tome that the relational model hadbeen inexistence for
almost20yearsandthatpeoplehadbeendesigningdatabasesusingthesamebasicmethod-
ology for about twelve years. (And I'm still surprised we're using it some 20+ years later.)
I was using the traditional design methodology at that time, but I occasionally found it dif-
ficult toemploy.Thetwothingsthat bothered methemostaboutitweretheNormalization
process(asawhole)andtheseeminglyendlessiterationsittooktoarriveataproperdesign.
Of course, these seemed to be sore points with most of the other database developers that
I knew, so I certainly wasn't alone in my frustrations. I thought about these problems for
quite some time, and then I came up with a solution.
I already knew that the purpose of Normalization is to take an improperly or poorly de-
signed table and transform it into a table with a sound structure. I also understood the pro-
cess: Take a given table and test it against the normal forms to determine whether it is
properly designed. If it isn't designed properly, make the appropriate modifications, retest
it, and repeat the entire process until the table structure is sound.
Figure 2.2
shows how I
visualized the process at this point.
