Integrity Rules and Normalization - Database Systems - page 72

relation is not in DKNF, and should therefore be further normalized. The DKNF as
proposed by Fagin, therefore represents an ideal situation to strive for.
Unfortunately, a number of problems arise from consideration of DKNF:

• Any constraint that restricts the cardinality of a relation

(i.e. the number of tuples in the relation) will render it in violation
of DKNF. (It was perhaps for this reason that Fagin excluded
from his definition of constraints, time-dependent constraints
or constraints relating to data values.) However, there are many
relations for which such constraints are required.

• There is no known algorithm for converting a relation to DKNF.

The conversion is intuitive and for this reason described as artistic
rather than scientific.

• Not all relations can be reduced to DKNF (relations with

cardinality constraints fall in this category).

• It is not precisely clear as to when a relation can be reduced to DKNF.

For these reasons, the DKNF has been compared by Date (see [Date, 2006]) to a
“straw man... of some considerable theoretical interest but not yet of much practical ditto.”

4.11.2 The Sixth Normal Form
A sixth normal form (6NF) has been proposed by C. J. Date in [Date, 2003], after several
years of exploitation, expounding, and research in the field of database systems. It relates
to so-called temporal databases . Date wrote a whole book on the subject; a summary
of the essence is presented in this sub-section. Date defines a temporal database as a
database that contains historical data as well as, or instead of current data. Temporal
databases are often read-only databases, or update-once databases, but they could be
used otherwise. In this sense, a temporal database may be considered as a precursor to a
data warehouse (discussed in Chapter 24).
For the purpose of illustration, assume that we are in a college or university setting
and desire to store the relation Course as defined below:

Course {CourseNo, CourseName, CourseCred}

Suppose further that we desire to show different courses at the time they existed
in the database. To make our analysis more realistic, let us also make the following
additional assumptions:

• The primary key is CourseNo ; for any given course, the attribute

CourseNo cannot be changed.

• For any given course, the attribute CourseName may be changed

any point in time.

• For any given course, the attribute CourseCred may be changed

any point in time.