Normalization Still Matters in System Design

When I wrote Oracle8 Design for UML Object Modeling in 1998, Martin Fowler was my technical editor.  I remember having a very serious discussion with him about whether normalization mattered for UML class diagrams. If you look at Martin’s diagrams in his writings, he clearly does not take normalization very seriously. I thought about this a lot and I think that normalization is still a great idea.

At least it is a great idea if you are using UML class diagrams to help design your database.  I will not insist that class diagrams used to stub out Java classes should be normalized.  That is not my world.

Back in the 1980’s, relational database designers did not take normalization very seriously.  I remember an article in Computer World asserting that normalization was just an academic dream and that  “real databases” could not afford to follow academic guidelines when trying to build a working system.  Designers tended to follow the rules of normalization loosely or not at all. As a result, our relational databases had the same kind of weird anomalous behaviors that their COBOL predecessors had. Starting in the early 90’s, we figured out that normalization was not just an academic dream, but actually moved us towards building working systems that were far easier to maintain than their non-normalized, more informal cousins.

I am not religious about normalization.  If you want to be really formal about the rules, then virtually every system ever built violates 3NF in the ADDRESS table. US states are clearly derivable from zip codes, but no one seems to get upset that they are in the same “tuple.”

Normalization is not the same as good design.  You can have a good design that violates some rules of normalization in a controlled way, and you can have Boyce-Codd Normal Form designs that are a developer’s worst nightmare.

The fact that many OO people tend to think that persistent copies of classes do not need to follow the rules of normalization is a big mistake.

The reason we evolved from not taking normalization seriously to taking it very seriously is that normalized data structures are better for the following reasons:

1. Normalization leads to a well structured set of tables without redundancy.
2. A change to an object’s attribute value only happens in one place.
3. There will be no odd anomalies such as “You can’t create a product unless it is in inventory”.
4. If we all follow the rules, it is easier to come up to speed with a new model, because it is structured in an understandable way.

Denormalized systems each march to the beat of their own drummers.