Concept 1 / 7
Why Normalization? Anomalies and Redundancy
When a relation schema bundles together facts about different entities, storing the same information in multiple tuples causes three classic problems:
| Anomaly | What goes wrong |
|---|---|
| Redundancy | The same fact (e.g. a department name) appears in every employee tuple — wastes space, risks inconsistency |
| Update anomaly | Changing one fact requires touching every tuple that contains it; a missed update leaves the database in an inconsistent state |
| Insertion anomaly | A new fact (e.g. a new department) cannot be recorded until at least one related entity (an employee) also exists |
| Deletion anomaly | Deleting the last tuple for some entity (e.g. the last employee in a department) silently destroys facts about the other entity (the department) |
Goal of normalization: Decompose a large relation schema R(A) with FDs F into smaller schemas Rᵢ(Aᵢ) such that:
- redundancy is minimized
- information is not lost (lossless-join)
- all constraints remain enforceable (dependency-preserving)
The normal form of a relation is the highest-level normalization condition it satisfies. 1NF is independent of FDs; 2NF, 3NF, and BCNF are defined in terms of FDs.