Basics of Microstrategy Reporting and Project

Design
April
2014
 AGENDA

Introduction to MicroStrategy Desktop

Overview of Application and Schema Objects

List of Public Objects

Reports

OLAP Services

List of Schema Objects

Warehouse Catalog

Schema Modelling

2
 Introduction to MicroStrategy Desktop

3
 MicroStrategy Desktop

MicroStrategy Desktop is a premier BI development environment, providing users

access to data through powerful analytical applications.

Enterprise Class Develop via a Single Powerful Graphing

Development
Within Desktop's intuitive Windows Interface
MicroStrategy Desktop users can Capabilities
A powerful graphing engine
based interface, users can access all Styles of BI through a allows users to select from a
interactively: single user interface. wide range of graph types, from
Build reports Users can create ad hoc reports simple bar or line graphs to
Retrieve and display formatted and report services documents more complex radar graphs.
results by dragging and dropping Users can easily format graphs
Navigate through information to reusable business attributes and and sub-graphs to display the
areas of interest metrics onto a report template. title, grid walls, and axes as
Data investigation is extended desired.
through drilling, pivoting, and
data slicing.

More than 300 mathematical, OLAP, statistical, and financial

functions
 MicroStrategy Desktop

MicroStrategy Desktop is used to build both Analysis and Report Objects.

Analysis Objects such as Metrics, Prompts, and Filters deliver computational
sophistication for the entire range of analytical capabilities, including sums,
counts, ranks, time comparisons, benchmarking, trends, data mining, and
predictive analysis.
Report Objects such as Dashboards, Enterprise Reports, and Graphs are the
containers that present data in an easy to understand format for business users.
They also support interactive investigation and OLAP manipulations so users can
get answers to any business question.
All objects and business rules defined using MicroStrategy Desktop are stored in
the central metadata repository, allowing all MicroStrategy BI products to reuse
the same definitions and build upon them.
 Overview of Application and Schema Objects

6
 MicroStrategy Objects Overview

The metadata contains three types of objects 1) Schema Objects 2)

Application Objects 3) Configuration Objects

Schema Application
Objects Objects

Reports and report related objects Logical Objects that map to the
such as filters, templates, metrics, physical data warehouse structure,
prompts etc. such as attributes, facts, logical
You build these objects using tables etc.
schema objects or other You create these objects in
application objects MicroStrategy Architect
 List of Public Objects

8
 Custom Groups and Consolidations

A Custom Group is a set of special filters that can be placed on a template. It is

made up of an ordered collection of elements called custom group elements.
Consolidations are used to specify the data you want to view in your report. They
allow you to group attribute elements in new ways without changing the
metadata and warehouse definitions.

Both of these features allow you to qualify a report on a row-by-row

basis

Custom Group Consolidatio

n

A custom group lets you group attribute
elements from the same or different attributes
to meet your reporting requirements.
This allows you to group attribute elements on
a report in a way that is not defined in your
data warehouse.
From the perspective of the report design
process, 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 element contains its own set of filtering
or banding qualifications.
Consolidations enable you to group together
and to pick specific attribute elements.
Further, consolidations 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.
For example, a consolidation allows you to
group together the elements of the Month of
Year attribute into various seasons and place
them on the template.
Editor - Custom Groups / Consolidations
 Custom Groups & Consolidations Comparison

The essential distinction is that consolidations work with attributes and custom
groups use filters.
Row level math can be performed with consolidations but not with custom groups.
Custom groups are more flexible than consolidations because you do not have to
know much about your data to create filters for a custom group. In contrast,
consolidations require that you know exactly which attribute elements to select
when creating the consolidation.
Feature Custom Group Consolidation
Arithmetic operations Not allowed Allowed
Where and how data is Warehouse Analytical Engine
calculated
SQL efficiency Low High
Re-using consolidation No Yes
elements
Subtotals Yes Yes
 Drill Maps

After executing a report in a MicroStrategy reporting environment, you may need to

execute another report based on the original report to get more detailed
information. Such actions where you create a related report based on an existing
report are referred to as Drilling.

Drill maps determine the options available to an user when drilling on a

report

When the drill hierarchies are created, a default drill map is created.
If no drill hierarchies are created, 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.
These different options are referred to as Drill Paths, which includes the
destination of the drill.
The destination can be an attribute, a consolidation, a hierarchy, or a
template.
 Drill Maps

A drill path can be one of the following types:

Up The destination can be any attribute or consolidation and does not have to be
related to the original object. The destination is shown as part of the Drill Up menu
when you right-click and select Drill in the report.

Down This is similar to Up, except that the destination is shown as part of the
Drill Down menu when you right-click and select Drill.

Across This is also similar to Up, except that:

The destination is shown as part of the Other Directions menu when you right-
click and select Drill.
A hierarchy can be used as a drill path.

Template This allows you to replace the template of the original report template
with a completely different destination template. Select the template to use as the
destination template.

Drill Map Use this as a shortcut to the drill paths of another drill map.
 Filters

A filter specifies the conditions that the data must meet to be included in the
report results.
Using a filter on a report narrows the data to consider only the information that is
relevant to answer your business question, since a report queries the database
against all the data stored in the data warehouse.
Filters are helpful in clarifying large quantities of data and only displaying
subsets of that data, so reports show users what they really need to see.
A filter is composed of at least one qualification. Qualifications are the actual
conditions that must be met, for example, "Region = Northeast" or "Revenue >
$1 million".
You can create multiple qualifications for a single filter, and then combine the
qualifications using the logical operators AND, AND NOT, OR, and OR NOT.
 Types of Filters

Attribute Qualifications

Attribute qualification allows you to filter on an attributes form (ID, description, and
so on) or on elements of the attribute.
An example of an attribute form qualification is a condition on the attribute form
Customer Last Name for last names that start with the letter H.
An attribute element list qualification on the Customer attribute consists of a list
of customers.

Set Qualifications

Set qualification allows you to create a set of attributes based on either the metrics
associated with those attributes (a metric qualification) or the relationships
between them (a relationship qualification).
A metric qualification allows a report to display the sales data for only those
products with inventory level below a specified value. It is also referred to as a
metric set qualification.
A relationship qualification can be used to create a report that displays all the
stores selling Nike shoes in the Washington, DC area. It is also referred to as a
relationship set qualification.
 Types of Filters

Shortcut qualification

Shortcut-to-a-report qualification, also known as a report qualification or a report

as filter, uses the dataset of one report as a filter inside another report.
Shortcut-to-a-filter qualification, also known as a filter qualification or embedded
filter, uses an existing filter, either as is or with additional conditions, on a report.

Advanced qualifications

Advanced qualifications allow you to create the following:

Custom expressions, which are customized filter expressions. You can use Apply
functions and you can create relationship filters.
Joint element lists, which join attribute elements and then filter the result sets.
 Prompts

A prompt is a 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.
For example, the user can enter information such as the region Northeast or
year 2007, and the data is returned from the data warehouse. With prompts
you can create reports that allow users to change the report content at run time.
Prompts are useful for asking questions about the set of data you want to see in
the report. Prompts allow the report to have dynamic report definitions, which
can change with each query by altering the information in the prompt dialog box.
Prompts can be a part of the report definition, filter, template, custom group, or
metric.

Prompts
are useful
to keep the
number of
reports in a
project
small
 Types of Prompts

Using the following prompt types, you can create a prompt for nearly every part of
a report. It is important to remember that prompts can be used in many objects
including reports, filters, metrics, and custom groups. All of these prompts will
reveal themselves at report execution time, but the origin of the prompt can be
within any of the objects.

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

An object template allows you to use a predefined structure to begin

creating a new object.
For example, you may want to create many filters that contain the
current month as part of the definition. Having a filter object template
that contains the current month allows you to skip the step of defining
that part of the filter each time you create a filter.
Another example is a need to build multiple reports containing the
attribute Day and the metrics Revenue, Cost, and Profit. To reduce the
time spent creating these similar reports, define a report with these
objects and save it in the Object Templates folder, thus creating a
report object template.

To be used as an
object template, the
object must be
saved in the Object
Templates folder
 Object Templates

You can create object templates for the following objects

Consolidations
Custom groups
Documents
Filters
Metrics
Reports

Empty object templates

Empty object templates are a subset of object templates. The only difference
between the two is that object templates contain a definition and empty object
templates do not. Empty object templates define default formatting and other
properties on a project level for new reports, templates, metrics, and documents.

There are two kinds of empty object templates

Empty object templates automatically provided in MicroStrategy. These are

displayed in the New Object dialog box as Empty Document, Empty Metric,
Empty Report, and Empty Template.
User-defined empty object templates help you control new objects created
in your project, by specifying a default set of properties that should be applied to
each new object..
 Auto Styles

MicroStrategy comes with several presentation styles for displaying reports.

These are called autostyles.
Each autostyle automatically applies a set of formatting that includes color
scheme, font style, and font type to a report.
Autostyles let you standardize formatting across many reports.
The default autostyle used for all reports is called Corporate, which includes a
gray background and dark blue font color.
The sample image below shows an autostyle with various colors applied to
different areas in the report grid.
 Metrics

Metrics are MicroStrategy objects that represent business measures and key
performance indicators.
They are calculations to be performed on data stored in the database and are
similar to formulas in spreadsheet software.
Questions such as What were the sales for the eastern region during the fourth
quarter?, Are inventory levels being consistently replenished at the beginning
of each week?, or How many employees are currently working for our
company? can easily be answered by creating metrics.
A metric definition must contain a formula, which determines the data to be used
and the calculations to be performed on the data.

A metric is categorized as one of the following types based on the functions used in
its formula:

Simple metric: The formula of a simple metric is a mathematical expression

based on at least one group function, such as sum or average, which is applied
to facts, attributes, or other metrics. It can also contain non-group functions or
arithmetic operators, in addition to the required group function.
Compound metric: The formula of a compound metric is based on arithmetic
operators and non-group functions. Arithmetic operators are +, -, *, and /; non-
group functions are OLAP and scalar functions such as running sum or rank. The
operators and functions can be applied to facts, attributes, or metrics.
 Metrics

A metric is an object you create in Desktop that performs a calculation on a fact.

A metric can employ everything from basic function, like sum, average, or
standard deviation to more advanced functions, like moving average, correlation,
or n-tiling.
For example, if you want to see Average Revenue on a report, you need to build
a metric that averages the Revenue fact values. The formula for an Average
Revenue metric would look like below (see image below)

Desktop provides over 200

built-in functions and
operators for use in
creating metric calculations,
including statistical,
mathematical, and financial
calculations.
 Types of Metrics

Metrics can belong to one of the following categories:

Simple
Nested
Compound

Simple metrics are the most basic metrics. You can use simple metrics to create
other types of metrics. In their structure, simple metrics

Include one or more aggregation functions

Are based on one or more facts or attributes
Include the specified level at which they are to be calculated
May include conditions that apply to its calculation
May include transformations, which are applied prior to its calculation

Nested metrics are metrics that perform multiple aggregations by placing one
calculation formula inside, or nested, in another. They provide a convenient way
to use metric functionality when tables in the data warehouse do not include data
at the level needed for a specific type of analysis. The result of the inner calculation
formula is stored in an intermediate table, which is then used to calculate the result
of the outer calculation formula.
 Types of Metrics

Compound metrics are created by combining one or more metric objects with
one or more mathematical operators or constants. You can create compound
metrics using simple, nested, or other compound metrics.
A compound metric inherits the levels, conditions, and transformations included
in the component metrics of its definition. You cannot include levels, conditions,
or transformations in the compound metric itself.
Compound metrics are automatically updated with changes that are made to the
component metrics that are used in its definition.
 Metric Editor

When you choose to create a new metric, the Metric Editor opens displaying several
tabs and panes, as shown below:
 Metric Editor

The Formula tab contains the following:

Object Browser enables you to navigate through the project to locate objects
you want to use in the metric filter definition.
My Shortcuts enables you to jump to locations in the Object Browser. You can
customize your shortcuts.
Metric Definition Window displays the complete metric definition, including its
formula, calculation level, condition (if any), and transformation (if any). The
bottom portion of the metric definition window changes depending on what part
of the metric definition you have selected in the top portion.

Subtotals/Aggregation Tab is used to configure subtotal and dynamic

aggregation settings for a metric.
The Subtotals/Aggregation tab contains the following:
Total subtotal function enables you to determine the aggregate function used
to calculate the Total subtotal values for the metric.
Dynamic aggregation function enables you to determine the aggregate
function used by the Analytical Engine for dynamic aggregation. Dynamic
aggregation occurs when a lower-level attribute is present in the Report Objects
window but is not displayed on the report template
Select the subtotals you want available for this metric enables you to specify
which subtotals you want to be available for the metric when it is placed on a
report template that displays subtotals.
 Level Metrics

Level, or dimensionality, enables you to determine the attribute level at which

a metric is calculated. However, you can specify the grouping and filtering
involved in a metric calculation.
By default, all metrics calculate at the report level, which means that the
attributes on the report template dictate the level at which the metric
calculates. However, you may specify any attributes as the calculation level of
a metric.
The metric-specified attribute levels override the default report level.

When you define the level for a metric, you need to consider the following
settings:

Target : The target is the attribute level at which the metric calculates. Any
attribute or hierarchy can be the target.

Grouping: Grouping determines how the metric aggregates. The option you
choose for the grouping of a metric affects the GROUP BY clause of the SQL
pass that calculates the metric.

Filtering : The filtering setting governs the relationship between the report
filter and the calculation of the metric..
 Level Metrics

The following grouping options are available in the Metric Editor for level metrics:
Standard : Groups by the attribute level specified as the target
None : Excludes the target (and its children) for the report grouping. This setting
calculates one total for the target attribute and any of its child attributes that are
included on the template.

The following filtering options are available in the Metric Editor:

Standard enables the report filter to interact as usual in the metric calculation.
The metric calculates only for the elements included in the report filter definition.
The filter criteria for the report is included in the WHERE clause of the SQL pass
that calculates the metric.
Absolute raises the level of the report filter to that of the target
Ignore completely ignores any related report filtering criteria. Any related report
filtering conditions are not included anywhere in SQL pass that calculates the
metric.
None directs the MicroStrategy Engine to use a particular fact table to calculate a
metric. You typically use this filtering option in combination with the None
grouping option.
The filtering setting only applies to filtering criteria that are related to the
attribute that is specified as the target. A report filter is related to the target if it
qualifies on an attribute that belongs to the same hierarchy as the target
attribute.
Metric Editor Level(Dimensionality)
 Reports

31
 Reports

Reports are the focus of business intelligence analysis. They enable users to
gather business insight through data analysis. The results from any Desktop report
is often just a starting point for further business intelligence investigations.

A report is a request for specific, formatted data from the data warehouse. It
consists of a template plus any desired filtering criteria.

Report Components

Template specifies
what information to
retrieve from the data
warehouse and
how this information will
be displayed in the report
results.
Report Filter specifies
the conditions that the
data must meet to be
included
in the report results.
View of a report is the
actual view of a report
subset.
 Report Types

You can view a MicroStrategy report from different perspectives, depending on the
type of work that you want to perform.
Grids
A grid report is the most commonly used type of report. Grid View displays grid
reports using a formatted, cross-tabular display of the report data. Most business
intelligence analysis is performed using this view.
Graphs
A graph report is a representation of data in a visual format that can help you see
overall trends easily, identify medians and exceptions, and so on. You display report
data as a graph using Graph View. There are many different graph styles you can
choose from to display your report data most effectively.
Grid and Graphs
Grid Graph View is a combination display of the Grid View and the Graph View of a
report, side by side.
 Creating Reports

Creating a report also involves creating a template and a report filter.

Template
A Template specifies what information to retrieve from the data warehouse and how
this information will be displayed in the report results.
To define the template, you can either drag and drop objects from the Object
Browser into the template definition window, or you can right-click the object in the
Object Browser and select Add to Rows or Add to Columns.
The layout of a template can be cross-tab or tabular.

A cross-tab layout is useful for multidimensional analysis, like 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, like a column of regions and
a column of stores.

Report Filter
A report filter specifies the conditions that the data must meet to be included in the
report results.
 Saving and Running Reports

Saving Reports

After you create a report, you can save the report, so you can execute it again in the
future. When you save a report, its name and definition (the template, all report
filtering criteria, and any report formatting) are stored in the MicroStrategy
metadata database.
You can save a report using the Save option from the File menu.
It is good practice to create and adhere to corporate standard naming and
storage conventions to make it easier to locate objects as your
MicroStrategy project grows.

Running Report

To execute a report, select the Run option from the File menu.
The report results display in the default report display view. The default report
display view is the report display view that was selected when the report was last
saved (see Report Types slide).
 Report Data Manipulations

Drilling
Drilling enables you to see data at levels other than that of the original grid or
graph. It helps you investigate the data on your report quickly and easily.

Page By
Page-by enables you to select and display subsets of your report results as separate
pages. This feature is most useful when you have extremely long report results and
scrolling is necessary to see all of the data.
 Report Data Manipulations

Pivoting
Data pivoting enables you to rearrange the columns and rows in a report, so you
can view data from different perspectives. With data pivoting, you can do the
following and many more
Move objects from the row header to the column header
Move objects from the column header to the row header
Change the order of objects in the row header
Change the order of objects in the column header

Subtotals
Subtotals reflect accumulations at selected attribute levels and can be applied
dynamically to any report. There are various subtotals available to you such as
count, minimum, maximum, average, and so forth.
Subtotals can be applied by Position, Across Levels
and Group By
Subtotals by Subtotals Across Subtotals Group By
Position Levels
 Report Data Manipulations

Sorting
Sorting enables you to specify the order in which the data in a report for a particular
row or column is presented, either ascending or descending. You can sort based on
any object that you place on the template. You can also select the sorting criteria
and the sorting order.

Outline Mode
Outline mode enables indented grouping of related attributes, much like heading
levels in a document outline. Outline mode is useful when users want to display the
same report at different levels very quickly.
 Report Data Manipulations

Printing
You can print a report in Grid, Graph, Grid and Graph, or SQL view. The formatting
you apply to the report in Desktop also applies to the printed copy of the report.

You can print a report using one of the following methods:

On the File menu, select Print.
On the toolbar, click Print Preview.

Exporting
You can export a Desktop report or e-mail a Desktop report (as an attachment) in
any of the following application formats:

Microsoft Excel
Microsoft Word
Microsoft Access
Plain text
HTML
PDF
 OLAP Services

40
 Overview of OLAP Services

MicroStrategy OLAP Services is an extension of MicroStrategy Intelligence Server

that brings In-memory Business Intelligence to the MicroStrategy BI platform to
significantly improve performance and analysis.
MicroStrategy OLAP Services is an add-on product to Intelligence Server. While
this product is not required to develop reports, the functionality it provides can
greatly enhance the type of analysis you can achieve with your reports.
This product provides MicroStrategy customers with the following types of
analysiscube analysis, derived elements, in-memory OLAP with the use of
report objects, view filters, and derived metrics.
Key Benefits
Higher performance at any scale
Reduced workload on every part of
the system
Less database query time
Less MicroStrategy Intelligence
Server query generation time
Easy Cube development
Familiar Cube Development
Interface
Optimized Memory Use
Create, Save, Reuse, and Share
Derived Elements
 In Memory ROLAP

In-memory ROLAP creates mid-tier cube databases called Intelligent Cubes that
contain selected portions of the data warehouse.
These Intelligent Cubes are seamlessly interwoven in the ROLAP architecture as
they populate portions of the global multi-dimensional metadata model with
actual data.

Faster Report Performance

The addition of In-memory ROLAP technology redirects many database queries
to be served directly from In-memory ROLAP. In-memory ROLAP takes advantage
of the huge addressable memory space on 64-bit systems.

Faster Queries, Smooth Database Usage

In-memory ROLAP offloads the highest value queries from the database and
serves them to the users quickly and directly from memory. These reports are
typically those with the highest level of use, interactivity, and those identified as
having the highest business value.
 In Memory ROLAP

Dynamically Source Data from Intelligent Cubes

MicroStrategy's Dynamic Sourcing automatically checks a report request, and
automatically sources data from a MicroStrategy Intelligent Cube wherever
possible.
It also automatically allows the report to source data from warehouse if the data
requirements for the report change, or cannot be satisfied by an Intelligent Cube.

Cube Advisor Tool

Cube Advisor scans the MicroStrategy Intelligence Server metadata, and
suggests the optimal set of Intelligent Cubes to service the reports and users'
most valuable requests.
Cube Advisor will suggest Intelligent Cubes that are optimized for reducing total
Database Time, Job Load, User Satisfaction, and Rows Required.

Shift Processing Away From the Database

Administrators can re-allocate expensive query jobs but shifting that processing
to an In-memory Intelligent Cube and thus reduce the overall burden.
MicroStrategy Cube Advisor is an good choice to effectively determine which
queries would be good candidates In-memory cubes.
 View Filters

A view filter enables you to further narrow down a report view, using only
those objects in the Report Objects window, (even if they are not displayed on
the template).
When you add or change a view filter, the original report filter remains intact.
(Recall that report filter conditions are applied in the SQL of a report when the
report runs.)
Only after a report result set is retrieved, are the view filter conditions
applied, so only a subset of the report results is displayed in the report view.
Another key difference between report filters and view filters is that view filter
conditions of a report are local to that report. In other words, view filter
conditions cannot be reused or shared across reports like report filters. View
Not
filters can, however, be saved with the report definition. e
When you have multiple
view filter conditions,
the default set operator
is AND. Click a set
operator and select
AND, AND NOT, OR, OR
NOT to change it.
 Derived Metrics

Derived Metrics are metrics you can create within a report, using only those
objects in the Report Objects window (even if they are not displayed on the
template), as well as functions and operators.

Derived metrics:
May include one or more functions and operators
Are based on the attributes and metrics in the Report Objects window
May be simple or compound, and therefore will inherit the characteristics of
whichever type you create.
Built In
Derived Metrics

Many common metrics that

are typically defined in terms
of other metrics are
available from the Insert
menu when you have
MicroStrategy OLAP
Services.
 Derived Elements

A Derived Element is a grouping of attribute elements on a report, that is

defined by a list, filter, or calculation.
These groups provide a new view of report data for analysis and formatting
purposes. Derived elements are evaluated on the report dataset retrieved
from an Intelligent Cube, without regenerating or re-executing SQL.
You can use derived elements to create these groups on-the-fly while viewing
a report, rather than defining consolidations or custom groups.
For example, you have a report with Region, Category, and Profit on the
template as displayed on the left hand side in the image below:
 List of Schema Objects

47
 Attributes

Business data represented by facts can offer little insight without the presence of
business concepts and context, which take the form of attributes in MicroStrategy.
Attributes provide the business model with a context in which to report on and
analyze facts.
Attributes are defined by these properties:
Attribute form: contains an identifier or descriptor of an attribute. Attributes can
have multiple attribute forms. For example, for the Customer attribute, Customer
Email, Customer First Name, and Customer Last Name are examples of attribute
forms
Attribute expression: maps a MicroStrategy attribute form to one or more
columns in the warehouse.
Attribute relationship: allows interaction of data at different conceptual levels
and shows how data is related within a project.

While creating attributes is a major step in

the initial creation of a project, it is often
necessary to modify and create attributes
throughout the life cycle of a project.
 Types of Attributes

Compound Attributes Heterogeneous Homogeneous

Attributes Attributes
A compound attribute is
one that uses two or more A Heterogeneous attribute A Homogeneous attribute
columns as its ID i.e., ID is one where at least one is one where each
form maps to a attribute form points to attribute form points to
combination of columns. two or more different the same column or set
There attributes require a columns or sets of of columns in every table
compound primary key in columns in the tables to to which it maps.
the data warehouse to which it maps.
uniquely identify their
elements.
 Facts

Facts are one of the essential elements within the business data model.
They relate numeric data values from the data warehouse to the MicroStrategy
reporting environment.
Facts generally represent the answers to the business questions on which users
want to report.
The facts you create in MicroStrategy allow users to access data stored in the
data warehouse.
Facts form the basis for metrics, which are used in the majority of analyses and
reports that users can create with MicroStrategy.
A fact entry level is the lowest set of attributes at which a fact is stored.

Facts are stored in the

data warehouse in fact
tables.
These fact tables are
composed of different
columns.
Each cell in the columns
represents a specific
piece of information.
 Structure of Facts

Facts are composed of the following components

Fact Definition is composed of one or more fact expressions. Every fact must
have at least one expression.

Column Alias stores the column name MicroStrategy uses to generate SQL
statements when creating temporary tables related to the fact. Every fact must
have a column alias. MicroStrategy selects a default column alias depending on
the type of fact, unless you create a new column alias.

Level Extensions allow facts stored in the data warehouse at one level to be
reported at an unrelated level. Extensions can also prevent a fact from being
reported at a certain level, even though it is stored at that level. Level extensions
are very effective for advanced data modeling scenarios.

You create facts in

Desktop using the
Fact Creation
Wizard and the
Fact Editor.
 Overview of Fact Extensions

Facts are stored in data warehouse tables at particular levels.

The level of a fact is defined by the attribute IDs present in the fact table. The
level at which a fact is stored directly affects how you can report on that fact. You
can report on a fact at the level at which it is stored, or you can aggregate it to a
higher level. Based on this fact table, you can report on unit sales at the item
or week levels. However, you cannot create a report that shows
unit sales by date because the fact is stored at the higher level
of week. You cannot determine the unit sales at the date level
using this fact table.
Sometimes, facts may not be available in the data warehouse at the levels
you want to analyze in reports.
You may not be able to change the levels at which they are stored in data
warehouse tables, but you can change the levels of facts in MicroStrategy
Architect by using fact level extensions.
Fact level extensions enable facts stored in the data warehouse at
one level to be reported on at a different level.
MicroStrategy Architect provides the following three types of fact level extensions:

Degradation: Enables you to extend the level of a fact to a lower level within
the same hierarchy.
Extension: Enables you to extend the level of a fact to include a level from a
different hierarchy not currently related to the fact
Disallow: Enables you to disallow a specific fact level to prevent unnecessary
cross joins to lookup tables when reporting on a fact
 Hierarchies

Hierarchies are groupings of attributes that can be displayed, either ordered or

unordered, to reflect the relationships that exist between the attributes in a project.

There are two types of hierarchies that exist in MicroStrategy:

System hierarchy
The system hierarchy is created according to the relationships defined between
the attributes in your project.
You do not need to create the system hierarchy; it is automatically created in
Desktop when you create a project.
Although the system hierarchy specifies an ordered set of all attributes in the
project, it does not define ordering or grouping among attributes.

User hierarchy
User hierarchies are groups of attributes and their relationships to each other,
arranged in ways that make sense to a business organization.
They are user-defined and do not need to follow the logical data model.
As the structure of your business intelligence system evolves, you can modify the
design of a user hierarchy to include additional attributes or limit user access to
certain attributes.
This type of hierarchy is created to provide flexibility in element browsing and
report drilling.
 Browsing and Drilling using Hierarchies

User Hierarchies can be configured as drill paths for analyzing report data
User Hierarchies are available to users throughout the project. Users can access
them in the Data Explorer Browser, Object Editors and Prompts
 Transformations

Transformations are schema objects most often used to compare values at

different times, for example, this year versus last year and today versus month to
date.
Transformations are useful for discovering and analyzing time-based trends in
your data.
Transformations are not placed on the template of a report or a document.
Instead, report developers use transformations to define Transformation
Metrics, simple metrics
Current Year that assume
vs. Last Year the properties of the transformation applied
to them.

Any transformation can

be included as part of
the definition of a
metric, and multiple
transformations can be
applied to the same
metric.
 Types of Transformations

There are two types of transformations:

Table Based Transformations: You implement these transformations using a

transformation table in the warehouse. These tables are often created during the
ETL process. Some transformation data can be easily incorporated into the lookup
tables for attributes such as Day by adding the transformation columns.
Expression Based Transformations: You implement these transformations using
a mathematical formula. A transformation expression typically includes an attribute
ID column, a mathematical operator, and a constant. For example, you could create
a Last Quarter or Last Month transformation using QUARTER_ID-1 or MONTH_ID-1.

Table Based vs. Expression Based

Table Based Transformation
The advantage of a table-based
transformation is the possible use of
indexing to speed query times. Table Based
provide additional flexibility beyond what
formula expressions can produce
The drawback of this kind of transformation
is that it requires the creation and
management of an additional table in the
warehouse
Expression Based Transformation
Dynamic calculation of an expression-based
transformation is that the DBA does not have
to create and maintain a transformation
table
The drawback is that the system must
perform the calculation every time.
 Transformations Components

All transformations have the following components:

Member attributes: The member attributes are attributes to which the

transformation applies. In other words, it is the lowest-level attribute on the
report to which you want to apply the transformation. For example, if you
analyze the report at the quarter level, you should add a Quarter member
attribute to the transformation.
Member expressions: Each member attribute has a corresponding expression
that needs to be resolved in the report SQL to obtain valid data. For expression-
based transformations, the member expression is a mathematical expression.
For table-based transformations, it is a column from a transformation table in the
warehouse that points to the valid data.
Member tables: The member tables store the data for the member attributes.
For expression-based transformations, the member tables are generally lookup
tables that correspond to the attribute being transformed, such as LU_DAY,
LU_QUARTER, and so forth. For table-based transformations, it is the
transformation table that stores the relationship.
Mapping type: The mapping type determines the way the transformation is
created based on the nature of the data. The mapping type can be one of the
following:
One-to-One: A typical one-to-one relationship is last year versus this year. A
year maps to exactly one other year.
Many-to-Many: A typical many-to-many relationship is year to date. A date
maps to itself and any other dates that came before it in the given year.
 Logical Tables

Physical tables in a data warehouse consist of columns, and logical tables in the
MicroStrategy schema relate this column data to attributes and facts. These
attributes and facts are part of the report definition that the MicroStrategy Engine
refers to when a report is executed.
Logical tables are MicroStrategy objects that form the foundation of a
schema.

Types of Logical tables

Logical table: A logical representation of a physical table that MicroStrategy uses

to generate SQL. A logical table is created for each physical table that is imported
into a project, using the Warehouse Catalog. This type of logical table maps
directly to physical tables in the data warehouse. These physical tables are
referenced in the SQL that is generated for the report.

Logical table alias: A logical table that uses a different name for a physical
table. One physical table can have more than one logical table alias. Logical table
aliases are used to create attribute roles.

Logical view: A logical table that is created using a SQL statement instead of
being a direct representation of a physical table. Once created, the logical view
can be used in the same way as any logical table. The logical view is also
referenced in the SQL that is generated for the report
 Logical Size

MicroStrategy assigns a size to every table in the project when you initially add it
to the project. These size assignments are based on the columns in the tables and
the attributes to which those columns correspond.
Because MicroStrategy uses the conceptual or logical attribute definitions to
assign a size to each table in the project, this measurement is referred to as
logical table size.
The logical table size determines which logical table to use to answer a query
when multiple logical tables would provide the same data.
A lower logical table size means the table has a higher level of aggregation.
The performance of accessing a table with a higher level of aggregation is
usually better than accessing a table with a lower level of aggregation.

Scenario
A base fact table contains millions of rows of transaction-level data.
The other tables have only higher-level or summary information.
Since the levels of the attributes are lower in the base fact table, the base fact table is
assigned a higher value for its logical table size than are the summary tables with higher-
level attributes.
This means the table with summary information is used to return data rather than the
table with transaction-level data when the tables can be used to answer the same query.
 Logical Table Editor

Logical views can be created in MicroStrategy Desktop using the Table Editor
 Logical Table Use Case

Attribute Form Expression across Multiple Tables

Customers often request the ability to generate an attribute form expression

across multiple tables. Usually, the case is on Date columns. For example, you
want to define an attribute based on the Date difference between two Date
columns (Ship_Date and Order_Date) in two different tables as follows.

F_Table1=

F_Table2=

Using the Logical View feature, you can use the following SQL query to create a
logical table to calculate the Date difference and then define the attribute on that
new column:

SELECT Ship_Date-Order_Date Cycle_time,F_table1.Order_ID, Fact1,Fact2

FROM F_table1, F_table2
WHERE F_table1.Order_ID=F_table2.Order_ID

The new logical table (logical view) looks like the following table, and a new
attribute can be defined on the Cycle_Time column.
 Partition Mapping

Partitioning is the division of a larger table into smaller tables.

You often implement partitioning in a data warehouse to improve query
performance by reducing the number of records that queries must scan to
retrieve a result set.
You can also use partitioning to decrease the amount of time necessary to load
data into data warehouse tables and perform batch processing.

There are two basic types of partitioning:

Server level
Server-level partitioning involves dividing one physical table into logical partitions in
the database environment. The database software handles this type of partitioning
completely, so these partitions are effectively transparent to MicroStrategy software.
Since only one physical table exists, the SQL Engine only has to write SQL against a
single table, and the database manages which logical partitions are used to resolve
the query.

Application level
Application-level partitioning involves dividing one large table into several separate,
smaller physical tables called partition base tables. You split the table into smaller
tables in the database itself, and then, the application that is running queries
against the database (in this case, MicroStrategy) manages which partitions are
used for any given query. Since multiple physical tables exist, the SQL Engine has to
write SQL against different tables, depending on which tables are needed to retrieve
 Partition Mapping

MicroStrategy supports application-level partitioning for fact tables through one of

two methods:
Warehouse partition mapping
This method is based on a physical warehouse partition mapping table (PMT) that
resides in the data warehouse and describes the partitioned base tables that are
part of a conceptual whole.

Metadata partition mapping

This method is based on rules logically defined in MicroStrategy Architect and stored
in the metadata.
 Global Unique Identifier

MicroStrategy objects are identified using Global Unique Identifier. An object has
an object ID and Version ID.
A unique identifier (Object ID and Version ID) is assigned when an object is
created new.
When an object is modified the Version ID changes but Object ID remains the
same.
Version ID changes when a logical table is renamed or new attribute form is
added
UnliketoVersion
an attribute or filterIDdefinition
ID, Object is changed.
is consistent acrossBut Object ID
projects remains
i.e., the
when an
same.
object is moved across projects or modified, the object ID remains the
same in the project(s).

When a Project is
duplicated, the
Project ID changes
but the Object ID
remains the same
for an object in
both the Projects.
 Warehouse Catalog

65
 Warehouse Catalog Overview

The Warehouse Catalog queries the data warehouse and lists the tables and
columns that exist in it. From this list, you can select the tables to add to your
project. Every project can have a unique set of warehouse tables.
The Warehouse Catalog enables you to maintain the integrity of the logical tables
with the data warehouse structure by providing a variety of options that apply to
the project tables on an individual basis.
You access these options in the Warehouse Catalog by right-clicking any table you
have added to a project.
 Warehouse Catalog Options

The Warehouse Catalog provides the following options for individual tables:

Remove: This option enables you to remove a table from the project.
Table Structure: Selecting this option opens the Table Structure window and
enables you to view the columns and data types stored in a logical table. If the
table structure has changed since you added the table to the project, you can
click Update Structure to force MicroStrategy Architect to recognize the
changes.
Update Structure: This option is a shortcut to the Update Structure function
available in the Table Structure window.
Show Sample Data : This option enables you to view the first 100 rows of data
in a table.
Calculate Table Row Count: Selecting this option enables you to calculate
and display the row count for a table. You can also choose to automatically
calculate the row counts for all project tables using a project-wide option in the
Warehouse Catalog.
Table Prefix: Selecting this option 0pens the Table Prefix window, which
enables you to add and remove prefixes and assign a prefix to a table. Assigning
a prefix to a table means that any time the SQL Engine uses that table, it
includes the prefix when referencing the table.
Table Database Instances: Selecting this option opens the Available
Database Instances window, which enables you to select the primary database
instance for a table and assign secondary database instances for a table.
Import Prefix: Selecting this option enables you to retrieve a prefix for a table.
 Schema Modelling

68
 Attribute Roles

Attribute Roles allow you to use the same data to define and support two
separate attributes.
Suppose you define two attributes that have the same data definition but play
different roles in your business model.
For example, in the following image, notice that the attributes Origin Airport and
Destination Airport are defined using the same lookup table, LU_AIRPORT, and
column, AIRPORT_ID.
When multiple attributes are defined using the
same lookup table and column, the attributes are
essentially playing different Attribute Roles.

Specifying Attribute Roles

Automatic attribute role recognition, where
you create multiple attributes that have the
same lookup table and allow MicroStrategy to
automatically detect the multiple roles.

Explicit table aliasing, where you create

multiple logical tables pointing to the same
physical table and define those two logical
tables as the lookup tables for the two
attributes.
 Many to Many Relationships

The presence of many-to-many relationships introduces complexity during the

warehouse design process. With the presence of many-to-many relationships, you
must make additional considerations to effectively plan your design.

Below are some real-life examples of many-to-many relationships which must be

carefully handled in the data model and schema:

In a certain organization, each salesperson can work in more than one calling
center. Likewise, each calling center has many salespeople.
In a car manufacturing plant, many models of cars are produced, and each
comes in several colors. That is, there are many colors for a single type of car,
and many types of cars can be associated with the same color.

Potential problems with many-to-many relationships usually come in the following

forms, both of which can be avoided by correctly modeling the relationship:

Loss of analytical capability

Multiple counting
 Many to Many Relationships

Loss of Analytical Capability

An example of many to many relationship is Items and Colors. One item can come
in many colors (red hats, blue hats, green hats) and one color can be associated
with many items (red dress, red hat, red shoes, red socks).

With the color/item many-to-many relationship, there is usually a business

questions In what colors are certain items available? for which users want
answers:

Answering this question requires a table that contains a list of all possible
item/color combinations. In many-to-many relationships this is not feasible. Rather,
a distinct relationship table needs to be present in your warehouse.
In summary, to prevent any loss of
analytical flexibility, the following
requirements must be met:
A distinct relationship table to
identify all the possible
combinations of attribute elements
between attributes
Both the attribute ID columns in the
fact table
THANK YOU