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

Modeling Business Dimensions
71
Good defining characteristics should be low cardinality, mandatory attributes.
They should have a small number of unique values to match the small number of
exclusive groups they control and they should always be present to provide con-
trolling values. Because of these properties DC attributes are typically important
levels in dimension hierarchies. If a DC attribute is optional and high cardinality
and/or a dimension is awash with exclusive groups it may be a clue that you are
struggling to model a ‘one size fits all’ generic dimension. Defining
Exclusive attribute groups can be nested if required. For example, if “for profit”
and “non profit” organizations were described differently, an additional defining
characteristic BUSINESS TYPE marked DC3,4 would govern their descriptive
attributes marked X3 and X4. As these are all business related attributes they
would be nested within the “Business” exclusive group X2 using the code combina-
tions X2, X3 and X2, X4. Their defining characteristic BUSINESS TYPE is also a
business only exclusive attribute so it should be marked in full as X2, DC3,4. Exclusive attribute
Some of the exclusive attributes in Figure 3-5 are marked as mandatory (MD) but
are not always present because they are exclusive to a subset of the dimension
members. The code combination Xn, MD means exclusive mandatory attribute:
attribute is only mandatory when its exclusive group is valid. An attribute can only
Defining characteristic and exclusive attribute groups allow you to model subsets
within a single BEAM ✲ table. Subsets can help you later to define restricted views
(or swappable dimensions, see Chapter 6) to increase usability and query perform-
ance. They also provide important ETL processing rules and checks. Exclusive attribute
characteristics
should be low
cardinality and
mandatory
groups can be
nested with other
exclusive groups
be mandatory when
its Xn group is valid
subsets can be
implemented
as separate tables
Using the 7Ws to Discover Attributes
Every dimensional attribute, just like every event detail, is one of the 7Ws. There-
fore you can use the 7Ws as a question checklist to help you ask stakeholders for
additional attributes when their initial flood of attributes starts to dry up. Not every
W question makes sense for every W-type dimension so you don’t want to stick so
rigidly to the BEAM ✲ sequence you use to follow the narrative arch of an event.
For who, what, when and where dimensions it is often useful to start with a ques-
tion of the same W-type as the dimension. For who and what dimensions the
answers are often example members for type attributes. For example, if you ask:
Who or what is a customer or a product?
Pomegranate stakeholders might reply with examples like:
Customers are consumers, businesses, charities…
Products are computers, software, accessories…
They can also be services.
Use the 7Ws
as a checklist
for discovering
attributes