Database Reference
In-Depth Information
tecture, the idea is to keep the views like they
are returned from the integration process. This
independence is seen as a further advantage of our
proposed approach. Two physical architectures
are then possible for every logical DW. What-
ever the chosen architecture, the data warehouse
is considered as a set of facts and dimensions.
The warehouse creator clarifies the type of the
chosen physical architecture and its request (the
list L of the components requested) according to
meta-model given below in Figure 5.
The presented meta-schema can handle
multiple DW. Each of these data warehouses is
considered as a set of views (DW_Views), cubes
and lattices (Lattice). OLAP cubes and lattices are
presented in (Badri, 2008). The views are those
obtained by our integration process, where each
view corresponds to one or more queries. A view
is described by a fact and dimensions. We can
combine multiple hierarchies in one dimension.
Each of these hierarchies has one or several levels
of granularity. Each level is related to a component
and a single sequence over a given hierarchy. The
components of the DW are derived from attributes
belonging to the DS.
The meta-base built from this meta-schema
is used to ensure the transition from star to flat
DW schema and vice versa. A transformation
procedure is carried out using the ConstrView()
algorithm which is launched for each dimension
and for each fact. More details and choice criteria
between these two architectures can be found in
(Badri, Boufarès & Heiwy, 2007).
Example 12:
Using the meta-schema, the
data warehouse W, obtained in example 11, is
composed of two facts:
F
1
=
{x
2
,
x
3
}
and
F
2
=
{x
5
}
and three dimensions:
D
1
=
{y
1
,
y
8
}
,
D
2
=
{y
9
}
and
D
3
=
{y
10
}.
Figure 5. The DW meta-schema
Search WWH ::
Custom Search