Download Selecting a Database Management System (DBMS)

Selecting a Database Management System (DBMS) – A Practical and QuasiTechnical 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 endproduct 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 quasitechnical role.
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:
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:
●
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).
●
What are some of the different types of
DBMS available on the market?
2.1. Relational Database Management
●
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?
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.
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.
System (RDBMS)
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 objectoriented 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 objectrelational 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) typeapplications. 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 highenergy 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 frontend 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.
●
Relationships are Represented Explicitly
A key feature of the OODBMS is the use of
pointers which enables the system to
access an object directly without requiring a
search. Through research, this has proven
to make the OODBMS preferred over a
RDBMS for performing many tasks. This
would apply to tasks that can be performed
using navigational interfaces instead of the
SQL standard – declarative interfaces.
Relationships are typically represented
using an explicit mechanism such as
pointers. Pointers and navigational
interfaces give an OODBMS an advantage
by telling the database ‘how’ instead of
making them search for a ‘what’.
5.1.2. RDBMS
● Strong Performance and Expandability
Relational databases exhibit rapid access to
stored data, large storage capacity, and are
considered flexible or expandable. It is not
necessary to understand every detail of how
a current RDBMS is designed to be able to
expand the database to include additional
relations. Conversely, the RDBMS relations
do not typically demonstrate direct
relationships or dependencies on other
relations and therefore, removing a table
can have substantially lower risk than
removing an object definition in an
OODBMS.
●
Wide-spread Comprehension of the
Relational Data Model
Relational databases are easy to
understand and can be interpreted in many
different ways. Tables and the
representation of data into tabular forms is a
concept familiar to most individuals whether
they are technical or non-technical. With
little knowledge of the domain or relational
databases, an individual will typically be
able to use their previous exposure of tables
and quickly decipher the data contained
within a relational database.
●
Mature System with Strong
Mathematical Foundation
RDBMS have been a business staple in
supporting applications for over 20 years.
The sheer number of RDBMS currently in
use has tested and proven successfully in
achieving a multitude of business needs.
Many researchers also state that the
RDBMS basis in set theory and the
mathematical concept of the relation also
attribute to the RDBMS success and
dominance. For many, the mathematical
aspect is an attraction for RDBMS because
it provides an accepted logic and rigor.
5.2. Disadvantages
5.2.1. OODBMS
● Unintuitive Data Model
The object-oriented model is not initially
intuitive to the average individual. Although
some researchers would contradict this
statement, this model is lost without
previous exposure or explanation on the
basics of the model. To properly design an
effective OODBMS, the database designer
must have a solid understanding of the
object-oriented model and how to efficiently
implement it.
In addition, some data domains have
explicit objects and clearly defined
relationships among objects. Most business
applications do not contain obvious or
intuitive objects which makes application of
the model more difficult.
●
Existing Dominance of the RDBMS
The RDBMS continues to have a stronghold
with business systems. This is a major
disadvantage for OODBMS because as new
databases are added or legacy systems are
modified, it is easier to insert another
relational database into the environment
than to add an OODBMS. The addition of
an OODBMS in this environment may
require modifications in the existing
databases in order to enable
communication and data access among the
existing databases and the new OODBMS.
Unfortunately, this will be a major obstacle
for any OODBMS and may end up being a
primary decision point for a company when
selecting a DBMS.
●
Reputation for Poor Performance
OODBMS performance has historically
been a major downfall and limitation on its
use. As with any product, previous
reputation can work against a product even
though the issue may no longer be of any
relevance. Many articles and research
projects of the late 1980’s thru the late
1990’s repeatedly identified this as being a
major limitation to the wide-spread
popularity and use of the OODBMS. It does
appear that in the current market, OODBMS
can perform at comparable speeds to
RDBMS assuming the data domain is an
ideal domain for an object-oriented data
model.
5.2.2. RDBMS
● Lack of support for data-intensive,
complex applications.
Relational databases lack the ability to
handle complex interrelationships of data.
The RDBMS is unable to store complex
data such as images, digital, and
audio/video data types. With the
commonality of these types of data rapidly
increasing, this presents a major limitation
on the use of RBMS.
●
Language Restrictions
A relational database cannot communicate
or operate with any language other than
SQL. Some researchers identified this as a
benefit claiming advantages such as easier
access to data in multiple databases and
straightforward migration of two or more
databases using a single sub-language.
Although these are valid points, this actually
requires the use of at least two
programming languages to implement any
application using an RDBMS – one for
implementing the application and one for
querying of the database. This would
require extensive knowledge by the
development team in order to ensure proper
implementation and increases the volume of
code that requires maintenance. It will
ultimately increase project scope and
complexity.
●
Assignment of Unique Identifiers
The assignment of object identifiers (OID) is
virtually a transparent process to the user in
an OODBMS. This is not a built process of
RDBMS and requires code and
maintenance to ensure tuples are uniquely
identified. If this function is performed
incorrectly, the integrity of the data comes
into question.
6. Conclusions
Relational databases have a strong-hold on
the current database market due to their
maturity, reliability, the majority of existing
applications using the relational model, and
some unknown factors associated with the
immaturity of object-oriented databases. As
object-oriented programming languages
continue to emerge as the favored or
dominate programming language for
building new applications, the OODMBS will
surpass the RDBMS as the most popular
and dominate database management
systems in the business market. Research
trends in academia tend to support this
observation by the number of projects
currently concluding or underway on
converting an existing relational model to an
object-oriented data model. Similarly, there
was extensive research on object-relational
database management system (ORDBMS)
The main objective of these database
management systems is to merge the
benefits of both the relational and objectoriented model. Not surprisingly, many
RDBMS products on the market today are
releasing first generation ORDBMS
products. If these products are able to fulfill
the main objective of ORDBMS as well as
enable companies to convert existing
relational models to partial or full objectoriented models, the fatality of relational
databases is almost eminent. This will
enable current products to cash-in on this
migration and preserve some semblance of
their market base.
References
[1] Barry & Associates. OODBMS Facts. April
2001. http://www.odbmsfacts.com.
[2] Chaterjee, Jagadish. Introduction to
RDBMS, OODBMS and ORDBMS. January
3, 2005.
http://www.aspfree.com/c/a/Database/Introd
uction-to-RDBMS-OODBMS-and-ORDBMS/
[3] Cigler, James B. Orooji, Ali. ORR: ObjectRelational Rapprochement. COMPSAC '99.
Proceedings. The Twenty-Third Annual
International. October 27-29, 1999.
Page(s):42 - 48
[4] Devarakonda, Ramakanth S., Objectrelational Database Systems — The Road
Ahead, Crossroads, March 2001. Volume 7
Issue 3.
[5] Fong, Joseph. Converting Relational to
Object-Oriented Database. d. March 1997.
Volume 26 Issue 1.
[6] Kim, Won. Object-Oriented Database
Systems: Strengths And Weaknesses.
Journal of Object-Oriented Programming
Focus On ODBMS. 1992.
[7] Kisworo, M.W.; Rajagopalan, P.
Implementation of an Object-Oriented FrontEnd to a Relational Database System. IEEE
Region 10 Conference on Computer and
Communication Systems. 24-27 Sept. 1990
Page(s):811 – 815.
[8] McClure, Steve. Object Database vs.
Object-Relational Databases. IDC Bulletin
#14821E - August 1997.
[9] McFarland, Gregory, Rudmik, Andres, and
Lange, David - Modus Operandi, Inc. Jan
31, 1999. Object-Oriented Database
Management Systems Revisited: An
Updated DACS State-of-the-Art Report.
https://www.dacs.dtic.mil/techs/oodbms2/oo
dbms-toc.shtml.
[10] Obasanjo, Dare 2001. An Exploration of
Object-Oriented Database Management
Systems.
http://www.25hoursaday.com/WhyArentYou
UsingAnOODBMS.html.
[11] Rahayu, W.; Chang, E.; Dillon, T.S.
Implementation of Object-Oriented
Association Relationships in Relational
Databases. Database Engineering and
Applications Symposium, July 1998.
Page(s):254 – 263.
[12] Smith, Karen E., Zdonik, Stanley B.,
INtermedia: A Case Study of the Differences
Between Relational and Object-Oriented
Database Systems. OOPSLA ’87
Proceedings. October 4-8, 1987.
[13] Sujithan, K. R. An Object Model of Data,
Based on the ODMG Industry Standard for
Database Applications. The Institution of
Electrical Engineers. 1995.
[14] Zand, Mansour, Collins, Va, Caviness, Dale.
A Survey of Current Object-Oriented
Databases. Data Base Advances, February
1995. Volume 26, No. 1.