Schema Design & Normalization
Structuring tables to avoid redundant, inconsistent data — and knowing when to deliberately break the rules for performance.
What normalization solves
An unnormalized schema stores the same fact in multiple places (e.g. a customer's address repeated on every one of their orders) — update one copy and forget another, and the data is now inconsistent. Normalization splits data into tables where each fact lives in exactly one place.
The normal forms, practically
- 1NF — every column holds a single, atomic value (no comma-separated lists in a cell).
- 2NF — every non-key column depends on the whole primary key, not part of it (relevant for composite keys).
- 3NF — every non-key column depends only on the key, not on another non-key column (no transitive dependencies).
Most application schemas target 3NF.
Denormalization is a deliberate trade
Joins across normalized tables cost query time. Denormalizing (duplicating some data) trades storage and update-consistency risk for read speed — a deliberate choice for read-heavy reporting tables, not a mistake to avoid everywhere.
Prerequisite
Assumes comfort with joins, since normalized data is only useful if you can efficiently join it back together at query time.