10.1.1.8.6980

7/29/2019 10.1.1.8.6980

1/18

Jeff Sutherland 1993

THE HYBRID OBJECT-RELATIONALARCHITECTURE (HORA)

An Integration of Object-Oriented

and Relational TechnologyRevised 20 November 1993

Earlier version published as: Sutherland, JV, Rugg, K, Pope, M [1993] The Hybrid Object-RelationalArchitecture (HORA): An Integration of Object-Oriented and Relational Technology.. In Proceedings ofthe 1993 ACM/SIGAPP Symposium on Applied Computing. : ACM Press, pp 326-333.

Jeff Sutherland

IDX Systems Corporation, Boston, [email protected]

Ken RuggObject Design, Burlington, MA

Matthew PopeObject Solutions, Inc., Toronto, Canada

7/29/2019 10.1.1.8.6980

2/18

J eff Sutherland 1993

ABSTRACT

Many organizations with investments inrelational database managementsystems (RDBMS) want to build object-oriented applications supporting agraphical user interface without forcingprogrammers to deal with SQL andRDBMS limitations. This paper

proposes a natural and relativelytransparent coupling of object-orientedclients with relational database servertechnology for new applications. Thespecified architecture can concurrentlydeliver key features of both The Object-Oriented Database Manifesto1 and theThird Generation Database SystemManifesto2. The Hybrid Object-Relational Architecture (HORA) is

designed to:

support ANSI SQL III object-oriented functionality usingcurrently available relationaldatabase systems

provide good server performance toboth relational and objectapplications

provide full object storage supportby the RDBMS

allow the specification of high-levelreferential integrity rules and user-specified constraints without SQLcoding.

The HORA approach allows read-onlyaccess from existing relationalapplications and is not designed to be

7/29/2019 10.1.1.8.6980

3/18


updated by legacy systems withoutusing the object manager.

7/29/2019 10.1.1.8.6980

4/18


1. INTRODUCTION

The two approaches most often used to

integrate object applications withrelational database managementsystems (RDBMS) are:

Direct connection of an objectapplication to legacy relationaldatastores without modification ofthe relational schema.

Connection of an object application toan object manager which translates

persistent objects into relationaltables eliminating the need forembedded SQL in the objectapplication.

The first approach has been widely usedin recent years and is part of manyvendors language products, classlibraries, and object database systems.It often requires hardwiring SQL codein the object client which negativelyimpacts flexibility and performance.Recent detailed data on a productionsystem of this type for an aerospaceapplication showed that 35-55% of theresources used to build an object-oriented application were wasted onrework generated by changes to therelational database schema during thedevelopment phase of the project.3

The second approach has beenimplemented in object databaseproducts such as G-BASE/SQL whichallows G-BASE developers to storeobjects transparently in an Oracle objectserver4 and OpenODB, a layer of objectservices provided by Hewlett Packardand licensed to Informix for distribution

with the Informix RDBMS.5 Both ofthese products allow object-orientedprogrammers to build new objectapplications independent of many of thelimitations of the underlying RDBMS.

In many environments, availableobject/relational database products maynot be suitable. For those cases, thispaper describes how to build objectservices from the bottom up that willallow persistent object storage in anRDBMS for new applications. Since theobject services must manage the schemaof the relational database, legacyrelational applications may read theobjects directly, but may not update thedatabase without using the objectmanager.

The approach presented has beenoptimized during repeatedimplementations during the period1989-1992.6,7,8 A similar design isinherent in the emerging specification ofISO/ANSI SQL III scheduled for release

in 1996.9

At that time all compliantrelational database systems will becomeobject-oriented.

The remainder of this paper specifiesthe architecture for the HybridObject/Relational Architecture (HORA)approach. Details of implementation ofobjects in relational tables in theRDBMS are carefully explained.Functionality that must be supported by

an object manager that uses the tables isdescribed at a high level. Details of theObject Manager design are beyond thescope of this article. An Object SQL andC++ syntax are used to illustrate asimple example.

7/29/2019 10.1.1.8.6980

5/18

J eff Sutherland 1993 2

2. HYBRID OBJECT-RELATIONALARCHITECTURE

The benefits of HORA are power,performance, and safety. There aremany published approaches to storingobjects in a relational database.Rumbaugh10 provides a good overviewof strategies for storing classes inrelational tables. This paper does notpresent new theory, but presents newexperience. The power of HORA is thatit is based on over a decade of objectdatabase research and productimplementation11. The performance ofHORA has been optimized due torepeated implementation in distributedenterprise environments over manyyears. Safety is based on experiencewhich guarantees that HORA will workwell in commercial environments.

HORA provides the following benefits:

A rich object Meta-model can bestored directly in the RDBMS. ThisMeta-model information is muchcloser to ANSI SQL III object-orientedcapabilities than the limitedconstraint definition capability ofANSI SQL II.

Distributed client applications can

locally run the object manager thatperforms dynamic mapping fromobjects to relational tables whileenforcing user-defined integrityconstraints. This allows "atomic"

changes from one valid object state toanother.

Object applications can be insulatedfrom RDBMS schema changes

through minor modifications of theMeta-model.

These distributed capabilities offloadthe RDBMS and improve relationalserver performance beyond serverbased SQL III implementations.Performance has been shown to be asefficient as typical relationalapplications because it is constrainedonly by the performance of the

underlying relational database.

HORA provides each class with arelational table. The records in the tablewill store object instances. In mostcases, this approach will look like anormalized database to a relationalapplication. However, since relationalapplications have no notion of objectidentity (which is maintained by

HORA), they may not be allowedbypass the object manager to update thedatabase.

HORA will not provide theperformance of a pure object databasefor complex objects because it will beconstrained by the performance of theunderlying relational database. It isdesigned for adding new objectapplications to currently available

relational database systems which havebecome standard technology in mostorganizations.

7/29/2019 10.1.1.8.6980

6/18


APPLICATION

OBJECT SQL

OBJECT

MANAGER

SERVERCLIENT

RDBMS

EMBEDDED SQL

Figure 1

3. HYBRID OBJECT-RELATIONALARCHITECTURE

In a commercial transaction processingenvironment, the client/serverarchitecture in Figure 1 has been founduseful.7 An object-oriented client

application communicates with therelational database through an objectaccess layer using an Object SQL(OSQL) dialect. The Object Managertranslates OSQL requests into one ormore standard SQL commands toretrieve objects from the relationaldatabase.

The OSQL and Object Manager layersconsist of class libraries with store andretrieve methods. OSQL provides aclear command structure and can beeasily understood by SQLprogrammers. The Object Manager canprovide a direct pass through of ANSIstandard SQL commands12 in order toprovide some support conventional

applications. In this case it must enforce

Codd's Nonsubversion Rule13 forrelational systems by ensuring thatstandard relational statements do notbypass object integrity constraints.

4. OBJECT IDENTITY IN THERELATIONAL DATABASE

In order to reduce the work required tobuild an object-oriented application andretain the power of the objectarchitecture, HORA gives every object aunique, system defined, objectidentifier.14 In a relational system,objects are not guaranteed uniqueidentity because they have keys whichmay be changed by a user. This createsa referential integrity problem whichhas increased development costs byover 50% on projects with publishedhard data on resource utilization.3

7/29/2019 10.1.1.8.6980

7/18


5. FUNCTIONS OF THEOBJECT MANAGER

For the purposes of this paper, weassume the Object Manager will bewritten in C++. It will accept OSQLmessages and return C++ objects. TheObject Manager must provide thefollowing functionality:

create, update, delete metadata,classes, and instances

support OSQL and standard SQLqueries

enforce metarules

The Object Manager stores metadata inthe database, is semantically complete,and has a full understanding ofrelationships between data. In contrast,a typical relational database stores only

a portion of the schema in the database.The ability to maintain and evolvesystems which store a complete set ofmetadata is enhanced over conventionalsystems. When an original developermoves on to other work, all theknowledge about the database does notdepart with the person. Much of itremains in the database as a Meta-model, class schema, and metarules

embodied in methods and theinheritance structure.

6. BUILDING THE HORAMETA-MODEL

The HORA Meta-model is created bybuilding an entity-relationship semanticdatabase model. The semantic modelcan be used to build an object templatesupporting methods and inheritance.

Once the object template is in place,application classes can be created. Theclass schema can then be used as atemplate to populate the database withinstances. Metaclasses, applicationclasses, and class instances are allobjects in the database. This recursivedesign enables powerful features notavailable in persistent object stores builtwithout a semantic data model

(dynamic schema evolution, forexample).15

The Meta-model has been designed tobe easily extensible to supportdistributed servers, versioning, andtriggers. Space limitations make thesetopics beyond the scope of this paper.

6.1. The HORA SemanticDatabase Model

HORA is based on a semantic databasemodel. Hull and King16 provide athorough review of the historicaldevelopment of semantic models alongwith an extensive bibliography. AllHORA objects are members of a classand all classes are constructed onlyfrom atomic attributes and

relationships. This semantic data modelis based on the work of Abrial17 anddirectly supports the EntityRelationship Model of Chen.18

Atomic attributes can consist of anydata type supported by the SQL Serveror any data type which the Object

7/29/2019 10.1.1.8.6980

8/18


Manager can support by using analgorithm to store data in the RDBMS.Strategies are available for storingBinary Large Objects (BLOBS) even inan RDBMS which does not directly

support them. The term attribute will beused hereafter to mean atomic attribute.Each class will have a single table whichstores all attributes.

HORA links objects through the use ofobject identifiers in an ObjectRelationship Table (see Figures 2 and 4).Referential integrity is maintained bythe Object Manager throughenforcement of one simple rule. Noobject can be deleted until all its links toother objects are deleted from the ObjectRelationship Table.

6.2 The HORA ObjectTemplate

Reduced Instruction Object Semanticscan be used to construct an objecttemplate by creating the following eightmetadata tables (see Figure 2).

Class Table

Attribute Table

Attribute Type Table

Class Relationship Table

Relationship Type Table

Method Usage Table

Method Table

Object Relationship Table

Note that the notion of superclass isdefined as a relationship type in Figure2. Reuse is supported through thisimplementation of multiple inheritance.

6.3. The HORA Metaclass

When the Object Manager receives arequest to open a new database, it opena database in the RDBMS and constructsthe eight tables shown in Figure 2.Initially, there are no data in the rows ofthese tables. The Class Table is firstpopulated with eight objects which

represent the eight metatables (objects1-8). In the Figures, object IDs arespecified so as to aid understanding.

Attribute types are created in theAttribute Type Table (objects 30-34).Before the Object Manager caninstantiate the HORA Metaclass, the"defines type of", "is made of", and "issuperclass of" relationship types areneeded. These are created in the

relationship type table (objects 20, 21,28).

The HORA Metaclass (the class named"Class") is made up of attributes andrelationships by creating objects 21 and22 in the Class Relationship table.Relationship 20 in the same tableindicates that Attributes Types arerelated to Attribute Usage. The Object

Manager must constrain AttributeUsage names to be unique to avoidname ambiguity in multiple inheritancespecifications. Attribute Types,however, may be reused by the ObjectManager.

7/29/2019 10.1.1.8.6980

9/18


The notion of superclasses is added bydefining the Metaclass as a superclass ofitself by adding relationship type 28 tothe Class Relationship Table. The ObjectManager supports standard

specialization inheritance, i.e. subclassesconsist of all attributes, relationships,and methods of all superclasses plusone or more additional attributes,relationships, or methods. Methods areadded by putting relationship type 24,"is operated on with", in the ClassRelationship Table. Methods forcreating, updating, and deletingmetadata can be added to the methods

table. Polymorphism is supported byallowing a subclass to respecify amethod previously defined in asuperclass. In order to avoid ambiguitywhen searching the network of classesfor methods, a Usage Sequence Numberis defined in the Method Usage Table.When a message is sent to a class, if themethod is not available in the class, thesearch for the method proceeds tosuperclasses. If multiple superclasses

have the same method defined, the onewith the lowest Usage SequenceNumber is selected.

Instantiation of the HORA Metaclassbootstraps the system. The ObjectManager can now dynamicallydetermine the method of constructionof all classes in the RDBMS by readingthe metatables. With the instantiation of

the appropriate methods, the ObjectManager has the tools to easily changethe Meta-model to support evolvingstandards such as those of the ObjectManagement Group (OMG).19,20,21 Forexample, a new Meta-model withadditional features can be created by

making it a subclass of the originalMeta-model.

6.4. HORA Approach to

Methods

From a theoretical standpoint, it isdesirable to store method code in thedatabase. In practice, distributed clientsrunning in different languages ondifferent platforms make this difficult.Also passing methods over the networkcan cause performance problems.

A workable solution is to store methodnames and version numbers in thedatabase. When a client applicationconnects to the database, it will read themetadata including method versioninformation. The client software canthen positively verify that theappropriate method versions have beenpreviously linked into client code, priorto allowing a user to run theapplication. Method code under thisscenario resides on application clientworkstations and not on the server.

7/29/2019 10.1.1.8.6980

10/18


CLIENT ACCOUNT

SAVINGSACCOUNT ACCOUNT

CHECKING

Owns

superclass

OverdraftLink

Figure 3

7. BANK ACCOUNTS - ASIMPLE EXAMPLE OF THEHORA IN ACTION

Consider the object diagram in Figure 3(Rumbaugh notation).

The example consists of two objecttypes, Clients and Accounts. Accountwill be used as a superclass of SavingsAccount and Checking Account. Clientswill own accounts and CheckingAccounts will be related to SavingsAccounts through and Overdraft Link.This will allow the system to withdrawmoney from a Savings Account in thecase of a Checking Account overdraft.Attributes of these objects are asspecified below:

CLASS Client

(Last_Name, First_Name, Middle_Initial,

SSN-SIN,

RELATIONSHIPS (Owns Account).

CLASS Account

(Account_Number, Opened_Date,

Balance,

METHODS (Open, Close, Deposi t,

Withdraw, Transfer).

CLASS Savings_Accoun t

(Interest_Rate,

SUPERCLASSES (Account),

METHODS (Post_Interest).

CLASS Checking Account

(Checking_Fee,

RELATIONSHIPS (Overdraft_Link

Savings_Account),

SUPERCLASSES (Account),

METHODS (Withdraw,

Post_Fee).

7/29/2019 10.1.1.8.6980

11/18


This simple example illustrates thepower of object technology. The classCHECKING ACCOUNT has aWithdraw method that overrides themethod of the same name in the

superclass ACCOUNT. This methodmay be written to transfer money froma savings account in the event ofoverdraft using the Overdraft_Linkrelationship. The Transfer method inACCOUNT may use Withdraw (fromitself) and Deposit (to another account).

Consider a transfer from a checkingaccount to another account. CHECKINGACCOUNT does not have a Transfermethod, so the Transfer method ofsuperclass ACCOUNT is executed. Thissends a Withdraw message to thechecking account. If the checkingaccount has insufficient funds, theWithdraw method sends a Transfermessage to the attached savingsaccount, and so forth. A complex seriesof events will occur automatically usingonly ACCOUNT Withdraw, Deposit,

and Transfer methods and the modifiedWithdraw method in CHECKINGACCOUNT.

Development and maintenance of thecode for these account transactions issignificantly reduced through reuse ofmethods and through the built in threadof execution of these methodssupported by inheritance. In a realbanking system, it will be necessary toconsider security, transaction logs andother factors. Reduction in coderequired will be much greater than inthis simple example.

7.1. Opening A Database

To open a new application database, theapplication must send the Object

Manager an OSQL command to create adatabase. The Object Manager willrespond by opening a database on theSQL server and creating the metadatatables described previously.

Using a proposed OSQL standardwhich will eventually be superceded byANSI SQL III syntax, the call wouldlook like as follows with the applicationcode specifying the database name andmode of operation (read/write). TheObject Manager returns a cursor andconnection ID for use in the next call tothe database.

Object_Manager::open(cursor , con n_ID, database,

mode);

7.2. Creating The Class Schema

Once the metatables are created, theapplication must send OSQL commandsto create the class schema.

Object_Manager::osql(cursor, OSQL_statement,

length, conn_ID);

where,

OSQL_statement=CREATE CLASS Account

(Account_Number integer 12 INDEX

REQUIRED,

Opened_Date date,

Balance money 15.2,

METHODS (Open 1, Close 1, Deposit

1, Withdraw 1, Transfer 1))

7/29/2019 10.1.1.8.6980

12/18


OSQL_statement=CREATE CLASS Client

(Last_Name string 30 INDEX

REQUIRED, First_Name string 30,

Middle_Initial str ing 1, SSN_SIN integer 9,

RELATIONSHIPS (Owns Account))

OSQL_statement = CREATE CLASS Savings_Account

(Interest_Rate 4.2,

METHODS (Post_Interes t 1),

SUPERCLASSES (Account))

OSQL_statement = CREATE CLASS

Checking_Accoun t (Checking_Fee 6.2,

RELATIONSHIPS (Overdraft_Link

Savings_Account),METHODS (Post_Fee 1, Withdraw 1),

SUPERCLASSES (Account))

Upon receipt of these commands, theObject Manager will set up the classschema in Figure 4 and generate theobject tables of Figure 5 withoutinstances. All that remains is to instructthe Object Manager to create theinstances.

7.3. Creating Instances

To enter the first account,

OSQL_statement = CREATE OBJECT OF CLASS

Savings_Account (Account_Number 500258,

Opened_Date 10-10-64, Balance 2200.00,

Interest_Rate 0.06)

A cursor will be returned withAccount_OID, a pointer to the objectjust created. This is used to connect aClient instance to the Savings Accountinstance.

OSQL_statement = CREATE OBJECT OF CLASS Client

(Last_Name "Wise", First_Name "Lisa" ,

Middle_Initial "T", SSN_SIN 111222333,

RELATIONSHIPS (Owns 1000, 1002, 1003))

The creation of the remaining instancesin Figure 5 proceeds in a similarfashion. Classes and instances can bemodified and deleted with similarOSQL commands.

8. OPTIMIZING THEDATABASE FOR

PERFORMANCE

When building a database applicationand bringing it into production, it issometimes necessary to improveperformance of the system bydenormalizing the database. Thisinvariably reduces the flexibility of thesystem and generates additionmaintenance overhead in a conventional

relational application. In the object-oriented environment, it can alsodestroy the integrity of the objectsystem.

There is one extension to the objectsystem which may improveperformance for some applications. Forone to many relationships, a foreign keyOID may be inserted as an attribute inthe instance tables. This will allowrelational joins to be accomplishedwithout going through the ObjectRelationship Table. The ObjectRelationship Table must still bemaintained to enable reverse pointerswhich support referential integrity. This

7/29/2019 10.1.1.8.6980

13/18


process can be automated throughproper design of the Object Manager.

In our example above, this would resultin an addition column in the Checking

Account table which would contain theOID's of the related Savings Account.This would yield performance gains ontransactions that require simultaneousaccess to both checking and savingsaccounts. For more complex objecthierarchies, improvements could besignificant.

9. CONCLUSION

The HORA methodology for connectingnew object-oriented applications torelational datastores has been described.It supports full object-orientedfunctionality while allowing traditionalapplications read access to the databaseand is easily extensible to distributedRDBMS servers and versioneddatabases. The object schema, including

the Meta-model, can dynamicallyevolve to support complex objectstructures and emerging ISO, ANSI, andOMG object standards.

7/29/2019 10.1.1.8.6980

14/18

Jeff Sutherland 1993 11

FIGURES

Figure 1 Client Server Architecture

Figure 2 Object Meta-model Schema

Figure 3 Bank Account Entity-Relationship Model

Figure 4 Bank Account Class Schema

Figure 5 Bank Account Instances

7/29/2019 10.1.1.8.6980

15/18

12

7/29/2019 10.1.1.8.6980

16/18

13

7/29/2019 10.1.1.8.6980

17/18

14

7/29/2019 10.1.1.8.6980

18/18

15

10. BIBLIOGRAPHY

1Atkinson, M. et al. The Object-OrientedDatabase Systems Manifesto. In Deductive andObject-Oriented Databases. Elsevier SciencePublishers, 1990.

2Committee for Advanced DBMS Function(Stonebraker, M., et al.). Third GenerationDatabase System Manifesto. ACM SIGMODRecord, Sep 1990.

3Gardner, J., Sutherland, J.V. Report on BuyerFurnished Equipment Development History and

Level of Effort. Object Databases, Cambridge,Mass., November, 1990.

4G-BASE/SQL Product Brief. Object Databases,Cambridge, 1990.

5Lyngback, Peter. OSQL: A Language for ObjectDatabases. Hewlett Packard Technical ReportHPL-DTD-91-4, Jan 15, 1991.

6Sutherland, J.V. Graphael-Boeing Working Paper:Boeing Aerospace APF Project. Graphael, Inc.,

Waltham, 1989.

7Rymer, J.R. Guiness P.A.'s Buyer FurnishedEquipment: An Object-Oriented ApplicationCase Study. First Class: The Object ManagementGroup Newsletter, Nov/Dec 1991, pp. 20-21.

8Rymer, J.R. Object Orientation 1991: TowardCommercial Reality. Patricia Seybold's OfficeComputing Group Special Research Report,1991, pp. 280-286.

9Melton, Jim. (ISO/ANSI) Working DraftDatabase Language SQL (SQL3). ANSI X3H2-92-155 DBL CNB-003, July 1992.

10Rumbaugh, J. et al. Object Oriented Modelingand Design. Prentice Hall, Englewood Cliffs,1991.

11Barthes, John-Paul A., Vayssade, M.,Znamierovska, M. Property Driven Databases.In Proceedings of 6th IJCAI, Tokyo. AAAI, 1979.

12Date, C.J. A Guide to the SQL Standard, SecondEdition. Addison-Wesley, Reading, Mass., 1989.

13Codd, E. F. The Relational Model for DatabaseManagement, Version 2. Reading: Addison-Wesley, 1990.

14Khoshafian, Setrag N., Copeland, George P.Object Identity. In Readings In Object-OrientedDatabase Systems. Zdonik, S.B., Maier, D. (Eds.)

San Mateo, Morgan Kaufmann, 1990.

15Sutherland, J.V. Is a Persistent Object Store aDatabase? In OOPSLA '89 Proceedings, NewOrleans, October 1-6. ACM, New York, 1989,pp. 499--500.

16Hull, Richard, King, Roger. SemanticDatabase Modeling: Survey, Applications, andResearch Issues. ACM Computing Surveys

19:3:201-260.

17

Abrial, J.R. Data Semantics. In Data BaseManagement. Klimbie JW, Koffeman KL (Eds.)North-Holland, 1974, pp. 1-59.

18Chen, P.P. The Entity-Relationship Model--Toward a Unified View of Data. In Readings inDatabase Systems. Stonebraker, M. (Ed) MorganKaufmann, San Mateo, 1988, pp. 374-387.

19Osher, H.M. Software Without Walls. BYTE17:3 (Mar), 1992, pp. 122-128.

20

Object Model Task Force (OMTF). TheOMG

Object Model. Framingham: Object ManagementGroup (OMG), draft 1 Mar 1992.

21Digital Equipment Corp. et al. The CommonObject Request Broker. Framingham: ObjectManagement Group (OMG), 1992.

Date post:	03-Apr-2018
Category:	Documents
Upload:	siddharth-anand
View:	218 times
Download:	0 times

10.1.1.8.6980

Documents