Normalization Interview Questions

Normalization is about reducing duplicate data and the bugs that come with it — update one place, forget the other. 1NF: columns are atomic, no repeating groups like phone1, phone2, phone3. 2NF: already 1NF, and every non-key column depends on the whole composite key, not just part of it. 3NF: already 2NF, and non-key columns do not depend on other non-key columns. A classic break is employees(id, dept_id, dept_name) — dept_name belongs in a department table. I still denormalize later for read-heavy dashboards, but only after I have measured. I would mention BCNF if they ask what is stricter than 3NF.

Read-heavy dashboards, expensive joins on huge tables, or a document I always fetch together. I would copy customer_name onto orders if we show it everywhere and names rarely change, and I would accept the update anomaly. I would not denormalize first. I would 3NF the write model, then add a read model or a column with a job to keep it in sync. Denormalizing because joins scare me is a junior move.

If I store course_name on every student-course row, renaming a course means updating many rows — update anomaly. If no student is enrolled I cannot even insert the course — insert anomaly. 3NF puts courses in their own table. I would draw two tables in the interview. Anomalies are why we normalize, not the '1NF 2NF 3NF' chant alone.

1NF means atomic cells and no repeating groups. I would not store 'Java,SQL,Redis' in one skills column if I need to query each skill. I would make a student_skill table. Comma-separated values look fine until I want all students who know Redis. That is the example I use. I would not start with 5NF.

A junction table student_course with student_id and course_id, unique on the pair, maybe with enrolled_at. That is the 3NF shape. I would not put a course_id array on student unless I have a strong read reason and a database that queries arrays well. I would index both FKs. This is the design question hiding inside normalization.