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

Level metrics in Microstartegy/MSTR

Level Metrics Level metrics allows the users to choose the right combination of level target, filtering, and grouping (referred to as elements) to achieve your desired results.  The elements of a metric level are described below: • Target : The target is the attribute level at which the metric calculation groups. For a more detailed description, see  Target: The context of a calculation . • Grouping : Grouping determines how the metric aggregates. For a more detailed description, see  Grouping: How aggregation is performed . • Filtering : Filtering governs how the report filter interacts with the metric calculation. For a more detailed description, see  Filtering: Interaction with report filters . The level is indicated between the curly braces ({ }) in the metric definition shown below: Sum(Revenue) {~, Product} The tilde (~) represents the report level with standard filtering, denoted by the plus sign (+). If you add item as a level, th...

Apply or Pass-through functions in Microstrategy

Ap ply (Pass-Through) functions MSTR Apply functions provide access to functions or syntactic constructs that are not standard in MicroStrategy but are provided by various RDBMS systems.. Syntax common to Apply functions Apply Function Name   ("expression with placeholders", Arg1, Arg2, Arg3, …ArgN) where: Apply Function Name  – is a generic name used for the predefined pass-through functions described above expression with placeholders  – is the string describing the actual expression or syntax that the engine uses while generating the SQL and which is sent to the RDBMS. The placeholders are represented by #0, #1, and so on. "#" is a reserved character for MicroStrategy. Arg  – is an argument that replaces the parameter markers in the pattern. Arg1 replaces #0, Arg2 replaces #1, and so on. There are   five  pre-defined Apply functions to replace regular, predefined functions of the same type. For more details, cli...

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...

Tableau Dataset Connector to Microstrategy REST API URL

Tableau Dataset Connector to Microstrategy REST API URL The MicroStrategy Dataset Connector is an out‑of‑the box feature that allows you to fetch data from reports or cubes that reside in MicroStrategy projects into Tableau Public (also known as Tableau Desktop). You can import datasets with up to four million rows and 30+ columns. Tableau Public 10.4 or later is needed. Open Tableau Desktop Public Edition. Under Connect, click  Web Data Connector . If it is not there, click  More > Web Data Connector . Enter the following URL: https:// <MSTR Domain> /CommunityConnectors/mstr/ If the connector does not automatically detect Tableau, add the query  ?mode=tableau  to the end of the URL and refresh your browser. Enter your API Server URL and environment credentials. Your REST API URL is your environment URL with  /MicroStrategyLibrary/  added at the end. Click  Connect Select the dataset you want to import. Select the...

Microstrategy Report Execution Process

The Report Execution Process  Report execution process at a high level: The report execution process is a three-step process:  1. Query Stage : Retrieve data from the warehouse  2. Populate and Evaluate : Fill report data required for display  3. Cross-tab : Pivot and display sorting and page-by Each of the engines plays an important part in the report execution process.  As you can imagine, the SQL Engine performs its role during the Query stage while the Query Engine and Analytical Engine can be involved in all three stages.

Microstrategy Removing sections that do not have metric data

Removing sections that do not have metric data This is an interesting feature which might not be explored by many of us and it comes us handy. A  cross join between datasets can result in rows or Group Header/Footer sections that do not have metric data. For example, a document contains two datasets. Dataset 1 contains Year and Revenue, with data for three years (2007-2009). Dataset 2 contains Year and Profit, filtered to return data for only two years (2008 and 2009). If you place Year and Profit in the Details and execute the document, it displays three rows, although no profit data exists for 2007. This is a product of the cross join between the two datasets. You do not want to see the blank line for 2007 since it does not give you any data for profit. You can select the  Trim sections for which no metric value data is available  check box. This removes the row for 2007, since no metric data for Profit is available for 2007. The results are shown below: ...

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 . ...

Custom Tooltips in Microstrategy developer and Web

Custom Tooltips in Microstrategy developer and Web The following table describes the macros you can use to customize graph tooltips in both MicroStrategy Developer and MicroStrategy Web: Macro Information Displayed {&TOOLTIP} All relevant labels and values associated with a graph item. {&GROUPLABEL} Name of the graph item's category. This value is often the graph item's attribute element information, as attributes are commonly used as the categories of graph reports. {&SERIESLABEL} Name of the graph item’s series. This value is often the graph item's metric name information, as metrics are commonly used as the series of graph reports. {&VALUE} The value of a given data point. {&XVALUE} The X-value of a data point. Only applicable to Bubble charts and Scatter plots. {&YVALUE} The Y-value of a data point. Only applicable to Bubble charts and Scatter plots. {&ZVALUE} The Z-value of a data point. Only applicable to Bubble charts and Scatter plots. {...

HyperIntelligence Training Videos

HyperIntelligence  Training Videos           Design and build hyper cards Optimizing Datasets for HyperIntelligence Using the HyperIntelligence for Office Outlook Add-In Building HyperIntelligence Cards Using HyperIntelligence for Mobile on Android Deploying HyperIntelligence for Outlook Insights On-The-Go: HyperIntelligence for Mobile Building HyperIntelligence Profile Cards Designing Custom HyperIntelligence Cards Using the Calendar with HyperIntelligence for Mobile

MicroStrategy Hadoop Gateway operation modes

MicroStrategy Hadoop Gateway operation modes MicroStrategy Hadoop Gateway is a native connector which was built based on Spark 1.6.x. You can choose one or more data files from Hadoop HDFS and load them into MicroStrategy Intelligence Server. Data files can be published as either an In-Memory Cube or a Live Connect Cube. MicroStrategy Hadoop Gateway supports three operation modes : YARN client Standalone (HDP cluster does not support Standalone) Local YARN client mode: The driver runs in the client process, and the application master is only used for requesting resources from YARN. Running in this mode requires YARN service to be enabled on your Hadoop cluster. Standalone mode:  MicroStrategy Hadoop Gateway uses Spark Master to coordinate data processing. Local mode:  no application is deployed in the Spark nodes. All data processing is executed in the MicroStrategy Hadoop Gateway host. This modality is intended for testing and troubleshooting.