From Ledgers to Intelligence Part 2: The Data Warehouse Revolution Inmon, Kimball, and the Birth of OLAP
Digital Transformation | May 2026
For thirty years after the first mainframes were installed in corporate data centres, analysts faced the same fundamental problem: the systems that ran the business were not designed for analysis. Transaction processing systems order management, payroll, inventory were optimised for high-volume, concurrent writes. Querying them for analytical purposes slowed them down, produced inconsistent results as data changed mid-query, and returned raw transactional detail rather than the summarised, comparable figures that management needed.
The data warehouse was invented to solve this problem. The idea was architecturally simple: separate the analytical workload from the operational workload by maintaining a dedicated, purpose-built store of historical, integrated, subject-oriented data. In practice, designing and building that store turned out to be one of the hardest problems in enterprise computing and it generated a debate between two schools of thought that reverberates to this day.
Bill Inmon and the Top-Down Architecture
Bill Inmon, often called the “father of the data warehouse,” published Building the Data Warehouse in 1992. His definition of a data warehouse has four components, each addressing a specific failure mode of the MIS/EIS era:
- Subject-oriented: organised around business subjects (customers, products, sales) rather than around the applications that created the data (order management system, CRM, billing system).
- Integrated: data from multiple source systems is reconciled into consistent definitions, formats, and values before being loaded.
- Non-volatile: once data enters the warehouse, it is not updated or deleted. The warehouse is a historical record. Operational corrections are represented as new records, not overwrites.
- Time-variant: every record carries a timestamp, allowing point-in-time queries “what did we know about this customer on 1 January 2019?”
Inmon’s architectural vision was top-down. The warehouse contained normalised, enterprise-wide data a canonical representation of the business. From this central store, data was distributed into smaller, subject-specific “data marts” for individual business units. The warehouse came first; the marts followed.
Ralph Kimball and the Bottom-Up Approach
Ralph Kimball took a different view. Where Inmon prioritised architectural correctness, Kimball prioritised speed to value. His approach documented in The Data Warehouse Toolkit (1996) centred on dimensional modelling: organising analytical data into a structure optimised for querying rather than normalisation.
The core construct of dimensional modelling is the star schema. At the centre sits a fact table a table of measurements (sales amount, order quantity, transaction value), each row representing a business event. Surrounding it are dimension tables descriptive context (customer, product, date, geography). Querying this structure is intuitive: to find total sales by product category by quarter, join the fact table to the date dimension (filter on quarter) and the product dimension (group by category).
Kimball’s architecture was bottom-up: start with a single, business-valuable dimensional model (the “data mart”), deliver value quickly, and accumulate marts over time into a unified architecture (“the data warehouse bus”). The bus was connected by “conformed dimensions” shared dimension tables (particularly the date and customer dimensions) that allowed queries to span marts consistently.
OLAP: Multidimensional Analysis
Parallel to the warehouse debate, a new category of analytical technology was emerging: Online Analytical Processing (OLAP). Edgar Codd whose relational model had defined OLTP published a 1993 paper outlining 12 rules for OLAP systems, which he distinguished sharply from relational databases. OLAP, in Codd’s formulation, should support multidimensional views of data, allow analysts to “slice and dice” along any dimension, and produce results in seconds rather than minutes.
Early OLAP products stored data in proprietary multidimensional cubes pre-calculated aggregations across all combinations of dimensions enabling fast query response at the cost of flexibility and storage. Oracle Express (acquired from IRI Software in 1995) and Arbor Software’s Essbase were the dominant MOLAP (Multidimensional OLAP) products. IBM’s DB2 OLAP Server was an early enterprise entrant.
As relational databases gained performance and optimisers became more sophisticated, ROLAP (Relational OLAP) serving OLAP-style queries directly from relational databases emerged as an alternative. The MOLAP vs ROLAP debate prefigured later arguments between pre-aggregated columnar stores and serverless query engines: the same trade-off between query speed (pre-computation) and flexibility (compute-on-query).
🏗️ Architecture: The Data Warehouse Era (1990s)
🏭 OLTP Sources (ERP, CRM, Billing) Normalised, Volatile → 🔄 ETL Process (Nightly Batch Extraction) → 🏛️ Enterprise Data Warehouse (Inmon: 3NF) → ⭐ Data Marts (Kimball: Star Schema) → 📊 OLAP Cubes (Essbase, Oracle Express) → 📋 Reports (Fixed Format, IT-Delivered)
Why Both Camps Were Right
The Inmon vs Kimball debate was framed as a binary choice throughout the 1990s and 2000s, generating enormous consulting revenue and considerable heat. In retrospect, both approaches addressed real problems.
Inmon was right that enterprise data needs a canonical, integrated, historically consistent representation. Without normalised, reconciled master data at the foundation, every query that spans departments produces inconsistency. The “single version of the truth” is not achievable without a shared model and that model needs to be maintained centrally.
Kimball was right that analyst-friendly structures require denormalisation. A query that requires joining twenty tables to answer a simple business question is not a practical analytical tool. The star schema is not a compromise of data integrity; it is a recognition that analytical and transactional workloads have fundamentally different optimal structures.
Most mature implementations converged on a hybrid: an Inmon-style normalised “enterprise data warehouse” (EDW) at the centre, from which Kimball-style dimensional models were derived for specific analytical domains. This pattern normalised core, dimensional consumption layer remains a dominant architecture pattern in on-premise warehouse deployments to this day.
The Hardware Constraint
Early data warehouses ran on the same relational database technology as OLTP systems Oracle, IBM DB2, Sybase. These row-oriented databases stored data in rows, which is efficient for retrieving individual records but inefficient for analytical queries that need to aggregate a single column across millions of rows. Running a data warehouse on a row-oriented database required careful physical design: clustered indexes, partitioning strategies, pre-summarised aggregation tables, and careful management of query plans.
The Teradata Data Warehouse Appliance, introduced in the 1980s, took a different approach: massively parallel processing (MPP) architecture purpose-built for analytical workloads. Teradata systems spread data across many parallel processors, each handling a portion of every query simultaneously. For large-scale analytics, this architecture was transformative and correspondingly expensive, placing enterprise-scale analytics out of reach for all but the largest organisations.
References
- Inmon, W. H. (1992). Building the Data Warehouse. John Wiley & Sons.
- Kimball, R. & Ross, M. (1996). The Data Warehouse Toolkit. John Wiley & Sons.
- Codd, E. F., Codd, S. B. & Salley, C. T. (1993). Providing OLAP to User-Analysts: An IT Mandate. E.F. Codd & Associates.
- Chaudhuri, S. & Dayal, U. (1997). An Overview of Data Warehousing and OLAP Technology. ACM SIGMOD Record, 26(1), 65–74.
- Kimball, R. & Caserta, J. (2004). The Data Warehouse ETL Toolkit. Wiley.
- Inmon, W. H., Hackney, D. & Imhoff, C. (2001). Using the Data Warehouse. Wiley.
- Devlin, B. A. & Murphy, P. T. (1988). An architecture for a business and information system. IBM Systems Journal, 27(1), 60–80.
📊 From Ledgers to Intelligence: The Evolution of Data Analytics | ← Part 1: Origins of Decision Support | Series Index | Part 3: ETL and the Relational Pipeline →
Comments 00