© ACM, 2004. This is the author's version of the work.

It is posted here by permission of ACM for your personal use. Not for
2004 ACM
redistribution. The definitive version was published in Proceedings of the 2004 ACM Symposium onSymposium on Applied(SAC),
Applied Computing Computing
ISBN
1-58113-812-1

Creation and Management of Versions

in Multiversion Data Warehouse 1
Bartosz Bębel Johann Eder Christian Koncilia
Institute of Computing Science Department of Informatics-Systems Department of Informatics-Systems
Poznań University of Technology University of Klagenfurt University of Klagenfurt
Poznań, Poland Klagenfurt, Austria Klagenfurt, Austria
bartosz.bebel@ [email protected] [email protected]
cs.put.poznan.pl

Tadeusz Morzy Robert Wrembel

Institute of Computing Science Institute of Computing Science
Poznań University of Technology Poznań University of Technology
Poznań, Poland Poznań, Poland
+48 61 6652370 +48 61 6652529
[email protected] [email protected]

ABSTRACT heterogeneous external data sources (EDSs) in order to provide an

A data warehouse (DW) provides an information for analytical information for analytical processing, decision making, and data
processing, decision making, and data mining tools. On the one mining tools [11]. For a few recent years users of data
hand, the structure and content of a data warehouse reflects a real warehousing systems have been paying a special attention to the
world, i.e. data stored in a DW come from real production analysis of operational data produced by OLTP (On-Line
systems. On the other hand, a DW and its tools may be used for Transaction Processing) applications, in order to discover trends,
predicting trends and simulating a virtual business scenarios. This anomalies, and patterns of behavior. Different analytical tools
activity is often called the what-if analysis. Traditional DW enable the analysts to make better1decisions.
systems have static structure of their schemas and relationships An important consequence of the autonomy of EDSs is that they
between data, and therefore they are not able to support any may evolve in time independently of each other and independently
dynamics in their structure and content. For these purposes, of a data warehouse. The changes in EDSs can be categorized as:
multiversion data warehouses seem to be very promising. In this (1) content changes, i.e. insert/update/delete records, and (2)
paper we present a concept and an ongoing implementation of a schema changes, i.e. add/modify/drop an attribute or a table that
multiversion data warehouse that is capable of handling changes are very common as reported in [19, 20]. Both types of changes
in the structure of its schema as well as simulating alternative may lead to schema changes in a data warehouse. For instance,
business scenarios. adding a new attribute in one of the EDS may require adding this
attribute to the DW schema, if one would like to analyze values of
Categories and Subject Descriptors this attribute in the warehouse. Furthermore, even a content
H.2. [Database Management]: Logical Design – data models. modification in the EDS, e.g., inserting a new record, may lead to
a schema modification in the DW. For instance, inserting a new
product in an EDS may lead to modification of the structure of the
General Terms Products dimension in the DW.
Design, Experimentation, Performance.
Most of the research done so far with respect to the data
warehouse maintenance has focused on providing transactional
Keywords incremental DW refreshing under content changes of EDSs.
data warehouse, versioning, integrity constraints. However, changes in the content of EDSs as well as changes in
the structure of EDSs may lead to schema changes of a DW. This
1. INTRODUCTION issue has not received much attention so far [7, 8, 19].
A data warehouse (DW) integrates autonomous and A naive approach to tackle the problem of schema changes is to
isolate the changes from a data warehouse. Isolation can be
Permission to make digital or hard copies of all or part of this work for
accomplished by the middleware level. This technique may be
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage, and that 1
copies bear this notice and the full citation on the first page. To copy This work is partially supported by the grant no. 4 T11C 019 23
otherwise, or republish, to post on servers or to redistribute to lists, from the Polish State Committee for Scientific Research
requires prior specific permission and/or a fee. (KBN), Poland
SAC'04, March 14-17, 2004, Nicosia, Cyprus
Copyright 2004 ACM 1-58113-812-1/03/04…$5.00.

717
applicable to a limited period of time only, since evolution of EDS violation from one group to a group of more severe violations.
schemas will lead to inconsistencies between EDSs and their This is an example of the real world simulation (the what-if
descriptions at a data warehouse level. In a consequence, it may analysis) and it should be handled by an alternative data
restrict the usage of existing client analytical queries and reports warehouse schema version.
or the analyses may produce obsolete results. A more advanced
approach to tackle the problem of schema changes is to ensure the DW systems and OLAP tools existing on the market support
correct propagation of these changes to the data warehouse neither managing changes of a data warehouse structure nor the
definition, i.e. the structure and content of a DW must be correctly what-if analysis functionality. [22] is an example of a software
adjusted. The data warehouse schema adjustments can be done in tool that is able to deal with some evolution issues. However, it is
two different ways, namely schema evolution [3] and schema limited to some basic operations and is not able to cope with
versioning [16, 18]. complex operations as presented in [7]. Furthermore, the approach
presented in [22] does not support storing several alternative data
The first approach consists in updating the schema and warehouse versions for the what-if analysis. Therefore, there is
transferring the data from an old schema into a new schema. Only evidently a need to develop techniques of management of schema
the current version of the schema is present. In contrast, the changes in data warehouse systems, techniques of managing
second approach keeps track of the history of all versions of a alternative "versions" of the same data warehouse, and build such
schema. Versioning can be done implicit by temporal extension or systems.
explicit by physically storing different versions of data.
Our contribution. Our approach to the problem of maintaining a
The process of good decision making often requires forecasting DW under changes of schemas and contents of EDSs is based on
future business behavior, based on present data and assumptions explicit versioning the whole data warehouse (i.e. schema and
made by decision makers. This kind of data processing is called data). Changes into a data warehouse structure and data are
the what-if analysis. In this analysis, a decision maker simulates reflected in a new, explicitly derived, version of a DW. The model
changes in the real world, creates a virtual possible scenarios, and of a multiversion data warehouse that we developed allows
explores them with OLAP queries. To this end, a data warehouse modeling alternative DW versions. The set of data originating
must provide means of creating various data warehouse from one version, can be persistently stored in another version.
alternatives, represented by different data warehouse versions.
Maintaining real and alternative versions of the whole data
In our project we propose two different kinds of versions: (1) real warehouse allows us on the one hand, to run queries that span
versions, which handle changes made to EDSs, and (2) alternative multiple versions and compare various factors computed in those
versions, which handle changes made by a user directly in a data versions, and on the other hand, to create and manage alternative
warehouse for the purpose of applying the what-if analysis. Real virtual business scenarios required for the what-if analysis.
versions represent previous states of EDS. These previous states
can be represented as a linear sequence of different real versions We implemented the mentioned approach as a prototype software
as depicted in Figure 1. However, as future is not yet known, using Visual C++. Data and metadata are stored in an Oracle
alternative versions necessary for the what-if analysis have to be database.
represented by a branching time model as shown in Figure 1. Paper organization. The rest of this paper is organized as
Notice that sometimes the user/administrator of a DW may be follows. Section 2 presents basic definitions in the field of data
interested in preserving old alternative versions. Consequently, warehouse technology. Section 3 presents a leading DW example.
our approach also allows to manage different (branching) Section 4 overviews existing approaches to DW evolution.
alternative versions in the past. Section 5 discusses our concept of a multiversion data warehouse,
discusses types of data warehouse versions and their properties,
presents time integrity constraints defined for DW versions, as
well as sketches our data sharing technique. Section 6 briefly
presents our prototype multiversion data warehouse system.
Finally, Section 7 summarizes and concludes the paper.

Figure 1. Representation of real versions (Vi)

and alternative versions (Aj)
2. BASIC DEFINITIONS
The most popular architecture of data warehouses are
To illustrate the issues mentioned above, let us consider an multidimensional data cubes, where measures which are
example of a police data warehouse, storing information about instances of facts, i.e. subjects of analysis, that are described in
committed violations and tickets given to drivers, in given terms of hierarchically organized dimensions. Examples of
locations (cities located in provinces) at given periods of time. measures include: number of items sold, income, turnover, etc.
Violations are organized into severity groups that define minimum Typical examples of dimensions are Time, Geography, Products,
and maximum fines allowed for violations. Let us assume that as a etc. A value of a measure in a n-dimensional cube is referenced by
result of legislative changes, the borders of provinces changed a n-dimensional vector, where each element corresponds to an
causing that some cities that had previously belonged to one element of a dimension.
province, were moved to another one. This is an example of a
change in the real world that has an impact on a data warehouse Dimensions are usually organized in hierarchies. An example of a
schema. In order to handle this change, a new real data warehouse hierarchical dimension is Geography, with Countries at the top,
version should be created. Assuming that a certain percent of fines that are composed of Regions, that in turn are composed of Cities.
paid in a city feeds the budget of that city, the police may A schema object in a hierarchy is called a level. Values in every
investigate how the city budget would increase if they moved a level are called dimension members.

718
Multidimensional cubes can be implemented either in MOLAP ----- ------- -------- --------
1 Group A 10 100
(multidimensional OLAP) servers or in ROLAP (relational 2 Group B 100 350
OLAP) servers. In the former case, a cube is stored in
select viol_id, viol_name, gr_id from violations;
multidimensional array. In the latter case, a cube is implemented
VIOL_ID VIOL_NAME GR_ID
as the set of relational tables, some of them represent dimensions, ------- ------------ ----------
and are called dimension tables, while others store values of 1 Violation 1 1
measures, and are called fact tables. In the paper, we will focus 2 Violation 2 1
3 Violation 3 2
our discussion on ROLAP implementation of a DW, but our
concept can also be used in a MOLAP implementation. select * from cities; select * from regions;
CITY_ID CITY_NAME REG_ID REG_ID REG_NAME
In the rest of this paper, we will use the definitions of a data ------- --------- ------ ------ --------
1 Poznań 1 1 Region A
warehouse schema and a data warehouse instance as presented 2 Warsaw 2 2 Region B
in [7] and [8]. Hence, the schema of a data warehouse is the set of 3 Konin 1
all defined dimensions, dimension levels, dimension members,
select * from inspected_violations;
hierarchical relations between dimension members and dimension TIME_ID VIOL_ID CITY_ID NB_OF_VIOL TOTAL_FINE
levels, and facts. The instances of a data warehouse are the ------- ---------- ---------- ---------- ----------
measures, i.e., the cell values stored in fact tables. 1 1 1 10 650
1 2 1 25 900
Therefore, we refer to each modification of a dimension, 1 3 2 15 3200
1 1 3 20 2000
dimension level, dimension member or fact as schema evolution
and schema versioning respectively. Examples of user analytical queries that run on the DW may
include: (1) compute sum of fines ever paid and (2) compute sum
3. MOTIVATING EXAMPLE of fines paid in every city.
Let us consider the police data warehouse, mentioned in the The data warehouse describes the real world that is likely to be
introduction. This DW stores data about violations committed by changing. In order to capture these kinds of changes real DW
drivers. Violations are inspected in various locations and at a versions are needed. The police may also want to simulate various
certain time. The police analyzes those data in order to find out operational scenarios. To this end, alternative DW versions are
how many violations were committed in given cities at certain needed.
periods of time. Cities where drivers are inspected are grouped
into administrative regions, whereas violations are organized into
groups. 3.1 Real Data Warehouse Version
The real world represented in a DW may change. In our example,
The schema of the police DW is shown in Figure 2. The schema is changing the borders of regions may result in cites being moved
composed of the three following dimensions: Locations, from one region to another. Such a change has an impact on the
Violations, and Time. The Locations dimension is composed of analytical results received from a data warehouse.
two levels, namely: Regions and Cities. The Violations
dimension is also composed of two levels: Violation_Groups and Let us assume a query computing a sum of fines per region and its
Violations. Every dimension member of Violation_Groups result:
defines a minimum and maximum fine that can be given for a REG_NAME SUM(IVI.TOTAL_FINE)
given violation (attributes min_fine and max_fine, respectively). -------------------- -------------------
The Time dimension has one level. Records in the Region A 3550
Region B 3200
Violation_Groups, Violations, Regions, Cities, and Time tables
are called dimension members. After moving city “Konin” from “Region A” to “Region B”
results of the same query are different, e.g.:
The Inspected_Violations fact table stores the information about:
number of violations committed (attribute nb_violations), total REG_NAME SUM(IVI.TOTAL_FINE)
-------------------- -------------------
fine paid by drivers for these violations (total_fine), and date the Region A 1550
violations were inspected (time_id). Let us further assume that the Region B 5200
tables store the following data.
In order to handle this kind of changes as well as process and
analyze data properly we need a new version of a data warehouse,
describing the real world after changes. In this case an old DW
version would store data before an administrative-territorial
change, and a new DW version would store data after that change.

3.2 Alternative Data Warehouse Version

A DW may also be used for simulating various
operational/business scenarios. For example, assuming that a
certain percent of fines paid by drivers in a city feeds the local
budget, the police may investigate how the budget would increase
Fig.2. An example schema of the police DW if they moved a violation from the group of ordinary violations to
select * from violation_groups; a group of more severe ones. Let us assume that in this simulation
GR_ID GR_NAME MIN_FINE MAX_FINE scenario “Violation 2” was moved from “Group A” to “Group B”.

719
In order to create such a simulating environment, a data of a database is however very large. Therefore, those versioning
warehouse must be able to create alternative versions of schema mechanisms are not suitable for data warehouse versioning.
and data as well as to manage these versions. The change must be
applied to the structure of the Violations dimension, consisting in The approaches to the management of changes in a data
assigning a given violation to a new group of violations (a warehouse can be classified into the two following categories that
violation’s foreign key update). support: (1) schema and data evolution: [3, 9, 10, 13], (2)
temporal and versioning extensions [5, 7, 8, 15, 1, 2, 4, 12, 14, 17,
Next, a police decision maker may assume an increase in fines 19]. The approaches in the first category support only one data
paid by drivers. This assumption is based on an observation that warehouse schema and its instance. When a change is applied to a
the higher the maximum fine allowed for a violation, the higher schema all data described by the schema must be converted, that
the tickets on average. In such a simulating scenario, a new incurs high maintenance costs.
version of fact data will also be created from the previous version.
The changes to fact data require computing new values of In the approaches from the second category, in [5, 7, 8, 15]
total_fine for every affected record in Inspected_Violations. In changes are time stamped in order to create temporal versions.
However, [5] and [15] expose their inability to express and
our example, only record <1, 2, 1, 25, 900> is affected, as it
process queries that span or compare several temporal versions of
describes violations of type “Violation 2”. More precisely, the
data. On the contrary, the model and prototype of a temporal data
value of total_fine must be increased according to a new range of
warehouse presented in [7, 8] support queries for a particular
values defined in “Group B”. Thus, we need a kind of conversion
temporal version of a DW or queries that span several versions. In
function that would compute new values of facts based on original
the latter case, conversion functions must be applied, as data in
data. In this scenario, the conversion function is written by a data
temporal versions are virtual.
warehouse administrator. New values of the total_fine attribute
may be computed assuming that coefficient In [12, 14, 17, 19] implicit versioning in a data warehouse was
(total_fine/nb_violations)/max_fine remains constant after proposed. In all of the four approaches, versions are used for
changing group assignment. avoiding conflicts and mutual locking between OLAP queries and
transactions refreshing a data warehouse. As versions are
Having created a new simulation version of a DW, and having
implicitly created and managed by the system, these mechanisms
converted the fact data, a decision maker may compare the real
can not be used in the what–if analysis. The same drawback
situation with a hypothetical situation. In both cases the total sum
applies to the previously discussed temporal data warehouses that
of fines as well as the sum of fines paid in each city is computed,
can manage only consecutive versions linearly ordered by time.
as shown below.
On the contrary, [2] proposes permanent user defined versions of
REAL CASE
views in order to simulate changes in a data warehouse schema.
SUM(IVI.TOTAL_FINE) CITY_NAME SUM(IVI.TOTAL_FINE) However, the approach supports only simple changes in source
------------------- --------- -------------------
6750 Konin 2000
tables and it does not deal either with typical multidimensional
Poznań 1550 schemas or evolution of facts or dimensions. Also [4] supports
Warsaw 3200 permanent time stamped versions of data. The proposed
mechanism, however, uses one central fact table for storing all
SIMULATION CASE
versions of data. In a consequence, the set of schema changes that
SUM(IVI.TOTAL_FINE) CITY_NAME SUM(IVI.TOTAL_FINE) may be applied to a data warehouse is limited, and only changes
------------------- ----------- -------------------
9000 Konin 2000
of dimensions' structure are supported.
Poznań 3800
Warsaw 3200 An approach supporting the what–if analysis was presented in [1].
It may be considered as a kind of virtual versioning. A
In the simulation case city “Poznań” would substantially increase hypothetical query is executed on a virtual structure, called
its budget. scenario. Then, the system using substitution and query rewriting
techniques transforms the hypothetical query into an equivalent
As we have shown in the above examples, data warehouse
query that is run on a real data warehouse. As this technique
versions are useful for handling changes in the real world as well
computes new values of data for every hypothetical query, based
as for simulating various business scenarios. Real data warehouse
on virtual modifications, the performance problems will appear
versions are applied in the first case, whereas alternative data
for large warehouses.
warehouse versions are applied in the second case. Both kinds of
versions are orthogonal.
5. MODEL OF A MULTIVERSION DATA
4. RELATED WORK WAREHOUSE
The support of evolution of schema and data turned up to be In order to be able to manage changes in a data warehouse schema
required in the applications of object–oriented databases to a model of a data warehouse with versioning capabilities was
Computer Aided Design, Engineering, and Manufacture systems. developed in [16]. In our approach, changes to a schema may be
The problem was intensively investigated and resulted in the applied to a new version of a data warehouse. This version, called
development of various approaches and prototypes, e.g. [23, 24, a child version, is explicitly derived by a DW administrator from
25, 26, 27]. These and many other approaches were proposed for any previous version, called a parent version. A multiversion
versioning complex objects for a moderated size of the whole set data warehouse (MVDW) is composed of the set of its versions.
of data. In data warehouse systems objects being versioned have Every version of a MVDW is in turn composed of a schema
very simple structure (several fact or dimension tables). The size version and an instance version. The latter stores the set of data

720
consistent with its schema version. Versions of a data warehouse (EVT). For example, real version V0 (from Figure 3) is valid
form a version derivation graph. Each node of this graph within time t0 – BVT and t1 – EVT, whereas V1 is valid within t2
represents one version, whereas edges represent derived–from and t3. Alternative versions V1.1, V1.2, and V1.1.1 are valid
relationships between two consecutive versions. In our approach, within the same time period as its parent real version. Below we
a version derivation graph is a DAG. formally define version valid time constraints.
Let DWV be the set of data warehouse versions and Vi be a
5.1 Versions of a Data Warehouse version in DWV. Let Î be the version derivation dependency
In our approach we distinguish two following kinds of data between a parent Vm and a direct child version Vn.
warehouses versions: real versions and alternative versions. A
real version reflects changes in the real world. Real versions are Let T represent any real time, ti be time in T. Let VT be a set of
created in order to keep up with the changes in real business valid times and VTi = <tk, tl> where VTi in VT and {tk, tl} in T.
environment, like for example: changing organizational structure TC1: Real Versions Valid Time Constraint
of a company, changing geographical borders of regions, creation
Real versions are linearly ordered by their valid time. The ending
and closing shops, changing prices/taxes of products. Real
valid time of a parent real version may be the beginning valid time
versions are linearly ordered by the time they are valid within.
of its child real version, or the valid time periods of parent and
The purpose of maintaining alternative versions is twofold. child real DW versions are disjoint.
Firstly, an alternative version is created from a real version in
order to support the what-if analysis. So, it is used for simulation Let VTm = <ta, tb> be a validity time of data warehouse version
purposes. Several alternative versions may be created from the Vm and VTn = <tc, td> be a validity time of version Vn.
same real versions. Secondly, such a version is created in order to ∀ (Vm, Vn) in DWV: Vm Î Vn then VTm ∩ VTn = ∅ or tb=tc.
simulate changes in the structure of a DW schema. The purpose of
such versions is mainly the optimization of a DW structure and This constraint is illustrated in Figure 4. The ending valid time of
system tuning. A DW administrator may create an alternative real versions V1, i.e. t7 is the beginning valid time of real version
version that would have a simple star schema instead of an V2, where V2 is the child of V1.
original snowflake schema, and then test the system performance
using new data structures. Alternative versions form a DAG.

Fig.4. Real and alternative versions and their valid time

Fig.3. An example of a set of DW versions constraint
Figure 3 schematically shows real versions and alternative TC2: Real–Alternative Versions Valid Time Constraint
versions. V0 is an initial real version of a DW. Based on V0, a A valid time of any alternative DW version is within the valid
new real version V1 was created and in this version the Regions time of its parent real version.
level was added, new dimension members were inserted to this
level, and existing cities were classified according to regions. Let VTr = <ta, tb> be a valid time of real version Vr and VTa =
Next, an alternative version V1.1 was derived from V1. In V1.1, <tc, td> be a validity time of alternative version Va.
"Violation 2" was moved from "Group A" to "Group B", as
∀ (Vr, Va) in DWV: Vr Î Va then VTa ⊆ VTr
discussed in Section 3. Then, alternative version V1.1.1 was
derived from V1.1 and this newly derived version "City 2" was This constraint is illustrated in Figure 4. Two alternative versions
moved from "Region North" to "Region South". V1 is also the V1.1 and V1.2 were derived from real version V1. Valid time of
parent version for another alternative version V1.2, which V1.1 is <t2, t5> and valid time of V1.2 is <t3, t6>, and both valid
simulates the case when minimum fine of violation group "Group times are within the scope of valid time of V1.
A" was increased by 10%. Note that the data warehouse schemas
of V1.1, V1.2, and V1.1.1 are the same and are identical with their TC3: Alternative Parent–Child Versions Valid Time
parent version V1. Constraint
A valid time of a child alternative DW version is within a valid
time of its direct parent version.
5.2 Time Constraints on Versions
Every version is valid within certain period of time. In order to Let VTy = <ta, tb> be a valid time of alternative version Vy and
check a version validity, every real and alternative DW version VTz = <tc, td> be a valid time of alternative version Vz.
has associated, so called valid time, represented by two
timestamps, i.e. beginning valid time (BVT) and ending valid time ∀ (Vy, Vz) in DWV: Vy Î Vz then VTz ⊆ VTy

721
This constraint is illustrated in Figure 4. A child alternative Let us also assume that another real DW version, i.e. V2, was
version V1.1.1 was derived from its parent alternative version derived from V1 and a new dimension Policemen was added.
V1.1. Valid time of V1.1.1 is <t2, t4> and valid time of V1.1 is <t2, After such a change records from the Inspected_Violations
t5>, where t5>t4. (version V1) table can not be shared by V2. In a consequence, a
new Inspected_Violations (version V2) table is created at the
From this constraint we can deduce that valid times of alternative implementation level for storing records loaded into version V2.
DW versions at the same level of the version derivation hierarchy
may overlap. It allow to represent alternative versions valid at the On the one hand, physical sharing reduces storage overhead, but
same time, while constraints TC2 and TC3 hold. on the other hand it slows down query processing. This is a trade
off between disk storage and good query performance. In the
Let VTy = <ta, tb> be a valid time of alternative version Vy, VTz = process of a DW tuning (in order to increase query performance),
<tc, td> be a valid time of alternative version Vz, and Vx be a a DW administrator may give up the physical sharing of data
parent alternative version, where Vx Î Vy and Vx Î Vz. between, say parent version Vm and child version Vn, and may
∀ (Vy, Vz) in DWV: (VTy ∩ VTz ≠ ∅ or VTy ∩ VTz = ∅) and decide to create the physical copy of data in version Vn. To this
(TC2 and TC3 hold). end, in our prototype we are implementing a dump version
operation.
According to the above observation, two alternative versions at
the same level of derivation hierarchy are presented, i.e. V1.1 and In order to reduce the number of existing alternative versions, by
V1.2. The valid time of V1.1 is <t2, t5> whereas the valid time of default our system automatically removes all alternative DW
V1.2 is <t3, t6>. In this case valid times of both versions overlap at versions derived from version Vm when a new real version is
<t3, t5>, additionally, constraint TC2 holds as valid times of both derived from Vm. It is because those alternative versions become
alternative child versions are within the valid time of their parent obsolete when a new real DW version is created. A decision
real version V1. maker can however mark any alternative version persistent,
preventing it from removal while deriving a new real version.
5.3 Data Sharing between Versions of a Data
Warehouse 6. PROTOTYPE MULTIVERSION DATA
A naive approach to dealing with versions of data consists in WAREHOUSE
storing a physical copy of data in every DW version. As the size The model of a multiversion data warehouse presented in Section
of data warehouses is of terabytes, this approach is not suitable. 5 is currently being implemented as a prototype multiversion data
Therefore, in our prototype system we are implementing data warehouse management system. The beta version of this prototype
sharing technique, that is sketched in this section. This technique was implemented in Visual C++, whereas data and metadata are
consists in physically storing in a given DW version only those stored in an Oracle database. The main management window of
data that were changed in a given version or are new. Other data, our software is shown in Figure 5. It is composed of a version
common to a parent and its child versions are stored only in the navigator, located at the left hand side and schema viewer, located
parent version and are shared by its child versions. at the right hand side. The schema viewer allows to among others:
(1) inspect the version derivation graph, (2) see the content of
For the data sharing purpose every record, in a fact or a level every version, and (3) administrate versions. Whereas the schema
table, has attached the information about all DW versions this viewer graphically presents the schema of a selected version.
record belongs to. At the implementation level, the information
about all versions a given record belongs to is represented in the In the current implementation, a version of a data warehouse
set of bitmaps, where one bitmap represents one DW version. The schema can be modified by means of 12 operations [21]: creating
number of bits in a bitmap equals to the number of records in a a new dimension, removing a dimension, creating a new level,
given table. The ith bit in a bitmap, describing version Vm, is set to connecting a level into a dimension, disconnecting a level from a
1 if the ith record in a table, in DW version Vm, exists in this dimension, removing a level from a schema, creating a new
version. Otherwise the bit is set to 0. attribute for a level, removing an attribute from a level, creating a
new fact table, creating a new attribute for a fact table, creating an
As an simplified example illustrating our data sharing technique association between a fact table and a dimension, removing an
let us consider the content of the Inspected_Violations table (from attribute from a fact table, removing an association between a fact
Section 3), as shown below. Initially this table exists in version table and a dimension, removing a fact table from a schema.
V1. Let us further assume that the alternative version V1.1 was
derived from V1, as discussed earlier in the paper. The change in In addition to the above 12 schema modification operations, our
V1.1 concerned moving "Violation 2" from "Group A" to "Group prototype supports 3 operations that change the structure of
B". In this case, original records from V1 are shared also by V1.1. dimensions: (1) inserting a new dimension member into a given
To this end a new bitmap describing version V1.1 is added to the level, (2) deleting a dimension member from a given level, (3)
table, as shown below. changing the association of a sublevel dimension member to
another super–level member.
Inspected_Violations (version V1)

TIME_ID VIOL_ID CITY_ID NB_OF_VIOL TOTAL_FINE V1 V1.1

------- ------- ------- ---------- ---------- ----- -----
7. SUMMARY, CONCLUSIONS AND
1 1 1 10 650 1 1 FUTURE WORK
1 2 1 25 900 1 1
1 3 2 15 3200 1 1 Commercial DW systems existing on the market have static
1 1 3 20 2000 1 1 structure of their schemas and relationships between data. In a
consequence, they are not well suited for handling of any changes

722
that occurs in the real world. A novel approach to this problem is Conference, Germany, 2001
based on a multiversion data warehouse. [8] Eder, J., Koncilia, C., Morzy, T.: The COMET Metamodel
In this paper we presented the concept of a multiversion data for Temporal Data Warehouses. Proc. of the CAISE'02
warehouse, types of versions needed in such a warehouse, and we Conference, Canada, 2002
defined inter-version time integrity constraints. A unique feature [9] Hurtado, C.A., Mendelzon, A.O.: Vaisman, A.A.:
of our model of a multiversion DW is its ability to represent Maintaining Data Cubes under Dimension Updates. Proc. of
alternative versions of a data warehouse (required for the what-if the ICDE Conference, Australia, 1999
analysis) as well as physical separation of different DW versions. [10] Hurtado, C.A., Mendelzon, A.O.: Vaisman, A.A.: Updating
We predict that on the one hand, queries spanning several versions OLAP Dimensions. Proc. of the DOLAP Workshop, 1999
will run faster than in other approaches, discussed in Section 4, as
DW versions are physically stored, thus, no dynamic data [11] Jarke, M., Lenzerini, M., Vassiliou, Y., Vassiliadis, P.:
conversions are required. But on the other hand, the complexity of Fundamentals of Data Warehouses. Springer-Verlag, 2000,
DW metamodel reflecting versions and sharing common elements ISBN 3-540-65365-1
as well as data will incur time overhead for processing queries [12] Kang, H.G., Chung, C.W.: Exploiting Versions for On–line
spanning several versions. Our concept is currently being Data Warehouse Maintenance in MOLAP Servers. Proc. of
implemented as a prototype software. The first beta version of our the VLDB Conference, China, 2002
prototype supports the management of versions of a data [13] Koeller, A., Rundensteiner, E.A., Hachem, N.: Integrating
warehouse schema. Current work focuses on physical sharing of the Rewriting and Ranking Phases of View Synchronization.
data between several DW versions. Future work will concentrate Proc. of the DOLAP Workshop, USA, 1998
on: (1) developing a multiversion query language capable of
[14] Kulkarni, S., Mohania, M.: Concurrent Maintenance of
processing data from several DW versions, (2) developing new
Views Using Multiple Versions. Proc. of the Intern. Database
mechanisms of indexing multiversion data, (3) developing a
Engineering and Application Symposium, 1999
model of transactions for a multiversion DW, (4) experimental
evaluation of schema and data management techniques as well as [15] Mendelzon, A.O., Vaisman, A.A.: Temporal Queries in
efficiency of processing queries addressing several DW versions. OLAP. Proc. of the VLDB Conference, Egypt, 2000
[16] Morzy, T., Wrembel, R.: Modeling a Multiversion Data
Warehouse: A Formal Approach. Proc. of the Int. Conf. on
Enterprise Information Systems - ICESI'2003, France, 2003
[17] Quass, D., Widom, J.: On–Line Warehouse View
Maintenance. Proc. of the SIGMOD Conference, 1997
[18] Roddick J.: A Survey of Schema Versioning Issues for
Database Systems. In Information and Software Technology,
volume 37(7):383-393, 1996
[19] Rundensteiner E., Koeller A., and Zhang X.: Maintaining
Data Warehouses over Changing Information Sources.
Communications of the ACM, vol. 43, No. 6, 2000
[20] Sjøberg D.: Quantifying Schema Evolution. Information
Fig.5. The main management window of the prototype
Software Technology 35, 1, 35-54, 1993
multiversion data warehouse system
[21] Wrembel, R. Bębel B.: Schema Management in a
Multiversion Data Warehouse. Submitted to the First Special
8. REFERENCES Interest Symposium on Data Warehousing and Data Mining,
[1] Balmin, A., Papadimitriou, T., Papakonstanitnou, Y.: Germany, July, 2003
Hypothetical Queries in an OLAP Environment. Proc. of the
[22] SAP America, Inc. and SAP AG. Data Modelling with BW -
VLDB Conf., Egypt, 2000
ASAP for BW Accelerator. 1998. http://www.sap.com
[2] Bellahsene, Z.: View Adaptation in Data Warehousing
[23] Agrawal, R., Buroff, S., Gehani, N., Shasha, D. (1991).
Systems. Proc. of the DEXA Conf., 1998
Object Versioning in Ode. Proc. of the ICDE Conference
[3] Blaschka, M. Sapia, C., Hofling, G.: On Schema Evolution in
[24] Ahmed-Nacer M., Estublier J.: Schema Evolution in
Multidimensional Databases. Proc. of the DaWak99
Software Engineering. In: Databases – A new Approach in
Conference, Italy, 1999
ADELE environment. Computers and Artificial Intelligence,
[4] Body, M., Miquel, M., Bédard, Y., Tchounikine A.: A 19:183-203, 2000
Multidimensional and Multiversion Structure for OLAP
[25] Bielikova M., Navrat P.: Modelling Versioned Hypertext
Applications. Proc. of the DOLAP'2002 Conf., USA, 2002
Documents. Proc. of the ECOOP´98, SCM-8 Symposium,
[5] Chamoni, P., Stock, S.: Temporal Structures in Data Belgium, 1998
Warehousing. Proc. of the Data Warehousing and
[26] Cellary, W., Jomier, G. (1990). Consistency of Versions in
Knowledge Discovery DaWaK, Italy, 1999
Object-Oriented Databases. Proc. of the VLDB Conference
[6] Chaudhuri, S., Dayal, U.: An overview of data warehousing
[27] Kim, W., Chou, H. (1998). Versions of Schema for Object-
and OLAP technology. SIGMOD Record, 26, 1997
Oriented Databases. Proc. of the VLDB Conference
[7] Eder, J., Koncilia, C.: Changes of Dimension Data in
Temporal Data Warehouses. Proc. of the DaWak 2001

723