MicroStrategy

Training

Mumbai, 11th September 2008

Agenda (1)
Introduction
BI Architecture Overview
MicroStrategy Architecture Overview
 MicroStrategy Desktop
 MicroStrategy Web
 MicroStrategy Intelligence Server
MicroStrategy Project Overview
Project creation – Key Concepts
Data Modelling – Logical Data Model
Data Modelling – Physical Data Model
MicroStrategy Project Builder
MicroStrategy Architect Tools
MicroStrategy Reports Overview
Practices/Exercises

2
Agenda (2)

Report creation – Key Concepts

Reporting Concepts
 Metrics
 Attributes
 Hierarchies
 Filters
 Custom Groups
 Consolidations
Report Editing
Aggregation
Partition Mapping
Logical Table Size
HTML Documents Overview
Other Concepts
Practices/Exercises

3
Data Exploration Technology

Report writers (“simple query

tools”)
OLAP - On line analytical
processing
MOLAP - Multidimensional On
Line Analytical Processing
ROLAP - Relational On Line
Analytical Processing
HOLAP - Hybrid On Line
Analytical Processing

4
ROLAP

Flexible Report Format

Access to all the data
available
Combine different
information: dimensions
and KPI’s
Totals by defined
Hierarchies
Complete Ad-hoc
Reporting may be
available
Direct Access to
Database

5
BI Architecture Overview
A typical BI architecture has the following components:
A source system (typically an OLTP system)
 Data access is optimized for frequent reading and writing.
 Data is aligned by application (business activities and workflow).
 Data formats are not necessarily uniform across systems.
 Data history is typically limited to recent or current data.

An extraction, transformation, and loading (ETL) process

 Represents all of the steps necessary to move data from different source systems to an integrated
data warehouse

A data warehouse (an OLAP/DSS system)

 Populated with data from the existing operational systems using an extraction, transformation, and
load (ETL) process.
 Data access is typically read-only. The most common action is select, with very few inserts,
updates, or deletes.
 Data is aligned by business subjects.
 Data history extends long term, usually two to five years.

A business intelligence (BI) platform

 Offers a complete set of tools for the creation, deployment, support, and maintenance of business
intelligence applications

6
 BI Architecture Overview
OLTP Data
Server Warehouse
Server
Intelligence Server Web Server

Operational
& Legacy
Systems
Data
WEB
Warehouse

Metadata
Closed-Loop ...
BI

Desktop

Mail
WAP
SMS

Transactor Server Narrowcast Server

7
MicroStrategy Project

What is a project?
The highest-level object in the MicroStrategy reporting environment.
The intersection of a Data Warehouse, metadata repository, and user
community.
Where you build and store all of the objects and information you need
to create an application.

A project …
Determines the set of warehouse tables to be used, and therefore the
set of data available to be analyzed.
Contains all of the schema objects used to interpret the data in those
tables (facts, attributes, hierarchies, and so on).
Contains all of the reporting objects used to create reports and
analyze the data (metrics, filters, reports, and so on).
Defines the security scheme under which the user community that will
access these objects will operate (security filters, security roles,
privileges, access control, and so on).

8
Project creation – Key Concepts

MicroStrategy Metadata
 Contains information in a relational database stored as
MicroStrategy objects.
 Facilitates the transfer of data between the data warehouse and
the MicroStrategy platform.
 Stores object definitions, information about the data warehouse.
 Maps MicroStrategy objects to the data warehouse structure and
content.

Project Source
 Contains the information necessary for MicroStrategy products to
connect to the metadata in which projects are stored.
 Stores the location of the metadata repository or of the
Intelligence Server definition that is used to host the projects.

9
Project creation – Key Concepts

Two types of project sources:

 Direct project sources connect directly to the metadata through ODBC.
 Server project sources connect to the metadata via an Intelligence
Server.
MicroStrategy
Desktop
Metadata (direct access)

Data
Warehouse

MicroStrategy
Intelligence Desktop
Server

A project is created within a specified metadata repository,

determined by the project source through which we create the
project.
The project’s warehouse location is specified by associating it with the
appropriate database instance.

10
Data Modelling – Logical Data Model

The logical data model

 Represents the definition, characteristics, and relationships of data in a
business, technical, or conceptual environment.
 An arrangement of data that is arranged logically for the general user, as
opposed to the physical data model or warehouse schema, which arranges
data for efficient database use.
 Similar in concept to needing a map and an itinerary when going on a trip.
You need to know where you are going and how to get there. You need a
plan, one that is visible and laid out correctly.

Logical data model components

 Facts
 Attributes
 Hierarchies

11
Logical Data Model - Facts

Facts
 Business measurements, data, or variables that are typically numeric and
suitable for aggregation.
 They relate numeric data values from the data warehouse to the
MicroStrategy reporting environment.
 Can come from different source
systems and they might have Year
Class
differing levels of detail. Month
 The rest of data modelling consists Subclass Week
mostly of providing context for Sku Day
these facts.
 In a data warehouse, facts typically
exist as columns featured in the
fact tables. Location

District

Region

Area

12
Logical Data Model - Attributes

Attributes
 Once the facts are determined, attributes must be identified.
 Attributes allow you to answer questions about a fact and provide a context
for reporting those facts.

Attribute elements
 Are the data shown on a report.
 Data usually refers to metric values.
 Allow you to qualify on data to get very specific results.

13
Logical Data Model - Attributes

Attribute relationships
 One-to-one - each element in the parent attribute has one and only one
corresponding element in the child attribute.
 One-to-many - each element in the parent attribute corresponds to two
or more elements in the child attribute
 Many-to-many - each element in the parent attribute can have multiple
children and each child element in the child attribute can have multiple
parents

Attribute forms
 Describe an attribute and one attribute can have many forms.
 Forms are displayed on reports.
 For example, Last Name, First Name, Phone Number, and E-mail Address
could each be forms of a Customer attribute.

Hierarchies
 In a logical data model are ordered groupings of attributes arranged to
reflect their relationship with other attributes.

14
Logical Data Model Summary
Four steps for creating a logical data model:
Identify the facts.
Identify the attributes.
Determine where there are attribute relationships.
Define hierarchies.

When all of the components are placed in a single diagram—facts,

attributes, relationships, and hierarchies—you get a logical data
model.

15
Data Modelling – Physical Data Model

The physical data model

 Based on the logical data model.
 It is a detailed graphic representation of your business data as it is
stored in the data warehouse.
 It organizes the logical model in a method that make sense from a
database perspective.

 Two key components make up the physical warehouse schema: tables

and columns

16
Physical Data Model – Key components -Tables
There are three types of tables:
 lookup tables
 relate tables
 fact tables

Lookup tables
 Lookup tables are the physical representation
of attributes.
 They provide the ability to aggregate data at
different levels.
 Functionally, lookup tables provide the
information for a attribute through data
stored in their ID and description columns.
 a lookup table might store information for one or more related
attributes.
 If a table only stores data about one attribute, it is said to be a
normalized table.
 Notice that the denormalized table holds the exact same data as
the three normalized tables.

17
Physical Data Model – Key components -Tables
Relate tables
 While lookup tables store information about one or more attributes,
relate tables store information about the relationship between two
attributes.
 Relate tables contain the ID columns of two or more attributes, thus
defining associations between them.
 With attributes whose direct relationship is one-to-many, 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.
 Possible to define
relationships between
attributes in the attributes’
lookup tables, creating
tables that function as
both lookup tables and
relate

18
Physical Data Model – Key components -Tables
 In the case of a many-to-many relationship, you must create a
separate relate table as shown in the following diagram:

19
Physical Data Model – Key components -Tables
Attribute relationships and lookup table structure
Attribute relationships are a major factor in determining the structure
of lookup tables in a physical warehouse schema. In general, the
following guidelines apply:

 One-to-one relationships - usually denote the existence of an

attribute form. The description column for the attribute form should
simply be included as an additional column in the attribute’s lookup
table.

 One-to-many relationships - there are various ways to model one-

to-many relationships in the physical warehouse schema, each with
its own advantages and disadvantages.

 Many-to-many relationships - usually require the use of a relate

table distinct from either attribute lookup table. The relate table
should include the ID columns of the two attributes in question.

20
Physical Data Model – Key components -Tables
Fact tables
 Fact tables are used to store fact data.
 Since attributes are what give meaning to fact values, both fact
columns and attribute ID columns are included in fact tables—that is,
facts exist at the intersection of indirectly related attributes.
 The attribute ID columns included in a fact table represent the level
at which the facts in that table are stored.

21
Physical Data Model – Key components - Columns
Table Keys
 In relational databases, each table has a primary key that creates a
unique value identifying each distinct data record (or row).

There are two types of keys:

 Simple key - requires only one column to identify a record uniquely
within a table.
 Compound key - requires multiple columns to identify a unique record.

22
Physical Data Model – Key components - Columns
Homogeneous versus heterogeneous
column naming

 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 reality, it is possible that the two

columns will not have the same name.

 When the columns have different

names, but they store the same data,
is called heterogeneous column
naming

23
Physical Data Model – Key components - Columns
Base fact columns versus derived fact columns
There are two types of fact
columns:

 Base fact columns - are

represented by a single column
in a fact table.

 Derived fact columns are

created through a
mathematical combination of
other existing fact columns.

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.

24
MicroStrategy Project Builder

Wizard designed to create simple MicroStrategy

projects.
Created with speed in mind, so it provides only
a subset of the features and functionality of
MicroStrategy.
Limited to adding a few tables at a time.
By default, Project Builder uses a Microsoft
Access database for the metadata repository.
It’s suitable to change the default setting and
allow Project Builder to use your preferred
database platform for the metadata repository
MicroStrategy Architect Tools can be used to
add greater functionality to any project created
using Project Builder.

25
MicroStrategy Architect Tools

Warehouse Catalog
Lists the tables present in the database to which your project’s
database instance connects. From this list, you can choose which
tables to add to your project.
Every project can have a unique set of warehouse tables.
Much faster and more efficient to add large numbers of tables using
the Warehouse Catalog than Project Builder.

Fact Creation Wizard

Allows you to create multiple facts quickly and easily, however it does
limit you to creating simple facts and it does not allow you to edit
existing facts.
Use as part of the initial project creation, for creating most of the
facts for the project.
Use the Fact Editor to add complexity to existing facts as your project
evolves.

26
MicroStrategy Architect Tools

Attribute Creation Wizard

The Attribute Creation Wizard guides you through creating new
attributes to use in your project:
 Select attribute ID columns to identify the columns in the warehouse that
represent the unique IDs for your attributes.
 Select attribute description columns to identify the default description
columns for the attributes.
 Select attribute lookup tables to identify the primary lookup tables for the
attributes.
 Define attribute relationships to determine the parent-child relationships
between the attributes. These are used to build the System Hierarchy and
define how MicroStrategy products interpret and understand relationships
between the data.

An ID column is a column or group of columns that uniquely

identifies each element of an attribute. When choosing the ID
column for an attribute, make sure that all values in the column
are unique and that it does not contain NULL values.
27
Next Steps …

Now you have enhanced the project that you

created with Project Builder by adding additional
facts and attributes using MicroStrategy Architect
tools.

28
MicroStrategy Reports
What is a report?
A report is a MicroStrategy object that represents a request .
for a specific set of formatted data from the data warehouse.
It’s typically composed of three main objects: metrics, attributes, and filters:

 Metrics
- MicroStrategy objects that represent business measures. They describe calculations
to be performed on data from the data warehouse in a manner similar to formulae in
spreadsheet software.

 Attributes
- Qualify business metrics and give them meaning. Metrics in the report are only
meaningful if they are referenced by one or more attributes.

 Filters
- Limit or constrain the data in the report so that it contains only the information that
is pertinent to the problem that is being investigated.
Reports may also contain other objects such as prompts,
hierarchies, consolidations and custom groups.

29
Reports Templates(1)
A template defines the layout of general categories of information in
a report.
In a template, you specify the information you want to retrieve from
the data warehouse and the way you want it to be displayed on the
report.
The layout of a template can be cross-tab or tabular.
 A cross-tab layout is useful for multidimensional analysis. For example, a
report with location information in the columns and corresponding sales
information in the rows.

 A tabular layout is useful for simple lists of information. For example, a

column of regions and a column of stores, followed by corresponding
columns of sales figures.

30
Reports Templates(2)
The Template Editor allows you to create and modify templates.
Before you begin using the Template Editor, you should:
 Know the report needs of your end users
 Be familiar with the different template layouts
 Know the rules for template object placement

Altering a template can affect reports. If a metric is removed from a

template, the change may affect all, some, or none of the dependent
reports.

When a template is modified or saved in Desktop, the Template

Dependency Validator is triggered. It lists:
 reports that depend on the template
 reports that will not run if the change is complete

You can create a stand-alone template in the Template Editor, and

you can create a report-specific template using the Report Editor.
31
Metrics
Metrics represent business measures and key performance indicators.
Also represent calculations to be performed on data stored in the
database, and are similar to formulas in spreadsheet software.
Metric types - Metrics can be categorized as one of these types:
 Simple metrics - can stand alone or be used as building blocks for
compound metrics. Simple metrics always have a formula and a level.
The entire metric can only contain one level.

 Compound metrics - cannot have a level placed on the entire metric,

although it can be set separately on each of the components.

32
Metrics – Simple metrics
Metrics are constructed of components that differentiate one metric
from all others and also serve as criteria for defining the calculations
and data included in each metric.
Simple metrics include the following components:
 The formula - defines the data to be used and the calculations to be
performed on the data. The outermost formula must be a group function.
 The level, or dimensionality - determines the level at which to perform the
metric calculation. For example, you can choose to calculate at the month
level or year level.
 Conditionality - associates a filter to the metric calculation. This is an
optional component.
 The transformation - applies offset values, such as “four months ago,” to
the selected attributes. This is also an optional component.

EXAMPLE

33
Metrics – Formulas
Formula
 The essential part of the metric
definition.
 Is a mathematical expression
consisting of group functions, such as
sum, average, minimum, maximum,
and so on.
 Also includes the data to be used in
the calculations. This can include
facts, attributes, constants, and
other metrics.
 Can also contain a non-group
function or arithmetic operator, in
addition to the required group
function.
 In SQL, the formula becomes part of
the SELECT clause of the SQL
command.

34
Metrics – Base Formulas
Base formulas
 You can recycle a formula to use it in multiple metric definitions. This is
called a base formula, which can contain arithmetic operators, attributes,
facts, group functions, metrics, and non-group functions.

Using a base formula allows you to:

 update multiple metrics by
modifying the base formula
only once.
 find or categorize all the
metrics that use a common
base formula
 use a simple expression as a
base formula to facilitate the
creation of more complex
metrics
 use it as a formula in simple
or compound metrics

35
Metrics – Level (Dimensionality)
Level
 The level of a metric, also referred to as dimensionality, allows you to
determine the attribute level at which the metric is calculated. In addition,
you can specify the grouping and filtering involved in a metric
 All metrics, by default, calculate at the report level. This means that the
attributes on the report template dictate how the metric is aggregated.

 The elements needed to specify a level

for a particular metric are:
– Target
– Grouping
– Filtering

 A target, grouping, and filtering

combination composes one level unit.
 Grouping and filtering are independent
of each other. That is, the target and
grouping work together to determine
the level, and the target and filtering
also work together to establish the
level.
36
Metrics Level – Target

The target is the attribute level

at which the metric calculation
groups.

It determines the table to use to

calculate the metric.

Any set of attributes or a

hierarchy can be the target.

A special case is the default

target, which is report level.

37
Metrics Level – Grouping(1)
Grouping determines how the metric aggregates. The result of this
setting is reflected in the GROUP BY clause of the SQL command.
The grouping options for levels include:
 Standard - groups by the attribute level of the target. That is, the metric
calculates at the level of the target, if possible.
 None - excludes the attribute in the target from the GROUP BY clause.

None is not an option if the target is set to the report level.

Also include
 Beginning lookup - uses the first value of the lookup table.
 Ending lookup - uses the last value of the lookup table.
 Beginning fact - accesses the first value of the fact table.
 Ending fact - accesses the last value contained in the fact table.

This last four options are only used for nonaggregatable metrics. A nonaggregatable
metric is one that should not be aggregated across an attribute.

An example is an inventory metric. Instead of summing values, you may want to use
the End-On-Hand and Beginning-On-Hand inventory numbers to see how the total
inventory changed over the time.

38
Metrics Level – Grouping(2)

39
Metrics Level – Grouping(3)

40
Metrics Level – Filtering

The filtering setting governs the relationship between the report filter
and the calculation of the metric. The filtering options are:
 Standard filtering - does not change the filter applied to the report.

 Absolute filtering - raises elements in the report filter to the level of the
specified attribute.

– If the attribute in the metric filter is a parent of the attribute in the

report filter, calculations are performed only on elements to which the
report filter applies.

– If the attribute in the metric filter is of the same level or a child of the
level in the report filter, calculations occur as specified by the report
filter.

Absolute filtering influences what is displayed on the report, not its

calculations.

41
Metrics Level – Filtering (2)

 Ignore filtering - omits filtering criteria based on the attribute in the target
and its related attributes (parents and children). The report filter does not
appear anywhere in the SQL for a metric with this setting.

 None - can be summarized as unspecified — the filtering behaviour for the

target is not determined by this component. Instead, the target and group
components of this level unit define the filter.

– If the report includes an attribute in the same hierarchy as that

indicated by the metric filter, aggregation takes place at the level of
that attribute.

– If the report does not include other attributes in the same hierarchy as
that indicated by the metric filter, aggregation defaults to the
“Absolute” option.

42
Metrics - Conditionality

Metric conditionality applies a filter to the metric calculation. You can

think of conditionality as attaching a filter to each metric.
Only metrics with an aggregate operator in the formula can use
conditionality.
Only one filter can be associated with a simple metric, although that
filter can contain as many filtering conditions as needed.
The Advanced options for conditionality allow you to select how the
report filter and metric filter interact, as described below:

 Merge report filter into metric - is the default setting. The report filter
criteria is applied to the data first. Then the metric filter is applied to the
results of the first evaluation.
 Merge metric condition into report - evaluates the metric filter first, then
applies the report filter to those results.
 Merge into new - intersects the metric and report filter.

43
Metrics - Transformation

A transformation is a schema object that encapsulates a business rule

used to compare results of different time periods.
Two types of transformations:
 Expression-based Transformations.
 Table-based Transformations.

Transformations are generally used for time-series analysis, for

example, to compare values at different times such as this year versus
last year, or month-to-date.

A Transformation metric is an otherwise simple metric that takes the

properties of the transformation applied to it.
For example, a metric calculates total revenue. Add a transformation
for last year and the metric now calculates last year’s total revenue.
Any transformation can be included as part of the definition of a metric
and multiple transformations can be applied to the same metric.
44
Metrics – Compound Metrics
A compound metric is a combination of expressions that, through the
use of functions, are themselves metrics. These expressions define
the data to be used and the calculations to be performed on that
data. The calculations can be group or non-group functions. The data
can be facts, attributes, constants, or other metrics.
A compound metric does not have to perform an additional
aggregation as does a simple metric. The two metrics can instead be
calculated individually. Those results are used to compute the final
result, as in the following diagram.
EXAMPLE

45
Metrics – Smart Metrics
The smart metric property of a compound metric allows you to
change the default evaluation order of the metric.

The report contains information

about sales. If you display
totals without allowing smart
metrics, the totals are incorrect.
To calculate the correct answer,
the total should be based on the
totals in the other Total Sales
and Discount Sales columns
instead.

Smart metrics calculate subtotals on the individual elements of

the compound metric.
For example, a smart metric uses the formula
Sum(Metric1)/Sum(Metric2) rather than Sum(Metric1/Metric2).

46
Metrics – Aggregation

Aggregation allow you to control how metrics are further computed or

rolled up.

These functions reflect only those most frequently used for further
aggregation of metrics or for evaluating metric subtotals.
47
Metrics – Subtotals

In the context of metrics, subtotals permit computation and

display of quantified data, gathered by MicroStrategy along
attribute groupings that you can specify dynamically for a report.

When a report containing that

metric is run, a user can choose
which of these subtotals to display.

The behaviour of subtotal

aggregations is based on the types
of data included in the metric to
which the subtotal is applied.

You can also create user-defined

subtotals, which allow you to
develop your own subtotals, using
aggregation or nested functions,
constants, and combinations of
these objects.
48
Metrics – Join Specification

You can set joins at the metric and report levels:

 metric: how the metric is joined to other metrics
 report: how metrics are joined together in the report; overrides metric join
settings for that report only

49
Metrics – Specific VLDB properties

Affect how MicroStrategy

Intelligence Server manages joins,
metric calculations, and query
optimizations, among others.
Available at multiple levels, so
that SQL generated for one report
can be manipulated separately
from the SQL generated for a
different report.
Metric-specific VLDB properties
that can be set at the metric level
include:
 Metric Join Type
 Null Check
 Zero Check
 Null Checking for Analytical Engine
 Subtotal Dimensionality Aware

50
VLDB properties

51
Metrics – Useful functions(1)
Rank
 In rank functions, you specify the metric to be ranked and whether to rank in
ascending or descending order.

Rank<Null=True, ASC=False>(Revenue {~+} )

Count
 Is usually used with an attribute, although a fact can also be counted. You can
specify whether to count from a fact or a lookup table and whether to count
distinct occurrences of the target.

Count<Distinct=True, Null=True, FactID=Revenue>(Item) {~+}

N-tile
 The N-tile function, which is also referred to as segmentation, sets up numbers
of groups, or tiles, for a metric. An example of an N-tile function in use is
displaying what items are in the top 25% of sales, the next 25%, and so on.

NTile(Revenue)

52
Metrics – Useful functions (2)
Running and moving sums and averages
 These functions include
• moving average
• moving sum
• running average
• running sum

 All these functions are similar and are called OLAP functions.

RunningSum(Revenue) <Sort Ascending by Date>

First and Last

 The First and Last functions provide the ability to use sort-by inside
aggregation functions, that is, functions where the value depends on the
sort order.
 First returns the First value in a sorted set of values, while Last returns the
last value. You can define the sort attributes in the function parameters.

Last<FactID=[Total Amount], SortBy= (Value) >(Revenue) {~+}

53
Attributes(1)
Attributes represent entities in the business model and are normally
identified by a unique ID column in the data warehouse.

Attributes allow you to define the level of aggregation for a metric.

If two attributes represent the same data in different tables with
different column names, you can link them together.

Attributes must be
distinct and group,
but not share,
elements.

Attributes allow you

to define the level of
aggregation for a
metric .

54
Attributes(2)
If an attribute requires more than one ID column to uniquely
identify it (called a compound key), it is called a compound attribute
and you must specify the number of ID columns required

When choosing the ID

column for an
attribute, make sure
that all values in the
column are unique and
that it does not
contain NULL values.

Although Desktop will allow it, you should never use as the ID
column for an attribute a column that has NULL or repeated values.
Doing so will result in unexpected behaviour and errors.
55
Attribute Relationships
The relationships give meaning to the data by providing logical
associations of attributes based on business rules.
Every direct relationship between attributes has two parts—a parent
and a child.
 A child must always have a parent.
 A parent can have multiple children.

Three types of
relationships can exist
between directly related
attributes, and they are
defined by the attribute
elements that exist in the
related attributes:
 One-to-one
 One-to-many
 Many-to-many

56
Nonrelated attributes

Care must be taken when using nonrelated attributes on a single

report,

If there is no relationship defined between two attributes in a lookup

or relationship table, a metric based on the relating fact must be
present on the report to avoid a Cartesian join, which is generally —
though not always— undesirable.

In the absence of a metric based on a fact that relates two nonrelated

attributes, a relationship filter can be used to force the engine to
establish the relationship in the table of your choice.

57
Attribute Forms
An attribute form describes an attribute and one attribute can have
many forms.
For example, Last Name, First Name, Phone Number, and E-mail
Address could each be forms of a Customer attribute.

You can change

some properties of
the different objects
such as the name
and description of
the object, the type
of object, and
object type details.

Notice that forms

are displayed on
reports.

58
Hierarchies
Hierarchies are ordered groupings of
attributes arranged to reflect their
relationship with other attributes.
Attributes in one hierarchy are not directly
related to attributes in another hierarchy.
Usually the best design for a hierarchy is to
organize or group attributes into logical
business areas.
For example, we can group the attributes
Year, Quarter, Month of Year, Month, and
Day to form the Time hierarchy.
One year has many quarters and both
attributes are in the Time hierarchy. You do
not need any additional information to
establish the relationship between the two
attributes.

59
Hierarchy Types
There are two types of hierarchies:
System hierarchy:
 The default hierarchy that MicroStrategy 7i sets up for you each time
you create a project.
 Specifies an ordered set of all attributes in the project but does not
define ordering or grouping among attributes.
 Represents the relationships as defined by the logical data model. There
is only one system hierarchy in each project.
 The system hierarchy cannot be edited but is updated every time you
add or remove children or parents in the Attribute Editor.
 Attributes from the system hierarchy do not need to be part of an
explicitly-defined user hierarchy.
User hierarchy:
 Are named sets of attributes and their relationships, arranged in specific
sequences for a logical business organization.
 They are user-defined and do not need to follow the logical model.
 You should define user hierarchies that correspond to specific areas of
your company business model and data warehouse schema.

60
Filters

A filter specifies the conditions that the data must meet to be

included in the report results.
Types of filters:
 A report filter that is a criterion used to select the data to calculate the
metrics in the report

 A report limit that specifies a set of criteria used to restrict the data
returned in the report data set after the report metrics are calculated.
Because it is based on the report’s metric values, a limit is applied after all
metrics are calculated.

 A view filter that is an additional filter applied in memory to the report

data set. It affects only the view definition.

Located at “Public Objects” folder

61
Report Filter
The following options are available while creating filters:
 Attribute qualification - allows you to filter on an attribute’s form (ID,
description, and so on) or on elements of the attribute.

 Set qualification - allows you to create a set based on one of the

following:
– a metric (also known as a metric qualification)
– a relationship filter

 Shortcut to a report, which is also referred to as Report as filter, uses an

existing report as a filter.

 Shortcut to a filter uses an existing filter as a base to which you can add
more conditions to further refine the filter.
 Advanced qualification lets you create one of the following:
– a custom expression, including a relationship filter
– a joint element list, which allows you to join attribute elements and then filter
on that result set

You can also create filters that prompt you for answers when you run
the report.
62
Report Filter – Attribute qualification
Attribute qualification
 Attribute qualifiers enable you to specify conditions that attribute elements
must satisfy to be included in the filter definition.
 For example, you can create a qualification on the attribute Month so that
the result set returns only months beginning with the letter “J”.

Attribute element list qualification

 Attribute element list qualifications allow you to qualify on a list of
attribute elements.
 For example, in a report, you can use an attribute element list
qualification on the attribute Customer, to return data only for those
customers that you specify in your list.

Attribute form qualification

 Attribute form qualifications allow you to qualify on an attribute form.
 For example, to return data only for those customers whose last names
start with the letter H, you can use an attribute form qualification for the
form Customer Last Name in a report.
 Another example, return data only for Monday of this week (using
dynamic dates).

63
Report Filter – Attribute qualification
Attribute-to-attribute qualification
 Allows you to create reports that compare two attributes through attribute
forms.
 For example, using attribute-to-attribute qualifications, by comparing
order date with ship date, you can create a report that displays the orders
that were shipped within a week of their order date.

Attribute Qualification Prompt

 An attribute qualification prompt allows you to qualify on the values of
attribute elements, attribute forms, or operators when you run a report.
 Types of attribute qualification prompts:
– Choose from all attributes in a hierarchy : You can choose just the attributes
from the selected hierarchy.

– Choose from an attribute element list : You can choose an attribute from a list
of attributes and qualify on the elements of the attribute.

– Value prompt : allows you to select a single value on which to qualify, such as a
date, a specific number, or a specific text string.

– Qualify on an attribute : You can choose an attribute from a list of attributes

and qualify on an attribute form.

64
Report Filter – Set qualification
Metric (set) qualification
 Metric qualifiers enable you to restrict metric values based on value, rank,
or rank percentage. Metric qualifiers restrict the amount of data used to
calculate the metrics on a report.

 You have the following options while creating a metric qualification:

– Output level defines the set of data that this set qualification
contributes to the filter as a whole.
– Break By feature allows you to choose the attribute level at which to
restart counting rank or percent values for a metric.

 For example, a store manager might want to see sales numbers for
products whose current inventory levels fall below a certain level. Notice
that, the report will not necessarily display the inventory figures for those
products. Let’s see two different break by examples:

65
Report Filter – Set qualification
Metric qualification prompt
 Allows you to select a function, or an operator, or specify the value for a
metric, when you run a report.

 You can create the following types of metric qualification prompts:

– Qualify on a metric prompt - allows you to qualify on a metric. You
can choose a metric by specifying a single metric to use when the
report is run or by specifying a search object to restrict the list of
metrics from which you can choose a metric, when a report is run.

– Metric Object prompt - allows you to select one or more metrics

that meet specific criteria when a report is run. For example, you
could use a search to return a list of all metrics that contain a certain
fact. From that list of metrics, you can then choose the metrics that
you want to see on the report.

– Value prompt - allows you to select a single value on which to

qualify, such as a date, a specific number, or a specific text string.

66
Report Filter – Set qualification
Relationship qualification (filter)
 Relationship qualification allows you to create a link between two
attributes and place a filter on that relationship. It allows you to create a
set of elements from an attribute based on its relationship with another
attribute.
 You have the following options while creating a relationship qualification:
– Output level - It is the level at which the set can be calculated.

– Filter Qualification - area allows you to define the input filtering

criteria. You can choose attribute qualification, a filter qualification, or
a metric qualification.

– Relate output level and filter qualification by - It is the relation

between the attributes in the output level and filter qualification. The
relation can be a fact, a table, or an empty filter.

 For example, to create a report that shows all the stores selling Nike shoes
in the Washington DC area, you need to set the output level to Stores, the
filter qualification to Nike shoes and Region, the relation to the fact sales.

67
Report Filter – Shortcut to a Report/Filter
Shortcut to a Report
 Also known as Report as filter.
 The report data set of an existing report can be used as a filter for another
report.
 When used as a filter, only the report’s data definition is considered.
 The report object prompt allows you to choose the results of one report to
be included in another report.

Reports with consolidations or custom groups cannot be used as a shortcut

to a filter.

Shortcut to a Filter
 Allows you to use an existing filter, or add conditions to that filter, to
apply to a report.
 The filter object prompt allows you to choose the filters to be included in a
report.

68
Report Filter – Advanced Filtering
Pass-through expressions, or apply functions, in MicroStrategy are
intended to provide access to the special functions or syntactic
constructs that are not standard in MicroStrategy, but are found in
various RDBMS platforms.
There are five predefined apply functions, each belonging to a
different function type:
 ApplySimple - Single-value function
 ApplyAgg - Group-value function
 ApplyOLAP - OLAP function
 ApplyComparison - Comparison function
 ApplyLogical - Logical function

Among these five functions, Apply Comparison and Apply Logical can
be used to create custom expressions for filtering.
 Ex: ApplyComparison ("#0>#1",Store@ID,Month@ID)
ApplyLogic ("#0 AND #1", Year@ID > 2002, Month@ID > 200201)

While an Apply function can be used wherever the function group it

belongs to is applied, you should NOT use any Apply functions when
standard MicroStrategy functions can be used to achieve the goal.
69
Report Limit & View filter
Report Limit
 After all the metrics are calculated, you may need to further restrict the
data, without changing how the calculations were performed.
 Report limit specifies a set of criteria used to restrict the data returned in
the report data set after the report metrics are calculated.
 Because it is based on the report’s metric values, a limit is applied after all
of them are calculated.

View Filter
 A quick qualification applied in memory to the report data set.
 Because it affects only the view definition, the report does not have to be
re-executed in the data warehouse.
 A view filter, just as the report limit, is always applied at the level of the
Report Objects list. However, the report limit and the view filter are not
interchangeable.
 In contrast, the view filter is applied to the report data set without altering
its size
This functionality requires MicroStrategy OLAP Services.

70
Prompts
MicroStrategy object that allows user interaction at report run
time.
The prompt object is incomplete by design. The user is asked
during the report resolution phase of report execution to provide
an answer to complete the information.
By using a prompt in a filter or template, you can:
 apply filtering conditions to the report, a custom group on the report,
or a metric on the report
 choose what objects, such as attributes and metrics, are included in the
report

Prompts allow you to determine how the report returns data from
the data warehouse.
Prompts save you time. Instead of building several different
reports, a simple question can be asked just before the report is
executed.
There are many types of prompts, and each type allows a different
type of question to be asked.
71
Prompt properties
Although each of the prompt types available has distinct
capabilities to provide a specific set of conditions, there are certain
properties that all prompts share:

 Title - identifies and differentiates the prompt.

 Description - indicates to the end user the nature or purpose of the

prompt.

 Default - contains the default answer to the prompt, if one was

specified.

 Maximum and minimum - determine how many answers a user

must/is allowed to choose (optional).

 Web options - define how the prompt appears in MicroStrategy Web.

72
Types of Prompts

Filter definition prompt - encompasses four different prompt

types, all of which allow the user to define the filtering criteria:
attributes in a hierarchy, attribute forms, attribute element lists,
and metrics.

Object prompt - allows you to select which MicroStrategy objects

to include in a report, such as attributes, metrics, custom groups
and so on. Object prompts can either determine the definition of
the report template or the report filter.

Value prompt - allows you to select a single value such as a date,

a specific number, or a specific text string. The value chosen by
the user is compared to metric or attribute element values, and
thus determines the data viewed by the user.

Level prompt - allows you to specify the level of calculation for a

metric.
73
Custom Groups
A custom group is an object that can be placed on a template and is
made up of a collection of elements called custom group elements.
Each custom group element can be labelled with a meaningful header
and can include a logical expression containing any of the following:
 attribute qualification
 set qualification
 report object
 filter object
 custom group banding
qualifications

A custom group element

can also use combinations
of any of the components
listed above, except
custom group banding
qualifications.

74
Custom Groups – Banding qualifications(1)
Banding qualifiers enable you to create banding custom group
elements. Banding is a method of slicing a list, defined by the output
level, of attribute elements using the values of a metric
You can apply different types of banding:
 Band size: to slice the range of metric values defined by “start at” and
“stop at” values into a number of bands, each defined by the parameter
“step size.”

 For example, in the

following diagram the
“start at” value is 10,
“stop at” is 50, and
“step size” is 10.

 These settings slice

the group into four
bands.

75
Custom Groups – Banding qualifications(2)
 Band count: to define the number of equal bands into which the range of
metric values is sliced. On the other hand, you use band size to define the
size of each band.
 For example, in the preceding diagram, the band count is set to four,
which has the same effect as the band size example. If you set the band
count to five instead, eight bands are produced.

 Banding points: to specify the value where a band is placed. This

enables you to produce bands of different sizes.
 For example, you want to create a report with two bands, one band
showing the top 10 stores and the second band showing stores 11-100.
For this, you must use three points — 1, 10, and 100—as shown in the
following figure.

76
Consolidations(1)

Consolidations enable you to group together and to pick specific

attribute elements.
Further, consolidations allow you to avoid changing the data model,
although in a limited way.

They also allow you

to place this grouping
of attribute elements
on a template just
like an attribute.

The elements of the

consolidation appear
as rows on your
report, and they can
have arithmetic
calculations.
77
Consolidations(2)

Consolidation elements do
not have to be based on a
single attribute.
You can use attributes at
different levels, such as
Region and Country.
Unrelated attributes, such
as Region and Year can
also be used.
Consolidations provide
two powerful functions
that enhance your
reporting needs. These
two functions are:
 Create a “virtual”
attribute
 Perform row level math

78
Consolidations – Create a virtual attribute
In the example of the Seasons consolidation, the four different
season consolidation elements are made up by adding together the
respective Months of Year that belong to the different seasons.
The effect appears as if you had a Seasons attribute in your data
model.

Of course, you can get the same effect

if you change your data model, and
actually add a Seasons attribute to
your Time hierarchy.
However, adding an attribute is
generally a very complex task because
you have to ensure that the proper
lookup and relationship tables exist in
the warehouse.
You are not limited to just adding. In fact, you can perform any
simple arithmetic operation while building your consolidation.

79
Consolidations – Perform row level math
Consolidations allow mathematical operations between elements or
element groups. That is, you can perform arithmetic operations such
as addition, multiplication, division, and subtraction.
This feature makes consolidations a
powerful tool in reporting.
It allows you to have a row in a report
that is specified by a mathematical
operation.
Continuing with the Seasons example,
the ratio of sales between different
seasons can be calculated using row
level math in a consolidation
Without consolidations, creating this analysis would be, at least,
cumbersome.
Notice that elements are formatted as dollars ($) and percentages
(%) in the same consolidation. You can format individual consolidation
elements in the Consolidation Editor.
80
Report Design VS Report Creation

Report design
 The process of building reports from basic report components in
MicroStrategy Desktop and Web.
 The most generic method for defining a report.
 Requires the most in-depth knowledge of the project.
 In general, this method should be available only to the select group of
advanced users and report designers who will design reports for others to
use.

Report creation
 The process of building reports from existing, pre-designed reports either
in Desktop or in Web.
 Report creation is different from report design in that it provides a more
guided experience and does not require your users to have a thorough
understanding of the project.
 Allows your users to create their own reports in a controlled, user-friendly
environment.

81
Reports – Display views

There are four report view modes:

 Design View: describes the report definition and allows you to

create and edit reports. The attributes, metrics, and other objects
to be used in the report are displayed. You do not have to execute
the report to view or modify the report structure.

 Grid View: offers a formatted, cross-tabular display of the actual

report data after the report is executed.

 Graph View: is similar to Grid View, but the display is in a

graphical format instead of cross-tabular.

 SQL View: displays the SQL generated by the MicroStrategy

Engine and executed in the warehouse. It also includes various
execution statistics.

82
Report Editing – Sorting
Sorting
 You can sort the data on the report without re-executing the report
against the warehouse.
 Sorting allows you to specify ascending or descending order to present
the report data for a particular row or column.
 You can select what objects you want to sort, the sorting criteria, and the
sorting order.

83
Report Editing - Page-by
Page-by and pivoting
 In Desktop and MicroStrategy Web you can reorganize report data by
swapping objects within an axis or by moving objects from one axis to
another.
 In particular, you can move objects to the Page axis, which causes the report
results to be divided into separate pages according to the object in the Page-
By.

84
Report Editing - Subtotals
Subtotals
 In Desktop and MicroStrategy Web you can add, remove, and edit the
subtotals at different levels for metrics on the report.
 The subtotal functions available include sum, count, min, max, average,
mean, median, and more.
 You might choose to display all subtotals, grand total only, or subtotals across
levels, where you select the object to be subtotalled.

85
Report Editing – Outline Mode
Outline Mode
 You can create an indented grouping of related attribute elements by
turning on Outline mode in Desktop and MicroStrategy Web.
 This is similar to Outline mode in a standard word processor.
 Outline mode allows you to collapse and expand sections of related data.
 This function is particularly useful in instances where the information
displayed would otherwise involve repetitive entries.

86
Aggregations
The lowest-level fact table (that contains atomic-level data), is
referred to as a base table.

In these terms, an aggregate

table is any fact table whose
data is derived by aggregating
data from an existing base
table.

By default, aggregation occurs

dynamically with a SQL
statement at report run-time.

Notice that, MicroStrategy

creates aggregates only on fact
tables, since lookup tables and
relationship tables are usually
significantly smaller.
87
Pre-aggregation

Aggregation can also be

completed before reports are
run, with the results stored in
an aggregate table.

This process is usually called

pre-aggregation.

Pre-aggregated tables can be

build as part of the ETL
process.

Pre-aggregation eliminates the

reading, sorting, and
calculation of data from many
rows in a large, lower-level
fact table at run time.
88
Partition mapping

Partition mapping divides large logical tables into smaller physical

tables based on a definable data level, such as month or department.
Partitions improve query performance by minimizing the number of
tables and records within a table that must be read to satisfy queries
issued against the warehouse.
By distributing usage across multiple tables, partitions improve the
speed and efficiency of database queries.
Time is the most common category for partitioning databases.
Partitioning by time limits growth of the database tables and
increases stability.
Partitioning can be managed by either the database server or the
MicroStrategy application.

Either way, the tables are partitioned at the database level —

the terms application and server refer to what manages the
partitioned tables, not where the tables are split.

89
Partition mapping - Server-level partitioning

In RDBMS server-level partitioning, the database server rather

than MicroStrategy manages the partitioned tables.

The original fact table is not physically broken into smaller tables.

Instead, the database server logically partitions the table

according to parameters specified by the database administrator.

You do not need to take any action in MicroStrategy to support the

partitioning.

Since only the logical table is displayed to the end user, the
partitioning is transparent to MicroStrategy.

90
Partition mapping - Application-level partitioning

In application-level partitioning the application, rather than the

RDBMS server, manages the partition tables.

A partition base table (PBT) is a warehouse table that contains one

part of a larger set of data.

Partition tables are usually divided along logical lines, such as time
or geography.

Starting MicroStrategy7i two types of partitioning are supported:

 Metadata partition mapping - stores the mapping information in the
project metadata.
 Warehouse partition mapping - uses a specialized warehouse table
to determine which table to access.

91
Metadata partition mapping

In a metadata partition mapping, you specify one or more

partitioning attributes in the Metadata Partition Mapping Editor.
You create all of the rules for choosing the appropriate PBT here
and the rules are stored in the MicroStrategy metadata.
Metadata partitions can be homogenous or heterogeneous:
Homogenous Partitioning
 Homogenous partitions must have the same amount of data stored at
the same PBT level.
 The logical structure of the PBTs must be the same, that is, they must
have the same facts and attributes defined.
 For example, each table must store one year of data at the month
level.

Heterogeneous Partitioning
 In contrast, heterogeneous partitioning, the PBTs can have different
amounts of data stored in them at different levels.
 For example, one table can contain six months of sales data, while
another stores an entire year.
92
Warehouse partition mapping

Warehouse partition mapping is the mapping of partitions carried

out and maintained in the warehouse.
You can define a warehouse partition by adding a table with a
special structure through the warehouse catalog.
This table contains the map for the partition, which is stored in the
warehouse.
Warehouse partitions divide tables physically along any number of
attributes, though this is not visible to the user.
Warehouse partitions must be homogenous,
unlike metadata partitions, so that the same
amount of data is stored at the same PBT
level and the same facts and attributes are
defined.
A partition mapping table (PMT), which is
used to identify the partitioned base tables as
part of a logical whole, must be created.

93
Logical Table Size

MicroStrategy Architect assigns a size to every table in the project

when you first add them to the project.
These size assignments are stored in the metadata and are
calculated based on the table columns and their corresponding
attributes.
Because Architect uses the conceptual or logical attribute
definitions when assigning sizes, this measurement is known as
the logical table size.
The initial logical table size is based on the number of attribute
columns and the various levels at which they exist in their
respective hierarchies.
Logically, a table with a higher-level attribute should be smaller in
size.

When you run a report, the Analytical Engine chooses

the smallest of all tables, based on logical table size,
that contains enough data to answer the query.
94
Other Concepts(1)

Autostyles
 Provide predefined formatting styles, allowing you to standardize formatting
among reports.
 Each autostyle is a collection of all the formatting layers, allowing you to
format the different report sections.

Operators
 An operator enables calculation by providing the mathematical expression,
such as addition or rank, for a given metric definition.

Searches
 The Search for Objects dialog box is a tool you can use to search for either a
specific object or a group of objects meeting certain criteria.
 You can select multiple criteria to search for an object
 For example, you can look for objects according to their type, and the date
on which they were last modified, and their owner(s)).

95
Other Concepts(2)

Drill maps
 Allow you to create fully customized drill paths that are available to your
users while drilling on a report.
 When the drill hierarchies are created, a default drill map is created.
 If no drill hierarchies are created, then the system hierarchy is used to
create the default drill map.
 The drill map determines what options are available to you when you drill on
a report object.
 You can create custom drill maps that can override these defaults.

Security filters
 A security filter is a stand-alone object with filtering capabilities that you
assign to users or groups that narrows their result set when they execute
reports or browse elements.
 Security filters enable you to control, at the MicroStrategy level, what
warehouse data users can see based on the filter criteria. This function is
similar to database views and row level security.

96
Other Concepts(3)

Privileges
 The following graphic sums
up the various privileges
available in Desktop and
Web.

 Not every user has to be

granted all the privileges for
a given role.

 For example, a Web

Reporter may be allowed to
execute reports only,
without prompt and drilling
options.

97
Questions?

98
Thank You !

99