The relational model is well established in the database world. Its simplicity makes it easy to understand, and powerful tools exist to support relational databases. There are, however, many applications where the limitations of the relational model make the mapping of the data model to the database model difficult and even severely affect the performance.
Object oriented databases are appearing mainly from two sources. A number of relational databases are being modified into object oriented databases by using an extended relational model. These usually perform well and offer all the traditional database services such as recovery, transactions and query optimizations; however, they do not necessarily interface well to object oriented languages.
In other cases, an object oriented language gets persistent objects to which database services such as indexing and querying are added. The integration with the language is good but the database services are usually limited.
Most relational databases only support fixed size objects. Each field must have a fixed length. For example, if the family name field size is too short, several names will not fit, but if it is too long a lot of space is wasted. Furthermore, the number of fields is fixed. Since, for instance, in some cases co-owners own a home, the ownership information must be stored in a separate database from the homes. One database would store the homes, another the persons and a third would store the ownership relations (records with a person identifier and a home identifier). Object oriented databases usually dont have this fixed size limitation.
The effect of fixed field length limitation is wasted space and a larger database, hence a smaller fraction of it remains in high speed memory. The fixed number of fields results in spreading the information across several database items, hence requiring several disk accesses instead of one. In applications with complex modeling requirements, keeping in a single database item the information about a home, a medical patient, or a mechanical part can speed up by 10 or more the retrieval time.
Variable length fields and repeatable fields make the database support tools, including indexing, somewhat more complex but much more flexible.
The basis of the relational model is using the primary key to relate items between databases. For example, each entry in a home database would be assigned a unique identifier (name or number). This identifier can then be used in other databases to specify a particular home. These identifiers are defined and managed explicitly. Several object oriented databases automatically assign a unique object identifier to each entry; these can then be used to refer to objects in the database.
The advantages of unique object identifiers are that they are generated automatically and that they are designed to be accessed very quickly, often through memory based hash tables. The disadvantage of automatically generated identifiers is when exceptional conditions require humans to examine these identifiers, for example if the database is corrupted or when two databases need to be merged. Indeed, when two separate databases are merged together, the same identifiers may used in each. Something must be done to translate object identifiers such that the new identifiers are unique with respect to the merged database.
With variable length fields, repeatable fields and object identifiers, it becomes feasible to model not only structures but also lists, arrays and pointers. This richer database model makes it possible to have a single model used both for the database and for the in memory representation of objects, when these are manipulated by regular programs. Having a single data model, conversion routines between the database and the in memory representation may be avoided.
To match object oriented languages, single or multiple inheritance of fields is easily added. Methods, although there are technical problems with this, may also be added to the database model.
Pointers to procedures, for instance in a method table, may in principle be stored in the database. If these procedures are in an interpreted language, this is fairly easy. The procedure source code is stored somewhere in the database and may be retrieved to be interpreted.
Source code in a safe programming language may also be stored in the database and be compiled and dynamically linked upon retrieval; not all operating systems and languages support such dynamic linking. Unsafe source code, which may destroy the application through incorrect pointer arithmetic, may be loaded in the same way only if trusted.
When dynamic compilation and linking is not feasible or too slow, it is also possible to store only procedure identifiers and hope that these procedures are available in the program retrieving the procedure identifiers. The program, for this purpose, must maintain a table of addresses of available procedures, accessed using the procedure identifiers.