Theory
Meera's sheet finally breaks
This is the moment the whole unit has been building to. Meera's one giant sheet crams items, suppliers and customers into a single table, the supplier's phone number written again on every item row he supplies.
Then three things go wrong on the same day: she cannot add a new supplier, changing one phone number takes twenty edits, and deleting an old item accidentally erases a supplier entirely.
These are the three anomalies, and they are the exact reason normalization exists. Meera's pain is the textbook's lesson.
Theory
Writing your address on every page
Imagine a diary where, on every single page, you rewrite your full home address. Move house, and you must correct every page (miss one and your diary contradicts itself). Want to note your new address before your first entry? You cannot, there is no page yet. Tear out your only page and your address vanishes too. Repeating the same fact everywhere is the root disease. Normalization is writing each fact once.
Theory
The three anomalies
All three spring from redundancy, storing the same fact in many rows:
- Insertion anomaly: you cannot add some data without other, unrelated data. Meera cannot record a new supplier until he has supplied an item, because supplier details live only on item rows.
- Update anomaly: a fact stored in many rows must be changed in all of them. The supplier's new phone means editing every item row; miss one and the data contradicts itself.
- Deletion anomaly: deleting a row loses unrelated facts. Delete the supplier's last item and you erase the only record of that supplier's existence.
At a glance
The three anomalies
| Anomaly | The problem | Meera's case |
|---|---|---|
| Insertion | Cannot add X without unrelated Y | New supplier needs an item first |
| Update | Change a fact in many rows or contradict | New phone = edit every item row |
| Deletion | Deleting loses unrelated data | Remove last item, lose the supplier |
Quiz
Meera changes a supplier's phone number, but it is stored on 30 item rows. She updates 29 and misses one. What kind of anomaly just bit her?
- Update anomaly, the redundant value now contradicts itself across rows
- Insertion anomaly, she added new data
- Deletion anomaly, she removed data
- No anomaly, this is normal database behaviour
Show the answer
Update anomaly, the redundant value now contradicts itself across rows
The phone number is stored redundantly on 30 rows, so updating it means changing all 30; missing one leaves the database saying two different phone numbers for one supplier, an update anomaly. The root cause is redundancy. Normalization would store the phone once in a Supplier table, so one edit fixes it everywhere. This is the classic update-anomaly scenario.
Think first
The accidental erase
Meera deletes the last item a certain supplier ever supplied, just tidying up old stock. Suddenly she has NO record that this supplier exists at all. Name this anomaly, and explain why splitting tables would prevent it.
Show the answer
This is a deletion anomaly: removing an item row also removes the only stored copy of that supplier's details, unrelated information lost as a side effect. If suppliers lived in their own table (linked to items by a foreign key), deleting an item would touch only the item, the supplier record would survive untouched. Separating entities into their own tables is exactly what normalization does, and it makes all three anomalies vanish.
Watch out
Where marks leak
Not naming the three anomalies precisely (insertion, update, deletion) with a distinct example each, this is the exam's favourite structure. Forgetting that redundancy is the root cause of all three. And saying normalization is 'just splitting tables', say why: to remove redundancy and thereby the anomalies. Vague answers lose marks; concrete anomaly examples (like Meera's supplier phone) earn them.
Formula
Exam recipe: 'why do we normalize?'
State it in one shape: normalization removes redundancy to eliminate the three anomalies, insertion (cannot add X without Y), update (change a fact everywhere or contradict), deletion (lose unrelated data). Give one concrete example per anomaly. Then add: it is achieved by decomposing one table into several linked by keys. Definition + three anomalies + examples + method = full marks, every time.
Theory
The cure has steps
You now feel the disease in your bones (Meera's three disasters). The cure, normalization, is applied in stages called normal forms: 1NF, 2NF, 3NF, BCNF, each removing a specific kind of redundancy. That is the very next lesson. Everything about keys and attributes you have learned was preparing you for this fix. Next: the normal forms, and the rules that drive them.
Summary
Key takeaways
- Normalization splits a bloated table into well-designed ones to remove redundancy.
- Redundancy (repeating a fact in many rows) causes three anomalies.
- Insertion anomaly: cannot add data without other unrelated data present.
- Update anomaly: a redundant fact must change in every row, or it contradicts itself.
- Deletion anomaly: deleting a row loses unrelated information as a side effect.
- The cure is decomposition into separate tables linked by keys.
- Memory hook: do not rewrite your address on every diary page, write each fact once.