Chapter 12 Generating Other Models from an OOM
You can set the following general generation options:
| Option | Description |
|---|---|
| Check Model | When selected, verifies the model before generating the PDM, and stops generation if an error is found |
| Save Generation Dependencies | When selected, PowerDesigner keeps track of the identity of the origin of each generated object. This is useful when merging two PDM which have been generated from the same OOM. Objects can be compared and recognized as the same object, even if the object has been modified in the merged PDM. If not selected, origin objects have no link with generated objects |
| O/R Mapping | When selected, allows to define the generated PDM as the data source of the current OOM and to create object correspondence between OOM and PDM. If you select the O/R mapping option, the Save Generation Dependencies option is automatically selected because O/R mapping uses object identifying numbers. You cannot deselect the Save Generation Dependencies option as long as the O/R mapping option is selected |
| Convert Names into Codes | When selected, object codes are generated from names using the corresponding conversion script. This is useful when generating models with very different naming conventions. For example a Java class attribute code may be "customerName" whereas a PDM table column code may be "CUSTOMER_NAME". With this option selected, both objects will have their codes generated from their names. If you do not select this option, generated object codes will be copied from original object codes |
| Rebuild Triggers | When selected, allows to rebuild triggers with preservation option, after the PDM generation. Rebuild takes place after merge if you are updating an existing PDM |
| Enable transformations | This button is used to activate transformations during generation.
When you click this button, the Pre-generation tab appears if the source model contains transformations. You can select the transformations to execute before generation. The Extended Model Definitions tab also appears for you to select extended model definition files to attach to the generated model. These files may contain post-generation transformations, in this case, the Post-Generation tab appears to let you select the transformations you want to be executed in the generated model. If the generation is an update, and the generated model contains extended model definitions with post-generation transformations, the Post-generation tab automatically appears as soon as you click the Enable Transformations button |
For more information on O/R Mapping, see section Understanding O/R mapping, in chapter Working with Object-Oriented Models.
For more information on conversion scripts, see section Using a conversion script, in chapter Managing models in the General Features Guide.
Check model before generation
If you select the Check Model option, the procedure to generate a PDM starts by checking the validity of the OOM. A PDM results when no errors are found. You can set check options by selecting Tools→Check Model.
The following parameter defines the naming convention for tables:
| Parameter | Description |
|---|---|
| Table prefix | Prefix for the names of tables generated from classes in the OOM |
The following parameters define default referential integrity constraints:
| Parameter | Description |
|---|---|
| Update rule | Default update constraint for referential integrity |
| Delete rule | Default delete constraint for referential integrity |
For a description of referential integrity, see the glossary in the Physical Data Model User's Guide .
By default, the name of the migrated foreign keys generated in a PDM is identical to the name of the primary key. In case of column name conflict, the first 3 letters of the name of the parent table are added before the name of the migrated column.
You can modify this default behavior and use templates for naming the migrated foreign keys. In the Reference groupbox, you can select one of the predefined templates in the FK Column Name Template list. These templates are saved in the registry, you can modify them, but their default value is preserved.
You can also create your own foreign key naming templates by typing a template directly in the FK Column Name Template box using the following variables:
| Variable | Value |
|---|---|
| %REFR% | Generated code of the reference |
| %REFNAME% | Reference name |
| %REFRCODE% | Reference code |
| %PARENT% | Generated code of the parent table |
| %PNAME% | Parent table name |
| %PCODE% | Parent table code |
| %COLUMN% | Generated code of the parent column |
| %COLNNAME% | Parent column name for the corresponding PK |
| %COLNCODE% | Parent column code for the corresponding PK |
| %KEY% | Name of the key constraint attached to the reference |
| %CONSTNAME% | Name of the key constraint attached to the reference (same as %KEY%) |
| %KNAME% | Name of the key attached to the reference |
| %KCODE% | Code of the key attached to the reference |
| %PROLE% | Role of the class that generated the parent table, this variable proceeds from the object-oriented environment. If no role is defined on the association, %PROLE% takes the content of %PARENT% to avoid generating a column with no name |
You can also use the default PowerDesigner formatting variables in the template as explained in section List of PowerDesigner formatting variables in chapter Variables in PowerDesigner in the PDM User's Guide.
Customized naming templates reappear in the generation dialog box the next time you open it, but are not saved in the registry thus not added to the dropdown list of predefined templates.
For example, if you define the template %PROLE%, the name of the foreign key will be made of the role beside the class that generated the parent table containing the primary key. If the parent table contains multiple keys, the foreign key names will be automatically renamed.
In the Reference groupbox, you can select the Always Use Template radio button to always use the default or customized template for naming FK columns, even if there is no conflict with an existing column.
The following parameters define naming conventions for indexes:
| Parameter | Description |
|---|---|
| PK index names | Naming convention for primary keys, by default %TABLE%_PK |
| Key index names | Naming convention for alternate keys, by default %TABLE%_AK |
| FK index names | Naming convention for foreign keys, by default %REFR%_FK |
| FK threshold | Minimum number of estimated occurrences of an entity necessary to create an index on a foreign key |
You can use the following variables in the PK index names and Key Index Names fields:
| Variable | Value |
|---|---|
| %TABLE% | Generated code of the table. This is the table code generated in the database. It may be truncated if the code contains characters not supported by the DBMS |
| %TNAME% | Table name |
| %TCODE% | Table code |
| %TLABL% | Table comment |
You can use the following variables in the FK index name field. The generated code of a variable is the code defined in the object property sheet, it may be truncated when generated if the code contains characters not supported by the DBMS.
| Variable | Value |
|---|---|
| %REFR% | Generated code of the reference |
| %PARENT% | Generated code of the parent table |
| %PNAME% | Parent table name |
| %PCODE% | Parent table code |
| %CHILD% | Generated code of the child |
| %CNAME% | Child table name |
| %CCODE% | Child table code |
| %PQUALIFIER% | Parent table qualifier |
| %CQUALIFIER% | Child table qualifier |
| %REFRNAME% | Reference name |
| %REFRCODE% | Reference code |
Preserving a modified primary key
If you modify a primary key in a PDM, then regenerate the PDM from an OOM, the modified primary key is not preserved. If you want to preserve a modified primary key, you need to modify the identifier in the OOM before regeneration.
| Copyright (C) 2005. Sybase Inc. All rights reserved. |
| |