The big idea: Normalisation rearranges tables so every fact is stored in exactly one place.
A fact stored twice can end up with two different values. A fact stored once cannot.
The word that runs through all of it: A functional dependency means one column's value determines another's.
Know a StudentID and you know the student's name: Name depends on StudentID. Normal forms are rules about which dependencies are allowed where.
Free preview
This is the free notes preview
You're reading the free notes. Aimnova Pro unlocks the full study experience — and you can try it with your first topic free to keep:
- FlashcardsLock in vocabulary and key terms with spaced repetition.
- Practice questionsAnswer exam-style questions and get instant AI marking.
- Mock exams & past-paper vaultSit full mocks and see exactly how examiners award marks.
- Personalised study planA daily plan built around your exam date and weak areas.
One school table taken from unnormalised to 3NF, with the rule and the problem named at each step.
Interactive diagram
Explore the labelled diagram, charts and maps for this topic in full study mode.
1NF — atomicity
Every cell holds one value, and every row is uniquely identified.
No lists in cells and no repeating groups of columns. A Clubs cell reading "Chess, Debate" becomes two rows.
2NF — no partial-key dependencies
In 1NF and every non-key column depends on the whole primary key, not part of it.
Only matters when the key is composite. StudentName depended on StudentID alone, which is half the key, so it moves to its own table.
3NF — no transitive dependencies
In 2NF and no non-key column determines another non-key column.
Club determined Teacher, and Teacher determined Room. Room depends on Club only indirectly — so Teacher and Room move to their own table.
A one-line test for each: 1NF — is any cell holding a list? 2NF — does anything depend on only part of a composite key? 3NF — does any non-key column depend on another non-key column?
See how examiners mark answers
Answer exam-style questions with model answers. Learn exactly what earns marks and what doesn't.
Update problems
- A teacher's room is written on every row they appear on
- Change it and you must find every copy
- Miss one and the database contradicts itself
Insert problems
- A new club with no members yet has nowhere to live
- You cannot record a club without inventing a fake student
- Missing data where the design forces it
Delete problems
- Remove the last student in a club
- The club's teacher and room disappear with them
- Data lost that nobody meant to delete
Why these three are the argument: "It saves space" is the weakest reason and rarely worth a mark.
The real case is that an unnormalised table makes it possible to be wrong — and a normalised one does not.
Multi-valued dependencies: A multi-valued dependency appears when one key has two independent lists stored in the same table — a student's sports and, separately, the languages they speak.
Every sport has to be paired with every language, so the table fills with repeated rows. The fix is the usual one: give each independent list its own table.
How this is tested — you must name the form, state its rule, and identify the offending dependency. It comes up two ways:
Paper 1 Section A
- Explain the difference between normal forms, 3-5 marks
- State which form a given table is in, and why
- Define a named dependency
Paper 1 Section B — case study
- Assess the case study's table design
- Explain the problems its current shape causes
The classic trap: Saying a table "is not in 3NF" without naming which dependency breaks it. The mark is for identifying the offending columns: Teacher determines Room, and neither is a key.
A table stores OrderID, ProductID, Quantity, ProductName and SupplierAddress, keyed on OrderID and ProductID. Explain which normal forms it breaks.
Model answer plan
See the answer broken into clear points, with guidance on how each point earns marks.