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

88
Chapter 3
Documenting CV Change Stories
For CV attributes:
copy their typical
examples into the
change story or
better still (time
permitting) ask for
new values to fill out
the change story
row and then
replace the typical
example values
If stakeholders confirm that an attribute’s history is never needed — perhaps they
want an explicitly current value attribute such as CURRENT STATUS or
LIFETIME VALUE — you label the attribute as CV. To fill out its change story, you
can either copy the attribute’s typical example (as you would if it was FV), for
speed, or ask stakeholders for a changed value, for clarity. If you do the latter you
must also change the typical example on the first row to this new value. Both the
typical example and the change story of a CV attribute contain the same value, the
new current value, to “show, don’t tell” that there is no history. Figure 3-16 illus-
trates this for CUSTOMER NAME: if customer Elvis Priestley changes his name to
J.B. Priestley both the first and the last rows in the BEAM ✲ dimension are updated
to J.B.; Elvis has left the building! The graphic demonstration of existing examples
being overwritten, during modelstorming, hammers home the point that history is
lost and may cause stakeholders to reconsider some of their CV attribute decisions.
Documenting HV Change Stories
For HV attributes
ask for new
examples for their
change stories but
leave their typical
examples unaltered
You can document
hybrid temporal
requirements by
combining HV and
CV short codes
If stakeholders say they do want the historical values of an attribute such as
PRODUCT TYPE, label the attribute as HV, and ask for a new example value to
place in the change story, as shown in Figure 3-15, but don’t update the original
typical example. Leaving different values in the first and last rows clearly document
the attributes that can change and will hold different historical values over time for
the same dimension member: product code IPPBS16G in the Figure 3-15 example.
If you, or the stakeholders, decide that both HV and CV data is needed for an
attribute you can label it as an HV/CV or CV/HV hybrid attribute, with its default
reporting behavior listed first. In figure 3-15, SUBCATEGORY and CATEGORY
default to HV but CV reporting will also be available. For both attributes their
change stories reflect the more complex HV behavior.
Unless you are using specialist temporal database technology, the CV and HV
values of a hybrid attribute will need to be stored as separate physical columns in
the same dimension or in separate hot swappable dimensions. See Chapter 6 for
the hybrid slowly changing dimension design pattern to implement this.
Use CV/PV to
document
requirements for
previous values
For certain attributes, that change very infrequently, stakeholders may be content
with the current value and one previous value: the value before the last change.
These attributes can be labeled CV/PV in the BEAM ✲ model and implemented as
separate columns in a physical star schema. This design pattern is know as a type 3
slowly changing dimension.
FV : Fixed Value or type 0 slowly changing dimension.
CV : Current Value only or type 1 slowly changing dimension.
HV : Historic Value or type 2 slowly changing dimension.
PV : Previous Value or type 3 slowly changing dimension.