Designing the Data Structure › Transforming the Data Model › Transformation Implications

Transformation Implications

Before starting transformation, it is worth considering the implications of transformation, which are the differences between the:

• Conceptual (business level) definition represented as a data model
• Logical database definition represented by the Data Structure List
• Physical definition represented by the Data Store List

When you transform the data model, a physical database definition is created. There is no dynamic link from this definition back to the data model.

The implications of transformation are:

• You can make changes to the data model with no impact on the data structure.
• You can use the CA Gen retransformation capability when changes need to be reflected in a Data Structure List or Data Store List.
• You can make changes to a Data Structure List without affecting the data model.
• You cannot change the Data Structure List to violate the rules of the data model. For example, a text field cannot become a numeric field.
• If you use transformation or retransformation again, the changes you made in the Data Structure List and Data Store List will be lost.
• If you remove a foreign key index from a data record and then retransform, you will typically see the foreign key index added back in. In some cases, it may be better to rename unneeded indexes. For example, you could prefix each unneeded index with ZAP. You could then delete them near the end of testing for a project.

You must use meticulous change management to maintain the business logic embodied in the data model while allowing physical changes to be made to the Data Structure List. Any modifications to these lists need to be documented thoroughly to ensure consistency between different versions of the lists.