Dependent vs Independent Marts and Why Independent Silos Break Conformance

Learning outcomes

1. The realistic problem: three teams need answers now

Finance wants daily revenue/profit, marketing wants customer and campaign slices, and operations wants orders and units. A data mart is a curated analytical dataset optimized for a bounded audience or subject. A dependent mart derives its shared business meaning from governed warehouse assets. An independent mart derives directly from source systems or team-local copies and owns its own definitions. The physical database can be identical in both cases; the dependency and semantic contract are what differ.

The business decision is whether AtlasMart can let domains deliver quickly without making “customer” and “revenue” mean different things. The source event is still one paid order line. The declared warehouse grain has not changed. The consumer changes—from enterprise semantic queries to domain-specific delivery surfaces—and that is exactly where drift can be introduced.

2. A mart boundary is not a permission to redefine enterprise meaning

Domain autonomy and conformance are not opposites. A marketing team may own campaign attribution logic while still consuming the enterprise customer identity and governed revenue metric.

3. Controlled failure: the independent marketing mart

A practitioner copies paid order lines and decides the sales channel is “not marketing,” so it adds channel <> 'sales'. The result is then named simply revenue. Nothing crashes. The dataset is syntactically valid and the output looks reasonable.

CREATE TABLE sandbox_marketing_revenue ASSELECT order_date, SUM(amount_cents)/100.0 AS revenueFROM fact_salesWHERE status='paid' AND currency_code='USD'  AND channel <> 'sales'GROUP BY order_date;

governed gross_revenue_usd.v1:        820.00 USDindependent marketing "revenue":        665.00 USDdelta:                                 -155.00 USDreason: hidden predicate channel <> 'sales'certification decision before repair:   BLOCKcertification decision after repair:    CERTIFY

The missing 155 USD is not a database bug: it is the two paid sales-channel lines (75 + 80). If the team wanted a marketing-attributed metric, it needed a different, explicitly named metric with an attribution contract. Reusing the generic word “revenue” hides a business-rule fork.

4. Repair: inherit shared meaning, extend only the domain-specific surface

CREATE VIEW marketing_revenue_v1 ASSELECT f.order_date,c.segment,c.geography_code,       SUM(f.amount_cents)/100.0 AS governed_revenue_usdFROM fact_sales AS fJOIN dim_customer AS c USING(customer_id)WHERE f.status='paid' AND f.currency_code='USD'GROUP BY f.order_date,c.segment,c.geography_code;

The mart now inherits customer conformance and the Chapter 20 revenue filter/currency semantics. Marketing remains free to add campaign, audience, or channel-specific measures, but those should use distinct names and owners when their semantics differ from the enterprise metric.

5. Make the dependency structure observable

mart_finance_daily  <- fact_sales  <- gross_revenue_usd.v1mart_operations_daily  <- fact_salesmart_marketing_customer_daily  <- fact_sales  <- dim_customer  <- gross_revenue_usd.v1mart_marketing_wide  <- fact_sales  <- dim_customer  <- dim_product  <- gross_revenue_usd.v1marketing_revenue_v1 (after repair)  <- fact_sales  <- dim_customer  <- gross_revenue_usd.v1

This graph is lineage, not just documentation. It answers impact questions: if gross_revenue_usd.v1 is deprecated, which marts must migrate? If dim_customer changes geography semantics, which certified products require regression tests?

6. Edge case: central governance can become a bottleneck too

A different failure is to require the central platform team to approve every domain-only attribute before a marketer can experiment. That protects conformance by stopping delivery. The safer boundary is: shared enterprise concepts are governed centrally/federatively; domain-only concepts are domain-owned but must be documented, versioned, and not masquerade as shared definitions. A sandbox can move fast; certification is the point where enterprise reuse requirements become mandatory.

7. Production judgment

Choose a dependent mart when consumers need domain ergonomics but enterprise metrics/dimensions must remain comparable. An independent analytical dataset may be justified for isolated research, acquisition data, or external datasets that have no enterprise identity yet, but do not certify it as an enterprise mart until shared semantics are reconciled. Correctness: row counts alone do not prove conformance. Freshness: mart SLAs cannot exceed upstream truth without disclosing staleness. Retry/replay: rebuilds should be deterministic from versioned dependencies. Security: copying data may create new bypass paths. Performance/cost: duplication may reduce query latency while increasing storage/refresh cost. Rollback: retain the previous certified contract and route consumers back to the governed semantic layer if promotion fails.

8. Bridge to Lesson 2

Lesson 1 established the non-negotiable rule: shared meaning is inherited. Lesson 2 turns that into a practical domain-data-product contract with owners, dependencies, SLAs, access boundaries, and independently evolvable domain extensions.

Knowledge check

Authoritative references

• Kimball Group — Enterprise Data Warehouse Bus ArchitectureIncremental domain delivery integrated through reusable conformed dimensions.
• Kimball Group — Conformed DimensionsShared descriptive domains are defined once and reused to preserve analytical consistency.
• Kimball Group — Enterprise Data Warehouse Bus MatrixBusiness-process rows and dimension columns provide a planning and conformance map.
• Kimball Group — Differences of OpinionExplains why conformed facts/dimensions matter across distributed presentation marts.

9. Lab cleanup/reset

Delete atlasmart_ch21_lab (or your configured local output directory) and rerun python ch21_lab.py to recreate a clean deterministic state. No cloud resource or repository file is modified by the lab.