Normalization
Organizing database tables to reduce redundancy by splitting data into related tables connected by foreign keys. Follows normal forms (1NF, 2NF, 3NF).
What is Normalization?
In short
Normalization is the process of organizing a relational database into multiple tables so each fact is stored exactly once, splitting data into related tables connected by foreign keys to remove redundancy and prevent update anomalies. It follows a series of rules called normal forms, the most common being first, second, and third normal form (1NF, 2NF, 3NF).
What normalization actually is
When you store data in a table, it is easy to repeat the same fact in many rows. Imagine an orders table where every row also carries the customer's name, email, and shipping address. If one customer places 50 orders, their email is copied 50 times. When that customer changes their email, you have to update all 50 rows, and if you miss one, your data now disagrees with itself. Normalization is the discipline of designing tables so each piece of information lives in one place.
The way you do this is to split a wide table into smaller tables linked by foreign keys. The customer's name and email move into a customers table with one row per customer. The orders table keeps only a customer_id that points back to that single row. Now the email exists once. Change it there and every order automatically sees the new value, because the order never stored a copy in the first place.
Normalization was defined by Edgar Codd, the inventor of the relational model, in the early 1970s. He laid out the normal forms as a checklist: each form removes a specific class of redundancy. A table that satisfies third normal form has no repeating groups, every non-key column depends on the whole primary key, and no non-key column depends on another non-key column.
The normal forms, step by step
First normal form (1NF) says every column holds a single atomic value, not a list. A column called phone_numbers containing "555-1234, 555-5678" violates 1NF. You split those into separate rows in a phones table so each phone number gets its own row.
Second normal form (2NF) applies when a table has a composite primary key made of more than one column. It requires that every non-key column depend on the entire key, not just part of it. If a table keyed on (order_id, product_id) stores the product's name, the name depends only on product_id, so it belongs in a separate products table.
Third normal form (3NF) removes transitive dependencies, where a non-key column depends on another non-key column. If an employees table stores department_id and also department_name, the name depends on the department_id, not on the employee. You move department_name into a departments table. There are stricter forms beyond this (BCNF, 4NF, 5NF), but most production schemas aim for 3NF because it removes nearly all anomalies while staying practical to query.
When to normalize and what it costs
Normalization shines in systems that write and update data constantly, which is most transactional applications: banking, inventory, order management, user accounts. Because each fact is stored once, updates are cheap and the database cannot drift into an inconsistent state. Storage is also smaller because you stop duplicating long strings across millions of rows.
The cost shows up at read time. To display an order with its customer name and product names, the database must join the orders, customers, and products tables back together. Joins are not free. A query that touches five normalized tables does more work than reading one wide table where everything is already side by side.
This is why high-traffic read paths often deliberately reverse the process. Denormalization copies some columns back into a table, or precomputes a joined result, to avoid joins on the hot path. The trade-off is the classic one: normalized schemas optimize for correctness and write efficiency, denormalized schemas optimize for read speed at the price of duplicated data you must keep in sync. Most teams normalize first to keep data correct, then denormalize narrowly where profiling proves a join is too slow.
A concrete example
Say you run an e-commerce store. A naive design puts everything in one orders table: order_id, customer_name, customer_email, customer_address, product_name, product_price, quantity. A customer with three orders has their name and address written three times. A product that appears in 10,000 orders has its price copied 10,000 times. Raise that price and you face 10,000 updates, with a real chance of leaving some rows stale.
Normalized to 3NF, this becomes four tables. customers holds id, name, email, address. products holds id, name, price. orders holds id, customer_id, created_at. order_items holds order_id, product_id, quantity. Now a customer's address lives in one row, a product's price lives in one row, and a price change is a single UPDATE.
This is exactly how the schema behind a tool like an online store or a banking ledger is laid out. Postgres and MySQL are both designed around this style. To show an order on screen you join the four tables, and the database engine, with proper indexes on the foreign keys, does that quickly for typical order sizes.
Where it is used in production
PostgreSQL
The reference relational database for normalized schemas; foreign keys, joins, and constraints enforce that each fact lives in one table.
MySQL
Powers countless normalized transactional apps; banking, e-commerce, and CMS schemas typically target 3NF before any denormalization.
Stripe
Stores customers, charges, and subscriptions in separate related tables so a customer's details are recorded once and referenced by every charge.
Shopify
Models products, variants, orders, and line items as separate tables joined by foreign keys, so a price change updates one row, not every historical order.
Frequently asked questions
- What is the difference between normalization and denormalization?
- Normalization splits data into multiple related tables so each fact is stored once, which keeps writes cheap and prevents inconsistency. Denormalization deliberately duplicates or precomputes data back into fewer tables to avoid joins and speed up reads, at the cost of having to keep the copies in sync. Teams usually normalize first, then denormalize narrowly where a read path is proven too slow.
- What are 1NF, 2NF, and 3NF in simple terms?
- 1NF means every column holds a single value, not a list. 2NF means every non-key column depends on the whole primary key, not just part of a composite key. 3NF means no non-key column depends on another non-key column. Most production schemas aim for 3NF because it removes almost all redundancy while staying easy to query.
- Is normalization always a good idea?
- For transactional systems that update data often, yes, because it keeps data correct and updates cheap. But it adds joins at read time. For read-heavy analytics, reporting dashboards, or hot API endpoints, controlled denormalization is common and intentional. The right answer depends on whether your workload is write-heavy or read-heavy.
- Do NoSQL databases use normalization?
- Usually the opposite. Document stores like MongoDB and key-value stores like DynamoDB favor denormalized, embedded data so a single read returns everything an application screen needs without joins, since those databases either lack joins or make them expensive. The redundancy is accepted in exchange for fast, scalable reads.
- What is an update anomaly?
- An update anomaly happens when the same fact is stored in many rows and an update misses some of them, leaving the data contradicting itself. For example, if a customer's email is copied across 50 order rows and you only update 49, the database now holds two different emails for one person. Normalization prevents this by storing the email exactly once.
Learn Normalization hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Normalization as part of a larger topic.
Database Normalization
1NF through 3NF, eliminating redundancy, update anomalies, and data corruption the structured way
foundation · database fundamentals
Vertical Partitioning
Splitting a wide table by columns, keeping hot data tight and cold data out of the way
foundation · database fundamentals
Data Transformation
Convert data from one format, structure, or representation to another, the glue between incompatible systems
intermediate · data governance compliance
Database Denormalization
Intentionally adding redundancy for read performance, when breaking the rules is the right call
foundation · database fundamentals
Database Triggers
Automatic reactions to data changes, audit logs, denormalization sync, and the hidden complexity they bring
foundation · database fundamentals
See also
Related glossary terms you might want to look up next.
Denormalization
Intentionally adding redundant data to database tables to speed up read queries by avoiding expensive joins. Trades storage and write complexity for read performance.
SQL
Structured Query Language for managing relational databases. Tables, rows, columns, and powerful joins to query related data.
Foreign Key
A column in one table that references the primary key of another table, enforcing referential integrity between related tables.
Database
An organized collection of data that can be easily accessed, managed, and updated. The backbone of almost every application.
NoSQL
Databases that don't use traditional table-based relational models. Includes document stores, key-value, graph, and column-family databases.
ACID
Four guarantees for database transactions: Atomicity (all or nothing), Consistency (valid states only), Isolation (no interference), Durability (changes persist).