Database Reference
In-Depth Information
part of a DW with a restricted scope of content
and support for analytical processing, serving a
single department, part of an organization and/
or a particular data analysis problem domain. By
adopting a bottom-up approach, the DW will turn
out to be the union of all the data marts.
This iterative approach promises to fulfill
requirement (c) since it cuts down development
costs and time by limiting the design and imple-
mentation efforts to get the first results. On the
other hand, requirement (d) will be fulfilled if the
designer is able to implement first those data marts
that are more relevant to the stakeholders.
It should be noted that adopting a pure bottom-
up approach presents many risks originating from
the partial vision of the business domain that will
be available at each design phase. This risk can
be limited by first developing the data mart that
plays a central role within the DW, so that the
following ones can be easily integrated into the
existing backbone, this kind of solution is also
called bus architecture (Kimbal et al., 1998).
Based on these considerations the main phases
for the DW life-cycle can be summarized as fol-
lows:
in more detail in the following. At each
iteration a new data mart is designed and
deployed.
3.
DW maintenance and evolution : DW main-
tenance mainly concerns performance op-
timization that must be periodically carried
out due to user requirements that change ac-
cording to the problems and the opportunities
the managers run into. On the other hand,
DW evolution (Golfarelli & Rizzi, 2009)
concerns keeping the DW schema up-to-date
with respect to the business domain and the
business requirement changes: a manager
requiring a new dimension of analysis for
an existing fact schema or the inclusion of
a new level of classification due to a change
in a business process may cause the early
obsolescence of the system.
DW design methodologies proposed in the
literature mainly concern phase 2 and thus should
be better referred to as data mart design method-
ologies. Though a lot has been written about how
a DW should be designed, there is no consensus
on a design method yet. Most methods agree on
the opportunity of distinguishing between the
following phases:
1.
DW planning : this phase is aimed at deter-
mining the scope and the goals of the DW,
and determines the number and the order in
which the data marts are to be implemented
according to the business priorities and the
technical constraints (Kimbal et al., 1998).
At this stage the physical architecture of the
system must also be defined: the designer
carries out the sizing of the system in order to
identify appropriate hardware and software
platforms and evaluates the need for a rec-
onciled data level aimed at improving data
quality. Finally, during the project planning
phase the staffing of the project is carried
out.
2.1 Requirement analysis: identifies which in-
formation is relevant to the decisional pro-
cess by either considering the user needs or
the actual availability of data in the opera-
tional sources.
2.2 Conceptual design : aims at deriving an im-
plementation-independent and expressive
conceptual schema for the data mart, ac-
cording to the conceptual model.
2.3 Logical design : takes the conceptual schema
and creates a corresponding logical schema
on the chosen logical model. While nowa-
days most of the DW systems are based
on the relational logical model (ROLAP),
an increasing number of software ven-
dors are proposing also pure or mixed
2.
Data mart design and implementation : this
macro-phase will be repeated for each data
mart to be implemented and will be discussed
Search WWH ::




Custom Search