 |
|
|||||||
 |
   
|
|
||||||
|
|
|||||||
|
|
|
||||||
 |
 |
 |
 |
|
 |
|
 |
 |
| Vendor | MicroStrategy |
| Tool Name | Intelligence Server |
| Tool Version | 7.0 to 9.0 |
| Tool Web Site | http://www.microstrategy.com/Software/index.asp |
| Supported Methodology | [Business Intelligence] Multi-Model, BI Design (RDBMS Source, Dimensional Target, Transformation Lineage), BI Report (Dimensional Source, Report Structure) via COM API |
Import tool: MicroStrategy Intelligence Server 7.0 to 9.0 (http://www.microstrategy.com/Software/index.asp)
Import interface: [Business Intelligence] Multi-Model, BI Design (RDBMS Source, Dimensional Target, Transformation Lineage), BI Report (Dimensional Source, Report Structure) via COM API from Import bridge: 'MicroStrategy' 7.0.3 - 2012-02-02 21:56:06
The bridge relies on the MicroStrategy Intelligence Server COM/OLE API to import metadata. Therefore, a supported version of MicroStrategy must be properly installed (and able to open the metadata to be imported) on the same computer where the bridge is executed.
Please note, MicroStrategy database corruption may be a problem for the proper function of this bridge. Such corruption may be reported in the MicroStrategy log file: C:\Program Files\Common Files\MicroStrategy\Log\DSSErrors.log. MicroStrategy support is aware of this issue and provides a ScanMD program which may be used to cleanup these errors. Be sure to always run the ScanMD program before using this bridge.
METAMODEL INFORMATION
Prompts:
The bridge metamodel has support for (data) Prompts as subtypes of Classifier and Feature. Data prompts are the kind of prompts that specify a piece of data from a table or dimension. MicroStrategy also support metadata prompts, which, for example, allow choosing a measure or a filter to include in a report. The bridge metamodel then models prompts as Classifier and Feature, and thus does not completely represent the lineage for metadata prompts that depend on objects that are not Classifiers or Features.
Documents:
MicroStrategy Documents and HTML Documents can use/refer to individual reports. The bridge metamodel has complete support for this notion, including a reference link between any bridge metamodel ReportItem object, such as ReportChart or ReportTable. This ability simplifies the determination of which report is referenced from which document. Since non-HTML documents may also have fields that display data directly, in addition to referring to reports, the document lineage algorithm should be:
1. Identify the document fields and associated attributes
2. Identify the referenced reports
3. Trace lineage for all these objects.
Database Connections:
This bridge does not import database connection or user information.
Dimensions:
This bridge imports MicroStrategy logical tables as Dimensions. MicroStrategy logical tables do not necessarily represent physical tables. Instead, MicroStrategy allow one to reverse engineer and rename a logical table. In addition, multiple logical tables can represent the same physical table. Finally, logical tables carry measures and levels that are dimensional notions.
Reports:
The bridge does not differentiate between user created reports and reports that are created automatically by MicroStrategy with a new project. They are treated the same, and thus reports that you may not be expecting will be imported.
SUPPORT
When reporting issues with the bridge, it is generally necessary for the support staff to reproduce the behavior and thus you must provide the original MicroStrategy metadata. The MicroStrategy Intelligence Server uses a relational database to store the projects' metadata. Use your RDBMS utilities to create a database backup. Please provide the database backup file and the MicroStrategy user name/password used to login.
Be sure to always run the ScanMD program (referred to above) before creating this backup file.
| Parameter Name | Description | Type | Values | Default | Scope | |||||||||||
| Version | Select the version of MicroStrategy. | ENUMERATED |
|
Auto detect | ||||||||||||
| Login Project Source name | Enter the name of the MicroStrategy Project Source to connect to. A Project Source is a connection to a repository that is located on a local or remote Intelligence Server which holds connectivity to a data warehouse and contains a number of metadata Projects that operate on this data warehouse. The list of Project Sources that are accessible from this computer is stored in the Windows registry. To connect to a remote Intelligence Server that has not yet been registered on the local computer, when a Project Source pointing to this Intelligence Server is not yet defined, create this Project Source first in MicroStrategy. |
REPOSITORY_MODEL | MicroStrategy Tutorial (Direct) | Mandatory | ||||||||||||
| Login Project name | Enter the name of the Project that you want to connect to in the selected Project Source. |
REPOSITORY_MODEL | MicroStrategy Tutorial | Mandatory | ||||||||||||
| Login user | Enter the user name used to connect to the Project Source. This import bridge is warrantied to be read only and will never affect the Repository contents. It is therefore safe to attempt the initial metadata harvesting as 'Administrator' in order to ensure that the entire Repository content is extracted without any access permission issue. Eventually, the administrator can set up a 'read only' user. Refer to the tool documentation on permissions and security for more details. |
STRING | Administrator | Mandatory | ||||||||||||
| Login password | Enter the password used to connect to the Project Source. |
PASSWORD | ||||||||||||||
| Default Language | Specify the language you would like to use. Only MicroStrategy versions 9.x support multiple languages. |
ENUMERATED |
|
English (United States) | ||||||||||||
| Data model Tables design level | This option controls the design level of the imported tables. It is particularly relevant when exporting metadata to a target tool which supports two views of the model: a logical view and a physical view. Some Data Modeling tools support this concept, where you can decide if a table appears both as a physical table and as a logical entity. Some Business Intelligence tools also support this concept, where you can decide if a table appears both in the physical model and in the business view of the model. 'Logical and physical' - Tables will appear in both in the logical view and in the physical view of the model. 'Physical' - Tables will appear only in the physical view of the model (default). |
ENUMERATED |
|
Physical | ||||||||||||
| Data model reverse engineer Joins | Select this option to transform the simple SQL joins of a model into foreign key relationships. This option is specially useful if you plan to export the model to a tool that only support structural relational metadata, such as a database design tool. 'True' - Transform SQL joins into foreign key relationships. 'False' - Do not transform SQL joins into foreign key relationships. If an SQL join carries a complex Where clause for which it does not make sense to infer the definition of a foreign key, the clause is imported as a join, even if this option selected. |
BOOLEAN | False | |||||||||||||
| Dimensional model reverse engineering | Select the algorithm to reverse engineer dimensional objects into relational objects. This algorithm is most useful when converting a BI/OLAP model to a destination tool that only supports relational metadata. In this case the business metadata from the BI/OLAP model will be applied to the relational objects. This algorithm will reverse-engineer the following properties: - the dimension name, description and role (fact or dimension) to the underlying table, - the attribute or measure name, description and datatype to the underlying column, These properties may be transferred if there is a direct match between the dimensional object to the relational object. If there is no direct match, this algorithm doesn't apply (if a measure maps to a set of columns with a complex expression for example). - 'Disabled' - no reverse engineering - 'Enabled (business names)' - reverse-engineer and migrate the dimension business names to the relational names - 'Enabled (physical names)' - reverse-engineer and migrate the dimension physical names to the relational names - 'Enabled (preserve names)' - reverse-engineer but the relational names are preserved. |
ENUMERATED |
|
Disabled |
| Meta Integration Repository (MIR) Metamodel (based on the OMG CWM standard) |
"MicroStrategy 7.0 to 9.0" Metamodel |
Mapping Comments |
| Argument | Function Parameter | |
| Comment | Comments | |
| Description | Description | |
| Name | Name | |
| NativeId | ID | MicroStrategy object ID |
| Association | Keys and referential integrity constraints are not persisted in the metadata | |
| AssociationRole | Keys and referential integrity constraints are not persisted in the metadata | |
| AssociationRoleNameMap | Keys and referential integrity constraints are not persisted in the metadata | |
| Attribute | Warehouse Table Column | |
| Comment | Comments | |
| Description | Description | |
| DesignLevel | as defined by the "Table Logical information" bridge option | |
| Name | Name | |
| NativeId | ID | MicroStrategy object ID |
| Position | as returned by the API | |
| BaseType | Datatype | |
| DataType | See datatype conversion array | |
| Name | Derived from the datatype | |
| NativeId | ID | MicroStrategy object ID |
| PhysicalName | Derived from the datatype | |
| CandidateKey | Keys and referential integrity constraints are not persisted in the metadata | |
| Class | Warehouse Table | |
| Comment | Comments | |
| CppClassType | Set to ENTITY | |
| CppPersistent | Set to True | |
| Description | Description | |
| DesignLevel | as defined by the "Table Logical information" bridge option | |
| Name | Name | |
| NativeId | ID | MicroStrategy object ID |
| ClassifierMap | Used to hold the lineage metadata | |
| NativeId | ID | MicroStrategy object ID |
| Condition | LogicalTable Lookup, Filter | Indicated how to perform the join between the LogicalTables Conditions are also created when importing Filters |
| DatabaseSchema | Warehouse Table | |
| Name | Namespace | |
| NativeId | ID | MicroStrategy object ID |
| DerivedType | Datatype | |
| DataType | DataType | See datatype conversion array |
| Length | Length in bytes | |
| Name | Derived from the datatype | |
| NativeId | ID | MicroStrategy object ID |
| PhysicalName | Derived from the datatype | |
| Scale | Scale | |
| DesignPackage | Folder | The imported MicroStrategy objects are placed in their respective folder |
| Comment | Comments | |
| Description | Description | |
| Name | Name | |
| NativeId | ID | MicroStrategy object ID |
| UserDefined | Set to TRUE | |
| Dimension | LogicalTable, Attribute, Fact, Metric | Each LogicalTable is imported as a Dimension Dimensions are also created to act as Classifier for Attributes, Facts and Metrics |
| Comment | Comments | |
| Description | Description | |
| Name | Name | |
| NativeId | ID | MicroStrategy object ID |
| Type | set to FACT if the logical table contains facts, REGULAR otherwise | |
| UserDefined | set to TRUE | |
| DimensionAttribute | LogicalTable BaseAttributeForm | Each BaseAttributeForm (implementation of an AttributeForm in the context of a Logical Table) is imported as DimensionAttribute |
| Comment | Comments | |
| Description | AttributeFormDescription | |
| Name | "AttributeName (AttributeFormName)" | |
| NativeId | ID | MicroStrategy object ID |
| Position | as returned by the API | |
| DrillPath | Hierarchy | Hierarchies are imported as MIRDrillPath as they can have many top levels (entry points) and they can span across levels of different MIRDimensions |
| Comment | Comments | |
| Description | Description | |
| Name | Name | |
| NativeId | ID | MicroStrategy object ID |
| DrillPathLevelAssociation | Hierarchy | Used to connect the Levels used in a Hierarchy |
| NativeId | ID | MicroStrategy object ID |
| Position | irrelevant for ragged hierarchies | |
| FeatureMap | AttributeForm, Fact | Used to hold the lineage and expressions metadata |
| NativeId | ID | MicroStrategy object ID |
| Operation | Expression text | empty if there is direct mapping to a source feature |
| OperationDescription | Expression text | |
| Filter | Filter, CustomGroup, Security Filter | |
| Comment | Comments | |
| Description | Description | |
| Name | Name | |
| NativeId | ID | MicroStrategy object ID |
| ForeignKey | Keys and referential integrity constraints are not persisted in the metadata | |
| Join | LogicalTable Lookup | Joins are imported based on the lookup LogicalTable of each AttributeForm |
| JoinRole | LogicalTable Lookup | Connects two LogicalTables involved in a Join |
| Level | Attribute | Attributes are imported as Levels |
| Comment | Comments | |
| Description | Description | |
| Name | Name | |
| NativeId | ID | MicroStrategy object ID |
| LevelAssociation | AttributeRelationship | Specifies the parent-child relationships between levels, used in DrillPaths via DrillPathLevelAssociation objects |
| LevelAttribute | AttributeForm | |
| Comment | Comments | |
| Description | Description | |
| Name | Name | |
| NativeId | ID | MicroStrategy object ID |
| Measure | LogicalTable FactInfo, Fact, Metric | Each Fact is imported as Measure Each FactInfo (implementation of a Fact in the context of a Logical Table) is imported as Measure Each Metric is imported as a Measure |
| Comment | Comments | |
| Description | Description | |
| Name | Name | |
| NativeId | ID | MicroStrategy object ID |
| Position | Position of the FactInfo in the LogicalTable, as returned by the API | |
| Model | Project | The project is accessed via a Data Source Name pointing to a MicroStrategy Intelligence Server |
| Comment | Comments | |
| Description | Description | |
| Name | Name | |
| NativeId | ID | MicroStrategy object ID |
| Operation | Function | Each Function is imported as an Operation |
| Comment | Comments | |
| Description | Description | |
| Name | Name | |
| NativeId | ID | MicroStrategy object ID |
| Prompt | Prompt | |
| Name | Name | |
| Question | Display Description / Meaning | |
| PromptAnswer | Prompt | |
| Comment | Comments | |
| Description | Description | |
| Name | Name | |
| NativeId | ID | |
| Report | Report, Document | |
| Comment | Comments | |
| Description | Description | |
| Name | Name | |
| ReportAttribute | Attribute, Metric, Limit, Consolidation, Subtotal | Represents objects used in the report |
| Name | Name | |
| ReportAxis | Report Axis | Represent the report Vertical, Horizontal and Page axis |
| ReportChart | Chart Report | |
| ReportDataSet | Attribute, Metric, Limit, Consolidation, Subtotal | Represents objects used in the report, and how they are grouped |
| Name | Name | |
| ReportField | Report template element | |
| ReportPage | Report | |
| ReportPageBody | Document Body | |
| ReportPageFooter | Document Footer | |
| ReportPageHeader | Document Header | |
| ReportTable | Grid Report | |
| ReportText | Text field | |
| Value | textual value | |
| Transformation | One default transformation is created to hold the traceability information | |
| NativeId | ID | MicroStrategy object ID |
Last updated on Thu, 2 Feb 2012 22:05:49
