Visual Atlas — Maps 01–06
Map 1 — DW/BI Operating Spine
Recall: Business Goals → Architecture → Integrate + Store → BI Delivery → Operate + Govern → Measure → feedback to goals/architecture.
Interpretation: Technology follows business purpose; go-live is not the end. Measurement feeds continuous improvement.
Rebuild: Draw six steps plus a feedback arrow. Under “Measure,” write usage / coverage / performance / satisfaction.
Answer check: If your map starts with “buy BI tool” or stops at production, rebuild it.
Source: pp. 361–365, 374–393.
Map 2 — Inmon / Corporate Information Factory
Recall: Applications → Staging → Integration → Enterprise DW → Data Marts → Analysis. Add ODS beside integration/DW path.
Interpretation: the normalized enterprise DW is the principal analytical integration point. ODS handles current/near-current operational needs.
Rebuild: label DW “historical / time-variant / non-volatile”; label ODS “current / lower latency / more volatile.”
Answer check: Do not put independent dimensional marts before the central enterprise integration layer as the defining Inmon feature.
Source: pp. 365–368.
Map 3 — Kimball Dimensional Warehouse
Recall: Sources → Staging Services → Dimensional Fact Areas/Marts → Access Tools, with conformed dimensions crossing fact areas and DW bus coordinating them.
Interpretation: facts measure processes, dimensions describe context, conformed dimensions integrate increments.
Rebuild: Draw Sales and Inventory fact areas sharing Product and Date.
Answer check: “Many marts” is not enough. Shared semantics are the integration mechanism.
Source: pp. 368–370.
Map 4 — Storage Role Separation
Recall: Staging | Atomic DW | ODS | Data Mart | Cube | BI Tool.
Write one verb/purpose: - Staging = prepare - DW = remember/integrate - ODS = operate/current - Mart = present for subject/user - Cube = analyze multidimensionally - BI tool = consume/explore
Answer check: ODS is not a small warehouse; staging is not the user destination; cube is not the enterprise integration layer.
Source: pp. 365–371, 381–384.
Map 5 — History Ladder
Recall: Current State → Point-in-Time State → Atomic History → Summaries → Predictive/Advanced Use.
Interpretation: preserved useful grain enables future summaries, trend reconstruction and advanced analysis. Summaries should not destroy the foundation needed for later questions.
Rebuild: circle Atomic History and draw several different summaries branching from it.
Answer check: A correct map does not make summary a replacement for required detail.
Source: pp. 365–372.
Map 6 — Batch CDC Choice
Question in center: “How can the source prove what changed?”
Branches: 1. Timestamp — simple; deletes not inherent. 2. Change/log table — explicit inserts/updates/deletes. 3. Transaction log — detailed/delete-aware; complex. 4. Message delta — event changes; low latency/reliability controls. 5. Full comparison — no better change indicator; potentially expensive.
Interpretation: no universal best CDC. Source capability + delete need + latency + source impact + complexity decide.
Rebuild: add one advantage and one limitation to each branch.
Source: pp. 371–374.