ODBMS VS RDBMS

By Umair Rabbani

ODBMS add database functionality to object programming languages. Object DBMSs broaden the semantics of the object programming languages to offer full-featured database programming facility, while retaining native language compatibility.

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 scenario this method of data organization provides quick and convenient access to information but there are cases when it becomes Complex.

Let us consider an example in which a person wants to store a car in the garage at the end of the day. In a relational system, all data needs to be normalized; i.e., it must be flattened to primitives and sorted by type. It means that the car must be disassembled, down to its primitive elements, which must each be stored in separate tables. So, the screws go in one table, and the nuts in another, and the wheels, and side panels, and pistons, etc. In the morning, when he wishes to drive to work, he must first reassemble the automobile, and then he can drive off.

This may sound exaggerated but it is not very different from many applications that are working. Whenever the application has complex (non-tabular, varying sized, interrelated) data structures, the application programmer must write code to translate from those data structures down to flat tables. This translation code has three problems.

1. Programming Time and Cost i.e. a programmer must hire to perform all such development.
2. Integrity Loss i.e. it may possible that one programmer will do this mapping differently from other another programmer, resulting in a mismatch in their work and integrity violations.
3. Performance i.e. nested structures or varying-sized structures require multiple RDBMS tables, and joins between them. The join, although it's quite flexible, but it requires a search-and-compare operation, which takes time, and gets slower as the database tables get larger. 

In contrast, ODBMS have no performance overhead to store or retrieve a hierarchy of interrelated objects.  Let’s take the same example of car. In an ODBMS, this is modeled with an object for the car, another for the garage, one method or function “store”.  Due to unification of the application and database development into a seamless data model and language environment, applications require less code, use more natural data modeling, and code bases are easier to maintain. Moreover, the one-to-one mapping of object provides higher performance management of objects, and it enables better management of the complex interrelationships between objects.