RDBMS vs. OODBMS: Comparing Database Management Systems

Introduction

The proliferation of database technologies, systems, and data structures continues to be driven by the needs organizations have for making more efficient and economical use of their data. Web-based applications that have increased in speed and security have acted as a catalyst for database growth, and will continue to do so as programming languages become more agile and flexible in design. Continual improvements in Relational Database Management Systems (RDBMS) and Object-Oriented Database Management Systems (OODBMS) are also leading to the development of enterprise systems that can scale across a company's entire value chain. The intent of this paper is to evaluate the purpose, development, and functions of RDBMS and OODBMS, in addition to comparing the advantages and disadvantages of these two dominant types of databases.

Of the two types of databases compared in this analysis, RDBMS is far more prevalently used today, as many Fortune 500 companies have standardized on it for the last three decades. An RDBMS is more agile and efficient in managing transaction-specific requests and forms the foundation of Enterprise Resource Planning (ERP), distributed order management, and Supply Chain Management (SCM) enterprise applications (Evermann & Wand, 2009). RDBMS-based platforms are also purpose-built to manage transaction-centric data and perform more effectively than OODBMS systems on these tasks. As a result, they are the database architecture of choice for the development and continual enhancement of transaction-centric enterprise systems (Connolly & Begg, 2006).

Fundamentals of Relational Database Management Systems

Another aspect of the RDBMS design that enables this architecture to be more effective at enterprise-wide tasks is the table- and array-based approach to storing and managing data. Enterprise system developers have found that using complex or multidimensional arrays for storing data — so they can be used for role-based usage requirements — significantly improves both the usability and performance of ERP systems, for example. This role-based approach to enterprise system use is based on providing database queries from tables and predefined record and data structures that are selectively updated based on department, division, and role-based data structure definitions.

The fundamental structure of an RDBMS is based on record- and row-based data that comprise a record. Each element or item in a record has a unique logical address in the data table, which makes the development of data structures highly efficient. As each row in an RDBMS is considered a record, a key field is used that defines the identity, logical location, and attributes of the table the record is part of. This key identifier field — which has a variety of names depending on the specific type of RDBMS used — is the pivotal element in the RDBMS, as it is used for linking one record, table, or database to another. This key identifier field also enables the linking of tables together and assists in the formation of data structures.

With the foundation of a database designed, the query languages used to traverse tables, create reports, and define entire applications based on their architectures become critical. The majority of RDBMS systems use a structured query language — often referred to as Standard Query Language (SQL). SQL is the language used for defining and running reports, often interlinking data from a variety of RDBMS systems and data structures.

The purpose of the RDBMS structure is to ensure data elements can be precisely defined and accessed regardless of their physical location on a network, while at the same time ensuring data quality and consistency are maintained. These design objectives have been the foundation of RDBMS systems being used for Governance, Risk, and Compliance (GRC)-based workflows and applications, as they are specifically developed to ensure the accuracy and integrity of the data they contain (He & Darmont, 2005). The design objectives of RDBMS systems also align with the concepts of atomicity, consistency, isolation of process areas, and durability. Taken together, these functional areas form the foundation of ACID compliance in database architecture (Antoniotti, Carreras, Antonella, Mauri, Merico, & Zoppis, 2010).

Purpose, Development, and Functions of RDBMS

RDBMS architectures fulfill the design requirements of ACID compliance and are therefore more often relied upon for complex system development and use. ACID-compliant systems are often used for enterprise-wide applications that must run several concurrent processes simultaneously, with distributed order management and supply chain management being the most prevalent examples.

The atomicity of an RDBMS refers to its innate design attributes that limit the effects of hardware failure on overall system performance (Antoniotti et al., 2010). As a design objective, atomicity has also evolved over time to include protection against operating system failure, database query and platform failure, and application failure in software installed on top of the RDBMS. Consistency is defined as the ability of a database architecture to progress from one process to another reliably, including the ability to overcome soft errors in processing. The use of data structures that enable this attribute in an RDBMS is considered a designed-in criterion for Web Services, given the continued growth of Internet-based applications. Consistency continues to be pursued as a design objective for RDBMS-based applications, as many require an application state engine — the ability to track the progress of specific tasks and oversee execution of all processes.

Consistency and isolation are often designed in conjunction with each other to ensure that an RDBMS has a state engine capable of overseeing the many processes that must be completed in synchronization. Isolation refers to the ability of a database to separate out a given process and subsystem to ensure that its failure does not bring down the entire RDBMS. Isolation is a critical design objective for RDBMS-based systems used in government and highly secure application areas, as in many cases rebooting a database system must be audited and evaluated for any security breaches.

The last attribute of ACID compliance is durability (Lee, Lee, & Kim, 2005). This attribute refers to the ability of an RDBMS to manage continual transactions across systems, systems of record, and third-party platforms, and to continue working even when those systems fail. The ACID compliance attributes of RDBMS systems are often relied upon for financial accounting and analysis systems, as these design attributes lead to system auditability, stability, and security.

The combination of a relational data structure's fundamental strengths — including support for logical data definition across networks — together with ACID compliance has positioned RDBMS-based systems as dominant in specific enterprise and government applications. An RDBMS relies on SQL-based queries to generate reports and develop online dashboards and scorecards. The foundational value of an RDBMS architecture is its agility and accuracy in managing transaction data while remaining highly reliable and secure through the use of the ACID compliance framework (Antoniotti et al., 2010).

Conclusion

Each of these technologies has a unique set of benefits that must be aligned to specific needs in organizations and enterprises over time to be effective. For the majority of business uses, the RDBMS architecture and its ability to manage thousands or millions of transactions a day make it ideally suited for business and commercial applications. The OODBMS architecture, on the other hand, is more suited to those application areas where graphical data and workflows matter most, which include the areas of scientific and engineering research.