Federating Object-Oriented and Relational Databases : The IRO-DB Experience* Georges Gardarin (1) Béatrice Finance (1), Peter Fankhauser (2) (1) Laboratoire PRiSM URA CNRS 1525 (2) GMD-IPSI Integrated Publication and Information Systems Institute Université de Versailles-StQuentin Dolivostrasse 15 45 avenue des Etats-Unis 64293 Darmstadt - GERMANY 78035 Versailles Cedex - FRANCE email : (1)
[email protected], (2)
[email protected]
Abstract From beginning of 1994 to the end of 1996, the IRO-DB ESPRIT project has developed tools for accessing in an integrated way relational and object-oriented databases, and for designing and maintaining integrated applications on large federations of heterogeneous databases. IRO-DB is based on the ODMG pivot object model and gives OQL/OML C++ interface to users on a federation of relational and object-oriented databases. This paper summarizes the main problems and choices done during the system design, describes the IRO-DB architecture and components, presents the project achievements, and gives a synthesis of the lessons learned during the project development. It also introduces future plans for the system.
1. Introduction A federated database management system adds layers of software on pre-existing heterogeneous DBMSs. These layers provide for syntactically uniform export schemas and data manipulation languages, and for semantically integrated schemas with global transaction management, and concurrency control over multiple sites. Most importantly, this approach does not violate the autonomy of the pre-existing databases. Database providers participating in a federation do not loose control over their data ; they do not have to re-engineer their DBMSs and applications to provide interoperability with other DBMSs. Several federated database systems have already been prototyped from the beginning of the 80s [26]. They can be distinguished through the pivot data model supported for integrating the various data sources. In the 80s, most federated DBMSs were built around the relational model,
which brought a simple uniform model to integrate smoothly alphanumeric data. The most well-known project were then ADDS [5], SIRIUS [18], Mermaid [29], and Dataplex [9]. To provide a better integration platform for applications, Multibase [17] adopts the functional model. With the advent of non-standard data types such as document, image and video, richer data model integrating complex attributes and methods are required. New projects are also considering semi-structured data models, as Tsimmis [20] or Information Manifold [15]. Recently several research projects have experimented the use of object-oriented techniques to facilitate the complex task of building federated database systems. The object-oriented paradigm brings new solutions in several dimensions, including the modeling of local data sources as objects with a well-defined and published interface, the use of a semantically rich common object model to ease application integration, the development of standards to interoperate among objects, the use of object-oriented transaction models, etc. Well-known research projects in object-oriented multi-database systems are Carnot [32], Disco [31], DOMS [21], Femus [2], GARLIC [7], InterBase [3], Pegasus [25], etc. A complete survey of object-oriented multidatabase systems can be found in [4]. The current paper focuses on IRO-DB (Interoperable Relational and Object-Oriented DataBases) [12], an ESPRIT project developed in Europe from 1993 to 1996. The novelty of the IRO-DB architecture is the use the ODMG'93 standard [8] as a common object model supporting the ODL definition language and the OQL query language to federate various object-oriented and relational data sources. The IRO-DB architecture is clearly divided into three layers, thus facilitating the cooperative development of the project in several research centers. The local layer adapts local data sources to the ODMG standard ; the communication layer efficiently
* This work is initiated and partially supported by the European IRO-DB ESPRIT project. The project is developed in cooperation with GMD, GOPAS, FAW-Linz, IBERMATICA, EDS, GRAPHAEL, INTRASOFT and O2 Technology. PRiSM acts as a subcontractor of both GRAPHAEL and EDS.
transfers OQL requests and the resulting collections of objects ; the interoperable layer provides schema integration tools, security management, transaction management, object management, as well as a global query processor. A version of the system is currently operational. It interconnects a relational system INGRES, and three object-oriented DBMS : O2, Matisse and Ontos. A Computer Integrated Manufacturing application (CIM) has been prototyped on top of the system [23]. This paper focuses on problems to solve when tightly federating relational and object-oriented databases. It summarizes the work done in the IRO-DB Esprit project. Then, it tries to isolate the lessons learned from the project development. It is organized as follows. In the next section, we discuss the primary issues addressed during the design of IRO-DB. We introduce and justify the principal choices made. In the third section, the IRO-DB architecture is presented. The main system components are briefly described. In the fourth section, the integrated system with its application demonstrator is introduced. In section five, we focus on the lessons learned from the project. In conclusion, we discuss the future of the project.
2. Problems to Design a Federated DBS The development of an interoperable object-oriented federated database system yields to a number of problems that we discuss below. Some of them are not specific to object-oriented systems. We mostly focus on problems coming from object-orientation. We discuss some alternatives and introduce the solution selected within IRO-DB.
2.1 Choosing a Pivot Database Model Old federated systems as Mermaid or R* are strongly based on the relational model, using a relational global schema and SQL as pivot language. More modern systems are centered around either an object-relational data model (e.g., Garlic or Omega), an object-oriented one (e.g., Pegasus or Disco), or even a semi-structured one (e.g., Information Manifold or Tsimmis). The object-relational models supports abstract data types in addition to standard relational concepts. Selecting a specific object-oriented model is not an obvious problem ; systems as Pegasus use their own model derived from a local system (i.e., Iris). A better solution seems to choose a standard data model, as the OMG object model [22]. This is the model selected in the CORBA distributed object architecture. In database systems, the ODMG proposal — derived from the OMG by adding database features such as class extents and relationships— was an interesting candidate for a common data model to federate object and relational systems.
Indeed, in 1994, when the selection was done, every ODBMS integrated in the project was claiming ODMG compatibility for 1995. Thus, we decided to select the ODMG’93 framework as the pivot model for IRO-DB. The ODMG’93 specifications [8] include an object model with the ODL associated definition language, the OQL query language, and a manipulation language called OML with its associated C++ binding. The object-relational model of SQL3 would be a possible alternative, but it was not clearly defined in 1994. Also, it was considered as easier to map OQL queries to relational one on top of relational systems rather than SQL3 queries to OQL queries on top of object systems.
2.2 Organizing Schemas and Repositories A problem which all federated database systems face, is the organization of schemas. In object database systems, it is not possible to export objects without exporting the corresponding class schema. Modern systems tend to avoid global integrated schemas ; they rather provide mechanisms to export method signatures of classes known as interfaces. For example, in the CORBA architecture, interfaces of exported objects are described in an interface repository managed by servers. Client stubs can be viewed as exported schemas. No composition service is provided to compose multiple interfaces. When exported classes are semantically heterogeneous, it is necessary to integrate them using another level of schemas. Thus export classes can be federated to make up interoperable views. For example, two variants of a Part class can be unified to provide a unique integrated class to the user. Unification can be performed using a traditional approach, through queries involving outer joins. It can also be performed using object-oriented facilities such as generalization to factorize common attributes and overloading to alleviate semantic heterogeneity. Enrichment of object semantics is often necessary before merging common properties for fine integration. When a schema architecture has been defined, repositories for schemas have to be designed. Repositories can be centralized on a unique site ; more efficiently, they can be distributed on various sites, each site handling the description of objects locally processed. Copies have to be handled in a consistent way. For storage organization, several choices are possible, from an object-oriented database to an ad-hoc file-based storage. For example, the OMG CORBA architecture is proposing a repository based on object contained and containing concepts, respectively stored in Contained and Content class extents. In IRO-DB, we selected a distributed schemas architecture, where each site manage a data dictionary. A
server dictionary contains an ODMG description of the locally exported schema. A client dictionary contains a copy of all exported schemas known (called imported schemas) and the locally defined integrated views. Consistency of replicated schemas is handled through a version number checked at each server access. In case of inconsistency, an error message is reported and the database administrator has to re-export the new consistent export schema. This is a simple solution which could be further automated. To alleviate semantic heterogeneity, we decided to develop an interactive schema integration tool, called the schema Integrator Workbench (IW). The tool graphically helps the administrator during his/her integrated view design and generates all required mapping structures in the client dictionary. Mapping structures are expressed using OQL, which is the basic query language. This choice was justified to simplify the query modification to take into account the mappings from integrated schemas to exported schemas. However, it appeared limited due to the lack of outer join in OQL.
2.3 Identifying Objects Distributed object identification is a difficult issue. A common format for object identifiers has to be provided and understood by all participant systems. Thus, a distributed object system has to provide procedures to identify objects. For example, the CORBA architecture supports a naming service and an interface to derive identifiers from names (the bind command). In databases where there exists a large number of fine granularity objects, it is in general impossible to name objects. Having a global identifier generator is also impracticable. Thus, to overcome the difficulty, we specified a compound format for object identifiers. An object identifier is composed of two parts : a local database identifier (in practice, a site number) to determine the responsible system for the object, and a bit string which is specific to each local system. The bit string has to be interpreted locally by the local database system. For example, to provide identifiers for a relational system, the local component of IRO-DB (i.e., the adapter) may manage tables converting identifiers to keys. An other solution is to perform some key encoding to generate the bit string part of a global identifier.
2.4 Choosing an Interchange Protocol Various interchange protocols could be chosen to send requests and receive answers. One object at a time protocols are known as inefficient. Thus, a good system should provide multiple object interchange protocol, with request to select the required objects. For relational
systems, the X/OPEN Group in collaboration with the SQL Access Group is promoting a protocol based on SQL named FAP (Format and Access Protocol) with a C application program interface (API) for database access under the name CLI (Call Level Interface)[28]. This interface is composed of a set of functions to establish a connection, send an SQL query, receive the results, and control transactions. Generalizing such protocols to object-oriented databases requires both the use of object extensions of SQL (e.g., OQL from ODMG), the generalization of commands to get results and method invocation on a specific object. This was the approach chosen in IRO-DB. Other possible solutions could have been to use the CORBA IIOP protocol or the HTTP protocol. However, both were only emerging at the time of the design, and were rejected for their lack of maturity. Java RMI was even not known at that time.
2.5 Managing Integrated Objects Integrated objects have to be created at the execution time in order to populate the integrated views and to be accessed through OML/C++. Two alternatives are possible to handle integrated objects on a client site : Such objects can be only transient and created as instances in C++ classes in memory. Another approach is to provide persistence for them, for example by integrating them into local object-oriented databases. This second approach gives better flexibility to manage complex views, possibly connected through relationships with other views or with local classes. It requires a powerful object-oriented home DBMS, but gives the opportunity to develop efficient home applications connected with remote data made concrete when needed. Managing concrete interoperable views is a difficult problem ; however, approaches have been suggested through triggers on server sites. We started the first phase of the project with the intent to provide persistent integrated views. Thus, we select an ODBMS to manage them (ONTOS) as virtual classes, capable of being concretized. After 18 months of extensive design and a first implementation, the approach appeared to have severe drawbacks : (1) implementing the integrated view support within ONTOS was more difficult than expected, as some system integration at the low level of ONTOS was required, (2) the client IRO-DB system was ONTOS dependent, (3) every user will have to buy ONTOS, and finally (4) replacing ONTOS by another ODBMS was rather a hard task due to a lack of compatibility between DBMSs. Thus, in the second phase of the project, we gave up this option and we replaced the home DBMS by an integrated object manager handling objects, method dispatching and object caching in main memory [10].
2.6 Optimizing Distributed Queries Query optimization in federated databases is a difficult task. Queries are formulated through integrated views. Thus, after parsing, they have to be translated to refer to imported schemas. Query optimization has then to take place to re-order operations and to decompose the query first into sub-queries addressed to local sites and second into a synthesis query processing the resulting objects. Caching mechanisms have also to be integrated. Several issues have to be considered during the design of a query optimizer : 1. What intermediate language is going to manipulate the query optimizer ? Query trees can be based on an object algebra, on a functional language [19], or on a direct representation of the source language (e.g., an OQL syntactical tree). 2. What cost model is going to be considered ? A fine optimization requires the use of a cost model including CPU time, I/O time and communication time. A problem with heterogeneous systems is that the cost models of the participating systems are generally unknown at the federation level. 3. How rewriting rules are going to be implemented ? To generate various query plans in the optimization process, rewriting rules have to be applied. The optimizer can be designed as a black-box (e.g., it implements a determined set of rules and is very difficult to extend) , or easy to extend with provisional support for various types of rules. For simplicity, we use query tree resulting directly from OQL query parsing. A query tree is a direct representation of an OQL query, possibly nested. It is called an Object Expression Tree (OET) and directly represents an OQL query as a set of C++ objects. Objects represent the SELECT, FROM and WHERE clause, or a method call, or a path traversal, etc. The particularity of OQL is that any object can be used either in the SELECT, or in the FROM or in the WHERE clauses making the language difficult to optimize and to evaluate. In the context of IRO-DB, query expressed on integrated views are strongly nested and require specific optimizations rules. OET are rewritten using rules directly written in C++. The optimizer is extensible in the sense that new rules can be added.
2.7 Managing Distributed Transactions Another problem — and probably not the last — is the management of distributed transactions. Handling flat transactions as in SQL is safely performed using a two step commit protocol. Handling nested transactions on heterogeneous system is a complex issue, which is not well-understood yet. Permissive locking protocols taking
into account commutativity of operations are much effort to implement, and need extensions of the ODMG transaction model [33]. Thus in this project, we have adapted the optimistic ticketing method [14] to the ODMG transaction model (see also Section 5.7). Intertask dependencies can serve as a framework for defining extended transaction models [1].
3. IRO-DB Architecture overview The architecture of the system is organized in three layers of components as represented in Figure 1 [12]. In this section, we introduce each layer and we then describe more precisely some important components.
3.1 System Layers At the interoperable layer, object definition facilities stand for specifying integrated schemas, which are integrated views of the federated databases. We fully support the ODL view definition language, with many to many relationships. An interactive tool called the Integrator Workbench (IW) is offered to help the database administrator in designing his/her integrated view. Views and export schemas are stored in a data dictionary. Object manipulation facilities include an embedding of OQL in the OML/C++ user language and modules to decompose global queries into local ones (global query processor) and to control global transactions (global transaction management). Object definition and manipulation facilities are built upon the integrated object manager (IOM). The communication layer implements object-oriented Remote Data Access (OO RDA) services through the Remote Object Access (ROA) modules, both on clients and servers. Integration of the ROA protocol within the interoperable layer is provided through the object manager, which is able to manipulate collection of any types. Thus, it is possible to invoke OQL/CLI primitives to retrieve collections of objects stored on the local site. OQL/CLI primitives include connection and deconnection, preparation and execution of OQL queries with transfer of results through collections of objects, plus some specific primitives to import at the interoperable layer the exported ODMG schemas, as well as a primitive to perform remote method invocation.
Interoperable Layer
Integrator Workbench
ODL/C++ Environment
C++ / API OML
Data Dictionary
Global Query Processor
Global Object Manager
GTransaction Manager Security Manager
Local Layer
Local Object Access Local DB Adapter
D D
INGRES
Local Object Access Local DB Adapter ONTOS
D D
Local Object Access Local DB Adapter
Interoperable Layer
Global Object Manager
Client Import Schema
Remote Object Access Communication Layer
Remote Object Access (ROA) Communication Layer
Object ODMG Interoperable Schema
Users & Applications
Administrator
Local Object Access Export Schema
D D
Local DB Adapter
Local
Object ODMG (exported)
Server Local Schema
Layer
Object ODMG (imported)
ODBMS X
X
MATISSE/O2
Figure 2 : Schema Architecture. Figure 1 : The IRO-DB system architecture. The local layer is composed of Local Database Adapters (LDA). A local database adapter provides functionalities to make a local system able to answer OQL queries on an abstraction of a local schema in term of ODMG schema (export schema). As an export schema only describes locally implemented types, only locally available functionalities are available for querying through OQL. That means for example that methods and access paths cannot be invoked with simple LDA whose does not know how to export complex ODMG schemas. In that case, only flat objects without relationships are handled at the local layer for relational systems. Of course, if the local system supports the full ODMG model, all syntactically correct ODMG queries are acceptable.
3.2 Schema Architecture The schema architecture is described in Figure 2. Each local database of a local DBMS is described with a schema called local schema. A local schema describes the subset of a database that a local system allows to be accessed by cooperating systems. Each local schema is defined using the data definition language of the correspondent local DBMS. An export schema is obtained by translating a local schema into the ODMG objectoriented data model derived from the OMG object model. We should emphasize that IRO-DB does not define a global integrated schema, but defines interoperable schemas, also called integrated views. Each interoperable schema is an integration of part of export schemas included in a federated database, with a unique semantic for all object types and operations. It consists of a set of derived classes with relationships together with mappings to the underlying export schemas.
3.3 System Components We now describe some of the system key components. 3.3.1 The Integrator Workbench The integrator workbench generates from a graphic interface the ODL description of an integrated schema, plus some mapping definitions using OQL and C++ method profiles. Integration is done one exported schema after the other. At first, two exported schemas are displayed using a graphical view of the object model. Classes are represented as nodes. Two types of arcs are used to represent relationships and generalizations linking class nodes together. Attributes and methods are directly linked to the class they belong to using aggregation arcs. A naïve schema integration is first perform by union of the two graphs. Then, integration is performed under the direction of the database administrator, which specifies similarities between the export schemas. For example, with the CIM test-bed application, we integrate two databases as represented in Figure 3. Site 1 manages parts and manufacturers. Site 2 manages parts. The G::PART integrated view is a class with a one-tomany relationship referencing manufacturers, i.e., G::MANUF. The integrator workbench generates the view definition in ODL and the mapping to the import schemas given in Figure 4.
Derived Classes
G::PART
G::MANUF
1:N object mapping
Imported Classes
G::S1_PART
G::S1_MANUF
G::S2_PRT
Interoperable system 1:1 object mapping
External Classes
S1::part
S1::manuf
Local ODMG system1
S2::prt Local ODMG system2
Figure 3 : Example of integrated databases.
Interface PART (extent keys attribute attribute attribute relationship
parts part_id) { String part_id; Date upd_date; String description; Set manufs inverse MANUF::parts ; }
mapping PART { sorig, iorig; origins def_ext select PART(sorig : s_inst, iorig : i_inst) from s_inst in s_parts, i_inst in i_prts where s_inst.part_id = i_inst.prt_id; def_att part_id as this.sorig.part_id; def_att upd_date as this.sorig.upd_date; def_att description as this.sorig.description; def-rel manufs as select me from me in manufs where ( this.sorig = me.sorig.part) or (this.iorig = me.iorig.part);
Figure 4 : Definition of a derived class. 3.3.2 The Global Query Processor The Global Query Processor goal consists in processing queries against an integrated schema. It is responsible for decomposing the query in order to identify the necessary object transfers and consequently the sub-queries that should be sent to local databases. It is composed of three components described below. Their complete description is presented in [11,27]. • Translator. It manages OQL queries expressed against derived classes and translate them in equivalent OQL queries expressed against imported schemas. The intuitive principle of translating a query expressed on derived classes consists in replacing all derived class extent names by their mapping definition. The translation process uses the derivation specification of each class available in the repository. If there are several layers of derived classes, the query is translated recursively, until it refers to imported classes only. • Optimizer. The optimizer task consists in improving the query processing performance. For that, it applies a set of rules to minimize the object transfers and the communication cost between the IRO-DB client and the local databases. At first, a cost model was designed for the optimizer using a calibrating approach [13]. Although some ODBMSs were calibrated, the cost model was finally not used and heursitics were used. First, rules are applied to flatten the query as much as possible. Next, selections (i.e., restrictions and projections) are moved down the tree. Finally, caching rules are used to avoid transferring objects already in the client cache.
• Decomposer. The query decomposer identifies sub-trees which refer to mono-site queries and generates the OQL corresponding sub-queries. The query decomposer generates an execution plan composed of two distinct parts : (i) the set of sub-queries executed on local DBMS, (ii) the synthesis query corresponding to the part of the query tree to evaluate globally. 3.3.3 The Global Object Manager The Global Object Manager ensures virtual object management for the imported and derived objects. It allows objects creation and access and guarantees their identity at the interoperable layer. The Object Manager imports objects from external database systems and combines them into a uniform representation by creating surrogate objects. In IRO-DB the management of imported classes differ from the management of derived class. The instantiation of an imported class is not necessary for the evaluation of an OQL query. On the contrary, for all queries that return derived objects as opposed to structured values, it is mandatory to create derived objects since they do not exist in other remote databases. The instantiation of a virtual class is done by its constructor method [6]. 3.3.4 The Remote Object Access The Remote Object Access component is implementing the CLI interface for OQL queries on TCP/IP. It provides a set of commands to manage contexts, connections, export schemas, statements, results and transactions as shown in Figures 5 and 6. We have modified the standard CLI interface to handle OQL queries in place of SQL, but also and mainly to handle collections of objects in place of tuples. Thus, primitives to handle object descriptions have been added. Iterators have been introduced and standard OML primitives to cross a collection through an iterator have been added. The implemented additional interfaces are given in Figure 6. Resource Management
Connection Management
OQLAllocEnv();
OQLConnect();
OQLAllocConnect();
OQLDisconnect();
OQLAllocStmt(); OQLFreeEnv(); OQLFreeConnect();
Statement Execution Management
Transaction Management
OQLPrepare();
OQLTransact();
OQLBindParam(); OQLSetParamValue();
Export Schema Management
OQLExecDirect(); OQLExecute();
Error Management
OQLCancel();
OQLFreeStmt(); OQLExportSchema();
OQLSMSelect();
OQLError();
Figure 5 :OQL CLI primitives. An ad-hoc protocol derived from FAP has been implemented to support the transfer primitives, using XDR for encoding. Commands are bundled into messages
by the ROA and unbundled on the server by the LOA. An object is transfered as a structures of values with a tag giving the type of each attribute. Similar objects are organized in collections (list, set, bag and arrays) both on the server site and the client site, according to the query result type. Collections of similar objects are packed in pages for improving the transfer rate. Iterator primitives
OQL-CLI primitives OQLDescribeResult();
Operations on collections :
Although we design a generic adapter for ODMG databases, we quickly discovered that each ODBMS interface is specific. Thus, except the common libraries which are those of the relational LDA, the object LDAs have no common modules. The O2 LDA is mainly implementing a dynamic OQL on top of O2. Each OQL query is translated into a selection of object identifiers and then into some accesses to the relevant object attributes or methods. The MATISSE LDA is very specific ; it interprets OQL queries using the MATISSE C API.
Coll.create_iterator();
OQLDescribeObj();
Operations on iterators :
OQLObjCount();
4. System Integration and Applications
Iter.first();
OQLBindObj();
Iter.last();
OQLFetch();
Iter.next(); Iter.previous();
OQLGetResult();
Iter.more();
OQLGetObj();
Figure 6 : Primitives to handle results. 3.3.5 The Local Database Adapters The role of local database adapter (LDA) is to execute received OQL queries on top of the local database and to send back results through the Local Object Access module (LOA). It accesses to the local data dictionary containing the definition of the export schema referenced by the query. To populate the dictionary from a local database schema, each LDA provides an export schema builder. There is a tool reading the relevant part of the local database schema and building an ODMG counterpart. The architecture of the relational LDA is represented Figure 7. It is composed of a set of common libraries to manipulate queries (i.e., parse, unparse, and transform) and manage results as collection of objects. The set of relational libraries is composed of a generic translator of OET in SQL and procedures to transform tuples in objects with identifiers. On top of each relational system is implemented a specific module to implement a CLI similar interface. In the prototype, only the INGRES LDA has been implemented. However, there are plans to develop the ORACLE and DB2 specific modules. LDA Common
Libraries + LINK TIME
LDA Relational Libraries
In this section, we report on practical aspects of the project, namely the system integration and the demonstrator application.
4.1 System Integration IRO-DB is an Esprit project. As such, it was implemented through a cooperation of research centers (GMD, PRiSM, FAW) and industrial partners (IBERMATICA, EDS, EURIWARE and INTRASOFT). While IBERMATICA and EURIWARE were responsible of LDAs, EDS was responsible of the communication layer. The interoperable layer was mainly implemented by GMD, except for the global query processor implemented by PRiSM, and the global query evaluation and security management done by FAW. The engineering was a bit difficult, but clear C++ class interfaces were specified, which facilitated distributed software engineering. A set of typical tests were defined for each component and a software delivery procedure was defined. A first integration was performed at GMD without the object local database adapters. A bunch of queries was run demonstrating the system capabilities. The final integration started in November 1996 at Intrasoft in Greece, with the relevant LDAs for the CIM application, and ended in April 1997, where a final demonstration was run. The application was partially running and an interactive OQL query processing facility was available for almost of types of queries, including joins and aggregates. However, due to difficulties with the ONTOS LDA, the query could not involve selection predicates pushed to ONTOS. Also, a limited support of distributed transactions was demonstrated, as objects updating was not possible with ONTOS.
+ LINK TIME Specific INGRES Module
Specific ORACLE Module
Specific DB2 Module
Figure 7 : The architecture of relational LDAs.
4.2 Application Demonstrator In order to demonstrate the IRO-DB capabilities and to illustrate how to define a CIM application with IRO-DB, Intrasoft, the user partner in the project, implemented a
subset of the INTRACOM CIM application [24]. The existing application is mainly transfering data from a hierarchical database (HP TurboImage) to a relational database (Ingres). The hierarchical database was reengineered on top of ONTOS. The federated database was run on Unix SUN as shown in Figure 8. The final application should share data between a SUN machine running INGRES and a DEC Alpha running an object DBMS. Federated Enineering Information System IRO-DB DBMS API Calls Calls
Demonstration Sun Sparc
IRO-DB (INGRES) LDA
IRO-DB Communication Layer (ONTOS) LDA
INGRES DBMS
ONTOS DBMS
DEC Alpha
SUNSpar c
Figure 8 : The demonstrator architecture. The simple exported schemas of each local database is given in Figure 9. It is composed of the two autonomous databases called INTRACIM (the relational one) and SYDIP (the object-oriented one). Both systems contain information about parts respectively named PART and PRT in SYDIP and INTRACIM systems. To each part corresponds a set of orders (EMPS). part_id PART
emps
> part
EMPS
description qty
date
SYDIP system
IRO-DB
Local Adapter
Local Adapter
Exported Schema (ODMG) Local Schema (Relational , Object)
SYDIP (ONTOS)
INTRACIM (INGRES)
emps
PRT
qty prt_id
prt_dsc
The application demonstrator was integrated in Greece and run succesfully at the review. However, due to difficulties with the ONTOS LDA, global updating transactions were not fully supported. The experience demonstrated the following advantages over the previous application version, which was using file transfers (FTP): 1. Better data validation due to the compiled interface in C++ ; 2. Better response time due to the caching mechanisms implemented at the global object manager; 3. Faster development time due to the integrated views and the OML/C++ interface supporting OQL query facility. 4. Eased migration path to Object-Oriented technology. The maintenance of the application should also be facilitated, as it is now written in standard language (C++) and not in an exotic 4GL. However, the application responsibles are still wondering what technology to use for the future version of the application. They are notably not convinced by the object database technology.
5. Discussion of some IRO-DB choices
dt
