MicroStrategy ONE
Mapping MDX Cube Data to Project Attributes
After you have imported MDX cubes, you can use the automatically generated managed object attributes to define the levels of your MDX cube data. Alternatively, you can map MDX cube data to existing attributes in the MicroStrategy project that are part of the relational schema. Mapping MDX cube data in this way replaces the managed objects that are used to represent MDX cube data with attributes in the MicroStrategy project. Mapping MDX cube data to attributes in a MicroStrategy project that are part of a relational schema has the following benefits:
- Report designers can integrate the logical model of the project with the data in imported MDX cubes, thus creating a relation between the two sets of data. Data can then be joined across sources within a Report Services document. For example, if an MDX cube report and a standard report both use the same Year attribute, then Year can be used to group the data within a document.
- Administrators can search for dependents and manage access control lists (ACLs) for attributes that map both to the data warehouse and an MDX cube source.
- MicroStrategy security filters can be applied to attributes in MDX cube reports. For example, you can map an MDX cube level to the Year attribute in your project. If a user with a security filter on Year runs the MDX cube report that contains Year, the security filter on Year is applied.
- With the MicroStrategy MultiSource Option, MDX cube reports can be used to filter other standard reports in MicroStrategy. See Using MDX Cube Reports to Filter Other Reports for details.
Metrics and prompts mapped to MDX cube data cannot be mapped to objects that are part of a relational schema. These metrics and prompts can only be mapped to managed object metrics and prompts that are mapped to MDX cube source data. For example, three MDX cubes can share the same managed object metric named Revenue. However, none of these metrics can share the same object as a Revenue metric mapped to relational data in the project. Sharing metrics between MDX cubes is required if you want to allow MDX cube reports to be able to switch the MDX cube that is used as the source of its data, as described in Switching the MDX Cube for an MDX Cube Report.
MDX cubes connected to SAP BW as an MDX cube source can contain variables. These variables are converted into prompts when imported into MicroStrategy (see Relating Objects from SAP BW to MicroStrategy for conversion information). If multiple MDX cubes contain the same variable, one MicroStrategy prompt can be mapped to more than one variable across MDX cubes. This enables a prompt to be displayed and answered only once when executing a Report Services document that uses these MDX cubes. For steps to map one prompt to variables in multiple MDX cubes, see Mapping SAP BW Variables to MicroStrategy Prompts.
Example 1: Unmapped MDX cube
You can map managed object attributes for your MDX cubes instead of using project attributes. This feature allows you to quickly start creating reports for your MDX cube data.
The drawback of an MDX cube mapped only to managed objects is that you cannot create a relation between your MDX cube data and other data in your project connected to a data source other than your MDX cube source. Since this relation is not created, you cannot join data from these different sources in a Report Services document and you cannot support project security filters in MDX cube reports.
The diagram below shows two logical models. The one on the left exists in a specific MDX cube, and the one on the right exists in a MicroStrategy project. Although both models have a Time hierarchy, none of the individual attributes are shared.
Example 2: Partially mapped MDX cube
After an MDX cube source has been included in MicroStrategy as an MDX cube, you can map the attributes within the MDX cube to existing project attributes.
The example in the diagram below also shows two logical models. The difference between this example and the example above is that the MDX cube has been partially mapped so that it shares the attributes Year, Quarter, and Month. With this technique, you can create a Report Services document that contains Year, Quarter, and Month information for both your data warehouse and MDX cube source. In addition, any security filters for Year, Quarter, and Month are applied to MDX cube reports that include these mapped attributes.
The dimensions of MDX cubes are always shared. Therefore, when a level is mapped, that change applies to all the MDX cubes that share that dimension. In this case, changes to the Time dimension apply to MDX cubes in the project that contain this dimension.