Normalisation is most useful in bottom-up approaches to database design, as the steps progressively repair problems associated with the faulty designs that can easily arise. A top-down approach, e.g. using an Entity-Relationship Model, is less likely to display the faults that require a technique such as normalisation to repair.
So, consider a poorly considered design and then progress through the steps
to improve the design.
1NF |
Extract repeating data |
An attribute shouldn't contain multiple values of the same type. Note: this is not the same as multiple attributes with semantically identical function (such as [Note1], [Note2], [Note3].. etc, but while this doesn't break 1NF condition, it is poor design.
|
2NF |
Extract redundant data |
If an attribute depends on only part of
a composite key, then the other part will be repeated, potentially many
times. |
3NF |
Extract data unrelated to the whole key |
Attributes should be facts about the key, not just part of composite key or independent of the key entirely. |
BCNF |
Boyce-Codd Normal Form |
In tables that have more
than one multi-valued candidate key, the attributes of those keys should
be independent |
4NF |
Isolate independent multiple relationships |
No table may contain two or more 1:n or n:m relationships that are not directly related. |
5NF |
Isolate semantically related multiple relationships |
As for 4NF, but focuses on sematic relationships
rather than data relationships - a much more fuzzy concept. |
-
For more detail, refer to one of the many fine expositions on normalization
in relational databases. Here's one.