Object Oriented Database Learning Center

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

Table of contents:

Object Oriented Database vs Relational Database

Performance

RDBMS decompose all data into relational tables. The rules for this decomposition are collectively referred to as the 1st, 2nd, and 3rd normal forms. These rules provide a simple and powerful way to organize data into rows contained within tables. For some problem domains this method of data organization provides quick and convenient access to information. A good example would be a checking account. Individual checks are represented as a row in a table with columns for the check number, date, payee, and the amount. A RDBMS could provide a software application expedient access to this data.

Distributed Control Blocks with 1:M I/O

Another example would be blocks in a Distributed Control System (DCS). Here the RDBMS would setup relational tables to hold information pertinent to a block. Much of the information in this problem domain is hierarchical and may be modeled using 1 to N or N to M sets of relationships. To show these hierarchical relationships in a RDBMS another table(s) would be setup mapping one row from the first table to another row(s) in some other table. As an example consider that the outputs of one block would be mapped to the inputs of other blocks. With a RDBMS a separate table must be inspected at the time of the query to determine which output is routed to which inputs. This operation is an example of selecting a set of rows from a table. If we needed to determine what types of blocks receive input from a specific output, then multiple tables must be inspected at the time of the query. This operation is referred to as a join, and it is expensive. The expense of a query dramatically increases as more tables are brought into consideration.

Alternatively, an OODBMS provides support for directly modeling the block and the mappings of block outputs to block inputs. No run-time selection from a table is required to determine which inputs are mapped to a specific output. No runtime joins of multiple tables are required to determine what types of blocks receive input from a specific output.

The OODBMS provide explicit support for 1 to N and N to M relationships. These relationships and the semantic information that they represent becomes an integral part of the data managed by the OODBMS. Not only is the data available to an application, but this semantic information is available with out the expense of a run-time selection or join. A RDBMS does not maintain this semantic information.

The way that an OODBMS stores information on disk is that same as the in memory representation. RDBMS store data in a format on the disk that is different from the in-memory form needed by applications; selects and joins are used to bridge these two formats at run-time. This fundamental dissimilarity causes dramatic differences in run-time performance of applications that deal in problem domains with 1 to N and N to M relationships.

A set of benchmarks run by Sun in 1990 showed that for certain classes of data an OODBMS would out perform a RDBMS by at least one order of magnitude. FRSI applications primarily work with data that fits this pattern.