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