What is database normalization?

Question

Accepted Answer

**Normalization** is the process of organizing data to **reduce redundancy** and improve integrity by splitting data into related tables, following a series of "normal forms." The goal: each piece of data is stored **once**, avoiding duplication and the anomalies it causes.

## The problem: a denormalized (redundant) table

Problems (anomalies):
  ✗ UPDATE anomaly — change Ann's email → must update EVERY one of her orders
  ✗ INSERT anomaly — can't add a customer without an order
  ✗ DELETE anomaly — deleting Ann's last order loses her info entirely
  ✗ Wasted storage and inconsistency risk
```

## The solution: split into related tables

Normalization splits the data so each fact lives in one place — customer info in `customers`, products in `products`, and `orders` references them by key.

## The normal forms (progressively stricter)

```text
1NF → atomic values (no repeating groups / multi-valued columns), a primary key
2NF → 1NF + no partial dependency (non-key columns depend on the WHOLE primary key)
3NF → 2NF + no transitive dependency (non-key columns depend ONLY on the key, not
      on other non-key columns)
→ 3NF is the common practical target; BCNF, 4NF, 5NF exist for stricter cases.
```

## Normalization vs denormalization (the trade-off)

```text
Normalized   → less redundancy, better integrity, but more JOINs (can be slower reads)
Denormalized → some duplication for FEWER joins → faster reads (e.g. analytics/reporting)
→ Normalize by default (integrity); selectively denormalize for read performance
  where justified (with care to keep duplicates consistent).
```

## Why it matters

Normalization is a fundamental database design concept — it's how you structure data to avoid redundancy and maintain integrity, which is essential for designing reliable relational databases, so understanding it is important.

The core value is preventing the **anomalies** that redundant (denormalized) data causes: **update anomalies** (changing duplicated data in many places, risking inconsistency), **insert anomalies** (can't add data without unrelated data), and **delete anomalies** (losing data when deleting related records) — all of which lead to inconsistent, corrupt data.

By splitting data into related tables so each fact is stored once, normalization eliminates these problems and ensures data consistency.

Understanding the **normal forms** (especially 1NF, 2NF, and **3NF** — the common practical target — and the principle that non-key columns should depend on the key) provides the framework for proper design.

Equally important is understanding the **normalization vs denormalization trade-off**: normalization improves integrity but requires more JOINs (potentially slower reads), so while you normalize by default for integrity, selective denormalization (accepting some duplication for fewer joins and faster reads) is sometimes justified for performance (e.g. analytics) — knowing when and why to make this trade-off reflects mature design judgment.

Since proper data modeling is foundational to reliable databases, and since understanding normalization (avoiding redundancy and anomalies) and its trade-off with denormalization (integrity vs read performance) is key to designing well-structured, consistent, performant databases, normalization is important, foundational knowledge for database design and a common interview topic that demonstrates understanding of sound data modeling.