Skip to main content

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 versus derived fact columns

The types of fact columns are base fact columns and derived fact columns:
• Base fact columns are represented by a single column in a fact table. The following diagram shows an example of a fact table and base fact columns:
• Derived fact columns are created through a mathematical combination of other existing fact columns. The following diagram shows an example of a fact table and how you can create a derived fact column from base fact columns:
In the example, the derived fact Tot_Dollar_Sales is created using the Qty_Sold, Unit_Price, and Discount fact columns. Also, the derived fact exists in several tables, including Item_Mnth_Sls and City_Ctr_Sls.
Because facts in different fact tables are typically stored at different levels, derived fact columns can only contain fact columns from the same fact table.
There are advantages and disadvantages to consider when deciding if you should create a derived fact column. The advantage of storing derived fact columns in the warehouse is that the calculation of data is previously performed and stored separately, which translates into simpler SQL and a speedier query at report run time. The disadvantage is that derived fact columns require more storage space and more time during the ETL process.
You can create the same type of data analysis in MicroStrategy with the use of metrics. Metrics allow you to perform calculations and aggregations on fact data from one or more fact columns. For more information on what metrics are and how to create them, see the Advanced Reporting Guide.
For more information on the different types of facts in MicroStrategy and how they are defined, see How facts are defined .

Fact table levels: The context of your data

Facts and fact tables have an associated level based on the attribute ID columns included in the fact table. For example, the following image shows two facts with an Item/Day/Call Center level.
The Item_id, Day_id, and Call_Ctr_id columns in the table above represent practical levels at which sales and inventory data can be analyzed on a report. The Sales and Inventory facts can be analyzed at the item, day, and call center levels because those levels exist as ID columns in the fact table.
You do not need to include more lookup column IDs than are necessary for a given fact table. For example, notice that the table above does not include the Customer_id column; this is because analyzing inventory data at the customer level does not result in a practical business calculation. Fact tables should only include attribute ID columns that represent levels at which you intend to analyze the specific fact data.

The levels at which facts are stored become especially important when you begin to have complex queries with multiple facts in multiple tables that are stored at levels different from one another, and when a reporting request involves still a different level. You must be able to support fact reporting at the business levels which users require.

For more details on the level of aggregation of your fact data, you could go through šŸ’ØšŸ’ØšŸ’ØšŸ’ØšŸ’ØšŸ’ØFact table levels: The context of your data.

Comments

Post a Comment

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

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

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

Microstrategy Dashboard performance improvements steps

Microstrategy  Dashboard performance improvements steps: Many times, causes of poor performance can be simplified to specific components. To troubleshoot performance issues, users must identify these components, then make the appropriate modifications to the environment and/or to the MicroStrategy dashboard to reduce bottlenecks. Dashboard execution stages can be represented below: MicroStrategy Intelligence Server When an end user makes a  Document Execution Request  through any client (a web browser via MicroStrategy Web, the MicroStrategy Desktop/Developer client, the MicroStrategy Mobile app, or the MicroStrategy Office client), the request is sent to the MicroStrategy Intelligence Server, which processes the request and prepares the response. The MicroStrategy Intelligence Server will execute all children datasets on the dashboard by either generating SQL and running this against the data warehouse, or by fetching data from a cache. The Inte...

Microstrategy Document Autotext macros:

Autotext  code/macros in  Microstrategy Document/dashboard This is a list of the available auto text macros that the Report Services Document engine recognizes. The following auto text codes allow you to add  document variable information to your document. These auto text codes are automatically replaced by information about the document. Auto text codes for MSTR document/dashboard:  AUTOTEXT DESCRIPTION   {&PAGE}  Display the current page.  {&NPAGES}  Display the total number of pages.  {&DATETIME}  Display the current date and time.  {&USER}  Display the user name that is executing the Report Services Document.  {&DOCUMENT}  Display the document name.  {&DOCUMENTID}  Display the document ID.  {&DESCRIPTION}  Display the document description.  {&PROJECT}  Display the project name.  {&EXECUTIONTIME}  Dis...

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

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

Best Practices for using images in Microstrategy reports

Using images in Microstrategy reports On the I-Server we copy the images to the following folders: - Program Files (x86)\MicroStrategy\Developer\Images - Program Files (x86)\MicroStrategy\IntelligenceServer\Images - Program Files (x86)\Common Files\MicroStrategy\images To reference an image using relative path, the following locations are required to store the image in order to display in multiple MicroStrategy products.    Relative path sample: images/ logo.jpg To display images on: MicroStrategy Desktop, Web, Mobile, Distribution Services: * Additional Adobe Flash security rule applies when displaying images on Flash Dashboard For image to display on MicroStrategy Web Services:   Note: It is recommended that HTTP path should be used for reference image. User should consider using HTTP path to reference image and store image in an client accessible server for easier maintain and upgrading purpose ...

Prompt-in-prompt(Nested Prompts) in Microstrategy

Prompt-in-prompt(Nested Prompts) in  Microstrategy Nested prompts allows you to create one prompt based on the other and other bases on another, nested prompts allows us to prompt the highest level(Like year) to middle level(like Quarter, then to the low level(like Month). Here you can see how to  create a 3-level deep nested prompt that will prompt the user to select a year, then a quarter within that year, then a month within that quarter. Prompt-in-prompt is a feature in which the answer to one prompt is used to define another prompt. This feature is only implemented for element list prompts . The following procedure describes how to achieve this: Create the highest level filter. This is a filter which contains a prompt on an attribute element list. Create a filter on the attribute "Year." Click "prompt on attribute element list" and click "Next" through the rest of the screens to accept the default values. Do not set any additio...

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.