RDBMS, OODBMS and ORDBMS with the Comparison
RDBMS, OODBMS and ORDBMS with the Comparison is given as below points.
Comparing the RDBMS with the OODBMS:
- These two types of data modeling is represented by the encapsulation(binds together the data and functions that manipulate the data, and that keeps both safe from outside interference and misuse) in the object of both is state and behavior with the object oriented model, while with the relational model only the state is evidenced.
- Relational database is made up of relations, who are sets of tuples (Tuplesare sequences, just like lists), while an object-oriented database is made up of classes (A class can be defined as a template that describes the behaviors/states), which are sets of classes.
- The class(OODBMS) hierarchy includes inheritance, while the scheme(RDBMS) includes external keys
- In the relational model there is a primary key that refer the related data, while object oriented model there is an object identifier (OID) that refer the inherited data.
|Main objectives: data encapsulation and independence.||Main objective: ensuring data independence from application programs.|
|Independence of classes: classes can be reorganized without affecting the mode of using them.||Data independence: Data can be reorganized and modified without affecting the mode of using them.|
|OODBMS store data and methods.||RDBMS store only data.|
|Encapsulation: the data can be used only through their classes’ methods.||Data partitioning: data can be partitioned depending on the requirements of the users and on the specific user’s applications.|
|Active objects: the objects active. Requests cause objects to execute their methods.||Passive data: the data are passive. Certain operations, which are limited, can be automatically brought into use when the data are used.|
|Complexity: the structure of data may be complex, involving different types of data.||Simplicity: users perceive data as columns, rows/tuples and tables.|
|Chained data: data can be chained so that the methods of classes may bring about increased performance. Structured data such as BLOBS (binary large objects) are used for sound, image, video etc.||Separate Tables: each relation/table is separate. The Join Operator refers data from separate tables.|
|Non-redundancy of methods: data and methods non-redundancy is achieved through encapsulation and inheritance. Inheritance helps to reduce the redundancy of methods.||Data non-redundancy: data normalization aims at eliminating or reducing data redundancy. It is used in the stage of designing the database and not in the stage of developing the applications.|
|Optimizing classes: the data for an object can be interrelated and stored together, so that they may all be accessed by the access mechanism||RDBMS performance is related to the level of complexity of the data structure.|
Comparing the ORDBMS with the OODBMS:
- OODBMSs and ORDBMSs both support user-defined ADTs, structured types, object identity and reference types, and in-heritance
- They both support a query language for manipulating collection types.
- ORDBMSs support an extended form of SQL, and OODBMSs support ODL/OQL.
- ORDBMSs consciously try to add OODBMS features to an RDBMS, and OODBMS in their turn have developed query languages based on relational query languages.
- Both OODBMSs and ORDBMSs provide DBMS functionality such as concurrency control and recovery.
- OODBMSs try to add DBMS functionality to a programming language, whereas ORDBMSs try to add richer data types to a relational DBMS.
- OODBMS put more emphasis on the role of the client side This can improve long, process intensive, transactions. ORDBMS SQL is still the language for data definition, manipulation and query.
- OODBMS have been optimized to directly support object-oriented applications and specific OO languages ORDBMS are supported by most of the ‘database vendors’ in the DBMS market place. ORDBMS Most third-party database tools are written for the relational model and will therefore be compatible with SQL3. ORDBMS search, access and manipulate complex data types in the database with standard (SQL3), without breaking the rules of the relational data model.
- When to use an ODBMS?
In applications that generally retrieve relatively few (generally physically large) highly complex objects and work on them for long periods of time.
- When to use an ORDBMS?
In applications that process a large number of short-lived (generally ad-hoc query) transactions on data items that can be complex in structure
- Semantic overloading.
- Poor representation of ‘real world’ entities.
- Poor support for integrity & business constraints.
- Homogeneous data structure and Limited operations.
- Difficulty handling recursive queries.
- Difficulty with ‘Long Transactions’.
- Normalization (Normal Forms and FDs) sometimes lead to relations which do not exist, or correspond, to entities in the real world. This compounds on the ‘join’ feature of query processing.
- The many to many relationship is difficult to express.
- The RDBMS has domains, keys, multi-valued and join dependencies
- Lack of a universal data model.
- Ad-hoc querying compromises encapsulation.
- Locking at object-level impacts performance.
- ComplexityLack of support for views.
- Lack of support for security.
- Increased costs.
- Unclear if the ORDBMS will actually combine relationships and encapsulated objects to correctly and completely mirror the ‘real world.
- Provision of a language(s)which will front end to SQL and will provide a migration path for existing SQL users