Conformed Dimensions
Conformed dimensions are dimensions that mean the same thing—and carry the same keys, attributes, and values—across multiple fact tables or data marts, letting you combine and compare metrics from different business processes with confidence.
In a dimensional architecture, different business processes get their own fact tables: orders, shipments, returns, web sessions. Each needs dimensions for context. A dimension is conformed when it is shared across those fact tables in a consistent way—either literally the same physical table or replicated copies that are guaranteed identical in structure and content. Kimball formalized this as the foundation of an enterprise data warehouse "bus": a matrix of business processes (rows) against conformed dimensions (columns) that shows which dimensions each process shares.
Two dimensions conform if they are identical, or if one is a strict, rolled-up subset of the other (a "shrunken" conformed dimension). For example, a Month dimension can conform to a Date dimension as long as the month attributes are exactly the same values used in the daily dimension. What matters is agreement on keys, attribute names, and the domain of values.
Conformance is the mechanism behind consistent "drill-across" reporting—querying multiple fact tables by the same dimension and merging the results—which is the difference between an integrated warehouse and a set of disconnected silos.
Key Characteristics
- ▶Mean the same thing across every fact table or data mart that uses them
- ▶Share identical keys, attribute names, and value domains
- ▶Either one physical table or replicated copies guaranteed identical
- ▶Form the columns of the Kimball enterprise data warehouse "bus matrix"
- ▶Can be "shrunken"—a strict rolled-up subset (e.g., Month conforming to Date)
- ▶Require explicit ownership and stewardship to stay conformed over time
Why It Matters
- ▶Make cross-process analysis possible—revenue per customer and tickets per customer only align if "customer" is the same everywhere
- ▶Enable consistent drill-across reporting that merges metrics from multiple business processes
- ▶Prevent the silent disagreement that comes from each team building its own near-duplicate of a core dimension
- ▶Conforming structure without governance still breaks totals when teams classify shared entities differently
- ▶Reorganizations and source-system changes erode conformance unless ownership is explicit
Example
A company analyzes orders and customer-support contacts. If both fact tables join to one conformed Customer dimension—same surrogate keys, same region attribute, same segment classification—then an analyst can produce a single report showing revenue and ticket volume side by side per region or per segment. Without conformance, the region values might differ ("US-West" vs. "Western US"), the segments might be defined differently, and the two metrics simply won't align.Coginiti Perspective
Conformed dimensions are fundamentally a governance problem, and Coginiti's analytics catalog and semantic layer are built to solve it through reuse rather than replication. A conformed dimension can be defined once as a CoginitiScript package—directory-based, with Go-like public/private visibility so the conformed definition is exported and imported (#+import) across teams rather than copied and forked. In SMDL, a single shared entity for Customer or Date is referenced by relationships from many fact entities, so every Semantic SQL query that touches "customer" resolves to the same governed definition, attributes, and values. This central-definition approach is exactly the cross-platform, semantic-governance pattern Coginiti favors: because the product follows ELT and connects to 24+ platforms, the same conformed dimension can sit over data that physically lives in different systems, while consumers see one consistent set of keys and attributes. #+test blocks can assert conformance invariants—matching value domains, exact subset relationships for shrunken dimensions—so drift is caught automatically rather than discovered in a mismatched report.
More in OLTP, OLAP & Workload Types
Analytical Workload
An analytical workload is a class of database queries that examine, aggregate, and analyze large volumes of historical data to extract business insights and support decision-making.
Dimension Table
A dimension table is a database table in a star or snowflake schema that stores descriptive attributes used to filter, group, and drill-down in analytical queries.
Fact Table
A fact table is a database table in a star or snowflake schema that stores measures (quantitative data) and foreign keys to dimensions, representing events or transactions in a business process.
Fan and Chasm Traps
Fan traps and chasm traps are two classic join hazards in dimensional and relational models where the structure of the joins causes measures to be over-counted or under-counted, producing numbers that look valid but are wrong.
Grain
Grain is the level of detail represented by a single row in a table—the precise answer to the question "what does one record mean?"—and it is the foundational decision in dimensional modeling because every dimension and measure in a table must be consistent with it.
HTAP (Hybrid Transactional/Analytical Processing)
HTAP is a database architecture that supports both transactional workloads and analytical workloads on the same data system, enabling real-time analytics without separate data warehouses.
See Semantic Intelligence in Action
Coginiti operationalizes business meaning across your entire data estate.