Normalization is the process of structuring the tables and columns in your schema to avoid having certain dependency constraints (functional dependencies, multivalued dependencies, and join dependencies).

It is possible to write an entire chapter or book on normalization [Dutka and Hanson 1989], though hard to make it fun to read. The odd thing about normalization is that it is really a state, not a process. The progress from first to second to third and so on is illusory ordering of a much more straightforward approach: find and eliminate structural dependencies that cause problems. There is no benefit at all to working through the various normal forms. Instead, you should understand the mathematics of dependencies, then focus on the practical design techniques that eliminate them as a whole.

Before getting into the dependencies, you should note that an OO design, as reflected in the UML data model, pretty much automatically removes most dependencies. The whole idea of object identity and the construction of cohesive hierarchies of classes tends to structure your data into related tables rather than into jumbled-together single tables with lots of interdependencies between the columns. Starting with OO (or even ER) design is much more likely to yield a normalized database than not. This fact impresses some designers so much they believe you can dispense entirely with the theory of normalization [Blaha and Premerlani 1998, pp. 273 274]. While I wouldn't go that far, it's fair to say that normalization is not really a worry if you...