Potential Loss of Metadata from Tool A to Tool B

There are 7 points of potential metadata loss from Tool A to Tool B:

• Tool A's Methodology/Metamodel Support & Implementation,
• Tool A's Export Capabilities,
• MIMB's Import Bridge for Tool A,
• MIR's Methodology/Metamodel Support & Implementation,
• MIMB's Export Bridge for Tool B,
• Tool B's Import Capabilities,
• Tool B's Methodology/Metamodel Support & Implementation.

Notes:

• As far as (1) and (7) are concerned, tools may have different implementations of the same methodology (IDEF1X or UML). For example some concepts may not have been implemented yet, or some proprietary extensions may have been done. We usually deliver a demo or generic coverage model for each tool in the "Samples" directory of the MIMB installation.
• As far as (2) and (6) are concerned, it is always a good idea to export a model from the tool and immediately re-import it to check if all modeling concepts are properly exported/imported. The Import/Export capabilities (file format or API) are not always the best-tested features of a tool. It makes business sense for design tool suppliers to put more priorities on functionalities, robustness, and performance, in order to keep a competitive advantage.
• As far as (4) is concerned, MIMB uses a non-persistent version of the Meta Integration Repository (MIR) which implements and integrates IDEF1X data modeling, OMG UML object modeling, and OMG CWM warehouse modeling. There are the current limitations:
• MIR does not implement all IDEF, OMG UML & CWM standards. MITI has been focusing on data and basic object modeling for its metadata and data movement solutions. The support for activity/process modeling is not implemented (due to the lack of agreements and possible mapping between methodologies in that area). Therefore:
• MIR implements IDEF1X data modeling, but does not implement the other IDEF standards such as IDEF0 activity modeling.
• MIR implements UML Class Diagrams, but does not implement the other UML diagrams such as Use-Case, State-Transition, or Interaction diagrams.
• MIR implements CWM Relational, OLAP and Transformation packages, but does not implement some the CWM metamodels such as Warehouse Process, or Warehouse Operation packages
• MIR implements conceptual, logical, and physical modeling concepts in an integrated manner. For example, the primary/foreign key of an IDEF1X physical data model is transferred as qualifiers of a UML logical object model. However MIR currently does not support multiple physical models for the same logical model.
• MIR defines some standard data types based on ODBC (in order to properly provide data movement solutions). Some tools may provide extra proprietary data types that cannot be properly mapped to MIR data types.
• As far as (3) and (5) are concerned, the metadata mapping of both import & export bridges of each tool can be found in the MIMB documentation: on-line help or through the help web site (select/click on a bridge to get the full specifications including all the bridge parameters/options and detailed mapping specifications).
• The Database Data Type support is limited by the published Data Type Mapping Specifications. Such limitations are based on the supported database or data store technologies, their supported versions, their supported data types, and finally on the actual data type mapping implemented by the import or export bridge. All Data Type Mappings are saved in XML files (within the configuration directory) which are dynamically read by all import and export bridges.
• The Database specific (proprietary) physical properties are not fully converted, as the information is not always portable across tools' target databases.

MITI provides the best possible metadata mapping across methodologies and tools. However, some modeling concepts may not be available in Tool A, MIR, or Tool B. In such a case, the import & export bridges try to use the descriptions or notes to carry such modeling concepts all the way from the source to the target tool without any loss.