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
- book-adwd-ch1-how-to-model-dw-2026-04-13
- book-adwd-ch2-modeling-business-events-2026-04-13
- book-adwd-ch3-modeling-business-dimensions-2026-04-13
- book-adwd-ch4-modeling-business-processes-2026-04-13
- book-adwd-ch5-modeling-star-schemas-2026-04-13
- book-adwd-ch6-who-what-design-patterns-2026-04-13
- book-adwd-ch7-when-where-design-patterns-2026-04-13
- book-adwd-ch8-how-many-fact-tables-2026-04-13
- book-adwd-ch9-why-how-design-patterns-2026-04-13
Related — Vault Cross-References
- ../01-projects/data-quality-framework/testing-matrix-template — our Scope × Basis framework that extends Corr’s profiling
- internal-review-mg-harness-cc-wrapped-2026-04-13 — MG harness review that identified TDD gap (Corr validates)
- 2026-04-07-seattle-data-guy-noisy-data-quality-checks — SDG’s complementary “fewer better checks” thesis
- 2026-04-11-garry-tan-thin-harness-fat-skills — Tan’s latent vs deterministic maps onto Corr: profiling = deterministic, BEAM✷ facilitation = latent