Category Archives: MicroStrategy Engine

Interview Question #10: Placing Hierarchies in Report Template in MicroStrategy

Question

Which of the following about placing hierarchies in the report template is true?

A. You can only place one hierarchy in the report template.

B. The report level is always resolved to the lowest level attribute in the hierarchy.

C. You can use user hierarchies as well as the System Hierarchy on the template.

D. For the SQL Engine to resolve the level of the report, one or more attributes from the same hierarchy should be referenced in the report filter.

E. Both B and D.

 

 

 

 

 

Answer

D. For the SQL Engine to resolve the level of the report, one or more attributes from the same hierarchy should be referenced in the report filter.

 

Why the others are false

A. You can only place one hierarchy in the report template. You can place any number on the report.

B. The report level is always resolved to the lowest level attribute in the hierarchy. Since the hierarchy contains several attributes, the SQL Engine does not automatically know which attribute to place on the result set.

C. You can use user hierarchies as well as the System Hierarchy on the template. Cannot use System Hierarchy.

E. Both B and D. B is False.

MicroStrategy Course Where You Will Learn About This Topic

MicroStrategy Engine Essentials Course

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.

Bryan Brandow: Triggering Cubes & Extracts using Tableau or MicroStrategy

trigger-720x340

bryan-headshots-004Bryan Brandow (photo, right), a Data Engineering Manager for a large social media company, is one of my favorite bloggers out their in regards to thought leadership and digging deep into the technical aspects of Tableau and MicroStrategy. Bryan just blogged about triggering cubes and extracts on his blog. Here is a brief synopsis.

One of the functions that never seems to be included in BI tools is an easy way to kick off an application cache job once your ETL is finished. MicroStrategy’s Cubes and Tableau’s Extracts both rely on manual or time based refresh schedules, but this leaves you in a position where your data will land in the database and you’ll either have a large gap before the dashboard is updated or you’ll be refreshing constantly and wasting lots of system resources. They both come with command line tools for kicking off a refresh, but then it’s up to you to figure out how to link your ETL jobs to call these commands. What follows is a solution that works in my environment and will probably work for yours as well. There are of course a lot of ways for your ETL tool to tell your BI tool that it’s time to refresh a cache, but this is my take on it. You won’t find a download-and-install software package here since everyone’s environment is different, but you will find ample blueprints and examples for how to build your own for your platform and for whatever BI tool you use (from what I’ve observed, this setup is fairly common). Trigger was first demoed at the Tableau Conference 2014. You can jump to the Trigger demo here.

I recommend you click on the link above and give his blog post a full read. It is well worth it.

Best regards,

Michael

Tips & Tricks #12: How to Troubleshoot Cross Joins in SQL Reports for the SQL Generation Engine 9.x

MicroStrategy Community Banner

Readers:

In my last blog post, I blogged about the new MicroStrategy Community. Jaime Perez, VP of Worldwide Customer Services, and his crew have come up with a better way for us to engage with MicroStrategy as well as his team.

Speaking of Jaime, last June, he posted this great tip on the MicroStrategy Knowledgebase site as a TechNote. I am reblogging it since it is one of the most frequent questions I get asked and I find it an extremely useful Tip & Trick. Also, this will give you an idea of the great stuff being posted in the MicroStrategy Community.

Best Regards,

Michael

MicroStrategy and Cross Joins

In some scenarios, one may encounter cross joins in the SQL View of a standard, SQL Report in MicroStrategy.  Cross joins appear when two tables do not have any common key attributes between them in which they can inner join.  As a result, the two tables essentially combine together to create one table that has all the data from both tables, but this results in poorer performance with a common effect of increased execution times.  Sometimes these execution times, and performance hits, can be very severe.  Therefore, it is important to understand some simple steps that can be performed to resolve a cross join, as well as some steps to understand why it may be appearing in the SQL View of the report.

One common occurrence of a cross join is when a report contains at least two unrelated attributes in the grid, and no metrics are present in order to relate the unrelated attributes via a fact table.  Such a occurrence can be resolved in a few ways:

  1. Create a relationship filter, set the output level as the unrelated attributes (or the entire report level), and then relate these by a Logical Table object
  2. Create a relationship filter, set the output level as the unrelated attributes (or the entire report level), and then relate these by a Fact object
  3. Add a metric to the report that uses a fact from a table in which both attributes can inner join to

This provides a pathway from the fact table to the lookup tables in which the unrelated attributes are sourced from.  The result is an inner join between the fact table and the lookup tables, which resolves the cross join between the two unrelated lookup tables.

Options 1 and 2 provide a means in which the report template can remain as only attributes, whereas Option 3 would have a metric on the report.  Option 3 may not be desired if a metric does not want to be placed on the report.  Keep in mind that other techniques can also be employed to have the metric on the report, but formatted to be hidden from display.

More common scenarios include cross joins between a fact table and a lookup table, and are typically surprising to a developer.  These situations can be a bit more tricky to troubleshoot and resolve, but here are a few techniques that can be employed to try to resolve the issue:

  1. In SQL View look at where the cross join appears, and between which tables the cross join appears
  2. Open up those tables in the Table Editor by navigating to the Schema Objects\Tables folder, and double-clicking the tables
  3. Select the Logical View Tab of both tables to see all the logical objects mapped to the table
  4. Take note of which attributes have a key icon beside them
  5. These key attributes denote attributes at the lowest level of their hierarchy presently mapped to the table and/or attributes that are in their own hierarchy (meaning they have no parents or children)
  6. The SQL Engine will join 2 tables on common key attributes only, so if none of the key attributes on either table exist on both tables, then a cross join should appear

This means that just because a Region attribute exists on Table_A and a Region attribute exists on Table_B does not necessarily mean that the SQL Engine will join on Region.  If Region has its child attribute on the table, then that attribute should be the key as it is the lowest level attribute of its particular hierarchy mapped to the table.  If Region exists on both tables, and is also a key attribute on both tables, then an inner join should take place on Region.

This essentially means that one can find a cross join, investigate the tables in which it appears, and verify if at least 1 common key attribute exists between the tables.  If not, then that should be the first path to investigate because a cross join is correct in that scenario.

Video

You can find a detailed video on how this issue is reproduced and resolved here: Tech Note 71019 . Steps to reproduce and resolve

Note

MicroStrategy Technical Support can assist with resolving cross joins in a specific report, however caution should be taken when resolving such issues.  In some scenarios, the cross join is resolved through modifications to the schema objects, which can have a ripple effect to all other reports in an environment.  For example, if a relationship is changed in the Region attribute to resolve a cross join in one report, this change will be reflected in all other reports that use Region, and potentially the hierarchy in which Region belongs.  As a result, the SQL View of one report will have the cross join resolved, but the SQL may have changed in other reports using Region or its related attributes.  This may or may not be desired.  MicroStrategy Technical Support may not be able to fully understand the impact of such a schema change to the data model, so before a change is made to the data model the consequences of such a change should be fully understood by the developer, and any changes made to the schema should be recorded.

References

[1] Jaime Perez, TN47356: How to troubleshoot cross joins in SQL Reports for the SQL Generation Engine 9.x, MicroStrategy Community, 06/24/2014, http://community.microstrategy.com/t5/Architect/TN47356-How-to-troubleshoot-cross-joins-in-SQL-Reports-for-the/ta-p/196989.

[2] MicroStrrategy Knowledgebase, Tech Note 71019 . Steps to reproduce and resolve,

Bryan’s BI Blog: MicroStrategy vs Tableau

Readers:

Bryan BrandowBryan Brandow, has posted his second new post on his new blog, Bryan’s BI Blog and it is a doozy. Bryan does an in-depth comparison of MicroStrategy vs. Tableau.

Here is a link to the MicroStrategy vs. Tableau post.

Best Regards,

Michael

 

How Data Blending Affects the Analytical Engine’s Behavior in MicroStrategy (Part 7)

MicroStrategy Analytics PlatformWith the release of MicroStrategy Analytics Enterprise 9.4.1, the Analytical Engine logic has been enhanced with respect to joining data from multiple datasets in a Report Services Document. One of the features that is available with this release is the ability to use objects (e.g., attributes, metrics) from multiple datasets in a single grid in a document.

If an attribute on a grid has elements that can be obtained from multiple datasets used in the document, the elements displayed will be from the global lookup table. Additionally, if one or more of the datasets containing the attribute has missing attribute form data or has different attribute form from the other datasets, the Analytical Engine will follow the rules noted below to compose the final output:

Rule 1:

If there is attribute form with null value, the Analytical Engine will use the non-null form value from other datasets instead of the null form.

Rule 2:

If several datasets have different attribute form information for the attribute element, the Analytical Engine will use the attribute form from the biggest dataset.

Rule 3:

If several datasets have different attribute form information for the attribute element, and those datasets have same number of rows, the Analytical Engine will use the first dataset in the document for the attribute form value (according to the dataset adding sequence).

NOTE: Users should note that the rules are applied for each individual attribute element in the result at the row level rather than at the dataset level.

Example 1:

Users may consider the following datasets – C01 is a dataset with Customer City, Customer and Order:

Part 7 - 1a

 

C02 is a dataset with Customer, Order and a profit metric. Users may note that the Customer attribute is missing the DESC form in the second dataset:

Part 7 - 2a

If a Report Services Document is built with both these datasets, and the attributes are placed on a grid, the following results may be seen. As noted in Rule 1, the Analytical Engine will display the non-Null values from C01 for the Customer attribute elements:

Part 7 - 3a

Example 2:

Now users may consider a different dataset as C02 – similar to the initial dataset, but here the Customer name (DESC) form contains values instead of NULLs. This time the values for the attributes are not consistent – see that Customer ID ‘1’ has different values for the DESC form for different Orders (1 & 6).

Customer Name Customer ID Order Profit
Customer D 1 1 100
Customer B 2 2 200
Customer C 3 3 300
Xia D 4 4 400
Kris Du 5 5 500
Customer A 1 6 610
Customer E 2 7 720
Customer F 6 8 860
Customer G 7 9 970
Customer H 8 10 1080

If a report is built for this dataset users will observe that the first attribute element value in the dataset is used as as the DESC form for the Orders 1 & 6 even if the value is different in subsequent rows (this is the same as previous Analytical Engine behavior). Part 7 - 5

When these datasets are used in the grid in a Report Services Document, the Analytical Engine will choose the attribute element values from dataset C02 to display in the attribute element values from. This is because of Rule 2 explained above.

Part 7 - 6a

Example 3:

Consider the following dataset:

Customer Name Customer ID Order Profit
Customer D 1 1 100
Customer E 2 7 720
Xia D 4 4 400
Kris Du 5 5 500
Customer G 7 9 970

A report built off this dataset appears as follows:

Part 7 - 8a

After replacing the dataset ‘C02‘ from the previous example with the new dataset, the following results are seen. As noted in Rule 3, because both C01 an C02 have the same number of rows, the elements displayed for the Customer attribute will be filled from from the first dataset to be added to the document – in this case C01. However for the first row in the results, where there is no corresponding customer in the dataset C01, Rule 1 will be applied and instead of a NULL value, the non-null Customer Name field ‘Customer G’ is picked from C02. (Rules are applied at the individual element level).

Part 7 - 9a

Next: Why are some metric values blank in documents using multiple datasets in MicroStrategy Analytics Enterprise 9.4.1

———————————————————————————-

References:

[1] MicroStrategy Knowledgebase, Engine behavior for grids on a Report Services Document or dashboard with multiple datasets where some attribute forms are missing or have different values the datasets in MicroStrategy Analytics Enterprise 9.4.1 and newer releases, TN Key: 45463, 03/13/2014, https://resource.microstrategy.com/support/mainsearch.aspx.

NOTE: You may need to register to view MicroStrategy’s Knowledgebase.

Interview Question #4: Slowly Changing Dimensions

Question

Which type of Slowly Changing Dimension (SCD) would you use if your data was time dependent and you do not require historical comparisons?

A.  Like vs. Like

B.  As Is vs. As Was (Type II)

C.  As Is vs. As Is (Type I)

D.  As Is vs. As Was

Answer

C.   As Is vs. As Is (Type I) involves analyzing all data in accordance with the attribute relationships as they currently exist.

Regardless of how relationships change over time, you aggregate and qualify all data (current and historical) based on the current values in the lookup and relationship tables. If aggregate tables exist, you either have to modify how the values roll up to reflect the current attribute relationships, or you have to ignore the tables when you perform this type of analysis.

MicroStrategy Course Where You Will Learn About This Topic

MicroStrategy Advanced Data Warehousing Course

 

Interview Question #1: MicroStrategy Generated SQL

Readers:

Today, I am going to introduce a new blog entry related to Interview Questions. I have interviewed a lot of people for various MicroStrategy positions over the years and thought I would share with you some of the questions I have asked or have been asked on interviews. I will try to add two interview questions a month.

Best regards,

Michael

Question

Why does the SQL you created using MicroStrategy (assume it generated a single-pass SQL) produce different results than when you run it directly against a database?

Answer

There may have been steps that required the analytical engine which would only occur on the Intelligence Server and not when you directly run SQL against a database.

Tips & Tricks #8: MicroStrategy VLDB Properties Hierarchy

Very Large DataBase

VLDB is an acronym for Very Large DataBase. VLDB properties enable MicroStrategy products to take advantage of the unique optimizations that different databases offer. There are over 100 settings that affect how the MicroStrategy Engine handles functions such as:

  • Join options (star join, full outer join, and so forth)
  • Metric calculation options (null and zero check during division operations)
  • Query optimizations (subqueries and driving tables)
  • Table types (temporary or derived tables)

These settings, along with other settings, directly modify how the SQL Engine writes SQL against the warehouse.VLDB Hierarchy

VLDB Properties

The diagram above illustrates how VLDB properties that are set for one level will take precedence over those set for another level.

DBMS Level

The default value for every VLDB property is based on the database type of the warehouse and is written into the metadata at the time that you configure the project. MicroStrategy supplies the default values for the DBMS level, which are optimized for the database type and version.

The VLDB properties values are inherited from the DBMS object when you have not changed any VLDB properties (and all the Use default inherited value check boxes are selected for every VLDB property in the VLDB Properties Editor).

Database Instance Level/Project Level

In the MicroStrategy platform, the Database Instance level and Project level settings are merged together (or considered to be one overall level), because only one database instance can be applied for each project. Also, the Project level settings contain the Analytical Engine-related VLDB properties and the MDX VLDB properties.

Yield Red SignWhen you change a VLDB property setting at the database instance or project level, you must restart the Intelligence Server for the MicroStrategy Engine to read the latest schema information from the metadata.

Report Level

Properties you set at the report level override properties at every other level. For example, if a VLDB property is set to one particular value for a report and the same VLDB property is set to a different value for a metric on that report, the report-level setting takes precedence over the metric-level setting for that VLDB property.

Template Level

Values set at the template level override those at the metric, database instance, and DBMS levels.

Attribute/Transformation Level

There are only a select number of VLDB properties available within the Attribute Editor and the Transformation Editor. If you alter these properties, they automatically override the values for the same properties at the database instance and DBMS levels.

Use default inherited value Check Box 

By default, all objects in a project, including the project itself, have the Use default inherited value check box enabled for all of the VLDB properties (see screenshot below). As mentioned earlier, when you have not changed any VLDB properties and all the Use default inherited value check boxes are selected for every VLDB property in the VLDB Properties Editor, the values are inherited from the DBMS level. If you customize the settings for a VLDB property at  particular object’s level (whether it is a metric, template, project, etc.), any objects above it (in the VLDB Hierarchy) automatically accept the custom setting as the inherited value.

Tip 8-2

Example: Sub Query Type VLDB Property

As an example, let’s review the Sub Query Type VLDB property.

Suppose you define the Sub Query Type VLDB property at the template level to use temporary tables instead of sub queries. You create a new report using the template. When you view the Sub Query Type VLDB property at the report level, you notice that the same value (use Temporary Table) is automatically inherited at the report level. The report inherits the template’s VLDB value because the Use default inherited value check box is enabled (and the check box even lists “Template level” as the level from which the report inherited the custom value). This behavior of inheriting the custom value (as long as long as the Use default inherited value check box is enabled) occurs in a recursive fashion all the way to the DBMS object.

Tip8-3