Skip to main content

Star schemas and aggregate (or summary) fact tables


Aggregate tables can further improve query performance by reducing the number of rows over which higher-level metrics must be aggregated. 
However, the use of aggregate tables with dimension tables is not a valid physical modeling strategy. Whenever aggregation is performed over fact data, it is a general requirement that tables joined to the fact table must be at the same attribute level or at a higher level. If the auxiliary table is at a lower level, fact rows will be replicated prior to aggregation and this will result in inflated metric values (also known as "multiple counting").

With the above Time dimension table, a fact table at the level of Day functions correctly because there is exactly one row in DIM_TIME for each day. To aggregate the facts to the level of Quarter, it is valid to join the fact table to the dimension table and group by the quarter ID from the dimension table.

Sql
select DT.QUARTER_ID,
   max(DT.QUARTER_DESC) Quarter_Desc
   sum(FT.REVENUE) Revenue
from DAY_FACT_TABLE FT
   join DIM_TIME DT
      on (FT.DAY_ID = DT.DAY_ID)
group by DT.QUARTER_ID

If, however, there is an aggregate fact table already at the level of Quarter, the results will not be correct. This is because the query must join on Quarter ID, but the quarter ID is not a unique key of the dimension table. Because any given quarter of a year contains 90, 91 or 92 days, the dimension table will contain that many rows with the same quarter ID. Thus fact rows will be replicated prior to taking the sum, and the sum will be too high.

Sql
select FT.QUARTER_ID,
   max(DT.QUARTER_DESC) Quarter_Desc
   sum(FT.REVENUE) Revenue
from QTR_FACT_TABLE FT
   join DIM_TIME DT
      on (FT.QUARTER_ID = DT.QUARTER_ID)
group by FT.QUARTER_ID

This is a generally recognized problem with star schemas, and is not strictly a MicroStrategy limitation.

Star schemas will function correctly with MicroStrategy SQL Generation Engine 8.x as long as they obey the general data warehousing principle that fact tables should not be at a higher level than the dimension tables to which they are joined.

If aggregate tables are required, it is necessary to provide higher-level lookup tables with unique rows corresponding to each aggregate table's key. Logical views are a way to do this without adding tables or views to the warehouse. For example, LWV_LU_QUARTER may be defined using the following SQL statement:

Sql
select distinct QUARTER_ID, QUARTER_DESC, YEAR_ID
from DIM_TIME

 

With this logical view, it becomes possible for MicroStrategy SQL Generation Engine 8.x to query the quarter-level fact table as follows. Since the logical view has distinct rows per quarter, multiple counting will not occur in this query.

Sql
select FT.QUARTER_ID,
   max(LQ.QUARTER_DESC) Quarter_Desc
   sum(FT.REVENUE) Revenue
from QTR_FACT_TABLE FT
   join (select distinct QUARTER_ID, QUARTER_DESC, YEAR_ID
         from DIM_TIME) LQ
      on (FT.QUARTER_ID = LQ.QUARTER_ID)
group by FT.QUARTER_ID

For more information on the use of logical views in MicroStrategy SQL Generation Engine 8.1.x and 9.x, consult the MicroStrategy Project Design Guide manual, Appendix B: Logical Tables, "Creating logical tables."

Aggregate tables store pre-summarized totals at a higher level of aggregation than the most granular fact table. They allow reports to be generated from small, rather than large, tables; therefore, performance is enhanced. A successful aggregation strategy seeks to choose aggregate tables that will have the most impact while taking the least amount of space.

Aggregation decisions are driven by the following factors:

  • Usage patterns: Build aggregate tables that are likely to be used the most.
  • Compression ratios: The compression ratio between two tables is defined as the size of the aggregate compared to the size of the smallest table from which the aggregate can be derived.
  • Volatility: Changes in hierarchies over time impact the accuracy of aggregate tables. Sometimes aggregate tables must be rebuilt as a result of changes in dimensions.
A good candidate for aggregation should have at most 10-15 percent of the size of the smallest table from which it is derived.

EXAMPLE:
The MicroStrategy Tutorial project uses aggregate tables by default. A simple metric sum (Revenue) will go to different aggregate tables depending on the attributes on the template.

  1. Create a report with Year on the rows and Revenue on the columns.
  2. Execute the report and view the SQL:

  3. Drill from Year to Item and view the SQL:

The query will go from using ORDER_FACT to ORDER_DETAIL. When Year is on the template, the engine selects the smaller table and the fact is calculated as:

sum(a11.ORDER_AMT)
    instead of:

    sum((a11.QTY_SOLD * (a11.UNIT_PRICE - a11.DISCOUNT)))
    Labels:

    Comments

    1. hinaFebruary 5, 2021 at 12:19 PM

      Is there any solution now to use aggregate tables with star schema without creating logical tables?

      ReplyDelete

    Post a Comment

    Popular posts from this blog

    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...
    4 comments
    Read more

    Types of prompts in Microstrategy

    Types of prompts in Microstrategy The different types of prompts allow you to create a  prompt  for nearly every part of a report. Prompts can be used in many objects including reports, filters, metrics, and custom groups, but all prompts require user interaction when the report is executed. The correct prompt type to create depends on what report objects you want users to be able to base a filter on to filter data, as described in the list below. Filter definition prompts   allow users to determine how the report's data is filtered, based on one of the following objects: Attributes in a hierarchy : Users can select prompt answers from one or more attribute elements from one or more attributes. The attribute elements that they select are used to filter data displayed on the report. This prompt lets you give users the largest number of attribute elements to choose from when they answer the prompt to define their filtering criteria. For example, on a repor...
    1 comment
    Read more

    Types of result caches in Microstrategy

    Types of result caches Microstrategy The following types of  result caches are created by Intelligence Server: • Matching caches • History caches • Matching-History caches • XML caches All document caches are Matching caches; documents do not generate History caches or XML caches. Intelligent Cube reports do not create Matching caches. Matching caches Matching caches  are the  results of reports and documents that are retained for later use by the same requests later on. In general, Matching caches are the type of result caches that are used most often by Intelligence Server. When result caching is enabled, Intelligence Server determines for each request whether it can be served by an already existing Matching cache. If there is no match, it then runs the report or document on the database and creates a new Matching cache that can be reused if the same request is submitted again. This caching process is managed by the system administrator and ...
    Post a Comment
    Read more

    URL API connection mode parameters

    URL API connection mode parameters When using the URL API, to denote which type of Authentication to use, developers can use the connMode parameter.  The following values are used for this parameter: Standard = 1 LDAP Authentication = 16 Database Authentication = 32 Guest = 8 Windows Authentication = 2 Trusted Authentication = 64 Integrated Authentication = 128
    Post a Comment
    Read more

    Non Aggregate metrics Beginning lookup, Ending lookup, Beginning fact., Ending fact

    Non Aggregate metrics  Beginning lookup,  Ending lookup,  Beginning fact .,  Ending fact A nonaggregatable metric, such as an inventory metric, is one that should not be aggregated across an attribute.   For example, if you have monthly inventory numbers in your data warehouse and want to calculate the yearly inventory, adding the monthly numbers together does not provide a useful business measure. Instead, you may want to use the end-on-hand and beginning-on-hand inventory numbers to see how the total inventory changed during the year.  The following options are available: • To use the first value in the lookup table, select  Beginning lookup . • To use the last value in the lookup table, select  Ending lookup . • To use the first value in the fact table, select  Beginning fact . • To use the last value in the fact table, select  Ending fact .
    Post a Comment
    Read more

    Super Cubes in MicroStrategy 2019

    Super Cubes in MicroStrategy 2019 Beginning in MicroStrategy 11.0 and 2019, users will notice objects referred to as " Super Cubes ".  Super Cubes are simply a renaming of what was previously referred to as MTDI (Multi Table Data Import) Cubes. Note that only the naming convention has changed, as the functionality remains the same . This name change is visible in MicroStrategy Workstation and MicroStrategy Web. In MicroStrategy Workstation, right click on any cube created via Data Import and select Properties . The object Type is listed as Super Cube: This can also be seen when editing or authoring a dossier. In your Datasets panel, hover over the name of your dataset. The tooltip will show the dataset type listed as a Super Cube.
    Post a Comment
    Read more

    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. {...
    2 comments
    Read more

    Algorithm to calculate Logical Table Size in Microstrategy

    How are the fact tables determined using the logical table size for SQL generation in MicroStrategy The logical table size is an integer number that represents the granularity or level of aggregation of a particular table. It is called 'logical' because it is not related to the physical size of the tables (number of rows). It is calculated according to the attribute IDs that are present in the table and their level in the system hierarchy.   Even though, the number does not reveal the actual number of rows in the table, it is an accurate way of measuring a table size without having to access its contents.   IMPORTANT:   The system hierarchy is defined by the parent-child relationships between attributes of the same family (formerly known as a dimension), not by user-defined hierarchies (i.e., drilling hierarchies).   MicroStrategy Engine utilizes an algorithm based on attribute keys to calculate the Logical Table Size (LTS): Given the following tables: ...
    Post a Comment
    Read more

    Optimizing queries in Microstrategy using VLDB properties

    Optimizing queries in  Microstrategy using VLDB properties #vldb #vldbproperties The table b elow summarizes the Query Optimizations VLDB properties. Additional details about each property, including examples where necessary, are provided in the sections following the table. Property Description Possible Values Default Value Additional Final Pass Option Determines whether the Engine calculates...
    Post a Comment
    Read more

    Displaying sections horizontally in MSTR

    Displaying sections horizontally in MSTR Document By default, all sections are displayed and printed vertically in a document. The Detail Header is displayed below the Document Header, the Detail is displayed below the Detail Header, and so on. For Ex: the title Monthly Revenue is displayed in the Detail Header, while Month and Revenue are placed in the Detail section as shown below. Displaying the Detail section horizontally displays the monthly revenue across the page, as shown in the document sample below. The Revenue metric was moved below Month, to present a half year of data across a single sheet of paper. The following image shows the same document in Design Mode. The Detail Header contains the title, while the Detail section contains Month and Revenue. The Detail section is displayed horizontally. You can also control the horizontal width using the settings:  A horizontally displayed section prints horizontally across a page and therefore needs addi...
    Post a Comment
    Read more