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

Modeling Business Events
55
Sufficient Detail
Just because you have enough details to define the event granularity does not mean
you stop adding details. If the stakeholders are still providing relevant details, keep
adding then. Event uniqueness is a minimum requirement. What you are aiming
for is the complete set of details that tell the “full” story (or at least as much of it as
is currently known).
Granularity is not
enough, you want
all the details
Naming the Event
It is now time to give the event a short descriptive name, one that the stakeholders
will be comfortable with and that matches a recognized business process. The
name can often be some variant of the event verb. If the verb is shared by other
events (you may have to model other types of orders; e.g., wholesale orders or
purchase orders) then a combination of subject and verb will be needed to make a
unique name. By convention, event names are uppercase plural. In Figure 2-13 the
completed event table, now named CUSTOMER ORDERS using the subject and a
verb, has been transferred to a spreadsheet.
Event names often
use the event
subject and verb
Figure 2-13
Documenting the
event
If the event verb doesn’t provide a good name try using one of the how details. For
example, if the main clause was “Customer Buys Product” an event name of
CUSTOMER BUYS might be replaced by CUSTOMER PURCHASES or
CUSTOMER INVOICES using how details like PURCHASE ID, or INVOICE
NUMBER. If the verb doesn’t
The subject of an event is actually subjective: it is based on the stakeholders’ initial
perspective. Different stakeholders can describe the very same event starting with a
different subject. Once all its details have been discovered the initial event might be
better described using one of those alternative points of view, by swapping around Event subjects are
sound right try a
how detail
subjective!