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
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.
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.
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.
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 ...
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.
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
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 codeThe 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).
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
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
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.
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 SystemThis paper is the final part of my indepedent study supervised by Dr. Sham Navathe and Wai Gen Yee.