A retailer wants sales, returns and support metrics across several acquired businesses. Customer identifiers disagree, source systems change independently, and finance needs reproducible historical totals. The design must decide where identities are reconciled and how consumers receive stable definitions.
Compare integration and presentation responsibilities
| Approach | Integration emphasis | Consumer representation | Main operating cost |
|---|---|---|---|
| Kimball bus architecture | Conformed dimensions and facts across business processes | Dimensional marts with shared definitions | Coordinating grain and dimensions as new processes arrive |
| Inmon-style enterprise warehouse | Integrated, normalized enterprise history | Downstream dimensional or other marts | Building the common integration model and delivering its consumers |
| Data Vault | Business keys, relationships and descriptive history with provenance | Business rules and presentation marts downstream | Many tables, temporal joins and automation/metadata discipline |
| Direct wide marts | Repeated queries over a defined business output | Denormalized reporting tables | Duplicated transformations and cross-mart definition drift |
A Kimball approach can deliver one business process at a time while planning shared dimensions through a bus matrix. It requires enterprise coordination; isolated departmental stars with incompatible customer definitions lose that integration.
An Inmon-style integration store can preserve a common enterprise representation before presentation models are built. That common layer adds work, so prioritize its contracts and consumer delivery together. A normalized integration model and dimensional reporting marts can coexist.
Kimball
Integrate business processes through shared dimensions.
Sales, returns and customer records
Conformed customer, product and date definitions
Fact rows
Fact rows
- Source systems to Dimensional bus.
- Dimensional bus to Sales.
- Dimensional bus to Returns.
Inmon
Integrate enterprise history before publishing marts.
Finance, operations and customer records
Integrated, normalized entities and history
Mart
Mart
- Source systems to Enterprise model.
- Enterprise model to Finance.
- Enterprise model to Operations.
Both approaches reconcile identities and definitions. Kimball coordinates dimensional marts through a bus of conformed dimensions; an Inmon-style design first builds an integrated enterprise model, then publishes marts.
Reference: Kimball Group.
Kimball bus architecture
A bus matrix maps business processes to shared dimensions. Sales and returns can be delivered separately while using the same customer, product and date definitions. Conformance includes keys, attribute meaning and historical rules; a shared column name alone is insufficient.
Joining line-level sales directly to multiple returns can multiply the sale amount. Shared dimensions enable cross-process analysis, while the query still has to preserve each fact’s grain. The dimensional modelling reference explains star, snowflake and bridge mechanics.
Inmon-style enterprise integration
An integrated enterprise warehouse reconciles source entities and history in a shared enterprise model, typically normalized. Consumer marts then reshape that representation. The normalization rules belong to functional dependencies and normal forms.
The common integration model can reduce repeated reconciliation in marts. It also creates coordination and delivery work. A mart-specific interpretation still needs an owner and explicit lineage back to the enterprise definition.
Data Vault structures
A hub captures a business-key identity. A link captures a relationship between identities. A satellite holds descriptive context and its history/provenance. Operational implementations need explicit record grain, load timestamps and source identity. In the simplified schema below, the suffixes BK and HK mean business key and hash key.
Swipe or scroll sideways to read the full diagram.
Customer and order hubs retain identities, the link captures their association, and satellites retain descriptive versions. Keys and timestamps shown are simplified; the full uniqueness rules depend on satellite grain.
Consumers can receive a star built from this integration model. Hash keys need canonical input and collision handling; identity matching still decides whether different source identifiers name the same customer.
A load timestamp answers when the platform recorded a change. Historical business interpretation may need separate effective times and rules.
Storage and organizational patterns are separate choices
Storage and execution are chosen independently of integration style. See lake and warehouse design for that platform decision; a dimensional model can be served from either a warehouse or lakehouse.
Data mesh assigns domain ownership and treats datasets as products supported by shared platform and governance capabilities. Domain-owned datasets still need product contracts, discoverability and cross-domain identity. A centralized team can use the same table formats and dimensional methods.
A practical hybrid can retain source objects, integrate customer/order history, then publish conformed facts to a warehouse and keyed operational projections to an application store. Each copy needs an owner, freshness promise and correction path.
Swipe or scroll sideways to read the full diagram.
Raw records support replay; an integration representation resolves identity and history; downstream facts support reporting and training, while an operational projection serves application lookups. Governance tracks contracts and releases.
Choosing an integration model
A small team with one stable source may do well with raw retention plus tested dimensional marts. Many changing sources and audit demands may justify a more explicit integration store. Repeated definition conflicts across marts call for conformed entities and metric ownership before another processing framework.
Measure onboarding time, reconciliation effort, change propagation, query latency, freshness and maintenance cost. Schema style alone supplies no storage or throughput limit. Capacity estimates turn those requirements into a workload, while Lambda, Kappa and medallion describe independent processing and quality choices.