Database Modeling and Design

6.5 Fourth and Fifth Normal Forms 133
transform tables from BCNF to 4NF must take into account the trade-off
between normalization and the elimination of delete anomalies, and the
preservation of FDs and possibly MVDs. It should also be noted that this
approach derives a feasible, but not necessarily a minimum, set of 4NF
tables.
A second approach to decomposing BCNF tables is to ignore the
MVDs completely and split each BCNF table into a set of smaller tables,
with the candidate key of each BCNF table being the candidate key of a
new table and the nonkey attributes distributed among the new tables in
some semantically meaningful way. This form of decomposing by candidate
key (that is, superkey) is lossless because the candidate keys
uniquely join; it usually results in the simplest form of 5NF tables, those
with a candidate key and one nonkey attribute, and no MVDs. However,
if one or more MVDs still exist, further decomposition must be done
with the MVD/MVD-complement approach given above. The decomposition
by candidate keys preserves FDs, but the MVD/MVD-complement
approach does not preserve either FDs or MVDs.
Tables that are not yet in BCNF can also be directly decomposed into
4NF using the MVD/MVD-complement approach. Such tables can often
be decomposed into smaller minimum sets than those derived from
transforming into BCNF first and then 4NF, but with a greater cost of
lost FDs. In most database design situations, it is preferable to develop
BCNF tables first, then evaluate the need to normalize further while preserving
the FDs.
6.5.4 Fifth Normal Form
Definition. A table R is in fifth normal form (5NF) or project-join normal
form (PJ/NF) if and only if every join dependency in R is
implied by the keys of R.
As we recall, a lossless decomposition of a table implies that it can be
decomposed by two or more projections, followed by a natural join of
those projections (in any order) that results in the original table, without
any spurious or missing rows. The general lossless decomposition constraint,
involving any number of projections, is also known as a join
dependency (JD). A join dependency is illustrated by the following example:
in a table R with n arbitrary subsets of the set of attributes of R, R
satisfies a join dependency over these n subsets if and only if R is equal
to the natural join of its projections on them. A JD is trivial if one of the
subsets is R itself.