AN EXPLORATION OF
OBJECT ORIENTED DATABASE
MANAGEMENT SYSTEMS
By
Dare Obasanjo
Introduction: Why Object Oriented Database Management Systems?
In today's world, Client-Server applications that rely on a database on the server as a
data store while servicing requests from multiple clients are quite commonplace. Most
of these applications use a Relational Database Management System (RDBMS) as their
data store while using an object oriented programming language for development. This
causes a certain inefficency as objects must be mapped to tuples in the database and
vice versa instead of the data being stored in a way that is consistent with the
programming model. The "impedance mismatch" caused by having to map objects to
tables and vice versa has long been accepted as a necessary performance penalty. This
paper is aimed at seeking out an alternative that avoids this penalty.
The purpose of this paper is to provide answers to the following questions
What is an Object Oriented Database Management System (OODBMS)?
Is an OODBMS a viable alternative to an RDBMS?
What are the tradeoffs and benefits of using an OODBMS over an RDBMS?
What does code that interacts with an OODBMS look like?
Overview of Object Oriented Database Management Systems
An OODBMS is the result of combining object oriented programming principles with
database management principles. Object oriented programming concepts such as
encapsulation, polymorphism and inheritance are enforced as well as database
management concepts such as the ACID properties (Atomicity, Consistency, Isolation
and Durability) which lead to system integrity, support for an ad hoc query language
and secondary storage management systems which allow for managing very large
amounts of data. The Object Oriented Database Manifesto [Atk 89] specifically lists the
following features as mandatory for a system to support before it can be called an
OODBMS; Complex objects, Object identity, Encapsulation , Types and Classes , Class
or Type Hierarchies, Overriding,overloading and late binding, Computational
completeness , Extensibility, Persistence , Secondary storage management,
Concurrency, Recovery and an Ad Hoc Query Facility.
From the aforementioned description, an OODBMS should be able to store objects that
are nearly indistinguishable from the kind of objects supported by the target
programming language with as little limitation as possible. Persistent objects should
belong to a class and can have one or more atomic types or other objects as attributes.
The normal rules of inheritance should apply with all their benefits including
polymorphism, overridding inherited methods and dynamic binding. Each object has an
object identifier (OID) which used as a way of uniquely identifying a particuler object.
OIDs are permanent, system generated and not based on any of the member data within
the object. OIDs make storing references to other objects in the database simpler but
may cause referential intergrity problems if an object is deleted while other objects still
have references to its OID. An OODBMS is thus a full scale object oriented
development environment as well as a database management system. Features that are
common in the RDBMS world such as transactions, the ability to handle large amounts
of data, indexes, deadlock detection, backup and restoration features and data recovery
mechanisms also exist in the OODBMS world.
A primary feature of an OODBMS is that accessing objects in the database is done in a
transparent manner such that interaction with persistent objects is no different from
interacting with in-memory objects. This is very different from using an RDBMSs in
that there is no need to interact via a query sub-language like SQL nor is there a reason
to use a Call Level Interface such as ODBC, ADO or JDBC. Database operations
typically involve obtaining a database root from the the OODBMS which is usually a
data structure like a graph, vector, hash table, or set and traversing it to obtain objects to
create, update or delete from the database. When a client requests an object from the
database, the object is transferred from the database into the application's cache where it
can be used either as a transient value that is disconnected from its representation in the
database (updates to the cached object do not affect the object in the database) or it can
be used as a mirror of the version in the database in that updates to the object are
reflected in the database and changes to object in the database require that the object is
refetched from the OODBMS.
Comparisons of OODBMSs to RDBMSs
There are concepts in the relational database model that are similar to those in the object
database model. A relation or table in a relational database can be considered to be
analogous to a class in an object database. A tuple is similar to an instance of a class but
is different in that it has attributes but no behaviors. A column in a tuple is similar to a
class attribute except that a column can hold only primitive data types while a class
attribute can hold data of any type. Finally classes have methods which are
computationally complete (meaning that general purpose control and computational
structures are provided [McF 99]) while relational databases typically do not have
computationally complete programming capabilities although some stored procedure
languages come close.
Below is a list of advantages and disadvantages of using an OODBMS over an RDBMS
with an object oriented programming language.
Advantages
1. Composite Objects and Relationships: Objects in an OODBMS can store an
arbitrary number of atomic types as well as other objects. It is thus possible to
have a large class which holds many medium sized classes which themselves
hold many smaller classes, ad infinitum. In a relational database this has to be
done either by having one huge table with lots of null fields or via a number of
smaller, normalized tables which are linked via foreign keys. Having lots of
smaller tables is still a problem since a join has to be performed every time one
wants to query data based on the "Has-a" relationship between the entities. Also
an object is a better model of the real world entity than the relational tuples with
regards to complex objects. The fact that an OODBMS is better suited to
handling complex,interrelated data than an RDBMS means that an OODBMS
can outperform an RDBMS by ten to a thousand times depending on the
complexity of the data being handled.
2. Class Hierarchy: Data in the real world is usually has hierarchical
characteristics. The ever popular Employee example used in most RDBMS texts
is easier to describe in an OODBMS than in an RDBMS. An Employee can be a
Manager or not, this is usually done in an RDBMS by having a type identifier
field or creating another table which uses foreign keys to indicate the
relationship between Managers and Employees. In an OODBMS, the Employee
class is simply a parent class of the Manager class.
3. Circumventing the Need for a Query Language: A query language is not
necessary for accessing data from an OODBMS unlike an RDBMS since
interaction with the database is done by transparently accessing objects. It is still
possible to use queries in an OODBMS however.
4. No Impedence Mismatch: In a typical application that uses an object oriented
programming language and an RDBMS, a signifcant amount of time is usually
spent mapping tables to objects and back. There are also various problems that
can occur when the atomic types in the database do not map cleanly to the
atomic types in the programming language and vice versa. This "impedance
mismatch" is completely avoided when using an OODBMS.
5. No Primary Keys: The user of an RDBMS has to worry about uniquely
identifying tuples by their values and making sure that no two tuples have the
same primary key values to avoid error conditions. In an OODBMS, the unique
identification of objects is done behind the scenes via OIDs and is completely
invisible to the user. Thus there is no limitation on the values that can be stored
in an object.
6. One Data Model: A data model typically should model entities and their
relationships, constraints and operations that change the states of the data in the
system. With an RDBMS it is not possible to model the dynamic operations or
rules that change the state of the data in the system because this is beyond the
scope of the database. Thus applications that use RDBMS systems usually have
an Entity Relationship diagram to model the static parts of the system and a
seperate model for the operations and behaviors of entities in the application.
With an OODBMS there is no disconnect between the database model and the
application model because the entities are just other objects in the system. An
entire application can thus be comprehensively modelled in one UML diagram.
Disadvantages
1. Schema Changes: In an RDBMS modifying the database schema either by
creating, updating or deleting tables is typically independent of the actual
application. In an OODBMS based application modifying the schema by
creating, updating or modifying a persistent class typically means that changes
have to be made to the other classes in the application that interact with
instances of that class. This typically means that all schema changes in an
OODBMS will involve a system wide recompile. Also updating all the instance
objects within the database can take an extended period of time depending on
the size of the database.
2. Language Dependence: An OODBMS is typically tied to a specific language via
a specific API. This means that data in an OODBMS is typically only accessible
from a specific language using a specific API, which is typically not the case
with an RDBMS.
3. Lack of Ad-Hoc Queries: In an RDBMS, the relational nature of the data allows
one to construct ad-hoc queries where new tables are created from joining
existing tables then querying them. Since it is currently not possible to duplicate
the semantics of joining two tables by "joining" two classes then there is a loss
of flexibility with an OODBMS. Thus the queries that can be performed on the
data in an OODBMS is highly dependent on the design of the system.
Who is currently using an OODBMS to handle mission critical data?
The following information was gleaned from the ODBMS Facts website.
The Chicago Stock Exchange manages stock trades via a Versant ODBMS.
Radio Computing Services is the world's largest radio software company. Its
product, Selector, automates the needs of the entire radio station -- from the
music library, to the newsroom, to the sales department. RCS uses the POET
ODBMS because it enabled RCS to integrate and organize various elements,
regardless of data types, in a single program environment.
The Objectivity/DB ODBMS is used as a data repository for system component
naming, satellite mission planning data, and orbital management data deployed
by Motorola in The Iridium System.
The ObjectStore ODBMS is used in SouthWest Airline's Home Gate to provide
self service to travelers through the Internet.
Ajou University Medical Center in South Korea uses InterSystems' Cachè
ODBMS to support all hospital functions including mission-critical departments
such as pathology, laboratory, blood bank, pharmacy, and X-ray.
The Large Hadron Collider at CERN in Switzerland uses an Objectivity DB.
The database is currently being tested in the hundreds of terabytes at data rates
up to 35 MB/second.
As of November, 2000, the Stanford Linear Accelerator Center (SLAC) stored
169 terabytes of production data using Objectivity/DB. The production data is
distributed across several hundred processing nodes and over 30 on-line servers.
Interacting With An OODBMS
Below are Java code samples for accessing a relational database and accessing an object
database. Compare the size of the code in both examples. The examples are for an
instant messaging application.
1. Validating a user.
Java code accessing an ObjectStore™ database
import
import
import
import
COM.odi.*;
COM.odi.util.query.*;
COM.odi.util.*;
java.util.*;
try {
//start database session
Session session = Session.create(null, null);
session.join();
//open database and start transaction
Database db = Database.open("IMdatabase",
ObjectStore.UPDATE);
Transaction tr =
Transaction.begin(ObjectStore.READONLY);
//get hashtable of user objects from DB
OSHashMap users = (OSHashMap) db.getRoot("IMusers");
//get password and username from user
String username = getUserNameFromUser();
String passwd
= getPasswordFromUser();
//get user object from database and see if it exists
and whether password is correct
UserObject user = (UserObject) users.get(username);
if(user == null)
System.out.println("Non-existent user");
else
if(user.getPassword().equals(passwd))
System.out.println("Successful login");
else
System.out.println("Invalid Password");
//end transaction, close database and retain terminate
session
tr.commit();
db.close();
session.termnate();
}
//exception handling would go here ...
Java JDBC code accessing an IBM's DB2 Database™
import java.sql.*;
import sun.jdbc.odbc.JdbcOdbcDriver;
import java.util.*;
try {
//Launch instance of database driver.
Class.forName("COM.ibm.db2.jdbc.app.DB2Driver").newInstance();
//create database connection
Connection conn =
DriverManager.getConnection("jdbc:db2:IMdatabase");
//get password and username from user
String username = getUserNameFromUser();
String passwd
= getPasswordFromUser();
//perform SQL query
Statement sqlQry = conn.createStatement();
ResultSet rset = sqlQry.executeQuery("SELECT password from
user_table WHERE username='" + username +"'");
if(rset.next()){
if(rset.getString(1).equals(passwd))
System.out.println("Successful login");
else
System.out.println("Invalid Password");
}else{
System.out.println("Non-existent user");
}
//close database connection
sqlQry.close();
conn.close();
}
//exception handling would go here ...
There isn't much difference in the above examples although it does seem a lot
clearer to perform operations on a UserObject instead of a ResultSet when
validating the user.
2. Getting the user's contact list.
Java code accessing an ObjectStore™ database
import
import
import
import
COM.odi.*;
COM.odi.util.query.*;
COM.odi.util.*;
java.util.*;
try {
/* start session and open DB, same as in section 1a */
//get hashmap of users from the DB
OSHashMap users = (OSHashMap) db.getRoot("IMusers");
//get user object from database
UserObject c4l = (UserObject) users.get("Carnage4Life");
UserObject[] contactList = c4l.getContactList();
System.out.println("This are the people on Carnage4Life's
contact list");
for(int i=0; i < contactList.length; i++)
System.out.println(contactList[i].toString());
//toString() prints fullname, username, online status and
webpage URL
/* close session and close DB, same as in
section 1a */
}//exception handling code
Java JDBC code accessing an IBM's DB2 Database™
import java.sql.*;
import sun.jdbc.odbc.JdbcOdbcDriver;
import java.util.*;
try {
/*
open DB connection, same as in section 1b */
//perform SQL query
Statement sqlQry = conn.createStatement();
ResultSet rset = sqlQry.executeQuery("SELECT fname, lname,
user_name, online_status, webpage FROM contact_list, user_table"
+
"WHERE
contact_list.owner_name='Carnage4Life' and
contact_list.buddy_name=user_table.user_name");
System.out.println("This are the people on Carnage4Life's
contact list");
while(rset.next())
System.out.println("Full Name:" + rset.getString(1) + "
" + rset.getString(2) + " User Name:" + rset.getString(3) + "
OnlineStatus:"
+ rset.getString(4) + " HomePage URL:" +
rset.getString(5));
/*
close DB connection, same as in section 1b */
}//exception handling code
The benefits of using an OODBMS over an RDBMS in Java slowly become
obvious. Consider also that if the data from the select needs to be returned to
another method then all the data from the result set has to be mapped to another
object (UserObject).
3. Get all the users that are online.
Java code accessing an ObjectStore™ database
import
import
import
import
COM.odi.*;
COM.odi.util.query.*;
COM.odi.util.*;
java.util.*;
try{
/* same as above */
//use a OODBMS query to locate all the users whose status
is 'online'
Query q = new Query = (UserObject.class,
"onlineStatus.equals(\"online\"");
Collection users = db.getRoot("IMusers");
Set onlineUsers = q.select(users);
Iterator iter = onlineUsers.iterator();
// iterate over the results
while ( iter.hasNext() )
{
UserObject user = (UserObject) iter.next();
// send each person some announcement
sendAnnouncement(user);
}
/* same as above */
}//exception handling goes here
Java JDBC code accessing an IBM's DB2 Database™
import java.sql.*;
import sun.jdbc.odbc.JdbcOdbcDriver;
import java.util.*;
try{
/* same as above */
//perform SQL query
Statement sqlQry = conn.createStatement();
ResultSet rset = sqlQry.executeQuery("SELECT fname, lname,
user_name, online_status, webpage FROM user_table WHERE
online_status='online'");
while(rset.next()){
UserObject user = new
UserObject(rset.getString(1),rset.getString(2),rset.getString(3)
,rset.getString(4),rset.getString(5));
sendAnnouncement(user);
}
/* same as above */
}//exception handling goes here
List of Object Oriented Database Management Systems
Proprietary
Object Store
O2
Gemstone
Versant
Ontos
DB/Explorer ODBMS
Ontos
Poet
Objectivity/DB
EyeDB
Open Source
Ozone
Zope
FramerD
XL2
Description of the MultiEdit Application
MultiEdit allows multiple users, potentially on different machines to edit a file
simultaneously. Each user has his or her own view of the file, and each view includes its
own cursor. Users may enter text into (the same or different points of) the file
simultaneously. It is an essential requirement of the application that the contents of the
file must always be kept consistent with the actions of users.
Javadocs For The Project Are Available
This project uses a Client/Server architecture to handle the difficulty of maintaining
consistency between multiple clients trying to edit the same document at once. Each
document is an object of class ShareableDocument stored in an Object Oriented
Database which is remotely accessible via a DocumentManager which sits on the server
and handles client requests. Whenever a user needs to access a document it is loaded
from the database by the DocumentManager and sent to them over the network. From
then on whenever an edit is performed by the user the actual key stroke and the position
of the cursor is sent to the server which updates an in memory copy of the object before
broadcasting the event to all users who are currently accessing the document including
the user that originally performed the edit.
The main drawback of the above method is that the user who is typing the document
will most likely experience a lag between when a character is typed and when it shows
up on the GUI which is dependent on the speed of the network. Also if there is a
network outage or similar error then the user cannot edit the document.
Saves are simply requests to the server to persist its in memory copy of the document
which is more efficient than sending the whole document to the server.
ShareableDocuments are not saved unless explicitly specified by a user or when a user
closes a document. The application also allows the user to lock entire
ShareableDocuments which prevents others from modifying the documents but they can
still see the edits being made by the owner of the lock in real-time
Description of Major Classes in System
User
This is a representation of a user of the system which is stored in the
ObjectStore™ database.
PersistableRemoteObject
This is an interface that describes operations that can be performed on a remote
object that is shared by multiple users.
Owner
An interface that describes any entity that owns (i.e. created) a
PersistableRemoteObject.
ShareableDocument
This is a representation of a document that can be editted by multiple users at
once or locked by a single user. It also is stored in the ObjectStore™ database
and implements the PersistableRemoteObject interface.
RemoteObjectFactory
This is an interface that describes the minimum amount of services that a server
that manages PersistableRemoteObjects must provide.
DocumentManager
This is an interface describing the methods that are remotely accessible on an
object that manages ShareableDocuments. It is a subclass of the
RemoteObjectFactory interface.
DocumentManagerImpl
This is the actual class that handles managing access to ShareableDocuments by
multiple users. It implements the DocumentManager interface and is a subclass
of Java.rmi.UnicastRemoteObject which allows it to be accessed remotely.
DocumentContext
This maintains information on a ShareableDocument that is currently being
accessed by one or more users. A table of these is kept in the
DocumentManagerImpl class to keep track of all the ShareableDocuments that
are being shared at once.
ClientView
This is the GUI that the user interacts with.
ClientControl
This does event handling for the ClientView.
ClientModel
This is the underlying model for the ClientView that contains data structures,
maintains state and communicates with the server. It implements the
ClientListener interface.
ClientListener
This is an interface that describes the methods that are remotely accessible on
the ClientModel. The method that allows the client receive keystroke events
from server is in this interface.
ClientState
This is an object that represents the current state of the ClientView.
LoginDialog
GUI used for logging on to the server.
AddUserDialog
GUI used for adding a new user to the system.
DocumentSelectionDialog
GUI used to select which document to edit.
MultiEdit State Diagram
Discarded Design Decisions and Potential Future Development of
MultiEdit
The original design called for a Paragraph object that would be a part of a
ShareableDocument and would be the atomic unit capable of being locked by a user.
Unfortunately the amount of semantic analysis required during runtime to constantly
reparse the document to decide what textual divisions indicated a paragraph degraded
performance to an unsatisfactory extent. Also a good solution is a non-trivial task.
Certain considerations were made towards locking lines if they were being accessed by
other users but this was outside the original specifications. Also originally each user
updated their GUI before sending the key stroke to the server, this meant that if some
other client had gotten to the server just before it and updated its GUI, then their
representations of the document would beout of sync. The solution was to make sure
that GUIs were not updated until the keystrokes had reached the server and were
broadcast to all interested parties. Finally the decision to keep a copy of the document
on the server instead of simply using the server to relay updates is so that when a new
user requests a document that is already being accessed by two or more users, there is
an effective way to give send the document without worrying about consistency issues.
Conclusion
The gains from using an OODBMS while developing an application using an OO
programming language are many. The savings in development time by not having to
worry about seperate data models as well as the fact that there is less code to write due
to the lack of impedance mismatch is very attractive. In my opinion, there is little reason
to pick an RDBMS over an OODBMS system for newapplication development unless
there are legacy issues that have to be dealt with.
This paper is the final part of my indepedent study supervised by Dr. Sham Navathe and
Wai Gen Yee.
Bibliography
1. OODBMS Facts. Barry & Associates. 29 April
2001<http://www.odbmsfacts.com/>
2. Atkinson, Malcolm et al. The Object-Oriented Database Manifesto. In
Proceedings of the First International Conference on Deductive and ObjectOriented Databases, pages 223-40, Kyoto, Japan, December 1989 <
http://www.cs.cmu.edu/People/clamen/OODBMS/Manifesto/htManifesto/Manif
esto.html >
3. McFarland, Gregory, Andres Rudmik, and David Lange. Object-Oriented
Database Management Systems Revisited. 31 January 1999
.<http://www.dacs.dtic.mil/techs/oodbms2/>
© 2001 Dare Obasanjo