Skip to main content

MSTR Inventory metrics or No Aggregate metrics

TN20363: How do non-aggregatable metrics work in MicroStrategy SQL Generation Engine 9.x?


https://success.microstrategy.com/t5/Architect/TN20363-How-do-non-aggregatable-metrics-work-in-MicroStrategy/ta-p/180533

Some kinds of fact data are not valid for aggregation with respect to one or more dimensions. The classic example is inventory with respect to time. The fact that there were 300 units in inventory yesterday is not relevant to the 200 units in inventory today. Adding those values together results in an inflated total, 500, that does not reflect the actual size of the inventory. What is relevant, rather than the sum, is the last atomic inventory value in a given period of time.

In MicroStrategy SQL Generation Engine 9.x, non-aggregatable metrics are used for this kind of calculation. Non-aggregatable metrics are defined using the dimensionality section of the metric editor. The "Grouping" property has six possible settings, of which four specify non-aggregating behavior:

  • Beginning (fact)
  • Ending (fact)
  • Beginning (lookup)
  • Ending (lookup)
"Fact" and "lookup" define how the first or last atomic value is identified within the period. "Fact" means to use the first/last existing value in the fact table, while "lookup" goes to the first or last child element of the element to be displayed on the report. For example, a fact table might contain data such as the following:

|| Quarter_ID
Month_IDFact
2006120060110
2006120060220
2006120060330
2006220060440
2006220060550

No data exist for June 2006. An ending fact metric would return 30 for Q1 2006 and 50 for Q2 2006; the corresponding ending lookup metric would return 30 for Q1 2006, but the value for Q2 2006 would be null. This is because the lookup table identifies June 2006 as the last month in the second quarter, but the fact table does not have any data for that month.

Dimensionality vs. fact table attributes
The actual calculation level of a non-aggretable metric will be the lowest level attribute from the non-aggregatable hierarchy that is present on the fact table. If the fact table includes the Day attribute, day-level values would be the result. If, instead, Month is the lowest fact table level, then the metric would produce month-level values.The level of the first or last "x" within "y" depends on the granularity of the fact table.

If fact tables exist at multiple levels within a non-aggregatable hierarchy, the attribute chosen as the dimensionality target determines the calculation level by influencing the selection of the fact table. If Month is the target attribute, the Engine will never choose a fact table at a higher level than Month (never Quarter or Year). Thus the first or last month-level value will be presented in the report.

Note: The final determination of the calculation level is based on the fact table. The Engine uses normal fact table selection logic for non-aggregatable metrics, taking into account dimensionality and filtering attributes. The Engine will revert to a lower-level fact table if that is the only way to support all of the grouping and filtering attributes. For example, if a metric indicates non-aggregatable dimensionality at the level of Month, but a report includes attributes that require a day-level fact table, the day-level table will be used. Even though the metric specified Month level, the report will display the first or last day's value within the time period because the fact table demands it.

Beginning/ending (fact) dimensionality
Beginning or ending (fact) metrics calculate according to the following procedure:

  1. Calculate the metric, including both the dimensional level attribute ("parent") and the fact table level attribute ("child"). Including the fact table level attribute at this stage ensures that the non-aggregatable hierarchy will not be subject to aggregation.
  2. For each "parent" element, find the first or last "child" element that exists in step 1.
  3. The metric's final result is the intersection of steps 1 and 2.
For example, an "End on Hand" metric may be defined with the following dimensionality. Month is used as the dimensional attribute because the fact exists at the level of Month.

external image TN5200-8X-2457_1.gif

A report calculating this metric over Quarters generates the following SQL. (Note that a filter restricts the results to one quarter. This is because the MicroStrategy Tutorial project uses a partitioned fact table for the End on Hand fact. The filter reduces the size of the SQL and makes a better illustration.)

Partitioning pre-query -- this is independent of non-aggregatable metrics

select distinct a11.PBTNAME PBTNAME

from PMT_INVENTORY a11

where a11.QUARTER_ID in (20074)


Month-level values, with Quarter ID included

select a12.QUARTER_ID QUARTER_ID,

a11.MONTH_ID MONTH_ID,

sum(a11.EOH_QTY) WJXBFS1

into #ZZTTS0200F6PO000

from INVENTORY_Q4_2007 a11

join LU_MONTH a12

on (a11.MONTH_ID = a12.MONTH_ID)

where a12.QUARTER_ID in (20074)

group by a12.QUARTER_ID,

a11.MONTH_ID


What is the last Month found in the metric table for each Quarter?

select pc11.QUARTER_ID QUARTER_ID,

max(pc11.MONTH_ID) WJXBFS1

into #ZZTTS0200F6MB001

from #ZZTTS0200F6PO000 pc11

group by pc11.QUARTER_ID


Intersect (inner join) the tables to preserve only the last Month's value from each Quarter

select distinct pa11.QUARTER_ID QUARTER_ID,

a13.QUARTER_DESC QUARTER_DESC,

pa11.WJXBFS1 WJXBFS1

from #ZZTTS0200F6PO000 pa11

join #ZZTTS0200F6MB001 pa12

on (pa11.MONTH_ID = pa12.WJXBFS1 and 

pa11.QUARTER_ID = pa12.QUARTER_ID)

join LU_QUARTER a13

on (pa11.QUARTER_ID = a13.QUARTER_ID)


drop table #ZZTTS0200F6PO000

drop table #ZZTTS0200F6MB001
Beginning/ending (lookup) dimensionality
Beginning or ending (lookup) metrics follow a slightly different procedure.

  1. Create a table containing the first or last child elements (fact table level) corresponding on the parent elements to be displayed (dimensional level). Note that there is no need to include the parent attribute in the SELECT clause of this pass, because the pass will be used only for filtering the fact table. (The parent attribute is in the GROUP BY clause.)
  2. Calculate the metric, grouping by the dimensional level attribute ("parent") but filtering according to the child elements from step 1.
external image TN5200-8X-2457_2.gif

Determine the latest Months in each Quarter, according to lookup table

select max(c11.MONTH_ID) MONTH_ID

into #ZZTTS0200GZOP000

from LU_MONTH c11

where c11.QUARTER_ID in (20074)

group by c11.QUARTER_ID


Partitioning pre-query -- this is independent of non-aggregatable metrics

select distinct a11.PBTNAME PBTNAME

from PMT_INVENTORY a11

where a11.QUARTER_ID in (20074)


// Calculate the metric, filtering on the set of last months in their quarters

select a13.QUARTER_ID QUARTER_ID,

max(a14.QUARTER_DESC) QUARTER_DESC,

sum(a11.EOH_QTY) WJXBFS1

from INVENTORY_Q4_2007 a11

join #ZZTTS0200GZOP000 pa12

on (a11.MONTH_ID = pa12.MONTH_ID)

join LU_MONTH a13

on (a11.MONTH_ID = a13.MONTH_ID)

join LU_QUARTER a14

on (a13.QUARTER_ID = a14.QUARTER_ID)

where a13.QUARTER_ID in (20074)

group by a13.QUARTER_ID


drop table #ZZTTS0200GZOP000

Comments

Popular posts from this blog

Case functions Microstrategy

Ca se functions Microstrategy Case functions return specified data in a SQL query based on the evaluation of user-defined conditions. In general, a user specifies a list of conditions and corresponding return values. Case This function evaluates multiple expressions until a condition is determined to be true, then returns a corresponding value. If all conditions are false, a default value is returned.  Case  can be used for categorizing data based on multiple conditions. This is a single-value function. Syntax Case ( Condition1 ,  ReturnValue1 ,  Condition2 , ReturnValue2 ,...,  DefaultValue ) Example Case(([Total Revenue] < 300000), 0, ([Total Revenue] < 600000), 1, 2) sum(Case (Day@DESC in (“Sat”,”Sun”), Sales, 0) {~+} Sum(Case(Category@DESC In("Books","Electronics"),Revenue,0)){~+} CaseV (case vector) CaseV  evaluates a single metric and returns different values according to the results. It can be used to perfo...

MicroStrategy URL API Parameters

MicroStrategy URL Structure The following table summarizes the root URL structure used for every request to MicroStrategy Web. Environment Main Application URL Administration URL J2EE http://webserver/MicroStrategy/servlet/mstrWeb http://webserver/MicroStrategy/servlet/mstrWebAdmin .NET http://webserver/MicroStrategy/asp/Main.aspx http://webserver/MicroStrategy/asp/Admin.aspx Every request sent to MicroStrategy Web calls a central controller. Parameters are appended to  Main.aspx  or  mstrWeb  (in a .NET and J2EE environment, respectively) to indicate to the controller how the request should be internally forwarded and handled. The following examples show a URL for accessing a MicroStrategy folder when the user does not have an existing session. The URL contains not only the parameters needed to connect to MicroStrategy Web, but also the parameters needed to log on and create a session. J2EE environment: <a href="http:...

Microstrategy Custom number formatting symbols

Custom number formatting symbols If none of the built-in number formats meet your needs, you can create your own custom format in the Number tab of the Format Cells dialog box. Select  Custom  as the Category and create the format using the number format symbols listed in the table below. Each custom format can have up to four optional sections, one each for: Positive numbers Negative numbers Zeros Text Each section is optional. Separate the sections by semicolons, as shown in the example below: #,###;(#,###);0;"Error: Entry must be numeric" For more examples, see  Custom number formatting examples . To jump to a section of the formatting symbol table, click one of the following: Numeric symbols Character/text symbols Date and time symbols Text color symbols Currency symbols Conditional symbols Numeric symbols For details on how numeric symbols apply to the Big Decimal data type, refer to the  Project Design Guide . ...

Settings for Outer Join between metrics in MicroStrategy

Settings for Outer Join between metrics in MicroStrategy MicroStrategy adopts multi-pass logic to determine the execution plan for a report. This means that every metric is evaluated in separate SQL passes. Outer Joins come into play when MicroStrategy Engine merges the results from all SQL passes into one report. For a multi-pass report, different Outer Join behaviors can give the user completely different results. In addition, report metrics can be of different types which can, in some cases, influence the result of the outer join. In MicroStrategy, there are two settings that users can access to control Outer Join behavior : Formula Join Type and Metric Join Type . Metric Join Type: VLDB Setting at Database Instance Level Report and Template Levels Report Editor > Data > Report Data Options Metric Level   Metric editor > Tools > Metric Join Type Control Join between Metrics Formula Join Type: Only at Compound/Split...

Control the display of null and zero metric values

Show   Control the display of null and zero metric values in a grid report You can determine how to display or hide rows and columns in a grid report that consist only of null or zero metric values. You can have MicroStrategy hide the rows and columns in the following ways: Hide rows and columns that consist only of null metric values Hide rows and columns that consist only of zero metric values Hide rows and columns that consist only of null or zero metric values (default) Once you have defined how MicroStrategy hides null and zero metric values in the grid, you can quickly show or hide the grid using the Hide Nulls/Zeros option in the Data menu, as described below, or by clicking the  Hide Nulls/Zeros  icon  in the Data toolbar. To determine how null and zero metric values are displayed or hidden in a grid report Open the report in Edit mode. From the  Tools  menu, select  Report Options . The Report Options...

Custom Subtotal Displays in MicroStrategy

Defining custom subtotal displays in MicroStrategy 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  U sers can make the subtotal name dynamic by typing special characters in the subtotal name field as listed in the following table. Character Description #A The name of the attribute under which the subtotal appears. #P The name of the attribute to the left of, or above the attribute under which the subtotal appears. #0 All the forms of the parent element. #1 The first form of the parent element reading from left to right or from top to bottom. #2 The second form of the parent element reading from left to right or from top to bottom. #3 The third form of th...

Retrieve a list of user groups and the associated users in MicroStrategy Developer 9.x / 10.x

Retrieve a list of user groups and the associated users in MicroStrategy Developer Follow the steps below to create a list of all groups and the users in each group: In MicroStrategy Developer 9.x, select 'Project Documentation' from the Tools menu to start the wizard. Select any project that is in the project source that contains the users and groups and click Next. Select only Configuration Objects for documentation. Uncheck the 'Basic Properties' object category from the next screen, as shown below: Then select only 'User Group' under the Configuration Objects section and only 'Groups' and 'Members' under the Definition section, as shown below: Go through the rest of the wizard, and open the resulting documentation. After navigating down to the User Groups, the documentation should look similar to the following image: This page shows every group, any child groups, and all members of each group.

Fact tables levels tables in Microstrategy explained

Fact tables levels in Microstrategy: Fact tables are used to store fact data. Fact tables should contain attribute Id's and fact values which are measurable. All the descriptive information about the fact tables should stored in Dimension tables either in Star Schema fashion or Snow Flake Schema fashion which is best suited to your reporting solution. Since attributes provide context for fact values, both fact columns and attribute ID columns are included in fact tables. Facts help to link indirectly related attributes using these attribute ID columns. The attribute ID columns included in a fact table represent the level at which the facts in that table are stored. So the level of a fact table in the Fact_Item_Day_Customer can be the attribute Id's which is at Day, Item & Customer Id level. For example, fact tables containing sales and inventory data look like the tables shown in the following diagram: Base fact columns ver...

Export a Report Services document to Excel with formatting using URL API

Export a Report Services document to Excel with formatting using URL API in MSTR Web In order to export a document in excel format using the URL API, the executionMode must be set to 4.  If excutionMode is not provided in the URL, by default PDF will be used as executionMode.   Below are the list of parameters that the URL must contain in order to execute correctly.   evt= 3069 src= Main.aspx.3069 executionMode= 4 documentID= 7E1644CA424F482DA811569FCE8127FF( Replace the document Id with your document ID)   Sample URL for .NET environment: http://WebServerName/MicroStrategy/asp/Main.aspx?evt=3069&src=Main.aspx. 3069 &executionMode= 4 &documentID= 7E1644CA424F482DA811569FCE8127FF    

Microstrategy "Error type: Odbc error. Odbc operation attempted

 "Error type: Odbc error. Odbc operation attempted: SQLExecDirect. [HYT00:0: on SQLHANDLE] [MicroStrategy][ODBC Oracle Wire Protocol driver]Timeout expired" is shown when executing reports from Web When users are trying to execute some reports in MicroStrategy web in particular, they may receive the Error “SQL Generation Complete Index out of range” and “Timeout expired” error as shown below: Possible Causes: One possible cause is that the MicroStrategy Intelligence Server using a cached database connection that was already dropped by the RDBMS. To resolve this: Admin should delete the database connection caches and create a new DSNs in case they are sharing DSNs to connect to different databases. In addition, change the settings for the ‘Connection lifetime’ and the ‘Connection idle time out’.  Follow the steps below to perform the mentioned changes and verify the report after each step and some of the settings require i-server r...