Download Relational Databases

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-oriented 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 query 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 advantage 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 tables
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, inheritance
 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 relational database to an objectoriented 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 would 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 (1970.)) 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 modular
and accessible to software engineers. (Shown below)
GUI I
I
GUI
I
Interface
Application
Modules
Interface
Application
Modules
Legacy Relational Database
Decomposable Legacy I.S.
Data
Legacy Non Relational Database
Non-Decomposable Legacy I.S.
Data
Decomposable I.S. include Oracle's database product line, Computer
Associates' CA-OpenIngres, and IBM's DB2
The routes
There are several recognised strategies that can be implemented to migrate
from a Relational (Decomposable Legacy), to 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 Information
System, (Legacy IS) and the Object Relational Database will be referred to as
the Target Information System, (Target IS.)
Cold Turkey
This strategy is when the Target I.S. is written from scratch and is brought live
when the Legacy I.S. shut down.
This 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-house, 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 included 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 migration 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 structure, 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 high 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 Relational 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, upgrading/ 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
components 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)
Legacy GUI
(Live)
Target New GUI
(Not live yet)
Gateway
Target I.S.
(OODB)
Data
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
problems before the users move over.
Longer time Scales.
This type of project is more difficult to manage and can fail because there can
sometimes be no end in sight. Just as one problem is sorted, more can
appear. However a parallel project lifecycle is infinitely 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 issues such as network
bandwidth have not been addressed first.
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 discarded 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 company 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 is no one answer to whether or not a company should migrate. In-depth
studies should be undertaken to weight up the important issues and establish
if a migration project will be beneficial for a particular company or
organization.
Our investigations also 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 beware 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/sf0801/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; ‘The Object-Oriented Database Manifesto’,: