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

Complex objects can be stored without segmentation:

RDBMS require data to be normalized to avoidredundancies. This means that the values belonging toone logical unit (the object) are often spread over several databaserelations. To access the whole object or itsinterrelationships with other objects severaljoins may be necessary. But joins are one of the most costlyoperation in the relational model and thus traversalsof object structures consisting of thousands of objects become tooslow for applications like e.g. CAD. Also, storing an objectwithout segmenting it eases clustering of the database.

User definable abstract data types(the classes):

RDBMS only allow to model and store data, the logicfor handling this data remains wholly in theapplications using the database (this is not exactlytrue for active databases, though). ODBMS on theother hand allow to incorporate the behavioral aspects of the datainto the database itself which can ease consistency maintenanceand behavior updates, and allows additional transaction models.

Object identity is inherent in the data model:

RDBMS often introduce artificial keys into thedatabase model to ensure different entities are representedas different even though all 'natural' values are the same (e.g. twopoints at (1,1) in a collection of geometric figures). Theuniqueness and the referential integrity of these artificialkeys have to be ensured explicitly by the database or theapplications, which costs time. In ODBMS object identity is aninherent concept of the language.

No impedance mismatch between programming language andDBMS:

The relational query language SQL differs from normalprogramming language in some respects andtherefore makes coupling difficult. For example relational databaseshandle collections of data as sets whereas most programminglanguages can handle only single data items. Also, SQL is notturing-complete, which requires any calculation of a transitive closure(e.g. all ancestors of a person) to be done in theprogramming language.

These differences also allow ODBMS to choose more efficientstrategies in other areas: Transactionmechanism can take advantage of the enhanced knowledge about thesemantics of operations on the data: E.g. two"increment a by n" operations are associative and cantherefore be exchanged when serializing operations; two "Reada, Write a" operations can't. Also versioning andconfiguration management are simpler if objects remain unsegmented.Beginning in the mid 90ties the developers of RDBMS have reacted tosome of these deficiencies and introduced object-oriented conceptsinto 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 pageserver architecture the database server handles all data withthe minimum granularity of a (memory) page. The individualobjects are retrieved from these pages only on the client side. Inan object server architecture the database client and servercommunicate on the basis of individual objects. This has majorconsequences on how and where transaction management, recoveryand method execution are implemented. In principle, page serversshould be more efficient for direct object access whereas objectservers should excel if queries can be split between client-and server-side.