Why Aren't You Using An OODMS?

Dare Obasanjo contributed this piece about a subject that probably only a very few people have ever taken the time to consider, or had to. Below he asks the musical question "Why aren't you using an Object Oriented Database Management System?"Update: 05/04 02:11 PM by H :This is also running on K5 - yes, that's on purpose, and yes, Dare, myself and Rusty all know. *grin*

Why Aren't You Using An Object Oriented Database Management System?

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.

What follows is a condensed version of the following paper; An Exploration of Object Oriented Database Management Systems, which I wrote as part of my independent study project under Dr. Sham Navathe.

Introduction

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.
   
   

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(TM) database
   
import COM.odi.*;
import COM.odi.util.query.*;
import COM.odi.util.*;
import 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(TM)
   
   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(TM) database
   
   import COM.odi.*;
import COM.odi.util.query.*;
import COM.odi.util.*;
import 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(TM)
   
   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 becomes 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(TM) database
   
   import COM.odi.*;
import COM.odi.util.query.*;
import COM.odi.util.*;
import 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(TM)
   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

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 separate 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.