Microstrategy Analytics

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 dialog box opens. To determine how

Microstrategy removing rows with Zero metric values If there are more than one metric and want to remove the rows with Zero metric values. There are several ways to do this but I guess the easiest one will be creating a Metric which is the sum of all the metrics to be used in the report. Such as Sum Metric = Metric 1 + Metric 2 + Metric 3 +........... The Sum Metric should be included in the report and it can be controlled by any of the ways below: 1) Adding a view filter to the report where  Sum Metric != 0 which will bring only non zero values 2) Creating a filter definition prompt with the  Sum Metric , so that when the rpeort is prompted user cans elect  Sum Metric value is >0 . Or we can jsut had code the filter  Sum Metric >0 if we want to pre-filter the report with non zero rows for all the metrics in the report. We can also use the report limits with metric values >0 with an and condition between each metric condition,

Creating Data Mart Reports in Microstrategy   When there is requirement to store all the report results to a database table you can use the interesting feature in Microstratgey called Data Mart Reports. To create a data mart table, you first create a data mart report that defines the columns of the data mart table. You then create the data mart table and populate it with data. The steps below walk you through the process of creating a data mart report and then executing the report to create a data mart table. The steps also include an example for most steps, based on Tutorial sample data in the MicroStrategy Tutorial project.                Follow the simple steps below to create a datamart report: 1 In MicroStrategy Developer, create a new report or select an existing report to use as the data mart table. The report should contain the attributes, metrics, and other objects that you want to use as columns in the data mart t

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

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

Homogeneous vs heterogeneous column naming Heterogeneous mapping: Suppose the data warehouse has information from two source systems, and in one source system regions are identified by column name Region_id and in the other the column name is Reg_id , as shown in the diagram below. Though the Region_id and Reg_id columns have different names, they store the same data: information about regions. This is called heterogeneous column naming . The data for the Lookup_Region table came from a different source system than the data for the Lookup_Call_Ctr and the source systems have different naming conventions. Homogeneous mapping: For consistency, it is a good idea for columns that contain the same data to have the same column name. This is called homogeneous column naming . In this case, the Region_ID column has the same name in both tables, as shown in the following diagram:

Relationship tables in Microstrategy Relate tables store information about the relationship between two attributes when one a parent of the other or vice-versa.. Relate tables contain the ID columns of two or more attributes, which will define associations between them. Relate tables are often used to create relationships between attributes that have a many-to-many relationship to each other. With attributes whose direct relationship is one-to-many—in which every element of a parent attribute can relate to multiple elements of a child attribute—you define parent-child relationships by placing the ID column of the parent attribute in the lookup table of the child attribute. The parent ID column in the child table is called a foreign key. This technique allows you to define relationships between attributes in the attributes’ lookup tables, creating tables that function as both lookup tables and relate tables as shown in the following diagram:

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 ver

Designing a Normalized Database from Microsoft Tables representing propositions about entities of one type (that is, representing a single set) are fully normalized. Correct and complete mapping of a conceptual ORM model to a logical model yields fully normalized tables. Properly designed entities in an ER model lead to fully normalized tables as well. However, both ORM and ER modeling start with the business description of a problem; it is possible to miss some dependencies between entities and leave some tables denormalized. Of course, there could also be a bug in the tool that produces the DDL script from the ORM and ER models. However, any denormalization can lead to update anomalies. Data integrity and consistency are fundamental for databases. Remember that a database holds propositions, and propositions are facts. If propositions are not true, they are not facts; they are falsehoods. You need a logical method that yields a fully normalized database. Normalization is

To display a group horizontally or Add sections horizontally: 1.  In MicroStrategy Web, open the document in  Design  or  Editable Mode . 2. From the  Tools  menu, select  Grouping . The Grouping panel is displayed. 3. In the Grouping panel, right-click the grouping field to display horizontally, and select  Grouping Properties . The Grouping Properties dialog box opens. 4 . Select the  Render  object name  horizontally  check box. 5 . Click  OK  to apply the changes and return to the document. Step1: Step 2: More Info: https://www2.microstrategy.com/producthelp/10.7/DocCreationGuide/WebHelp/Lang_1033/Content/DocumentCreationGuide/Displaying_a_group_horizontally.htm#grouping_and_sorting_4135344594_1105953

 Recommended VLDB Properties for use of  MicroStrategy 9 with Hive 0.7x The recommended VLDB optimizations for Hive 0.7x are listed below. These values are set by default when the "Hive 0.7x" database object is used (set at  Configuration Managers > Database Instances > Database Instance > Database connection type ) Selected Default VLDB Properties for Hive 0.7x  VLDB Category  VLDB Property Setting  Value   Tables  Fallback Table Type  Permanent Table  Tables  Maximum SQL Passes Before FallBack   0 (no threshold)  Tables  Maximum Tables in FROM Clause Before FallBack  0 (no threshold)  Tables  Drop Temp Table Method  Drop after final pass   Tables  Table Creation Type  Implicit Table  Query Optimizations   Sub Query Type   Use Temporary Table, falling back to IN (SELECT COL) for correlated subquery  Joins  Full Outer Join Support  Support  Select/Insert  Distinct/Group By option (when no aggregation and not tabl