First, Second, and Third Normal Forms (1NF–3NF): What They Are and How They Relate

This top-landing page gives you a crisp overview of the first three normal forms and why they matter. Use it as your hub to the detailed lessons on functional dependencies, 2NF limitations, transitive dependencies, and 3NF decomposition.

Why Normalize?

Normalization reduces redundancy and prevents update, insert, and delete anomalies. You’ll decompose tables along functional dependency lines and re-link them with foreign keys, so each fact lives in exactly one place.

A graphic representation of the general normalization process. — Figure: Conceptual flow—identify dependencies → decompose by subject → link with keys → validate.

First Normal Form (1NF)

A relation is in 1NF when it has a primary key, no repeating groups, and only atomic (indivisible) values. Each column has a single meaning and consistent type; each row is unique.

Non-1NF example (repeating group)

| OrderID | ProductNames        |
|---------|---------------------|
| 1       | Pen, Pencil         |
| 2       | Notebook            |

1NF rewrite (one fact per row)

| OrderID | ProductName |
|---------|-------------|
| 1       | Pen         |
| 1       | Pencil      |
| 2       | Notebook    |

Tip: Use a surrogate key if needed for simplicity, but keep meaningful candidates (like a natural order number) UNIQUE to prevent accidental duplicates.

Second Normal Form (2NF)

A relation is in 2NF if it’s in 1NF and every non-prime attribute (not part of any candidate key) is fully dependent on the entire candidate key. 2NF primarily addresses partial dependencies in tables with composite keys.

Partial dependency example

| OrderID | ProductID | ProductName |
|---------|-----------|-------------|
| 1       | P1        | Pen         |
| 1       | P2        | Pencil      |

Here, the candidate key is (OrderID, ProductID), but ProductName depends only on ProductID (a part of the key). That violates 2NF.

2NF decomposition

OrdersProducts(OrderID, ProductID)
Products(ProductID, ProductName)

Tip: Validate 2NF by asking “Does any non-prime attribute depend on only part of a composite key?” If yes, split by subject.

Third Normal Form (3NF)

A relation is in 3NF if it’s in 2NF and has no transitive dependencies—that is, no non-prime attribute depends on another non-prime attribute. In notation: if A → B and B → C, then A → C is transitive; 3NF forbids storing C in the A table when B is a non-prime attribute.

Transitive dependency example

| ProductID | ProductName | CategoryName |
|-----------|-------------|--------------|
| P1        | Pen         | Stationery   |
| P2        | Pencil      | Stationery   |

If ProductName → CategoryName, then CategoryName is transitively dependent on ProductID through ProductName. That’s a 3NF violation.

3NF decomposition

Products(ProductID, ProductName, CategoryID)
Categories(CategoryID, CategoryName)

Tip: In practice, make each determinant (e.g., CategoryID) the key of its own table. Enforce FOREIGN KEY constraints and add indexes for common join paths.

Putting It All Together: A Minimal Checklist

List dependencies: Derive from business rules (not from current spreadsheets or ad-hoc reports).
1NF: Ensure atomic values, consistent types, and clear keys.
2NF: Remove partial dependencies on composite keys.
3NF: Remove transitive dependencies (non-prime → non-prime).
Re-link: Connect tables with FKs; apply UNIQUE for natural identifiers.
Validate anomalies: Updates to any fact should touch exactly one row in exactly one table.

Normalization: High-Level Process

Normalization arose when entity-relationship analysis needed further refinement. You decompose tables to eliminate redundancy and bind them back together with keys and constraints. After each decomposition, test your result against the definitions of 1NF, 2NF, and 3NF. If the table still shows redundancy or anomalies, iterate.

Key Terms (quick reference)

Candidate key: Minimal attribute set that uniquely identifies a row.
Primary key: The selected candidate key used for identification.
Non-prime attribute: Attribute not in any candidate key.
Determinant: Attribute/set that functionally determines another attribute.
Transitive dependency: Non-prime attribute determined via another non-prime attribute.

Continue Learning

Next steps in this module: