An Architecture for Data Warehouse Systems Using a ...

An Architecture for Data Warehouse Systems Using a Heterogeneous Database Management System Diva de S. e Silva IBGE, Rio de Janeiro, Brazil Elvira Mª A. Uchôa PUC-Rio, Rio de Janeiro, Brazil

Sean W. M. Siqueira PUC-Rio, Rio de Janeiro, Brazil Mª Helena L. B. Braz DECivil/ICIST – UTL Lisboa, Portugal

Rubens N. Melo PUC-Rio, Rio de Janeiro, Brazil

Abstract In today’s highly competitive world, enterprises are using Data Warehouse (DW) systems in order to make better and faster decisions. However, the success of a DW project is related to the quality of the information. This quality depends on data cleansing, consolidation and extraction processes. In this paper, an architecture for DW systems is proposed. This architecture provides high data quality through the use of a heterogeneous database management system, called HEROS, to solve data integration problems. A case study presenting the use of the proposed architecture is also shown.

1.

Introduction

Nowadays, it is very difficult to find the necessary information, in a fast and consistent way. Generally there is a high amount of data, which are heterogeneous, distributed on the production systems of the company and usually do not reflect the managerial perspective which is essential for decision support. Data warehousing technology has been used for helping decision support. Data from production systems and external sources are combined with the objective of facilitating better analysis under the managerial prism. However, the complexity of such data integration has caused the failure of many DW systems [9]. In the database community, a possible solution for heterogeneous data integration is the use of heterogeneous database management systems (HDBMS). In such systems, data from several sources interconnected by communication networks are accessed with no heterogeneity. The integration processes assure the high quality of the resulting information. In this paper, an architecture for DW systems is proposed. This architecture uses a HDBMS (HEROS) for data integration. A systematic for the use of this architecture is also presented through the description of a case study. The remainder of this paper is organized as follows: in section 2, some concepts of DW and HDBMS, in special HEROS, are presented. Section 3 describes the proposed DW architecture and its components. In section 4, a sequence of steps for the use of the architecture is presented. In section 5, the proposed architecture is compared to related works. And, finally, section 6 contains final remarks are emphasized.

2.

Concepts

This section introduces the essential concepts for understanding the proposed architecture. Thus, the main concepts related to DW and HDBMS, in particular to HEROS, are presented. 2.1. Data Warehouse According to William H. Inmon [11], a DW has the following characteristics: ♦ It is subject oriented (data are stored according to business areas or specific subjects/aspects of interest to the company). ♦ It is integrated (i.e., it integrates data coming from several data sources and many inconsistencies are eliminated). ♦ It is a non-volatile collection of data (which means data is loaded and accessed, but update of data generally does not occur in the DW environment). ♦ It is time-variant (the time horizon for DW is significantly longer than that of production systems; data is a sophisticated series of snapshots, taken at one moment in time; and the key structure of the DW always contains some element of time). ♦ It is used in support of management’s decisions. In general, an architecture for DW systems (Figure 1) involves the integration of current and historical data. The data sources (DS 1, DS 2… DSn) can be internal (production systems of the company) or external (containing complementary data from outside the company such as economic indicators). Generally, data integration deals with different data models, definitions and/or platforms. This heterogeneity forces the existence of extractor and transformation applications, in order to allow data integration. Once integrated, the resulting data are stored in a new database – DW – that combines different points of view for decision support. This database is used by end-user applications, for data analysis. A DW can be divided in several databases, called Data Marts (DM) [12]. These DM contain information that may be useful to the different departments of the company. They are also considered departmental DW. DM/DW can be accessed through OLAP (Online Analytical Processing) tools, Data Mining and/or EIS (Executive Information Systems). These tools allow data navigation, managerial analysis and knowledge discovery.

Data Marts DM 1

DW Transformers Extractors

Extern al S ources

Managerial (OLAP) Applications

DM2

DS1

DS 2

... ...

Managerial View DSn

Production Systems Figure 1: DW systems' architecture

Operational View

Techniques for DW/DM development are described in ([11] and [12]). In [5], concepts, components and tools of Data Warehousing, OLAP and Data Mining are introduced. Practical advice from expert, related to DW development, are presented in [2]. Finally, topics on planning and designing a DW can be found in [3]. 2.2. Heterogeneous Database Management System In database community, HDBMS are one of the solutions for integrating heterogeneous and distributed data. A HDBMS ([17] and [21]) is a layer of software for controlling and coordinating heterogeneous, autonomous and pre-existing data sources connected by communication networks. The term heterogeneity denotes not only technological differences (hardware and software), but also differences in data models, database management systems and semantics. The analysis about the level of integration that exists among the component systems allows heterogeneous database systems (HDBS) to be classified into tightly coupled or loosely coupled HDBS [21]. In loosely coupled HDBS, the end-user must know in which sources the data that he/she wants to access are located and their paths. HDBMS just supply mechanisms to facilitate the access. In tightly coupled HDBS, the end-user has an integrated view in which there is no heterogeneity. It gives the illusion that there is only one system. In the Computer Science Department of PUC-Rio, a HDBMS called HEROS – HEteRogeneous Object System [16] has been developed since 1993 ([7], [14], [15], [16], [19], [22], [26], [27], [28], [29], [30], [31], [32], [33], [34] and [35]). HEROS is a tightly coupled HDBMS. It allows the integration in a federation of a set of HDBS, cooperative but autonomous, where queries and updates can be executed with transparency in relation to location of data, access paths and any heterogeneity or redundancy [28]. The schema architecture used by HEROS is shown in Figure 2. In this architecture, each data source has a local schema, represented in its own data model. This local schema is translated to HEROS' object oriented data model, resulting in an export schema. All export schemas must be integrated, resulting on a global schema, with no heterogeneity. Finally, end user's views can be created from this global schema, generating external schemas. A HEROS’ federation consists of an integrated set of autonomous component systems. Application with an integrated view External Schemas Global Schema

… … …

HEROS Federation

Integration Export Schemas Translation Local Schemas Local Data Sources

Production Systems Figure 2: Schema Architecture used by HEROS

Recently, HEROS’ architecture has been restructured, by the use of the framework 1 technique. This technique promotes the reuse of the HDBMS architecture/implementation code to construct different federations, according to their particularity [30]. This restructuring has enabled an increased flexibility in HEROS’ architecture that facilitates its adaptation to new environments and the integration of new types of component systems. The description of HEROSfw framework and its components may be found in [30]. As instances of HEROSfw framework are HDBMS, the proposed architecture uses an instance of HEROSfw framework. Data Visualization / Analysis Tools

Aplicações DBA

DW Materializer

DW Schema

Extractor Integration Middleware

DW

HEROS

Data Sources

DS1

DS2

...

DSn

Production systems and external data sources

Figure 3: Proposed Architecture for DW systems

3.

Proposed Architecture

The proposed architecture for DW systems uses HEROS HDBMS for data integration (extraction, cleaning, consolidation and aggregation). This architecture is organized in four layers, as presented in Figure 3: Data Sources, Integration Middleware, DW Materializer and Data Visualization/Analysis Tools. More details can be found in [20]. 3.1. Data Sources In the proposed architecture, the "Data Sources" layer refers to data from production systems of the company and from external sources. It comprises only relevant data to the DW. External sources are important to complement the information of the company. This layer also includes the schemas of the component systems. These schemas are expressed using the concepts of the data model used by the local Database Management System - DBMS (if it is not a DBMS, a specific model could be used to represent the data structure. For example, to represent geographic data FGDC [10] could be used). A local schema can be the conceptual schema of the local data source or a view, which is defined for an application or users' class, specific to the component system.

1

Frameworks are a particular way to denote architectures [4]. A framework defines the architecture for a family of (sub)systems and provides the basic building blocks to create them. It also defines the parts of itself that must be adapted to achieve a specific functionality.

3.2. Integration Middleware The integration middleware layer is composed by HEROS HDBMS, where data extraction, cleaning, transformation and integration processes are executed. This layer allows a group of data sources, cooperative but autonomous, be integrated in a federation in such a way that queries and updates can be executed transparently to data location and any heterogeneity or redundancy. In order to provide easier understanding of the resulting data from the integration process, DW semantics were incorporated into HEROS’ global schema. Typically, a DW is modeled using the dimensional model [12] that is an intuitive technique to represent business models. The dimensional model is generally implemented in relational databases, resulting in a schema similar to a star. This resulting schema is called star schema. In this schema, there is a central table that stores business measures (facts). Around this fact table, several other tables are created. These tables represent information of business interest that means the different perspectives (dimensions) which are available to do the analysis. Using the OMT notation [18], a DW can be represented as a class (DW*) composed by several stars where each star is composed by a fact and several dimensions (Figure 4). This is the metamodel that must be first instantiated and after specialized in HEROS' global schema in order to incorporate DW semantics to HEROS' federations. [20] Fact (1,1)

DW*

(1,N)

Star Dimension (1,N)

Figure 4: DW Metamodel

3.3. DW Materializer HEROS provides access to the component systems with no data materialization. Therefore, the DW materializer layer is responsible for supplying data persistence after integration processes. This persistence allows better performance because a query, which is submitted to a stored DW (where the integrated data were previously stored), executes much faster than doing the whole integration processes on the fly. The execution of integration processes increases network traffic and processing time in the local systems that must also execute local applications. Besides, a persistent DW allows the preservation of historical data, one of the DW requirements for trend analysis. In order to materialize data resulting from HEROS’ processing, an extractor program is necessary. This program is responsible for requesting HEROS the extraction/integration of local data and to store the result in a persistent database. This is one of the most important components of the proposed architecture. The DW database administrator (DBA) requires data extraction/load for a specific DW, activating the extractor. So, the extractor puts HEROS in action, which makes the access and data integration. The result is returned to the extractor. Then, the extractor analyzes the DW catalog to discover in which table of the persistent DW database it should insert the data. After the insertions in the respective tables, the business data are ready to be

accessed through data visualization/analysis tools. The DW catalog is stored in the persistent DW database, a relational DBMS. Using a relational DBMS is an important aspect as almost all OLAP tools access this type of DBMS. 3.4. Data Visualization/Analysis Tools Application tools (OLAP, Data Mining and EIS) for visualizations and data analysis compose this layer. These tools support decision-making. As the proposed architecture has a persistent relational database (DW), just like in DW traditional approaches, this layer works exactly as data visualization and analysis tools used in the traditional (commercial) DW systems ([2], [3] and [5]). 4.

Steps for Using the Architecture

To use the proposed architecture, it is necessary to follow three steps: the DW construction, the DW load and the DW use through data visualization and analysis tools. In order to evaluate the architecture, a case study was used. This case study was based on a real case and it was simplified to facilitate the understanding of the architecture’s functionality. A Non-Governmental Organization (NGO), denominated Rivers and Lakes (fictitious name), wants to control predatory fishing, through integrated and consolidated information on fishing landings. The information comes from several landing locations in the municipal districts of the Amazon basin. Each landing location has an administrative structure and its own information system, according to local needs. With the financial support from an important international corporation, it was possible to install a communication network connecting landing locations and the NGO. The NGO will use the proposed architecture to create a DW, called Fish-DW whose main objective is to monitor predatory fishing. This control is needed because the environmental laws have become more and more rigorous. As consequence, companies, communities and even the fishermen by themselves have been involved in controlling and monitoring the fishing activities and their environmental impact. Information about fishing activities must be available in an integrated way with easy access in order to allow this control. The development of Fish-DW – using the proposed architecture – follows five steps [20]: 1. Business interviews and data gathering for identifying and understanding the data sources. 2. Creation of a HEROS’ federation [26] for the Fish-DW: • To define a new HEROS’ federation and to explain the data semantic of each local system on HEROS’ data dictionary. • To create an export schema for each local schema. At present, this is necessary because HEROS’ active rules mechanism has not been developed yet. This mechanism would create the export schemas automatically. • To create the global schema it is necessary to specialize the metamodel classes, considering the integration of the export schemas and to define command trees achieving data semantic integration and consolidation. The global schema integrates all the export schemas organizing the integrated information according to the proposed DW metamodel.

3. Creation of tables for storing data in the persistent DW. 4. Creation of a mapping catalog between HEROS’ outputs and the tables, which compose the persistent DW. 5. Definition and configuration of visualization and analysis tools. The existence of two types of data sources was noticed through interviews with users and data gathering. These data sources are: • Fishing system – there is a fishing system, which controls fishing data, running on several landing locations. Even though there are several Fishing systems as data sources, in this case study, it was considered only one in order to make the steps easier to understand. • Research system – relative to data of reproduction periods of the fish species. This system is used only in the NGO. Figure 5 and 6 detail the local schemas of these two component systems with some simplifications. These models were represented using PowerDesigner CASE tool [24].

SPECIES

STATE STATE_CODE CHAR(2) REGION_CODE CHAR(2) STATE_NAME CHAR(20)

SPECIES_CODE SPECIES_COMMOM_NAME

CHAR(2) CHAR(20)

FISHING_EQUIPMENT FISHING_EQUIPMENT_CODE FISHING_EQUIPMENT_NAME

CHAR2) CHAR(20)

REGION_CODE = REGION_CODE FISHING_EQUIPMENT_CODE = FISHING_EQUIPMENT_CODE

REGION REGION_CODE REGION_NAME

SPECIES_CODE = SPECIES_CODE

CHAR(2) CHAR(10)

STATE_CODE = STATE_CODE

SPECIES_IN_STATE SPECIES_CODE CHAR(2) STATE_CODE CHAR(2)

SPECIES_CODE = SPECIES_CODE

STATE_CODE = STATE_CODE

CITY STATE_CODE CITY_CODE CITY_NAME

CHAR(2) CHAR (4) CHAR(40) STATE_CODE = STATE_CODE

STATE_CODE = STATE_CODE

STATE_CODE = STATE_CODE CITY_CODE = CITY_CODE

LANDING LANDING_CODE

CHAR (2)

STATE_CODE

CHAR(2)

CITY_CODE LANDING_LOCATION_CODE VESSEL_TYPE_CODE

CHAR (4) CHAR 2) CHAR(4)

LANDING_DESCRIPTION FISH_ AMOUNT FISHERMEN_ NUMBER

CHAR(50) CHAR (5) CHAR (2)

FISHING_DAYS_NUMBER ARRIVAL_DATE

CHAR 3) DATE

LANDING_LOCATION_CODE = LANDING_LOCATION_CODE LANDING_CODE = LANDING_CODE

LANDING LOCATION STATE_CODE CITY_CODE LANDING_LOCATION_CODE LANDING_LOCATION_NAME

CHAR(2) CHAR (4) CHAR 2) CHAR(20)

VESSEL TYPE VESSEL_TYPE_CODE VESSEL_TYPE_DESCRIPTION

Figure 5: Local Schema of theFishing System

CHAR(4) CHAR(30)

STATE STATE_CODE REGION_CODE STATE_NAME

CHAR(2) CHAR(2) CHAR2(20)

STATE_CODE = STATE_CODE

STATE_CODE = STATE_CODE

CITY STATE_CODE CITY_CODE CITY_NAME

REPRODUCTION_IN_STATE SPECIES_CODE CHAR(2) STATE_CODE CHAR(2)

CHAR(2) CHAR(4) CHAR2(30)

SPECIES_CODE = SPECIES_CODE REGION_CODE = REGION_CODE

REGION REGION_CODE REGION_NAME

CHAR(2) CHAR2(20)

CIENTIFSPECIES SPECIES_CODE SPECIES_SCIENTIFIC_NAME SPECIES_COMMOM_NAME REPRODUCTION_TIME_START REPRODUCTION_TIME_END

CHAR(2) CHAR(50) CHAR(30) CHAR(6) CHAR(6)

Figure 6: Local Schema of theResearch System

For the creation of a DW federation , in HEROS, it is necessary to follow the steps, which were proposed in [26] and reviewed in [27]. Considering these steps, a new DW federation - RL-NGO - was created. This federation is composed by three component systems: • Fishing System – on Oracle DBMS, version 7.3; • Research System – on Postgres DBMS version 4.0; • HEROS – HEROS' own database, used as a working area during the integration processes.

Research System

Fishing System

HEROS

Landing

Fishing_Equipment

Fish_WorkArea2

Fish_WorkArea

Landing_Code Species_Commom_Name State_Code City_Code Landing_Location_Code Vessel_Type_Code Fishing_Equipment_Code Kgs_Fish_AMT Fishermen_QTY Fish_Days_ QTY Arrival_Date

Fishing_Equipment_Code Fishing_Equipment_Name

Species_Cient_Name Local_Code Vessel_Type_Code Fishing_Equip_Code Arrival_Date Kgs_Fish_AMT Fishmen_ QTY Fish_Days_ QTY

State_Code City_Code City_Name Region_Code Vessel_Type_Code Vessel_Type_Desc Fishing_Equip_Code Fishing_Equip_Name Species_Cient_Name Reprod_Time_Start Reprod_Time_End Arrival_Data Species_Cient_Name Local_Code Vessel_Type_Code Fishing_Equip_Code Kgs_Fish_AMT Fishmen_ QTY Fish_Days_ QTY Arrival_Date

Get_Landing

Get_Fishing_Equipment

Landing_Location State_Code City_Code City_Name Region_Code

Get_Landing_Location

Vessel_Type Vessel_Type_Code Vessel_Type_Description

Cientific_Species Científic_Name Commom_Name State_Code

Get_CientifName

Get_Consolidation

Species Científ_Species_Name Reprod_Time_Start Reprod_Time_End

Get_Species

Get_Vessel_Type

Group_Data_Ret

Figure 7: Export Schemas of the Component Systems

For the creation of export schemas, it is necessary to represent the local schemas in HEROS’ data model. Figure 7 presents the classes of the export schemas concerning the simplified case study. The methods of these classes represent the data mappings from the export schema to the local schema. For each method of an export schema, local procedures

must be implemented to extract data from local component systems. The detailing procedures and execution paths for this case study can be found at [20]. Finally, the DW metamodel is specialized in HEROS’ global schema, according to the semantic of the case study (Figure 8). A global query relative to global classes may be decomposed to sub-queries for other classes in the global schema and afterwards to subqueries for classes in the export schemas. The execution trees, which are responsible for treating the semantic heterogeneity and data consolidation, are detailed in [20]. Landing

Fact (1,1) Get_Fact DW*

Star

Get_Fact

(1,N) Get_ DW

CientificSpecies_Name Local_Code VesselType_Code Fishing_Equipment_Code Kgs_Fish_AMT Fishermen_ QTY Fishing_Days_ QTY Arrival_Date

Get_Star

Dimension (1,N) Get_Dimension

Fishing Equipment Fishing_Equipment_Code Fishing_Equipment_Name Get_Dimension Species

Fish-Ctr_Fact

Get_Dimension

(1,1) Fish-DW

Fish-Control_Star

Get_Fish-Ctr_Fact

Vessel Type Vessel_Type_Code Vessel_Type_Description

(1,N) Get_ Fish-DW

Species_Cientific_Name ReproductionTime_Start ReproductionTime_End

Get_Dimension

Get_FishControl_Star

Fish-Ctr_Dimension Landing_Location (1,N) Get_FishCtr_Dimension

State_code City_code City_Name Region_code Get_Dimension

Figure 8: Global Schema of the RL-NGO federation

Once the federation of DW was created, in HEROS, the next step is the creation of the necessary tables of the DW, in the persistent database. In the case study, the created tables were Landing_Location, Vessel_Type, Species, Fishing_Equipment and Landing. Then, it is necessary to create a catalog for mapping between HEROS’ outputs and the DW tables. This catalog will enable the extractor to load the persistent DW database from the integrated result of HEROS’ data processing. Figure 9 represents the catalog for the case study. In the proposed architecture, the last step for the development of a DW system refers to the choice (and/or settings) of data visualization and analysis tools. This step is equivalent to traditional DW developments. The DW is loaded through the activation of the extractor by the DBA.

Corp. Unity Name

DW Name

Output Position

RL-NGO

Fish-DW

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Table Name Landing_Location

Vessel_Type Fishing_Equipment Species

Landing

Attribute Name State_code City_code City_Name Region_code VesselType_code VesselType_Description FishingEquipment_code FishingEquipmentName Species_Cientific_Name ReproductionTime_Start ReproductionTime_End CientificSpecies_Name Local_code VesselType Fishing_Equipment ArrivalDate Kgs_Fish_AMT Fishermen_ QTY Fishing_Days_ QTY

Figure 9: Catalog of Mappings between HEROS’ output and DW persistent tables

5. Related works In this section, the proposed architecture will be compared with other proposals. The discussion is focused on the data integration technique. In figure 10, a table summarizes the considered alternative proposals: WHIPS project [13], TIC96-6903 project [23] and some commercial products such as: Virtual DB ([1] and [6]), SynopSys&trade [25] and InterViso [8]. Projects/Products

Commercial/Academic

Virtual DB, InterViso e SynopSys&trade

Commercial

WHIPS Project TIC96-6903 Project DEXA’98

Academic (Stanford University) Academic (Universitat 2 Politècnica da Catalunya)

Proposed Architecture

Academic (PUC-Rio)

Integration Technique Proprietary Programs Mediators and Wrappers HDBMS (2) HDBMS (HEROS)

Figure 10: Related Work

Commercial products generally behave as "black" boxes. The integration procedures are hidden from the users that are responsible for the DW definition. This fact obstructs the user’s perception about extraction and cleansing processes, creating the possibility of errors in the integrated data. Moreover, these commercial products don't consider the semantic heterogeneity. It must be treated through other programs/procedures, in a previous phase to the use of these products. 2

It has found no more details about this work.

The use of HEROS to integrate heterogeneous data assumes that local data-schemas and translation processes are well known to the person responsible for the DW definition. Once this knowledge is encoded in HEROS, it will treat the heterogeneity automatically and will carry out data integration processes. In order to include a new data source, the user (DBA) needs only to do the specialization of some classes in HEROS' data model. This approach contributes to a more organized and transparent process. HEROS supports the development of a DW without the need of external programs. The DW metamodel’s concepts, which were specified in HEROS, allow DW data to be analyzed according to business reality. Thus, the integration processes become less liable to errors, reducing the possibility of failure of the DW project. Some commercial projects, like Virtual DB, InterViso and SynopSys&trade, use the idea of a virtual DW, where there is no data materialization. The adopted integration mechanism generally is similar to loosely coupled HDBS. On the contrary, the proposed architecture considers the existence of a materialized DW. This contributes to achieve better performance, as it is not needed to accomplish data integration every time a new query is executed. Besides that, the fact of using a tightly coupled HDBS provides integration transparency to the end-user. The WHIPS project is based on wrappers and mediators for data extraction and transformation to the DW. Wrappers and mediators are software programs, which are developed to assist a specific class of problem. They work as black boxes not allowing the access to their logic. The proposed architecture uses HDBMS HEROS for data extraction, transformation and integration. The use of a HDBMS allows that any system, even a nonconventional one, is integrated in an easy way. It is only required to do the specialization of some classes in its data model. The TIC96-6903 project described an idea that is similar to our work. However, until now, no literature was found mentioning neither the adopted solutions nor any afterwards evolution. The proposal that is presented in this paper details the use of a HDBMS in the architecture of DW systems and it defines the steps for its use. Besides that, this work specifies a metamodel of DW systems that is the basis for the definition of HEROS’ global schema. The existence of the metamodel facilitates data integration in DW systems, once its definition considers the semantic adopted in the dimensional model commonly used by DW community. 6. Final Remarks In the highly competitive business world, it is very important to access the right information in order to make the best decision. DW Systems intend to present the information according to managerial needs. However, one of the biggest challenges in DW systems development is related to the need for data integration because available data are usually distributed and heterogeneous. In order to contribute to the solution of these problems, an architecture for DW systems using a HDBMS – HEROS – was proposed. A simplified case study in the environmental area was developed to present the steps for the use of the proposed architecture. These steps guide the development of the DW systems. The use of a HDBMS improves data quality. Therefore, DW projects based on the proposed architecture are more reliable, flexible and have more semantic. The end-user uses the DW semantics that are supported by the DW metamodel’s definition and accesses integrated information not noticing

heterogeneity. Even though the idea of using a HDBMS as an integration middleware for the development of DW systems was also discussed in [23], the architecture proposed in this paper is more detailed and its feasibility was proved by a case study. As future work, it is suggested the implementation of a monitor to activate the extractor to automatically load the DW. This application could be a set of agents monitoring inserts and updates in the local data sources and activating the extractor. 7. Acknowledgements The authors would like to thank TecBD team for their strong commitment to this project. Thanks are also due to IBGE, CAPES and ICIST, for the financial support received throughout this work.

References [1] Adams, P.: Virtual Warehousing: Spreading out Data Reaps Lower Development Costs and a Faster ROI; The Technology Network, Application Development, Web Site: http://techweb.cmp.com/vb/oct/177app.htm, October 1997 [2]

Bischoff, J. & Alexander, T.: Data Warehouse – Practical Advice from the Experts , Prentice-Hall, Inc., 1997

[3]

Barquin, R. & Edelstein, H.: Planning and Designing the Data Warehouse , Prentice Hall, Inc., 1997

[4]

Beck, K. & Johnson, R.: Patterns generate architectures , European Conference on Object Oriented Programming (ECOOP’94), Spriger-Verlag, Bologna, Italy, July 1994

[5]

Berson, A. & Smith S. J.: Companies, Inc., 1997

[6]

Callaghan, D.: Virtual DB Breaks Down Data Barriers; Data Management & Analysis; Web Site: http://www.midrangesystems.com/archive/1997/oct10/dm101603.htm, October 1997 (Last Access – July/2000)

[7]

C. E. P. S. Castro ; Integration of Legacy Systems and Heterogeneous Databases . Computer Science Department – Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). M.Sc. Thesis, 1998 (in Portuguese)

[8]

Data Integration, Inc. – “DII; An Introduction to DII and InterViso”; Web Site: http://www.cerfnet.com/~margie/dii.htm, July 1998 (Last Access – September/ 1999)

[9]

[11]

Dresner, H. & Lett, B.: Evaluating Executive Information Systems . An Gartner Group Strategic Analysis Report. September 1995 Federal Geographic Data Committee – “Content Standard for Digital Geospatial Metadata”, http://www.fgdc.gov/metadata/csdgm/ 1998 (Last Access – July/2000) Inmon, W. H.: Building the Data Warehouse, John Wiley & Sons, Inc., 1996

[12]

Kimball, R.: The Data Warehouse Toolkit, John Wiley & Sons, Inc., 1996

[10]

Data Warehousing, Data Mining & OLAP , McGraw-Hill

[13]

Labio, W. J. & Zhuge, Y. & Wiener, J. L. & Gupta, H. & Molina, H. G. & Widow, J.: The WHIPS Prototype for Data Warehouse Creation and Maintenance ; Proc. ACM SIGMOD Conf. AZ, USA, 1997

[14]

Oliveira, E. S.: HEROS: using CORBA for Interoperability of its Components . Computer Science Department – Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). M.Sc. Thesis, 1997 (in Portuguese)

[15]

Piccinini, H. S.: Integration of Internet/Intranet Resources and Heterogeneous Databases. Computer Science Department – Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). M.Sc. Thesis, 1998 (in Portuguese)

[16]

Pacitti, E. & Silva, S. D. & Duarte, C. H. C. & Melo, R. N.: HEROS: An Object Oriented Heterogeneous Database System , VIII Brazilian Database Symposium, Campina Grande, PB, 1993 (in Portuguese)

[17]

Ram, S.: Guest Editor's Introduction: Heterogeneous Distributed Database Systems . In: IEEE Computer, Vol.24, N.12, December 1991.

[18]

Rumbaugh, J. & Blaha, M. & Premerllan, W. & Eddy, F. & Lorensen, W.: Object Oriented Modeling and Design. Prentice-Hall, Englewood Clifs 1991.

[19]

Silva, S. D.: Heterogeneous Database Systems: a Transactions Management Execution Model. Computer Science Department – Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). Ph.D. Thesis, 1994 (in Portuguese)

[20]

Silva, D. S.: An Architecture for Data Warehouse Systems using HEROS: a Heterogeneous Database Management System . Computer Science Department – Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). M.Sc. Thesis, 1999 (in Portuguese)

[21]

Sheth, A. P. & Larson, J. A.: Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases em ACM Computing Surveys , Vol. 22, N. 3, September 1990

[22]

Silva, S. D. & Melo, R. N.: A Transaction Management Model for Heterogeneous Databases; X Brazilian Database Symposium, Recife, PE, 1995

[23]

Samos, J. & Saltor, F. & Sistac, J. & Bardés, A.: DataBase Architecture for Data Warehousing: An Evolutionary Approach ; DEXA Conference and Workshop Programme, Vienna, Austria, 1998

[24]

Sybase’ Products Web Page, http://www.sybase.com/products/powerdesigner/ (Last Access – July/2000)

[25]

SynopSys™ White Paper, Web Site: http://www.themis.co.uk/WhtPaper1.html, January 1998

[26]

Uchôa, E. M. A.: HEROS – A Heterogeneous Database System: Integrating Schemas . Computer Science Department – Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). M.Sc. Thesis, 1994 (in Portuguese)

[27]

Uchôa, E. M. A.: A Framework for Heterogeneous Database Systems. Computer Science Department – Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). Ph.D. Thesis, 1999 (in Portuguese)

[28]

Uchôa, E. M. A & Lifschitz, S. & Melo, R. N.: HEROS: A Heterogeneous ObjectOriented Database System; DEXA Conference and Workshop Programme , Vienna, Austria, 1998

[29]

Uchôa, E. M. A. & Melo, R. N.: Integration of Heterogeneous Database Systems using Frameworks; XIV Brazilian Database Symposium, Florianópolis, SC, 1999 (in Portuguese)

[30]

Uchôa, E. M. A. & Melo, R. N.: HEROSfw: a Framework for Heterogeneous Database Systems Integration ; DEXA Conference and Workshop Programme , Florence, Italy, 1999

[31]

Uchôa, E. M. A. & Melo, R. N. & Lifschitz, S.: Object Interoperability Patterns in HEROS; Computer Science Technical Report, Computer Science Department, PUCRio, 1995 (in Portuguese)

[32]

Uchôa, E. M. A. & Melo, R. N. & Lifschitz, S.: Object Interoperability in Heterogeneous Database Systems ; Computer Science Technical Report, Computer Science Department, PUC-Rio, 1996 (in Portuguese)

[33]

Uchôa, E. M. A. & Melo, R. N. & Lifschitz, S.: HEROS: A Heterogeneous Database System using CORBA ; Computer Science Technical Report, Computer Science Department, PUC-Rio, 1997 (in Portuguese)

[34]

Uchôa, E. M. A. & Melo, R. N. & Lifschitz, S.: Interoperability in a Heterogeneous Database System , XII Brazilian Database Symposium, Fortaleza, CE, 1997 (in Portuguese)

[35]

Uchôa, E. M. A. & Silva, S. D. & Melo, R. N.: HEROS Database Model – Object Oriented Heterogeneous Database System , IX Brazilian Database Symposium, São Carlos, SP, 1994 (in Portuguese)