Schema Evolution

 

Schema Evolution is the process of assisting and maintaining the changes to the schematic information and contents of a database. An important issue in schema evolution is to provide evolution transparency to the users, whereby they would be able to pose queries to the database based on a (possibly old) version of the schema they are familiar with, even if the schema has evolved to a different state. This will make the front-end to the user more declarative, as she is no longer bothered about the details of the database schema.

Consider an application which has schema changes happening in a dynamic way. Every time the schema gets modified, the previous application programs written for the database become invalid and the user will have to rewrite/modify them after `updating' herself about the schema status. We maintain that a end user should not be bothered with the details about the schema of the database she is using, especially if it keeps changing often. A better approach would be to assume that the user has the knowledge of a particular schema and let her use this to formulate queries against the database, even after the schema has been modified. The idea is to shield the modifications to the schema of the database from the user as much as possible. As a consequence, it should be possible to maintain currency and relevance of application programs with very little modifications to account for the changes to the schema. This framework affords the possibility of schema-independent querying and programming.

We consider an example to illustrate our approach. This example assumes there has been no loss of information in the meta-data, between different stages of the evolution.

Time t1:
$schema$₁:              $rel$₁ (a₁₁, a₁₂, a₁₃)        $rel$₂ (a₂₁, a₂₂).

Time t2 (current schema):
$schema$₂:              $rel$₁ (a₁₁, a₁₂)        $rel$₁' (a₁₂,a₁₃)        $rel$₂ (a₂₁, a₂₂).

Relation $rel$₁ has been split into $rel$₁ and $rel$₁' at time t2 (assuming the decomposition is loss-less join).

The following SchemaLog program defines a mapping between the two schemas.

$schema$₁::rel₁[f(X,Y,Z):a₁₁ $→$ X, a₁₂ $→$ Y, a₁₃ $→$ Z]  $←$
$schema$₂::rel₁[I':a₁₁ $→$ X, a₁₂ $→$ Y],  schema₂::rel₁'[I'':a₁₂ $→$ Y, a₁₃ $→$ Z]

$schema$₁::rel₂[f(X,Y):a₂₁ $→$ X, a₂₂ $→$ Y]   $←$  schema₂::rel₂[I':a₂₁ $→$ X, a₂₂ $→$ Y]

Suppose the user has a view of $schema$₁; she can still pose queries with that view. The transformation program will take care of the relevant evolutionary relationship between the two schemas. Besides, since the mapping between older versions and evolved versions of the schema is maintained declaratively as a logic program, the maintenance of application programs becomes much easier.

One complication that may arise in the context of schema evolution is that evolution might involve some loss of (meta-)information (say deletion of attributes). How can we produce meaningful answers to queries (based on an older version of the schema) which refer to such ``lost" information? We suggest a cooperative query answering (See 1.6) approach to this problem.