Chapter 21 · Data Marts, Domain Data Products, Self-Service Analytics, and Ownership
Wide Reporting Tables vs Reusable Dimensional Marts: Speed, Duplication, and Semantic Drift
Compare purpose-built wide reporting tables with reusable dimensional marts, including duplication, query ergonomics, refresh cost, semantic drift, and when a wide surface is safe to certify.
Learning outcomes
Compare wide reporting tables with reusable dimensional marts using semantic, maintenance, and consumer criteria.
Identify duplication that is merely physical from duplication that creates a second business definition.
Use governed metrics/dimensions to make a wide table a safe delivery surface rather than an ungoverned API.
Explain change amplification when descriptive attributes and business logic are copied into many wide tables.
Choose a shape from evidence instead of treating “wide” or “star” as universally correct.
Chapter 21 begins from Chapter 20's governed warehouse/semantic
truth:
10 current paid lines, 8 orders, 12 units, 820 USD gross
revenue, 495 USD cost, and 325 USD gross profit. The canonical fact grain remains
one current paid order line. The active
semantic contracts remain gross_revenue_usd.v1,
active_customers.v1, and
period_retention.v1. This chapter does not redefine
those facts or metrics. It adds domain delivery surfaces—marts,
data products, sandboxes, and certified outputs—whose shared
concepts must inherit the governed contracts.
Runtime: Python standard library plus SQLite;
generation evidence uses the local runtime reported by the
script. Environment: local/in-process,
synthetic, and no-cost. Storage: one SQLite
file plus JSON evidence; views stand in for dependent marts.
Source: the Chapter 20 AtlasMart fact/dimension
fixture. Time: warehouse
order_date semantics remain UTC and are not
silently converted. Currency: governed gross
revenue is USD-only. Security: access-class
labels are metadata in this lab, not database-enforced
authorization; production enforcement belongs in the
warehouse/semantic/security stack.
History: existing SCD/history semantics are
unchanged. Portability: the mart concepts are
vendor-neutral; view syntax, catalog metadata, masking, policy
enforcement, and materialization are engine-specific.
1. The appeal of one wide table
A wide reporting table denormalizes facts plus descriptive attributes into a consumer-friendly relation. AtlasMart marketing can avoid repeated joins by exposing customer name/segment/geography and product name/category next to each sales line. That can be a valid physical delivery choice. The danger appears when the wide table becomes an unversioned permanent API whose copied attributes and derived metrics drift from the governed sources.
2. Same semantics, different physical shapes
CREATE VIEW mart_marketing_wide ASSELECT f.order_date,f.order_id,f.line_no, f.customer_id,c.customer_name,c.segment,c.geography_code, f.product_id,p.product_name,p.category, f.channel,f.quantity, f.amount_cents/100.0 AS governed_revenue_usdFROM fact_sales fJOIN dim_customer c USING(customer_id)JOIN dim_product p USING(product_id)WHERE f.status='paid' AND f.currency_code='USD';rows = 10SUM(governed_revenue_usd) = 820.00 USDatomic fact control = 820.00 USDresult = PASS3. Reusable dimensional mart versus wide surface
| Decision | Reusable dimensional mart | Wide delivery surface |
|---|---|---|
| Consumer joins | More visible | Often fewer |
| Attribute reuse | Central/shared | Copied into rows |
| Change amplification | Lower | Higher if materialized/copied |
| Semantic risk | Low when conformed | Low only if generated from governed dependencies |
| Storage | Less duplication | Potentially more |
| Use case | Reusable exploration | Stable bounded report/data extract |
4. Controlled failure: copied business logic inside the wide table
If the wide table embeds
CASE WHEN channel='sales' THEN 0 ELSE amount but
still names the column revenue, it has recreated
the 665 USD drift. Likewise, copying customer segment values
into a persistent table without an SCD/as-of policy can freeze
current-state attributes onto historical facts. Denormalization
does not eliminate semantic contracts; it makes refresh/version
behavior more important.
SELECT ..., CASE WHEN channel='sales' THEN 0 ELSE amount_cents/100.0 END AS revenueFROM copied_sales_with_customer_text; -- hidden semantic fork5. Detect duplicate definitions, not merely duplicate columns
A duplicate-definition scan searches transformation
code/metadata for local definitions of governed metrics,
customer classifications, currency conversions, date windows,
and status filters. Repeating a physical column such as
customer_name is not automatically wrong; repeating
the business rule that defines revenue under a generic
name is the dangerous duplication.
independent definition found: sandbox_marketing_revenue.revenue hidden predicate: channel <> 'sales' shared name collision: revenuestatus: DRIFT_DETECTED_AND_REPAIREDgoverned reuse found: gross_revenue_usd.v1 -> finance + marketing certified marts6. Performance/cost claims need measurements
This fixture is too small to justify latency claims. A wide table may reduce joins but increase bytes scanned, refresh work, and storage. A star may enable pruning or cache reuse differently by engine. Benchmark with representative row counts, projections, filters, concurrency, cache state, and update patterns. Never present a query-plan shortcut as a semantic reason to duplicate business logic.
7. Certification rule for wide tables
A wide table is certifiable when its grain, dependencies, metric versions, history policy, access policy, freshness, and tests are explicit. It should be regenerated from governed sources, not hand-maintained as a second system of record. If consumers need a breaking schema change, publish a new version or compatibility view and migrate them deliberately.
8. Production judgment
Use a wide surface for bounded consumer ergonomics, not as an excuse to fork semantics. Correctness: reconcile additive measures to atomic facts. History: define current vs as-was attributes. Replay: deterministic build from versioned dependencies. Security: denormalization can copy sensitive attributes into more places. Observability: track freshness and consumer usage. Cost: account for refresh/storage as well as query speed. Rollback: maintain previous certified view/table version.
9. Bridge to Lesson 4
Wide tables solve shape, not governance. Lesson 4 formalizes the lifecycle from experimental sandbox to certified data so teams can explore freely without consumers mistaking experiments for trusted APIs.
Knowledge check
Check your understanding
- Is denormalization itself semantic drift?
- What makes a wide table safe?
- Why can copied current customer attributes be historically wrong?
Review the answers
1. No; drift comes from changed/hidden meaning, not width alone.
2. Governed dependencies, explicit grain/history/freshness/security, reconciliation, versioning, and ownership.
3. Current attributes can overwrite the context that applied when the historical fact occurred.
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.
10. 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.