Selecting a Database Management System - College of Engineering ...

plumponionchipsΛογισμικό & κατασκευή λογ/κού

18 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

123 εμφανίσεις

Selecting a Database Management System (DBMS)


A
Practical and
Quasi
-
Technical
Analysis

of

Relational Database Management Systems (RDBM
S
) and
Object Database Management Systems (ODBMS)


Christine Weiss

University of Colorado at Colorado Springs


1.

Introduc
tion

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
co
nsumers
who are
uneducated and
un
familiar 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.

R
elational database management sys
tems
(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 explore
s 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; r
elational
database management
systems (RDBMS),
and
object
-
oriented

database management systems
(O
O
DBMS).

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
,

particu
larly
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 art
icle 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 proje
ct team of possessing a
basic to
moderat
ely 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 ava
ilable 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
decision
s or provide valuable input to
decisions on projects regarding

the
selection of a
datab
a
se

management
system

for a particular project
.

The
following questions were proposed and
served as guidance prior to and du
ring
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.

Type
s

of DMBS

Two

different types of DBMS

were selected
for evaluation and analysis
; the relational
database management system and the
object
-
orie
nted database management
system
.
Although other
DBMS

do
exist,
thes
e 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 softwa
re 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 mo
del for
designing

and
outlining

the database
schema;




A
standard
language
for querying of the
datab
ase
which enables user to retrieve,
mod
ify
,

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 d
urability

(ACID).

2.1.

R
elational 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
constr
uct 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 m
odel;
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
c
ommercial RDBMS
to date

has ever been
able to
confor
m

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 e
ach
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 as
sign
ed 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 at
tributes, 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 dat
abases of this type until
the mi
d 1980

s. T
he 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.

T
his 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 obj
ect
-

oriented programming
methodologies
(
i.e.,
encapsulation, inheritance
, abstraction
)

and

basic
databa
se management principles

that
help to ensure ACID

properties are me
t
.


One of the

primary feature
s

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 in
teracting 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 a
n

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

a
nd these objects
are recreated
using the
saved data upon
opening.

The
Object Data Management Group
(ODMG) wa
s a group aimed at developing
standards for OODBM
S

and object
-
relational database management systems
(ORDBMS).
They released three versions
of a do
cument referred to as the ODMG
which recorded and communicated
agreed
upon
standards for OODBMS
. The group
h
as since disbanded. One standard the
ODMG did identify was the

selection of the
Object Query Language
(
OQL
)
as the
standard query language

for OOD
BMS
.
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

The
re does seem to be a consensus among
sc
holars a
nd 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 con
tinue 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 ap
plication would
pr
obably
continue to
benefit from it
s 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 tha
t 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 biolo
gy

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 facto
r 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

m
anagement system
would

occur

hand
-
in
-
hand or virtually
s
imultaneously.

Unfortunately, this is
not
the typical process.
In most cases,

the
programming language
is
decided by the
customer/client and documented in the
system requirement
s

therefore,
leaving
the
database dec
ision
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
a
bsurd
.

For
applications using an OO language for the
implementation of the front
-
end, the
database and communication between it
almost becomes intertwined and
almost
in
distinguishable from the
application

code

eludi
ng a complementa
ry 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 c
onsideration
when
selecting

a

language
for front
-
end
implementation and evaluating languages
that exhibit
similar fundamentals and
prop
erties wo
uld appear to be desir
able
.
This may require evaluation and trial of a

d
eclarative 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 infl
icted upon them
.


The relationship to consider or highlight, if
any, when considering the language for
which the front
-
end will b
e 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 RDB
MS 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
predi
cated 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
item
s 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.

Advant
a
ges

5.1.1.

OODBMS



Promotion of
Reuse

OODBMS
are ripe for reu
s
e


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
object
s

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 th
e
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.
Appl
ication 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 ch
a
ra
cteristics

such as recovery,
versioning, and
persistence
.



R
elationsh
ips are Represented E
xplicitly

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 interfa
ces instead of the
SQL standard


declarative interfaces.

Relationships are typically represented
usi
ng an exp
licit mechanism such as
pointers. Pointers and navigational
interfaces
give an OODBMS an advantage
by
tell
ing

the database ‘how’

instead of
making them search for
a

‘what’.

5.1.2.

RDBMS



Strong
Performance and Expandability

Relational databases exhibit r
apid 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
, t
he
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
R
elational
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 f
amiliar 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 Found
ation

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 bas
is 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



Unintuitiv
e 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 de
sign 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

mod
el 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
data
bases 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.



Reputati
on 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 ma
y no longer be of any
relevance. Many articles and re
search
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 stor
e

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 oper
ate 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 a
ny
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 increa
se 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 que
stion.

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
objec
t
-
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
t
rends in academia tend to support this
observation by the number of projects
currently concluding or
underway

on
converting a
n existing

relational model to an
object
-
oriented data model.
Similarly, there
was extensive re
search on
o
bject
-
relational
database management s
ystem (ORDBMS)

The
main

objective
of

these database
management systems

is

to merge the
benefits of both the relational and object
-
oriented model.

Not surprisingly, many
RDBMS products on the market today ar
e
releasing fi
rst 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 object
-
oriented models, the fatality of relational
databa
ses 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.odbmsfac
ts.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
-
OR
DBMS/

[3]

Cigler, James B. Orooji, Ali. ORR: Object
-
Relational Rapprochement.
COMPSAC '99.
Proceedings. The Twenty
-
Third Annual
International.
October

27
-
29
,

1999
.

Page(s):42
-

48

[4]

Devarakonda, Ramakanth S., Object
-
relational Database Systems


The Road
A
head,
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
System
s: Strengths And Weaknesses.
Journal of Object
-
Oriented Programm
ing
Focus On ODBMS
.

1992.

[7]

Kisworo, M.W.; Rajagopalan, P.
Implementation of an Object
-
Oriented Front
-
End 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 Ob
ject 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.