Perform analysis of the source database components
Perform analysis of the source database logical and physical layouts
Perform analysis of the source database structure (tables, indexes, views, constraints, and so on.)
Perform analysis of the source database table data
Create a DB2 database
Perform initial database configuration
Create target database structure
Migrate sample representative test data to the DB2 database
After you perform the assessement and planning steps, you can begin the process of converting the structure (DDL) of the source database to DB2. Differences in syntax can often be fixed without a lot of effort, but in some cases, you must implement workarounds to achieve the original functionality. This is especially the case if non-standard or proprietary features are used.
Metadata is the logical Entity-Relationship model of the data, and describes the meaning of each entity, the relations that exist, and the attributes. From this model, SQL data definition language (DDL) statements can be generated to implement the model.
If the database structure is already in a logical form (that is, a modeling tool was used), it is often possible to have the modeling tool generate a new set of DDL that is specific to DB2. Otherwise, the DDL from the current system must be captured then modified so all the syntax is compatible with DB2. After the DDL is converted, it can be loaded in a DB2 database.
There are three approaches typically used to move the structure of a database:
Manual methods - Dump the structure using a native database utility, make manual adjustments for any non-supported syntax, and import it to DB2.
Metadata transport - Use a modeling tool to generate DB2-compatible DDL.
Porting and migration tools - Use a tool to automatically extract the structure, adjust it, and then deploy it to DB2.
Most DBMSs offer a utility that can extract the database structure and place it into a text file. The structure is represented as DDL statements, which can be used to re-create the structure on another database server. However, in order for the DDL to deploy successfully to DB2, any non-compatible syntax must be changed or removed.
Besides syntactical differences, changes may also be needed to account for differences in data types and other semantics. For example, there is no native BOOLEAN data type in DB2 - it must be simulated using another type such as SMALLINT or by using a user-defined type. Before converting and deploying all the DDL at once, try deploying a small representative portion and examine any errors that may be reported. From this, most of the corrections that will be needed will become evident. Once these corrections are made in the rest of the DDL, deployment should be almost error free. Consult the appropriate DB2 porting guide for more information about syntax and other differences.
Many database structures are designed and deployed using modeling tools. These tools let the designer specify the database structure in the form of Entities and Relationships (E-R). The modeling tool then generates the physical model (in other words, the DDL) from the E-R description. If the database being ported was designed (and maintained) using one of these tools, porting the database structure to DB2 can be as simple as generating DB2-compatible DDL from the tool.
Another popular way of porting a database structure (and other database objects) is with the use of a porting and migration tool. This type of tool usually extracts all relevant information from the source database, then modifies and deploys it in the destination database.
For example, the IBM Migration Toolkit (MTK) accepts a DDL file containing object definitions or connects directly to the source system and performs its own extraction. It then converts the DDL into a DB2-compatible form. You then have the option of deploying the converted DDL in a DB2 database.
Although it may seem that the conversion should be straightforward (SQL is SQL, isnt it?), there are still issues that may arise due to differences in DBMSs. For example, you may encounter issues around data type differences, storage limitations, large object handling, and other proprietary functionality or syntax used.
