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

110
Chapter 4
RP dimensions can
play multiple roles in
the same event
A role-playing dimension can play multiple roles in the same event. For example,
EMPLOYEE could appear twice in an evolving event containing both order and
shipment details as both SALESPERSON and WAREHOUSE WORKER. Similarly,
CALENDAR — the most commonly occurring role-playing dimension — would play
the roles of ORDER DATE and SHIP DATE.
When using [ ] notation to document an event role you can drop its generic W-
type (e.g., [who] or [what]) to save space, because this is already documented
within the dimension table and on the matrix.
Define conformed
role-playing
dimensions as early
as possible
Changing the name of a dimension (and its attributes) to make it more reusable at
the design stage is painless compared to the refactoring and testing involved if the
dimension had already been deployed. Hence the importance of modeling multiple
events to identify conformed dimensions and their role-playing opportunities
before the first star schema is deployed.
Don’t implement any dimension until you have used an event matrix to check
whether it should be conformed across multiple events.
Role-playing
dimensions, while
more conformed,
may not initially
appeal to
stakeholders
Use the new event’s
main clause with the
7Ws to ask for
further details
Is a role-playing employee dimension the right approach? Stakeholders can often
feel uncomfortable with generalization (see opposite) like this, if they cannot see
any business benefit, i.e., cannot imagine ever wanting to group together the
activities of salespeople and warehouse staff. If stakeholders do voice concerns, you
should try to encourage them to see the “bigger picture” benefit of a conformed
dimension beyond the current scope. You can also assure them that when they
query sales or logistics they will have filtered lists of salespeople or warehouse staff
to choose from, and will never have to search through all employees.
Once you have added the new event to the matrix, you ask for the rest of its details
almost exactly as you would if filling out an event table: by turning its main clause
into a series of questions using the 7Ws. The only difference being that you ignore
when and how many questions as you don’t need that level of detail for the matrix.
Using the who, what and where column headings on the matrix as a checklist, you
might ask:
Warehouse worker ships product for/to/using whom?
Warehouse worker ships product with what/in what way?
Warehouse worker ships product from/to where?
Add any new
dimensions to the
matrix and then tick
off all dimensions
used by the event
In response to these who, what, where questions the stakeholder might identify
CUSTOMER (who) and DELIVERY ADDRESS (where) as potential conformed
dimensions, and introduce new dimensions for CARRIER (who), SHIP MODE
(more of a how than a what) and WAREHOUSE (where) as new dimensions.
When you, or better still the stakeholders themselves, have added these to the
matrix, it should look like Figure 4-11.