papers.adligo.com

Tabular Normal Forms

Author: Scott Morgan
Created: 2025-11-25
Edited: 2025-12-02
Id: 1.3.6.1.4.1.33097.5.0
Copywrite 2025 Adligo Inc

Normalization and the normal forms are essentially a system for de-duplication of data. More formally this has been described as a way of reducing data inconsistancy and improve data integrity.

Foundational Terms

1.3.6.1.4.1.33097.5.0.1

Primary Key

1.3.6.1.4.1.33097.5.0.1.0 ‘A primary key is nonredundant if it is either a simple domain (not a combination) or a combination such that none of the participating simple domains is superfluous in uniquely identifying each element.’

Candiate Key

1.3.6.1.4.1.33097.5.0.1.1

A minimal set of attributes that can uniquely identify a tuple (row) in a relation. A relation can have multiple candidate keys.

Prime Attribute

1.3.6.1.4.1.33097.5.0.1.2

A attribute that is part of at least one candidate key in a database table.

Super Key

1.3.6.1.4.1.33097.5.0.1.3

Any set of attributes that includes a candidate key. It can uniquely identify tuples but might contain redundant attributes.

Elementary Prime Attribute

1.3.6.1.4.1.33097.5.0.1.4

An attribute that is part of an elementary key.

Functional Attribute Dependency

1.3.6.1.4.1.33097.5.0.1.5

A relationship between two sets of attributes where the value of one set determines the value of another. For example, (CustomerID → CustomerName). The first set (CustomerID) is the determinant.

Datum

1.3.6.1.4.1.33097.5.0.1.6

A peice of information.

Elementary Key

1.3.6.1.4.1.33097.5.0.1.7

A candidate key (a minimal superkey) is considered an elementary key if there exists at least one attribute it determines where the functional dependency is elementary.

Elementary Functional Dependency

1.3.6.1.4.1.33097.5.0.1.8

A non-trivial functional dependency X → Y is elementary if there is no smaller proper subset of X that also determines Y (i.e., it is a full functional dependency with a minimal determinant).

Normal Forms

1.3.6.1.4.1.33097.5.0.0

UNF The Unnormalized Form (circa 1970)

1.3.6.1.4.1.33097.5.0.0.0

1NF The First Normal Form (circa 1970)

1.3.6.1.4.1.33097.5.0.0.1

Every datum in a relational database can be uniquely addressed by means of the relation, name, primary key value, and attribute name.

A relation (or a table, in SQL) can be said to be in first normal form if each field is atomic, containing a single value rather than a set of values or a nested table. In other words, a relation complies with first normal form if no attribute domain (the set of values allowed in a given column) has relations as elements.

1NF.1 Unique rows (no duplicate records)

1.3.6.1.4.1.33097.5.0.0.1.0

1NF.2 Scalar columns (columns cannot contain relations or composite values)

1.3.6.1.4.1.33097.5.0.0.1.1

2NF The Second Normal Form (circa 1971)

1.3.6.1.4.1.33097.5.0.0.2

2NF.0 Every datum must first be in NF1

1.3.6.1.4.1.33097.5.0.0.2.0

2NF.1 Every non-prime attribute has a full functional dependency on each candidate key (attributes depend on the whole of every key)

1.3.6.1.4.1.33097.5.0.0.2.1

3NF The Third Normal Form (circa 1971)

1.3.6.1.4.1.33097.5.0.0.3

3NF.0 Every datum must first be in NF2

1.3.6.1.4.1.33097.5.0.0.3.0

3NF.1 Every non-trivial functional dependency either begins with a superkey or ends with a prime attribute (attributes depend only on candidate keys)

1.3.6.1.4.1.33097.5.0.0.3.1

BCNF The Boyce–Codd Normal Form (circa 1974)

1.3.6.1.4.1.33097.5.0.0.3.5

BCNF.0 Every datum must first be in NF3

1.3.6.1.4.1.33097.5.0.0.3.5.0

BCNF.1 Every datum must first be in EKNF

1.3.6.1.4.1.33097.5.0.0.3.5.1

Note this is a strange rule that seems to have been discovered at some point after BCNF was created and added to wikipedia.

BCNF.2 Every non-trivial functional dependency begins with a superkey (a stricter form of 3NF)

1.3.6.1.4.1.33097.5.0.0.3.5.2

4NF The Fourth Normal Form (circa 1977)

1.3.6.1.4.1.33097.5.0.0.4

4NF.0 Every datum must first be in BCNF

1.3.6.1.4.1.33097.5.0.0.4.0

4NF.1 Every non-trivial multivalued dependency begins with a superkey

1.3.6.1.4.1.33097.5.0.0.4.1

5NF The Fifth Normal Form (circa 1979)

1.3.6.1.4.1.33097.5.0.0.5

5NF.0 Every datum must first be in 4NF

1.3.6.1.4.1.33097.5.0.0.5.0

5NF.1 Every join dependency has only superkey components

1.3.6.1.4.1.33097.5.0.0.5.1

DKNF The Domain Key Form (circa 1981)

1.3.6.1.4.1.33097.5.0.0.80.0

DKNF.0 Every datum must first be in 5NF

1.3.6.1.4.1.33097.5.0.0.80.0.0

DKNF.1 Every constraint is a consequence of domain constraints and key constraints

1.3.6.1.4.1.33097.5.0.0.80.0.1

EKNF The Elementary Key Form (circa 1982)

1.3.6.1.4.1.33097.5.0.0.80.1

EKNF.0 Every datum must first be in NF3

1.3.6.1.4.1.33097.5.0.0.80.1.0

EKNF.1 Every non-trivial functional dependency either begins with a superkey or ends with an elementary prime attribute (a stricter form of 3NF)

1.3.6.1.4.1.33097.5.0.0.80.1.1

6NF The Sixth Form (circa 2003)

1.3.6.1.4.1.33097.5.0.0.6

Codd’s 12 Rules

1.3.6.1.4.1.33097.5.0.1

Notes

‘Sometimes the following questions arise: Why call it the relational model? Why not call it the tabular model? There are two reasons: (1) At the time the relational model was introduced, many people in data processing felt that a relation (or relationship) among two or more objects must be represented by a linked data structure (so the name was selected to counter this misconception); (2) Tables are at a lower level of abstraction than rela- tions, since they give the impression that positional (ar- ray-type) addressing is applicable (which is not true of n-ary relations), and they fail to show that the informa- tion content of a table is independent of row order. Nevertheless, even with these minor flaws, tables are the most important conceptual representation of relations, because they are universally understood. ‘

The normal forms were added to this file first because they are of more importance than Codd’s 12 rules in modern (circa 2025) computing.

Citations