Database Reference
In-Depth Information
Figure 7. Relational schema derived from e-Ticket DTD
•
Import
Payments
,
PaymentMethods
and
RoomBands
from
hotel room booking
relational schema.
Import the relations
the
relations
table. To do so, we perform a reverse engineering
task by precisely examining the structure of the
tables in the sources. In fact, this leads to a scan
of the set of attributes composing the primary and
foreign keys of the source tables.
We have presented in our previous work
(Feki, & Hachaichi, 2007-a) how to partition a
set of tables, issued from an operational infor-
mation system, into two subsets: A subset of
tables modeling relationships and another subset
modeling entities. Briefly, a table representing a
relationship is characterized by its primary key
being composed of one or several foreign keys,
whereas a table representing an entity generally
has its primary key not containing foreign keys.
This classification should well form the two sub-
sets of tables by satisfying three basic properties:
Disjointness
,
Completeness
and
Correctness
. The
first property imposes that the two subsets share
no common table
; this ensures that each table is
uniquely classified. The completeness property
ensures that every table has a class. The correctness
property recommends that each table is correctly
identified,
i.e.
, as a relationship if it originally
models a relationship and as an entity if it models
an entity. Correctness is less trivial than the two
first properties and it is not satisfied in the two
following situations: 1) when the primary key of
•
SingerBuy
and
Concert
from the
e-Ticket
relational schema.
Import the relations
•
Room
,
RoomTypes
,
RoomBands
,
RoomFacilities
,
Bookings
,
Customer
,
County
,
State
and
City
from
e-
Ticket
and
hotel room booking
schemas and
integrate them using the union operator.
RELATION CLASSIFICATION
In current data-driven DW/DM development
methods, entities and relationships are the key-
stone of the conceptual design. More precisely,
dimensions are often built from entities and date
dimensions from temporal attributes; whereas
facts are mainly built from
n
-ary relationships
linking entities and, rarely on entities. However,
this distinction is not explicitly present in the re-
lational model where one single concept is used
to model both entities and relationships, namely
the relational table (or table for short).
Hence, in order to define a design process that
correctly identifies facts and dimensions from a
relational schema (
i.e.,
a set of relational tables) we
must first determine the conceptual class of each
Search WWH ::
Custom Search