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

Table 1. Source relations classified into entities and relationships

Relational Tables Conceptual Class

Room Entity

RoomTypes Entity

RoomBands Entity

RoomFacilities Entity

Payments Entity

PaymentMethods Entity

Bookings Relationship

Customer Entity

County Entity

State Entity

City Entity

Singer Entity

Concert Entity

Buy Relationship

Measure Identification tivity ( e.g. , Sales, Bill) is generally modeled as

a relationship. This observation incites to limit
the construction of facts mainly on relationships
(Golfarelli, Maio, & Rizz, 1998), (Cabibbo, L., &
Torlone, R. 1998), (Feki, Nabli, Ben-Abdallah, &
Gargouri, 2008) and rarely on entities (Moody , &
Kortnik, 2000), (Phipps, & Davis, 2002), (Feki,
Nabli, Ben-Abdallah, & Gargouri, 2008). On the
other hand, in practice, not all relationships are
useful to build facts; so we limit the set of facts at
the first-relevance level to those containing a non
key numeric attribute. For the integrated schema
of our running example e-Ticket and hotel room
booking , we obtain the facts depicted in Table 2
where a fact built on a table T is conventionally
named F-T .
To complete this fact identification step, we
consider that each table representing an entity and
containing a numeric, non key attribute is a fact at
the second-relevance level ( cf. , Table 2). Note that
the numeric non key attribute condition excludes
facts without measures, which are considered as
infrequent facts.

A fact contains a finite set of measures. In most
cases, measures serve to compute summarized
results ( e.g. , total amount of sales by month and
year, by mart…) using aggregate functions; hence,
measures have numeric values. Therefore, we ex-
tract measures mainly from fact-tables ( i.e ., table
on which the fact is built). Furthermore, rarely
few additional measures could be extracted not
from a fact-table itself but from tables parallel to
it. Below, we informally explain how we extract
measures in each of these cases.

Measure Identified from a Fact-Table

To construct a significant set of candidate mea-
sures for a fact F-T built on a table T , we exclude
key-attributes from the set of numeric attributes
of T because keys are generally artificial and
redundant data, and they do not trace/record the
enterprise business activity. Moreover, we have
shown in (Feki, & Hachaichi, 2007-b) that we
must exclude from T its “non key attributes be-
longing to other tables” because these attributes