The big idea: Denormalisation deliberately stores some data more than once, to make reading it faster.
It is not a mistake or a shortcut. It is a considered trade: accept a risk to the data in exchange for speed.
Where the cost of 3NF shows up: Normalising spreads facts across many tables, so answering a question means joining them back together.
One join is nothing. Six joins, on millions of rows, run thousands of times a minute, is a real cost.
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.
Normalised
- Each fact stored once, so it cannot contradict itself
- Updates touch one row
- No insert or delete problems
- Reads need joins, which cost time
- Queries are longer to write and harder to read
Denormalised
- Some facts repeated, so they can disagree
- An update must find and change every copy
- Insert and delete problems come back
- Reads are fast — fewer joins, sometimes none
- Queries are short and simple
The deciding question: Is this data read far more often than it is written?
If yes, denormalising may pay. If it changes constantly, the cost of keeping every copy correct outweighs any speed gained.
Get feedback like a real examiner
Submit your answers and get instant feedback — what you did well, what's missing, and exactly what to write to score full marks.
A read-intensive report
A dashboard read thousands of times a day, from data updated once each night.
Storing the joined result directly means each read needs no joins at all — and the single nightly update keeps every copy correct.
A stored total
An order's total could be recalculated from its lines every time it is shown. Storing it on the order row removes that work.
The risk: if a line changes and the total is not updated, the two now disagree.
A data warehouse
Built for analysis rather than day-to-day work: loaded in bulk, then read repeatedly and almost never updated.
Denormalised by design, because the update problem barely exists there.
When NOT to
Anything written frequently — a live booking system, a bank balance, stock levels.
Every copy is another chance for the data to be wrong, at exactly the moment being wrong matters most.
Normalise first, then measure: Design in 3NF, run it, and find out where it is actually slow.
Denormalising before you have a measured problem gives away correctness for a speed gain you cannot show.
How this is tested — you must EVALUATE — name what is gained, what is risked, and decide from the read-write balance. It comes up two ways:
Paper 1 Section A
- Evaluate the need to denormalise, 4-6 marks
- Give an advantage and a disadvantage of each
- Say when denormalising is justified
Paper 1 Section B — case study
- Judge whether the case study should denormalise
- Justify it from how their data is used
The classic trap: Treating denormalisation as bad practice. It is a legitimate engineering decision — the mark is for naming the read-write balance that justifies it, not for disapproving.
A retailer's website shows a product page thousands of times an hour, built from five joined tables. Prices change weekly. Evaluate denormalising the product data.
Model answer plan
See the answer broken into clear points, with guidance on how each point earns marks.