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

1. Object Oriented Principals In Database
Abstract: 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 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, Computationalcompleteness , Extensibility,P
ersistence , Secondary storage management,
Concurrency, Recovery and an Ad Hoc Query
Facility.
Keywords: Object oriented model, database, DBMS,
OODB, object oriented system, RDBMS, class types.
I.INTRODUCTION
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 particular 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 integrity 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
Fig 1: OODB
II. 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
behaviours. 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) while relational databases
typically do not have computationally complete
programming capabilities although some stored
procedure languages come close.

2. Fig 2: Comparisons Of OODBMSs To RDBMSs
III. Advantages
a. 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.
b. 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.
c. 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.
d. No Impedance Mismatch:
In a typical application that uses an object oriented
programming language and an RDBMS, a
significant 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.
e. 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.
f. 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 separate model for the operations and behaviours
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
IV. Disadvantages
a. 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.
b. Language Dependence:
An OODBMS is typically tied to a specific
language via a specific API. This means that data in

3. an OODBMS is typically only accessible from a
specific language using a specific API, which is
typically not the case with an RDBMS.
c. 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.
V. List Of Object Oriented Database
Management Systems
a. Proprietary
 Object Store
 O2
 Gemstone
 Versant
 Ontos
 DB/Explorer ODBMS
 Ontos
 Poet
 Objectivity/DB
 EyeDB
b. Open Source
 Ozone
 Zope
 FramerD
 XL2
VI. OODBS Features
To have an idea about OODBS, the table shows the
correspondence between object oriented and
relational database systems:
Fig 3: OODBS Features
VI. Mandatory features of object-oriented
systems
a. Support for complex objects
A complex object mechanism allows an object to
contain attributes that can themselves be objects. In
other words, the schema of an object is not in first -
normal-form. Examples of attributes that can
comprise a complex object include lists, bags, and
embedded objects.
b. Object identity
Every instance in the database has a unique
identifier (OID), which is a property of an object
that distinguishes it from all other objects and
remains for the lifetime of the object. In object -
oriented systems, an object has an existence
(identity) independent of its value.
c. Encapsulation
Object-oriented models enforce encapsulation and
information hiding. This means, the state of objects
can be manipulated and read only by invoking
operations that are specified within the type
definition and made visible through the public
clause.
In an object-oriented database system
encapsulation is achieved if only the operations are
visible to the programmer and both the data and the
implementation are hidden.
d. Support for types or classes
 Type: in an object-oriented system,
summarizes the common features of a set of
objects with the same characteristics. In
programming languages types can be used at
compilation time to check the correctness of
programs.
 Class: The concept is similar to type but
associated with run-time execution. The term
class refers to a collection of all objects with
the same internal structure (attributes) and
methods. These objects are called instances of
the class.
Both of these two features can be used to group
similar objects together, but it is normal for a
system to support either classes or types and not
both.
e. Class or type hierarchies
Any subclass or subtype will inherit attributes and
methods from its superclass or super type.

4. f. Overriding, Overloading and Late Binding
 Overloading: A class modifies an existing
method, by using the same name, but with a
different list, or type, of parameters.
 Overriding: The implementation of the
operation will depend on the type of the object
it is applied to.
 Late binding: The implementation code cannot
be referenced until run-time.
g. Computational Completeness
SQL does not have the full power of a conventional
programming language. Languages such as Pascal
or C are said to be computationally complete
because they can exploit the full capabilities of a
computer. SQL is only relationally complete, that
is, it has the full power of relational algebra. Whilst
any SQL code could be rewritten as a C++
program, not all C++ programs could be rewritten
in SQL.
For this reason most relational database
applications involve the use of SQL embedded
within a conventional programming language. The
problem with this approach is that whilst SQL deals
with sets of records, programming languages tend
to work on a record at a time basis. This difficulty
is known as the impedance mismatch. Object-oriented
databases attempt to provide a seamless
join between program and database and hence
overcome the impedance mismatch. To make this
possible the data manipulation language of an
object-oriented database should be computationally
complete.
VII. Mandatory features of database systems
A database is a collection of data that is organized
so that its contents can easily be accessed,
managed, and updated. Thus, a database system
contains the five following features:
a. Persistence
As in a conventional database, data must remain
after the process that created it has terminated. For
this purpose data has to be stored permanently on
secondary storage.
b. Secondary Storage Management
Traditional databases employ techniques, which
manage secondary storage in order to improve the
performance of the system. These are usually
invisible to the user of the system.
c. Concurrency
The system should provide a concurrency
mechanism, which is similar to the concurrency
mechanisms in conventional databases.
d. Recovery
The system should provide a recovery mechanism
similar to recovery mechanisms in conventional
databases.
e. Ad hoc query facility
The database should provide a high-level, efficient,
application independent query facility. This needs
not necessarily be a query language but could
instead, be some type of graphical interface.
The above criteria are perhaps the most complete
attempt so far to define the features of an object-oriented
database in 1989. Further attempts to
define an OODBS standard were made variables of
researchers. One of them is a group called Object
Data Management Group (ODMG). They have
worked on an OODBS standard for the industry.
VIII. Object model
a. Classes
An object is an instance of exactly one class.
Objects with the same internal structure and
methods are grouped together into a class and are
called instances if the class.
b. Objects
An object is a chunk of private memory with a
public interface. Internally, most objects are
divided into fields called instance variables. Each
instance variable can hold a value, which is another
object. Objects communicate with other objects by
passing messages. Object is the root of all
super/subclass hierarchy.
c. Messages
Messages are requests for the receiving object to
change its state or return a result. The set of
messages an object responds to is called protocol
(its .public interface.). An object may be inspected
or changed only through its protocol. The basic
form of all message expressions is <receiver>
<message>. The <receiver> part is an identifier or
expression denoting an object that receives and
interprets the message. The <message> part gives
the selector of the message and possible arguments
to the message
d. Methods
The methods are the concrete implementations that
can be invoked by a message sent to an instance.
An object can only responds to a message if it
contains a method with a selector that matches the

5. message format. Methods are provided to query
and manipulate the internal structure.
Fig 4: Message Passing in gem stone.
e. Collection classes
A class defines the structure of its instances, but
rarely keeps track of all the instances. Instead,
collection objects . Arrays, Bags, sets . can store
groups of instances . not necessarily of the same
type . in indexable or anonymous storage slots.
GemStone provides built-in support for managing
collections of objects by the pre-defined Collection
class and its subclasses.
 Array: like String, is a subclass of Collection.s
subclass SequenceableColletion.
 Bags and Sets: are non-sequenceable
Collections, in which instance variables are
anonymous. They do not maintain any order
on their elements. The difference between a
Bag and a Set is that the ins tances of Bag may
contain the same object several times, whereas
a Set contains an element just once . even
though it might have been inserted several
times
Fig 5: Classes hierarchy of collection classes
Conclusion
The OODBMS contains extensive concepts, which
makes it a lot more complicated comparing with
the RDBS. This paper gives an introduction of
OODBMS concepts and its principles.
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 new application development unless
there are legacy issues that have to be dealt with.
Acknowledgement:
I will like to thank our Prof. for giving the chance
to explore oneself.
References:
[1]. http://www.dacs.dtic.mil/techs/oodbms2
[2].http://www.25hoursaday.com/WhyArentYouUs
ingAnOODBMS.html
[3]. http://www.scribd.com/doc/42099675/Paper-
Object-Oriented-Database-Theory
[4].ieor.berkeley.edu/~goldberg/courses/F04/215/2
15-OODB.ppt
[5].http://dusk.geo.orst.edu/buffgis/PPT/geo580_6_
oo10.ppt