Conformed Dimension

Two teams build marts. Sales models orders by customer; support models tickets by customer. Each has a customer dimension, each is correct in isolation, and the first executive question that crosses them — revenue per support contact — produces two different customer counts and an afternoon of argument.

A conformed dimension is the same dimension table, with the same keys and the same attribute meanings, shared by both facts. Where a full shared table is not possible, conformance can be partial: the dimensions agree on a subset of attributes and on the key, which is enough to allow a drill-across query.

The idea comes from Kimball's dimensional modelling work in the 1990s, and it survives every change of storage technology because the problem it solves is semantic, not technical.

Why it matters

Without conformance, each fact table's dimension is a private definition, and cross-process analysis becomes a reconciliation project each time it is asked for. The cost is not compute; it is the meeting.

Conformance is also what makes a bus matrix usable: business processes as rows, dimensions as columns, and a mark where a process has facts at that dimension's grain. It tells you in one page which questions the estate can answer today and which it cannot, which is a rarer artefact than it should be.

Implementation patterns

• Publish one dimension table per real-world entity, owned by a named team, with surrogate keys generated in one place.
• Version attribute meaning explicitly, so customer_segment has a documented definition and a change to it is an event with a date rather than a silent restatement.
• Where teams must own their own tables, conform on the key and a documented attribute subset, and test it: a scheduled job comparing distinct key counts and attribute distributions across the two tables is a cheap, effective control.
• Handle history with a slowly-changing-dimension strategy chosen once for the shared dimension, because two teams with different strategies will disagree on any historical query.
• Treat date as the first conformed dimension, including fiscal calendars, because almost every cross-process question is time-bounded.

Industry example

Every large analytics estate rediscovers this. The published accounts of metric layers built in the 2010s and 2020s — Airbnb's Minerva work being the widely cited example — begin with the same symptom: teams computing the same measure from differently defined entities, and an organisation unable to say which number is right. The metric layer is conformance applied to measures; the conformed dimension is the same discipline applied to the things measures are sliced by, and a metric layer over unconformed dimensions still produces two answers.

Failure scenarios

• Two customer dimensions with overlapping but unequal populations, so any drill-across query silently drops rows.
• A shared dimension quietly re-keyed by one team's reload, orphaning facts elsewhere.
• Attribute drift: one mart updates the segmentation rule, the other does not, and a year-on-year comparison shifts for reasons no query explains.
• A dimension conformed in structure but not in grain, for example customer at account level in one mart and at contact level in another.
• Conformance by copy: a nightly duplicate of the shared dimension that falls behind, which reintroduces the original problem with a timestamp.

Trade-offs

Conformance costs coordination: a shared table has an owner, a change process and consumers who must be told before an attribute changes. That is precisely the friction domain-oriented teams try to remove, and the honest position is that conformance buys cross-domain questions and sells some domain autonomy. Buy it only for the dimensions that are actually crossed — typically date, customer, product and organisation, rarely more than a dozen.

When not to use it

A dimension used by exactly one fact table does not need to be conformed, and forcing it into a central model adds a dependency for no analytical gain. Similarly, in a genuinely federated organisation where cross-domain analysis is rare and the entities differ in meaning (a "customer" in a regulated subsidiary may legally not be the same customer), conformance is an expensive fiction. Publish the mapping instead of pretending the entity is one.

Interview question

Q: Two domain teams each own a customer dimension, and the CFO wants revenue per support contact. You are told a central customer master is politically impossible this year. What do you deliver instead, and what do you tell the CFO about the number's limitations?

What a strong answer covers: conforming on the key and a minimal attribute subset rather than merging tables; a mapping table with a documented match rate; a scheduled test comparing populations so the divergence is measured rather than argued; publishing the number with its match rate attached; and being explicit that an unmatched tail means the metric is a lower bound — which is more useful to a CFO than a precise number that is wrong.

Quick check

Quiz: What is the minimum needed for two marts to support a drill-across query? — A shared key and agreement on the meaning and grain of the attributes being used, even if the tables stay separate.

Flashcard: Which dimensions are worth conforming? — The ones crossed by more than one business process: date, customer, product, organisation. A dimension used by one fact table is not worth the coordination.