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

236
Chapter 8
If all the repeated
milestone values
are needed they
must be modeled
as discrete events
If milestone events
have a M:M
relationship it may
not be appropriate
to combine them in
the same evolving
event
Tell process stories
that describe the
typical, min and max
intervals between
milestones
Use missing values
to describe the initial
state of an event.
You also want to
describe its final
states, completed
or otherwise
How Many
Typically, BI queries will use the most recent values for a repeating milestone but if
stakeholders say they need all the values then you will have to model the milestone
as a separate discrete event at its atomic-level of detail. If you have already done so
you can point the stakeholders at its event table. Either way, you still want to push
for a single value definition for each repeating detail so that you can add it to the
evolving event. To help stakeholders to understand why the most recent value
would be useful, remind them that the role of the new event table is to summarize
the current progress or final state of each evolving event story.
If stakeholders continue to struggle to give you a single value definitive answer for
a detail, then it probably does not belong in the evolving event. This can happen
where there is a M:M relationship between milestones and more complex alloca-
tions are needed. In which case, it may not be appropriate to combine any of the
details from the milestone. If the initial event and a milestone turns out to have a
M:1 relationship, this is not so problematic but some allocation of additive quanti-
ties will be needed. For example, if 2 different orders for 100 units are partially
fulfilled by a single shipment of 190 units, a SHIPPED QUANTITY of 100 must be
assigned to the first evolving order event and 90 assigned to the second.
If you determine that a milestone' detail belongs in the event, you should use its
examples to tell interesting process stories. For milestone dates, ask stakeholders to
give you examples that will represent typical, minimum, and maximum intervals
between milestones. If a detail has already been modeled as part of a discrete event,
you may be able to reuse values from its event table, but these must make sense in
combination with the examples already present in the evolving event. For example,
if you have used a relative time value like “Today” for ORDER DATE you might
leave SHIP DATE as missing to show that initially there is no shipment yet for an
order loaded into the data warehouse today.
As you add new details, you may have to alter some of the existing examples dates
to bring out interesting scenarios, such as the initial and final states of the event.
The initial state will have missing values for all the milestone details that have not
happened yet. This means some details that are mandatory in discrete events must
become optional in the evolving event. For example, CARRIER is always present
on a CARRIER DELIVERY event but will be “Unassigned” in the evolving
CUSTOMER ORDERS event if an order has not been shipped yet. If there can be
more than one final state, try to capture additional process stories for each possible
outcome; for example, ask stakeholders to give you stories of successfully com-
pleted orders and cancelled orders.
When you have finished modeling an evolving event, it is a good idea to reorder
the details after the main clause in W and process order—keeping all the whens,
whos, whats, wheres, and so on together in the order they appear chronologically.
Doing so can make a complex evolving event much easier to read.