The big idea: An operational database is optimised for recording transactions — many small writes, one row at a time.
A data warehouse is optimised for asking questions of history — few enormous reads scanning years of records. They are the same data with opposite requirements.
| Operational (OLTP) | Warehouse (OLAP) | |
|---|---|---|
| Optimised for | Writing — many small transactions | Reading — few huge queries |
| Holds | Current state | History, often years of it |
| Structure | Normalised — no duplication | Denormalised — deliberately duplicated |
| A typical query | One customer's balance | Sales by region by quarter since 2019 |
| Users | The application, constantly | Analysts, periodically |
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.
Four reasons
- Load — a query scanning five years of sales would slow the system customers are using right now
- History — operational systems overwrite. Yesterday's price is simply gone
- Many sources — sales, web, stock and support each have their own database and their own formats
- Structure — normalised tables need many joins per analytical query; a warehouse denormalises so those joins are already done
ETL is where the work is: Extract from each source system · Transform into one consistent shape — the same date format, the same country codes, the same definition of "a sale" · Load into the warehouse.
The transform step is where most of the effort goes, because every source defines things slightly differently.
Denormalised on purpose: A warehouse breaks the normalisation rules deliberately. Update anomalies are the usual objection — but a warehouse is rebuilt in bulk, not edited by users, so the anomaly cannot arise.
That is what makes the trade safe here and unsafe in an operational system.
Feeling unprepared for exams?
Get a clear study plan, practice with real questions, and know exactly where you stand before exam day. No more guessing.
Not live
- Loaded on a schedule — nightly is common
- So it is out of date by design
- Never use it to answer "what is the stock right now?"
Not a backup
- It holds transformed data, not the originals
- You could not restore the business from it
- Different purpose entirely
Not free
- Storage for years of duplicated history
- The ETL pipeline must be built and maintained
- Every source change breaks it until it is updated
Name the latency: Saying "a warehouse is not real-time — it is loaded nightly, so it answers questions about the business up to yesterday" is frequently a mark. It shows you know what the design costs.
How this is tested — you must separate recording from analysing, and justify the duplication a warehouse involves. It comes up two ways:
Paper 1 Section A
- Explain the objectives of a data warehouse, 3-4 marks
- State one difference from an operational database
- Name the stages of ETL
Paper 1 Section B — case study
- Justify a warehouse for a scenario
- Explain why denormalisation is acceptable here
The classic trap: Describing a warehouse as "a copy of the database". It holds transformed, integrated history from several sources, deliberately denormalised — and it is only current to the last load.
A supermarket chain wants to analyse five years of sales across 200 stores alongside its loyalty and stock systems. Explain why a data warehouse is appropriate rather than querying the existing databases.
Model answer plan
See the mark-by-mark plan — for / against / judgement, with marking guidance — in study mode.