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

Modeling Business Events The third event story in Figure 2-6 shows that this is possible. Each time you add a new detail to the event you return to the repeat story to see if that detail can be used to differentiate the event, by adding it to the previous question; for example, “Can this CUSTOMER order this PRODUCT again on the same day, from the same SALES LOCATION?” If that’s possible repeat the typical story values. 41 Repeat the typical story if it is not yet unique You might have uniqueness with the subject, object, and initial when details alone, or you might not have it until you discover a how detail with your very last question. Figure 2-6 Adding event stories Missing Stories You ask for a missing story to discover which event details can have missing values (e.g. unknown, not applicable, or not available) and which are mandatory (always present). You use a missing story to document how stakeholders want to see missing values displayed on their reports. When you fill out a missing story (such as the fifth story in Figure 2-6) you use normal values for mandatory details and the stakeholders’ default missing value labels (e.g. “N/A”, “Unknown”) for the non mandatory details. For quantities you must find out whether missing data should be treated as NULL (the arithmetically correct representation of missing) or replaced by zero, or some other default value. You document the mandatory details by also adding the short code MD to their column type. Missing stories document how missing values will be treated by BI applications. They also help to identify mandatory event details MD : mandatory detail. Event detail is always present under normal circum- stances (no data errors). Missing stories can be unrealistically sparse, containing missing values for any detail that might ever be missing. It’s okay if there are more missing values than would ever be seen in a single real event story. It’s OK for missing stories to be unrealistically empty