The Core Idea
Removing Redundancy, One Rule at a Time
Normalization is the process of restructuring database tables to eliminate redundant data — the same fact stored in more than one row or table — because redundancy leads directly to update anomalies: if a customer's address is stored in every one of their order rows, updating their address means you must remember to update it in every single row, and missing even one leaves the database internally inconsistent.
Normalization proceeds through a series of increasingly strict rules called normal forms (1NF, 2NF, 3NF, and beyond), each one eliminating a specific, well-defined category of redundancy that the previous form didn't address. Each normal form assumes the table already satisfies all the previous ones.
💡 Memory Trick
Think of normalization as tidying up a messy binder of facts. 1NF: make sure every cell holds exactly one piece of information — no cramming a comma-separated list of three phone numbers into a single cell. 2NF: make sure every fact in a row actually depends on the WHOLE key, not just part of it — don't file a fact under 'Order #47, Product B' if that fact is really only about Product B in general. 3NF: make sure every fact depends DIRECTLY on the key, not on some other non-key fact in the same row — don't file 'city' under a row keyed by zip code when zip code itself is just another fact about the row, not the row's actual identity.
The Three Normal Forms
What Each One Specifically Fixes
1NF
First Normal Form — Atomic Values
Every column must hold a single, indivisible (atomic) value — no comma-separated lists, no repeating groups of columns within one row. A 'phone_numbers' column containing '555-1234, 555-5678' violates 1NF; the fix is a separate table linking each phone number to the person, one number per row.
Example: instead of one row with columns phone1, phone2, phone3, create a separate phone_numbers table with one row per number.
2NF
Second Normal Form — No Partial Dependency
Applies specifically to tables with a composite (multi-column) primary key. Every non-key column must depend on the ENTIRE composite key, not just part of it. If a table keyed by (order_id, product_id) also stores product_name — which really only depends on product_id, not on order_id at all — that's a partial dependency violating 2NF.
Example: move product_name into a separate products table keyed only by product_id, since it doesn't depend on order_id.
3NF
Third Normal Form — No Transitive Dependency
Every non-key column must depend directly on the primary key, not on another non-key column. If a table keyed by employee_id also stores both department_id and department_name, department_name really depends on department_id (a non-key column), not directly on employee_id — that's a transitive dependency violating 3NF.
Example: move department_name into a separate departments table keyed by department_id, referenced from the employees table via a foreign key.
The Trade-off
Normalization vs. Denormalization
Normalization eliminates redundancy and the update anomalies it causes, but it does so by splitting data across more tables, which means retrieving a complete picture of something (like 'an order with its product names and customer's full address') requires JOINing multiple tables back together — adding query complexity and potentially reducing read performance for very read-heavy workloads.
This is why real systems sometimes deliberately denormalize — reintroducing some controlled redundancy on purpose — for specific tables or specific reporting/analytics use cases where read speed matters more than the (well-understood, carefully managed) risk of update anomalies. The decision to normalize or denormalize is a deliberate design trade-off, not a sign that one approach is simply 'correct' and the other 'wrong.'
🖥️ Applied Scenario
You inherit a database where the orders table has columns order_id, customer_id, customer_name, customer_address, product_id, and product_name all in one table, and customers keep reporting that their address updates don't apply to older orders.
1
You identify that customer_name and customer_address depend only on customer_id (not on the full order), and product_name depends only on product_id — both are transitive dependencies violating 3NF.
2
You split the table: a customers table (customer_id, name, address), a products table (product_id, name), and a slimmer orders table referencing customer_id and product_id via foreign keys instead of duplicating their details.
3
Now, updating a customer's address means changing exactly one row in the customers table — every order referencing that customer_id automatically reflects the updated address through the join, with zero risk of some orders showing stale data.
4
Conclusion: the original bug wasn't really about the update logic — it was a normalization problem, where the same fact (customer address) was duplicated across every order row instead of being stored exactly once.
📌 Exam Application
Exam questions typically give you a table design and ask you to identify which normal form it violates and why, or ask you to normalize a given unnormalized table through 1NF, 2NF, and 3NF step by step. A strong answer identifies the SPECIFIC dependency causing the violation (partial dependency for 2NF, transitive dependency for 3NF) rather than vaguely stating 'there's redundancy.'
⚠️ Most Common Database Normalization Mistakes
The most common mistake is confusing 2NF's partial dependency (a non-key column depending on only PART of a composite key) with 3NF's transitive dependency (a non-key column depending on another NON-KEY column instead of the key directly) — both involve 'a column depending on the wrong thing,' but the specific relationship being violated is different, and exam questions frequently test this exact distinction. Another frequent error is assuming higher normal forms are always strictly better — over-normalizing a table used purely for fast read-heavy reporting can hurt performance without a corresponding practical benefit, since update-anomaly risk may not even apply to read-only reporting data.
✓ Quick Self-Test
Can you explain, in one sentence each, what specific problem 1NF, 2NF, and 3NF each solve? Given a sample unnormalized table, can you correctly identify which columns need to be split into separate tables to reach 3NF, and explain why each split is necessary?
Next Lesson
Database Indexes
→
← All Databases Lessons