Explain database normalisation and the common normal forms.
Assesses fundamental understanding of DBMS conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Normalisation organises columns into tables to reduce redundancy and update anomalies. The common normal forms:
- 1NF: atomic values, no repeating groups, each row unique.
- 2NF: 1NF plus no partial dependency on part of a composite key.
- 3NF: 2NF plus no transitive dependency, so non-key attributes depend only on the key.
- BCNF: every determinant is a candidate key, a stricter version of 3NF.
Unnormalised: order(id, customer_name, customer_city, product, qty)
3NF: customer(id, name, city)
product(id, name, price)
order(id, customer_id)
order_item(order_id, product_id, qty)
Each fact is stored once, so updating a customer's city touches one row. Normalisation improves integrity and simplifies writes, and it can cost joins on read. Denormalisation deliberately reintroduces redundancy, for example storing a total or a copied name, to speed reads, and must be maintained carefully with triggers or application logic.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.