Databases Reference
In-Depth Information
NOTE
A derived attribute may be stored at the physical level but not displayed
to the business users.
A derived attribute can also be created to tie together parts within a
dimension in order to facilitate reporting. This is useful when, for example,
you have three important identifiers that are used alone and together such
as Line of Business, Company, and Risk for an insurance policy dimension.
Figure 7-20 shows this derived attribute within the body of a dimension.
Line of
Business
Company
Risk
Policy
Effective Date
Policy Group
Renewal
Policy
Expiration
Date
Call
Transaction
Figure 7-20
Derived attribute within the Policy dimension
Multiple Instances of a Dimension: Role Playing
There are many transactions whereby what originally seems like a single
dimension occurs multiple times for a fact group. This must be fully explored
to ensure that this is really the case. If so, each needs to be identified for
query and analysis purposes as a separate role for that dimension. In order to
minimize confusion, each attribute must be uniquely labeled. Typically, this
means that each attribute must have a prefix to clarify which role is being
represented.
One of the most common instances of role playing is for the Date dimen-
sion. Is it common for a single business transaction — say, for a product
shipment — to have multiple dates. These would include the product order
date and the product ship date. Figure 7-21 shows the two separate dimen-
sions, whereas Figure 7-22 shows that each role of the dimension is included
in the fact group diagram.
