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 Dossiers explained

Microstrategy  Dossiers With the release of MicroStrategy 10.9, we’ve taken a leap forward in our dashboarding capabilities by simplifying the user experience, adding storytelling, and collaboration.MSTR has  evolved dashboards to the point that they are more than dashboards - they are  interactive, collaborative analytic stories . Ultimately, it was time to go beyond dashboards, both in concept and in name, and so  the've  renamed VI dashboards to  ‘ dossiers ’.  Dossiers can be created by using the new Desktop product or Workstation or simply from the Web interface which replaces Visual Insights. All the existing visual Insights dashboards will be converted to Dossiers   With MicroStrategy 10.9, there was an active focus on making it easier to build dashboards for the widest audience of end users. To achieve this, some key new capabilities were added that make it easier to author, read, interact and collaborate on dashboards ...

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

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

Display a report in different view modes through URL API in MicroStrategy Web

The URL parameter report view mode in Microstartegy visMode - the mode in which the document is displayed, e.g. 2 for Interactive reportviewmode  determines how reports are displayed in the view mode, e. g. 1 for grid mode. &reportViewMode=1 (grid) &reportViewMode=2 (graph) & reportViewMode=3 (grid/graph)  &visMode=0 (no visualization) &visMode=51 (AJAX visualization)  <--- this and Flash (50) require that you setup a Custom Visualization in the report definition.&visMode=50 (Flash visualization). M ake sure those modes are enabled in Document Properties. Other parameters in the URL API Webserver - name or IP address of the webserver  Evt - event/action to be performed, e.g. 2048001 for running a document  Src - web page component to perform the event  documentID - document object ID to be executed  The parameter to pass an answer to an element list prompt:  elementsPromptAnswers=AttrID;AttrID:E...

Microstrategy Caches explained

Microstrategy Caches Improving Response Time: Caching A  cache is a result set that is stored on a system to improve response time in future requests.  With caching, users can retrieve results from Intelligence Server rather than re-executing queries against a database. To delete all object caches for a project 1 In Developer, log into a project. You must log in with a user account that has administrative privileges. 2 From the  Administration  menu, point to  Projects , and then select  Project Configuration . The Project Configuration Editor opens. 3 Expand  Caching , expand  Auxiliary Caches , then select  Objects . To delete all configuration object caches for a server 1 Log in to the project source. 2 From the  Administration  menu in Developer, point to  Server , and then select  Purge Server Object Caches . 4 Click  Purge Now . To purge web cache follow the steps in the link ...

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

Transaction Services - Configure Transactions

Configure Transactions in MSTR Web Transaction Services-enabled document displayed on an iPhone, iPad, or Android device can allow users to insert/update/delete data in to the database, using the options in the Configure Transactions Editor. To do so, you must link a Transaction Services report to a grid or to text fields in a panel stack. If the document is being displayed on an iOS device, you can link the report to the cells of a transaction table. Data from the input objects defined in the Transaction Services report is displayed in the grid, text fields, or cells for users to edit. Prerequisites:        Ø   You must have the Web Configure Transaction privilege assigned by MSTR user admin. Ø   Create the Transaction Services report (usually a grid report) you want to link to the grid, text fields, or transaction table cells. Make sure that the Transaction Services report must contain the input object for each value you w...

Types of filters in Microstrategy

Types of filters in Microstrategy Below are the types of filters: 1. Attribute qualification filter These types of qualifications restrict data related to attributes on the report. a) Attribute form qualification Filters data related to a business attribute’s form(s), such as ID or description. •  For example, the attribute Customer has the forms ID, First Name, Last Name, Address, and Birth Date. An attribute form qualification might filter on the form Last Name, the operator Begins With, and the letter H. The results show a list of customers whose last names start with the letter H. b) Attribute element list qualification Filters data related to a business attribute’s elements, such as New York, Washington, and San Francisco, which are elements of the attribute City. • For example, the attribute Customer has the elements John Smith, Jane Doe, William Hill, and so on. An attribute element list qualification can filter data to display only those customer...

Time-based and event-based schedules

Time-based and event-based schedules executed in a clustered MicroStrategy A  schedule  is a MicroStrategy object that contains information specifying when a task is to be executed. Schedules are stored at the project source level, and are available to all projects within the project source. MicroStrategy Intelligence Server supports two kinds of schedules: Time-triggered schedules execute at a specific date and time, or at a specific recurring date and time. These schedules execute based on the time on the machine where they were created. Event-triggered schedules execute when the event associated with them is triggered. Both types of schedules can be used to schedule reports and documents, called subscriptions, or to schedule administrative tasks like delete all history list, idle project, etc. Execution of Time-Based Schedules in a MicroStrategy Intelligence Server Cluster: In a 9.x MicroStrategy Intelligence Server clustered environment, subscriptions...