Lesson 10

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:

1. Explain the requirements for third normal form (3NF)
2. Identify transitive dependencies
3. Normalize a relation to 3NF
4. Describe Codd's 12 criteria for a fully relational RDBMS
5. Explain how Codd's 12 criteria relate to normalization
6. Explain what type of dependencies might require normalization beyond 3NF
7. 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.

This module introduced you to the following terms:

1. third normal form (3NF): A table is in third normal form if it contains no transitive dependencies.
2. denormalization: To move a table to a lower normal form (e.g., from 3NF to 2NF).
3. determinant: An attribute upon which another attribute is functionally dependent.
4. functional dependency: A one-way relationship between two attributes so that, for any unique value of one attribute, there is only one value of the other attribute.
5. third normal form (3NF): A table is in third normal form if it contains no transitive dependencies.
6. transitive dependency: A term derived from the mathematical equation for a transitive property: If a>b and b>c, then a>c. In terms of a database, a transitive dependency refers to a relationship between two entities that is dependent upon a second relationship between one of the first two entities and a third entity.
7. transitivity: Amathematical property which states that if A

The next module discusses joins and user views.

1. normalization to 3NF,
2. Codd's rules,
3. normalization beyond 3NF, and
4. denormalization.

Before you continue to the next module, click the Quiz link below to reinforce your understanding of Third Normal Form - Quiz