This module covered database normalization up to 3NF, explained how normalizing a database to 3NF meets Codd's 12 criteria for a fully relational database, noted there are normal forms beyond 3NF, and discussed denormalization.
Having completed this module, you should be able to:
- Explain the requirements for third normal form (3NF)
- Identify transitive dependencies
- Normalize a relation to 3NF
- Describe Codd's 12 criteria for a fully relational RDBMS
- Explain how Codd's 12 criteria relate to normalization
- Explain what type of dependencies might require normalization beyond 3NF
- Define denormalization and identify when it might be useful
The academic definition of normalization is the accepted format of Normal Forms definition.
I like to label normalization as academic because the precise definitions of Normal Forms are often misunderstood in a
commercial environment. In fact, the truth is that language use in the exact definitions for Normal Forms is
so very precise and carefully worded that problems are caused.
Many database designers do not understand all the details of normalization.
This may be a result of the precise use of language. There are a multitude of database architects who do not speak English, have a limited command of the English language, and should not be expected to be well-versed in the academic language used with normalization.
In general, normalization removes duplication and minimizes redundant chunks of data. The result is
better organization and more effective use of physical space, among other factors.
Normalization is not always the best solution. For example, in data warehouses
, there is a completely
different approach. In short, normalization is not the only thing that is important in relational database model design.
It is just as important to understand Normal Forms from a more academic, more precise but possibly less commercially viable
perspective. The problem with the academic approach to normalization is that it seems to insist on always
expecting a designer to apply every Normal Form layer in every situation.
In my experience, in a commercial environment this is nearly always a mistake.
The trouble with the deeper and more precisely refined aspects of normalization is that normalization tends to over-define itself for the sake of simply defining itself further.