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

hierarchies not only at the schema but also at
the instance level. Thus, by using corresponding
cardinalities designers can represent this kind of
hierarchy without ambiguity.

8a. However, when using ER notation it is not
clearly indicated whether levels may form a hierar-
chy since higher hierarchy levels (e.g., Category )
may be included in supertype (e.g., Customer )
and are not related to the other hierarchy levels
in its subtypes. Therefore, in Malinowski and
Zimányi (2008) we proposed a new notation as
shown in Figure 8b to represent a hierarchy that
clearly distinguishes different paths according to
existing subtypes, e.g., a path formed by the lev-
els Customer-Occupation type-Category is used
for an individual customer, while a path with the
levels Customer-Business type-Category may be
traversed for a customer that is a reseller.
A generalized hierarchy is characterized by
having at the schema level multiple exclusive paths
sharing at least the leaf level; these paths may also
share some other levels, as shown in Figure 8b
for the Category level. All these paths form one
hierarchy that uses the same analysis criterion.
Since each member of the hierarchy belongs to
only one path, as can be seen in Figure 8c 5 , we use
the symbol ⊗ to indicate that paths are exclusive
for every member at the instance level.
Unfortunately, this kind of hierarchy is not
represented as such in the AdventureWorksDW
and cannot be implemented in SSAS. In general,
the proposed solution is, first, to create two sepa-
rate dimensions (i.e., for Individual and Reseller
that, in the AdventureWorksDW, correspond to
DimCustomer and DimReseller , respectively)
and, second, to use separate fact tables for each
of these dimensions. Another commonly-applied
solution is to create one flat table with all types
of customers and to include null values for the
attributes not applicable for the specific type of
customer. One disadvantage of these approaches
is that the common levels of the hierarchy can-
not be easily distinguished and managed, such as
the Customer and Category levels in Figure 8b.
Furthermore, the inclusion of null values requires
specifying additional constraints that ensure cor-
rect queries (e.g., to avoid grouping Business type

Recursive Hierarchies

Recursive hierarchies 4 are a special case of unbal-
anced hierarchies and represent the situation where
the same level is linked by the two different roles
of a parent-child relationship. Figure 3 includes a
Supervision recursive hierarchy for the Employee
dimension. This hierarchy represents the employee-
supervisor relationship expressed by subordinate
and supervisor roles of the parent-child relationship
linked to the same Employee level. When recursive
hierarchies are used all hierarchy levels most often
express the same semantics, i.e., the characteristics
of the children and parents are similar (or the same),
e.g., where an employee has a supervisor who is
also an employee.
The usual way to represent this kind of hierar-
chy at the logical level is by including a foreign
key in the same table that contains a primary key,
as can be seen in Figure 2 for the DimEmployee
table, which includes a ParentEmployeeKey
representing a supervisor. This implementation
is called a parent-child table.
A recursive hierarchy is not represented as a
hierarchy in SSAS; instead, a hierarchy symbol
is attached to the attribute that represents a
parent key. Notice that even though the conceptual
(Figure 3) and logical (Figure 2) representations of
these kinds of hierarchies are similar, this is not the
case for the implementation model of SSAS.

Generalized Hierarchies

A generalized hierarchy occurs when a dimen-
sion includes subtypes that can be modeled as a
generalization/specialization relationship (Abelló
et al, 2006; Akoka, Comyn-Wattiau &Prat, 2001,
Luján-Mora et al., 2006) as can be seen in Figure