Database Reference
In-Depth Information
Note
: For most practical purposes, you only have to worry about 5NF if you are try-
ing to implement an M:M relationship involving more than two relations. Once in 5NF,
further decompositions would share candidate keys and are therefore to no avail (recall
corollary of Heath's theorem). Notwithstanding this, other normal forms have been
proposed, as will be discussed in the upcoming section.
4.11 Other Normal Forms
The field of Database Systems is potentially a contemptuous one. Indeed, there are
accounts of former friends or colleagues becoming foes over database quibbles
(in Figure
4-7
of section 4.12, the current author relates a personal experience he had as
a young software engineer on a project of national importance). Various individuals have
proposed several database theorems and methodologies, but they have not all gained
universal acceptance as have the normal forms of the previous sections. Two additional
normal forms that have been, and will no doubt continue to be the subject of debate are
the
domain-key normal form
(DKNF) and the
sixth normal form
(6NF). Without picking
sides of the debate on these two normal forms, this section will summarize each.
4.11.1 The Domain-Key Normal Form
The domain-key normal form (DKNF) was proposed by Ronald Fagin in 1981. Unlike the
other normal forms which all relate to FDs, MVDs and JDs, this normal form is defined in
terms of domains and keys (hence its name). In his paper, Fagin showed that a relation
DKNF has no modification anomalies, and that a relation without modification
anomalies must be in DKNF. He therefore argued that a relation in DKNF needed no
further normalization (at least, not for the purpose of reducing modification anomalies).
The definition of DKNF is as follows:
This definition contains three important terms that need clarification:
•
A constraint is used to mean any rule relating to static values of
attributes. Constraints therefore include integrity rules, editing
rules, foreign keys, intra-relation references, FDs and MVDs, but
exclude time-dependent constraints, cardinality constraints and
constraints relating to changes in data values.
•
A key is a unique identifier of a row (as defined in Chapter 3).
•
A domain is a pool of legal attribute values (as defined in Chapter 3).
The implication of the DKNF is clear: If we have a relation that contains constraint(s)
that is (are) not a logical consequence of its (candidate) key and domains, then that
