The object-oriented database model provides for the storage of data as objects. Objects are modulated in the same way as object-oriented programming. An object defined as an entity contains:
- The properties (attributes) required to describe the entity
- Links (relationships) to other objects
- Functions that allow access to the stored data (methods)
- An object can be defined as a group of data whose interface can be used to access data. Objects are abstract data types.
The object-oriented database management system (ODBMS) automatically assigns an ID to each object. This makes it possible to uniquely identify the object and address it with methods. This object ID is state-independent, which is to say it is decoupled from the object values. This makes it possible to give two objects with the same data (the same status) two different IDs. This clearly differentiates the object-oriented database model rom the relational model, in which each tuple can be identified from its data (e.g. by a primary key).
Another characteristic of the object-oriented database model is data encapsulation. Stored data can only be accessed using the previously defined methods. The data encapsulated in the object is then protected against charges through undefined interfaces.
Database structures are defined in the object-oriented database model using a hierarchical classification system. In object-oriented programming, a class is a set of objects that have the same characteristics. Each object class is based on a class definition. This schema specifies the attributes and methods of all objects in the class and so determines how they are created and changed.
Users interact with the ODBMS using an SQL-based query language for object databases: the object query language (OQL). The result of an OQL query is not a result set as with SQL, but a list of those objects that meet the conditions of the OQL statement.
Known implementations of the object-oriented database model are Realm, ZODB, and Perst.
Object-oriented databases were developed as a solution to a problem in application development called object-relational impedance mismatch.
If objects from an object-oriented programming language (e.g. C#, C++, or Java) are to be stored in relational database, incompatibilities inevitably occur due to fundamental differences between the two programming paradigms.
- Relational databases do not support object-oriented concepts like classes and inheritance
- State-independent object identification cannot be implemented in the relational database model
- The data encapsulation protection mechanism is not available in the relational database model
One approach to avoid these incompatibility problems is to do without relational databases and use an object database instead in object-oriented application programming. However, this is inevitably accompanied by the disadvantage that data encapsulated in objects is not available independently of the associated application. Added to this is the low distribution of object databases. Most tools and interfaces for analyzing data sets are still designed for relational databases and do not support the object-oriented data model.
However, application developers who do not want to give up the advantages of relational data storage can compensate for incompatibilities using object-relational mappers (O/R mappers). Object-relational mapping functionalities (ORM) are implemented in libraries. These create an abstraction layer between the object-oriented application and the data stored in tables.
Numerous relational database manufacturers also equip their products with functions that compensate for incompatibilities in object-oriented programming. Database systems of this kind are known as “object-relational.”