is only supported on Microsoft Windows.
|Tool Name||COOL:Xtras Mapper|
|Tool Web Site||http://www.ca.com/acq/sterling/|
|Supported Methodology||[Data Modeling] Data Store (Physical Data Model, Logical Data Model, Stored Procedure Expression Parsing) via VAR Export File|
|Remote Repository Browsing for Model Selection|
Tool: CA technologies / COOL:Xtras Mapper version 5.3.2 via VAR Export File
Metadata: [Data Modeling] Data Store (Physical Data Model, Logical Data Model, Stored Procedure Expression Parsing)
Component: CaTerrainMap version 11.0.0
This metadata bridge is a model integrator that takes as input:
- a logical data model from a COOL:BusinessTeam VAR file and
- a physical data model from a COOL:DBA VAR file and integrates them to produces a logical and physical data model.
To use this bridge, you should supply the full path to the logical COOL:BusinessTeam VAR file to the bridge option named 'Groundworks file' and the full path to the physical COOL:DBA VAR file into the usual 'From' field.
IMPORTING FROM STERLING SOFTWARE COOL:BUSINESSTEAM (GROUNDWORKS)
When a model is currently loaded in Sterling Software COOL:DBA (Cayenne Terrain for DB2):
1. Choose 'Export' from the 'File' menu.
2. Type the file name for the model you are saving in the 'File Name' text box (browse to select a specific directory).
3. Click 'Save'.
Some versions of the Terrain design tool, such as Sterling COOL:DBA 2.1.6, may offer the choice between multiple VAR export format flavors:
- The 'Terrain for DB2 5.3 format' flavor is supported by this bridge
- The 'Terrain for DB2 5.4 format' flavor is supported by this bridge
- The 'COOL:DBA 2.1 format' flavor is supported by this bridge
- The 'COOL:DBA 2.x Full Meta Format' flavor is not supported by this bridge
FREQUENTLY ASKED QUESTIONS
Q: How does this bridge work?
A: The TerrainMap utility, delivered with the COOL:DBA tool, allows to generate COOL:DBA physical data models from COOL:BusinessTeam logical data models. This bridge uses the information generated by TerrainMap (MAPSYSMAP) in the COOL:DBA VAR file to merge each physical object with its corresponding logical object in the logical model.
Q: What is the recommended Terrain VAR format flavor?
A: We know the choice of a Terrain VAR format flavor has an impact on how the mapping and traceability information between a logical model and a physical model is encoded and saved in the file. The TerrainMap integrator bridge allows to use this mapping information to integrate a logical model and a physical model. In order to do that, make sure to choose one supported format flavor, and set the option labelled 'Mapping encoding version' to the appropriate value:
- Terrain for DB2 5.3: This one applies if you saved your Terrain model using the export flavor 'Terrain for DB2 5.3'
- Terrain for DB2 5.4: This one applies if you saved your Terrain model using the export flavors 'Terrain for DB2 5.4' or 'COOL:DBA 2.1'
|Groundworks file||Enter here the full path to the Groundworks VAR file to import and merge with the current Terrain model.||FILE||*.var||Mandatory|
|Terrain file||Enter here the full path to the Terrain VAR file to import and merge with the current Groundworks model.||FILE||*.var||Mandatory|
|Mapping encoding version||This option allows you to select which algorithm must be used to decode the mapping information between the physical model and the logical model. The encoding of this mapping information in the Terrain VAR file depends on the version of the tools used to design the model, but cannot be detected automatically. When using COOL:DBA 2.1.6, four VAR export format flavors are available:
- Terrain for DB2 5.3 -> use option value 'Terrain for DB2 5.3'.
- Terrain for DB2 5.4 -> use option value 'Terrain for DB2 5.4'.
- COOL:DBA 2.1 -> use option value 'Terrain for DB2 5.4'.
- COOL:DBA 2.x full meta format -> this format is not supported.
|Terrain for DB2 5.3|
|Tables merge logging level||Use this option to customize the amount of information to be reported during the merge process and allows to define which messages to display when merging a table with an equivalent logical entity:
'Not merged' - Only display a message for tables which could not be merged (default).
'Merged' - Only display a message for tables which could be merged with an entity.
'Both' - Display a message for all tables.
'None' - Do not display any information on how tables were merged.
|Candidate Keys merge logging level||Use this option to customize the amount of information to be reported during the merge process and allows to define which messages to display when merging a physical candidate key with an equivalent logical candidate key:
'Not merged' - Only display a message for candidate keys which could not be merged (default).
'Merged' - Only display a message for candidate keys which could be merged.
'Both' - Display a message for all candidate keys.
'None' - Do not display any information on how candidate keys were merged.
|Foreign Keys merge logging level||Use this option to customize the amount of information to be reported during the merge process and allows to define which messages to display when merging a physical Foreign key with an equivalent logical Foreign key:
'Not merged' - Only display a message for foreign keys which could not be merged (default).
'Merged' - Only display a message for Foreign keys which could be merged.
'Both' - Display a message for all Foreign keys.
'None' - Do not display any information on how Foreign keys were merged.
|Duplicate Attributes on Generalizations||Determine whether Attributes should be duplicated through Generalizations.
'True' - Yes, all attributes are copied from the parent Class to the subtype Class.
'False' - No. Only the primary key Attributes are migrated.
|CREATE VIEW fix||This option adds an extra ';' at the end of the 'CREATE VIEW' SQL statement.
This is a workaround for some of our customers and should not be changed unless you know for certain that you need it.
|Encoding||Specifies the character set encoding of the model to be imported or exported. If there are multiple choices for a language, the actual encoding will be indicated between parentheses. The default is 'Western European (Windows 1252)' on Windows and 'Western European (ISO 8859-1)' on other platforms.||ENUMERATED||
|Meta Integration Repository (MIR)
(based on the OMG CWM standard)
|"CA COOL:Xtras Mapper (TerrainMap for DB2)"
|Aggregation||Based on attributes belonging both to a primary key and a foreign key associated with the association|
|Source||Based on the multiplicity|
|AssociationRoleNameMap||When migrated attributes have a different name|
|BaseType||Domain||Created as side effect of Derived Type creation|
|DataType||Datatype||See datatype conversion array|
|Name||Datatype||Standard name based on the type|
|PhysicalName||Datatype||Standard name based on the type|
|UniqueKey||Only for primary key|
|CppClassType||Set to ENTITY|
|CppPersistent||Set to True|
|ClassDiagram||Filter, Keyword||Diagrams based on Filters and Keywords are imported|
|DataType||Datatype||See datatype conversion array|
|LowerBound||Numeric Range (Maximum)|
|UpperBound||Numeric Range (Minimum)|
|DesignPackage||No equivalent in GroundWorks. A main package "Logical View" is created to contain all entities/partnerships|
|Index||Keys, Foreign Keys||Associated with each key|
|IndexMember||Associated with each attribute in a key|
|Position||Order in the file|
|Projection||Diagram Object Projection||Graphical Information|