Browse Prior Art Database

Efficient Schema Evolution for structured data types

IP.com Disclosure Number: IPCOM000032223D
Original Publication Date: 2004-Oct-26
Included in the Prior Art Database: 2004-Oct-26
Document File: 3 page(s) / 41K

Publishing Venue

IBM

Abstract

In DB2 UDB v7.1, it is possible to create tables with columns that are of a structured type. Data in these columns are stored using an efficient embedded storage mechanism coupled with runtime codes that can process the storage format.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

Page 1 of 3

Efficient Schema Evolution for structured data types

Background

In DB2 UDB v7.1, it is possible to create tables with columns that are of a structured type. Data in these columns are stored using an efficient embedded storage mechanism coupled with runtime codes that can process the storage format.

The types that are used to form columns have to be defined before the columns are defined. Eg:

create type Point as (x int, y int) mode db2sql;
create table data as (i int, p Point) mode db2sql;

Instances of Point may be stored in the "p" column of data as follows:

insert into data values (5, Point()..x(5)..y(8));

Now it's possible to create subtypes of Point ... :

create type 3DPoint under Point as (z int) mode db2sql;

.... and store instances of these subtypes in the "p" column of "data":

insert into data values (6, 3DPoint()..x(5)..y(8)..z(10));

Suppose though, that the table "data" did not exist. If that's the case, it's possible to alter the type Point like so:

alter type Point add attribute (z int);

Then there would be no need to create the subtype 3DPoint.

Problem

However, once a table with a column of a structured type exists, it is impossible (in today's implementation in DB2 v7.1) to alter the structured type (or any other structured type which might be contained in an instance of the type)

This causes severe usability problems, and also hinders application developers from being able to modify their types over time.

Reason for the problem

Why does the current DB2 implementation impose such a restriction on users ?

The embedded storage implementation of structured types (ADTs) is described in earlier patents.


1.


2.


3.

In essence, it affords access to and mutation of attributes through an "offset scheme". That is, each attribute has a unique offset in a type and all of its subtypes .

Access to and mutation of such an attribute results in the generation of compile-time code with

generic OBSERVER and MUTATOR operators. The operands for these mutators specify the offset of the attribute that will be used at runtime to perform the observe/mutate operation. Adding an attribute after data (potentially) of the unaltered type (the old data ) exists in a column

causes the following problems :

The number of attributes in the ADT header of old data is no longer accurate.

Since you can alter a type which has subtypes, the offsets corresponding to the subtype

attributes in new data no longer match the offsets corresponding to old data.

1

Page 2 of 3


3.


4.

Generic operators like OBSERVER and MUTATOR cannot deal with old-data coexisting with

new-data.

Note also that since a type could be altered multiple times, these generic operators need to

co-exist with multiple different data forms.

Because of the problems listed above, we choose to limit schema evolution by not permitting

altering of types once there exists the potential of data with such types in table columns.

We describe in this invention, a novel scheme to achieve "real" schema evoluti...