Conformed dimension

What is a conformed dimension?

A conformed dimension is a dimension table that is reused consistently across several fact tables, data marts, or business processes. Typical examples are Date, Customer, Product, Store, Employee, and Supplier.

The same dimension means the same keys, the same values, the same attributes, and the same business definitions. If March 2026, customer 4021, or product group spare parts appears in several reports, it should mean the same thing everywhere.

Ralph Kimball's definition is still the clearest one: dimensions conform when attributes in separate dimension tables have the same column names and the same domain contents. They may be identical, or one may be a clean subset of another, such as a Month dimension derived from a Day dimension.

In plain business language: sales, finance, and support should not each keep their own slightly different customer list if the company wants one customer view.

Why conformed dimensions matter

The value is comparison. When two fact tables share the same dimension, their numbers can be placed on the same row in a report.

Suppose sales revenue is stored in one fact table and marketing spend in another. If both tables use the same Date and Product dimensions, you can show revenue and marketing cost by product group and month. Kimball calls this drill-across reporting: measures from different fact tables are aligned by shared conformed dimension attributes.

Without those shared dimensions, the report becomes a reconciliation exercise. One table uses fiscal month, another uses calendar month. One team groups products by commercial category, another by warehouse category. The numbers may be correct in isolation, but they will not line up cleanly.

A simple example

Imagine a retailer with two fact tables.

Sales fact
One row per sold order line: date, store, product, quantity, revenue, discount.

Inventory snapshot fact
One row per product, store, and day: date, store, product, quantity on hand.

The two tables describe different processes at different grains. Sales happens transaction by transaction. Inventory is captured as a daily snapshot. They still become comparable because both tables point to the same Date, Store, and Product dimensions.

Now a report can show monthly sales next to average inventory by product group. That works because March 2026, Store 14, and Product 90018 are not three local interpretations. They are shared dimension rows.

Conformed dimensions in the Kimball bus architecture

Conformed dimensions are the backbone of the Kimball enterprise bus architecture. Instead of building one huge data warehouse in a single project, you build business process by business process: sales, inventory, invoicing, returns, service, delivery.

Each process gets its own fact table. Integration happens through shared conformed dimensions.

The planning tool is the bus matrix. Rows are business processes. Columns are dimensions. A marked cell means that process uses that dimension. The matrix shows which dimensions must be standardised and in which order data marts can be delivered without creating disconnected reporting islands.

This is why conformed dimensions belong with star schemas and dimensional modelling. They are the mechanism that turns separate stars into a coherent warehouse.

What goes wrong without them

Without conformed dimensions, every team builds its own local truth.

Sales defines a customer by CRM account. Finance defines a customer by billing entity. Support defines a customer by contract. Ecommerce defines a customer by email address. Each report may be defensible, but the moment management asks for revenue, complaints, and margin by customer segment, the definitions clash.

A conformed dimension forces the disagreement to be solved at the model level instead of in every meeting. That does not mean every source system becomes identical. It means the reporting layer has one agreed way to identify, group, and describe the entity.

Conformed dimension versus related patterns

Role-playing dimension
A role-playing dimension is the same dimension used more than once in one fact table. A Date dimension might appear as Order Date, Ship Date, and Invoice Date. That is different from conformance, which is about reuse across fact tables. The same Date dimension is often both role-playing and conformed.

Slowly changing dimension
A slowly changing dimension tracks changes in descriptive attributes, such as a customer's segment or a product's category. A conformed dimension can also be slowly changing. The key is that every fact table uses the same versioning logic.

Master data management
Master data management governs the source-of-truth records for customers, products, suppliers, and similar entities. A conformed dimension often consumes that master data and turns it into a reporting-friendly dimensional table.

What to watch out for

Do not conform labels only
Calling two columns CustomerId is not enough. The keys and business meaning must match.

Agree grain and history
Is Customer one legal entity, one branch, one contact person, or one CRM account? Do you report the current segment or the segment at the time of the sale? Decide this before several marts depend on it.

Govern changes
A shared dimension needs ownership. If someone changes product hierarchy or customer grouping, every report using that dimension may change.

Allow clean subsets
Not every process needs every attribute. A smaller month-level date dimension can conform to a day-level date dimension if the shared attributes still mean the same thing.