An independent study reference written by Dr Phuc V. Nguyen. It is not official subject material — for assessment requirements always follow your subject outline and vUWS.
The data warehouse
A data warehouse is a separate database built for analysis rather than for running the business. Inmon's four properties define it. It is subject-oriented, organised around customers or sales rather than around an application. It is integrated, with codes and units reconciled across source systems. It is time-variant, keeping history instead of overwriting it. It is non-volatile: once loaded, records are read rather than edited transaction by transaction, whether the load arrives as a nightly batch or as a continuous stream. Operational systems are tuned for many small writes, and they often optimise for the current state, overwriting earlier values rather than keeping a dated history. Analysis needs the opposite, wide reads across years, and one database serving both degrades at both.
Why it matters
A shop's till records what is happening right now, and it has to be fast for one sale at a time. Nobody wants the till to freeze because head office is adding up three years of trading. The warehouse is the back room where a copy of everything is filed by subject, translated into one common language, and kept in date order so you can look back. The till answers "what do I charge this customer". The warehouse answers "what has been happening".
A firm updates customer and price records in place in its transaction system, holding no history table and no change log. A student argues that with fast enough hardware every analysis could run on that database. What is the strongest reason this still fails?
Worked examples
A retailer's finance team runs a monthly margin report directly against the point-of-sale database. It takes six hours, and store staff report checkout delays while it runs.
Two workloads are competing for one machine. The report scans years of rows and holds locks, while the till needs sub-second writes. Moving the report to a warehouse fixes both, but the deeper gain is history. The operational table here keeps only the current price, so last April's margin cannot be recovered once a price changes. The warehouse keeps a dated row for every price, which is what time-variant means and why the report becomes not merely faster but actually correct.
An analytics lead proposes replacing the warehouse with a data lake so nothing is discarded and no schema decisions are needed up front.
A lake is genuinely useful for raw and unstructured sources that have no agreed shape yet, and it removes the pressure to decide everything before landing anything. What it does not supply is integration. Two source systems that identify a customer differently still disagree inside the lake, and every analyst rediscovers the reconciliation alone. Most organisations end up with both: a lake as the landing area, and modelled tables downstream where definitions are agreed once and reused.
Common mistakes
- ✗A data warehouse is just a backup of the operational systems. A backup preserves a source as it was, while a warehouse reconciles conflicting codes and units across sources and keeps a dated history the source never held.
- ✗Warehousing is mainly about speed. Speed is the visible benefit, and the harder benefit is one agreed definition of a customer or a sale, which is what makes two departments' numbers match.
- ✗A data lake makes the warehouse obsolete. A lake removes the need to decide the shape up front, which helps with raw sources, and the integration and definition work still has to happen somewhere.
- ✗Non-volatile means the contents cannot be wrong. It means analysts do not edit rows one at a time; a faulty load can still put bad data in, which is why loads are logged and reproducible.
Revision bullets
- •Inmon: subject-oriented, integrated, time-variant, non-volatile
- •Operational systems favour small fast writes and often overwrite earlier values instead of keeping history
- •Warehouses hold history and favour wide reads across years
- •Integration is the hard part: one agreed definition across source systems
- •A data mart is a departmental subset; a lake is a raw landing area, not a substitute for modelling
Quick check
A firm updates customer and price records in place in its transaction system, holding no history table and no change log. A student argues that with fast enough hardware every analysis could run on that database. What is the strongest reason this still fails?
Two departments report different total sales for the same quarter, both querying the same warehouse. Which warehouse property is most likely failing?
Connected topics
More in Data Foundations
Sources
- Inmon (2005)Inmon, W. H. Building the Data Warehouse, 4th ed. Wiley, 2005.Source of the subject-oriented, integrated, time-variant, non-volatile definition.
- Kimball & Ross (2013)Kimball, R., & Ross, M. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, 3rd ed. Wiley, 2013.The dimensional counterpart to Inmon, arguing from business process and query readability rather than from an enterprise model.