I n f o r m i x

Architectural Options for

Object-Relational DBMSs

©1997 Informix Software, Inc. The following are worldwide trademarks of Informix Software, Inc.,Informix Corporation, or their subsidiaries, registered in the United States of America as indicatedby “®” and in numerous countries worldwide: Informix®, The Informix Logo®, DataBlade®, DynamicScalable Architecture™, Illustra™. All other names or marks are registered trademarks or trademarksof their respective owners.

4100 Bohannon Drive

Menlo Park, California 94025

1 415 926 6300

World Wide Web: http://www.informix.comPrinted in U

.S.A.–10K

–02/97–000-21460-70 Dr. Michael Stonebraker ♦ Chief Technology Officer ♦ Informix Software, Inc.

Unleashing Business Innovation

Informix Software is leading the next greatwave in database innovation to enables theworld’s leading corporations to manageand grow their businesses. With its focusedtechnology strategy, superior customer service, and best-or breed partnerships,Informix is the demonstrated technologyleader for corporate computing environmentsranging from workgroups to very largeOLTP and data warehouse applications—as well as a catalyst in major new IT trendssuch as dynamic content management, theWeb, smart cards, and mobile computing.

For more information about Informixproducts and services, please contact thesales office nearest you, or visit us on theWeb at www.informix.com

Regional Sales Offices

Asia/Pac i f i c65 298 1716

Canada (Toronto)416 730 9009

Europe/Midd le East/Afr i ca44 1784 422 000

Federa l703 847 2900

Japan81 3 5562 4500

Lat in Amer i ca305 265 7545

North Amer i ca800 331 1763415 926 6300

Table of Contents

Abstract

Introduction 1

Components Requiring Modification

to Create an Object-Relational Engine 3

Option 1: Supply Plug-In Code to

Make Function Calls to Other Applications 6

Option 2: Add Separate APIs and

Server Subsystems to Support Object Functionality 7

Option 3: Simulate Specialized

Object-Relational Functionality in a Middleware Layer 11

Option 4: Completely Redesign the Database Engine 17

Option 5: Add a New Object-Oriented Layer to Support

Rich Datatypes atop a Proven Relational Database Engine 18

Summary 19

References 20

Abstract

This white paper compares and evaluates current architectural options for

evolving relational database management systems to the new object-relational

paradigm. The objective is to achieve the benefits of both the relational and

the object models: both massive scalability and versatile object functionality,

including support for rich datatypes, such as video or 3-D graphics. First the

basic and necessary mechanisms for supporting an object-relational database

engine are explained. Then five current options for achieving object-relational

functionality are critically examined. The paper argues for the superiority of

a redesigned ORDBMS engine or a hybrid relational database engine with

an API supporting a “top” layer of rich ORDBMS datatypes.

Introduction

Object-relational technology is the next evolutionary step in the design of

universal database management systems. Leading enterprise DBMS vendors

have committed to object-relational database management systems (ORDBMS)

because this model alone can efficiently support a universal spectrum of emerging

datatypes (including 3-D, spatial, time series, and so on) along with the versatile,

customizable functionality required to cogently query such complex data. Only

a universal ORDBMS can integrate multimedia, video, 2-D and 3-D spatial,

time series, and other rich datatypes with unlimited object programmability

for the sophisticated query capabilities required.

Due to its openness, versatility, and reusability, object-oriented programming

is now the standard for multiplatform internet-capable application development.

An object-relational DBMS should combine the best features of object databases

and relational databases. However, a relational DBMS must be drastically

modified to take advantage of such classic features of object-oriented programming

as encapsulation, inheritance, and polymorphism.

But what are the best architectural design paths from the current industry-

standard relational DBMS to the new paradigm? This paper assesses five current

architectural options, in ascending order of practicality, performance, and

general desirability:

1. Supply plug-in code to make function calls to other applications

2. Add separate APIs and server subsystems to support object functionality

3. Simulate specialized object-relational functionality in a middleware layer

4. Completely redesign the database engine

5. Add a new object-oriented layer to support rich datatypes atop a proven

relational database engine

To appreciate the trade-offs and relative advantages of these approaches,

it might be helpful to first examine the basic mechanisms required to implement

object-relational functionality. The next section briefly analyzes the necessary

components of an ORDBMS to identify the key design objectives. Then, the

subsequent sections evaluate how each of the current design strategies attempt

to achieve those objectives.

1

2

Example : An Objec t -Re lat ional Schema

This section contains a sample query that will be used to illustrate several

points later in this paper. This object-relational schema illustrates the added

functionality possible with an ORDBMS:

create EMP-OR (name = C12, age = int, salary =

int,

dept = C12, location = point, picture = image);

Here, we have added two additional fields to the traditional Employee

table, the location of the employee’s home address, and his picture. These

fields are of the datatypes “geographic point” and “image,” respectively.

Here is a typical query to this table:

select name

from EMP-OR

where beard (picture) > 0.7 and

age > 60 and

location in circle ( “10,10”, 5);

This query finds the older employees with considerable facial hair who

live within a five-mile circle surrounding the point “10,10.” The query makes

use of a user-defined operator (in) and a user-defined function (beard) for

the new datatypes.

Components Requiring Modificationto Create an Object-Relational Engine

To support the additional object-relational functionality, designers must

modify these components of a relational DBMS:

• Access methods

• Executor

• Parallelism system

• Optimizer

• Parser

In the following subsections, the required modifications to each of

these modules are discussed to help clarify the challenge of adding object-

relational functionality.

[Note: An object-relational DBMS also needs a transaction system

and storage manager. However, these modules can be implemented by

using essentially the same code that supports a relational database engine

with little or no modification.]

Access Methods

Most relational DBMSs already support a B-tree access method to optimize

keyed access to a collection of records. However, the support for the SQL-92

datatypes is hard-coded in the access method. For ORDBMSs, this functionality

must be extended to support indexing new datatypes, that is, B-tree code

must be made generic and capable of indexing any datatype.

Because a B-tree stores index records in an order determined by the operator,

< (less than), it is imperative that the B-tree code make use of the < operator

appropriate for the datatype currently indexed by the B-tree. The definition of

this operator must be retrieved from the metadata in the system catalogs.

In addition, certain new datatypes generate queries with search requirements

not easily met with B-trees. For example, geographic points generate two-

dimensional searches that cannot be optimized using a one-dimensional

access method such as a B-tree. To perform such searches requires access

methods particularized to geographic data, such as R-trees, quad trees, or grid

files. As a result, an object-relational engine must be capable of supporting

additional access methods, including those written by third parties. We call

these user-defined access methods.

3

Support for user-defined access methods requires that access methods are

not hard-coded into the DBMS. Rather, designers must define an abstraction

for an access method and write the DBMS to understand any implementation

of this abstraction.

A third requirement is the ability to support indexes on a function of

the data. Again, consider the example of searching an employee database for

employees with a beard. It makes no sense for a DBMS to build a B-tree index

on the bits in an image. There is no inherent order that could be exploited by

such an index. Instead, if the user defined a function, beard, that guesses how

much facial hair the employee has, then he might want to index the floating

point number that results from the application of the beard function. As a

result, a good object-relational system should allow indexes to be defined on

a function of an attribute.

Executor

The executor must be capable of solving queries, such as the EMP-OR query

in the example, that contain user-defined functions and user-defined datatypes.

This requires a table-driven executor that can examine metadata in the system

catalogs and call the appropriate functions and operators. Therefore, the hard

coding of SQL-92 datatypes in current relational executors must be removed

and replaced by more flexible code.

Moreover, it is obviously undesirable to shut down a system and relink

it whenever a user defines a new datatype, a new function, or an operator, or

simply changes the definition of an existing function. Hence a good object-

relational DBMS must dynamically link and unlink user-defined functions.

Para l le l i sm System

Many relational engines support intraquery parallelism. In this case, a relational

table is stored in multiple storage fragments, and user queries are run in parallel

on each fragment. In a multiprocessor environment, this can result in dramatically

reduced response time for lengthy decision-support queries.

To operate in an object-relational environment, this parallelism system

must be extended. For example, a relational engine is capable of executing

aggregates in parallel, such as sum and average. To compute average, a relational

engine will first compute the sum and count for each stored fragment. As a

final step, these partial computations are “rolled up” by adding the partial sums

and then dividing by the total count.

Such hard-coded aggregate behavior must be removed and replaced by

an abstraction for parallel aggregates, so that user-defined aggregates can be

defined as an instance of the abstraction.

4

Opt imizer

A relational optimizer examines a heuristically chosen subset of all possible

plans to find the one with the least expected resource consumption. In a

relational DBMS, the SQL datatypes and the cost of their associated operators

and functions are hard-coded into optimizer logic. In an object-relational

DBMS, these routines must be replaced by more flexible routines that look

up data on types, operators, selectivities, and so on, in the system catalogs.

In other words, the optimizer must be converted from one using hard-coded

logic to one that is table-driven.

In addition, it is possible to include in queries some functions that are very

expensive to compute, such as the beard function mentioned in the previous

example. To correctly optimize predicates with expensive functions, the optimizer

cost model must be changed from considering only the number of pages and

the number of records examined to additionally including CPU instruction

path length as one of its resource parameters.

Parser

A relational parser hard codes the SQL datatypes, operators, and functions

into its internal data structures. Clearly, ORDBMS designers must convert

this module to a table-driven parser, which reads the metadata in the system

catalogs to ascertain legal operations on legal datatypes.

In addition, complex objects, sets, and references must be handled by the

parser, along with the required notion of inheritance. Therefore, a complete

rewrite of a relational parser is required.

In summary, truly major surgery is required to transform a conventional

relational database engine into an object-relational engine. The connection

system must be redone and major changes made to all development tools.

This means that the software written by relational DBMS vendors over

the last ten years is technologically obsolete in terms of competing in the

emerging object-relational world.

Keeping these design challenges in mind, let us now consider various

strategies currently proposed to support object-relational functionality.

5

Option 1: Supply Plug-In Codeto Make Function Callsto Other Applications

An object-relational DBMS adds type extension, complex objects, and

inheritance to a relational DBMS, as noted in the white paper [STON95].

To support user-defined functions, the DBMS must support linking, loading,

and execution of such functions in an SQL context.

For example, to run the sample query, the DBMS must execute the beard

function and the code for the operator in. The performance and safety of the

possible protocols is discussed in the white paper [STON96C].

In a non-SQL context, many middleware and client application

frameworks also support execution of user-written routines. These

frameworks for plug-ins include:

• VB controls

• Netscape plug-ins

• Oracle cartridges

• Novell Network Loadable Modules (NLMs)

• The class library interface in most 4GLs

Application frameworks, such as the Oracle extensible server, are designed

to allow one user program to make a function call to a second user program.

This capability is useful for application-to-application connectivity. However,

it has nothing to do with DBMS type extension, because it is a middleware

plug-in system, not a DBMS plug-in system. As such, middleware plug-ins

do not constitute a true ORDBMS architecture at all. It would be misleading

to pretend that an application framework is the same thing as DBMS

type extension.

6

Option 2: Add Separate APIs andServer Subsystems to Support Object Functionality

It is always possible to include one or more specialized servers with a relational

DBMS, as shown in Figure 1.

Here, a relational DBMS is packaged with a collection of completely

separate software server systems, each with its own proprietary application

program interface (API). A user program can interact with the relational

engine using standard SQL-92 to run relational queries. In addition, users

can interact with each server by using a proprietary interface.

Oracle 7.3 packages three secondary systems with their relational engine:

• Context: a text-search system

• Media Server: a storage system for video

• OLAP: a multidimensional data cube server

Media Server is a high-performance, file system-based storage system for

video that was written to support the video-on-demand trials run by the

telephone companies that experimented with movie delivery to the home.

This system efficiently stores movies and delivers them at high speed to an

ATM network for transmission to a set-top box for ultimate display on an

attached TV. Media Server is based on file system technology, because it

is a real-time “bit moving” application. Appropriately, it has no relationship

with Oracle 7, the relational DBMS.

Re l a t i ona l DBMS

Se r ve r 1 Se r ve r 2 Se r ve r 3

7

F i g u r e 1 :

The Separate

API Approach

Similarly, Context and OLAP are stand-alone servers supporting specialized

functionality in their application domains.

There are three main problems with packaging secondary servers with a

relational DBMS:

• poor functionality;

• more complex system administration; and

• bad performance.

These issues are illustrated with the sample query:

select name

from EMP-OR

where beard (picture) > 0.7 and

age > 60 and

location in circle ( “10,10”, 5);

In Oracle 7.3, pictures can be stored in Media Server and the rest of

the data is stored in the relational engine. Alternately, the user can store the

picture attribute in a binary large object (BLOB). However, by using either

approach, the user CANNOT run the query specified above.

Rather, the user must decompose the object-relational interaction into

a relational component:

select name

from EMP-OR

where age > 60;

The user can send this component to the relational engine but must

then code the remainder of the query in user logic:

where beard (picture) > 0.7 and

location in circle ( “10,10”, 5);

Required data must be fetched from the relational engine by using SQL

or from a secondary server using its custom interfaces. Then, the predicates

must be evaluated with user logic. Finally, the user must join together the

relational answer with the answer obtained from user logic.

This solution requires the user to understand:

• the distribution of data among the secondary servers;

• how to fetch data from a server, using a server-specific interface; and

• how to compute object-relational predicates in user logic.

8

In summary, a relational engine plus one or more secondary servers is

not an object-relational engine at all. It does not support object-relational

queries; rather it forces the user to solve such queries in user logic. This

absence of integration with the underlying DBMS forces the user to write

large amounts of code.

In addition, in a multiple server system, system administrators must

contend with multiple storage managers. This complicates system management

significantly, because there are multiple system management interfaces.

Additional performance bottlenecks can be spread across multiple systems,

again contributing to system management complexity. Finally, the various

servers may not have the same transaction capabilities as the relational engine.

As a result, data consistency problems may result when updates span

multiple systems.

Again, system administration headaches are the likely result. System

administration complexity increases at least linearly with the number of

server systems.

The third problem, bad performance, is equally serious. There are four

ways for a real object-relational engine to perform the query above:

1. Use a B-tree on age to find older employees, then evaluate beard

and location

2. Use a functional index on beard (picture) to find employees with

significant facial hair, then evaluate age and location

3. Use an R-tree index to find employees in the required circle, then

evaluate age and beard

4. Use more than one index to optimize the query, intersecting the lists

of employees to find the data records that must ultimately be accessed

The optimizer in an object-relational engine can evaluate all four

strategies and pick the one with the least expected cost. The strategy chosen

may depend on the constants in the predicate (60, 0.7, “10,10”, and 5).

9

In contrast, the user with a multiple server system must code an algorithm

in her program. More than likely, she will select option 1 because it is easiest

to code. In contrast, options 2 through 4 require significantly more effort.

Unfortunately, option 1 is not necessarily optimal. In addition, the user might

not have access to run-time constants when she writes the program. As a result,

she might again make a suboptimal selection.

For these reasons the multiple server approach is likely to result in poor

performance. Performance problems become more severe as the complexity

of the user query increases. Not only do bad optimizer choices become more

damaging with increasing query complexity, but also the user is forced to

perform joins in user logic or copy data from one system to another; either

way performance problems are very likely.

In summary, the architectural option that adds one or more server

subsystems to a relational engine does not provide real object-relational

functionality; instead the user must code a portion of her query in user

logic. In addition, system management headaches are likely from the multiple

storage managers. Finally, poor performance results from poor optimization

of queries, the necessity of copying data between systems, and user space joins.

10

Option 3: Simulate SpecializedObject-Relational Functionalityin a Middleware Layer

Another tactic used in Oracle 7.3 is to simulate specialized object-relational

functionality outside the DBMS in a middleware layer. This approach does

not change a relational DBMS at all; rather, it puts a specialized wrapper or

simulator around the DBMS. Instead of extending a relational engine to

provide the correct functionality, this approach simply places a bandage on

top of an inappropriate engine.

Simulators are attractive because they allow a vendor to implement

functionality quickly because they do not need to be integrated with the

underlying engine. Unfortunately, simulators also share two of the

disadvantages that we have seen with multiple server subsystems:

• Poor Performance:

The DBMS does not support the functionality of the simulator

in “native” or “kernel” mode. Typically, simulations have a severe

performance problem compared to a native mode implementation.

For example, it is possible to simulate a 370 instruction set on an

Intel x86 computer; but the simulation slows down instruction

execution by more than one order of magnitude.

Bandage

Use r P rog ram

DBMS

11

F i g u r e 2 :

The Architecture

of Middleware

Simulators

• Poor Functionality:

The user sees the DBMS through the simulator, which must implement

all DBMS services or pass them through to the underlying DBMS.

Because the complexity of supporting all services can be prohibitive,

simulators often support only a subset of desired services. This makes

a simulator system extremely difficult to use.

To understand these twin problems, consider the simulator supported in

Oracle 7.3 called Oracle Multidimension, renamed the Spatial Data Option

(SDO), as discussed in their white paper [ORAC95].

Because SDO is a simulator on top of a relational DBMS, it does not have

a specialized geographic access method, such as R-trees, but must perform

geographic search in another way, at drastically reduced performance. A detailed

example along with the exact organization and performance of spatial data

in both INFORMIX-Universal Server and in Oracle SDO is contained in

a companion white paper [STON96A].

In addition, Oracle SDO is not capable of performing spatial joins or

dealing with nonpoint data such as circles, polygons, and rectangles. Hence,

SDO is a low functionality system that can support only points and only

certain operations on points. The white paper [STON96A] contains a detailed

example of these shortcomings.

Because Oracle 7.3 is a relational engine packaged together with three

server subsystems and a simulator, it suffers from poor functionality, poor

performance, and increased system administration complexity. Oracle 7.3

cannot support object-relational queries, but forces the user to code them in

user logic. The resulting interactions are likely to suffer very poor performance.

OLAP S e r ve r

Med i a S e r ve r

Con t ex t S e r ve rRe l a t i ona l

DBMS

Spa t i a l S imu la t o r

12

F i g u r e 3 :

The Architecture

of Oracle 7.3

Oracle 7.3 has been marketed as a “Universal Server,” seemingly capable

of storing and accessing all types of data. As we have seen, this is not, in

fact, the case. Instead, Oracle 7.3 contains exactly three server subsystems

and a simulator.

In its ambitious “Brahms” project, Sybase attempted to rewrite Sybase

System 10 from scratch, designing a new ORDBMS engine from the ground

up. After two years, however, the Brahms project was canceled in February

1996, discarding at least 100 man-years of development.

Now, in place of a new engine, Sybase has proposed to devise an object-

relational simulator. The same architectural option has apparently been adopted

in the current pre-alpha release of Oracle 8.

The object-relational simulator must perform three different functions:

• If objects are stored in the relational engine, then the DBMS must include

a general-purpose object simulator on top of the relational engine.

• If objects are stored in one of the separate systems, then the simulator

must include a complete SQL executor on top of the various servers.

• If some data is stored in a separate system and other data is stored in the

relational engine, then one must support queries that span data in both

systems. As a result, one must be able to perform cross-system joins.

To perform an update that changes data in both systems, a two-phase

commit protocol must exist between the two systems to guarantee data integrity.

Such cross-system services are required in any architecture that supports SQL

seamlessly across multiple systems.

Re l a t i ona l DBMS

Ob j e c t -Re l a t i ona l S imu la t o r

Se r ve r 1 Se r ve r 2 Se r ve r X

13

F i g u r e 4 :

Object-Relational

Simulator

In order to show the three simulator functions more clearly, Figure 5

shows the simulator of Figure 4, decomposed into its three constituent pieces.

In time it would be possible to implement all three parts and thereby run

object-relational queries. If so, some poor functionality could be eliminated.

However, because the architecture is based on multiple systems and simulators,

it would still suffer from serious performance and system administration problems.

These include the following disadvantages:

Prob lems with Ob jec t S imu lators

Object simulators impose inherent limitations on an ORDBMS:

• The object-relational optimizer is middleware and detached from

the relational optimizer. An optimizer on top of an optimizer will

tend to produce inferior plans and bad performance.

• No type-specific access methods are possible.

• The work of writing a simulation of new types on top of SQL-92

objects may be painful and slow.

• A large amount of data may be copied from the engine to the middleware

layer, resulting in degraded performance. For example, if the beard

function in the sample query is executed in middleware, then each

employee picture must be copied from the relational engine to the

middleware layer, resulting in serious performance degradation.

Re l a t i ona l DBMS

Ob j e c t S imu la t o r SQL Exe cu t o r

C ro s s - Sy s t em Se r v i c e s (G l ue Laye r )

Se r ve r 1 Se r ve r 2 Se r ve r X

14

F i g u r e 5 :

Cross-System

Support

Prob lems with Separate Systems and an SQL Executor

Separate server subsystems incur a number of performance and

administrative penalties:

• Separate systems equipped with an SQL executor constitute a

complete object-relational DBMS. Providing a full-function object-

relational DBMS with reasonable scalability is a lot of work, and

is likely to take vendors a long time to accomplish.

• Functionality is implemented multiple times. For example, relational

engines have a system that supports intraquery parallelism. This

parallelism system must be engineered a second time in the SQL

executor. Moreover, each secondary system must support parallel

data access. This involves a great deal of replicated code, leading to

maintenance problems.

• Secondary systems often have weak or nonexistent support for transaction,

parallel execution, and crash recovery, resulting in performance and data

integrity problems.

• Configuring and running multiple software systems increases the

complexity of system administration.

Prob lems with a G lue Layer

Glue layers cause additional performance degradation:

• Joins require moving data up to the glue layer. This is slow, and

requires join logic to be replicated in the glue layer, as well as in

the relational DBMS, the object simulator, and the object executor.

• Two-phase commit must be supported. This makes updates very

slow. But if it is not present, then data integrity problems result.

These problems with a glue layer are further discussed in the white

paper [STON96B].

15

As a result, expect poor performance and system administration headaches

from this architecture. At this writing, Sybase has announced no delivery

schedule for the various pieces. Hence, it is unknown when a complete system

with this middleware architecture will be available.

Oracle is planning three different releases of preproduction code for Oracle,

Version 8. The first release has recently been placed in the hands of select users.

Two more releases are planned, with a final production ship date scheduled

for Q4’97, but the final functionality and actual architecture have not yet been

determined. Unfortunately, with a ship date so far in the future, users cannot

make reliable plans based on its delivery.

There is some indication that Oracle 8 will support user-defined datatypes,

user-defined functions, and inheritance in a simulation layer. At present,

however, Oracle offers no support for complex objects, references, or sets.

As a result, the Oracle architecture will likely suffer from poor functionality,

poor performance, and increased system administration complexity.

16

Option 4: Completely Redesignthe Database Engine

When faced with new functionality that is significantly different from that

required for earlier relational systems, the obvious technical approach is to build

a new DBMS engine from scratch. This architectural option was employed

by Illustra Information Technologies, as well as by most of the startup companies

offering true ORDBMSs.

Using this technology, new modules with the correct functionality

were built for the nine major components of a DBMS listed in the section

Components Requiring Modification to Create an Object-Relational Engine.

The result is a well-designed object-relational engine.

17

Option 5: Add a New Object-Oriented Layer to Support RichDatatypes atop a Proven RelationalDatabase Engine

Another sound strategy is to rewrite the “top half ” of a relational engine

to support object-relational functionality, including extensible, complex

datatypes. This approach involves building the upper half of an object-relational

engine and then layering it onto the storage manager and transaction system

of a proven relational system. This was the technique adopted by both

Informix (with INFORMIX-Universal Server) and by IBM (with its DB2/6000

Common Server) enabling the intelligent management of complex data as

native objects rather than as BLOBs while preserving superior performance

and manageability required for OLTP-intensive applications.

This architectural option retains the storage manager, transaction system,

buffer pool, and operating system interface from a robust relational DBMS.

Because these modules do not have to change to support object-relational

functionality, they can be retained without negative impact. This approach

leverages years of refinement of the code base to achieve maximum reliability.

Investments in legacy systems are preserved.

Scalability is one of the difficult challenges faced by the “build from

scratch” advocates. Relational DBMS vendors have spent many years making

these engines scalable to very high transaction rates and database sizes.

Relational DBMSs have perfected massive parallel processing.

For these reasons, a hybrid solution—an object layer built atop the storage

manager, transaction system, buffer pool, and operating system interface of

a robust relational engine—solves the scalability issue without sacrificing

functionality, stability, manageability, or performance.

INFORMIX-Universal Server is an example of one such hybrid

architecture. It combines the power and scalability of Informix’s Dynamic

Scalable Architecture™ (DSA) relational engine with the object-oriented

DataBlade technology, which enables intelligent management of complex

data as native objects rather than as BLOBs. Additional DataBlade modules

can be added to support new datatypes—and sophisticated functionality—

as needed.

18

Summary

The following chart summarizes the current architectural options for developing

an object-relational DBMS:

A R C H I T E C T U R E V E N D O R S I S S U E S

Plug-in support for Oracle extensible No DBMS type remote program calls server extension

Separate APIs & Oracle 7.3, Sybase Complexity, performance server subsystems degradation

Middleware simulation Oracle 8, Sybase Limited functionality, performance degradation

New ORDBMS engine Start-ups Solid design, must start from scratch

Hybrid, object top Informix, IBM Blends object functionality with scalable, proven relational foundation

19

References

[ORAC95] Oracle Corp, “Oracle 7 Multidimension, Advances in

Relational Database Technology for Spatial Data Management,” Oracle

White Paper, March 1995.

[STON96A] Stonebraker, M., “Spatial Bandaids for Relational Systems,”

Informix White Paper, November 1996.

[STON96B] Stonebraker, M., “Object Middleware: How Bad Can It Get,”

Informix White Paper, November 1996.

[STON96C] Stonebraker, M., “DBMS Extension: The Good, the Bad, and

the Ugly,” Informix White Paper, November 1996.

[STON95] Stonebraker, M., Object-Relational DBMS: The Next Great

Wave, Morgan-Kaufman Publishers, San Francisco, CA, 1995

20

I n f o r m i x

Architectural Options for

Object-Relational DBMSs

©1997 Informix Software, Inc. The following are worldwide trademarks of Informix Software, Inc.,Informix Corporation, or their subsidiaries, registered in the United States of America as indicatedby “®” and in numerous countries worldwide: Informix®, The Informix Logo®, DataBlade®, DynamicScalable Architecture™, Illustra™. All other names or marks are registered trademarks or trademarksof their respective owners.

4100 Bohannon Drive

Menlo Park, California 94025

1 415 926 6300

World Wide Web: http://www.informix.com

Printed in U.S.A

.–10K–02/97–000-21460-70 Dr. Michael Stonebraker ♦ Chief Technology Officer ♦ Informix Software, Inc.

Unleashing Business Innovation

Informix Software is leading the next greatwave in database innovation to enable theworld’s leading corporations to manageand grow their businesses. With its focusedtechnology strategy, superior customer service, and best-of-breed partnerships,Informix is the demonstrated technologyleader for corporate computing environmentsranging from workgroups to very largeOLTP and data warehouse applications—as well as a catalyst in major new IT trendssuch as dynamic content management, theWeb, smart cards, and mobile computing.

For more information about Informixproducts and services, please contact thesales office nearest you, or visit us on theWeb at www.informix.com

Regional Sales Offices

Asia/Pac i f i c65 298 1716

Canada (Toronto)416 730 9009

Europe/Midd le East/Afr i ca44 1784 422 000

Federa l703 847 2900

Japan81 3 5562 4500

Lat in Amer i ca305 265 7545

North Amer i ca800 331 1763415 926 6300