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

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

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

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

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.

Update the data on an Intelligent Cube without having to republish the entire cube in MicroStrategy

Update the data on an Intelligent Cube without having to republish the entire cube in MicroStrategy MicroStrategy has introduced a feature known as, Incremental Refresh Options, which allow Intelligent Cubes to be updated based on one or more attributes, by setting up incremental refresh settings to update the Intelligent Cube with only new data. This can reduce the time and system resources necessary to update the Intelligent Cube periodically versus a full republish. For example, if a user has an Intelligent Cube that contains weekly sales data, the user may want this Intelligent Cube to be updated at the end of every week with the sales data for that week. By setting up incremental refresh settings, he can make it so that only data for one week is added to the Intelligent Cube, without affecting the existing data and without having to reload all existing data. Users can select t...

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 default sort order for an attribute elements browsing

MicroStrategy default sort order for an attribute elements browsing and display How does MicroStrategy 9.x resolve the default sort order for an attribute when different sort orders are defined for different forms? Consider the following cases: CASE 1 A new attribute is created with three forms, all with sort order set to none. Form Name Form Type Default Sort Order ID ID None DESC DESC None LongDesc None None The overall sort order is evaluated and stored in the attribute definition when the attribute is saved. With all form sort orders set to none there is no saved sort order, MicroStrategy defaults to sort ascending by ID. CASE 2 The same attribute is modified so the forms are now: Form Name Form Type Default Sort Order ID ID None DESC DESC Descending LongDesc None Ascending Now when the attribute is saved, MicroStrategy goes through each form in the order they appear in the main 'Forms' window of the attribute editor. The first...

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

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

mstrio – Python and R wrappers for the MicroStrategy

mstrio – Python and R wrappers for the MicroStrategy REST APIs Connecting to MicroStrategy  Create a connection to the Intelligence Server using   Connection()   and    connect()  in Python and R, respectively. Required arguments for the   Connection()  function are the URL for the MicroStrategy REST API server, MicroStrategy Intelligence Server username and password, as well as the MicroStrategy project name. By default, the   connect()  function anticipates your MicroStrategy Intelligence Server username and password. LDAP authentication is also supported. Use the optional argument    login_mode=16    in the    connect()  function for LDAP authentication.  Extract data from cubes and reports  To extract data from MicroStrategy cubes and reports, use the   get_cube()  and   get_report()  functions. Use...