Database Reference
In-Depth Information
Problems of Cube
Structure Changes
lead to wrong decisions. One possible solution to
this problem is data transformation, i.e. viewing
old data under new structures or vice versa. One
may define the semantics of a query, and the system
has - provided that the necessary information is
available - the ability to include only the desired
data, exclude undesired data and adjust the data
to the desired structure and semantics.
It is obvious that the cube structure is modeling a
certain part of the real world. For instance, depart-
ments and divisions of a company will somehow be
represented in a cube used in that company. Thus,
there may be a Company dimension comprising
members for the departments and divisions. And,
as the real world tends to change, such changes
must also be represented in the cube structure.
Changes can happen on the schema level, i.e.
dimensions or categories are changed, or on the
instance level, i.e. the members are changed.
Figure 1 shows examples for schema and in-
stance changes. It contains three different version
of a cube structure in a car dealer's data warehouse.
For sake of simplicity, only the Cars dimension is
depicted. The dealer sells different car models of
different brands. Each model has assigned a user
defined attribute Engine Power. Traditionally, for
German cars this is given in horsepower, whereas
for English models it is given in kilowatt. In the
second version there are various instance changes:
the new model BMW1 is introduced and Silver
Spirit is renamed to Silver Spirit II. In version 3
there is also a schema change. Due to the merge
of BMW and Rolls Royce on the one hand and
Mercedes and Chrysler on the other hand, a new
dimension level is introduced. Of course for this
new level also new members are created and the
existing members are relocated accordingly. The
brand Puch is discontinued, the model attached
to it is now sold under the brand of Mercedes.
The new brand Chrysler with one car model is
introduced, whereas the Phantom V is removed
from the product portfolio. The attribute for the
engine power is unified to kilowatt. All these
structure modifications are due to changes in the
data warehouse's application domain.A modifica-
tion resulting from a changed requirement can for
instance be the introduction of a member profit
in the facts dimension, depicting the car dealers
wish to keep track of his profit.
BACKGROUND: THE
DATA WAREHOUSE
MAINTENANCE PROBLEM
The standard architecture and modeling approach
for data warehouses is the multidimensional data
cube. A multidimensional data cube consists of a
set of
Dimensions,
each of them comprising a set
of
Dimension Members
(also called simply
Mem-
bers
). Dimensions are hierarchically organized
into a set of
Categories
or
Dimension Levels,
each of them having assigned a set of members.
The members themselves are also hierarchically
structured, accordingly to the categories they are
assigned to. Dimensions and categories define
the
schema
of the cube, whereas the members
are called the
instances.
Schema and instances
together define the
cube structure.
Selecting one
member from each dimension defines a
Data Cell
,
containing either a
Cell Value
or a NIL value.
Although there is no standardized terminology
in data warehousing till today, these basic terms
are widely accepted. The terms
Fact
and
Measure
are sometimes used with different semantics. In
this chapter they are used as follows: A fact is a
dimension member in the
Fact Dimension,
repre-
senting a certain subject of analysis (for instance
Turnover). The term measure is used synonym
to cell value.
Search WWH ::
Custom Search