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

Modeling Business Events
47
Detail About Detail
A new event detail can sometimes turn out to be an additional characteristic of an Check that each
existing detail, rather than a detail of the whole event itself. It is detail about detail new detail belongs
instead of detail about the event. You can be given unnecessary details if you ask to the whole event
too many what questions as they can sound so open-ended. For example, the what and is not just detail
question: “CUSTOMERS order PRODUCTS with what?” might give you an answer about detail that
“with product type”, but is PRODUCT TYPE a detail of the event that would be lost if only further
it was not recorded in the event or does it belong elsewhere? describes a detail
you already have
Spotting detail about detail is usually intuitive, but if you have any doubts you can
test a detail to see if it is position sensitive. You do this by mentally swapping the
new detail into the middle of the main clause, and reading it both ways: before and
after swapping. If the event still makes sense, then the detail isn’t position sensitive,
and belongs to the event. However, if the event sounds like nonsense (even when
you change the detail preposition), then the detail is really about another detail and
will only make sense if placed directly to the right of the detail that it actually de-
scribes. For example:
“CUSTOMER orders PRODUCT with PRODUCT TYPE”
This sounds okay, but try placing the new detail after the subject:
“CUSTOMER with PRODUCT TYPE orders PRODUCT”
Oops, clearly this no longer makes sense. Customers don’t have product types,
products do. Product type only makes sense if it appears directly after (to the right
of) PRODUCT. It is position sensitive. This tells you that product type describes
PRODUCT, not the event itself, and is therefore detail about detail.
Stripping out any details that are not directly related to the event is important, so that Detail about detail
the event can be used to define an efficient fact table. However, you do not want to isn’t discarded.
completely discard the important finding that PRODUCT TYPE is a detail about It is used to define
products. It’s obviously something that stakeholders want to report on. Instead of dimensions
adding it to the table you can place it above the PRODUCT column in the space set
aside for capturing detail about detail. You will use it shortly to define the PRODUCT
dimension.
You can apply the same test to the SALESPERSON detail from the earlier who
question: swap it around the event main clause and listen to yourself saying:
“from SALESPERSON CUSTOMER orders PRODUCT” or
“CUSTOMER, from SALESPERSON, orders PRODUCT”
You sound strange (like Yoda in Star Wars) but it still makes sense. You can see
that the additional who detail can be placed anywhere in the main clause and its
meaning is not lost. Therefore SALESPERSON is not position sensitive, and this
tells you that it is a detail about the event.