Data Model: Oodbms Vs. Rdbms

1 Data model: OODBMS vs. RDBMS

For this coursework two kinds of data models can be used. The object oriented data model, Object Oriented Database Management System(OODBMS), or the relational data model, Relational Database Management System(RDBMS). The differences between these two models and the data model to be used are described in this chapter.

1.1 Enumeration of some specifications of OODBMS and RDBMS

RDBMS have been around for more than 20 years, OODBMS are relatively new;

RDBMS can handle >10.000.000.000 records, OODBMS up to 10.000.000.

OODBM is good for storing complex descriptions (e.g., a plant schematic), RDMSs appropriate for simple, “flat” data.

RDBMS control the DB market (>90%), OODBMS own <5% of the market.

The relational model, as implemented in most RDBMSs, can represent a lot of different models, but has difficulty representing inheritance hierarchies, and complex relationships (many many-to-many's) are costly to process

1.2 Advantages of an OODBMS

1. Composite Objects and Relationships: Objects in an OODBMS can store an arbitrary number of atomic types as well as other objects. It is thus possible to have a large class which holds many medium sized classes which themselves hold many smaller classes, ad infinitum. In a relational database this has to be done either by having one huge table with lots of null fields or via a number of smaller, normalized tables which are linked via foreign keys. Having lots of smaller tables is still a problem since a join has to be performed every time one wants to query data based on the "Has-a" relationship between the entities. Also an object is a better model of the real world entity than the relational tuples with regards to complex objects. The fact that an OODBMS is better suited to handling complex,interrelated data than an RDBMS means that an OODBMS can outperform an RDBMS by ten to a thousand times depending on the complexity of the data being handled.

2. Class Hierarchy: Data in the real world is usually has hierarchical characteristics. The ever popular Employee example used in most RDBMS texts is easier to describe in an OODBMS than in an RDBMS. An Employee can be a Manager or not, this is usually done in an RDBMS by having a type identifier field or creating another table which uses foreign keys to indicate the relationship between Managers and Employees. In an OODBMS, the Employee class is simply a parent class of the Manager class.

3. Circumventing the Need for a Query Language: A query language is not necessary for accessing data from an OODBMS unlike an RDBMS since interaction with the database is done by transparently accessing objects. It is still possible to use queries in an OODBMS however.

4. No Impedence Mismatch: In a typical application that uses an object oriented programming language and an RDBMS, a signifcant amount of time is usually spent mapping tables to objects and back. There are also various problems that can occur when the atomic types in the database do not map cleanly to the atomic types in the programming language and vice versa. This "impedance mismatch" is completely avoided when using an OODBMS.

5. No Primary Keys: The user of an RDBMS has to worry about uniquely identifying tuples by their values and making sure that no two tuples have the same primary key values to avoid error conditions. In an OODBMS, the unique identification of objects is done behind the scenes via OIDs and is completely invisible to the user. Thus there is no limitation on the values that can be stored in an object.

6. One Data Model: A data model typically should model entities and their relationships, constraints and operations that change the states of the data in the system. With an RDBMS it is not possible to model the dynamic operations or rules that change the state of the data in the system because this is beyond the scope of the database. Thus applications