06-reference

book adwd master synthesis 2026 04 13

2026-04-13·reference·source: Agile Data Warehouse Design (book)·by Lawrence Corr, Jim Stagnitto

Agile Data Warehouse Design — Master Synthesis

Why this book is in the vault

The founder's favorite data modeling textbook. Corr & Stagnitto's BEAM✷ methodology is the agile counterpart to Kimball's dimensional modeling patterns — where Kimball provides the design patterns, Corr provides the collaborative discovery process for getting stakeholders to define what goes into those patterns. This is the methodological foundation for RDCO's consulting engagements in analytics engineering.

The Book in One Paragraph

BEAM✷ (Business Event Analysis & Modeling) treats dimensional modeling as a collaborative storytelling exercise. Stakeholders narrate data stories using the 7Ws (who, what, when, where, how many, why, how), which are captured in BEAM✷ tables — spreadsheet-friendly artifacts that look like reports but define star schemas. The agile twist: model just enough for the next sprint, profile source data as a form of TDD before building anything, and use an event matrix to plan iterative delivery of conformed dimensions across business processes.

Chapter Map

Ch Title Core Concept RDCO Application
1 How to Model a Data Warehouse OLTP vs DW/BI, case for dimensional modeling, BEAM✷ intro Consulting methodology — why dimensional over ER for analytics
2 Modeling Business Events Data stories, 7Ws framework, event granularity Client intake interviews — "who does what?" as the opening question
3 Modeling Business Dimensions Dimension stories, hierarchies, SCD history Facilitation workshops — change stories for SCD type decisions
4 Modeling Business Processes Conformed dimensions, event matrix, bus architecture Engagement scoping — event matrix as the planning artifact
5 Modeling Star Schemas Data profiling as TDD, severity ranking, surrogate keys Data quality framework — Column × Absolute profiling, Stop/Pause/Go tiers
6 Who & What: Design Patterns Customer dims, hierarchy maps, mini-dims, products Pattern library for client implementations
7 When & Where: Design Patterns Time/calendar dims, location, international time Temporal testing, FACT STATE freshness checks
8 How Many: Fact Tables & Measures Fact types, additivity, aggregation, drill-across ARR waterfall validation, semi-additive trap detection
9 Why & How: Design Patterns Causal dims, bridge tables, weighting, audit dims Attribution modeling, ETL lineage

Five Things to Steal for RDCO

1. The 7Ws as a client interview framework

Every analytics engagement starts with "who does what, when, where, how many, why, and how?" This is both a requirements gathering technique and a dimensional modeling scaffold. It maps directly to our /audit-model skill's interview phase.

2. Data profiling as TDD

Corr's central methodological claim: profile source data BEFORE designing target schemas. This is the test-first approach the founder identified as missing from the MG harness. Our framework goes further (3×6 matrix vs Corr's Column × Absolute), but his framing of profiling-as-testing validates the approach.

3. The event matrix as a planning tool

A single artifact that shows which dimensions participate in which business events. This is the data warehouse equivalent of our Notion task board — it tells you what to build next, what's conformed, and where the dependencies are. Useful for scoping multi-sprint engagements.

4. Severity tiers for data source issues

Table 5-2's 12-level ranking (Stop/Pause/Go) is now integrated into our testing matrix as the severity assignment system. Missing conformed dimensions = Stop. Missing mandatory values = Pause. Mismatched attributes = Go.

5. BEAM✷ tables as collaborative deliverables

Spreadsheet-format artifacts that stakeholders can read and validate without understanding ER diagrams or star schemas. This is the "Google Sheets as a modeling tool" approach — approachable, collaborative, and it makes stakeholders feel ownership of the design.

What the Book Doesn't Cover (and We Do)

Gap Our Framework's Answer
Row-level cross-column validation Scope × Basis matrix: Row scope
Aggregate-level accounting identities Scope × Basis matrix: Aggregate scope
Relative: Production reconciliation Basis axis: Relative: Production
Relative: External recon (Stripe, bank) Basis axis: Relative: Recon
Temporal change detection Basis axis: Temporal
Automated test generation from framework /generate-tests skill
Interactive test plan building /audit-model skill
Self-improving quality feedback loop /self-review + /improve skills

Corr's profiling occupies one column of one row in our 3×6 matrix. The book is a 2011-era foundation; our framework extends it for the modern dbt/Snowflake stack.

Related — Chapter Notes

Related — Vault Cross-References