Object-oriented Database Management Systems (ODBMS or OODBMS)
offer persistent storage for object data, often with direct
bindings to object-oriented programming languages. They distinguish
themselves from relational databases (RDBMS)
in the following key points:

Complex objects can be stored without segmentation:

RDBMS require data to be normalized to avoid
redundancies. This means that the values belonging to
one logical unit (the object) are often spread over several database
relations. To access the whole object or its
interrelationships with other objects several
joins may be necessary. But joins are one of the most costly
operation in the relational model and thus traversals
of object structures consisting of thousands of objects become too
slow for applications like e.g. CAD. Also, storing an object
without segmenting it eases clustering of the database.

User definable abstract data types
(the classes):

RDBMS only allow to model and store data, the logic
for handling this data remains wholly in the
applications using the database (this is not exactly
true for active databases, though). ODBMS on the
other hand allow to incorporate the behavioral aspects of the data
into the database itself which can ease consistency maintenance
and behavior updates, and allows additional transaction models.

Object identity is inherent in the data model:

RDBMS often introduce artificial keys into the
database model to ensure different entities are represented
as different even though all 'natural' values are the same (e.g. two
points at (1,1) in a collection of geometric figures). The
uniqueness and the referential integrity of these artificial
keys have to be ensured explicitly by the database or the
applications, which costs time. In ODBMS object identity is an
inherent concept of the language.

No impedance mismatch between programming language and
DBMS:

The relational query language SQL differs from normal
programming language in some respects and
therefore makes coupling difficult. For example relational databases
handle collections of data as sets whereas most programming
languages can handle only single data items. Also, SQL is not
turing-complete, which requires any calculation of a transitive closure
(e.g. all ancestors of a person) to be done in the
programming language.

These differences also allow ODBMS to choose more efficient
strategies in other areas: Transaction
mechanism can take advantage of the enhanced knowledge about the
semantics of operations on the data: E.g. two
"increment a by n" operations are associative and can
therefore be exchanged when serializing operations; two "Read
a, Write a" operations can't. Also versioning and
configuration management are simpler if objects remain unsegmented.
Beginning in the mid 90ties the developers of RDBMS have reacted to
some of these deficiencies and introduced object-oriented concepts
into their databases leading to so called Object-Relational DBMS
(ORDBMS).

A major architectural distinction of ODBMS is between page servers and object servers. In a page
server architecture the database server handles all data with
the minimum granularity of a (memory) page. The individual
objects are retrieved from these pages only on the client side. In
an object server architecture the database client and server
communicate on the basis of individual objects. This has major
consequences on how and where transaction management, recovery
and method execution are implemented. In principle, page servers
should be more efficient for direct object access whereas object
servers should excel if queries can be split between client-
and server-side.