* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Relational Databases
Survey
Document related concepts
Oracle Database wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Relational algebra wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Ingres (database) wikipedia , lookup
Encyclopedia of World Problems and Human Potential wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Concurrency control wikipedia , lookup
Functional Database Model wikipedia , lookup
ContactPoint wikipedia , lookup
Clusterpoint wikipedia , lookup
Versant Object Database wikipedia , lookup
Transcript
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’,: