“A data warehouse is a subject-oriented, integrated, time-variant, and nonvolatile collection of data in support of management's decision making process.”W. H. Inmon · Building the Data Warehouse · 1992 · Building the Data Warehouse (1992), cap. 2 — definiția depozitului de date
Subject-oriented, integrated, time-variant, nonvolatile: four adjectives, one architecture.
Inmon's four adjectives are really four design decisions. Subject-oriented: data is organised by customer, product, order — not by the applications that produced it. Integrated: the same country codes, the same units, the same keys, however many sources sit behind them; integration is the most expensive part of the work and the reason the warehouse exists at all. Time-variant: every row is a dated snapshot, and history is kept rather than overwritten. Nonvolatile: data is loaded and read; it is not corrected in place the way a transactional system corrects it. The production system answers "what is this customer's address now?". The warehouse answers "how has order value moved across regions over the last five years?". The first question wants one row, fast and consistent. The second wants millions of rows that can be compared with each other. They are two different jobs, and the lessons that follow show why the same engine does not do both well.
Integration is not a one-time job. It is an ongoing practice. Every source system comes with its own habits: one store writes "RO", another "Romania", another a numeric code. The warehouse picks a single form and keeps it, for every new load. That is why the real work is not copying but translation — deciding what "same customer" or "same sale" means across different sources. Think of two branches tracking the same customers with names spelled differently. Without a shared rule, the customer count doubles on paper. Once translation becomes a daily discipline, a new question appears: what do we do with old rows when the rule changes?
The previous passage ended with a natural question: what do we do with old rows when the integration rule changes? Inmon's answer is a design decision, not an accident: the warehouse does not delete them. It is nonvolatile — data gets loaded and read, but not corrected in place, as in a transaction system. If the store updates your address, the production system overwrites the old row and moves on. The warehouse keeps both versions, each with its own date. This creates comparable history: you can see not just where the customer lives now, but where they lived when each order was placed. Think of a subscriber who moves from Cluj to Bucharest mid-year. A report by county only makes sense if orders from the first half stay tied to Cluj. But if nothing is deleted, the warehouse grows endlessly — which raises another question: how do you quickly find what you need in such a huge pile?
Why it matters Without a warehouse, every report does its own integration — and each does it slightly differently. Decisions need comparable history, and comparable history is exactly what production systems do not keep.