Object Oriented Database Learning Center

Objectivity Home - Government - Objectivity/DB - Webinars - Download Software

Table of contents:

Object Oriented Database vs Relational Database

Productivity

The data model used by a RDBMS is not natural from a programmer's point of view. A software engineer working in an Object-Oriented language like C++ is use to dealing with data abstractions. These abstractions may be directly modeled by C++ and they bind data and operations on that data together into a single entity. An OODBMS makes C++ data abstractions persistent. From a code view there is almost no difference between a transient instance that lives and dies in RAM verses a long lived instance that is managed by the OODBMS. This means that the persistent entities are made available to the engineer in seamless fashion. The OODBMS is not obtrusive in the application's code.

Alternatively, a RDBMS is very visible to a software engineer working in a C++ environment. Here the engineer is fully cognizant of the fact that two representations of the entities exist, the natural C++ version of an object and it's RDBMS counterpart which may be spread over multiple relational tables. This mapping between the tables in the RDBMS and the natural in memory form of an object must be managed with code provided by the software engineer. There is no alternative here; the mappings must be identified and code must be written to handle the mappings.

The basic types of information stored by a RDBMS are very limited. A RDBMS has support for primitive data such as: [integer + real + text + date]. A RDBMS has no provision for storing complex data abstractions built up through aggregation or inheritance. An OODBMS can directly manage user defined data abstractions based on aggregation or inheritance.

An OODBMS also maintains semantic information that is not available in an RDBMS. Relationships that must be derived in a RDBMS through selection and join operations are explicitly kept in the OODBMS. The operations that may be invoked upon entities managed by an OODBMS are defined by the data abstraction that the engineer designs. The RDBMS has no way to bind behavior to objects. This must be done through convention and represents a large opportunity for introducing errors.

The data model produced by the software engineer during the analysis and design phase of project may be directly and simply mapped to an OODBMS' schema. With a RDBMS, data abstractions must be decomposed into a set of tables that conform to the normal forms of the relational rules.

There's also an impedance mismatch between the way that data is available through a RDBMS verses an OODBMS. An engineer working with a RDBMS works in SQL; that is all access to information managed by the database is framed in the context of SQL. SQL is an excellent way to work with data on an ad hoc basis, but a developer wants the information in terms of the data abstractions that were identified in the analysis and design phase of the project. This is not possible using the SQL access afford by an RDBMS.

A developer working with an OODBMS directly sees the same data abstractions in the database that were identified during analysis and design. No queries are used. This gets back to the fact that objects managed by an OODBMS appear to an application developer in a seamless fashion.

OODBMS directly support reuse through inheritance. This concept is absent from a RDBMS. Commercial grade container libraries and other third party class libraries may be easily stored in OODBMS. This is not possible with a RDBMS.

All of these differences between OODBMS and RDBMS result in a real and sizable productivity gain for developers working with OODBMS.