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

Modeling Business Dimensions
61
Hierarchy charts are used to ask stakeholders questions about how they
organize (an active verb) the members of a dimension (the values in event sto-
ries) into groups. These groups, because they generally have much lower cardi-
nality than the individual members of the dimension, make good row headers
and filters for reports — good starting points for telling fewer, higher-level event
stories for BI analysis. Many of these groups have hierarchical relationships
with one another. Exploring these hierarchies will prompt stakeholders for ad-
ditional descriptive attributes and provides the information needed to config-
ure BI drill-down and aggregation facilities. Hierarchy charts
Change stories are data stories that document how each dimensional attribute
should handle historic values. By asking stakeholders how dimension members
change (another active verb) they not only describe which attributes can and
cannot change (but can be corrected), but also state their reporting preferences
for using current values or historical values. Getting stakeholders to think
about change reminds them of additional attributes that behave in similar ways
to existing ones and can lead to the discovery of auxiliary business processes
that capture changes. Some of these auxiliary processes can be significant
enough that they need to be modeled as business events in their own right. Change stories
help you to ask
questions about
how dimensions
are organized
describe how
dimensional
attributes change,
and how they
should reflect
history for reporting
purposes
The Cardinality of an attribute or relation refers to the number of unique values.
High cardinality attributes have a large number of unique member values, whereas
low cardinality have a small number of unique members.
Discovering Dimensions
Having modeled an event, there is no elaborate discovery technique for dimensions
because they naturally come out of the event details that you already have. Each
event detail that has additional descriptive attributes will become a dimension. For
most details there is, at the very least, an identity attribute — a business key — that
uniquely identifies each dimension member. This is typically the case for the who,
what, when, where, and why details. The candidate dimensions from Chapter 2’s
CUSTOMER ORDERS event are:
CUSTOMER [who]
PRODUCT [what]
ORDER DATE [when]
DELIVERY DUE DATE [when]
SALESPERSON [who]
SALES LOCATION [where]
DELIVERY ADDRESS [where]
PROMOTION [why]
Missing from this list are the event quantities and any how details, such as ORDER
ID, which do not have any additional descriptions that need to be modeled in
separate dimension tables. When the event is converted into a star schema these
Dimensions are
discovered as event
details by telling
event stories
Event details with
additional
descriptions
become dimensions