To Data Warehouse Lifecycle ~upd~ | Kimball Approach

Key output: A prioritized list of business processes to model, along with conformed dimensions (shared, consistent lookup tables across the enterprise). Phases: Data Modeling, ETL Design & Development, BI Application Design.

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.

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

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.

Another criticism: ETL for slowly changing dimensions can be complex. But this complexity is essential if you need to answer "What was the customer’s region at the time of that sale last year?" Kimball gives you a pattern; Inmon’s normalized approach often cannot answer that question without massive joins. Today, the Kimball lifecycle has been absorbed into almost every major data warehousing platform. Snowflake’s documentation? Full of star schema examples. dbt (data build tool)? Its core philosophy of modular, testable, SQL-based transformations is a direct expression of Kimball’s layered ETL approach. Even the term "conformed dimension" is standard vocabulary for any modern data engineer. Key output: A prioritized list of business processes

Star schemas are highly denormalized, which plays perfectly to the strengths of columnar databases (Redshift, BigQuery, Snowflake) and traditional RDBMSs. Query optimizers love star joins.

That methodology is the .

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.