Learn · SQL · Core
Normalization
Normalization is organising your tables so no fact is stored twice. It’s why you keep customers in one table and orders in another instead of repeating the customer’s details on every row.
Before we start
- What normalization is and the problem it solves
- 1NF, 2NF, 3NF in plain words
- Update anomalies and why duplication is dangerous
- When to deliberately denormalize
- Explain why we split data across tables
- Spot redundant data in a schema
- Say the trade-off between normalized and denormalized
Why you’re learning it: good schema design is asked in DBMS interviews, and it’s why your joins exist. ⏱️ ~20 min.
The problem — duplication
Suppose every order row also stored the customer’s full name, email and address. Now the same customer’s address sits on 50 rows. Move house, and you must update 50 rows — miss one and your data disagrees with itself. That’s an update anomaly. The fix: store each fact once, in the table it belongs to, and link by id.
The three forms — plain words
| Form | Means |
|---|---|
| 1NF | Each cell holds one value — no lists crammed into a column, no repeating groups |
| 2NF | Every column depends on the whole key, not just part of it |
| 3NF | No column depends on another non-key column (store facts about a thing with that thing) |
Rule of thumb: “each fact lives in exactly one place.” If you’re repeating data, it probably wants its own table.
The trade-off — denormalization
Normalized data means more tables and more joins, which can be slower to read. Sometimes — for heavy read workloads or reports — teams deliberately denormalize (duplicate some data) for speed, accepting the maintenance cost. Knowing when to break the rules is senior-level judgement.
Where you’ll use it — real life
Every time you design tables, you’re normalizing — deciding what gets its own table.
Store the customer once → their info can never disagree across orders.
Split data must be rejoined to answer questions — normalization and joins are two sides of one coin.
Denormalization is the deliberate exception when reads must be fast.
Out loud: “What is normalization, what’s an update anomaly, and when would I denormalize?” Log it in your Journal.
Back to your Siemens roadmap →