Here, the famous Kimball dimensional model is created. A fact table is designed for a single business process (e.g., "Daily Sales Facts"). Dimensions are "conformed" so they can be used across multiple fact tables—ensuring that "Customer" means the same thing in Sales and Returns.
The other pillar of the philosophy is . Instead of complex, normalized schemas (third normal form) that confuse analysts, Kimball advocates for star schemas: a central fact table containing quantitative measures (sales dollars, units sold) surrounded by dimension tables containing descriptive attributes (customer name, product color, date). This design is intuitive, fast, and resilient to change. The Kimball Lifecycle: A Roadmap, Not a Waterfall The Kimball lifecycle is often visualized as a circular, iterative flow, not a straight line. It comprises nine high-level phases, but they group into four critical stages. Stage 1: Planning & Business Alignment Phases: Project Planning, Business Requirements Definition, Technical Architecture Design.
You don't need to build everything at once. The first dimensional model pays for itself; each subsequent model adds value without breaking prior work. The Criticisms (And Why They Don’t Kill It) Critics say Kimball is too rigid for unstructured data (JSON logs, text, images) or real-time streaming. And it’s true—raw data lakes are better for data science exploration. However, the modern response has been hybrid: use a lakehouse for ingestion and exploration, then serve refined, business-trusted data through Kimball-style dimensional models for reporting and BI. kimball approach to data warehouse lifecycle
Adding a new data source or attribute? You often just add a row to a dimension or a column to a fact table. No massive schema redesign.
What Kimball truly gave the industry is a contract between technical teams and business users: you define the business process and its key metrics; we will build a dimensional model that answers any question about that process quickly and correctly. The Kimball approach to the data warehouse lifecycle is not the trendiest topic at a data engineering conference. It does not promise to replace your data team with AI. But if you need to answer a business question—"What were our sales of red shoes to left-handed customers in Texas during last year's Q3 promotion?"—quickly, correctly, and with trust, you will eventually arrive at a dimensional model. Here, the famous Kimball dimensional model is created
Simultaneously, the back room (ETL) and front room (BI) are developed in parallel. Kimball famously separates the (data staging area: messy, technical, high-volume) from the presentation area (dimensional models: clean, business-facing, accessible). The ETL system must handle slowly changing dimensions (SCDs)—tracking historical changes like a customer’s address over time—a signature Kimball contribution. Stage 3: Deployment & Iteration Phases: BI Application Development, Deployment, Maintenance & Growth.
This is where Kimball distinguishes itself from "big bang" Inmon approaches. A Kimball warehouse goes live in weeks or months, not years. Each iteration delivers concrete, queryable value. Phases: Program Management, Ongoing Support. The other pillar of the philosophy is
The final phase is often overlooked but crucial. Kimball insists on a that manages conformed dimensions, tracks business requirement changes, and oversees the growing bus matrix. Without this, the warehouse degrades into a set of isolated, inconsistent data marts—the very problem Kimball designed to solve. Why Kimball Wins in Practice 1. Understandability: Business users can read a star schema. They know that "Sales Amount" lives in the fact table and "Customer Name" lives in the customer dimension. Queries are simple joins.