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

94
Chapter 3
Summary
A dimensional data warehouse is only as good as its dimensions. Good dimensions contain
dimensional attributes that describe business events using terms that are familiar and
meaningful to the BI stakeholders. This is the best reason for asking stakeholders to modelstorm
the dimensions they need using examples to clarify the terms they use.
Dimensions themselves are discovered by event modeling; most who, what, when, where and
why event details become dimensions. Dimensional attributes are discovered by modeling each
of these details as the subject of its own BEAM ✲ dimension table. How details can be
dimensionalized in this way too but they typically do not have additional descriptive attributes.
Non-descriptive how details become degenerate dimensions, stored in fact tables along with the
how many details which become facts.
The first additional attribute that must be modeled for a dimension subject is its identity. This is
the business key (BK) which uniquely identifies each dimension member and defines the
dimension granularity. If a dimension is created from multiple source systems there may be
more than one BK for a dimension member. The unique BK for a dimension can be a
composite of multiple source systems keys.
Further dimension attribute requirements are gathered by asking stakeholders to provide
example descriptive data for each dimension (using the 7Ws as an attribute type checklist).
Examples help to discover mandatory attributes (MD), and exclusive attribute combinations
(Xn) together with their defining characteristics (DCn,n).
Hierarchy charts describe how stakeholders (want to) organize dimensional members
hierarchically to support drill-down analysis and plan vs. actual reporting. Drawing these charts
helps to prompt stakeholders for additional hierarchical attributes and data sources. Hot
hierarchy levels, that represent popular levels of summarization, help to identify additional
planning events, rollup dimensions and aggregation opportunities.
Hierarchies can be balanced, ragged or variable depth. Each type can be single or multi-parent.
Single parent, balanced hierarchies are the easiest hierarchies to implement dimensionally and
the simplest to work with for BI. Additional techniques are needed to balance ragged
hierarchies and represent multi-parent and variable depth hierarchies (See Chapter 6).
Change stories describe how dimensional history is handled. The short codes CV, HV, FV, PV
are used to document the temporal properties of each attribute. These temporal codes can be
numbered to define group change rules involving multiple attributes.
Minor events are events that occur infrequently and contain few details. They typically do not
represent significant business processes that warrant modeling as separate events. Often they
can be modeled as HV dimensional attributes, or as additional details of other major events
(recognizable business processes).