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

Modeling Business Dimensions
67
then you have found a single-valued attribute that belongs. You should also find
out how many other address values a customer can have. If customers have only
two additional addresses, for example, home address and work address, then you
can define them as separate attributes in the dimension by being more precise
about their meaning/name. A small fixed
If customers can have multiple addresses (some might have hundreds) then you
may have discovered a missing where detail of CUSTOMER ORDERS. Addresses
might be delivery addresses; customers are ordering gifts for their family and
friends or resellers are ordering products for their clients. If that is the case, the
addresses in question don’t belong to customers. They belong instead to the busi-
ness event as a DELIVERY ADDRESS detail and subsequently as a separate dimen-
sion. This handles the genuine many-to-many (M:M) relationship between
customers and these addresses. If a proposed
If the answer to the question: “Can a [dimension name] have more than one [at-
tribute name] (at one moment in time)?” is a resounding NO then the attribute
belongs in the dimension. If the answer is a resounding YES it most likely doesn’t
belong but may warrant more investigation before you rule it out. If no one is
happy to see the dimension without a particular attribute, you may have to qualify
the attribute in some way (for example, Primary Address), or adjust the dimen-
sion’s granularity to accommodate it. A proposed attribute
If the multiple addresses do belong to a customer — they are the offices or stores of
a corporate customer — you might need to change the CUSTOMER dimension
granularity to customer location, if event activity is tied to specific locations and
stakeholders treat each location as an individual customer. In which case you
would redefine the granularity as one row per customer per location and define a
composite business key to uniquely identify each member. Alternatively the
number of values
can be modeled as
separate attributes
attribute has
multiple values it
may represent a
separate dimension
of the business
event
can be qualified
(e.g. Main… or
Primary…) to
restrict it to a
single value
dimension
granularity might
need to be adjusted
to match the vital
attribute
The previous example treats customer address as a single attribute. In reality,
address would be several dimensional attributes, such as Street, City, Region,
Postal Code, and Country: attributes that represent a geographic hierarchy. If this
is well understood by stakeholders, the individual attributes can be modeled later.
Attribute Examples
After you have established that an attribute belongs in the dimension you add it to
the BEAM ✲ table and ask the stakeholders for example values that match the
dimension subject. The dimension subject will already contain typical and excep-
tional (different and group themed) examples copied from an event (that you
captured using the event story themes in Chapter 2). These usually prompt the
stakeholders to provide interesting values for each new attribute, too. Stakeholders
will typically give you values that they want to see on their reports.
Ask for examples for
each new attribute
that match the
dimension subject
members