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

each sub-category can have many products. The
cardinality between the Employee and Depart-
ment levels are many-to-many, indicating that
the same employee can be assigned to different
departments; this hierarchy may include a symbol
of called a distributing factor that indicates
how the measures associated with an employee
are divided between departments. These and other
cardinalities in the parent-child relationships lead
to different kinds of hierarchies, to which we will
refer in more detail in the next sections.
The hierarchies may be represented using
different structures depending upon analysis
purposes; to differentiate these them, we include
an analysis criterion . For example, the Product
dimension in Figure 3 includes two hierarchies:
Product groups and Product colors . The former
hierarchy comprises the levels Product , SubCat-
egory , and Category , while the latter hierarchy
includes the levels Product and Color .
The hierarchies include two distinguishable
levels: the leaf level that contains the most detailed
data and the root level representing the most gen-
eral data. The leaf level must be the same for all
hierarchies included in a dimension and its name
is used as the dimension's name. For example, the
Product dimension includes two hierarchies with
the same leaf level Product, while the root levels
are different for each hierarchy, i.e., the Color level
for the Product colors hierarchy and the Category
level for the Product groups hierarchy.
A fact relationship represents a focus of
analysis and corresponds to an n-ary relation-
ship between leaf levels, e.g., the Reseller sales
fact relationship relates the Product , Employee ,
Reseller , Date , and Region levels in Figure 3.
Level members may participate in a fact rela-
tionship from 0 to n times, thus defining (0,n)
cardinality. To simplify the model, we omit
such cardinalities. Moreover, since in some ap-
plications it may be required that the same level
participates several times in a fact relationship,
we define roles . To represent each role we use
a separate link with a name between the cor-

responding level and the fact relationship, e.g.,
Due date , Order date , Ship date in Figure 3 for
the Date dimension.
A fact relationship may contain attributes
commonly called measures , e.g., SalesAmount
and OrderQuantity in Figure 3; they are usually
numeric data meaningful for the leaf members that
are aggregated while traversing different hierar-
chy. Measures have been classified as additive ,
semiadditive , or nonadditive (Kimball & Ross,
2002; Lenz & Shoshani, 1997). We assume by
default that measures are additive, i.e., they can
be summarized along all dimensions. To indicate
that measures are semiadditive or nonadditive, we
include the symbols +! and +, respectively, next
to the measure's name as shown for the nonad-
ditive measure UnitPrice in Figure 3. By default,
for additive measure the sum function is applied
when aggregation takes place. If another function
is required we include it in the schema, e.g., the
maximum value for the measure TotalCost in Fig-
ure 3. Additionally, measures and level attributes
may be calculated on the basis of other measures
or attributes. We call them derived and use the
symbol / as can be seen for the SalesAmount
measure in Figure 3.
The conceptual schema in Figure 3 contains
different kinds of hierarchies and dimensions that
cannot be distinguished in the logical schema in
Figure 2. We will refer to different elements of the
schema in Figure 3 explaining their meaning in
more detail and showing the added expressiveness
of conceptual representation compared to logical
and implementation ones.

Mapping to relational Model

The usefulness of a conceptual model consists in
providing different elements for representing ad-
equately the semantic of an application. However,
the conceptual schemas must be transformed into
implementation schemas that are currently avail-
able for developing the DW and OLAP systems.
Malinowski and Zimányi (2008) proposed the