Database Reference
In-Depth Information
Conventionally, it is an aggregate attribute also
know as calculated attribute, metrics or measure.
Examples of facts are the total amount of funds
allocated, funds consumed and funds in hand etc.
Key attributes are relationship attributes, as they
represent a relationship between fact and dimen-
sion tables. b) Dimension tables are different
perspectives, which can be used for analysis of
measures that are critical for the business (Paulraj,
2001). A dimension table consists of hierarchies
which can be used during analysis for drilling-
up, drilling down, slicing and dicing operations.
Examples of dimension are, Time (Day, Month,
Quarter, Year) and Product (ID, Name, Type,
Category) etc.
Practical guideline 1: Label the root
node of DW as V0.0;
Practical guideline 2: For each
change in OLTP (that can not be han-
dled by the current data warehouse),
a new version of the data warehouse
should be created in such a way that
each version represents a consistent
state of the data warehouse;
Practical guideline 3: Once a new
version is created, further data popu-
lation should take place in the new
version of the data warehouse.
Principle 2: With an exception of the root
version, each DW version is derived from
a version of the data warehouse. The initial
version of the data warehouse is called root
version or 0 th version, and it is not derived
from any previous version. As soon as the
operational sources of the DW change and
require a DW change, a new version is de-
rived from the 0 th version. In this case, the
derived version is called the child version
and the version from which it is derived is
called the parent version. For accommo-
dating a change, a new version can either
be derived from the 0 th version or from a
current child version. This parent to child
relationship is useful for understanding
overtime changes in the data warehouse
and for identifying dependencies between
versions.
Principles of MvdW
In order to solve the problems and to meet the
requirements elicited in section 2, the multiversion
data warehouse has been proposed (Rundensteiner,
2000). In multiversion data warehouses a new
version of the data warehouse is created as soon
as operational sources evolve, in such a way that
they cannot be handled by the conventional data
warehouse alone. The data produced after the
change is populated in the new version of the data
warehouse. Following are the main principles of
multiversion data warehouse:
Principle 1: Ensure that real-world events
do not lead data warehouse to inconsistent
state. A real-world event causes changes
in OLTP and it has been established that
changes in OLTP may yield inconsisten-
cies in data warehouses. Examples of such
events are: changes in administrative struc-
ture, new business markets and business
reengineering (Wrembel, 2005). Therefore,
DW administrator must ensure that real-
world events do not yield inconsistencies
in the data warehouse. Following are the
high-level guidelines by which inconsis-
tencies can be avoided.
Practical guideline 1: The label of
version should consistently identify
the version and its parent version.
Practical guideline 2: Multiple ver-
sioning graphs can be developed over
a set of versions of MVDW, in order
to restrict user access (see section 4.2
for details about versioning graph).
Principle 3: Validity time of a version de-
pends upon the time for which the real
world change is valid for business. Each
version of the data warehouse is valid for a
Search WWH ::




Custom Search