Object-Relational Database Systems -- An Introduction

8/14/2019 Object-Relational Database Systems -- An Introduction

1/8

Object-Relational Database Systems: an Introduction

Divya Kommineni

1. Introduction:The relational data model has proven very successful at solving most business data

processing problems. However, there are many engineering applications like CAD systems,programming environments, geographic data, and graphics for which a conventional relationalsystem is not suitable. The relational databases and object technology can be used in conjunctionwhich involves bringing relational data into objects, where the data can be navigated andapplications built. Then, the altered object data needs to be brought back to the relationaldatabase where it can be securely stored [1].

2. Strengths and Weaknesses of Relational Model:The strengths of a relational model are its strong theoretical foundation based on first-order predicate logic, simplicity, reliability, suitability for online transaction processing and its

support for data independence [2], relatively static repositories for business data [3]. However,RDBMSs have their own weaknesses. They are:

Poor representation of real world entities

Semantic overloading

Poor support for integrity and enterprise constraints

Homogenous data structure

Limited operations

Difficulty handling recursive queries

Impedance mismatch

Problems with RDBMSs associated with concurrency, schema changes and poornavigational access

The RDBMS has domains, keys, multi-valued and join dependencies

Expressing many to many relationship is difficult

Normalisation may sometimes lead to relations which do not correspond to entities in thereal world.

3. Object Relational Database Management Systems:Many of the advanced database management systems make use of object oriented features

like

User extensible type system

Encapsulation

Inheritance

Polymorphism

Dynamic binding of methods

Complex objects including non-1NF objects

Object identity


2/8

One way to overcome the weaknesses of the relational model is to extend the relational

model with the above mentioned features. The RDBMSs which have incorporated the objectoriented features are now referred as Object Relational DBMSs (ORDBMSs). Some analystspredict ORDBMS will have 50% larger share of market than RDBMS. Object-relational DBMSs

add support for object-oriented data modeling by extending both the relational data model andthe query language while keeping the already successful technology (especially the SQL) of arelational DBMS relatively intact. There are two classes of object-relational DBMSs in themarket:

ORDBMSs that have been built from scratch (e.g., Illustra, UniSQL) and

ORDBMSs that are built by extending existing relational DBMSs (e.g.: DB2, Informix,Oracle, and Sybase). This approach is essentially a bottom-up approach, being data (ordatabase) centric [4].

RDBMSs are currently the dominant database technology with estimated sales of $6 -$10 billion per year ($25 billion with tools sales included). OODBMS market is still small, but it

still finds new applications areas such as Web. Some analysts expect OODBMS market to growat a faster rate than total database market, but unlikely to overtake relational systems. But thevendors of RDBMSs are conscious of the threat and promise of OODBMS. They also agree thatthe current RDBMSs are not suitable for the advanced applications and that additionalfunctionality is required. But they reject the claim that RDBMSs do not provide sufficientfunctionality or will be too slow to cope adequately with new complexity [2]. The shortcomingsof relational model can be overcome by extending the model with object oriented features.

3.1Design methodology:Developers using ORDBMS get the most benefit from the technology when taking a

more holistic approach to database analysis and design than is typical with relational DBMStechnology. A good way to think about an ORDBMS is as a kind of software "back-plane": aframework within which you can embed software modules (object classes) corresponding to thethings the application is interested in. What distinguishes an object-relational DBMS from moreconventional software frameworks-such as pure object-oriented DBMSs, application-servers, orTP-monitor middleware-is that the embedded object classes are deployed within an abstracted orlogical data model. As a result, object-relational database development teams need to work attwo levels. One team of developers implements the objects in the database using languages likeC or Java, while another team combines these objects to address the high-level requirements ofthe application's problem domain [3].

4. Stonebrakers vi

ew:

Stonebraker has proposed a four-quadrant view of the database world, as shown inFigure1. The lower left quadrant contains the applications that process simple data and have noneed for querying the data. These types of applications use standard text processing packageslike Word, WordPerfect and Framemaker which can make use of the underlying operatingsystem to obtain the essential DBMS functionality of persistence. In the lower-right quadrantcontains the applications with complex data but require no significant data querying. For these


3/8

types of applications, computer-aided design packages may be an appropriate choice of DBMS.In the top-left quadrant, the applications with complex querying but simple data are present.Many of the traditional business applications fall in to this quadrant and a relational DBMS maybe the most appropriate DBMS for those types of applications. The top-right quadrant has theapplications that require complex querying with complex data. These applications require some

advanced database features and ORDBMS is the most appropriate one in this case. This is a verysimplistic classification and also it is not easy to distinguish the database applications in to one ofthese cases.

5. Advantages of ORDBMSs:Apart from overcoming the weaknesses of relational models, ORDBMSs have the following

advantages. In ORDBMS, the server performs the standard functions centrally instead of having it

coded in each application which increases the productivity. This can be referred to asreuse. It gives rise to increased productivity both for developer and end-user.

This ORDBMS preserves the knowledge and experience that is gained in developing therelational applications.

Able to handle and query large and complex applications.6. Disadvantages of ORDBMSs:

Though ORDBMS have some advantages by the way of using object oriented features, itis also not fully solving the problems. It also has some disadvantages. Proponents of relationalapproach believe that the simplicity and purity of relational model are lost. Some believe thatRDBMS is being extended for what will be a minority of applications. OO purists are also notattracted by extensions [2]. ORDBMSs have some disadvantages like

Complexity Increased costs Simplicity and purity of the relational model are lost with these extensions. SQL is now extremely complex.7. PostgresAn early ORDBMS:

The Ingres relational database management system was implemented at the University ofCalifornia. Many extensions of that were proposed later and it became more difficult to includeany more substantial new functions to it. Because of the earlier design decisions and the problemof integrating the previously proposed ideas to the new system, it became difficult to extend theexisting system. Hence, a new database system called Postgres(Post INGRES) was built.Postgres attempts to extend the relational model with abstract data types, procedures, and rules[5]. The objectives of this project were [5]:

1. Providing better support for complex objects: Engineering data is more complex anddynamic in contrast to the business data. Although the required data types can besimulated in the relational system, the performance of the system is unacceptable.


4/8

2. Providing user extensibility for data types, operators, and access methods: This helps inthe system being used for new application domains. A conventional DBMS has a smallset of built-in data types and access methods. Many applications require specialized datatypes like geometric data types for CAD/CAM or a latitude or longitude position datatype for mapping applications. Though these data types can be simulated on the built-in

data types, the resulting queries are confusing and the performance is poor. Suchapplications would be best served by the ability to add new data types and new operatorsto a DBMS. Moreover, easy-to-use interfaces should be preserved for any code that willbe written by a user.

3. Supporting active databases and rules: Many applications are most easily programmedusing alerters and triggers. A database alerter is needed to bring attention to a particularproblem. Triggers can be used in the database to propagate updates to maintainconsistency.

4. Simplifying the DBMS code for crash recovery: Most DBMSs have large amount ofcrash recovery code that is tricky to write, full of special cases, and very difficult to testand debug. The model for crash recovery should be as simple as possible and easilyextendible. The approach proposed in [5] is to treat log as normal data managed by theDBMS which will simplify the recovery code and simultaneously provide support foraccess to the historical data.

5. Making use of new technology whenever possible:A system design with optical disks inits hierarchy and also the usage of multiple-processor work-stations, and custom-designed VLSI chips will have an advantage.

6. Making a few changes as possible (preferably none) to the relational model: Rather thanbuilding a system that is based on a large, complex data model, a new system should bebuilt on a small, simple model that is extendible.

Some features are added to the relational model in order to support aggregation,generalization, complex objects with shared sub-objects and attributes that reference tuples inother relation. They are: Abstract data types, Data of type procedure, Rules.

Postgres provide a set of predefined atomic types: int2, int4, float4, float8, bool, char, anddata. Users can add new atomic types and structured types. An Abstract Data Type definitionincludes a type name, its length in bytes, procedures for converting a value from internal toexternal representation (and vice versa) and a default value. For example, the type int4 isinternally defined as:DEFINE TYPE int4 IS ( InternalLength = 4, InputProc = CharToInt4, OutputProc = Int4ToChar,Default = 0)

The procedures Int4ToChar and CharToInt4 are implemented using some high level programming language like C and they are made known to the system using DEFINEPROCEDURE command. An operator on ADTs is defined by specifying the number and type ofoperand, the return type, the precedence and associativity of the operator, and the procedure that


5/8

implements it. Structured types are defined using type constructors for arrays and procedures. Avariable or fixed length array is defined using an array constructor. The procedure constructorallows values of type procedure in an attribute, where a procedure is a series of commandswritten in Postquel, the query language of Postgres and the corresponding data type is called thepostquel data type.

7.1 Relations and Inheritance:

The declaration of a relation in Postgres looks like:CREATE TableName( columnName1 = type1, columnName2 = type2, )[KEY (listOfColumnNames)][INHERITS (listOfTableNames)]

Multiple inheritance is supported and the key specifications are also inherited. The followingdeclaration shows how to create an entity Staff that inherits the attributes of a Person:

CREATE Person ( fName = char[15], lName = char[15], sex = char, dateOfBirth = date)KEY (lName, dateOfBirth)CREATE Staff( staffNo = char[5], position = char[10], salary = float4, branchNo = char[4],manager = postquel)INHERITS (Person)

The relation Staff now includes the attributes declared explicity for that and also the attributesdeclared for Person. In this case, the key is also inherited for the Staff relation which is same asthat of the Person. The manager attribute is defined as a type postquel to indicate that it is aPostquel query. The following declaration shows how a tuple can be added to the Staff relationusing the APPEND command:

APPEND Staff ( staffNo = SG37, fName = Ann, lName = Beech, sex = F, dateOfBirt =10-Nov-60, position = Assistant, salary = 12,000, branchNo = B003,manager = RETRIEVE (s.staffNo) FROM s IN Staff WHERE position = Manager AND

branchNo = B003)

Accessing the manager attribute can be done in two ways: One using RETRIEVE command andthe other using EXECUTE command.

RETRIEVE ( s.staffNo, s.lName, s.manager.staffNo) FROM s IN Staff

EXECUTE ( s.staffNo, s.lName, s.manager.staffNo) FROM s IN Staff

Parameterized procedures can be used where the query parameters can be taken from otherattributes in the tuple. The $ sign is used to refer to a tuple in which a query is stored. The abovequery can be redefined using parameterized procedure type as

DEFINE TYPE Manager ISRETRIEVE ( staffNumber = s.staffNo) FROM s IN Staff WHERE

position = Manager AND branchNO = $.branchNo


6/8

and this can be used in the creation of the table as:CREATE Staff ( staffNo = char[15], position = char[10], salary = float4,

branchNo = char[4], manater = Manager)INHERITS (Person)

And the query to get the staff details is written as:RETRIEVE ( s.staffNo, s.lName, s.manager.staffNumber) FROM s IN Staff

The mechanism of ADT in Postgres is limited in comparison with OODBMSs. In Postgres, theobjects are composed based on ADTs whereas the objects themselves are treated as ADTs inOODBMSs. Hence the concept of encapsulation is not fully satisfied. Moreover, the inheritancemechanism is associated with tables and not with ADTs.

7.2Object Identity:Postgres implicitly creates and maintains an attribute called oid for every relation that contains

tuples unique identifier. The user queries can only access oid but cannot update it. The oi d canbe used as a mechanism to simulate attribute types that reference tuples in other relations. A typethat references a tuple in the Staff relation can be defined as

DEFINE TYPE Staff(int4) ISRETRIEVE ( Staff.all) WHERE Staff.oid = $1

Same name can be used for both relations and type name because each of them have differentname spaces. A relation that uses this reference type can be created as:

CREATE PropertyForRent( propertyNo = char[15], street = char[25], city = char[15], postcode =char[8], type = char[1], rooms = int2, rent = float4, ownerNo = char[5], branchNo = char[4],staffNo = Staff)KEY (propertyNo)

A property to the database can be added using the following query:

APPEND PropertyForRent( propertyNo = PA14, street = 16 Holhead, city = Aberdeen,postcode = AB7 5SU, type = H, rooms = 6 , rent = 650, ownerNo = C046, branchNo =B007, staffNo = Staff(s.oid))FROM s IN StaffWHERE s.staffNo = SA9)

8. Conclusion:Though ORDBMS tries to extend the relational DBMS with object oriented concepts, it

still does not support advanced transaction models compared to OODBMS. But the features ofsecurity, integrity and viewing mechanism that are supported by ORBDMS are not fullysupported in OODBMS. There is no single extended relational data model but the degree to


7/8

which these extensions are made varies. Hence, the choice of a database system is made based onthe features demanded by the particular application in which the database system is used.

References:

[1] Vermeulen R. (1997). Upgrading Relational Databases Using Objects. Cambridge UniversityPress.[2] Thomas Connolly and Carolyn Begg, Database Systems: A Practical Approach to Design,Implementation and Management, Fourth Edition, Addison-Wesley, 2005.

[3] Developing Object-Relational Database Applications, Part 1The article was posted in the IBM website under developer works. This is the first article in atwo-part series on developing object-relational. The article was written by Paul Brown.URL:http://www.ibm.com/developerworks/db2/library/techarticle/0206brown/0206brown1.html

[4] Object Persistence in Object Oriented ApplicationsThis paper was posted in Journals home page of IBM. The paper was written by V. Srinivasanand D. T. Chang. URL:http://researchweb.watson.ibm.com/journal/sj/361/srinivasan.html

[5]THE DESIGN OF POSTGRESThe paper was posted in the Database Group section of theComputer Science Division at the University of California, Berkeley.URL:http://db.cs.berkeley.edu//papers/ERL-M85-95.pdf
http://www.ibm.com/developerworks/db2/library/techarticle/0206brown/0206brown1.htmlhttp://www.ibm.com/developerworks/db2/library/techarticle/0206brown/0206brown1.htmlhttp://www.ibm.com/developerworks/db2/library/techarticle/0206brown/0206brown1.htmlhttp://researchweb.watson.ibm.com/journal/sj/361/srinivasan.htmlhttp://researchweb.watson.ibm.com/journal/sj/361/srinivasan.htmlhttp://researchweb.watson.ibm.com/journal/sj/361/srinivasan.htmlhttp://db.cs.berkeley.edu/papers/ERL-M85-95.pdfhttp://db.cs.berkeley.edu/papers/ERL-M85-95.pdfhttp://db.cs.berkeley.edu/papers/ERL-M85-95.pdfhttp://db.cs.berkeley.edu/papers/ERL-M85-95.pdfhttp://researchweb.watson.ibm.com/journal/sj/361/srinivasan.htmlhttp://www.ibm.com/developerworks/db2/library/techarticle/0206brown/0206brown1.html


8/8

Figures:

Figure 1: Four-quadrant view of the database world[1].

Documents

Object-Relational Database Systems -- An Introduction