Improving Expressive Power in Modeling Data Warehouse and OLAP Applications - Evolving Application Domains of Data Warehousing and Mining - page 34

Figure 13. A parallel hierarchy with two composed hierarchies in SSAS a) schema and b) instances
during combination of hierarchies

clients will pay for them; therefore, a client dimen-
sion is playing two different roles in participation
in a fact relationship.
In Figure 3 the Date dimension is represented
as a role-playing dimension using its members to
represent order date (when the product was or-
dered), due date (when the product was delivered),
and ship date (when the product was shipped).
When this dimension is mapped to the relational
model, the key attribute for the Date level will be
included as a foreign key in the fact table as many
times as different roles this level is playing. As a
consequence, the relational representation will be
the same as in Figure 2 for the FactResellerSales
table, i.e., including the foreign key DueDateKey ,
OrderDateKey , and ShipDateKey .
However, as can be seen in Figure 2 and 3,
the conceptual schema is much more expressive
in indicating different roles than its correspond-
ing relational mapping. The latter requires some
technical knowledge and adequate naming in order
to distinguish role-playing dimensions.
SSAS uses a wizard that is able to discover
role-playing dimensions if several foreign keys
referring to the same dimension are included
in the fact table (as shown in Figure 2). Then,
the role-playing dimensions (handled as virtual
objects) are represented in the dimension panel
(Figure 14a) and they correspond to a one time

dimension included in the solution explorer panel
(Figure 14b) (handled as a physical object related
to the DimTime table).

degenerate or fact dimensions

In several applications a user may require to
analyze data at the lowest granularity level, e.g.,
an order line representing a product; however,
he/she may require grouping different products
according to the order to which they belong.
That could be useful for applications related to,
e.g., market-basket analysis. The usual practice
promoted by Kimball and Ross (2002) is not to
represent this order as a separate dimension in the
multidimensional schema, since all data, except
order number, already form part of the schema,
e.g., products, date, employee who sells, reseller
who buys, etc. Instead, an attribute is included in
the fact table, e.g., the SalesOrderNumber attribute
in the FactResellerSales table in Figure 2. This
attribute is called in two different ways: (1) fact
dimensions since it is included in the fact table
playing the dimension role or (2) degenerate
dimensions since it has only one attribute.
We consider that even though in the logical or
implementation level this attribute can form part of
a fact table, the conceptual schema should keep it
as a dimension to indicate that users may require