Designing Data Marts from XML and Relational Data Sources - Data Warehousing Design and Advanced Engineering Applications - page 74

is the primary key of T1 .
In addition to dimensions built on tables, we
can build a dimension both on an attribute of a
special data type (Boolean, temporal) as well as
on an attribute issued from an empty entity. Such
a dimension is known in data warehousing as a
degenerated dimension. For instance, a Boolean
column splits data-rows of its table into two
subsets; thus, such an attribute can be an axis of
analysis. In practice, a degenerated dimension is
integrated inside the fact.
A Boolean column b pertinent to a fact-table
T produces for T a candidate, degenerated dimen-
sion named D-b and identified by b . For instance,
a Gender column in a Client database table can
build a dimension D-Gender .
Furthermore, the data warehouse community
assumes a DW as a chronological collection of data
(Kimball, Reeves, Ross, & Thornthwaite, 1998).
Consequently, the time dimension appears in all
data warehouses. For this reason, we propose to
build dimensions on temporal attributes as follows:
A temporal attribute (date or time) belonging to
a fact-table T timestamps the occurrences of the
fact built on T ; it generates a candidate dimension
for T where it is the identifier. For the relational
schema issued from e-Ticket and Hotel room
booking , the above rules produce the dimensions
shown in Table 3.

tained parameter constitutes a hierarchy. Secondly,
for each one, we extract its successor parameters.
Thus, a parameter of level two is either:

a) the primary key of a table of class Entity

directly referred by a dimension-table d ;

b) a Boolean or temporal attribute belonging

to a dimension table d ; or

c) a non (primary or foreign)-key attribute be-

longing to a dimension-table d and to other
tables.

The recursive application of the above two
steps on the tables obtained in step a) produces
parameters of level higher than two. Table 4 pres-
ents the hierarchy parameters of each dimension
in Table 3.
A parameter may functionally determine some
attributes within its origin table; these attributes
describe the parameter and, therefore, are called
descriptive (also non-dimensional or weak) attri-
butes. Descriptive attributes for a parameter p are
non-key textual or numerical attributes belonging
to a table supplying p and not belonging to other
tables. Among these attributes, those textual are
more significant than numerical ones (Feki, &
Hachaichi, 2007-a). Table 5 presents for each
parameter of Table 4 its associated descriptive
attributes.

Hierarchy Identification

CASE TOOLSET

The attributes of a dimension are organized into
one or several hierarchies. These attributes are
ordered from the finest towards the coarsest
granularity. In order to distinguish them, we call
these attributes parameters. In addition, any hier-
archy of a dimension d has the identifier of d as
its finest parameter ( i.e. , at the level one ) already
extracted with d . The remaining parameters ( i.e. ,
those of level higher than one) forming candidate
hierarchies for d will be extracted in two steps.
First, we extract the parameters located im-
mediately after the dimension identifier; each ob-

To support our design method, we have imple-
mented the CAME ( “ C onception A ssistée de
M agasins et d' E ntrepôts de données” ) case toolset.
CAME carries out the design of conceptual DM
schemes starting from either the relational database
schemas of an operational database, or from a set
of XML documents compliant to a given DTD.
Its main functions cover our DM design method
steps: 1) Acquisition and pretreatment of a DTD
using a DTD parser and the XQuery language to
extract typing information; 2) Conversion of XML