“Chapter 2: Modeling Business Events” — Corr & Stagnitto

Why this is in the vault

This chapter is the operational core of BEAM (Business Event Analysis & Modeling) — the method Corr proposes for collaboratively discovering dimensional models with stakeholders. For Ray Data Co, this matters because:

• We build data products for clients who often struggle to articulate what they want to measure. The 7Ws framework gives us a repeatable interview protocol that works with non-technical stakeholders.
• The story-type taxonomy (discrete / evolving / recurring) maps directly to the three physical fact table types. Knowing which type you are dealing with early prevents expensive mid-build schema pivots.
• BEAM tables are spreadsheet-native. They can be shared in Google Sheets or Notion databases during discovery, lowering the barrier for async collaboration — critical for a lean consultancy.

Key concepts

Data stories and the 3Ds

BEAM treats business events as the atomic unit of data modeling. Every event is processed through three steps: discover (ask “who does what?”), document (build a BEAM table), and describe (fill the table using the 7Ws and event stories). Data stories are the dimensional-modeling analogue of agile user stories — concrete, example-driven narratives told by stakeholders about their own business processes.

Story types

Events fall into three temporal categories, each mapping to a specific fact table architecture:

The preposition on a when detail is the key signal: “on” suggests a date-grain discrete event, “at” implies date+time, and “every” flags a recurring event. If any when detail can change after initial load, the event is evolving.

The 7Ws

The 7Ws are both a questioning framework and a classification scheme for every detail in an event:

The recommended sequence starts with who + what (to form the subject-verb-object main clause), then when (to establish time grain and story type), then where, how many, why, and how. In practice the answers flow between Ws — a quantity naturally prompts a “why” about its variance.

Event story themes

Five story themes let you populate 5-6 example rows that surface most modeling edge cases with minimal effort:

1. Typical — representative values for every detail
2. Different — extreme or contrasting values to expose data ranges and history depth
3. Repeat — near-duplicate of the typical row to discover what combination of details defines uniqueness (granularity)
4. Missing — which details can be null vs. mandatory (documented with short code MD)
5. Group — variations in meaning (B2B vs. B2C customers, product bundles) that reveal mixed hierarchies

Event granularity

Granularity is the combination of detail values that uniquely identifies each event story. It is discovered through the repeat theme — if every detail in a repeat row matches the typical row, you need more details. Usually granularity comes from a combination of who, what, when, and where, but sometimes only a transaction ID (how detail) can guarantee uniqueness. Granular details are marked with the short code GD.

Detail about detail

Not every discovered detail belongs to the event itself. The position-sensitivity test distinguishes event details from dimensional attributes: swap a detail into the middle of the main clause. If it reads like nonsense (“CUSTOMER with PRODUCT TYPE orders PRODUCT”), it is detail about detail — an attribute of a dimension, not the event. These get parked above the relevant column and modeled as dimension attributes later.

Naming and completing the event

The event name is chosen last, after all details are known, typically as an uppercase plural noun phrase derived from subject + verb (e.g. CUSTOMER ORDERS). Story type codes [DE], [RE], or [EE] are added to the table header. A double bar on the right edge signals the table is complete.

Mapping against Ray Data Co

Client discovery sessions. The “who does what?” opener and the 5-theme story pattern can be templated into our standard intake questionnaire. Instead of asking clients to describe their reporting needs abstractly, we ask them to narrate concrete business events — a technique that sidesteps the common problem of clients requesting summary reports without understanding the underlying grain.

Data product architecture. Classifying client events as DE/EE/RE early in scoping lets us estimate ETL complexity before writing a line of code. Discrete events are insert-only and simple; evolving events require update logic and duration calculations; recurring events need careful attention to semi-additive measures. This classification should appear in our project scoping template.

Modelstorming as a service offering. BEAM’s whiteboard-and-spreadsheet approach is deliberately low-tech. For a consultancy that works async and remote, the spreadsheet variant (BEAM tables in Google Sheets) could become a deliverable in its own right — a collaborative artifact that clients continue to own and extend after our engagement ends.

Granularity discipline. The repeat-story technique for discovering grain is more rigorous than the ad-hoc “what’s the primary key?” conversation that most projects default to. Adopting it would reduce the frequency of grain-mismatch bugs in our dbt models.

Related

• 2026-02-18-practical-data-modeling-mma-ch1-full — Practical Data Modeling (MMA Ch1) covers complementary ground on data modeling foundations
• 2026-04-04-building-the-event-clock — Event clock architecture connects directly to the when dimension and recurring event patterns
• 2026-04-04-dedp-dwh-mdm-datalake-reverse-etl-cdp — Data engineering platform taxonomy provides the infrastructure context for where these fact tables live
• 2026-04-04-dedp-mv-obt-dwa — Materialized views and one-big-table patterns represent alternatives to the star schema approach BEAM targets
• 2026-04-05-etl-is-dead — ETL/ELT debate is relevant because BEAM’s story types directly predict ETL complexity (discrete = simple insert, evolving = upsert logic)
• 2026-04-04-sql-patterns-xheblati — SQL patterns complement the physical implementation side that BEAM’s conceptual models feed into