Object-Oriented

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 avoid redundancies. This means that the values belonging to one logical unit (the object) are often spread over several databaserelations. 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 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.