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

Modeling Business Events
35
Summary events can always be added afterwards for query efficiency, if necessary,
so long as the details are there. You should make sure you initially model the most
granular discrete events the stakeholders are interested in. You can then model
recurring and evolving events from these (in subsequent iterations) to provide
easier access to the performance measures that stakeholders need. Chapter 8 covers
the event modeling and dimensional design techniques for doing this. Summary events
Asking: “Who does what?” does not always ensure that you will get actual who and
what details. Objects especially can be any of the 7Ws, including how many. For
automated recurring events there may simply not be a responsible who subject that
triggers them. For example, “Store stocks product” or “Weather station records
temperature” are both perfectly valid events, but neither has who details. “Store”
and “weather station” are where-type subjects, and “temperature” is an example of
a how many object rather than a what object. Subjects and
There is no need to fret over this, and try to coax stakeholders into supplying
actual people (who) and things (what) in every case as this can get in the way of
capturing their perspective on the event. The most important thing is that stake-
holders supply a main clause containing a verb worth measuring. If their main
clause doesn’t contain a who or what you will soon discover any that belong to the
event as you use each of the 7Ws to discover more details. As long as you have
can always be
added later. You
should initially
concentrate on
the atomic detail
objects are not
always who and
what. They can be
any of the 7Ws
a verb you will find
any whos or whats
involved (if any) by
asking more W
questions shortly
Verbs
Verbs are one of the most difficult parts of any language. Because of numerous
tenses, cases, and persons, the possible ways of expressing a verb can be
confusing. For instance, the verb “to buy” can be written as “buy”, “bought”,
“buying” and “buys”. To simplify events, use this last version “buys” which is the
third-person singular present tense. This simply means it sounds right after “he”,
“she”, or “it”. In English, this version of the verb always end in “s”. For example,
“to call” becomes “calls”, “reviewed” becomes “reviews”, “auditing” becomes
For verbs, use the
third-person singular
present tense
“audits”, and “will sell” becomes “sells”. This standard form is intuitive and avoids
awkward verb variations.
2. Document the Event: BEAM✲ Table
Now that the stakeholders have supplied an event, you need to document and
display it on a whiteboard or screen where everyone can see it using a BEAM✲
example data table. Figure 2-3 shows the initial table for “Customer orders prod-
uct.” If this looks like it could be an “ordinary” spreadsheet table that’s a good
thing; Business stakeholders are the target audience for this model and they are
usually very comfortable with spreadsheets.
An event is
documented as a
BEAM✲ table on a
whiteboard or in a
spreadsheet