Domain-key normal form
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
Domain-key normal form (DK/NF or DKNF) is a normal form used in database normalization which requires that the database contains no constraints other than domain constraints and key constraints.
A domain constraint specifies the permissible values for a given attribute, while a key constraint specifies the attributes that uniquely identify a row in a given table.
The domain/key normal form is achieved when every constraint on the relation is a logical consequence of the definition of keys and domains, and enforcing key and domain restraints and conditions causes all constraints to be met. Thus, it avoids all non-temporal anomalies.
The reason to use domain/key normal form is to avoid having general constraints in the database that are not clear domain or key constraints. Most databases can easily test domain and key constraints on attributes. General constraints however would normally require special database programming in the form of stored procedures (often of the trigger variety) that are expensive to maintain and expensive for the database to execute. Therefore, general constraints are split into domain and key constraints.
It's much easier to build a new database in domain/key normal form than it is to convert from databases on lesser normal forms which may contain numerous anomalies. However, successfully building a domain/key normal form database remains a difficult task, even for experienced database programmers. Thus, while the domain/key normal form eliminates the problems found in most databases, it tends to be the most costly normal form to achieve. However, failing to achieve the domain/key normal form may carry long-term, hidden costs due to anomalies which appear in databases adhering only to lower normal forms over time.
The third normal form, Boyce–Codd normal form, fourth normal form and fifth normal form are special cases of the domain/key normal form. All have either functional, multi-valued or join dependencies that can be converted into superkeys. The domains on those normal forms were unconstrained so all domain constraints are satisfied. However, transforming a higher normal form into domain/key normal form is not always a dependency-preserving transformation and therefore not always possible.
Example
[edit]A violation of DKNF occurs in the following table:
| Wealthy Person | Wealthy Person Type | Net Worth in Dollars |
|---|---|---|
| Steve | Millionaire | 124,543,621 |
| Roderick | Billionaire | 6,553,228,893 |
| Katrina | Billionaire | 8,829,462,998 |
| Gary | Millionaire | 495,565,211 |
(Assume that the domain for Wealthy Person consists of the names of all wealthy people in a pre-defined sample of wealthy people; the domain for Wealthy Person Type consists of the values 'Millionaire' and 'Billionaire'; and the domain for Net Worth in Dollars consists of all integers greater than or equal to 1,000,000.)
There is a constraint linking Wealthy Person Type to Net Worth in Dollars, even though we cannot deduce one from the other. The constraint dictates that a Millionaire will have a net worth of 1,000,000 to 999,999,999 inclusive, whilst a Billionaire will have a net worth of 1,000,000,000 or higher. This constraint is neither a domain constraint nor a key constraint; therefore we cannot rely on domain constraints and key constraints to guarantee that an inconsistent Wealthy Person Type / Net Worth in Dollars combination does not make its way into the database.
The DKNF violation could be eliminated by removing the Wealthy Person Type column. The wealthy person's status as a millionaire or billionaire is determined by their Net Worth in Dollars, as defined in the Wealthiness Status table, so no useful information is lost.
| Wealthy Person | Net Worth in Dollars |
|---|---|
| Steve | 124,543,621 |
| Roderick | 6,553,228,893 |
| Katrina | 8,829,462,998 |
| Gary | 495,565,211 |
| Status | Minimum | Maximum |
|---|---|---|
| Millionaire | 1,000,000 | 999,999,999 |
| Billionaire | 1,000,000,000 | 999,999,999,999 |
Foreign keys
[edit]Relationships that are impossible to express as foreign keys are obvious violations of DKNF. For example, a "Parent ID" attribute that points to one of several referenced tables, depending on a second "Parent Type" attribute, violates DKNF.
See also
[edit]References
[edit]- Fagin, Ronald (1981). "A Normal Form for Relational Databases That Is Based on Domains and Keys" (PDF). ACM Transactions on Database Systems. 6 (3): 387–415. CiteSeerX 10.1.1.73.373. doi:10.1145/319587.319592. S2CID 14664427.
External links
[edit]- Database Normalization Basics Archived 2007-02-05 at the Wayback Machine by Mike Chapple (About.com)
- An Introduction to Database Normalization by Mike Hillyer.
- Normalization by ITS, University of Texas.
- A tutorial on the first 3 normal forms by Fred Coulson
- Description of the database normalization basics by Microsoft