Skip to main content

Data Modelling issues with Split, Ragged and Recursive Hierarchies in Microstrategy

TN6831: Known data modeling restrictions and solutions in MicroStrategy SQL Generation Engine 8.1.x and 9.x

https://success.microstrategy.com/t5/Architect/TN6831-Known-data-modeling-restrictions-and-solutions-in/ta-p/167845

I. Split Hierarchy with M-M relationships:

ExplanationA split hierarchy is the one - that at the lowest level - has more than one child. The schema looks like the following diagram.
TN5200-7X0-0123A.gif
TN5200-7X0-0123A.gif
ProblemReports that contain or will ignore filters on
RecommendationMicroStrategy recommends to have only one child at the lowest level.
Workaround / SolutionMake B and C IDs to be compound with A


II. In-line M-M Relationships:


ExplanationAn in-line many-to-many relationship involves an attribute with at least one parent and one child . Its relationships with them are many-to-many.
TN5200-7X0-0123B.gif
TN5200-7X0-0123B.gif
ProblemDouble counting, ignored filters.
RecommendationMicroStrategy does not recommend this type of schema.
Workaround / SolutionModify table structures, remove M-M relationship.



III. Star Schemas:


ExplanationThis schema is characterized by one lookup table per dimension, with base tables at the lowest level. This is the fastest way to set up a data warehouse:
TN5200-7X0-0123H.gif
TN5200-7X0-0123H.gif

This type of schemas is fully supported but difficulties may arise when adding aggregate tables:
TN5200-7X0-0123I.gif
TN5200-7X0-0123I.gif
ProblemDouble counting. According to the diagram above, a report that contains and the a metric SUM(SALES_AMT) will go to the aggregate table and join to the column to retrieve the description from the table. Since the column is not unique in its lookup table, the results will appear duplicated.
RecommendationMicroStrategy engine is optimized to work with snowflake schemas, where each attribute level has a distinct lookup table. Star schemas are supported, as long as fact tables are not at a higher level than the dimension tables to which they are joined. Consult the following MicroStrategy Knowledgebase document for further information.
TN19194 - Considerations for the use of star schemas with MicroStrategy SQL Generation Engine 8.1.x and 9.x
Workaround / SolutionIf aggregate tables are needed, use one lookup table per attribute to avoid double counting.



IV. Recursive Hierarchies:


ExplanationA recursive hierarchy or recursive dimension, usually consists of elements that point to other elements pertaining to the same attribute with a parent-child relationship. A classic example is an organization chart:
TN5200-7X0-0123J.gif
TN5200-7X0-0123J.gif

This information can be stored in a recursive fashion in only one table:
TN5200-7X0-0123K.gif
TN5200-7X0-0123K.gif
ProblemRecursive hierarchies are not natively supported by MicroStrategy 8.x
RecommendationExplode the schema from recursive to dimensional
Workaround / SolutionThe recursive hierarchy table has to be split into several tables, one for each level in the hierarchy. A physical snapshot of the solution is:
external image TN5200-7X0-0123_19.gif
Each attribute has a 1-M relationship with its child.
V. Ragged Hierarchies
ExplanationA ragged hierarchy is the one in which the parent attribute element of one or more
attribute elements are not in the level immediately above the attribute. In short, some attribute elements
don't have a relationship with their parent attribute, but instead have a direct
relationship with a grand-parent. Information in a ragged hierarchy may look like:
external image TN5200-7X0-0123_14.gif
Notice that the Esprit and the Diablo have a missing entry for the Branch, but they have one for the corporation.
ProblemRagged hierarchies are not natively supported by
MicroStrategy 8.x
RecommendationCreate entries for the missing attributes.
Workaround / SolutionConsider the case where the data has the following format:
external image TN5200-7X0-0123_15.gif
external image TN5200-7X0-0123_16.gif
New entries for the missing attributes should be added to the Branch attribute lookup table. These entries have to keep the one-to-many relationship of the attributes, so they can not share the same ID. As shown below for the above example, the entries should be added to the LU_BRANCH table. Additionally the BRANCH_ID column of the LU_MODEL table must also be updated:
external image TN5200-7X0-0123_17.gif
external image TN5200-7X0-0123_18.gif

Comments

  1. I truly appreciate the time and work you put into sharing your knowledge. I found this topic to be quite effective and beneficial to me. Thank you very much for sharing. Continue to blog.

    Data Engineering Services 

    AI & ML Solutions

    Data Analytics Services

    Data Modernization Services

    ReplyDelete

Post a Comment

Popular posts from this blog

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

Slowly Changing Dimension Types 0, 4, 5, 6 and 7

Slowly Changing Dimension Types 0, 4, 5, 6 and 7 Ralph introduced the concept of slowly changing dimension (SCD) attributes in 1996. Dimensional modelers, in conjunction with the business’s data governance representatives, must specify the data warehouse’s response to operational attribute value changes.  Core SCD approaches:  Type 1 (overwrite),  Type 2 (add a row), and  Type 3 (add a column).  Since legibility is a key component of the Kimball mantra, we sometimes wish Ralph had given these techniques more descriptive names, such as “overwrite” instead of “type 1.” But at this point, the SCD type numbers are part of our industry’s vernacular. We have written about more advanced SCD patterns, such as the 2005 article entitled “ Slowly Changing Dimensions are Not Always as Easy as 1, 2, 3. ” However, we’ve not consistently named the more advanced and hybrid techniques. With the third edition of  The Data Warehouse Toolkit  (Wiley, 201...

Internationalization Design Technics

Microstrategy Internationalization Design Technics MicroStrategy supports data internationalization through two different techniques. You can either provide translated data through the use of extra tables and columns, or you can provide separate databases to store your translated data. These techniques are described below: You can support data internationalization in your database by using separate tables and columns to store your translated data. You can use various combinations of tables and columns to support and identify the translated data in your database. To support displaying the name of each month in multiple languages, you can include the translated names in a separate column, one for each required language, within the same table. Each column can use a suffix to identify that the column contains translated data for a certain language. The same LU_MONTH_OF_YEAR table with translated data for the Spanish and German langua...

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

Uniquely identifying data using Compound Key in Microstrategy

Uniquely identifying data in tables with Compound Key attribute: The types of keys that can be assigned to a table include: • Simple key requires only one column to identify a record uniquely within a table. • Compound key requires multiple columns to identify a unique record. . The following diagram shows how the different key structures can be used to identify a cal...

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

Configure a report for use with Bulk Export in MicroStrategy

Configure a report for use with Bulk Export in MicroStrategy The Bulk Export feature enables a large report to be saved as a delimited text file. Using this feature, it is possible to retrieve result sets from a large dataset without having to load the entire dataset into memory. PS:  Once a report is setup for bulk export it cannot be used as a regular report. So if the report needs to be run as a normal report and as a bulk export report, the first step is to make a copy of the report for use with bulk export. Configure Bulk Export Bulk Export options are only available in MicroStrategy Developer. Open a 3-tier connection using MicroStrategy Developer and edit the desired report. Go to 'Data' on the top menu bar. Select 'Configure Bulk Export': Specify any additional desired configuration options. General Settings Bulk export database instance : This is the database instance to use to store the bulk export results. Temporary tables w...

Configure Connection Mapping in Microstrategy

Configure Connection Mapping in Microstrategy The following steps demonstrate the second scenario where two different data warehouses are used within the same project: Create two different database connections -                                                                                        One that points to the data warehouse for the European users                                                                 and the other that points to the data warehouse for USA users as shown below: Select Europe as the default database connection for the database Instance as seen below: Go to P...

Sort by metric subtotals and attribute elements together in Microstrategy

Sort by metric subtotals and attribute elements together in Microstrategy Users may observer that when creating a report that contains advance sorting with a metric that contains subtotals the report results appear to be only sorted by the metric values specified. Even if a sort is specified for the attribute elements on the report, the results in the report appear as if the attribute sort was not defined. In the screenshot below, the results for a report are shown where the Advance Sorting option 'Sort metrics hierarchically using: Total' is selected. For this report, a second sort is defined on the Customer Gender - 'DESC' form, users would notice that the ordering of the this attribute is not consistent: The sort definition for the report is shown below: CAUSE: When the option to 'Sort metrics hierarchically using: Total' option is selected, the MicroStrategy Engine first sorts the results based on the Total values, and then sorts th...
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...