Third Normal Form (3NF)
The third normal form checks for transitive dependencies. A transitive dependency
is similar to a partial dependency in that they both refer to
attributes that are not fully dependent on a primary key. A dependency
is transient when attribute1 is dependent on attribute2, which is dependent on the primary key.
The second normal form is violated when an
attribute depends on part of the key. The third normal form is violated
when the attribute does depend on the key but also depends on another
non-key attribute.
The key phrase when describing the third normal form is that every attribute “must provide a fact about the key, the whole key, and nothing but the key.”
Just as with the second normal form, the third normal form is resolved by moving the nondependent attribute to a new entity.
Continuing with the Regional Office Store example, assume that a manager is assigned to each region. The Regional Manager attribute belongs in the Regional Office
entity; but it is a violation of the third normal form if other
information describing the manager is stored in the regional office, as
shown in Table 5.
Table 5 Violating the Third Normal Form
The DateofHire describes the manager not the region, so the hire-date attribute is not directly dependent on the RegionalOffice entity's primary key. The DateOfHire's dependency is transitive — it describes the key and a non-key attribute — in that it goes through the Manager attribute.
Creating a Manager
entity and moving its attributes to the new entity resolves the
violation of the third normal form and cleans up the logical design, as
demonstrated in Table 6.
Table 6 Conforming to the Third Normal Form
Best Practice
If the entity has a good primary key
and every attribute is scalar and fully dependent on the primary key,
the logical design is in the third normal form. Most database designs
stop at the third normal form.
The additional forms prevent problems
with more complex logical designs. If you tend to work with
mind-bending modeling problems and develop creative solutions,
understanding the advanced forms can prove useful.
The Boyce-Codd Normal Form (BCNF)
The Boyce-Codd normal form occurs
between the third and fourth normal forms, and it handles a problem
with an entity that has multiple candidate keys. One of the candidate
keys is chosen as the primary key, and the others become alternative
keys. For example, a person might be uniquely identified by his or her
Social Security number (ssn), employee number, and driver's license
number. If the ssn is the primary key, the employee number and driver's
license number are the alternative keys.
The Boyce-Codd normal form simply stipulates that
in such a case every attribute must describe every candidate key. If an
attribute describes one of the candidate keys but not another candidate
key, the entity violates BCNF.
Fourth Normal Form (4NF)
The fourth normal form deals with
problems created by complex composite primary keys. If two independent
attributes are brought together to form a primary key along with a
third attribute, but the two attributes don't uniquely identify the
entity without the third attribute, the design violates the 4NF. For
example, assume the following conditions:
1. Regional Office and the regional office's Manager were used as a composite primary key.
2. A Store and the Manager were brought together as a primary key.
3. Because both used a manager all three were combined into a single entity.
The preceding example violates the fourth normal form.
The fourth normal form is used to help identify
entities that should be split into separate entities. Usually this is
only an issue if large composite primary keys have brought too many
disparate objects into a single entity.
Fifth Normal Form (5NF)
The fifth normal form provides the method for designing complex relationships that involve multiple (three or more) entities. A three-way or ternary
relationship, if properly designed, is in the fifth normal form. The
cardinality of any of the relationships could be one or many. What
makes it a ternary relationship is the number of related entities.
As an example of a ternary relationship, consider
a manufacturing process that involves an operator, a machine, and a
bill of materials. From one point of view, this could be an operation
entity with three foreign keys. Alternatively, it could be thought of
as a ternary relationship with additional attributes.
Just like a two-entity many-to-many relationship,
a ternary relationship requires a resolution entity in the physical
schema design to resolve the many-to-many relationship into multiple
artificial one-to-many relationships; but in this case the resolution
entity has three or more foreign keys.
In such a complex relationship, the fifth normal
form requires that each entity, if separated from the ternary
relationship, remains a proper entity without any loss of data.
It's commonly stated that a third normal
form is enough. Boyce-Codd, fourth, and fifth normal forms may be
complex, but violating them can cause severe problems. It's not a
matter of more entities versus fewer entities; it's a matter of
properly aligned attributes and keys.
