Category Archives: MicroStrategy Developer

Tips & Tricks # 14: How Attribute Roles Work in MicroStrategy

Airport_Gates

Attribute Roles

The support of attribute roles is among the most requested features in the schema/modeling area. It is the result of a common modeling practice where two or more attributes are defined using the same lookup table and column. When these attributes are placed on the same report, the result may return no data. To address this issue, a unique table name alias is required.
This Tips & Tricks post demonstrates a business scenario where two possible solutions are available in MicroStrategy:
  1. Explicit logical table aliasing can be used to generate correct report Structured Query Language (SQL).
  2. MicroStrategy SQL Generation Engine automatically detects tables where the same column is used to create two different attributes.

Business Case Scenario

The Airport Example

A user defines two attributes that have the same definition but play different roles in the business model. In this example, attribute Origin Airport and Destination Airport are defined using the same Lookup Table and Column (Airport_ID).

TN5800-072-0108A.gif

Both attributes share the same forms, or information about them (Description, Location, etc.). In the fact table, however, a separate column exists for each of their roles (Origin_Airport_ID and Destination_Airport_ID).

TN5800-072-0108B.gif

If the user places both attributes on a report to obtain the number of flights originated from ‘MIA’ and arrived at ‘LGA’, an empty result set is returned. The SQL statement tries to obtain the description of an airport that is both ‘MIA’ and ‘LGA’ at the same time (Airport_ID = “MIA” AND Airport_ID = “LGA”), thus generating an empty result set as shown below:
Example

 

NOTE: The SQL for this template is similar to the following:

TN5800-072-0108D.gif

Returning no data as explained previously:

 

SOLUTIONS

1. Explicit Table Alias Definition

The recommended way to model attribute roles in MicroStrategy is using explicit table aliases. This approach gives project architects direct control over the specific attributes to be treated as different roles, as well as their mappings to logical tables. This level of control can ensure consistent Engine behavior.

  1. In MicroStrategy Desktop Schema Objects/Tables folder, right-click on the Table and select ‘Create Table Alias’.

     

  2. A logical table alias is created for LU_AIRPORT as LU_AIRPORT (1). The alias name can be modified. In this example, the alias table is named ‘LU_AIRPORT_ALIAS’.
The two attributes, Origin Airport and Destination Airport, can each have its own lookup table.
In this example, the Destination Airport attribute uses LU_AIRPORT_ALIAS as the primary lookup table. Be sure to uncheck LU_AIRPORT as a source table so no join will be made.
Form Definition for the ID

Form Definition for the DESC

TN5800-072-0108J.gif

The Origin Airport attribute’s definition remains the same, using LU_AIRPORT as the source table for both of its forms. LU_AIRPORT_ALIAS is not checked as a source table.
Form Definition for the ID

TN5800-072-0108K.gif

Form Definition for the DESC

TN5800-072-0108L.gif

Report SQL

TN5800-072-0108M.gif

2. Automatic Attribute Role Recognition

A VLDB property is available at database instance level in the Query Optimizations folder, called “Engine Attribute Role Options.” The option is disabled by default. When enabled, the engine detects columns that support more than one attribute in the same table and automatically creates a separate alias in memory only for each attribute. These automatic aliases are not saved into the metadata and cannot be edited in MicroStrategy Desktop. Thus, while the engine attribute role option makes it more convenient to use attribute roles, it also represents a loss of control over the schema representation that is ultimately used for SQL generation. As a result, some logical schema designs may function incorrectly when using automatic role recognition.
Example

 

REPORT SQL

TN5800-072-0108G.gif

Enabling/Disabling ‘Automatic Attribute Role Recognition’

Attributes are considered candidates for the unique table name alias feature if their attribute forms are defined off the same column of a lookup table. Due to the specific nature of the modeling design described above, and that users may want to create two attributes of the same definition, automatic attribute role recognition is an optional setting.

The Very Large Database (VLDB) ‘Engine Attribute Role Options’ property can be found under Project Configuration/VLDB Properties/Query Optimizations folder in the VLDB Settings.

IMPORTANT NOTES:

1. Attribute roles are intended for lookup tables. Since automatic role recognition effectively splits a logical table into several virtual logical tables, the option should not be applied when a fact table supports more than one attribute on the same column. In that case, some levels of analysis will not be available (that is, reports may return the “Fact does not exist at a level that can support the requested analysis” error). In general there should be no need to have attribute roles on fact tables. However, if it is necessary in a specific scenario, explicit table aliases should be used.
2. The automatic detection option will not work if the attributes in the roles situation are in the same hierarchy, meaning that a child attribute is shared. In the example above, the two airport attributes do not have a common child attribute.
———————————————————————————
Source: Jaime Perez, TN6197: How do Attribute Roles Work in MicroStrategy 8.x?, MicroStrategy Knowledgebase, ‎08-30-2001.

MicroStrategy Report Optimization: Components of Performance

Readers:

Today, I am adding the second post in my MicroStrategy Report Optimization series. This will be a multi-part series (I will leave it open-ended so I can continue to add to it).

Today, we will look at the components that comprise performance.

Best Regards,

Michael

Source: MicroStrategy University, Deploying MicroStrategy High Performance BI, V9.3.1, MicroStrategy, Inc. September, 2013.

Components of Performance

There are five key layers or components that a typical BI query must go through. They are:

  • Caching Options
  • Data Transfer
  • System Architecture and Configuration
  • Client rendering or Data Presentation
  • Data Warehouse Access

The components above are not listed in any specific order of access during the execution of a query. The image below illustrates the five components.

The Components of High Performance

Caching and Intelligent Cubes

MicroStrategy’s memory technology is engineered to meet the increased demand for higher BI performance, which is driven by the rapid expansion of both data volumes and the number of BI users in organizations across industries. MicroStrategy accelerates performance by pre-calculating computations and placing the results into its memory acceleration engine to dramatically improve real-time query performance.

Data Transfer

Data transfer over one or more networks are a very important component of a BI implementation. A slow or poorly tuned network performance in any of those transfers will translate into poor performance from a report or a dashboard execution perspective.

System Architecture and Configuration

Successful BI applications accelerate user adoption and enhance productivity, resulting in demand for more users, data, and reports. MicroStrategy provides the ability to adapt quickly to constant changes and evolve along with business requirements. MicroStrategy Intelligence Server hs been proven in real-world scenarios to deliver the highest performance at scale with the fewest servers and minimum IT overhead.

Data Presentation

Dashboards provide graphical, executive views into KPIs, enabling quick business insights. MicroStrategy enables higher performing dashboards, averaging 30-45% faster execution and interactivity. Using new compression methods, MicroStrategy dashboards have a smaller footprint than ever before – up to to 55% smaller – resulting in faster delivery using less network bandwidth. Dashboards deliver ever more analysis and data for end-users.

Data Warehouse Access

High performance BI starts with optimizing SQL queries to retrieve results from the database as quickly as possible. BI performance is dependent largely on the time that the queries take to execute in the database. An average reporting request usually takes 40 seconds to complete, out of which 34 seconds, or 85% of the query time, is spent executing in the database.

Therefore, it is critical to optimize report queries to reduce database execution time.

Tips & Tricks #4: How to Create N-Level Deep Nested Prompts in MicroStrategy Developer (Desktop)

This is something that I actually had the opportunity to use this week. It really came in handy and helped satisfy my client’s requirements.

Just a reminder as we discuss this tip, I am using MicroStrategy v9.4.1 and MicroStrategy Developer. Developer is the new name for MicroStrategy Desktop as of v9.4.1

This example demonstrates how to create a 3-level deep nested prompt that will prompt the user to select a year, then a quarter within that year, then a month within that quarter.

Prompt-in-prompt is a feature in which the answer to one prompt is used to define another prompt. This feature is only implemented for element list prompts. The following steps describes how to achieve this.

Create the Year Prompt

  1. Create the highest level filter first. This is a filter which contains a prompt on an attribute element list. Create a filter on the attribute “Year” and click “Prompt“.
  2. Click “prompt on attribute element list” and then click “Next” through the rest of the screens to accept the default values.
  3. Do not set any additional conditions. Save the filter as “Year Filter“.

Trick4-1

Trick4-2

From this level on, each filter will contain both a prompt on an element list and will have its element list filtered by the filter created one level above it. There is no limit to the number of such filters that can be layered.

Create the Quarter Prompt

  1. Create a filter on attribute “Quarter” and click “Prompt“.
  2. Select “Use a filter to reduce the number of elements” and select the “Year Filter” created in the previous step.
  3. Save this filter as “Quarter Filter” .

Trick4-3

Create the Month Prompt

  1. Follow the same basic procedure as above to create a Month filter. Create a filter on attribute “Month“.
  2. Click “Prompt“.
  3. Select “Use a filter to reduce the number of elements” and select the “Quarter Filter” created in the previous step.
  4. Save this filter as “Month Filter” .

Trick4-4

Try it Out

Place only the lowest level filter in the filter section of the report. In this case, the “Month Filter” will be placed in the filter section.

When the report is executed, it will prompt for Year, then for Quarters in the selected Year, then for Months in the selected Quarter, as shown in the following sequence of screen shots.

Trick4-5

Trick4-6

Trick4-7

Tips & Tricks #3: How to Define Custom Subtotal Displays in MicroStrategy Desktop

By default, when users apply subtotals in a report, the name of the subtotal is displayed in the subtotal line items that appear in the report. Users can use custom subtotals to give more control over the characteristics of a subtotal. Custom subtotals allow users to define custom subtotal line items that appear on the reports.

Users can make the subtotal name dynamic by typing special characters in the subtotal name field as listed in the following table.

Trick2-1

Trick2-2

To define a specific subtotal displays for a report like the one shown above, follow the steps below:

  1. Select Subtotals from the Data menu. The Subtotals dialog box opens. Clear the Totals check box to remove the standard subtotals.
  2. Click Advanced.
  3. Click New to create a custom subtotal.
  4. Type the following for the name: “Total for the #P #0”. Remember that P displays the parent attribute and 0 (the number zero, not the letter o) displays all the forms of the parent attribute. In this case, only one form exists for each, as shown below.

Trick2-3

 

All the metrics on the report are listed. Users can select the subtotal function to use for each. Total is correct for all of the metrics.

  1. Check the Total for the #P #0 subtotal (shown below).
  2. Click Advanced.
  3. Select Across level and then select the Region and the Employee as the levels.
  4. Click OK to save the new subtotal.
  5. Click OK to return to the Subtotals dialog box.
  6. Click OK.

Trick2-4

The report should now look like this.

Trick2-5