Database Normalization Forms Explained
Fast recall
Quick revision
Core answer
Whether you understand relational data modeling fundamentals and can reason about trade-offs between normalization and denormalization.
Candidates often memorize definitions without being able to identify violations in a real schema or explain when to deliberately denormalize.
Explain the practical trade-off: normalized schemas reduce write anomalies but can hurt read performance, leading many teams to intentionally denormalize for OLAP workloads or caching layers.
Interview-ready guide
Interview answer
Most interviews on normalization test whether you can identify violations in a real table, not whether you can recite definitions. The forms build on each other — a table in 3NF is automatically in 2NF and 1NF — and each one eliminates a different class of data anomaly.
1NF — one atomic value per cell
- Every column must hold a single indivisible value — so a
tagscolumn storing"java,spring,sql"violates 1NF because it packs multiple values into one cell, which means you can't filter or index individual tags without string parsing - No repeating column groups either —
item1,item2,item3on an order row violates 1NF because adding a fourth item requires a schema change rather than a new row
2NF — no partial dependency on a composite key
- 2NF applies only when the primary key is composite — every non-key column must depend on the whole key, not just part of it
order_items(order_id, item_id, item_name)violates 2NF becauseitem_namedepends only onitem_id, not the full composite key — which means every order line duplicates the item name, and a rename requires updating hundreds of rows instead of one- Fix: move
item_nameto a separateitems(item_id, item_name)table
3NF — no column-to-column dependency
- Non-key columns must depend directly on the primary key, not on each other — so
employees(emp_id, dept_id, dept_name)violates 3NF becausedept_namedepends ondept_id, notemp_id - That transitive dependency means renaming a department updates every employee row in that department instead of one row in a
departmentstable
BCNF — every determinant must be a candidate key
- BCNF tightens 3NF for tables with overlapping candidate keys — it handles the edge cases that 3NF misses, relevant for scheduling or assignment tables with complex key constraints
In production, OLTP schemas target 3NF. For reporting and caching, teams deliberately denormalize — duplicating customer_name on order rows to skip a join on every report query. The key is making that trade-off intentionally with a documented sync strategy, not by accident.
Database Normalization Forms Explained
Direct Answer
Normalization organizes a relational database to reduce data redundancy and improve integrity. The forms are progressive: 1NF eliminates repeating groups, 2NF removes partial dependencies on composite keys, 3NF removes transitive dependencies between non-key columns, and BCNF is a stricter variant that closes the overlapping-key edge case. OLTP schemas target 3NF; read-heavy paths deliberately denormalize with a documented update strategy.
Code Example
// Violates 1NF: repeating groups in a single column
// orders(id, customer, items) where items = 'book,pen,paper'
// 1NF: atomic values, no repeating groups
// orders(id, customer_id)
// order_items(order_id, item_id, quantity)
// Violates 2NF: partial dependency on composite key
// order_items(order_id, item_id, item_name, quantity)
// item_name depends only on item_id, not the full composite key
// 2NF: remove partial dependencies
// order_items(order_id, item_id, quantity) -- depends on full key
// items(item_id, item_name, price) -- item_name moved here
// Violates 3NF: transitive dependency
// employees(emp_id, dept_id, dept_name)
// dept_name depends on dept_id, not directly on emp_id
// 3NF: remove transitive dependencies
// employees(emp_id, dept_id)
// departments(dept_id, dept_name)
// BCNF: every determinant must be a candidate key
// teaching(student, subject, teacher)
// If teacher -> subject (a teacher teaches only one subject),
// teacher is a determinant but not a candidate key -- violates BCNF
// Solution: teacher(teacher, subject) + enrollment(student, teacher)
Common Mistakes & Pitfalls
Candidates often memorize definitions without being able to identify violations in a real schema or explain when to deliberately denormalize.
Check your understanding
Answer these without looking back at the article.
- When would you deliberately denormalize a schema?
- How does normalization affect query performance for reporting workloads?
- What is the difference between 3NF and BCNF in practice?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.