Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Database evolution group for transparency and integrity of application access

IP.com Disclosure Number: IPCOM000166487D
Original Publication Date: 2008-Jan-14
Included in the Prior Art Database: 2008-Jan-14
Document File: 3 page(s) / 80K

Publishing Venue

IBM

Abstract

In this article, a database revolution group is proposed for transparency and integrity of application access when database schema changed. With this solution, database applications can transparently access their corresponding develop-based databases, and these different databases can maintain data integrity by log shipping and replay with a SQL mapper.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 3

Database evolution group for transparency and integrity of application access Database evolution group for transparency and integrity of application accessDatabase evolution group for transparency and integrity of application access

Background

Nowadays, businesses agility leads to fast change, consequently its corresponding database should be able to adapt these changes, which are called database evolution. In database evolution activity, related database schema change leads to incompatibility of database access code in the client applications. Currently, several different approaches can be used to obtain the compatibility between databases and applications.

Change related database access code of all applications. This approach is very time-consuming and complex, especially under the below situations: 1), when the database access code is dispersed in the application; 2), when database access code changes will trigger a lot of other changes in the application; 3), when there are a lot of applications that access this database, need to perform the adaptation; 4), when there is a legacy system that access the database, the change of its code would lead to a disaster
Create a database layer to adapt the changes to client applications. By this approach, the application access code is not required to be updated. Instead, a database layer between database and applications will be used, when the old application issues request to access the new database, the database layer will transform this request to be compatible with the new database schema. Database view mechanism is one typical solution, a database view is a virtual or logical table composed of the result set of a query. Unlike ordinary tables in a relational database, a view is not part of the physical schema: it is a dynamic, virtual table computed or collated from data in the database. When database refactoring is performed to change the database schema, some new views can be constructed to adapt the change, so the database access code is not required to update. But still this approach has below limitations: It can't guarantee database access transparency and database integrity. For example, when a column of a table is deleted in the old database schema, thus the new database schema doesn't have this column, when an old database requests to write some data to the new database, then after the database layer transformation, the column is deleted in the new database, later when the old database reads data from new database via this database later, it will be found out that the data requested to write to database is not really written to the new database but deleted by the transformation layer.

Database Revolution Group

To obtain database access transparency and database integrity when database schema is changed, a database revolution group is proposed in this artic...