Meta Integration® Model Bridge (MIMB)
"Metadata Integration" Solution
Description "Reference Guide"
- Technology Overview
- Metadata Movement Use Cases
- Metadata Movement Solutions
- Business Intelligence Metadata Engineering
- Known Limitations
- Frequently Asked Questions
- FAQ on Internationalization & Encodings
- FAQ on OMG XMI for UML and CWM
- FAQ on Microsoft Visio
- FAQ on Microsoft Repository
Known Limitations as of 2009/01/01
Table of Contents
- Consistency Check of the Source Model
- Metadata movement/conversion is limited to the "Mapping Specifications"
- Potential loss of metadata from Tool A to Tool B
- Limitations on Import/Export Round-Trip
- Limitations in the Receiving Environment for Merge/Update of Metadata
- API based Bridges
- Multi-file based Bridges
- Graphical Layout is carried only through some Bridges
- Transformation Expression based Bridges
Consistency Check of the Source Model
The user can select between "basic" or "detailed" consistency check of the imported model before the export to the target tool.
This kind of model consistency check can detect disconnected
relationships, foreign keys not connected to any primary
or alternate key, etc.
Having a centralized model validation between import and export
allows to continuously improve the consistency check algorithms,
and avoids each export bridge to retest for the same issues.
Consistency checks can report "warnings" in the source model,
or "errors" that are fatal and will prevent the export to any
tool. The solution is to fix the original model, and then import
it again. If the user purposly decides to turn off all consistency
check (e.g. when the tool is not available to fix the source model),
then the imported model may break the export bridge, or produce an invalid model that may break the target tool.
MITI assumes no responsibility when consistency check is turned off.
Metadata movement/conversion is limited to the "Mapping Specifications"
The metadata mapping and transformations implemented by Meta Integration® Model Bridge (MIMB)
are limited to the published model mapping specifications for each integrated tool.
Such specifications are part of the MIMB online help, and are also published on the web
http://www.metaintegration.net/Products/MIMB/Documentation/
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.
-
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
(see
http://www.metaintegration.net/Products/MIRSDK/ for more details).
There are the current limitations:
- MIR does not implement all IDEF, OMG UML & CWM standards.
MITI has been focussing 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 MITI web site
http://www.metaintegration.net/Products/MIMB/Documentation/.
-
Database specific 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.
Limitations on Import/Export Round-Trip
There are an additional considerations when performing what is often referred to as a "round-trip",
or importing from tool A, exporting to tool B, editing the model (or not) in tool B,
re-import this model in from tool B, and exporting back to tool A. In this case,
the 7 points of potential metadata loss identified above are compounded so that there
are now 7 additional points of loss:
-
They involve methodology changes (e.g., UML back to IDEF1X)
-
They may contain "Many to one" or "many to many" type relationships (e.g., data type information
and data base definitions many be much narrower in one tool than another)
-
They are based upon different levels of information in the import process as opposed to
the export process (or vice-versa) used to determine the result (e.g, expressions)
-
In addition, the tool's own transformations and metadata coverage (even medium for exchange)
will likely be different on import versus export (e.g., import may be using an
API with information about the entire tool repository available for the bridge,
while export is via an XML file which then must be parsed by the receiving tool itself).
Again please refer to the web site for this information
http://www.metaintegration.net/Products/MIMB/Documentation
The fidelity of some simple types of metadata may be well maintained, where there is a
direct, one-to-one, translation from tool A --> MIR's methodology --> tool B and
then back again. Examples include tools with the same methodology and metadata coverage
(e.g., a data modeling and design tool to another data modeling or design tool), or simple
elements like the name, description, layout, etc. This process is referred to as
"round-tip migration", and may work successfully given these restrictions.
However, it is never recommended that a combination of import-> export-> edit-> export-> import
(i.e., "round-trip engineering") be expected to retain fidelity when there is a migration
from tool A to tool B (and vice-versa) of methodology, metadata coverage or any of the known
limitations identified above. What round-trip engineering implies is a forward-engineering
and then reverse engineering process, which has never been a reality in systems engineering.
One should not expect the forward engineering of simple to complex transformations
(e.g., forward engineering from a spreadsheet to an ETL tool and then reverse engineering from the
ETL tool back to a spreadsheet) would be reversible, or even bear much resemblance to the original.
The proper process is to treat the forward-engineering step as "irreversible", treat the
reverse engineering step as a separate process, and not expect to effectively compare
the original will the "round-trip" result, nor re-use the result for further engineering of the metadata.
Some examples:
-
The process of importing from Informatica PowerCenter and then exporting to to Microsoft
Excel is in fact a "Mapping Requirement Reporting" exercise by reverse engineering of
a very complex and large graph of transformations steps into a summary direct mapping
lineage in Excel
-
The process of importing an ETL design in Microsoft Excel and exporting it to
Informatica PowerCenter is in fact a "Mapping Requirement forward Engineering" exercise
to allow business users to automatically prepare the work for the technical
designers of the Informatica design tools
-
Although each of the above steps can use the same Excel format (MetaMap), the roundtrip
reengineering is not recommended and is likely to produce results which are not useful
for all of the reasons identified above. Furthermore, Informatica PowerCenter, like many
destination tools, is unable to consume the exported metadata correctly, i.e., it is
unable to compare/merge/integrate different versions of complex transformations.
(Please see the section on Limitations in the Receiving Environment for Merge/Update of Metadata.)
Limitations in the Receiving Environment for Merge/Update of Metadata
The export bridges generally depend upon the tool receiving the metadata to integrate the
metadata correctly, i.e., provide compare, merge and integrate capabilities. Such capabilities are:
-
Frequently available on data modeling and model design tools (e.g. CA ERwin Data Modeler)
-
Available in some ETL tools to source/target data stores, but not for data transformations
(e.g. Informatica PowerCenter)
-
Rarely available on Business Intelligence design tools (e.g. SAP Business Objects Designer)
In order to accomodate these limitations in the destination tool, the following MIMB export bridges
offer "limited" metadata update capabilities (Please see the bridge parameter tooltips for more details):
- Data Integration (DI) tools (for ETL Transformations), such as:
- Microsoft SQL Server Integration Services (SSIS)
- Oracle Warehouse Builder (OWB)
- Business Intelligence (BI) design tools, such as:
- Business Objects Designer
- Microsoft SQL Server Analysis Services (SSAS)
API based Bridges
Some MIMB bridges rely on the tool's API to import/export metadata, for example:
- Business Objects Crystal Reports
- Business Objects Designer (Windows only)
- Business Objects Desktop Intelligence (Windows only)
- Business Objects Web Intelligence
- Business Objects Repository
- CA Allfusion ERwin 4.x (ER1) (Windows only)
- CA Allfusion ERwin 7.x (erwin) (Windows only)
- CA COOL:Gen
- Cognos Impromptu (Windows only)
- Cognos ReportNet Repository
- IBM Rational Data Architect
- IBM Rational Software Architect
- IBM WebSphere Metadata Server
- IBM / Telelogic / Popkin System Architect (Windows only)
- JDBC
- Microsoft Excel (Windows only)
- Microsoft ODBO / ADOMD (Windows only)
- Microsoft SQLServer Analysis Services (DSO) (Windows only)
- Microsoft SQLServer Analysis Services 2005 via Repository (Windows only)
- Microsoft SQLServer Integration Services 2005 via Repository (Windows only)
- Microsoft SQLServer Reporting Services 2005 via Repository (Windows only)
- MicroStrategy (Windows only)
- NCR Teradata MDS (Windows only)
- Oracle Warehouse Builder
- SchemaLogic SchemaServer
Such MIMB bridges require these tools to be installed with
their API properly setup on the machine (PC) where the MIMB bridge is executed.
Multi-file based Bridges
When multiple files are involved, all them them must be accessible to the MIMB bridge.
Some MIMB bridges have paramaters of type "Directory" instead of just "File",
and therefore require access to a directory of multiple files, for example:
- CA COOL:Enterprise (OI.exp, AI.exp, PI.exp, TI.exp)
- CA COOL:Gen (*.ief)
- CoSort RowGen (*.ddf)
- IBM Rational Data Architect (*.dbm, *.ldm)
- IE:Advantage (iexent.imp, iexattr.imp, iexassoc.imp, iextable,imp, ietext.imp)
- Informatica Metadata Manager (*.ime)
- Oracle Data Integrator (*.xml)
Some MIMB bridges have parameters of type "File" which support the notion of "include" files,
and therefore require access to all the specified include file paths, for example:
- IBM Rational Rose (MDL)
- XML Schema (XSD) and Document Type Definition (DTD)
Graphical Layout is carried only through some Bridges
Some MIMB bridges convert the graphical information between tools,
including conversion of the model layout between various notations like IDEF1X data modeling,
and UML object modeling. The following MIMB bridges carry graphical information:
- Business Objects Designer
- Computer Associates ERwin
- Computer Associates COOL:BusinessTeam (Sterling GroundWorks) for some versions
- Computer Associates COOL:DBA (Sterling Terrain) for some versions
- Embarcadero ER/Studio
- IBM Rational Data Architect
- IBM Rational Software Architect
- IBM Rational Rose Object and Data Modeler
- Sybase PowerDesigner CDM and PDM
- Telelogic (Popkin) System Architect
However, some MIMB bridges do not transfer the graphical information of the model layout.
The primary reason for this limitation is that the import /
export capabilities of most tools do not provide graphical information. In
other words, their published file formats and/or Application Programming
Interface (API) cover the semantic (each of the modeling concepts), but not the
graphical information (i.e. the concept's associated shape sizes and positions).
Furthermore, when available, such graphical information is not easily reusable in
the target tool. This problem is also true for tools sharing the
same methodology (e.g. a tool may allow a graphical layout that is not
graphically implementable in another equivalent tool). This problem is
accentuated when crossing methodology boundaries (e.g. IDEF1X to UML).
-
MIMB focuses in moving the full model semantic between tools. The
graphical information is then reproduced by the auto-size and auto-layout
capabilities of the target tool. For example, CA ERwin may
automatically perform an auto-layout when importing an ERX or XML file, and
IBM Rational Rose provides a "Layout Diagram" and "Autosize
All" features in its "Tools" menu. Some OLAP/BI tools
offer more sophisticated autolayout features such as Cognos ReportNet FM
with an option to autolayout as a star schema.
Transformation Expression based Bridges
Parsing of Transformation Expressions in Import Bridges
Some MIMB Import Bridges depend on "Transformation Expression Parsing"
to capture the transformation semantic (i.e. ClassifierMap and FeatureMap).
Such parsing might be limited by the complexity of the transformation expression
(e.g. proprietary SQL language extensions).
MIMB bridges depending on "Transformation Expression Parsing"
include the following import bridges:
- Database (for SQL View transformations), such as:
- any database via JDBC
- IBM DB2 (via JDBC)
- Microsoft SQL Server (via JDBC)
- Oracle (via JDBC)
- Data modeling tools (for SQL View transformations), such as:
- CA ERwin
- Embarcadero ER/Studio
- IBM Rational Data Architect
- Sybase PowerDesigner PDM
- Telelogic (Popkin) System Architect
- Data Integration (DI) tools (for ETL Transformations), such as:
- Informatica PowerCenter
- IBM DataStage
- Microsoft SQL Server Integration Services (SSIS)
- Microsoft SQL Server Analysis Services (SSAS)
- Microsoft SQL Server Reporting Services (SSRS)
- Oracle Data Integrator (ODI)
- Oracle Warehouse Builder (OWB)
- Business Intelligence (BI design, OLAP, reporting) tools, such as:
- Business Objects Designer
- Business Objects Desktop Intelligence
- Business Objects Web Intelligence
- Cognos FrameworkManager
- Cognos ReportSudio
- IBM DB2 Cube Views
- Kalido
- Microsoft SQLServer Analysis Services
- Microsoft SQLServer Reporting Services
Conversions of Transformation Expressions in Export Bridges
Some MIMB Export Bridges depend on "Transformation Expression Conversions"
to restore the transformation semantic (ClassifierMap and FeatureMap).
Such conversion might be limited by the complexity of the transformation expression.
MIMB bridges depending on "Transformation Expression Conversions"
include the following export bridges:
- Data Integration (DI) tools (for ETL Transformations), such as:
- Informatica PowerCenter
- IBM DataStage
- Microsoft SQL Server Integration Services (SSIS)
- Oracle Data Integrator (ODI)
- Oracle Warehouse Builder (OWB)
- Business Intelligence (BI) design tools, such as:
- Business Objects Designer
- Cognos Framework Manager
- Microsoft SQL Server Analysis Services (SSAS)
- Oracle Business Intelligence (OBI)
![]() |
![]() |
Copyright © Meta Integration Technology, Inc. 1997-2009 All Rights Reserved.
Meta Integration® is a registered trademark of Meta Integration Technology, Inc.
All other trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
http://www.metaintegration.com
|