Selecting a Database Management System (DBMS) – A Practical and Quasi-Technical Analysis of Relational Database Management Systems (RDBMS) and Object Database Management Systems (ODBMS)
Christine Weiss
University of Colorado at Colorado Springs
1. Introduction
The stronghold or dominance of one product in a particular line of business can lead to the selection of a product not based on appropriateness and fit for the need but rather reputation and word of mouth. This would seem to be an easy pitfall for consumers who are uneducated and unfamiliar with the product’s domain however it is also prevalent in areas where the consumer does have limited to moderate experience and knowledge with the domain in question.
Relational database management systems (RDBMS) currently dominate the database market for use in commercial, business applications and with this trend there arises an assumption that the relational model and RDBMS is best suited for most, if not all, business-driven applications. This document explores the validity to this dominance and makes a case for the need to select a database management system (DBMS) for an application based on the application’s purpose, desired use and functionality, and application environment independent of product reputation or commonplace in the market. This article discusses two database management systems currently available on the market for use; relational database management systems (RDBMS), and object-oriented database management systems (OODBMS). This document is not intended to present or identify one DBMS as superior or ideal conversely the goal is encourage the selection of a DBMS based on analysis and evaluation of the database’s purpose and desired competencies.
1.1. Background
There is a tendency in business, particularly in the technology field, to depend upon the knowledge and expertise of those individuals with strong technical backgrounds when a project is forced to make ‘technical decisions’. Although this does tend to work out favorably for the end-product and the project team, there remains a need or, rather, a desire for individuals in decision making positions and/or in positions of influence with a limited to moderate technical background to weigh-in and provide useful input to technical decisions. This article is aimed at the latter of the two groups and presents ideas that have technical basis mixed with real-world application and understandability.
The author of this article typically falls into that role on a project team of possessing a basic to moderately strong technical background and understanding. When faced with making a technical decision alone on what type of database management system to use for a master’s project, there emerged a desire to research the different database management systems available and represent the findings for others falling into this quasi-technical role.
Therefore, the purpose of this research paper is to provide sound reasoning and explanatory information for a reader without extensive technical knowledge to make decisions or provide valuable input to decisions on projects regarding the selection of a database management system for a particular project. The following questions were proposed and served as guidance prior to and during research. The article should answer:
● What are some of the different types of DBMS available on the market?
● What effects or influence does the domain of the project or the purpose of the application have on selecting a DMBS?
● What is the relationship between the front-end implementation and the DBMS? How does this relationship affect the selection process?
● What are the advantages and disadvantages of each DBMS?
2. Types of DMBS
Two different types of DBMS were selected for evaluation and analysis; the relational database management system and the object-oriented database management system. Although other DBMS do exist, these systems were selected based on the large number of commercial products available in the market for each system and their contrasting data models.
A DBMS is a database software program used to catalog, store, maintain, and retrieve data in a database. The key characteristics of a database management system are:
● Use of a data model for designing and outlining the database schema;
● A standard language for querying of the database which enables user to retrieve, modify, and specify storage of data;
● Data structures; and
● A method for performing transactions aimed at ensuring the four key features of database transactions; atomicity, consistency, isolation, and durability (ACID).
2.1. Relational Database Management System (RDBMS)
A relational database management system uses the relational model as its basis. The relational database model was created by Edgar F. Codd at IBM during the early 1970’s and is based on the set theory to construct data in terms of rows and columns. Codd defined 12 rules by which a truly relational database is defined: foundation rule; information rule; guaranteed access rule; systematic treatment of null values; dynamic on-line catalog based on the relational model; comprehensive data sublanguage rule, view updating rule; high-level insert, update, and delete; physical data independence; logical data independence; integrity independence; distribution independence; and the nonsubversion rule. Interestingly, no commercial RDBMS to date has ever been able to conform to all 12 of Codd’s rules. Because of this, the 12 rules have evolved into guiding principles or goals of database design.
The RDBMS structures data into relations (tables) which form a two-dimensional representation of the data into rows and columns. A relation contains tuples (rows) and each tuple represents a distinct record in the table. A tuple consists of a set of unorganized attributes (columns) providing detail for the record. Rows are assigned a unique identifier, also known as a primary key, by which the record can be accessed, manipulated, and referenced by other tables or applications. Columns store the attributes of a record, more commonly known as fields, and each attribute is assigned a data type.
During the mid 1980’s, Structured Query Language (SQL) was identified and accepted as the standard query language and transaction mechanism for RDBMS. SQL queries can be used to access and return data from tables, define records and their attributes, and to view data from multiple tables through operations such as a join.
Two of the most popular examples of RDBMS currently on the market are Oracle and Microsoft Access.
2.2. Object-Oriented Database Management System (OODBMS)
As implied by the title, object-oriented database management systems use the object-oriented model (OOM) similarly to how object-oriented programming languages (OOPL) adhere to the OOM. Coincidentally, research of OODBMS also dates back to 1970’s (late 1970’s/early 1980’s) however the term ‘object-oriented’ wasn’t coined for databases of this type until the mid 1980’s. The first commercial product did not appear on the market until the late 1980’s. More recently, there has been a resurgence in OODBMS as open source object databases emerged that were more affordable and user-friendly due to the use of OO-languages such as Java and C#. The relationship of an OODMS and an OOPL establishes a strong correlation between the application data model and the database data model. This relationship or marriage of the OODBMS and OOPL serves as a focal point for analysis and evaluation of OODBMS.
An OODBMS is the combination of object- oriented programming methodologies (i.e., encapsulation, inheritance, abstraction) and basic database management principles that help to ensure ACID properties are met. One of the primary features of an OODBMS is that “accessing objects in the database is done in a transparent manner such that interaction with persistent objects is no different from interacting with in-memory objects.” (Obasanjo, 1). In addition, the OODBMS employs the same mechanisms for retrieving and modifying stored object data as the OOPL would utilize to perform the same actions on an object in the applications cache. An example of how an OODBMS operates is to consider the process of saving data from an application developed using an OOPL to a flat file. The system saves specific instances of an object or multiple objects to a file using the object identifier (OID) as it’s key and these objects are recreated using the saved data upon opening.
The Object Data Management Group (ODMG) was a group aimed at developing standards for OODBMS and object-relational database management systems (ORDBMS). They released three versions of a document referred to as the ODMG which recorded and communicated agreed upon standards for OODBMS. The group has since disbanded. One standard the ODMG did identify was the selection of the Object Query Language (OQL) as the standard query language for OODBMS. OQL uses syntax similar to SQL and is rarely used since the basic functionality of queries in intrinsic to object-oriented programming languages.
3. The Effects and Influence of the Application’s Domain
There does seem to be a consensus among scholars and researchers that the purpose or business use of an application should be considered when selecting a DBMS. This is particularly apparent when the domain is well understood and defined upfront when the selection processes occurs.
Relational database continue to dominate and out perform an object-oriented database for applications meeting traditional business objectives. The performance of these databases is still considered the ideal and therefore, any transaction dependent business application would probably continue to benefit from its use.
Object-oriented databases are becoming increasingly popular in Computer Aided Design (CAD), Computer Aided Manufacturing (CAM), and Computer Aided Software Engineering (CASE) type-applications. A characteristic that is apparent in these and other similar applications using object-oriented databases is their use of real-world objects that are easily converted to database objects using the object-oriented data model. These systems where objects can be rolled up into a hierarchical structure or decomposed into smaller pieces seem to be ripe candidates for object-oriented databases. Additional examples include software for assembling airplanes or cars, warehouse management, and fields of science such as molecular biology and high-energy physics.
In some instances, such as those stated above, the domain of the application has a clear and obvious influence on the type of database selection. In other applications, the impact seems minimal if any exists at all. This factor will serve on a case-by-case basis.
4. Relationship of the DMBS and the Application’s Front-end Implementation
On an ideal project, the decision on which programming language to develop an application’s front-end and the selection of a particular database management system would occur hand-in-hand or virtually simultaneously. Unfortunately, this is not the typical process. In most cases, the programming language is decided by the customer/client and documented in the system requirements therefore, leaving the database decision to occur as an afterthought during design activities.
With the use of the object-oriented data model as the basis of OODBMS and OOPL, consideration of a DBMS other than a OODBMS for an application developed in an OOPL seems almost absurd. For applications using an OO language for the implementation of the front-end, the database and communication between it almost becomes intertwined and almost indistinguishable from the application code eluding a complementary relationship between the two or marriage.
Relational database management systems do not have a similar relationship with any one programming language used for front-end implementation. The one element that does stand-out and would probably find benefit from consideration is the RDBMS dependency on SQL for communication between an application and the database. Thus, taking SQL into consideration when selecting a language for front-end implementation and evaluating languages that exhibit similar fundamentals and properties would appear to be desirable. This may require evaluation and trial of a declarative programming language. Additionally, procedural languages seem to blend with the principles of the relational database and SQL. In procedural programming, the objective is to segment the solution into collection of data structures and routines. This seems reminiscent to the relational model which also aims to breakdown the solution into sets of similar data that have a common set of activities or functions that can be inflicted upon them.
The relationship to consider or highlight, if any, when considering the language for which the front-end will be implemented and a DMBS is to identify languages that have a basis in complimentary data models. This is one of the primary reasons that an OOPL and an OODBMS correlate and are often identified together.
5. Advantages and Disadvantages
As with most dueling technologies, most current research tends to imply a relationship of ‘one’s disadvantage is the other’s advantage’ among RDBMS and OODBMS. In terms of selecting a database management system, the advantages and disadvantages of each DBMS should be measured against the goals and objectives of the application. Selecting a database should not occur in a void as selection is predicated on the software’s purpose and environment in comparison to the advantages and disadvantages of any DBMS.
It is important to note that extensive research in academia has been performed on the advantage and disadvantages of OODBMS and RDBMS. This items listed in the subsequent sections are not an exhaustive list. This list is aimed and specific to meeting the objectives outlined of this article and should only provide a basis for comparison.
5.1. Advantages
5.1.1. OODBMS
● Promotion of Reuse
OODBMS are ripe for reuse – a common goal for most software applications. Inheritance and polymorphism are two key features of the object-oriented model that provide the user with the ability to reuse objects. Those familiar with OOPL, which demonstrate the same capabilities, recognize the advantage of this feature that allows them to reuse existing data structures and operations as a foundation for adding new objects exhibiting similar features. This element is not only useful for expanding the current number of stored objects in a single database but is also applicable from one OODBMS to another.
● Management of Application Code by Database Facilities
The use of an object-oriented database can greatly decrease the volume of code used by the application. As characteristic of the object-oriented model, an object holds an entity consisting of attributes, behaviors, states, and relationships. Therefore, this data does not need to be defined in the application code as this data would be stored with the object in the database. Application code is also reduced by not requiring a querying language to access and store data. The advantage of storing the majority of the application data in a database is that it can then be managed by database facilitates that ensure data integrity characteristics such as recovery, versioning, and persistence.