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

42
Chapter 2
Occasionally you may have an event subject that is consistently missing. For
example, a retail sales event might be described as “CUSTOMER buys PRODUCT
in STORE”, but the customer name is never recorded. When the event is imple-
mented as a physical fact table this virtual detail will be dropped, but during event
storytelling it focuses everyone on the atomic-level event. Perhaps the event
stories should contain “Anon.” or “J. Doe”.
Evolving events will
have many missing
details.
For discrete and
recurring events this
is a warning that
they may be too
generic
Group stories
highlight details that
vary in meaning
Evolving events by their nature will have a number of validly missing details that
are unknown when the event begins; for example, ACTUAL DELIVERY DATE for
an order or FINAL PAID AMOUNT for an insurance claim. However, if you find
discrete and recurring events with a lot of missing details it is often a clue that you
are trying too hard to model a “one size fits all” generic event that is difficult for
stakeholders to use and it may be better to model a number of more specific event
tables where the details that really define distinct business events are always pre-
sent.
Group Stories
You ask for example events containing groups to expose any variations in the
meaning of a detail. For example, a typical order event consists of an individual
customer ordering a product. But is this always the case? You should ask the
stakeholders:
Is a customer always an individual?
Can a product be something more complex,
like a bundle of products?
Mixed business
models (B2B, B2C,
products and
services) are often
discovered by group
stories
The last two example events in Figure 2-6 are group themed. From these you learn
that customers can be organizations as well as individuals and orders can be placed
for multi-product bundles. The knowledge that there are different types of cus-
tomer (B2B: business-to-business and B2C: business to consumer), and prod-
uct/service bundles will make you think carefully about how you implement these
details as dimensions. Chapter 6 covers mixed customer type dimensions, multi-
level dimensions and hierarchy maps, while Chapter 9 covers multi-valued dimen-
sions. These design patterns can be used to solve some of the more vexing model-
ing issues surfaced by group themed examples.
You should ask for just enough event stories so that everyone is clear about the
meaning of each event detail. Don’t get carried away trying to record every story—
that’s what the data warehouse is for—you want to concentrate on discovering all
the event details.