Conforming Dimensions and Data Conformance
One definition, many trusted facts
An entity (customer, product, date) used identically across facts is a conformed dimension. Conformance is what lets separate processes reconcile into one story.
What you will learn
- Define conformance and why it enables reconciliation
- Apply conformed keys and attribute alignment
- Detect conformance failures early
What is this?
Conformance means the same business entity is modeled identically wherever it appears — the customer '3' is the same customer with the same region and segment in every fact it touches. Conformed dimensions underpin cross-source reconciliation: sales and returns, finance and operations can agree because 'customer', 'product' and 'date' mean the same thing everywhere.
Why do you need it?
- Dashboards only reconcile when shared dims mean the same thing.
- Conformance prevents the classic 'sales says X, returns says Y' war.
- One conformed dimension replaces N graveyard copies.
- Master-data alignment is the practical key to conformance.
Mental model
Every team reading from the same office address book
Conformed dimensions
If marketing has 'Ann, EU' and ops has 'Anne, Europe', the two teams' numbers won't reconcile into one report. A single shared address book (conformed dim) — one canonical name, region and key — lets every team's facts agree when they meet on the same page.
How it works
- A conformed dimension has a shared surrogate key + canonical attributes funded by master data.
- Facts from different processes join to the same dim rows.
- Attribute values (region, segment) are governed, not invented per process.
- Role-playing still uses the same physical dim (e.g., single dim_date).
- Degenerate attributes bundled into facts (order id) are conformed via the id itself.
Shared dim anchoring multiple facts.
Examples
The conformance test
A conformed dimension passes three checks: 1. KEY : the same surrogate key is used by every fact. 2. TEXT : 'EU' is spelled the same in every attribute. 3. SCOPE : the attribute set is governed by one owner. Anti-pattern: fact_sales.dim_customer (EU) fact_returns.dim_customer2 (EUROPE) <- NOT conformed => Revenue vs Returns neither slices nor reconciles.Conformance is key + spelling + owner alignment. Enforce it at the model layer, and cross-process reconciliation becomes routine.
In production
- A commerce model conforms dim_customer and dim_product across orders, returns and support.
- Finance and ops share dim_entity, so P&L and operational dashboards reconcile.
- dim_date is a single conformed dim; YTD logic works identically in every fact.
Best practices
- Design conformed dims from master data; one owner per attribute.
- Use stable surrogate keys, not natural keys that drift.
- Test conformance: join two facts through the shared dim and demand reconciliation.
- Govern all 'copies' as downstream snapshots, never alternate sources of truth.
Common mistakes
- Each process building its own customer table with its own spellings.
- Natural keys ('cust_123') shared across systems with drifting meaning.
- Attribute values owned by no one, so 'EU' vs 'Europe' multiply.
- Skipping reconciliation tests until a board meeting surfaces the split.
Debugging tips
- Two facts won't join by dim → compare spelling/casing of the join attribute.
- Reconciliation fails by a known chunk → isolate the non-conformed rows.
- Users game by filtering 'their version' → kill duplicate dims; route to the conformed one.
Interview checkpoint
Quick quiz
The shared equal surname in conformed dims is enforced by:
Two facts with differently-spelled region attributes still reconcile automatically.