Ralph Kimball's dimensional modeling is the bottom-up approach to warehouse design. Rather than building one enterprise model first, you build dimensional data marts one business process at a time - sales, then shipping, then support - and tie them together with shared dimensions. Each mart is a star schema, deliverable on its own, and the warehouse emerges as the union of marts rather than being designed as a monolith up front.

Model around business processes

The unit of work is a business process that produces measurements: taking an order, shipping a package, logging a support call. Each becomes a fact table at a clearly stated grain, surrounded by denormalized dimension tables for the descriptive context. The design follows four steps - pick the process, declare the grain, choose the dimensions, choose the facts - which keeps the model anchored to something the business actually does, not an abstract entity diagram. This is the inverse of Inmon's normalized-core-first method.

The conformed-dimension bus

What stops a pile of independent marts from becoming disconnected silos is the bus architecture. The marts share conformed dimensions - a single dim_date, dim_customer, and dim_product reused identically across every fact. Kimball captures this in a bus matrix: rows are business processes, columns are dimensions, and a mark shows which dimensions each process uses.

                date   customer   product   store
Sales            ✓        ✓          ✓        ✓
Shipments        ✓        ✓          ✓
Returns          ✓        ✓          ✓        ✓

Shared columns are the conformed dimensions. Once they're agreed, any new process that reuses them slots into the warehouse and can be compared drill-across with the others - which is how the federation grows into a coherent galaxy schema.

What you gain and what it costs

The strengths are speed and business alignment. You ship a useful mart in weeks, not after a multi-year enterprise build, and the star schemas are exactly what BI tools and analysts query well. The cost is discipline: the integration that Inmon gets from a normalized core, Kimball gets only by enforcing conformed dimensions across teams. Skip that governance and the marts drift apart, two reports disagree on "active customer," and you've rebuilt the silos the warehouse was meant to remove. Kimball suits organizations that need value fast and can commit to the conformed-dimension discipline that holds the bus together.

Frequently asked questions

What is the Kimball approach? A bottom-up method that builds dimensional data marts around individual business processes as star schemas, integrated through shared conformed dimensions rather than a normalized enterprise core.

What is the bus architecture? The framework of conformed dimensions shared across all marts, documented in a bus matrix (processes by dimensions). It lets independently built marts be compared and combined.

How does it differ from Inmon? Kimball builds dimensional marts first and integrates bottom-up via conformed dimensions; Inmon builds a normalized 3NF enterprise warehouse first and derives marts top-down.

When is Kimball the right choice? When you need a usable warehouse quickly and want it shaped for analyst and BI-tool querying, and you can enforce the conformed-dimension governance that keeps the marts consistent.