Scenario Lab 01–06
1 — Enterprise integration debate
Stem: Finance wants a normalized corporate warehouse that downstream marts source from.
- Primary problem: warehouse architecture/modeling approach.
- Leading KA: Data Warehousing & BI.
- Supporting: Data Architecture, Modeling, Integration, Governance.
- Roles: Enterprise/Data Architect, DW designers, Data Modelers, sponsor.
- Best action: use an Inmon/CIF-style enterprise normalized warehouse as central integration layer, then source marts from it.
- Weaker response: call it Kimball merely because marts exist; Inmon can contain marts.
- Changed fact: dimensional marts integrated through conformed Product/Date → Kimball becomes stronger.
- Source: pp. 365–370.
2 — Shared dimensions
Stem: Sales, Inventory and Orders need the same Date and Product context across separate marts.
- Primary: cross-process dimensional consistency.
- Leading: DW/BI.
- Supporting: Modeling, Reference/Master Data, Metadata, Governance.
- Roles: Data Modeler, Steward, DW Architect, BI developers.
- Best: define conformed Date/Product dimensions and coordinate increments with DW bus matrix.
- Weaker: independent Product/Date definitions per mart; destroys comparison.
- Changed: a dimension used only by one mart may remain local.
- Source: pp. 368–370.
3 — Operational low latency
Stem: Customer service needs integrated data every few minutes and only recent history.
- Primary: current integrated operational analytics.
- Leading: DW/BI.
- Supporting: Integration, Storage/Operations, Architecture.
- Roles: DW Architect, integration team, operational consumers.
- Best: ODS/equivalent current integrated store aligned to latency need.
- Weaker: force historical DW as sole store despite current/minimal-history clue.
- Changed: multi-year stable history/trends → DW.
- Source: pp. 366–368.
4 — No user queries here
Stem: extracted source data is cleansed and standardized before loading.
- Primary: intermediate preparation.
- Supporting: Integration, DQ, Metadata.
- Roles: integration engineers, DQ specialists, DW operations.
- Best: staging/refinement area.
- Weaker: data mart; mart is analytical consumption, staging is preparation.
- Changed: department users analyze historical prepared data → mart.
- Source: pp. 366–371.
5 — Reproduce last quarter exactly
Stem: executives require the same historical result no matter when the query runs.
- Primary: point-in-time historical preservation.
- Supporting: Modeling, Storage, Metadata, Governance.
- Roles: DW designer, Modeler, compliance/business users.
- Best: time-variant/non-volatile history at sufficient grain to reproduce states.
- Weaker: store only current value; destroys evidence.
- Changed: only current state matters → historical requirement can shrink and current operational store may fit.
- Source: pp. 365–371.
6 — Daily source changes with timestamps
Stem: rows have reliable updated_at, but physical deletes disappear.
- Primary: recurring change detection.
- Supporting: Integration, source operations, load controls.
- Roles: integration engineer, source DBA/owner, DW operations.
- Best: timestamp delta when appropriate, plus explicit delete strategy if deletes matter.
- Weaker: assume timestamps inherently show deletes.
- Changed: transaction log accessible + delete capture required → transaction-log CDC stronger.
- Source: pp. 371–374.