Migration of IMAGE Data

April 2002

Migration of IMAGE Data

Strategy to consider while examining your Transition plans

Steps in IMAGE migration

By Charles Finley

Actually migrating an IMAGE database is a multiple-part process. First, the IMAGE schemas are analyzed programmatically to extract dataset names, data item names, compound items, data types, key items, search items, sort items, and paths. The analysis program produces SQL CREATE table scripts for each IMAGE master and detail set (automatic master sets as a physical table are not required, although their indexing function will be preserved). These SQL scripts can then be executed to produce empty tables ready to be populated with data.

Our product’s Xschema processor makes various changes that are needed in order to map IMAGE data to the target RDBMS. For example, in Oracle, names can contain only alphanumeric characters from the database character set and the characters _, $, and #. The dash character is therefore mapped to the underscore character.

Compound items are a feature of IMAGE that do not have an equivalent in the target RDBMS. Multiple unique column names are created to support these items. Naming of schema objects has some restrictions in the target RDBMS.

Migration of IMAGE data involves exporting master and detail sets to sequential files using third-party utilities or custom export programs. These files are then transferred to the target Unix machine, and an automated tool uses the native RDBMS loader utility to populate the empty relational tables with this data.

It is important to note that the preceding process does not result in any normalization of the data. Relational database systems are based largely on mathematical relational theory. Designing a relational database involves the process of normalization.

The theory of normalization is a key element of relational database design. In simple terms, normalization is the process of decomposing and arranging the attributes in a schema, which results in a set of tables with very simple structures. The purpose of normalization is to make tables as simple as possible and to reduce the redundancy of information within a database. When done properly, the normalization process will result in well-designed tables, with reduced storage of redundant data and the increased ability to effectively enforce integrity constraints.

This normalization process, if attempted on an existing IMAGE database, obviously would involve major reengineering of the application and would thus be impractical. The inherent network structure and key/ search item construct of IMAGE, by its very nature, produces some data redundancy.

The lack of normalization can be perceived as a drawback, but it is perfectly acceptable to have migrated IMAGE data into a non-normalized relational form for an intermediate period of time. Once the migration is complete, there are no restrictions on normalizing at a managed pace appropriate for the application and future development.

One of the advantages of migrating data into a RDBMS immediately even while retaining the IMAGE API is that it allows the user to take advantage of new functionality sooner. The flexibility of SQL allows for the ad hoc creation of indices to improve performance, as well as data structures, such as views and synonyms, to mask or massage the data structure without actually changing the table structure itself.

Using SQL like this brings advantages. The application developer is able to write new applications with the productivity tools that are available in the target environment being migrated toward. They can then use the power of distributed transaction processing, client-server configurations, and head toward full application portability.

Charles Finley (cfinley@xformix.com) is president of Transformix Computer Corporation (www.xformix.com), a company that specializes in the migration and enhancement of MPE applications to Unix and Windows.