Normalization Overview

Normalization is a systematic process for organizing the columns and tables in a relational database so that data redundancy is minimized and the database is protected from a category of bugs known as update, insert, and delete anomalies. It is a series of guidelines — the "normal forms" — each one stricter than the last, and each one eliminating a specific kind of structural problem.

A denormalized table and the problems it causes

The easiest way to understand why normalization matters is to look at a table that ignores it. Suppose all order information is jammed into a single table, including customer details repeated on every row:

A single denormalized orders table

SQL

CREATE TABLE orders_denormalized (
  order_id       INT PRIMARY KEY,
  customer_name  VARCHAR(100),
  customer_city  VARCHAR(50),
  customer_email VARCHAR(150),
  product_name   VARCHAR(100),
  product_price  DECIMAL(10, 2),
  quantity       INT,
  order_date     DATE
);

INSERT INTO orders_denormalized VALUES
  (1, 'Alice Nguyen', 'New York', 'alice@example.com', 'Wireless Mouse', 19.99, 2, '2024-01-05'),
  (2, 'Alice Nguyen', 'New York', 'alice@example.com', 'USB-C Cable',    9.99, 1, '2024-01-06'),
  (3, 'Bob Smith',    'Boston',   'bob@example.com',   'Wireless Mouse', 19.99, 1, '2024-01-07');

Every row that belongs to Alice repeats her name, city, and email in full. This single design decision causes several concrete problems:

Update anomaly: if Alice moves to Boston, her city has to be updated in every one of her order rows. Miss one, and the table now contains two different cities for the same customer, with no way to know which is correct.
Insert anomaly: to add a new customer who has not placed an order yet, there is no order row to attach their details to — the schema has no place to put a customer that does not yet have an order.
Delete anomaly: if Bob's only order (order 3) is deleted, all record of Bob as a customer disappears along with it, even though he may still exist as a customer.
Wasted storage and inconsistency risk: product_price and product_name are repeated on every order line for the same product, and nothing stops two rows from disagreeing about the price of the same product.

Normalization fixes these problems by splitting the single wide table into several smaller, focused tables — customers, products, and orders — each storing one kind of fact exactly once, and connecting them with foreign keys instead of repeating data.

The normal forms, at a glance

Normal form	What it eliminates
1NF (First Normal Form)	Non-atomic column values and repeating groups — every column must hold a single, indivisible value.
2NF (Second Normal Form)	Partial dependency — every non-key column must depend on the entire primary key, not just part of it.
3NF (Third Normal Form)	Transitive dependency — a non-key column must depend directly on the primary key, not on another non-key column.
BCNF (Boyce-Codd Normal Form)	A stricter version of 3NF that closes a few edge cases involving overlapping candidate keys.

Each normal form builds on the one before it — a table cannot be in 3NF unless it is already in 2NF, and cannot be in 2NF unless it is already in 1NF. The following pages walk through each one in order, using a concrete before-and-after example each time.

Normalization is a spectrum, not a finish line

Higher normal forms are not automatically "better" in every situation. Most production systems are designed to satisfy 3NF and stop there, because it captures the vast majority of the practical benefit — protection from anomalies — without excessive fragmentation of tables. Some systems then deliberately reintroduce a controlled amount of redundancy afterward, called denormalization, to speed up read-heavy queries. That trade-off is covered later in this section, once normalization itself is fully understood.