MIGRATION FROM RELATIONAL TO OBJECT-ORIENTED DATABASES By Masood Asif, Kenny Dunlop, Gerard Given & Grant Stalker

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

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

72 εμφανίσεις

MIGRATION FROM RELATIONAL TO
OBJECT
-
ORIENTED DATABASES

By

Masood Asif, Kenny Dunlop, Gerard
Given & Grant Stalker



Abstract


At the moment many companies and organisations are deciding whether to
upgrade their existing relational databases to new object
-
o
riented databases.

Within this seminar we aim to discuss the existing relational database
technologies and object
-
oriented databases.
I will also discuss the reasons
why these organisations should or should not migrate their databases.
I will
then identify

various routes, which a company may take if they go down the
migration path. I will then conclude all my findings and observations of
migrating databases.


Introduction


Relational Databases


A relational
database

is a collection of
data

items organized
as a set of
formally
-
described tables from which data can be accessed or reassembled in
many different ways without having to reorganize the database tables. The
standard user and application program interface to a relational database is the
structured qu
ery language

(
SQL
). SQL statements are used both for
interactive queries for information from a relational database and for gathering
data for reports.

In addition to being relatively easy to create and access, a relational database
has the important adva
ntage of being easy to extend. After the original
database creation, a new data category can be added without requiring that
all existing applications be modified.

However, relational databases have the following deficiencies, which we will
discuss.

Pros

and Cons for Relational Databases

Cons (Relational)



Very little flexibility for data structuring



Current query language is not computationally complete



Little or no support for temporal data



They cannot sufficiently express data that does map well to tabl
es



The new query language (SQL3) is far too complex


Pos (Relational)



Very simple to understand and implement



Well documented



Many proven vendor solutions available



Easy to modify existing databases

Object Oriented Databases



Object Oriented Databases are

widely used in different organizations.


For Example:



trade stock using an Internet trading service,


Use your pager,


Use your voicemail,


book a flight,


Use your PCS phone

According to Malcolm Atkinson and others; ‘
The Object
-
Oriented Database
Manifesto’
, defines an OODBMS as
follows
:

An object
-
oriented database system must satisfy two criteria:



it should be a DBMS



it should be an object
-
oriented system, i.e., to the extent possible, it
should be consistent with the current crop of object
-
oriented
programming languages.


The

first criterion translates into five features:



persistence



secondary storage management



concurrency



recovery



ad hoc query facility



The second one translates into eight features:



complex objects



object identity



encapsulation



types or classes, inheri
tance



overriding combined with late binding



extensibility



computational completeness



Pros (Object
Oriented)



Model real
-
world environment effectively



Objects encapsulates both state and behavior allowing for code reuse



Organization of data can be done
by the needs of the application



OO Programming languages provide faster development e.g.
Applications.


Cons (Object Oriented)



Many vendors in the market but which ones will survive to provide
support



Migrating


Migrating involves moving data from a rel
ational database to an object
-
oriented database. This could be a mammoth task for companies but in the
long run it can prove beneficial. For example

a travel agent using an

object oriented databases for booking flights

woul
d be able to increase the
speed of

querying.



Cons

for Migrating




Cost of migration


expensive



Potential for loss of data



Risk of project failure


loss of project budget



Companies may have recently completed a relational database
migration project and
so be unwilling yet another project.


Pros

for Migrating




Reduce maintenance cost of current relational DB.



Increase business and profits due to increase functionality





Architectures

of the Legacy Databases


In migrating terms, relational database are
relatively easy Information
Systems to migrate. Relational databases can be categorised as a
Decomposable Legacy Information Systems

(shown below). Theses
systems are usually relatively modern and conform to the modern standards
e.g. (
E. F.
Codd

rules (197
0.)) Older Information Systems, for example
that
are

hand

coded and
are pre
-
relational are
known as
Non
-
Decomposable
.
These

can be more complex to migrate due to the enclosed “Black Box”
design. With the Decomposable Legacy I.S., all the
components

are mo
dular
and
accessible

to software
engineers
.

(Shown below)




Decomposable I.S. include
Oracle
's database product line, Computer
Associa
tes' CA
-
OpenIngres, and IBM's
DB2


The routes


There are several recognised strategies that can be implemented to migrate
from a Relational (Decomposable Legacy), t
o the new target Information
System in this case an Object Orientated Solution. I will, now discuss these
strategies individually, highlighting the benefits and pitfalls of each route. The
Relational Database will now be referred to as the Legacy Informati
on
System, (Legacy IS) and the Object Relational Database will be referred to as
the Target Information System, (Target IS.)


Cold Turkey

Legacy Relational Database

Decomposable Legacy I.S.



Data

Legacy Non Relational Database

Non
-
Decomposab
le Legacy I.S.

Data

Application


Modules

Application


Modules

GUI I

Interface

Interface

GUI


This strategy is when the Target I.S. is written from scratch and is brought live
when the Legacy I.S. shut down.


T
his strategy has the following issues


Lack Documentation

Although usually exceeded, the typical useful lifespan of an I.S. is ten years.
With these sorts of time spans it is unusual to find intact documentation for the
Legacy IS. The original developers

have probably moved on as well, leaving
the code itself as the only specifications. This makes the process more
difficult.


Application Dependencies

Within the lifecycle of I.S. typically new applications, for example performance
and monitoring tools have

been implemented but not documented. These
applications may now be Mission Critical to the company but may be
overlooked with Cold Turkey.



Project Management

This route has the largest management overhead of all. If this project is
attempted in
-
ho
use, previous case studies have shown uncontrollable growth
as project continues on demands of staff and resources. Few companies
realistically have the resources to manage such a migration project of a
medium to large IS. However, an in
-
house development,

managed correctly
can provide substantial savings


Time does not stand still

The development period for a new I.S. can be as long as 3 years. Within that
time the Legacy system may have evolved significantly. These new changes
may not be able to be incl
uded in the Target I.S. current development cycle.

If there are a significant amount of these changes within the Legacy I.S., it
could result in total failure of the project when it is brought online.


New Functionality

For management of a company to agree

to a very expensive Target I.S. they
will typically need to be promised more that a long term reduction of
maintenance costs. They will demand increased functionally to increase
business. This functionality will increase the complexity of the project and
goes against the K.I.S.S. rules (Keep it Simple Stupid!)


Live data

Data Dumping of the Legacy I.S. can in some cases take several days/
weeks. When this data is migrated to the live Target I.S. there will be
concurrency problems. Planning the actual migra
tion of Mission Critical Data
is a major issue with the Cold Turkey Strategy and may in some case prevent
its success.


Company Reorganisation

With the implementation of a large Target I.S. comes the temptation from
management to reorganise a company’s str
ucture, which they may have been
unable to do previously because of the Legacy I. S. This will increase the
complexity to the project and
so
will increase the chances of failure.




Savings

As discussed above, the Cold Turkey can be classed as a hig
h risk strategy.
However if successful, the saving can be significant both in in
-
house
development costs and the profits attached increased productivity and
business.



Chicken Little


This Strategy is relatively low risk, but can be considered to have a “
Forth Rail
Bridge Painting Job” (never ending) project lifecycle. The Legacy I.S. is
gradually upgraded by the developers until the desired Target I.S. is achieved.

The main issues attached to this cycle are discussed below


Step by Step

As discussed, a R
elational DB can be considered as a Decomposable Legacy
System. This means that the applications, system and user interfaces are
typically independent from each other (shown above.) This allows the
developers to be modular with the approach by say, upgradi
ng/ replacing only
one application/ module at once.



Gateways

The use of Gateways is fundamental with the Chicken Little approach. A text
book description is this


“A software module introduced between operational software
compo
nents to mediate between
them”

Michael L. Brodie

(Darwin: On the
Incremental Migration of Legacy Information Systems


Gateways allow developers to introduce the new components of the new
Target IS while other Legacy I.S. components remain. For example a user
interface can be kept
live while the actual DB has been changed behind the
scenes. (Shown below)

















Many Gateways would be used in a typical migration



Dead & Alive Parallel Approach


This strategy, like Cold Turkey usually involves a
total rewrite and so suffers
from some same problems of budget, project management & concurrency,
already discussed. However, the difference is that the Target and Legacy
I.S.’s are ran together in parallel. This allows the developers to iron our any
probl
ems before the users move over.


Longer time Scales.

This type of project is more difficult to manage and can fail because the
re

can

sometimes

be no end in sight. Just as one problem is sorted, more can
appear. However a parallel project lifecycle is infi
nitely quicker that the
Chicken Little approach.


Requires more Resources


Running two I.S. will require more hardware, software & manpower. It could
also be impossible to run a parallel project if the issue
s

such as network
bandwidth have not been address
ed first.


Target I.S.

(OODB)

Gateway

Data

Legacy GUI

(Live)

Target New GUI

(Not live yet)




Gradual User Migration


Like the Chicken Little approach users can be gradually migrated to the
Target I.S. allowing a more controlled project.


Recovery /step back


A major problem when upgrading a database is what to do if in the event of a

mistake or error. I will new discuss the recovery/ step back qualities these
different strategies provide
.


Cold Turkey

This system is all or nothing. Once a Target I.S. has been switched over to,
there can sometimes be no way to go back the Legacy I.S.
if problems occur.
This makes Cold Turkey one of the most risky of all strategies


Chicken Little

Because of the modular implementation of this approach, errors can be
corrected by a simple step back. This means that if that particular module has
to be dis
carded altogether, only a relatively small part of the project time/
resources has been wasted. However the developers can sometimes not
anticipate all the eventualities. For example a combination of module B & C
may stop module A or even the whole Legacy

I.S. from working.



Dead & Alive Parallel Approach

As this approach should not affect the Legacy I.S. at all, it has a good fall
back position if the Target I.S. fails. It could mean that several years of
developing the Target I.S. are lost, but the com
pany can survive and continue
to trade, using the Legacy I.S. However a correctly managed user migration
could allow for live user testing, (users perhaps updating & queuing both
systems) which should decrease the chances of failure.


Conclusion

There i
s no one answer to whether or not a company should migrate.
In
-
depth

studies should be under
taken

to weight up the important issues and establish
if a migration project will be beneficial for a
particular

company or
organization.


Our investigations als
o show that if a company does choose to migrate from a
relational to an Object Orientated DB
, there

as not one

of the shelve


solution to aid them. Again
,

complex
analysis

will have to be
completed to
assess which migration route should be invested in.
Perhaps it may not be
one of the routes
discussed

but a combination of all.
However
, one fact our
research has shown…..

would
-
be mirageties should be
ware

due to the
potential
business

crippling risks involved.





References


OODB better than RDB

http://www.devx.com/dbzone/articles/sf0601/sf0601
-
1.asp


Performance perks of OODB

http://www.devx.com/dbzone/articles/s
f0801/sf0801
-
1.asp


Front end approach

http://www.javaworld.com/javaworld/jw
-
01
-
2000/jw
-
01
-
step.html


Migrating to OODB

http://www.cis.paisley.ac.uk/conn
-
ci0/papers.html


Future of databases

http://www.intelligententerprise.com/020509/508feat1_1.shtml


OODB Articles
-
Gen

http://www.odbmsfacts.com/articles/object
-
oriented_databases.html



Michael L. Brodie

(Darwin: On the Incremental Migration of Legacy
Information Systems)


Malcolm Atkinson and others; ‘
Th
e Object
-
Oriented Database Manifesto’
,
: