Deep Battle Cards A–F
A — Inmon / CIF vs Kimball
Definition: Inmon/CIF centers analytical integration in an enterprise warehouse, traditionally normalized, with downstream marts. Kimball centers dimensional business-process fact areas/marts integrated through conformed dimensions/facts and the DW bus.
Purpose: both create integrated trustworthy analytical data; they organize integration differently.
Inputs: business processes, subject model, sources, history/grain, consumer needs.
Outputs: Inmon → enterprise DW/CIF + marts; Kimball → fact/dimension structures + conformed dimensions + bus matrix.
When to choose: central normalized enterprise layer → Inmon. Star schemas/business-process facts/shared dimensions → Kimball.
Common confusion: Kimball is not isolated departmental marts; Inmon can still have marts.
Deciding distinction: where/how enterprise analytical integration is organized.
Contrasts: normalized enterprise Customer/Order DW feeding marts → Inmon. Sales and Inventory share Product/Date → Kimball.
Trap: never select one as universally superior.
Hook: Inmon integrates centrally; Kimball integrates dimensionally.
Source: pp. 365–370.
B — Staging vs ODS vs DW vs Data Mart
Staging: transient/intermediate preparation.
ODS: integrated current/near-current, lower latency, more volatile.
DW: durable integrated historical analytical store.
Mart: targeted subject/process/user analytical presentation.
Deciding dimensions: persistence, time horizon, volatility, latency, consumer purpose.
Contrast: temporary cleansing → staging; last 30 days refreshed every few minutes → ODS; five-year reproducible history → DW; Finance profitability subset → mart.
Trap: physical co-location does not make architectural roles interchangeable.
Hook: Stage prepares; ODS operates; DW remembers; Mart presents.
Source: pp. 365–371.
C — Fact vs Dimension vs Conformed Dimension
Fact: process measurement.
Dimension: descriptive context.
Conformed Dimension: dimension governed consistently for reuse across fact areas/marts.
Deciding clue: what is measured vs what describes it vs what connects analytical areas semantically.
Contrast: Revenue/Quantity = facts; Product/Date = dimensions; same governed Product used by Sales and Inventory = conformed.
Trap: numeric datatype does not automatically mean fact.
Hook: Facts measure; dimensions describe; conformed dimensions connect.
Source: pp. 368–370.
D — Five Batch CDC Methods
Timestamp: rows changed since high-water mark; simple; deletes not inherent.
Log table: explicit source change records; can represent I/U/D.
Transaction log: DBMS transaction evidence; detailed/delete-aware; more complex/platform-dependent.
Message delta: published change events; low latency; event reliability/replay needed.
Full comparison: compare complete states; fallback with no better evidence; expensive at scale.
Owners: integration engineers, source DB/application owners, DW operations.
Output: controlled insert/update/delete deltas.
Deciding distinction: where trustworthy evidence of change exists, then assess delete, latency, source impact and complexity.
Trap: most sophisticated is not automatically best.
Hook: Time, Table, Transaction Log, Message, Full Compare.
Source: pp. 371–374.
E — Trickle Feed vs Messaging vs Streaming
Trickle: small frequent batches accumulate at source.
Messaging: source publishes events to bus/middleware which distributes to subscribers.
Streaming: continuous flow accumulates in target-side queue/buffer.
Purpose: lower analytical latency below classic batch windows.
Deciding distinction: accumulation point—source vs bus vs target.
Contrast: send every 500 changed rows → trickle; enterprise event bus → messaging; continuous direct target queue → streaming.
Trap: do not choose streaming merely because the stem says “fast.”
Hook: Trickle = source; Messaging = bus; Streaming = target.
Source: pp. 372–374.
F — Mapping vs Remediation vs Transformation
Mapping: documents source-target equivalence and connecting rules.
Remediation: corrects defects/root causes.
Transformation: intentionally converts/derives/restructures data to target/business meaning even when source is valid.
Inputs: source/target schemas, business rules, profiling, DQ requirements.
Outputs: mapping specs, remediation rules/actions, transformation logic.
Deciding question: explain where it goes? fix what is wrong? deliberately change what is valid?
Contrast: source.country_code → dim_country.country_key = mapping; U$ → US because malformed = remediation; valid US → 840 under enterprise target standard = transformation.
Trap: warehouse transformation should not permanently hide a correctable source defect.
Hook: Map = where; remediate = fix; transform = convert/derive.
Source: pp. 375–379.