A conformed dimension is a dimension table that is defined once, maintained in a single authoritative version, and shared across multiple fact tables, data marts, and analytical models — ensuring that the same dimension member means the same thing in every context where it is used. In a finance data warehouse with GL actuals, AP invoices, AR transactions, and payroll costs as separate fact tables, the Account dimension is a conformed dimension if a single Account table — with a single AccountKey, AccountCode, AccountName, and AccountCategory — is shared as the lookup dimension for all four fact tables. When a user slices any report by Account, they see the same account names, the same hierarchy, and the same category classifications regardless of which underlying fact table’s data they are viewing. Without conformed dimensions, each fact table’s related account information may be defined differently — different codes for the same account in different source systems, different category classifications reflecting different teams’ preferences — making cross-fact-table analysis impossible without complex reconciliation logic.
Conformed Dimension Architecture
| Dimension | Fact Tables It Serves | Governance Requirement |
|---|---|---|
| Date | GL Actuals, AP Invoices, AR Transactions, Payroll, Budget | Single Date table; fiscal calendar definition owned by Finance |
| Account (Chart of Accounts) | GL Actuals, Budget, Forecast, FCCS Consolidation | Account codes and categories owned by Group Finance Controller |
| Entity (Legal Entity / Cost Centre) | GL Actuals, Headcount, Budget, AR, AP | Entity hierarchy and codes owned by Group Finance / Company Secretary |
| Vendor / Supplier | AP Invoices, Procurement Spend, Payment Transactions | Vendor master owned by Procurement; unique VendorKey from MDM |
| Customer | AR Transactions, Revenue, Customer Profitability | Customer master owned by Commercial; ZATCA VAT registration linked |
Conformed Dimensions Across the LWS Service Stack
Conformed dimensions are relevant not only within the BI data warehouse but across the full finance technology stack that LWS implements. An Account dimension that is conformed across Oracle EPM Cloud (where budget and forecast data is maintained), Oracle FCCS (where consolidation uses the same account hierarchy), and the Power BI data warehouse (where actuals, budget, and forecast are compared) enables a three-system analytical environment where a CFO’s budget-to-actual report in Power BI draws from EPM budget data and ERP actuals data that both use the same account dimension — requiring no cross-system mapping to reconcile. The conformed Account dimension is the technical enabler of a “single source of truth” across the finance technology stack.
What Goes Wrong in Practice
The most common conformed dimension failure in GCC enterprise data warehouses is a dimension that was conformed at build time but drifted over time — because different teams adding new dimension members to different source systems used different codes, different naming conventions, or different hierarchy placements. An Account dimension that starts conformed between Oracle EBS and Oracle FCCS will drift if new accounts are added in EBS without the corresponding addition in FCCS, or if FCCS’s hierarchy is reorganised without the corresponding update in the data warehouse’s Account dimension. Conformed dimension governance — defining who owns each dimension, who can add members, and what the update process is across all consuming systems — is the operational discipline that keeps a conformed dimension conformed over time.
How Loop Wise Solutions Maintains Conformed Dimensions
We design conformed dimension governance as a deliverable in every finance data warehouse engagement — specifying the dimension owner, the source of record for each dimension, the process for adding or modifying members across all consuming systems simultaneously, and the reconciliation check that confirms conformance between the warehouse dimension and each source system’s equivalent structure.
Answers before you ask.
A dimension table shared consistently across multiple fact tables and data marts, so the same entity, account, or time period means the same thing wherever it appears in the warehouse. One governed Date or Entity dimension serves every fact, ensuring reports built from different facts agree on those shared dimensions.
Because without them, different fact tables and marts define the same dimension their own way, so the same metric can differ between reports. Conformed dimensions give one shared, agreed definition used everywhere, so cross-process analysis is comparable. They are what let separate business-process star schemas integrate into a coherent enterprise view.
By sharing the same dimension across facts, they let a report combine measures from different business processes along a common dimension — comparing, say, budget and actual facts by the same entity and period. This drill-across is only valid when the dimension is conformed; otherwise the measures cannot be reliably aligned. Conformance is the prerequisite for integrated analysis.
Conformed dimensions are the core of Kimball's bus architecture — the shared dimensions that tie individual star schemas into an integrated warehouse. The bus matrix maps which conformed dimensions each business process uses. Building marts against conformed dimensions is how Kimball achieves enterprise consistency incrementally rather than through one monolithic model.