METU Interoperable Database System A. Dogac, C. Dengi, E. Kilic, G. Ozhan, F. Ozcan, S. Nural, C. Evrendilek, U. Halici, B. Arpinar, P. Koksal, N. Kesim, S. Mancuhan Technical Report 6-1, June 1995 Software Research and Development Center Scienti c and Technical Research Council of Turkiye Middle East Technical University 06531, Ankara Turkiye e-mail:
[email protected]
Abstract METU INteroperable Database System (MIND) is a multidatabase system that achieves interoperability among heterogeneous, federated DBMSs. MIND architecture is based on OMG distributed object management model. It is implemented on top of a CORBA compliant ORB, namely, ObjectBroker. MIND provides users a single ODMG-93 compliant common data model, and a single global query language based on SQL. This makes it possible to incorporate both relational and Object oriented databases into the system. Currently Oracle7, Sybase and METU OODBMS (MOOD) has been integrated to MIND. The main components of MIND are a global query processor, a global transaction manager, a schema integrator, interfaces to supported database systems and a graphical interface. In MIND all local databases are encapsulated in a generic database object with a well de ned single interface. This approach hides the di erences between local databases from the rest of the system. The integration of export schemas is currently performed manually by using an object de nition language (ODL) which is based on OMG's interface de nition language. The DBA builds the integrated schema as a view over export schemas. The functionalities of ODL allow selection and restructuring of schema elements from existing local schemas. MIND global query optimizer aims at maximizing the parallel execution of the subqueries. Through MIND global transaction manager, the serializable execution of the global transactions are provided.
Bilkent University, 06533, Ankara Turkiye
1 Introduction In today's enterprises information is typically distributed among multiple heterogeneous database management systems. The heterogeneity exists at three basic levels. The rst is the platform level. Database systems reside on di erent hardware, use di erent operating systems and communicate with other systems using di erent communications protocols. The second level of heterogeneity is the database management system level. Data is managed by a variety of database management systems based on di erent data models and languages (e.g. le systems, relational database systems, objectoriented database systems etc.). Finally the third level of heterogeneity is that of semantics. Since di erent databases have been designed independently semantic con icts are likely to be present. This includes schema con icts and data con icts. Commercially available technology o ers inadequate support both for integrated access to multiple databases and for integrating multiple applications into a comprehensive framework. Some products o er dedicated gateways to other DBMSs with limited capabilities. Thus, they require a complete change of the organizational structure of existing databases to cope with heterogeneity. Another way of achieving interoperability among heterogeneous databases is through a multidatabase system. A multidatabase system (MDBS) is a database system that drives other database systems and allows the users to simultaneously access independent databases using a single data de nition and manipulation language. The primary objective of a MDBS is to significantly enhance productivity in developing and executing applications that require simultaneous access against multiple independent databases. A multidatabase sys-
tem provides a single global schema that represents an integration of the relevant portions of the underlying local databases. This in turn requires the support of a single common data model and a single data de nition and manipulation language. The users may formulate queries and updates against the global schema. We have implemented a multidatabase system, namely, METU INteroperable Database system (MIND) on a CORBA compliant ORB implementation, namely, DEC's ObjectBroker. DEC's ObjectBroker runs on several platforms such as Windows, SunOS, AIX, Open VMS. Our implementation platform is SunOS. CORBA(The Common Object Request Broker Architecture) which is developed by the Object Management Group (OMG) [OMG 91] is a speci cation and an architecture that provides implementation independent access to objects on heterogeneous systems. In other words CORBA handles the heterogeneity at the platform level. In CORBA, clients ask for work to be done and servers do that work, all in terms of tasks called operations that are performed on entities called objects. Applications interact with each other without knowing where the other applications are on the network or how they accomplish their tasks. By using CORBA's model, it is possible to encapsulate applications as sets of distributed objects and their associated operations so that one can plug and unplug those client and server capabilities as they need to be added or replaced in a distributed system. These properties provide the means to handle heterogeneity at the database level. Thus CORBA provides for an infrastructure for implementing a multidatabase system. Semantic interoperability remains to be solved at the application programming level. We have de ned an interface of a generic Database Object accessible through CORBA and developed multiple implementations of this interface for Oracle7, Sybase and MOOD (METU Object-Oriented Database System) [DEOO 94, Dog 94, Dog 95, DAOD 95]. The current implementation makes it possible to access any of these databases through CORBA using a global query language based on SQL. When a client application issues a global SQL query to access multiple databases, this global query is decomposed into local subqueries and these subqueries are sent to the ORB (CORBA's Object Request Broker) which transfers them to the relevant database servers on the network. On a server site, the local subquery is executed by using the corresponding call level interface routines and the result is returned back to the client again by the ORB. The results returned to the client from the related servers are processed by the client if necessary. A general overview of the system is presented in Figure 1.
MIND 1 Application
Server-2 Oracle Impl.Sybase Impl.
SyBase Server
Oracle MIND 2 Application
Server
ORB
Server-1 Oracle Impl. MIND
MOOD Other DBMS Impl. Impl.
3
Application Oracle Server
MOOD Server
Other DBMS Server
Figure 1: A General Overview of the System The rest of the paper is organized as follows. In Section 2, we provide a brief overview of CORBA. The architecture of the MIND system is described in Section 3. Section 4 presents the infrastructure of the system. The design decisions and experiences in developing generic Database Object implementations for various DBMSs are discussed in this Section. Section 5 describes the schema integration in MIND. The global query manager of the system is given in Section 6. In Section 7, the global transaction manager is described.
2 What is CORBA? CORBA is the core communication mechanism which enables distributed objects to operate on each other. There is another complementary standard developed by the OMG, called Common Object Services Speci cation (COSS), for integrating distributed objects. COSS [OMG 94] provides a set of standard functions to create objects, control access to objects, keep track of objects and object references. CORBA (the Common Object Request Broker Architecture) [OMG 91] is both an architecture and a speci cation for distributed object-oriented computing that has implementations currently available from several major software vendors (e.g. ObjectBrokerDEC, DistributedObjectsEverywhere-SunSoft, System Object Model-IBM, Distributed Smalltalk-HP, OrbixIona Technologies). It should be noted that some CORBA implementations also contain COSS features such as Object Life Cycle Services, Name Services and Event Services [OMG 94]. CORBA uses an object-oriented model and de nes
Client Program Client Part of the Client Interface CORBA Interface
CORBA Interface
Client side of Client Interface Global Client
Server side of Client Interface Cursor Impl.
OQL Parser Decomposer
GDR
Global Data Repository
Manager
Query Processor Optimizer Global Transaction Manager
GDA
LDA
LD Client
GDA CORBA Interface LDA
LDA
Server Side of the Client Interface OQL Parser
LD
LD
Cursor Implementation
OQL to Local SQL Translator
Type Converters
Export Schema Repository
Local Data Repository
Interface to Local DBMS (e.g. CLI)
Figure 2: An Overview of the MIND Architecture the Object Request Broker (ORB) as an intermediary between clients and servers. In this model, clients send requests to the ORB asking for certain services to be performed by whatever servers can ful ll those needs. Only the ORB needs to know the locations of CORBA clients and servers on the network, that is, it is completely transparent to the client where the server is on the network and similarly, the location of the client is transparent to the server. A library of functions, which is called Basic Object Adapter, is used by the server program to locate and initialize the server implementation and to invoke the appropriate method to satisfy the client request. CORBA restricts communication between the client and the server to a type of message called a request . Each request is sent from the client to the server and it contains an operation to be performed and a speci c object on which the operation is to be performed. The objects and operations that a client can request and to which a server can respond are de ned by the interface that both the client and the server support. In objectoriented terminology an interface is very similar to a class de nition which de nes the characteristics and behavior of a kind of object [DEC 94a]. In CORBA, interfaces are de ned using the Interface De nition Language (IDL). When an IDL code is compiled by the CORBA compiler, it generates client
stubs and server skeletons. The server skeleton makes it possible for the ORB and an object adapter to translate the client request to a speci c method on the server. A client stub maps IDL operation de nitions for an object type into procedural routines that is called to invoke a request. CORBA's object-oriented model provides several bene ts that make it easier to integrate applications into a distributed system. First of all it allows the designers to take the advantage of many object-oriented design techniques, such as encapsulation, information-hiding and inheritance.Object-oriented design techniques encourage the designer to de ne each object in the system as a black box that is capable of performing certain tasks, without the system knowing how that black box accomplishes those tasks. Second, it provides more clearly de ned interfaces between the parts of the system, which can be changed without a ecting the entire system. This enhances software modularity so that software components can be worked on more independently. When a new capability is added to the system, it is simply de ned as a set of new operations on one or more changed objects. Third, the technique of inheritance promotes the reuse of software by allowing the properties and behaviors of one object to be subsumed by another. And nally, CORBA is not a pure object-oriented system
4 The Infrastructure of MIND
with its own language, but a hybrid object-oriented system that allows one to create an object-oriented system using more familiar programming languages, such as C As an initial step in implementing the MIND system, we encapsulated Oracle7, Sybase, MOOD DBMSs in and C++ . multiple implementations of a generic Database Object. The Database Object conveys requests from client to the underlying DBMSs by using the Call Level Interfaces of these DBMSs. The call interfaces of these sysMIND architecture is based on OMG distributed ob- tems [ORACLE 92, SYBASE 90, Dog 95] support SQL ject management model. In other words, MIND al- data de nition, data manipulation, query, and translows clients (users and application programs) to ac- action control facilities. We have used C++ call level cess databases that reside anywhere in the environment interface to access these database servers. Results of transparently and without having knowledge of loca- the requests returned from the call level interfaces of tion or format of queries or operations involved. That underlying DBMSs are conveyed to the client through is, what clients see are homogeneous objects acessible CORBA. through a common interface. The common interface's Our basic implementation decisions in registering data model (i.e., the canonical data model) is ODMG- di erent databases to CORBA are as follows: 93 and the query language of the interface is ODMG-93 1) Object granularity: In CORBA, objects can query language namely, OQL. Currently only a subset be de ned in di erent granularities. In registering a of OQL is operational. DBMS to CORBA an object can be a row in a relation An overall view of MIND Architecture is provided or it can be a database When ne granularity is provided in Figure 2. The basic components of the objects are registered, dueitself. to insertion and deletion of system are as follows: objects,it may be necessary to recompile the IDL code. 1. A collection of local database agents (LDA). Each Furthermore IDL code will be voluminous. Therefore we have de ned each database as an object. LDA: Figure 3 illustrates invoking an operation to a maintains export schemas provided by the lo- database object instance. cal DBMSs represented in ODMG-93 data 2) Invocation style: CORBA allows both dymodel, namic and stub-style invocation of the interfaces by the translates the queries received in common client. query language (OQL) to the local query lanIn stub-style interface invocation, the client uses guage and back. generated code templates (stubs) that cannot be changed. Stubs provide code for invoking methods so 2. A collection of global database agents (GDA). A that the method invocation is similar to a standard proGDAcontains a global integrated schema, cedure call, thereby reducing the complexity of method invocation. a global query processor that is responsible In dynamic interface , the client de nes and builds from parsing, decomposing, and optimizing requests as it runs. The dynamic interface, provides the queries [EDNO 95], clients with more exibility, allowing the use of deferred a global transaction manager that ensures serisynchronous operations and new interfaces. It is best alizability of multidatabase transactions with- used when application to discover new types of out violating the autonomy of local databases. objects at run time. Weneeds have chosen to use stub-style interface because in our current implementation all the objects are known and the interface that the clients use Clients access the MIND system through a collection is not likely to change over time; there is no need for Global Database Agents (GDA). For a client a GDA is dynamic invocation. a server. From GDA's point of view, LDAs are servers. 3) Mapping client requests to servers: In assoSymmetrically from LDA's point of view a GDA is a ciating a client request with a server method, CORBA client. provides the following alternatives: The infrastructure of the system is build on a i. One interface to one implementation CORBA implementation, namely, DEC's ObjectBroker ii. One interface to one of many implementations [KOD 95]. The DBMSs currently registered to the sysiii. One interface to multiple implementations tem are Sybase, Oracle7 and MOOD[Dog 94, Dog 95, DOAD 95]. When mapping one interface to one implementa-
3 MIND Architecture
Database Client An object reference to a DB Object Operation Client Stub
ORB
Object Adapter Server Skeleton A Method Object Implementation DBMS Interface
Database Server
DBMS
Figure 3: Invoking an operation to a Database Object instance through ORB tion, there is a direct one-to-one relationship between the operations in the interface and the methods in the implementation. Although the simplicity of this approach is an advantage, it has the disadvantage of being fairly in exible because each operation must be supported by a method in the implementation, and the operations and methods must match each other exactly. In the second alternative, for any one interface, it is possible to have several di erent implementations. Here again, there is a direct one-to-one relationship between the interface operations and the methods in the implementations, however, one can have several implementations which might be on di erent servers. Allowing multiple implementations gives the exibility to have di erent, but similar, implementations for the same in terface. The third alternative makes it possible to have multiple implementations associated with the same interface, with each implementation providing only a portion of the interface. Since every database management system registered to CORBA provides methods for all of the operations that the interface de nition speci es, the second alter-
native is sucient for our purposes. 4) Object Life Cycle: A client application needs an object reference to make a request. In CORBA, the initial object reference can be obtained in one of the following three ways: i. The application developer can build the object reference into the client. This requires the client application to be compiled together with the server application. During compilation a built-in object reference is generated in both codes. Thus the rst request is statistically bound to this built-in object reference. ii. The client can get the object reference from an external source. This external source could be a le or a database containing initial object references in string form. iii. ObjectBroker allows servers to store initial object references in the Advertisement Partition of Registry. Then clients can access the Advertisement Partition to obtain object references using the Naming Service of COSS. The rst approach makes the system in exible since it requires that all client applications must know the statically bound object references to make any requests. The second approach is not suitable either, since it is not feasible to maintain or replicate a single le or a database as an external source in a distributed environment. Therefore we have chosen the third approach to get initial object references. Every DBMS server puts an initial object in the Advertisement Partition of Registry of ORB. Object references selected from the Advertisement Partition are then used to get the object references of the corresponding DBMS objects and to connect the client to that speci c database. In this way each client has its own object to communicate with the DBMS servers. 5) Activation Policy: A server code contains several implementations for the interface de ned one for each of the databases. So every site can have Oracle7, Sybase, MOOD database servers. There is a direct oneto-one relationship between the interface operations and the methods in the implementations. When registering di erent databases to CORBA, one has to specify an activation policy for the implementation of each DBMS. This policy identi es how each implementation gets started. An implementation may support one of the following activation policies : i. Shared : The server can support more than one object for the implementation. ii. Unshared : The server can support only one object at a time for the implementation. iii. Server per method : A new server is used for each method invocation.
iv. Persistent : The server is never started automatically. Once started, it is the same as the shared policy. The shared activation policy is best suited to our server implementations since it is used when multiple objects are related and handled by the implementation. In our system, more than one client may request an object of a database implementation. Therefore the implementations of DBMSs must support shared activation policy. This policy also allows the server to be more
exible. 6) ORB Binding policies: ORB has di erent binding policy options to resolve object references. Note that there could be more than one implementation for an interface. For example, in our case, there are different implementations of our generic Database Object for Oracle7, Sybase and MOOD. In binding a request to an implementation ORB provides the following policy options: i. Static : All methods for an implementation must be executed by one speci c server. ii. Automatic: All methods for an implementation must be executed by the same server, but the server can be any server that can handle that implementation. iii. Dynamic: Each method for an implementation can be executed by a di erent server. The static binding is best used when only one, speci c implementation can handle an interface's operations for the duration of the process. But in our implementation any server can support more than one implementation of the interface's operations. So static binding is also not suitable for our implementation. In our implementation all the interface's operations are handled by each of the DBMS's implementation. So there is no need to use dynamic binding which is best when the interface's operations can be processed independently but worse on performance than the other bindings since method resolution is necessary for each method invocation. We selected automatic binding so that the interface's operations are all handled by one implementation but also, more than one instance of an implementation can exist at a time. Performance of servers with automatic binding is generally better than for servers with dynamic binding because method resolution is bypassed after the initial method invocation. Automatic binding provides more than one instance of an implementation.
autonomy and heterogeneity in a multidatabase system. This schema architecture includes four di erent kinds of schemas: 1) Local Schema: A local schema is the conceptual schema of a export database system. A local schema is expressed in the native data model of the export database and hence di erent local schemas may be expressed in di erent data models. 2) Export Schema: A export schema is derived by translating local schemas into a canonical data model (which is ODMG-93 in our case). The process of schema translation from a local schema to a export schema generates mappings between the local schema objects and the export schema objects. 3) Derived (Federated) Schema: A derived schema combines the independent export schemas to a (set of) integrated schema(s). A federated schema also includes the information on data distribution (mappings) that is generated when integrating export schemas. The global query processor transforms commands on the federated schema into a set of commands on one or more export schemas. 4) External Schema: In addition, it should be possible to store additional information that is not derived from export databases. An external schema de nes a schema for a user or application. An external schema can be used to specify a subset of information in a federated schema that is relevant to the users of the external schema. Additional integrity constraints can also be speci ed in the external schema. The classes in export and derived schemas behave like ordinary object classes. They consist of an interface and an implementation. But unlike ordinary classes, which store their objects directly, the implementation of the classes in these schemas derives their objects from the objects of other classes.
5.1 Classi cation of Schema Con icts
With the local databases transformed into equivalent ODMG schemas, potential schematic con icts between the export schemas are identi ed according to the following classi cation framework. 1) Semantic Con icts (Domain Con icts): Two designers do not perceive exactly the same set of real world objects. For instance, a 'student' class may appear in one schema, while a more restrictive 'cs-student' class is in another schema. This is the rst kind of con icts which relate to the domains of classes. The domain of a class is the set of objects in that class. According to their domains, relationships between classes are classiMIND implements a four-level schema architecture that ed in four groups. addresses the requirements of dealing with distribution, a) Identical Classes : Classes in export schemas
5 Schema Integration in MIND
represent the same set of objects (e.g. 'instructors' in one database and 'lecturers' in another database). These classes are merged into a single class in the global schema. b) Intersecting classes: classes may represent overlapping sets of objects. For instance 'student' and 'employee' classes in two databases may have common objects which represent research-assistants. Such classes are integrated in the global schema as classes having a common subclass that contains the set of common objects. c) Inclusion classes: the domain of one class is a subset of another class (e.g. Employee - Manager). In the global schema the more restrictive class is represented as the subclass of the other class. d) Disjoint classes: These are classes whose domains are completely di erent but related (e.g. Graduate vs Undergraduate students). Such classes are generalized into a superclass in the global schema. 2) Structural Con icts (Descriptive Con icts): When describing related sets of real-world objects, two designers do not perceive exactly the same set of properties. This second kind of con icts include naming con icts due to the homonyms and synonyms, attribute domain, scale, constraints, operations etc. For instance di erent number of attributes or methods may be de ned for semantically equivalent classes; or di erent names may be used for identical attributes. Such con icts are resolved by providing a mapping between the class and attribute names in the global schema and class and attribute names in export schemas. This mapping is expressed in the object de nition language described in Section 5.2.
5.2 MIND Schema Integrator
In MIND schema integration is a two phase process: 1) Investigation phase: First commonalities and discrepancies among the export schemas are determined. This phase is manual. That is the DBA examines export schemas and de nes the applicable set of inter-schema correspondences. The basic idea is to evaluate some degree of similarity between two or more descriptions, mainly based on matching names, structures and constraints. The identi ed correspondences are prompted according to the classi cation of schema con icts given in Section 5.1. 2) Integration phase: The integrated schema is built according to the inter-schema correspondences. The integration phase cannot be fully automated. Interaction with the DBA is required to solve con icts among export schemas. In MIND, the integration of export schemas is currently performed manually by using an object def-
inition language (ODL) which is based on OMG's interface de nition language. The DBA builds the integrated schema as a view over export schemas. The functionalities of ODL allow selection and restructuring of schema elements from existing local schemas. In ODL, a schema de nition is a list of interface de nitions whose general form looks as follows: interface classname:superclass_list { extent extentname; keys attr1; attribute attr_type attr1; ... relationship OtherClass relname inverse OtherClass::invrel; ... }
where classname is the name of the class whose interface is de ned; superclass list includes all superclasses of the class; extentname provides access to the set of all instances of the class; keys allows to de ne a set of attributes which uniquely identi es each object of the class. Attribute and relationship constitute the signature of the class. In addition to its interface de nition, each class needs information how to determine the extent and how to map the attributes onto the local ones. The general syntax for this mapping de nition is as follows: mapping classname { origin typename orig1, ... def_ext extname as select classname(orig1:i1,...) from ... in ... where ...; def_attr attname as query; ... def_rel pathname as [element (] select classname(orig1:i1, ...) from ... in ... where ... [)]; }
The keyword mapping marks the block as a mapping de nition for the derived class classname. The origin clauses de ne a set of private attributes that store the back-references to those objects, from which an instance of this class has been derived. The extent derivation clause starting with def ext de nes a query that provides full instantiation of the derived class. A list of def attr lines de nes the mapping for each attribute of the class. And nally a set of def rel lines express the relationships between derived classes as separate queries which actually represent the traversal path de nitions.
These are all speci cations necessary to describe the federated schema(s). We are currently developing a graphical tool which will automatically generate these textual speci cation of class derivations. Our ultimate aim is to establish a semi-automated technique for deriving an integrated schema from a set of assertions that state the inter-schema correspondences. The assertions will be derived as a result of the investigation phase. To each type of assertion there will correspond an integration rule so that the system knows what to do to build the integrated schema.
6 Query Optimization in the MIND project We attack two problems related with multidatabase query optimization: We formulate the query decomposition in multidatabases in case of data replication as the following optimization problem [EDNO 95]: - given an initial assignment of relations and fragments to the sites, distribute the modi ed and decomposed query to the sites such that the independent parallel execution time is optimized, i.e.,the load distribution is balanced. For this NP-Complete assignment problem we propose a heuristic solution. The second problem that we attack is the optimization of intersite joins. We note that there are three additional parameters to be considered: - the appearance times, - the communication costs and - the conversion costs of the local subqueries. We then propose a two-step heuristic algorithm for intersite join optimization: - The rst step produces a linear order from the query graph where the most pro table joins appear together in the linear sequence. - In the second step, this order is exploited to maximize the parallelism in execution of intersite joins by also taking the appearance times, the communication costs and the conversion costs of local subqueries into account. -The algorithm also produces the schedule, that is, the assignment of join pairs to the sites.
7 MIND Transaction Management Global Transaction Manager (GTM) controls the execution of global transactions that access data across sites through MIND to preserve database consistency (Figure 2). The correctness criterion for the execution of multidatabase transactions is chain con icting serializability [ZE 93]. Transaction Management is performed in a distributed manner, therefore global concurrency control (gcc) is more resilient to site failures than a centralized gcc. The problem in providing global serializability in multidatabases lies in the following: even though the local schedulers provide serializable executions and the execution order of the global transactions at all local sites are consistent, the global serializabilty may still be violated. Even tough global transactions are submitted and committed at all sites in the same order, their serialization order can change because of indirect con icts caused by local transactions. In [GRS 94] a practical solution namely the ticket method is suggested to enforce serializability of global transactions in an MDBS environment. In this method, arti cial con icts are introduced between multidatabase transactions at each site they are executing by reading and writing the same database item called a ticket. Ticket values determine the serialization order of multidatabase transactions at each site. If the local serialization orders of global transactions are consistent at all sites than the global serializability is ensured. In MIND the original ticket idea is extended and implemented in a distributed manner. Global transactions can be submitted to any of the participating sites which is capable of coordinating their execution. The GTM to which a global transaction is submitted becomes the coordinator for that transaction. GTM employees an optimistic scheduling algorithm which assigns a global timestamp (or global ticket value) to each global transaction submitted to MDBS. Global ticket value is assigned according to submission order of transactions to the system and incremented monotonically. Global ticket values are maintained distributedly and it is not necessary to obtain tickets from a speci c site. GTM determine sites involved in the global transaction and distributes the global subtransactions to Global Transaction Agent (GTA)s accordingly (Figure 2). GTAs at each site are responsible from processing global subtransactions and submitting them to Local DBMS (LDBS)s. Global subtransactions are serialized in the timestamp order at all sites. To enforce the timestamp serialization order of global transactions at all sites,
MDBS requires each subtransaction of a global trans- [EDNO 95] action to perform additional data manipulation operations on a common data item called ticket stored in the local database. This technique introduces forced local con icts between the subtransactions of global transactions at each LDBS. The ticket operations guarantee that the local serialization order is equivalent to the or- [GRS 94] der of ticket operations, or subtransaction is aborted by the local system. Hence, global serializability is maintained.
Evrendilek, C., Dogac, A., Nural, S., Ozcan, F., "Query Optimization in Multidatabase Systems", in Proc. of the Next Generation Information Technologies and Systems, Israel, June 1995. D. Georgakopoulos, M. Rusinkiewicz and A. Sheth, "Using Tickets to Enforce the Serializability of Multidatabase Transactions", IEEE Trans. on Data and Knowledge Eng., Vol. 6, No.1, 1994. [HFBK 94] Huck, G., Fankhauser, P., Busse, R., Klas, W., "IRO-DB : An ObjectOriented Approach towards Federated M.J.Carey, et. al., "Towards Heteroand Interoprable DBMSs", in Proc. of geneous Multimedia Information SysADBIS '94, Moscow, May 1994. tems: The Garlic Approach", in Proc. of RIDE-ROM '95 [KOD 95] E. Kilic, G. Ozhan, C. Dengi, N. Kesim, P. Koksal and A. Dogac, "Experiences Cattell, R.G.G., The Object Database in Using CORBA in a Multidatabase Standard: ODMG-93, Morgan KaufImplementation", in Proc. of 6th Intl. mann, 1994. Workshop on Database and Expert System Applications, London, Sept. 1995. The Guide to CORBA, Digital Equipment Coop., August 1994. [ODE 95] C. Ozkan, A. Dogac, C. Evrendilek, "A Heuristic Approach for Optimization of ObjectBroker, System IntegraPath Expressions", in Proc. of 6th Intl. tor's Guide, Digital Equipment Coop., Conf. on Database and Expert System August 1994. Applications, London, September 1995. Dogac, A., Evrendilek, C., Okay, T., [OMG 91] Object Management Group, "The ComOzkan, C., "METU Object- Oriented mon Object Request Broker: ArchitecDBMS", in Object-Oriented Database ture and Speci cation", OMG DocuSystems, edited by Dogac, A., Ozsu, T., ment Number 91.12.1, December 1991. Biliris, A., Sellis, T., Springer-Verlag, [OMG 94] Object Management Group, "The Com1994. mon Object Services Speci cation, VolDogac, A., et. al., "METU Objectume 1", OMG Document Number Oriented Database System", Demo De94.1.1, January 1994. scription, in the Proc. ACM SIGMOD Intl. Conf. on Management of Data, [ORACLE 92] Programmer's Guide to the Oracle Call Interfaces, Oracle Corporation, DecemMinneapolis, May 1994. ber 1992. Dogac, A., Altinel, A., Ozkan, C., Durusoy, I., Altintas, I., "METU Object- [SYBASE 90] Open Client DB-Library /C Reference Manual, Sybase Inc., November 1990. Oriented DBMS Kernel", in Proc. of Intl. Conf on Database and Expert Sys- [ZE 93] A. Zhang and A. Elmagarmid, "A tems Applications, London, September Theory of Global Concurrency Control 1995 (Lecture Notes in Computer Sciin Multidatabase Systems", Journal of ence, Springer-Verlag, 1995). VLDB, Vol. 2, No. 3, 1993. Dogac, A., Altinel, M., Ozkan, C., Durusoy, I., "Implementation Aspects of an Object-Oriented DBMS", in ACM SIGMOD Record, Vol.24, No.1, March 1995.
References [GAR 95]
[Cat 94] [DEC 94a] [DEC 94b] [DEOO 94]
[Dog 94]
[Dog 95]
[DAOD 95]
