MIGRATION FROM RELATIONAL TO
Masood Asif, Kenny Dunlop, Gerard
Given & Grant Stalker
At the moment many companies and organisations are deciding whether to
upgrade their existing relational databases to new object
Within this seminar we aim to discuss the existing relational database
technologies and object
I will also discuss the reasons
why these organisations should or should not migrate their databases.
various routes, which a company may take if they go down the
migration path. I will then conclude all my findings and observations of
is a collection of
as a set of
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
). 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
and Cons for Relational Databases
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
The new query language (SQL3) is far too complex
Very simple to understand and implement
Many proven vendor solutions available
Easy to modify existing databases
Object Oriented Databases
Object Oriented Databases are
widely used in different organizations.
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; ‘
, defines an OODBMS as
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
first criterion translates into five features:
secondary storage management
ad hoc query facility
The second one translates into eight features:
types or classes, inheri
overriding combined with late binding
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.
Cons (Object Oriented)
Many vendors in the market but which ones will survive to provide
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
d be able to increase the
Cost of migration
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.
Reduce maintenance cost of current relational DB.
Increase business and profits due to increase functionality
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
0.)) Older Information Systems, for example
can be more complex to migrate due to the enclosed “Black Box”
design. With the Decomposable Legacy I.S., all the
Decomposable I.S. include
's database product line, Computer
OpenIngres, and IBM's
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
System, (Legacy IS) and the Object Relational Database will be referred to as
the Target Information System, (Target IS.)
Legacy Relational Database
Decomposable Legacy I.S.
Legacy Non Relational Database
le Legacy I.S.
This strategy is when the Target I.S. is written from scratch and is brought live
when the Legacy I.S. shut down.
his strategy has the following issues
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
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.
This route has the largest management overhead of all. If this project is
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
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.
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!)
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
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
will increase the chances of failure.
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
development costs and the profits attached increased productivity and
This Strategy is relatively low risk, but can be considered to have a “
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.
The use of Gateways is fundamental with the Chicken Little approach. A text
book description is this
“A software module introduced between operational software
nents to mediate between
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
ems before the users move over.
Longer time Scales.
This type of project is more difficult to manage and can fail because the
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
such as network
bandwidth have not been address
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
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
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.
s no one answer to whether or not a company should migrate.
studies should be under
to weight up the important issues and establish
if a migration project will be beneficial for a
Our investigations als
o show that if a company does choose to migrate from a
relational to an Object Orientated DB
as not one
of the shelve
solution to aid them. Again
will have to be
assess which migration route should be invested in.
Perhaps it may not be
one of the routes
but a combination of all.
, one fact our
research has shown…..
be mirageties should be
due to the
crippling risks involved.
OODB better than RDB
Performance perks of OODB
Front end approach
Migrating to OODB
Future of databases
Michael L. Brodie
(Darwin: On the Incremental Migration of Legacy
Malcolm Atkinson and others; ‘
Oriented Database Manifesto’