126 DKNF

Domain-Key Normal Form, or DKNF, is an ideal normal form in which every constraint on a relvar is a logical consequence of domain constraints and key constraints. A domain constraint restricts the values that may appear for an attribute, while a key constraint states that certain attributes uniquely identify a tuple. If some further constraint is needed to prevent an invalid relvar value, then the relvar is not in DKNF.

DKNF is stronger in scope than the normal forms based on particular classes of dependencies. Rather than considering functional, multivalued, or join dependencies separately, it asks whether all of the constraints have been reduced to two fundamental kinds. It is an ideal rather than a normal form that every practical design can necessarily attain.

A dependency not captured by domains and keys

Consider a relation that records an employee, the employee's department, and the manager of that department:

Suppose each employee belongs to one department and each department has one manager. The relation therefore satisfies the dependencies employee -> department and department -> manager. If employee is the key, the second dependency is not implied merely by the attribute domains and that key. A separate constraint is required to prevent two employees in the same department from naming different managers. The relation is therefore not in DKNF.

The familiar relational repair decomposes the facts according to their determinants. One relation records each employee's department, and another records each department's manager. The dependency from department to manager is then represented by a key of the latter relation rather than by an additional constraint over the former.

The Predica interpretation

Predica can express the same repair by introducing the domain that is the subject of the manager fact:

entity Department
{
    String name;
    String manager;

    key {name};
}

entity Employee
{
    String name;
    Department department;

    key {name};
}

entity Organisation
{
    Department department*;
    Employee employee*;
}

The manager is now an attribute of Department, the domain it describes. Employees refer to values of type Department instead of repeating a department name and manager combination. The constraint that was previously stated across employee tuples has been absorbed into the type structure, the key of Department, and the cardinality of its attributes.

This illustrates why the DKNF principle is especially relevant to Predica. Predica domains are not limited to primitive scalar types. Entity, value, enum, variant, quotient, intersection, and union types can express semantic distinctions directly, and their definitions can include keys and attributes. Introducing the right nominal domain can therefore convert some apparently global constraints into local consequences of the type structure.

Beyond relational DKNF

The relational definition of DKNF mentions only domain and key constraints. A direct Predica analogue would be broader because cardinality constraints belong to predicate extensions rather than to value types, and subtype and relationship structure can also constrain valid database states. It is therefore better to treat DKNF as a design principle than to claim that these additional constructs are part of relational DKNF.

Nor should every Predica constraint be forced into a type or key declaration. Some business rules genuinely relate several independently meaningful predicate extensions. Such a rule remains a general constraint on the database type. The useful DKNF question is whether a constraint is genuinely global, or whether its presence reveals a missing domain, a misplaced fact, or an undeclared key.