Kimball bus matrix

What is the Kimball bus matrix?

The Kimball bus matrix is a planning grid that captures an entire data warehouse on a single page. The rows are the organisation's business processes, and the columns are the dimensions those processes share. Where a dimension applies to a process, you mark the cell. Ralph Kimball and the Kimball Group introduced it as the tool for designing and communicating what they call the enterprise data warehouse bus architecture.

The name borrows from a computer's bus, the shared backbone that every component plugs into. In a warehouse, the shared backbone is a set of common dimensions, and every business process plugs into the same ones.

Filled in, the matrix reads like a map. A retailer might have rows for sales, inventory, purchasing, and returns, and columns for date, product, store, customer, and supplier. A glance shows that sales uses date, product, store, and customer, while purchasing uses date, product, supplier, and store. The dimensions repeat across rows, and that repetition is the whole point.

How to read the matrix

Each row is one business process: a real activity the business carries out that generates measurements, such as taking an order or shipping a pallet. A row becomes a fact table, so choosing the rows is choosing what you will measure.

Each column is a dimension: the descriptive context you slice those measurements by, such as date, customer, or product. When a dimension is shared across several processes, it is a conformed dimension, meaning it has one agreed definition, one set of attribute names, and one set of values wherever it appears.

The design team works the grid in both directions. Reading across a row checks that a process has all the dimensions it needs. Reading down a column checks where a dimension has to be conformed, because the same customer or product dimension will feed sales, returns, and support alike, and all of them must agree on what a customer is.

Building a warehouse one row at a time

The matrix earns its keep as a delivery plan. Instead of designing the whole warehouse before shipping anything, a team implements one row at a time. Each row is a self-contained project: one business process, its fact table, and the dimensions in its shaded cells.

Because the dimensions are conformed, the second row reuses dimensions the first row already built. Ship sales first, and its date, product, and customer dimensions are ready when inventory arrives next. The warehouse grows process by process without turning into a set of disconnected islands, and business managers can prioritise which row delivers value first.

This is the practical answer to the classic trap of building isolated data marts that each define customer differently and never join up. The bus matrix keeps every increment plugged into the same shared dimensions from the start.

The matrix and drilling across

Conformed dimensions are what make the matrix more than a to-do list. Because sales and returns both hang off the same customer and product dimensions, you can drill across: query each fact table separately by the same dimension attributes and line the results up side by side.

That gives you answers no single fact table holds on its own, such as units sold next to units returned per product per month. Without conformed dimensions the two numbers would sit in incompatible tables and never reconcile. The columns of the bus matrix are, in effect, a promise that this kind of cross-process comparison will hold together.

What to watch out for with the bus matrix

A row is a business process, not a department or a report. Rows drawn from org charts (the sales team, the finance team) produce overlapping, badly grained fact tables. Anchor each row to a real activity that generates measurements.

Conforming dimensions is organisational work, not just modelling. Getting sales and support to agree on one definition of customer means resolving a business disagreement. The matrix surfaces that conversation early, and it still has to happen.

Keep it current. A bus matrix drawn once and left in a slide deck stops matching the warehouse within months. Treat it as a living design document that changes as processes and dimensions are added.

It plans, it does not build. The matrix tells you what to build and in what order. The grain statements, keys, and attributes of each fact table and dimension table are the detailed work that follows.