Normalisation to Third Normal Form
Splitting tables until every field depends on the key, the whole key, and nothing but the key. Each step removes a way the data could contradict itself after an update.
What a learner can do afterwards
- Take an unnormalised table through first, second and third normal form
- Name the update, insert or delete problem that each step removes
- Say when a designer might accept a repeated field on purpose
1 · Read
Normalisation is the discipline of splitting tables until every field depends on the key, the whole key, and nothing but the key. Each split kills a way the data could contradict itself after an update. Good design starts by asking what the things are and how they relate.
An orders table repeats the customer address on every order. One day an address changes and the update misses a row, so two rows disagree and nobody knows which is right. Move the address into a Customers table and leave only the customer key on each order. That split just killed the update anomaly.
First normal form needs one value per cell, with no repeating groups, so split lists into their own rows. Second normal form needs every non-key field to depend on the whole key, not just part of it. Third normal form needs every field to depend on the key alone, never on another non-key field.
Name the victim of every split: the update problem, the insert problem, or the delete problem. Without a split you cannot add a new product unless you invent a fake order to hang it on, and deleting the last order can wipe out a product entirely. A designer may still repeat a field on purpose for speed, but only knowingly, while guarding it.
Split until every field answers to the key alone, and name the anomaly each split destroys.
2 · Watch
Take it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.