My first Publication Agile-Data-Warehouse-Design-eBook

30 Chapter 2 Nightly inventory for a product at a retail location Monthly balance and interest charges/payments for a bank account Minute-by-minute viewing figures by audience for a TV channel Recurring events summarize discrete events but can also represent the atomic detail for “automatic” measurements Recurring events are typically used to sample and summarize discrete events, especially when cumulative measures, such as stock levels or account balances, are required that would be expensive to derive from the discrete events. For example, calculating an account balance at any point in time would require all the transac- tions against the account from all prior periods to be aggregated. Recurring events can also represent atomic-level measurement events that “automatically” occur on a periodic basis; for example, the hourly recording of rainfall at weather stations. Events and Fact Tables Events are business models for physical fact tables Table 2-1 Story types and their matching star schemas Discrete events are user models for transaction fact tables Recurring events represent periodic snapshots Evolving events represent accumulating snapshots The three BEAM ✲ event story types are business models (conceptual models) for the three physical fact table types found in the star schemas of dimensional data warehouses. Table 2-1 shows how story types and fact table types are related. BEAM✲ S TORY T YPE S TAR S CHEMA T YPE /P HYSICAL D IMENSIONAL M ODEL Discrete Transaction fact table Recurring Periodic snapshot Evolving Accumulating snapshot Discrete events are implemented as transaction fact tables. All the detail that there is to know about discrete events is known before they are loaded into a data ware- house. This means that each discrete event story (fact record) is inserted once and never updated, greatly simplifying the ETL process. Recurring events are implemented as periodic snapshot fact tables. Many of their interesting measures are semi-additive balances that must be carefully reported over multiple time periods. Evolving events are implemented as accumulating snapshot fact tables. They are loaded into a data warehouse shortly after the first event in a predictable sequence, and are updated each time a milestone event occurs until the overall event story is completed. Chapter 5 describes the basic steps involved in translating events into star sche- mas. Chapter 8 provides more detailed coverage on designing transaction fact tables, periodic snapshots and accumulating snapshots.

My first Publication Agile-Data-Warehouse-Design-eBook | Page 51