Editing Database normalization (section)

=== Satisfying DKNF ===
Let's have a look at the '''Book''' table from previous examples and see if it satisfies the [[domain-key normal form]]:
{| class="wikitable"
|+Book
!<u>Title</u>
!'''Pages'''
!Thickness
!''Genre ID''
!''Publisher ID''
|-
|Beginning MySQL Database Design and Optimization
|520
|Thick
|''1''
|''1''
|-
|The Relational Model for Database Management: Version 2
|538
|Thick
|''2''
|''2''
|-
|Learning SQL
|338
|Slim
|''1''
|''3''
|-
|SQL Cookbook
|636
|Thick
|''1''
|''3''
|}

Logically, '''Thickness''' is determined by number of pages. That means it depends on '''Pages''' which is not a key. Let's set an example convention saying a book up to 350 pages is considered "slim" and a book over 350 pages is considered "thick".

This convention is technically a constraint but it is neither a domain constraint nor a key constraint; therefore we cannot rely on domain constraints and key constraints to keep the data integrity.

In other words – nothing prevents us from putting, for example, "Thick" for a book with only 50 pages – and this makes the table violate [[Domain-key normal form|DKNF]].

To solve this, a table holding enumeration that defines the '''Thickness''' is created, and that column is removed from the original table:

{|
|
{| class="wikitable"
|+Thickness Enum
!<u>Thickness</u>
!Min pages
!Max pages
|-
|Slim
|1
|350
|-
|Thick
|351
|999,999,999,999
|}
|
{| class="wikitable"
|+Book - Pages - Genre - Publisher
!<u>Title</u>
!Pages
!''Genre ID''
!''Publisher ID''
|-
|Beginning MySQL Database Design and Optimization
|520
|''1''
|''1''
|-
|The Relational Model for Database Management: Version 2
|538
|''2''
|''2''
|-
|Learning SQL
|338
|''1''
|''3''
|-
|SQL Cookbook
|636
|''1''
|''3''
|}
|}

That way, the domain integrity violation has been eliminated, and the table is in [[Domain-key normal form|DKNF]].