What Is a Conformed Dimension? Building Shared Context Across Fact Tables

A conformed dimension is a dimension table that is shared identically across multiple fact tables in a data warehouse. When the customer dimension used by the sales fact table and the customer dimension used by the support tickets fact table are the same table — same grain, same surrogate keys, same business key, same attributes — the customer dimension is conformed. This conformance is what enables integrated cross-process analytics.

The concept was formalized by Ralph Kimball and is a cornerstone of the Kimball dimensional modeling methodology. Conformed dimensions are the mechanism that makes an enterprise data warehouse an integrated analytical system rather than a collection of independent data marts.

Why Conformed Dimensions Matter

Without conformed dimensions, cross-process analysis is impossible or inaccurate.

Consider an organization with two independently built data marts: a sales mart with its own customer dimension built from Salesforce, and a support mart with its own customer dimension built from Zendesk. Both have customer tables. But:

- The sales customer dimension uses the Salesforce Account ID as the business key; the support customer dimension uses the Zendesk Organization ID

- The customer names are slightly different due to data entry inconsistencies

- The customer segments (small business, mid-market, enterprise) are defined slightly differently in each mart

Now ask: "what is the support ticket rate for customers in their first 90 days after signing?" This question joins sales data (contract start date) to support data (ticket date) to get an answer. Without a conformed customer dimension with a consistent customer key that means the same thing in both fact tables, this join produces incorrect or incomplete results.

Conformed dimensions solve this by ensuring the customer key in the sales fact table and the customer key in the support fact table refer to the same customer definition, at the same grain, with consistent surrogate keys. The join works cleanly, and the result is analytically trustworthy.

Designing Conformed Dimensions

A conformed dimension satisfies these requirements:

**Identical grain:** The dimension describes the same concept at the same level of detail across all fact tables that use it. A customer dimension at the account level is conformed across fact tables if both use account-level customer data — neither uses contact-level detail.

**Identical surrogate keys:** The integer surrogate key assigned to each customer is the same in every fact table. If customer ABC Corp has surrogate key 12345 in the sales fact, it must have surrogate key 12345 in the support fact. Key consistency is what makes joins between fact tables through the shared dimension produce correct results.

**Identical business key definition:** The natural business key — the real-world identifier that resolves to the conformed dimension record — must be consistently applied. When the same customer exists in Salesforce with one ID and in Zendesk with another, the MDM or entity resolution layer that maps both to the same conformed dimension record is the prerequisite for dimension conformance.

**Consistent attribute definitions:** The customer segment attribute in the conformed dimension means the same thing regardless of which fact table is queried through it. Segment definitions that differ between systems undermine conformance — the label is shared but the meaning is not.

Conformed Dimensions in Practice

In modern data warehouse implementations using dbt, conformed dimensions are built in the transformation layer as shared staging or mart models:

The raw data from Salesforce (accounts, contacts) and Zendesk (organizations) flows through staging models that standardize field names and clean values. An entity resolution step (using a mapping table, probabilistic matching, or manual curation) produces a canonical customer table with a single surrogate key per customer. The sales fact table and support fact table are both built with references to this canonical customer dimension.

**The dimensional bus matrix** is the planning tool for managing conformed dimensions across a multi-mart enterprise warehouse. It is a grid with fact tables as rows and dimension tables as columns; a checkmark in a cell indicates that the fact table conforms to that dimension. The bus matrix makes conformance explicit — you can see which dimensions are shared and identify gaps where a dimension is used in one fact but not another that it should join to.

Conformed Facts

Related to conformed dimensions is the concept of conformed facts — measure definitions that are identical across fact tables and business units. Revenue per customer means the same thing whether calculated from the sales fact or the subscription fact. Conforming the metric definition (which revenue lines are included, how refunds are treated, which contract types are counted) ensures that analysis combining data from both fact tables produces consistent numbers.

Conformed facts are implemented at the semantic layer — dbt Semantic Layer, Looker LookML, or Cube.dev — where the metric definition is encoded once and referenced by any report or analysis that uses it. When the definition must change, it changes in one place and propagates everywhere.

Our data architecture services practice designs dimensional models with conformed dimensions and metrics, enabling the integrated enterprise analytics that requires cross-process analysis to be accurate. Contact us to discuss your data warehouse architecture.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.