MODELING A MULTIVERSION DATA WAREHOUSE: A FORMAL APPROACH *

MODELING A MULTIVERSION DATA WAREHOUSE: A FORMAL APPROACH* Tadeusz Morzy, Robert Wrembel Institute of Computing Science, Poznań University of Technolo...
Author: Avis Simmons
4 downloads 0 Views 355KB Size
MODELING A MULTIVERSION DATA WAREHOUSE: A FORMAL APPROACH* Tadeusz Morzy, Robert Wrembel Institute of Computing Science, Poznań University of Technology, Poznań, Poland Email: [email protected], [email protected]

Keywords:

data warehouse, schema evolution, versioning

Abstract:

A data warehouse is a large centralized repository that stores a collection of data integrated from external data sources (EDSs). The purpose of building a data warehouse is among others: to provide an integrated access to distributed and usually heterogeneous information, to provide a platform for data analysis and decision making. EDSs are autonomous in most of the cases. In a consequence, their content and structure change in time. In order to keep the content of a data warehouse up to date, after source data changed, various warehouse refreshing techniques have been developed, mainly based on an incremental view maintenance. A data warehouse will also need refreshing after a schema of an EDS changed. This problem has, however, received little attention so far. Few approaches have been proposed and they tackle the problem by using mainly temporal extensions to a data warehouse. Such techniques expose their limitations in multi–period querying. Moreover, in order to support predictions of trends by decision makers, the what– if analysis is often required. For these purposes, multiversion data warehouses seem to be very promising. In this paper we propose a model of a multiversion data warehouse, and show our prototype implementation of such a multiversion data warehouse.

1

INTRODUCTION

Enterprises, institutions, companies collect their data in various formats and systems (e.g. relational, object-relational, and object-oriented databases, online multimedia data stores, Web pages, spreadsheets, flat files). Moreover, data are often geographically distributed. In order to take strategic decisions, these various data must be accessed and analyzed by managers. Therefore, the ability to integrate information from different, autonomous and heterogeneous data sources is crucial for today's business. One of the basic approaches to integrate external data sources and to provide integrated information to users is a data warehousing approach (Chaudhri, Dayal, 1997). In this approach, data of interests coming from external sources are extracted, filtered, merged, and stored in a central repository, called a data warehouse (DW). Data are also enriched by historical and summary information. Then, queries are issued for this data warehouse. The advantages of a data warehousing approach are as follows: (1) queries operate on a local centralized data *

repository, that reduces access time to data, (2) queries need not be decomposed into different formats and their results need not be integrated, (3) a data warehouse is independent of its data sources which may be temporarily unavailable, (4) local processing at local sources is not affected by global applications running on a DW, and (5) the structure of a DW is usually optimized for specific analytical data processing. Due to its properties, a data warehousing approach has been found to be an extremely useful technology for information integration for large and medium companies requiring high query performance and high data availability (Chaudhri, Dayal, 1997), (Jarke et al. 2000). A data warehouse is the source of information for so called On–Line Analytical Processing (OLAP) as well as for data mining. Research in the data warehousing area has been focusing mainly on design issues, data refreshing strategies, query optimization, and data structures. However, one important research issue has received little attention so far, i.e. the evolution of a data warehouse schema. The problem is related to dynamicity of external data sources (EDSs). A DW

This work is supported by the grant no. 4 T11C 019 23 from the Polish State Committee for Scientific Research (KBN), Poland

integrates autonomous and heterogeneous external data sources. The main feature of EDSs that makes the integration process difficult is their autonomy. Autonomy means that the external data sources were designed and developed independently, and that they have an independent control over their data. An important consequence of the autonomy of EDSs is that they may evolve in time independently of each other and of a data warehouse. The evolution of an EDS comprises not only changes in its content, i.e. data, but also its schema. When an EDS changes its content, these changes have to be propagated to a data warehouse to ensure that the DW is kept up to date. However, the content of a data warehouse may become obsolete also because a schema of an EDS changed. Therefore, there is evidently a need to analyze and study the propagation of EDS schema changes to data warehouse systems and to manage that changes at a DW. A few examples of changes in real world environment that have impact on the structure and content of a data warehouse may include: 1. the unification of East and West Germany; 2. the separation of several countries from the former Soviet Union; 3. changing geographic borders of provinces in Poland and creating new administrative entities within those provinces; 4. accessing the European Union by new countries. Such changes in an administrative organization of the country have impact on various economic analyses spanning periods before and after the changes (e.g., comparing total number of inhabitants per region/country, comparing the state revenue). The problem is similar to a schema evolution or database versioning in object-oriented databases, e.g. (Kim, Chou, 1988), (Cellary, Jomier, 1990), (Fernandina et al., 1994), (Abdesallem, Jomier, 1997). In the context of a data warehousing, however, it has received little attention so far. Most of the existing approaches use temporal extensions to a data warehouse to store changes in the structure of a data warehouse, e.g. (Chamoni, Stock, 1999), (Mendelzon, Vaisman, 2000), (Yang, Widom, 2000), (Eder, Koncilia, 2001a). The main disadvantage of these approaches is that they do not allow to model alternative versions of a data warehouse, that are required for the what–if analysis within a decision making process. Moreover, queries spanning more than one temporal version need data conversions from one data format valid at time, say, t1 to another format, valid at t2. Our approach to this problem is based on explicit versioning a data warehouse schema and data. Changes in a data warehouse structure and data are reflected in a new, explicitly derived version of a

schema and data consistent with this version of a schema. The model of a multiversion data warehouse proposed in this paper allows modeling alternative versions of the whole data warehouse and it supports data conversions between various versions. Having converted a set of data originating from one version, this set can be persistently stored in another version. Thus, queries spanning multiple versions operate on persistent data. The rest of this paper is organized as follows. Section 2 presents basic concepts concerning the data warehouse technology. Section 3 overviews existing approaches to schema evolution and versioning in databases as well as in data warehouses. Section 4 presents a formal model of a multiversion data warehouse. Section 5 overviews our prototype multiversion data warehouse system, and finally, Section 6 summarizes and concludes the paper.

2

BASIC CONCEPTS

A data warehouse system typically uses a multidimensional data model (Chaudhuri, Dayal, 1997), (Husemann, 2000). In this model, data are organized in n–dimensional cubes. Each cube contains so called measure attributes as well as dimension attributes. Examples of measures include: number of items sold, income, number of elements controlled. A value of a measure in a cube depends on a value of each dimension in that cube. One of typical cube examples includes three dimensions: Time, Salesperson, and Product. Whereas a measure may include sale in dollars. Thus, one can easily analyze sales by a given salesperson, of a given product, in a given period of time. Dimensions are often organized in hierarchies. One of typical examples of hierarchical dimension is Location, with Country at the top, Region – being a child of Country, City – being a child of Country, and District at the bottom of the hierarchy. A n–dimensional cube can be implemented either in MOLAP servers or in ROLAP servers. In the former case, a cube is stored in multidimensional array. In the latter case, a cube is implemented as a set of relational tables, some of them represent dimensions, and are called dimension tables, while others store values of measures, and are called fact tables. Three typical ROLAP schemas are used for an implementation of a cube, i.e. star schema (Chaudhuri, Dayal, 1997), snowflake schema (Chaudhuri, Dayal, 1997), and fact constellation schema (Teste, 2001). In a star schema, a fact table is connected to its dimensions, that are flat, i.e. have only one level. In a snowflake schema, a fact table is

connected to its dimensions, that are explicitly organized in hierarchies. In a fact constellation schema, flat or hierarchical dimensions are shared between several fact tables. An architecture of a DW usually includes so called data marts (Jarke et al. 2000). A data mart (DM) is a small data warehouse that contains only a subset of data coming from a central DW. The content of a DM represents information from a given domain of interest, e.g. a DM for marketing will contain information about customers, their purchase history, and promotions. A DM enables faster analysis as it contains less amount of data, which usually are highly aggregated. In data warehousing systems data are explored by means of complex queries containing from a few to dozens operations of joining, filtering, grouping, and aggregating. They are, so called On–Line Analytical Processing (OLAP) queries. In order to make good management decisions, decidents often run so called what-if analyses. In such an analysis, a user simulates changes in a real world environment by changing the structure and content of a data warehouse or a data mart.

3

RELATED WORK

The support of evolution of schema and data turned up to be required in the applications of object–oriented databases to Computer Aided Design, Engineering, and Manufacture systems. The problem was intensively investigated and resulted in the development of various approaches and prototypes, e.g. (Kim, Chou 1988), (Cellay, Jomier, 1990), (Agrawal et al., 1991), (Fernandina, 1994), (Monk, Somerville, 1993), (Andonoff, 1998), (Franconi et al., 2000). Similarly, the concept of temporal databases was intensively investigated and resulted in the development of various concepts and systems, e.g. (Böhlen, 1995), (Gorawalla et al., 1995). The support of changes in a data warehouse was studied in the three following areas: (1) schema and data evolution: (Koeller, 1998), (Blaschka, 1999), (2) temporal extensions: (Chamoni, Stock, 1999), (Huarto, 1999a), (Huarto, 1999b), (Mendelzon, Vaisman, 2000), (Eder, Koncilia, 2001a), (Eder, Koncilia, 2001b), (Eder et al., 2002), and (3) versioning (Quass, Widom, 1997), (Teschke, Ulbrich, 1998), (Kulkarni, Mohania, 1999), (Kang, Chung, 2002), (Balmin et al., 2000), (Body et al., 2002), (Bellahsene, 1998). In (Koeller et al., 1998), a DW is implemented as a set of materialized views. When a schema of a data source changes, a view is rewritten. (Blaschka,

1999) presents a schema evolution algebra for a multidimensional data warehouse schema and its instance. However, it is unclear how data are converted along with schema modifications and how to define conversion methods. Both of these approaches support only one data warehouse schema and its instance, that are constantly converted as a result of modifications. (Chamoni, Stock, 1999) consider changes in a structure of a data cube and propose time stamping as a method of storing information about consistent structures at a given time. However, the paper does not give any information on how to navigate through such a temporal cube and how to deal with fact data. In (Yang, Widom, 2000), temporal views and a temporal query language are proposed in order to solve the problem of view self maintainability. Nonetheless, the approach does not consider changes in a source schema and a data warehouse schema. (Huarto et al, 1999a) and (Huarto et al., 1999b) present a formal model of a multidimensional data warehouse supporting dimension updates and the set of operators and their taxonomy. (Mendelzon, Vaisman, 2000) present formally a temporal query language. However, the authors do not consider relationships between temporal versions and the proposed technique does not support transformations of data from one temporal version to another. Moreover, the limitation of the proposed temporal query language is its inability to express queries spanning or comparing more than two temporal versions of data. In (Eder, Koncilia, 2001a), (Eder, Koncilia, 2001b), (Eder et al., 2002) a formal model and a prototype of a temporal data warehouse system is discussed. The prototype, supports changes in a data warehouse schema and changes in data warehouse content. From a user's point of view such a temporal data warehouse is perceived as a set of so called structure versions, each of which being a view on a DW schema and its data, valid for a given time interval. Every change to a DW structure results in creating a new structure version. Users can execute queries for a particular structure version or queries that span several versions. In the latter case, conversion functions are applied. Implicit versioning in a data warehouse was proposed in (Quass, Widom 1997), (Teschke, Ulbrich, 1998), (Kulkarni, Mohania, 1999), (Kang, Chung, 2002). In all of the four approaches versions are used for avoiding conflicts and mutual locking between OLAP queries and transactions refreshing a data warehouse. As versions are implicitly created and managed by the system, these mechanisms can not be used in the what–if analysis. The same drawback applies to previously discussed temporal data warehouses that

can manage only consecutive versions ordered by time. Moreover, if a user will issue a query over several temporal versions of a warehouse, data from one version will have to be dynamically transformed to another adjacent version. For long lasting OLAP queries such a solution may not be acceptable. On the contrary, (Bellahsene, 1998) proposes permanent user defined versions of views in order to simulate changes in a data warehouse schema. However, the approach supports only simple changes in source tables and it does not deal either with typical multidimensional schemas or evolution of facts or dimensions. An approach supporting the what–if analysis was presented in (Balmin et al., 2000). It may be considered as a kind of virtual versioning approach, thus it differs entirely from the previously discussed concepts. A hypothetical query is executed on a virtual structure, called scenario. Then, the system using substitution and query rewriting techniques transforms the hypothetical query into an equivalent query that is run on a real data warehouse. As this technique computes new values of data for every hypothetical query, based on virtual modifications, the performance problems may appear for large warehouses.

4 MULTIVERSION DATA WAREHOUSE MODEL In order to be able to manage changes in a data warehouse schema we developed the model of a data warehouse with versioning capabilities. In our approach, changes to a schema may be applied in a new version of a data warehouse. This version is explicitly derived by a warehouse administrator from any previous version. Versions of a data warehouse form a version derivation graph. Each node of this graph represents one version, whereas edges represent derived–from relationship between two consecutive versions. In our approach a version derivation graph may be a DAG.

4.1 Multiversion data warehouse A multiversion data warehouse (MVDW) is composed of a set of its versions. Formally, a MVDW is defined as: MVDW = < dw_id, dw_name, MVDWS, S, MVDWI, DWS¨DWI, CM > where dw_id and dw_name are the identifier and name of a data warehouse, respectively;

MVDWS is the set of data warehouse schema versions (DWSV1, ..., DWSVi); MVDWS = S is the set of parent-child dependencies between data warehouse schema versions where one child version, say DWSj was derived from one parent version, say DWSi; MVDWI is the set of data warehouse instances (DWIV1, ..., DWIVi), each of which is consistent with a given version of a data warehouse schema; MVDWI = DWS¨DWI represents an assignment of a given version of a data warehouse instance to a given version of a DW schema; CM is the set of, so called conversion methods, applied at the level of a schema instance. These methods convert data from one parent schema version to another – direct child schema version. Every version of a data warehouse (DWV) is assigned a unique identifier (dwv_idi) and a user– given name (v_namei). A DWV is composed of a version of a schema (DWSVi) and a version of an instance (DWIVi) consistent with its schema version. Formally it is defined as follows: ∀(i=1, ..., n) DWVi ∈ DWV, DWVi = < dwv_idi, v_namei, DWSVi, DWIVi >

4.2 DW schema version A data warehouse schema version (DWSVi) is composed of the following elements of the model. The set of data warehouse version identifiers VID. Each version identifier dwv_idi belongs to VID, i.e. ∀(i=1, ..., n) dwv_idi ∈ VID The set of dimension versions: DV = {DV1, DV2, …, DVn}. ∀ DVi (i=1, …, n)∈ DV, DVi = d_idi is a dimension identifier, d_name is a dimension name, and dwv_idi is a data warehouse version identifier. The set of levels: LV = {LV1, LV2, …, LVn} ∀ LVi (i=1, …, n)∈ LV, LVi = l_id id an identifier of a level, l_name is its name, dwv_idi is a data warehouse version identifier, Z is a partial order on levels in LV, such that if LV1 and LV2 ∈ LV and LV2ZLV1 then does not exist LVj such that LV2 Z LVj Z LV1.

For a given level LVl function super_levelV returns a set of its super–levels in a given version of a data warehouse. ∀ LVl (l=1, …, n)∈ LV and ∀ dwv_idp (p=1, …, n)∈ VID, super_levelV(LVl, dwv_idp) = {LVk} | LVk ∈ LV and ∀ LVl , LViZLVk The set of level assignments to dimensions: LVfDV = {LV1fDV1, …, LVmfDVn} ∀ LVifDVj (i=1, …, n)(j=1, ..., m)∈ LVfDV, LVifDVj = {LVmfDVj, LVnfDVj, ..., LVrfDVj} Function dimension_levelsV returns a set of levels assigned to a given dimension DVj in a given data warehouse version. ∀ LVifDVj (i=1, …, n)(j=1, ..., m)∈ LVfDV and ∀ dwv_idp (p=1, …, n)∈ VID, dimension_levelsV(DVj, dwv_idi) = {LVk}(k=1, ..., q) | LVk ∈ L The set of attributes: A = {A1, A2, …, An} ∀ Ai (i=1, …, n)∈ A, Ai = a_id, a_name, and a_type are an identifier, name, and type of an attribute, respectively. The set of attribute assignments to levels: AfLV = {A1fLV1, …, AmfLVn} ∀ AifLVj (i=1, …, n)(j=1, ..., m)∈ AfLV, AifLVj = {AmfLVj, AnfLVj, ..., ArfLVj} Function level_atrributesV returns a set of attributes assigned to a given level LVj in a given data warehouse version. ∀ AifLVj (i=1, …, n)(j=1, ..., m)∈ AfLV and ∀ dwv_idp (p=1, …, n)∈ VID level_attributesV(Lj, dwv_idi) = {Ak}(k=1, ..., q) | Ak ∈ A The set of fact tables: FV = {FV1, FV2, …, FVn} ∀ FVi (i=1, …, n)∈ FV, FVi = f_id is an identifier of a fact table, f_name is its name, and dwv_idi is a data warehouse version identifier. The set of attribute assignments to fact tables: AfFV = {A1fFV1, …, AmfFVn} ∀ AifFVj (i=1, …, n)(j=1, ..., m)∈ AfFV, AifFVj = {AmfFVj, AnfFVj, ..., ArfFVj} Function fact_attr_assocV returns a set of attributes assigned to a fact FVj in a given data warehouse version. ∀ AifFVj (i=1, …, n)(j=1, ..., m)∈ AfFV and ∀ dwv_idp (p=1, …, n)∈ VID fact_attr_assocV(Fj, dwv_idp) = {Ak}(k=1, ..., q) | Ak ∈ A

The set of associations between fact tables and dimensions: FV¨DV = {FV1¨DV1, …, FVmfDVn} ∀ FVi¨DVj (i=1, …, n)(j=1, ..., m)∈ FV¨DV, FVi¨DVj = {FVm¨DVj, FVn¨DVj, ..., FVr¨DVj} The function fact_dim_assocV returns a set of attributes assigned to a fact Fj that associate Fj with its dimensions. These attributes come from appropriate levels of that dimension in a given data warehouse version. ∀ FVi¨DVj (i=1, …, n)(j=1, ..., m)∈ FV¨DV and ∀ dwv_idp (p=1, …, n)∈ VID fact_dim_assocV(Fj, dwv_idp) = {Ak} | Ak ∈ level_attributes(dimension_levels(Dj, dwv_idp)) Having defined the above elements of a multiversion data warehouse model let us define a version of a DW schema. A versions of a data warehouse schema is defined as a record of ten previously defined elements: ∀ DWSVi (i=1, …, n) ∈ MVDWS and ∀ dwv_idi (i=1, …, n)∈ VID DWSVi =

4.2 DW instance version The above multiversion data warehouse schema describes the structure of data. A set of data conforming to a given DW schema version is called a DW instance version (DWIV). Its formal model is composed of the elements described below. The set of multiversion record identifiers MVRID. MVRID = {mvrid1, mvrid2, …, mvridn} The set of multiversion records, each of which has a unique identifier (mvrid) and a set of its versions. For every version of a data warehouse dwv_idi function rValueV returns the set of values of records in this DW version, i.e. ∀ mvridi (i=1, …, n) ∈ MVRID and ∀ dwv_idi (i=1, …, n)∈ VID rValueV (dwv_idi) = {v} | v ∈ VAL where VAL is the set of values, each of which corresponds to a given record version in MVRID. The levelAssignmentV function, that assigns a set of multiversion record identifiers to levels in that DW version. ∀(i=1, ..., n) LVi ∈ LV, ∀ dwv_idi (i=1, …, n)∈ VID

levelAssignmentV(dwv_idi) = { mvridi } | mvridi ∈ MVRID For every multiversion level LVi and for every data warehouse version dwv_idi, function vlevel_recV returns the set of records assigned to that version of the level. ∀(i=1, ..., n) LVi ∈ LV, ∀ dwv_idi (i=1, …, n)∈ VID vlevel_recV(LVi, dwv_idi) = { rvj } | rvj ∈ RV where RV is the set of record versions. The factAssignmentV function, that assigns a set of multiversion record identifiers to multiversion fact tables in that DW version. ∀(i=1, ..., n) FVi ∈ FV, ∀ dwv_idi (i=1, …, n)∈ VID factAssignmentV(dwv_idi) = { mvridi } | mvridi ∈ MVRID For every multiversion fact table FVi and for every data warehouse version dwv_idi, function vfact_recV returns the set of records assigned to that version of the fact table. ∀(i=1, ..., n) FVi ∈ FV, ∀ dwv_idi (i=1, …, n)∈ VID vfact_recV(FVi, dwv_idi) = { rvj } | rvj ∈ RV The set of record identifiers MVRID contains the values of records assigned to dimensions as well as facts, i.e. MVRID = ∪ i=1i=n { levelAssignmentV(LVi) | LVi ∈ LF } ∪ { factAssignmentV(FVi) | FVi ∈ FV }

Having defined the above elements of a multiversion data model let us define a version of a DW instance. A version of a data warehouse instance is a record of five elements: DWIVi =

5 PROTOTYPE MULTIVERSION DATA WAREHOUSE MANAGEMENT SYSTEM The model of a multiversion data warehouse presented in Section 3 is currently being implemented in a prototype multiversion data warehouse management system. The beta version of this prototype is briefly presented in this section. A data warehouse administration tool was implemented in Visual C++, whereas data and metadata are stored in an Oracle database. The main management window of our prototype is shown in Figure 1. It is composed of a version navigator, located at the left hand side and schema viewer, located at the right hand side.

Figure 1: The main management window of the prototype

Our system supports among others: (1) derivation of a new version of a data warehouse schema from a selected version, cf. Figure 2, (2) adding, deleting, and modifying attributes of fact as well as dimension tables, c.f. Figure 3, (3) adding and removing dimension records, and (4) presenting schema version derivation graph.

Figure 2: Creating a new version of a data warehouse

Current implementation does not support the management of data warehouse instance versions but the prototype is currently under development and that feature will be added soon.

6 SUMMARY, CONCLUSIONS, AND FUTURE WORK In this paper we presented a formal model of a multiversion data warehouse, which to the best of our knowledge, has not been discussed previously in research publications. Moreover, our model is currently being implemented as a prototype multiversion data warehouse management system. The first beta version of our prototype supports the management of versions of a data warehouse schema and it will be extended soon with the support of versioning data. In our opinion, the support of versions of a data warehouse is required for the three following

reasons. Firstly, alternative DW versions allow us to perform various what–if analyses. Secondly, by maintaining versions of data, queries spanning several versions will run on them much faster than those running on temporal data, because in the latter case data need dynamic conversions. Finally, versions may reduce conflicts between OLAP queries run by end users and transactions keeping a warehouse up to date. As it concerns the impact of our versioning mechanism on a DW performance there are two aspects. On the one hand, our system explicitly stores data in every version of a DW. Therefore, version spanning queries will not be burdened with data conversions. On the other hand, our current implementation does not support sharing of unchanged data between several versions. In a consequence there is data redundancy. We plan to incorporate data sharing in future release of the prototype. In this case, the system will have to find all the relevant data for a given DW version, that may be possibly stored in another version. This searching will result in slower query performance. Future experiments will show the time overhead. As the domain of multiversion data warehouses is just emerging, there are many other open issues including among others: • the analysis and development of inter– and intra–version integrity constraints; • the development of a query language able to span, work on, and compare data from multiple versions of a data warehouse; • the development of new data structures for efficient storing and indexing multiversion data and their experimental evaluation; • the analysis and development of the concept of a transaction in the context of a multiversion data warehouse.

Figure 3: Creating a dimension or a fact table

REFERENCES Abdessalem, T., Jomier, G. (1997). VQL: A Query Language for Multiversion Databases. Proc. of the 6th Int. on Workshop Database Programming Languages (DBPL), USA, LNCS 1369. Agrawal, R., Buroff, S., Gehani, N., Shasha, D. (1991). Object Versioning in Ode. Proc. of the ICDE Conf. Al-Jadir, L., Falquet, G., Leonard, M. (1993). Context Versions in an Object-Oriented Model. Proc. of the DEXA Conf. Andonoff, E., Hubert, G., le Parc, A. (1998). A Database Interface Integrating a Query Language for Versions. Proc. of the East-European Conference on Advances in Databases and Information Systems (ADBIS), Poland. Balmin, A., Papadimitriou, T., Papakonstanitnou, Y. (2000). Hypothetical Queries in an OLAP Environment. Proc. of the VLDB Conf., Egypt. Bellahsene, Z. (1998). View Adaptation in Data Warehousing Systems. Proc. of the DEXA Conf. Blaschka, M. Sapia, C., Hofling, G. (1999). On Schema Evolution in Multidimensional Databases. Proc. of the DaWak99 Conference, Italy. Böhlen, M. (1995) Temporal Database System Implementations. SIGMOD Record, 24. Cellary, W., Jomier, G. (1990). Consistency of Versions in Object-Oriented Databases. Proc. of the VLDB Conference. Chamoni, P., Stock, S. (1999). Temporal Structures in Data Warehousing. Proc. of the Data Warehousing and Knowledge Discovery DaWaK, Italy. Chaudhuri, S., Dayal, U. (1997) An overview of data warehousing and OLAP technology. SIGMOD Record, 26. Eder, J., Koncilia, C., Morzy, T. (2001a). A Model for a Temporal Data Warehouse. Proc. of the Int. OESSEO 2001 Conference, Italy. Eder, J., Koncilia, C. (2001b). Changes of Dimension Data in Temporal Data Warehouses. Proc. of the DaWak 2001 Conference, Germany. Eder, J., Koncilia, C., Morzy, T. (2002). The COMET Metamodel for Temporal Data Warehouses. Proc. of the 14th Int. Conference on Advanced Information Systems Engineering (CAISE'02), Canada. Fernandina, F., Meyer, T., Zicari, R. (1994). Implementing Lazy Database Updates for an Object Database System. Proc. of the VLDB Conference. Franconi, E., Grandi, F., Mandreoli, F. (2000). Schema Evolution and Versioning: a Logical and Computational Characterisation. Proc. of the 9th Int. Workshop on Foundations of Models and Languages for Data and Objects ( FoMLaDO/DEMM), Germany, LNCS 2065. Gorawalla, I., Tansel, A., Özsu, M. (1995). Experimenting with Temporal Relational Databases. Proc. of the CIKM Conf., USA.

Huarto, C.A., Mendelzon, A.O.: Vaisman, A.A. (1999a). Maintaining Data Cubes under Dimension Updates. Proc. of the ICDE Conference, Australia. Huarto, C.A., Mendelzon, A.O.: Vaisman, A.A. (1999b). Updating OLAP Dimensions. Proc. of the DOLAP Conference. Husemann, B., Lechtenborger, J., Vossen, G. (2000). Conceptual Data Warehouse Design. Proc. of the International Workshop on Design and Management of Data Warehouses (DMDW 2000), Sweden. Jarke, M., Lenzerini, M., Vassiliou, Y., Vassiliadis, P. (2000). Fundamentals of Data Warehouses. SpringerVerlag, ISBN 3-540-65365-1. Kang, H.G., Chung, C.W.: (2002). Exploiting Versions for On–line Data Warehouse Maintenance in MOLAP Servers. Proc. of the VLDB Conference, China. Kim, W., Chou, H. (1998). Versions of Schema for Object-Oriented Databases. Proc. of the VLDB Conference. Koeller, A., Rundensteiner, E.A., Hachem, N. (1998). Integrating the Rewriting and Ranking Phases of View Synchronization. Proc. of the Int. Workshop on Data Warehousing and OLAP (DOLAP), USA. Kulkarni, S., Mohania, M. (1999). Concurrent Maintenance of Views Using Multiple Versions. Proc. of the Intern. Database Engineering and Application Symposium. Mendelzon, A.O., Vaisman, A.A (2000). Temporal Queries in OLAP. Proc. of the VLDB Conference, Egypt. Monk, S., Sommerville, I. (1993). Schema Evolution in OODBs Using Class Versioning. SIGMOD RECORD, Vol. 22, No. 3. Quass, D., Widom, J. (1997). On–Line Warehouse View Maintenance. Proc. of the SIGMOD Conference. Teschke, M., Ulbrich, A. (1998). Concurrent Warehouse Maintenance whithout Compromising Session Consistency. Proc. of the DEXA Conf. Teste, O. (2001). Towards Conceptual Multidimensional Design in Decision Support Systems. Proc. of the EastEuropean Conference on Advances in Databases and Information Systems (ADBIS), Lithuania. Yang, J., Widom, J. (2000). Temporal View Self– Maintenance. Proc. of the EDBT Conference, Germany.

Suggest Documents