How to Reverse Engineer a Model from a Database or a Script

Reverse engineering is the process of creating a data model from a database or a script. The modeling tool creates a graphical representation of the selected database objects and the relationships between the objects. This graphical representation can be a logical or a physical model.

You can reverse engineer only into a blank model. You cannot reverse engineer into a model that has objects in it.

A database can be reverse engineered for the following reasons:

To understand how the objects are related to each other and then to build upon it
To demonstrate the database structure

After the reverse engineering process completes, you can perform the following tasks:

Add new database objects
Create the system documentation
Redesign the database structure to suit your requirements

Most of the information that you reverse engineer is explicitly defined in the physical schema. However, reverse engineering also derives information from the schema and incorporates it into the model. For example, if the target DBMS supports foreign key declarations, the reverse engineering process derives identifying and non-identifying relationships and default role names.

You can derive all the major model information, except subtype relationships, because currently no SQL database management system supports it. However, the target databases vary in the amount of logical data model information that is included in the physical schema. For this reason, the resulting models can vary depending on the target database that is selected. You can also infer some logical information including primary keys, foreign keys, and table relationships. You can use the table index definitions or column names to infer these keys and relationships.

You can include or exclude RI triggers in the reverse engineering process. You can select to treat RI triggers as model objects or use the forward engineering option to include RI triggers in the schema. You can also choose to include or exclude these options during reverse engineering.

When you reverse engineer a database, you can set a trace file to record the queries that are executed to retrieve objects. You can review the queries after the reverse engineering process completes.

The following diagram illustrates the steps to reverse engineer a model from a database or a script:

Illustrating the reverse-engineering process

Complete the following steps to reverse engineer a model:

(Optional) Save database queries to a trace file.
Select model details.
Select the reverse engineering options.
Connect to a database and reverse engineer.

More information:

Inference Table for Reverse Engineer

Save Database Queries to a Trace File

Reverse Engineering Specific Objects

This section includes details about how the reverse engineering process works for different database objects.

Index

When you reverse-engineer a database, the name, definition, and parameters of each index that is defined on the server are imported. When you import the index information from a server, the storage location information for each index is maintained. Therefore, you can recreate the database using the same storage assignments. You do not have to reassign the storage location for each index manually.

After you import indexes, you can view or modify the index properties, definitions, and table associations in the Indexes dialog. You can assign an index to a physical storage object in the Indexes dialog for a Db2 z/OS, Informix, Oracle, SQL Server, and SAP ASE database. If your target database is Db2 z/OS, Informix, and Oracle, you can also modify the storage parameters in the Indexes dialog.

If a physical storage option is selected for a Db2 z/OS, Informix, Oracle, or SAP ASE database, then the schema includes index physical storage parameters.

Physical Storage Object

When you reverse-engineer a database, you can import the names and definitions of physical storage objects you have defined on the target server. The import happens in the same way that physical tables, indexes, and other physical schema information is imported. After you import physical storage objects, you can view or modify the object definitions and table associations using the standard editors.

Validation Rule

When reverse-engineering from a schema file, script, or system catalog, validation rules are imported and attached to the appropriate table or column in the resulting model. The convention that is used to name the imported validation rules is as follows:

VALID_RULEn

Here n is a sequential number starting at zero. The first validation rule that is encountered is named VALID_RULE0, the next rule VALID_RULE1, and so forth, until the entire schema is processed.