Introduction
An object-oriented database, also known as a database model is made up of data in form of entities that are commonly used by programmers in the object-oriented form of encoding. The database management system, therefore, presents object-oriented databases as a niche of the other data management fields such as the relational database management system.
Current systems mainly use the client-server applications where the database is on the server. According to InterSystems (2005), this form of setup requires relational database management systems (RDBMS) as the data store and object-oriented program for its language development. This means having an object-oriented database management system that can cater to relationships. The main disadvantage of having this form of setup lies in the need to have various objects linked to the database instead of having consistency between the database and the programming model.
Overview of Object-Oriented Database Management Systems (OODBMS)
OODBMS occurs because programmers use a combination of database management principles such as consistency, durability, atomicity, and isolation. It also caters to various object-oriented programming aspects such as polymorphism, encapsulation, and inheritance (Bloor, 2003).
This form of combination promotes the impromptu formation and management of large databases. OODBMS, therefore, supports objects that are almost impossible to differentiate from the object supported by objective programming language. According to Bloor (2003), “Subsequent objects in a database should have similar atomic types and connection to other objects working as attributes”. The rules must apply to all these subsequent objects even when each of the objects has a unique identifier.
The object identifiers are unique, semi-generated, non-biased, and permanently generated to assist in simplifying the storage references to other objects. Consequently, Bloor emphasizes the need to have a hybrid database since the OODBMS fails to capture all important aspects of an RDBMS such as querying (2003).
Tradeoffs between RDBMS and OODBMS
Errors related to referential integrity of data occur when an object is removed from the database, yet it had a referenced unique identifier. The OODBMS is thus completely object-oriented running on a database management system as used in firms or organizations (Bernstein and Haas, 2008). Various features that are present in Relational Database Management Systems (RDBMS) are also found in OODBMS such as indexing, restoring, backup, deadlock detection, recovery, and ability to work with large related databases.
One of the main differences between the OODBMS and RDBMS is based on the accessibility of information. Accessing objects in OODBMS is transparent with easy use of all objects as though they were all important. It does not require interaction with other objects such as the queries and sub-query languages, or other querying interfaces like ADO or ODBC (InterSystems, 2005).
A requested action from the database cause object to transfer to a cache of the application, where changes made on either of its transient values are independent of what it represents in the main database (Bloor, 2003). Changes are done on the object, therefore, do not affect the database because they occur on the mirrored version in the cache. The object must first be obtained again from the OODBMS.
OODBMS support arbitrary numbers entries made of atomic types, thus support for complex objects with the ability to hold other smaller relational objects. A large class of data can hold sub-classes, which subsequently hold smaller classes up to an infinite end level. Contrary, “RDBMS would need a huge table having data with many null fields or various normalized tables with links via primary and foreign keys” (Bloor, 2003).
The disadvantage of having many smaller tables falls on the need to enhance the joining requirements when querying data. Bloor emphasizes the need to have a database table to support the options for both the OODBMS and RDBMS (2003). However, considering a real-life situation, the object-oriented would present a more favorable working model as opposed to relational tuples that are made of complex objects. The OODBMS is, therefore, more preferable for complex interrelated data than RDBMS.
According to Bernstein and Haas (2008), real-life data is often in a hierarchical format and OODBMS supports the parent and dependant classes. It also circumvents the impendence or needs to map the database objects and tables. It is possible to avoid the impedance mismatch when using the OODBMS as opposed to the RDBMS where one must ensure mapping between the programming language and atomic structure of the database.
Managers of the RDBMS have to be concerned with the relationships between tuples in the database by ensuring the primary key, which is the unique identifier, remains exclusive. The identifier of objects in OODBMS works in a hidden manner and ensures minimal limitations to values stored in any of the database objects (Bloor, 2003).
Lastly, the data model of OODBMS enables the management of both the models and the entities, as if they were made of a single unit. The relationships, operations, and constraints on data entries in the database are universally managed. Contrary, it is not possible to model dynamic applications in RDBMS since they are static and separate entities. The manager requires the entity-relationship diagram (ERD) to model the objects.
Conclusion
The OODBMS application is hard to modify or update compared to the RDBMS since changes made on a class of application require subsequent changes on a related class. According to Bloor all schema changes in any of the OODBMS requires a total system recompilation (2003). It is difficult to update all the involved objects in a database especially when the database is big. RDBMS would therefore be easy to update or edit since all the tables are independent entities.
OODBMS also requires a specific application language and lacks the flexibility involved in querying data from the database tables. Ad-hoc querying of a database is important since databases are for providing access to required data without time or access limitations. This situation raises the need for hybrid databases that incorporates all these important flexibility aspects (Bloor, 2003).
References
Bernstein, P. & Haas, L. (2008). Information Integration in the Enterprise. Communications of the ACM. 51, 9; p. 72-79.
Bloor, R. (2003). The Failure of Relational Database, The Rise of Object Technology, and the Need for the Hybrid Database: A Revolutionary Paradigm. Baroudi Bloor. Web.
InterSystems. (2005). Cache Technology Guide, Chapter 1: Data Modelling: Relational or Object Access. Web.