Microstrategy Architect - Advanced Project Design

MICROSTRATEGY ARCHITECT: ADVANCED PROJECT DESIGN
Course Guide
Version: ADVPD-901-Jan11-CG
20002011 MicroStrategy Incorporated. All rights reserved.
This Course (course and course materials) and any Software are provided as is and without express or limited
warranty of any kind by either MicroStrategy Incorporated (MicroStrategy) or anyone who has been involved in the
creation, production, or distribution of the Course or Software, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the Course
and Software is with you. Should the Course or Software prove defective, you (and not MicroStrategy or anyone else
who has been involved with the creation, production, or distribution of the Course or Software) assume the entire cost
of all necessary servicing, repair, or correction.
In no event will MicroStrategy or any other person involved with the creation, production, or distribution of the Course
or Software be liable to you on account of any claim for damage, including any lost profits, lost savings, or other
special, incidental, consequential, or exemplary damages, including but not limited to any damages assessed against or
paid by you to any third party, arising from the use, inability to use, quality, or performance of such Course and
Software, even if MicroStrategy or any such other person or entity has been advised of the possibility of such damages,
or for the claim by any other party. In addition, MicroStrategy or any other person involved in the creation, production,
or distribution of the Course and Software shall not be liable for any claim by you or any other party for damages
arising from the use, inability to use, quality, or performance of such Course and Software, based upon principles of
contract warranty, negligence, strict liability for the negligence of indemnity or contribution, the failure of any remedy
to achieve its essential purpose, or otherwise.
The Course and the Software are copyrighted and all rights are reserved by MicroStrategy. MicroStrategy reserves the
right to make periodic modifications to the Course or the Software without obligation to notify any person or entity of
such revision. Copying, duplicating, selling, or otherwise distributing any part of the Course or Software without prior
written consent of an authorized representative of MicroStrategy are prohibited.
U.S. Government Restricted Rights. It is acknowledged that the Course and Software were developed at private
expense, that no part is public domain, and that the Course and Software are Commercial Computer Software and/or
Commmercial Computer Software Documentation provided with RESTRICTED RIGHTS under Federal Acquisition
Regulations and agency supplements to them. Use, duplication, or disclosure by the U.S. Government is subject to
restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at
DFAR 252.227-7013 et. seq. or subparagraphs (c)(1) and (2) of the Commercial Computer SoftwareRestricted Rights
at FAR 52.227-19, as applicable. The Contractor is MicroStrategy, 1850 Towers Crescent Plaza, Vienna, Virginia 22182.
Rights are reserved under copyright laws of the United States with respect to unpublished portions of the Software.
Trademark Information
MicroStrategy, MicroStrategy 6, MicroStrategy 7, MicroStrategy 7i, MicroStrategy 7i Evaluation Edition,

MicroStrategy 7i Olap Services, MicroStrategy 8, MicroStrategy 9, MicroStrategy Distribution Services, MicroStrategy
MultiSource Option, MicroStrategy Command Manager, MicroStrategy Enterprise Manager, MicroStrategy Object
Manager, MicroStrategy Reporting Suite, MicroStrategy Power User, MicroStrategy Analyst, MicroStrategy Consumer,
MicroStrategy Email Delivery, MicroStrategy BI Author, MicroStrategy BI Modeler, MicroStrategy Evaluation Edition,
MicroStrategy Administrator, MicroStrategy Agent, MicroStrategy Architect, MicroStrategy BI Developer Kit,
MicroStrategy Broadcast Server, MicroStrategy Broadcaster, MicroStrategy Broadcaster Server, MicroStrategy
Business Intelligence Platform, MicroStrategy Consulting, MicroStrategy CRM Applications, MicroStrategy Customer
Analyzer, MicroStrategy Desktop, MicroStrategy Desktop Analyst, MicroStrategy Desktop Designer, MicroStrategy
eCRM 7, MicroStrategy Education, MicroStrategy eTrainer, MicroStrategy Executive, MicroStrategy Infocenter,
MicroStrategy Intelligence Server, MicroStrategy Intelligence Server Universal Edition, MicroStrategy MDX Adapter,
MicroStrategy Narrowcast Server, MicroStrategy Objects, MicroStrategy OLAP Provider, MicroStrategy SDK,
MicroStrategy Support, MicroStrategy Telecaster, MicroStrategy Transactor, MicroStrategy Web, MicroStrategy Web
Business Analyzer, MicroStrategy World, Application Development and Sophisticated Analysis, Best In Business
Intelligence, Centralized Application Management, Information Like Water, Intelligence Through Every Phone,
Intelligence To Every Decision Maker, Intelligent E-Business, Personalized Intelligence Portal, Query Tone, Rapid
Application Development, MicroStrategy Intelligent Cubes, The Foundation For Intelligent E-Business, The Integrated
Business Intelligence Platform Built For The Enterprise, The Platform For Intelligent E-Business, The Scalable
Business Intelligence Platform Built For The Internet, Industrial-Strength Business Intelligence, Office Intelligence,
MicroStrategy Office, MicroStrategy Report Services, MicroStrategy Web MMT, MicroStrategy Web Services, Pixel
Perfect, Pixel-Perfect, MicroStrategy Mobile, MicroStrategy Integrity Manager and MicroStrategy Data Mining
Services are all registered trademarks or trademarks of MicroStrategy Incorporated.
All other company and product names may be trademarks of the respective companies with which they are associated.
Specifications subject to change without notice. MicroStrategy is not responsible for errors or omissions.
MicroStrategy makes no warranties or commitments concerning the availability of future products or versions that
may be planned or under development.
Patent Information
This product is patented. One or more of the following patents may apply to the product sold herein: U.S. Patent Nos.
6,154,766, 6,173,310, 6,260,050, 6,263,051, 6,269,393, 6,279,033, 6,567,796, 6,587,547, 6,606,596, 6,658,093,
6,658,432, 6,662,195, 6,671,715, 6,691,100, 6,694,316, 6,697,808, 6,704,723, 6,741,980, 6,765,997, 6,768,788,
6,772,137, 6,788,768, 6,798,867, 6,801,910, 6,820,073, 6,829,334, 6,836,537, 6,850,603, 6,859,798, 6,873,693,
6,885,734, 6,940,953, 6,964,012, 6,977,992, 6,996,568, 6,996,569, 7,003,512, 7,010,518, 7,016,480, 7,020,251,
7,039,165, 7,082,422, 7,113,993, 7,181,417, 7,127,403, 7,174,349, 7,194,457, 7,197,461, 7,228,303, 7,260,577, 7,266,181,
7,272,212, 7,302,639, 7,324,942, 7,330,847, 7,340,040, 7,356,758, 7,356,840, 7,415,438, 7,428,302, 7,430,562,
7,440,898, 7,486,780, 7,509,671, 7,516,181, 7,559,048, 7,574,376, 7,617,201, 7,725,811, 7,801,967, 7,836,178, 7,861,161
and 7,861,253. Other patent applications are pending.
How to Contact Us
MicroStrategy Education Services MicroStrategy Incorporated

1850 Towers Crescent Plaza 1850 Towers Crescent Plaza
Vienna, VA 22182 Vienna, VA 22182
Phone: 877.232.7168 Phone: 703.848.8600
Fax: 703.848.8602 Fax: 703.848.8610
E-mail: education@microstrategy.com E-mail: info@microstrategy.com
http://www.microstrategy.com/education http://www.microstrategy.com
TABLE OF CONTENTS
Preface Course Description...................................................................... 9

Who Should Take this Course ............................................... 10
Course Prerequisites ............................................................. 10
Follow-up Courses ................................................................. 10
Related Certifications............................................................. 10
Course Objectives ................................................................. 11
About the Course Materials ......................................................... 12
Content Descriptions ............................................................. 12
Learning Objectives ............................................................... 12
Lessons ................................................................................. 13
Opportunities for Practice ...................................................... 13
Typographical Standards ....................................................... 13
MicroStrategy Courses .......................................................... 16
Core Courses......................................................................... 16
1. Introduction to Lesson Description ................................................................... 17

Advanced Project Lesson Objectives ................................................................. 18
Design
Review of the Project Design Process......................................... 19
Review of Schema Objects.......................................................... 22
Lesson Summary......................................................................... 25
2. Managing Project Lesson Description ................................................................... 27

Schema Lesson Objectives ................................................................. 28
Review of Database Instances .................................................... 29
Primary and Secondary Database Instances at the Project
Level ...................................................................................... 30
2011 MicroStrategy, Inc. 5

Table of Contents MicroStrategy Architect: Advanced Project Design
Maintaining Warehouse Catalog.................................................. 33

Maintaining Individual Tables................................................. 33
Project-Wide Warehouse Catalog Options ............................ 36
Aggregation Awareness............................................................... 39
Review of Base and Aggregate Fact Tables.......................... 39
How Is MicroStrategy Aggregate-Aware?.............................. 41
Data Marts ................................................................................... 46
What Is a Data Mart? ............................................................. 46
Creating Data Marts............................................................... 53
Using Data Marts in a Project ................................................ 60
Exercises: Managing Project Schema ......................................... 64
Create an Aggregate Table Using Data Mart......................... 64
Modify a Warehouse Table .................................................... 73
Lesson Summary......................................................................... 77
3. Using MicroStrategy Lesson Description ................................................................... 79

MultiSource Option Lesson Objectives ................................................................. 80
Introduction to MicroStrategy MultiSource Option ....................... 81
Primary and Secondary Database Instances at the Table
Level ...................................................................................... 82
Support for Duplicate Tables ................................................. 83
SQL Generation for Multisource Reports............................... 85
Supported Use Cases............................................................ 91
Associating Tables to Database Instances.................................. 96
Adding Tables with a Single Data Source.............................. 97
Adding Tables with Multiple Data Sources .......................... 102
Changing the Primary Database Instance for a Table ......... 108
Removing a Database Instance from a Table...................... 113
Creating Objects for Multisource Reports.................................. 115
Creating the Forecast Revenue Fact ................................... 117
Creating the Forecast Revenue Metric ................................ 118
Creating a Multisource Report ................................................... 119
Processing of SQL for Sample Report................................. 120
Exercises: Using MicroStrategy MultiSource Option ................. 130
Add Tables from a Secondary Database Instance .............. 130
Create an Attribute for a Multisource Report ....................... 133
Create a Multisource Report ................................................ 135
Lesson Summary....................................................................... 140
6 2011 MicroStrategy, Inc.

MicroStrategy Architect: Advanced Project Design Table of Contents
4. Fact Level Extensions Lesson Description ................................................................. 143

Lesson Objectives ............................................................... 144
Overview of Fact Level Extensions............................................ 145
Degrading Fact Levels............................................................... 148
Steps for Fact Degradation .................................................. 150
Creating a Fact Degradation................................................ 152
Extending Fact Levels ............................................................... 156
Steps for Fact Extension Using the Table Relation Method 159
Creating a Fact Extension Using the Table Relation
Method ................................................................................. 165
Steps for Fact Extension Using the Fact Relation Method .. 169
Creating a Fact Extension Using the Fact Relation Method 172
Steps for Fact Extension Using the Cross Product Method. 176
Creating a Fact Extension Using the Cross Product
Method ................................................................................. 177
Disallowing Fact Levels ............................................................. 179
Exercise: Create a Fact Degradation......................................... 184
Lesson Summary....................................................................... 190
5. Transformations Lesson Description ................................................................. 191

What Is a Transformation? ........................................................ 193
Types of Transformations .................................................... 195
Transformation Components ............................................... 198
Creating and Using Transformations ......................................... 200
Creating Transformations .................................................... 200
Using Transformations in Metrics ........................................ 203
Transformation Examples .................................................... 206
Exercise: Create the Last Years Transformation ...................... 211
Lesson Summary....................................................................... 220
6. Partitioning Lesson Description ................................................................. 221

Introduction to Partitioning Concepts......................................... 223
Warehouse Partition Mapping ................................................... 226
Overview .............................................................................. 226
Implementing Warehouse Partition Mapping ....................... 227
Metadata Partition Mapping....................................................... 234
Overview .............................................................................. 234

Table of Contents MicroStrategy Architect: Advanced Project Design
Implementing Metadata Partition Mapping .......................... 234

Lesson Summary....................................................................... 237
Index ......................................................................................... 239

PREFACE
Course Description
This 1-day course covers advanced features involved in the

creation and maintenance of a MicroStrategy project. The
course assumes an understanding of basic report
development concepts from the 2-day MicroStrategy
Desktop: Reporting Essentials course and the 2-day
MicroStrategy Architect: Project Design Essentials course.
First, students will learn how to manage project data sources

using primary and secondary database instances and how to
maintain a project schema with the Warehouse Catalog. Next,
students will learn how the MicroStrategy Engine is
aggregate-aware and how to create aggregate tables using
data marts. Next, students will learn how to use
MicroStrategy MultiSource Option to configure projects to
access heterogeneous data sources. Finally, students will
learn about fact level extensions, transformations, and
partition mappings.
After taking this course, students will understand how to

maintain MicroStrategy projects and how to build advanced
schema objects.

Preface MicroStrategy Architect: Advanced Project Design
Who Should Take this Course

This course is designed for:
Project architects
Course Prerequisites
Before starting this course, you should know all topics
covered in the following courses:
MicroStrategy Desktop: Reporting Essentials
MicroStrategy Architect: Project Design Essentials
You should also have a basic knowledge of SQL.
Follow-up Courses
After taking this course, you might consider taking the
following courses:
MicroStrategy Advanced Data Warehousing
Related Certifications
This course does not have any recommended follow-up
certifications.
10 Who Should Take this Course 2011 MicroStrategy, Inc.

MicroStrategy Architect: Advanced Project Design Preface
Course Objectives
After completing this course, you will be able to:
Describe the project design process and describe the basic

and advanced schema objects you can create with
MicroStrategy Architect. (Page 18)
Define the primary and secondary database instance, use

the Warehouse Catalog to maintain project tables,
describe how the MicroStrategy SQL Engine is aggregate
aware, and create aggregate fact tables using data
marts. (Page 28)
Describe how you can use MultiSource Option to access

heterogeneous data sources, associate tables in a project to
multiple database instances, create objects for multisource
reports, and create multisource reports. (Page 80)
Describe the three types of fact level extensions available

in MicroStrategy Architect, create fact degradations to
lower the levels of facts, create fact extensions to extend
the levels of facts to other hierarchies, and disallow fact
levels to prevent unnecessary cross joins. (Page 144)
Create different types of transformations, use

transformations in transformation metrics, and describe
common uses for transformations in
reporting. (Page 192)
Describe the purpose of partitioning, explain the

difference between the server-level and the
application-level partitioning, and use warehouse and
metadata partition mapping to support partitioned fact
tables in a MicroStrategy project. (Page 222)
2011 MicroStrategy, Inc. Course Objectives 11

About the Course Materials

This course is organized into lessons and reference
appendices. Each lesson focuses on major concepts and skills
that help you to better understand MicroStrategy products
and use them to implement MicroStrategy projects. The
appendices provide you with supplemental information to
enhance your knowledge of MicroStrategy products.
Content Descriptions
Each major section of this course begins with a Description
heading. The Description introduces you to the content
contained in that section.
Learning Objectives
Learning objectives enable you to focus on the key knowledge
and skills you should obtain by successfully completing this
course. Objectives are provided for you at the following three
levels:
CourseYou will achieve these overall objectives by

successfully completing all the lessons in this course. The
Course Objectives heading in this Preface contains the list
of course objectives.
LessonYou will achieve these main objectives by
successfully completing all the topics in the lesson. You
can find the primary lesson objectives directly under the
Lesson Objectives heading at the beginning of each
lesson.
Main TopicYou will achieve this secondary objective by

successfully completing the main topic. The topic
objective is stated at the beginning of the topic text. You
can find a list of all the topic objectives in each lesson
under the Lesson Objectives heading at the beginning of
each lesson.
12 About the Course Materials 2011 MicroStrategy, Inc.

Lessons
Each lesson sequentially presents concepts and guides you
with step-by-step procedures. Illustrations, screen examples,
bulleted text, notes, and definition tables help you to achieve
the learning objectives.
Opportunities for Practice

A Workshop is a reinforcement and assessment activity that
follows two or more lessons. Because a Workshop covers
content and applied skills presented in several lessons, it is a
separate section on the level of a lesson.
The following sections within lessons provide you with

opportunities to reinforce important concepts, practice new
product and project skills, and monitor your own progress in
achieving the lesson and course objectives:
Review
Case Study
Business Scenario
Exercises
Typographical Standards
Following are explanations of the font style changes, icons,
and different types of notes that you see in this course.
Actions
References to screen elements and keys that are the focus of

actions are in bold Arial font style. The following example
shows this style:
Click Select Warehouse.
2011 MicroStrategy, Inc. About the Course Materials 13

Code
References to code, formulas, or calculations within

paragraphs are formatted in regular Courier.New font style.
The following example shows this style:
Sum(Sales)/Number of Months
Data Entry
References to literal data you must type in an exercise or

procedure are in bold Arial font style. References to data you
type that could vary from user to user or system to system are
in bold italic Arial font style. The following example shows
this style:
Type copy c:\filename d:\foldername\filename.
Keyboard Keys
References to a keyboard key or shortcut keys are in

uppercase letters in bold Arial font style. The following
example shows this style:
Press CTRL+B.
New Terms
New terms to note are in regular italic font style. These terms
are defined when they are first encountered in the course.
The following example shows this style:
The aggregation level is the level of calculation for the

metric.

Notes and Warnings
A note icon indicates helpful information.

Ainformation
warning icon calls your attention to very important
that you should read before continuing
the course.
Heading Icons
The following heading icons are used to indicate specific

practice and review sections:
Precedes a Review section
Precedes a Case Study
Precedes a Business Scenario
Precedes Exercises
2011 MicroStrategy, Inc. About the Course Materials 15

MicroStrategy Courses
Core Courses
Implementing MicroStrategy: Development and
Deployment
MicroStrategy Administration
MicroStrategy Desktop: Advanced Reporting
MicroStrategy Desktop: Reporting Essentials
MicroStrategy Report Services: Document Essentials
MicroStrategy Report Services: Dynamic Dashboards
MicroStrategy Web for Professionals
MicroStrategy Web for Reporters and Analysts
All courses are subject to change. Please visit the MicroStrategy Web site for the lat-
est education offerings.

1
INTRODUCTION TO ADVANCED
PROJECT DESIGN
Lesson Description
This lesson introduces you to the MicroStrategy Architect:

Advanced Project Design course.
In this lesson, you will first review the project design process
and learn about the tools and components that enable you to
manage the project schema. Next, you will review the basic
schema objects that you can create in MicroStrategy
Architect. Finally, you will learn about additional schema
objects that enable you to perform advanced functions.

1 Introduction to Advanced Project Design MicroStrategy Architect: Advanced Project Design
Lesson Objectives
After completing this lesson, you will be able to:

Describe the project design process and describe the basic
and advanced schema objects you can create with
MicroStrategy Architect.
After completing the topics in this lesson, you will be able to:
Describe the project design process and learn about the

tools and components that enable you to manage the
project schema. (Page 19)
Describe the basic schema objects that you can create in

MicroStrategy Architect and learn about additional
schema objects that enable you to perform advanced
functions. (Page 22)
18 Lesson Objectives 2011 MicroStrategy, Inc.

MicroStrategy Architect: Advanced Project Design Introduction to Advanced Project Design 1
Review of the Project Design Process
After completing this topic, you will be able to:

Describe the project design process and learn about the tools
and components that enable you to manage the project
schema.
In the MicroStrategy Architect: Project Design Essentials

course, you learned about the primary steps involved in the
project design process:
Project Design Process
Recall that project design involves more than just creating a

project in MicroStrategy Architect. Understanding how users
want to report on information in the data warehouse, how
data in the warehouse is related, and how that data is stored
are all fundamental parts of the project design process.
2011 MicroStrategy, Inc. Review of the Project Design Process 19

Designing the Logical Data Model
When you design the logical data model, you need to

determine the information that users want to see in reports
and determine what information is actually available in the
source systems. Finally, you design the model that
incorporates both.
Designing the Data Warehouse Schema
When you design the data warehouse schema, you need to

first consider the advantages and disadvantages of various
structures for storing data in the data warehouse. You then
determine the optimal schema design that balances the
reporting requirements, performance requirements, and
maintenance overhead. Finally, you create the data
warehouse using this schema design or modify the existing
data warehouse to use this schema design.
Creating the Project in MicroStrategy Architect
You need to have a solid design for the logical data model and
data warehouse schema before you move on to creating the
actual project. Both of these components can directly affect
how you query data in a project, what data you can query,
how fast queries run, and so forth.
Managing the Project Schema
Managing the project schema is the final and ongoing step in

the project design process. Over the life of the project, your
logical data model or data warehouse may change, or your
reporting needs may change, which can necessitate changes
to schema objects.
20 Review of the Project Design Process 2011 MicroStrategy, Inc.

In the MicroStrategy Architect: Advanced Project Design

course, you will learn about different strategies and tools that
help you manage your projects schema. In particular, you
will learn about the following:
Primary and secondary database instancesA database

instance is a logical object in the MicroStrategy metadata
that typically represents a connection to a data
warehouse. Each project must have a primary database
instance. You can associate any number of secondary
database instancesdata sourcesto a project.
Warehouse CatalogThe 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.
Aggregation awarenessMicroStrategy Architect assigns

each table a logical table size and uses it to query the
aggregate table rather than the base fact table in cases
where either table could provide the answer.
Data martsA data mart is a relational table containing

results of a report. Among other applications, you can use
data marts to create aggregate fact tables.
Multisource report executionBy default, the objects in a

standard report have to come from a single data source.
However, you can use the MultiSource Optionan add-on
component to Intelligence Serverto overcome this
limitation. MultiSource Option enables you to define a
single project schema that uses multiple data sources. As
a result, you can create a standard report that executes
SQL against multiple data sources.
2011 MicroStrategy, Inc. Review of the Project Design Process 21

Review of Schema Objects

Describe the basic schema objects that you can create in
MicroStrategy Architect and learn about additional schema
objects that enable you to perform advanced functions.
Recall that schema objects are logical objects that relate

application objects to data warehouse content. They are the
bridge between your reporting environment and your data
warehouse. As such, you have to create the basic schema
objects a project requires before you can complete any other
tasks, such as creating templates, filters, reports, or
documents.

course you learned how to create the following basic schema
objects that form the foundation of a MicroStrategy project:
TablesLogical objects that correspond to physical tables

stored in the data warehouse that you want to use in a
MicroStrategy project
FactsLogical objects that relate aggregatable data stored

in the data warehouse to the MicroStrategy reporting
environment. They are usually numeric, and you can
aggregate them to different levels, depending on your
reporting needs.
AttributesLogical objects that relate descriptive

(non-fact) data stored in the data warehouse to the
MicroStrategy reporting environment. They provide
context for reporting on facts and define the level of detail
at which you want to analyze facts.
HierarchiesLogical objects that enable you to group

attributes to reflect their relationships or provide
convenient browsing and drilling paths in the
MicroStrategy reporting environment.
22 Review of Schema Objects 2011 MicroStrategy, Inc.

The following illustration shows an example of each of these

types of schema objects:
Basic Schema Objects
In the MicroStrategy Architect: Advanced Project Design

course, you will learn about additional properties of facts.
You will learn how to create different types of fact extensions
that will enable you to report on facts at additional levels,
beyond how they are stored in the data warehouse.
You can also create other types of schema objects in

MicroStrategy Architect that you use for more advanced
functions:
TransformationsLogical objects most often used to

compare values at different timesfor 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.
Partition mappingsPartitioning is the division of a

larger table into smaller tables in the data warehouse. You
can bring partitioned tables into a MicroStrategy project
through warehouse partition mapping or metadata
partition mapping.
2011 MicroStrategy, Inc. Review of Schema Objects 23

The following illustration shows an example of each of these

types of schema objects. You will learn about these objects
later in the course:
Additional Schema Objects
24 Review of Schema Objects 2011 MicroStrategy, Inc.


Lesson Summary
In this lesson, you learned:
The project design process involves the following steps:

designing the logical data model, designing the data
warehouse schema, creating the project in MicroStrategy
Architect, and managing the project schema.
As part of managing the project schema, you will learn

how to define primary and secondary database instances,
use the Warehouse Catalog, understand
aggregation-awareness, create data marts, and enable
multisource report execution.
The following basic schema objects form the foundation of

a MicroStrategy project: tables, facts, attributes, and
hierarchies.
You can also create other types of schema objects in

MicroStrategy Architectsuch as transformations and
partition mappingsthat you use for more advanced
functions.
2011 MicroStrategy, Inc. Lesson Summary 25

26 Lesson Summary 2011 MicroStrategy, Inc.

2
MANAGING PROJECT SCHEMA
Lesson Description
This lesson covers a variety of advanced topics that enable

you to maintain a MicroStrategy project as it changes over
time and help you optimize performance within your project.
In this lesson, you will review the concept of primary and

secondary database instances. You will then learn about
Warehouse Catalog options that enable you to maintain
project tables. You will also learn how the MicroStrategy SQL
Engine is aggregate aware. Finally, you will learn how to
create aggregate fact tables using data marts. You will learn
what a data mart is, how to create data mart reports and data
mart tables, and how to incorporate data mart tables into a
project.

2 Managing Project Schema MicroStrategy Architect: Advanced Project Design
Lesson Objectives

Define the primary and secondary database instance, use the
Warehouse Catalog to maintain project tables, describe how
the MicroStrategy SQL Engine is aggregate aware, and create
aggregate fact tables using data marts.
Describe the primary and secondary database instances

and their use in MicroStrategy project. (Page 29)
Describe how the Warehouse Catalog options in

MicroStrategy Architect can help you maintain a project
over time. (Page 33)
Describe how MicroStrategy Architect calculates logical

table size, and how the SQL Engine uses logical table size
to select the optimal table for a query. (Page 39)
Define a data mart, and list and define data mart objects;
create a data mart table by creating and executing a data
mart report; list and define data mart column creation
options; use a data mart table in a project. (Page 46)

MicroStrategy Architect: Advanced Project Design Managing Project Schema 2
Review of Database Instances

Describe the primary and secondary database instances and
their use in MicroStrategy project.
A database instance is the logical object in the MicroStrategy

metadata that typically represents a connection to a data
warehouse. Whenever you run a report, you connect to the
data warehouse using the DSN, login, and password stored as
part of the database instance definition.
You learned how to create a database instance in the

course.
Ifauthentication
you are using security features such as warehouse
or connection mapping, different users
may access the same data warehouse using different
DSNs or logins. However, even in these cases, the
project database instance is still associated with a
default DSN and login.
Although a project uses a single primary database instance to

access the data warehouse, you can create any number of
secondary database instances that point to a variety of data
sources. You can then use these database instances for other
tasks such as creating data marts and Freeform SQL or Query
Builder reports.
Tohavecreate and configure database instances, you must

the appropriate administrative privileges.
For more information about Freeform SQL reports,

refer to the MicroStrategy Freeform SQL Essentials
course.
You also create and configure a database instance to

connect to an MDX data source. For more information
on MDX reports, refer to the MicroStrategy MDX
Cube Reporting Guide product manual.
2011 MicroStrategy, Inc. Review of Database Instances 29

Primary and Secondary Database Instances at the Project Level

By default, the database instance you select during the project
creation process becomes this projects primary database
instance. All standard reports in a project by default execute
against the data source defined in the primary database
instance.
Each MicroStrategy project must have a primary database

instance. However, you can associate any number of
secondary database instances with a single project.
If you want to use a secondary database instance in a project

to create data marts, Freeform SQL, Query Builder, or MDX
reports, you must first explicitly associate it with the project.
When you create a non-standard report, it then executes SQL
against the database instance to which it points.
You can also associate a secondary database instance

with a project automatically, when you add a table
from the secondary database instance to a project
using MultiSource Option. You will learn about
MultiSource Option later in this course.
To associate a secondary database instance with a project:
1 In MicroStrategy Desktop, log in to the project source that

contains your project.
2 Using the Database Instances manager, create the

database instance that points to the secondary data
source.
Tothelearn how to create database instances, refer to

MicroStrategy Architect: Project Design
Essentials or MicroStrategy Administration:
Configuration and Security courses.
3 Right-click the project name and select Project

Configuration.
4 In the Project Configuration Editor, in the Categories list,

expand the Database instances category.
30 Review of Database Instances 2011 MicroStrategy, Inc.

5 In the Available Data Mart, Query Builder, Freeform SQL

and non-primary warehouse database instances list, select
the database instance that you want to associate to the
project.
You can also create new database instance by

clicking New.
6 In the message window, click No.
This window asks you if you want to configure the

data mart optimization for the database instance.
You do not have to configure data mart
optimization if you do not plan to use that database
instance to create data marts. For information on
database optimization, see Data Mart
Optimization starting on page 50.
7 Click OK to close Project Configuration Editor.
The following image shows the Project Configuration Editor

with a single primary database instance and multiple
secondary database instances associated with the
MicroStrategy Tutorial project:
Primary and Secondary Database Instances
2011 MicroStrategy, Inc. Review of Database Instances 31

Whether you create a standard or a non-standard report, it

always executes SQL against a single data source (database
instance). If you want to combine data from multiple data
sources, you can then create a Report Services document and
include standard and non-standard reports that connect to
different data sources as its datasets. However, you cannot
access two distinct data sources within a single standard or
non-standard report unless you use MultiSource Option,
which is covered later in this lesson.
32 Review of Database Instances 2011 MicroStrategy, Inc.

Maintaining Warehouse Catalog

Describe how the Warehouse Catalog options in
MicroStrategy Architect can help you maintain a project over
time.

course, you learned how to create a MicroStrategy project.
However, a project grows and changes over time as the
volume of data or users increase, new requirements arise, or
existing requirements change. You need to be able to
adequately maintain a project throughout all stages of its
lifecycle. MicroStrategy Architect has functionality to assist
you with project maintenance.
MicroStrategy also has a variety of administration

functionality designed to help you with project
maintenance. For more information, see the
MicroStrategy Administration: Application
Management and Tuning course.
You already learned how to use the Warehouse Catalog to

select the data warehouse tables you want to use in a
MicroStrategy project. Now, you will learn about other
options available in the Warehouse Catalog that enable you to
maintain a project. You will learn about options that apply to
individual tables and options that apply to all tables across a
project.
Maintaining Individual Tables

After you add the warehouse tables to the project and create
schema and application objects, you may find that the
warehouse schema changes over time. The database
administrator may alter the structure of a table, for example,
by adding additional columns. Some table sizes may grow
over time, while others remain the same, making them better
candidates for aggregate queries. Some tables may become
obsolete and may be removed from the warehouse.
2011 MicroStrategy, Inc. Maintaining Warehouse Catalog 33

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. The following image displays these
individual table options:
Individual Table Options
The Warehouse Catalog provides the following options for

individual tables:
RemoveThis option enables you to remove a table from

the project.
Table StructureSelecting 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 StructureThis option is a shortcut to the

Update Structure function available in the Table Structure
window.
34 Maintaining Warehouse Catalog 2011 MicroStrategy, Inc.

Show Sample DataThis option enables you to view the

first 100 rows of data in a table.
Calculate Table Row CountSelecting 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 PrefixSelecting 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 InstancesSelecting 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. This
option enables you to choose additional database
instances in which you want to search for the table if you
cannot obtain it from the primary database instance.
The primary database instance is the database

instance that you should use for element browsing
against the selected table and queries that do not
require joins to other tables. The secondary
database instance is any other database where the
table also exists. You use it to support database
gateways and when you create duplicate tables
with MultiSource Option.
Import PrefixSelecting this option enables you to

retrieve a prefix for a table.
There are no table prefixes for the MicroStrategy

Tutorial data warehouse.
You can also choose to automatically display the

prefixes for all project tables in the warehouse
catalog using a project-wide option in the
Warehouse Catalog.

Project-Wide Warehouse Catalog Options

In addition to the table-level options, the Warehouse Catalog
also contains a variety of options that apply across a project.
You access these options in the Warehouse Catalog by
clicking the Options button on the toolbar. The following
image displays the Warehouse Catalog Options window,
which contains various categories of project-wide options:
Warehouse Catalog Options
These project-wide options are separated into a series of the

following expandable categories:
CatalogThe options in this category enable you to
quickly edit the primary project database instance, specify
custom login, customize the SQL statement to query the
database catalog tables, define different column reading
settings, and specify the default read mode.
The Warehouse Connection subcategory of the

Catalog category is displayed in the image above.

ViewThe options in this category enable you to specify

table viewing options, such as displaying table prefixes,
row counts, and name spaces by default.
The following image shows the Table Prefixes subcategory

in the View category:
View Category in the Warehouse Catalog

SchemaThe options in this category enable you to

configure the automatic mapping of schema objects to the
tables brought into the Warehouse Catalog and the
calculation of logical table sizes.
The following image shows the Automatic Mapping

subcategory in the Schema category:
Schema Category in the Warehouse Catalog
As you can see, the Warehouse Catalog has a host of options

that provide flexibility in maintaining your project over time.
For detailed information on the Warehouse Catalog

options, refer to the Project Design Guide product
manual.

Aggregation Awareness

Describe how MicroStrategy Architect calculates logical table
size, and how the SQL Engine uses logical table size to select
the optimal table for a query.
Review of Base and Aggregate Fact Tables

course, you learned that there are two types of fact tables that
you typically have in a data warehouse. Base fact tables are
tables that store a fact or set of facts at the lowest possible
level of detail. Aggregate fact tables are tables that store a
fact or set of facts at a higher, or summarized, level of detail.
For example, consider the following two fact tables:

Base and Aggregate Fact Tables
The FACT_SALES table stores dollar and unit sales data at

the lowest possible level of detailby item, employee, and
date. Therefore, it is the base fact table for these two facts.
The FACT_SALES_AGG table stores dollar and unit sales
data at a higher level of detailby category, region, and
month. Therefore, it is an aggregate fact table for these two
facts.
2011 MicroStrategy, Inc. Aggregation Awareness 39

Because they store data at a higher level, aggregate fact tables

reduce query time. For example, if you want to view a report
that shows unit sales by region, you can obtain the result set
more quickly using the FACT_SALES_AGG table than the
FACT_SALES table.
In a data warehouse, you often have multiple aggregate fact

tables for the same fact or set of facts to enable you to more
quickly analyze fact data at various levels of detail.
For guidelines on building aggregate fact tables, refer

to the MicroStrategy Advanced Data Warehousing
course.
Using Aggregate Tables in a Project
There are two actions that you need to perform to integrate

an aggregate fact table into an existing project:
1 Add the table to the project using the Warehouse Catalog.
2 If necessary, map the existing attributes and facts to the

aggregate table.
If your aggregate fact table structure is consistent with your

base fact table structure, MicroStrategy Architect is
intelligent enough to automatically add the table to the
definitions of your existing attributes and facts. However, if
your aggregate fact table structure contains new columns that
have not been mapped to existing attribute form expressions
and fact expressions, you have to manually map the new table
to the desired attributes and facts.
Iffactthetable,
aggregate fact table structure matches the base
MicroStrategy Architect can automatically
map the new table to existing attributes and facts as
long as automatic mapping is used for the
corresponding attribute form expressions and fact
expressions.
40 Aggregation Awareness 2011 MicroStrategy, Inc.

How Is MicroStrategy Aggregate-Aware?

At this point, you should understand how MicroStrategy
Architect becomes aware of aggregate fact tables. However,
the question remains as to how MicroStrategy Architect
knows to use the aggregate table rather than the base fact
table in cases where either table could provide the answer.
MicroStrategy Architect assigns a size to every table in a

project when you initially add them to the project and stores
these size assignments in the metadata. It assigns sizes based
on the columns in the tables and the attributes to which those
columns correspond. Because MicroStrategy Architect uses
the logical attribute definitions to assign a size to each table
in the project, this measurement is referred to as logical table
size.
The following illustration is a visual representation of the

algorithm used by MicroStrategy Architect in assigning
logical table sizes:
Calculating the Logical Table Size

Logical table size is the sum of the weight for each attribute
contained in the table. Attribute weight is defined as the
position of an attribute in its hierarchy divided by the number
of attributes in the hierarchy multiplied by a factor of 10.
Therefore, using this formula, MicroStrategy Architect
calculates the respective weight of each attribute as shown in
the illustration above. Then, the logical table size of each fact
table is simply the sum of their respective attribute weights.
You can view the logical table size for each table in the Logical
Table Editor. When the SQL Engine can obtain data from two
or more tables in the warehouse, it looks at the logical table
size and generates SQL against the table with the smallest
logical table size. This process helps the SQL Engine select
the optimal table for a query.
Changing the Logical Table Size
At times, you may need to reassign the logical table size for a
table. For example, in the previous illustration for logical
table sizes, there are two aggregate fact tables that both have
the same logical table size of 15. However, one of these tables
contains item and region information, and the other one has
class and store information. Clearly, based on the attributes
they contain, the table with item and region information is
larger. There are many more items than classes to which
items belong. In this example, where the logical table size is
the same but the physical size is actually very different, you
can change the logical table size automatically assigned by
MicroStrategy Architect.
Generally, smaller logical size does equate to smaller physical

size. Tables with higher-level attributes usually have a
smaller logical table size than tables with lower-level
attributes. However, there are times when this is not the case
due to the particular combination of attributes in a table. In
such cases, you have to change the logical table size to force
the SQL Engine to use the table that you know has a smaller
physical size.

To change the logical table size for a table:
1 In MicroStrategy Desktop, in the Schema Objects folder,

in the Tables folder, double-click the table you want to
modify.
2 In the Table Editor, on the Logical View tab, in the Logical

size box, type the new value that you want to assign for the
logical size.
3 Select the Preserve this logical size when updating

Schema information (Lock Logical Table Size) check
box.
You should select this option if you want to ensure

that the logical size you have selected is not
overwritten by MicroStrategy Architect during
updates of the project schema. When you update
the project schema, you can choose to update
logical table sizes. You may need to perform this
action for other tables. Selecting this option allows
you to update the logical sizes of other tables while
preserving the sizes of tables that you have
manually assigned.
4 Click Save and Close.
5 Update the project schema.

The following image shows the Table Editor for the

CITY_CTR_SLS fact table with the logical size set to 15:
Changing Logical Size in the Table Editor
Using the Table Editor, you can change the logical size for an
individual table. This procedure works fine if you are
changing the logical size of just a few tables. However, it is
tedious if you have to change the logical size for a number of
tables. Alternatively, you can use the Logical Size Editor. This
editor provides a single interface for you to change the logical
size of any table in a project.
To change logical table sizes using the Logical Size Editor:
1 In MicroStrategy Desktop, on the Schema menu, select

Edit Logical Size.
2 In the Logical Size Editor, for the table you want to

modify, in the Size value box, type the new value you want
to assign for the logical size.
3 If you want to preserve the logical table size, select the

Size locked check box for the table.
4 Repeat steps 2 to 3 for each table that you want to modify.

5 When you have changed the logical sizes for all the
desired tables, on the File menu, select Save.
6 On the File menu, select Close.
The following image shows the Logical Size Editor:

Changing Logical Size in the Logical Size Editor

Data Marts

Define a data mart, and list and define data mart objects;
create a data mart table by creating and executing a data mart
report; list and define data mart column creation options; use
a data mart table in a project.
What Is a Data Mart?

A data mart is a relational table containing results of a
report. You create the data mart report in MicroStrategy
Desktop and you save the data mart table in a warehouse of
your choice. After you create a data mart table, you can add it
to a project and then use it as a source table from which to
execute reports.
Some common applications for data marts are:
Creating aggregate fact tables
Creating tables for very large result sets and then using
other applications such as Microsoft Excel or Microsoft
Access to access the data
Creating tables for off-line analysis
In this lesson, you will use data marts to create aggregate fact
tables.
46 Data Marts 2011 MicroStrategy, Inc.

For example, consider the following scenario:

Base Fact Table
In this example, forecasting data is stored at the employee

and date level in the FORECAST_SALES base fact table.
However, you want to report on the forecast unit sales at the
region level. Since the report displays data at the region level,
the Engine has to roll the data up from the employee level
through call center to the region level. This requires three
joins from the fact table to the LU_REGION lookup table. In
addition, the FORECAST_SALES table may have millions of
rows. This query may be very costly, especially if the users
request it often.
2011 MicroStrategy, Inc. Data Marts 47

What if you could create an aggregate table that limits the

number of joins and the number of rows in the fact table? You
can achieve this with a data mart. You can then bring this
table into your project, map the forecast unit sales to it, and
have your region-level reports automatically use it, as shown
below:
Aggregate Fact Table Created as Data Mart
Data Mart Objects
Creating data marts involves creating two objects:
Data mart reportThis is a metadata object that you

create in the Report Editor. When executed, the data mart
report creates the data mart table in the warehouse of
your choice. The data mart report contains attributes,
metrics, and other application objects that translate into
columns in the data mart table.
Data mart tableThis is the relational table created after

the execution of a data mart report.
Data Mart Database Instances
When you create a data mart report, you must specify a

database instance in which to create the data mart table.
You create a data mart in a database instance in one of the

following ways:
Option 1Use the projects primary database instance.

Option 2Use a secondary project database instance that

exists in the same warehouse as the primary project
database instance.
Option 3Use a different database instance than the

project, and one that is in a different warehouse than the
primary project database instance.
The following figure illustrates each of these data mart

database instance options:
Data Mart Database Instance Options
If you use the primary project database instance, then you do

not need to take any additional steps to create a data mart.
You simply select the primary data mart database instance as
a target when you create the data mart report.
For more details on how to create data marts, see

Creating Data Marts starting on page 53.

If you plan to use a secondary project database instance, then

you must create that database instance before creating the
data mart. You then associate this database instance to the
project in the Project Configuration Editor.
For instructions on how to associate a secondary

database instance to a project, see To associate a
secondary database instance with a project: starting
on page 30.
Data Mart Optimization
When you associate a secondary database instance to a

project in the Project Configuration Editor, a message
window displays prompting you to configure data mart
optimization:
Data Mart Optimization Warning Message
This message does not display if you have enabled data

mart optimization for the data mart database instance
before you associated this database instance to a
project.
When you click Yes, the Database Instances editor for the
data mart database instance opens with the Advanced tab
automatically selected.
Data mart optimization occurs when you create a data

mart in the primary project database instance or in a
database instance that points to the same data
warehouse as the primary project database instance.

To optimize a database instance:
1 In the Database Instances editor, on the Advanced tab,

under Data mart optimization, select the This database
instance is located in the same warehouse as check
box.
Ifinthe data mart database instance does not reside

the same warehouse as the project database
instance, do not select this check box.
2 In the list of database instances, select the primary project

database instance.
3 Click OK.
The following image shows the data mart optimization option

for the database instance that resides in the same warehouse
as the Tutorial Data:
Data Mart Optimization Option

Why Optimize?
When you create a data mart using the primary project

database instance or using a database instance that resides in
the same warehouse as the primary project database
instance, you simplify the SQL that is generated to create the
data mart. You also conserve the Intelligence Server machine
resources by minimizing the memory footprint.
The following table displays sample SQL generated when

creating a data mart using a database instance in the same
data warehouse as the primary project database instance, and
when using a different data warehouse:
Sample SQL
Same Data Warehouse Different Data Warehouse
drop table Same_ Datamart _Instance select a11.Month_Id Month_Id,

max(a12.Month_Desc) Month_Desc,
sum(a11.Tot_Dollar_Sales) DOLLARSALES
create table Same_ Datamart _Instance
(Month_Id INTEGER, Month_Desc from MNTH_CATEGORY_SLS a11
VARCHAR(100), DOLLARSALES FLOAT) join LU_MONTH a12
on (a11.Month_Id = a12.Month_Id)
insert into Same_Datamart_Instance group by a11.Month_Id
select a11.Month_Id Month_Id,
max(a12.Month_Desc) Month_Desc, drop table Different_ Datamart _Instance
sum(a11.Tot_Dollar_Sales) DOLLARSALES
from MNTH_CATEGORY_SLS a11 create table Different_ Datamart _Instance
join LU_MONTH a12 on (a11.Month_Id = (Month_Id INTEGER, Month_Desc
a12.Month_Id) VARCHAR(100), DOLLARSALES FLOAT)
insert into Different_ Datamart _Instance

values 201001, 'Jan 2010', 8817)
When you create the data mart in the same data warehouse,
MicroStrategy Intelligence Server creates the data mart table
in the project warehouse and then inserts the result data rows
directly into the table.
When you create the data mart in a different data warehouse,

MicroStrategy Intelligence Server extracts the results from
the project data warehouse with a SELECT statement and
brings the result set into the Intelligence Server machines
memory. It then creates the data mart table in the different
data warehouse and inserts the results.

Creating Data Marts

In MicroStrategy Desktop, you create a data mart report by
converting an existing report or by creating a new report.
To create a data mart:
1 In the Report Editor, on the Data menu, select Configure

Data Mart.
The report template must contain an attribute, a

metric, or some other object for this option to be
enabled.
2 In the Report Data Mart Setup window, on the General

tab, in the Data mart database instance drop-down list,
select the database instance in which you want to create
the data mart table.
3 In the Table name box, type the name of the data mart
table you want to create.
The table name you type is not validated by the

system at this point.
By default, the This table name contains placeholders

check box is selected. The selection of this check box
enables you to specify whether the data mart table uses
placeholders to name the table. Placeholder names enable
you to modify table names dynamically.
The following table lists placeholders available for naming

data mart tables.
Data Mart Placeholders
Placeholder Replacement Option
!U user name
!D date on which table was created
!O report name
??? temporary table name
!!! all column names
!a attribute column names

Data Mart Placeholders
Placeholder Replacement Option
!j job ID
!r report GUID
!t timestamp
!p project name
!z project GUID
!s user session GUID
4 Select one of the following options:
Create a new table
Append to existing tableThis option enables you to

add the data mart report results to an existing table.
The name specified in the Table name box must be the
name of the existing table you want to append.
5 On the Advanced tab, specify data mart governors and

table creation properties.
6 On the SQL Statements tab, specify SQL statements that

can be inserted before and after the table is created or
before data is inserted in the table.
For information on the data mart governors, table

creation properties, and SQL statements refer to
the Advanced Reporting Guide product manual.
7 Click OK to close the Report Data Mart Setup window.
You may see a warning that data mart tables created in

common table spaces may overwrite someone elses
data mart table. If you want to proceed, click OK.
8 Save the report.
9 Execute the data mart report to create the data mart table.

For example, using the Forecasting Project you can create a

data mart report that contains the Region and Year attributes
and the Forecast Units Sold metric, as shown in the image
below:
Data Mart Report Definition
You can then convert this report into a data mart. The
following image shows the Report Data Mart Setup Window
with data mart report configured as
REGION_YEAR_FORECAST_UNIT_SALES table in the
Forecast Data database instance:
Report Data Mart Setup Window

The following image shows a message displayed by the data

mart report when it is executed:
Data Mart Execution Complete Message
Data Mart Options
A data mart table has the same structure as any other data
warehouse table. By default, it contains columns
corresponding to all attribute forms and metric columns
present on the report template.
You can control the structure of a data mart table in the

following ways:
You can control what attribute columns are included in

the data mart table.
You can determine the names for the columns that

contain the metric calculations.

Attribute Columns
A data mart table contains an attribute ID column for each

attribute selected in the data mart report. Additionally,
depending on the default display for each attribute in the data
mart report, the data mart table can also include attribute
description columns.
Generally, you would remove any non-ID form

descriptions from the data mart report display to avoid
storing duplicate attribute descriptions in the data
mart table.
Consider the data mart report from the previous example that
has the Region and Year attributes and the Forecast Units
Sold metric on the template. Assuming that the default
display for the Region attribute is ID and description, and for
Year is ID, when the data mart report is executed, the data
mart table contains the following columns:
REGION_ID
REGION_NAME
YEAR_ID
WJXBFS1
If you do not want to include attribute description columns in

your data mart table to improve query performance, you
must modify the attribute display and forms available in
report objects for each attribute in the data mart report.
To modify the attribute display in a data mart report:
1 In the Report Editor, on the Data menu, select Attribute

Display.
2 In the Attribute Display window, in the Attribute

drop-down list, select the attribute whose display you
want to modify.
3 Under Select one of the display options below, click Use

the following attribute forms.
4 In the Available forms list, select the ID form.

5 Click the upper > button to move the ID form to the

Displayed forms list.
6 In the Displayed forms list, select all non-ID forms.
7 Click the upper < button to remove the non-ID forms

from the report display.
8 In the Report objects forms list, select all non-ID forms.
9 Click the lower < button to remove the non-ID forms from
the report objects.
10 Click OK.
The following image shows the Attribute Display window

with the Region attribute configured to use only the ID form:
Attribute Display Options

Using the previous example, after you change the display for
the Region attribute from description to ID only, and then
execute the data mart report, the data mart table contains the
following columns:
REGION_ID
YEAR_ID
WJXBFS1
Metric Column Alias
A data mart table contains a column that corresponds to each

metric selected in the data mart report. These columns,
created from metric calculations, become the fact columns.
By default, the alias generated for a fact column in a report

SQL is WJXBFS<n>, where n is a number. The first metric
alias MicroStrategy Engine creates for a report is WJXBFS1,
the next WJXBFS2, and so forth.
If you want to use a different name, you can create a column

alias for the fact column that contains the metric calculation.
You specify the column alias in the Metric Editor of the

metric on which the column is based.
To name a fact column in a data mart table:
1 In the Metric Editor, on the Tools menu, point to

Advanced Settings and select Metric Column Options.
2 In the Metric Column Alias Options window, in the

Column Name used in table SQL creation box, type a
name for the metric column.
3 In the Data type drop-down list, select the data type and,
if appropriate, define other relevant parameter setting(s).

4 Click OK to close the Metric Column Alias Options

window.
5 Save and close the metric.
The following image shows a custom Total_Unit_Sales

column alias for the Forecast Units Sold metric:
Metric Column Alias Options Window
Using the same example, after you change the column alias
for the Forecast Revenue metric, and then execute the data
mart report, the data mart table contains the following
columns:
REGION_ID
YEAR_ID
Total_Unit_Sales
Using Data Marts in a Project

After you create the data mart report and execute it, the data
mart table (with report result set) is created in the data
warehouse. This table is like any other physical data
warehouse table.
To use a data mart table as a source table in the project in

which the data mart was created, you must first update the
warehouse catalog for the project, then update the
appropriate fact, and finally update the project schema.

Updating Warehouse Catalog
To update the warehouse catalog:

Warehouse Catalog.
2 In the Warehouse Catalog editor, in the Tables available

in the database instance list, select the data mart table and
click the upper > button.
3 On the toolbar, click Save and Close.
The following image shows the

REGION_YEAR_FORECAST_UNIT_SALES table added to
the projects warehouse catalog:
REGION_YEAR_FORECAST_UNIT_SALES Added to the
Project
Updating the Fact
To use the data mart table as a source table from which to

execute reports, you must update the fact on which the metric
used to create the data mart table is based.

To update the fact expression:
1 In MicroStrategy Desktop, edit the metric used in the data

mart table in the Metric Editor.
2 In the Metric Editor, determine the fact on which the

metric is based.
The relationship of the metric to the fact on which

it is based is referred to as a child dependency. You
can use MicroStrategy Object Manager to quickly
locate child dependencies for the metric.
3 In the Schema Objects folder, in the Facts folder, open the

fact on which the data mart metric is based.
4 In the Fact Editor, create a new fact expression that uses

the data mart table as a source table.
Ifsame
the fact column in the Data Mart table is named the
as the underlying fact, you may select the
Automatic mapping method for the new fact
expression. By default, when you create a data mart
table, the fact has a unique name that is different than
the other facts in the project.
5 Save and close the fact.

The following image shows the Forecast Units Sold fact

mapped to the data mart aggregate table:
Mapping a Fact to a Data Mart Table
Updating the Project Schema
After you add the data mart table to a project and update the
appropriate fact object, you must also update the schema
logical information in the metadata.


Exercises: Managing Project Schema
Create an Aggregate Table Using Data Mart
Forecasting Project Information
You should complete the following exercises using the

Forecasting Project, which is found in the MicroStrategy
Analytics Modules project source. The logical data model and
schema for this project are included with the exercises. You
need to review this information before beginning the
exercises.
You will also use the Forecasting Project to complete

other exercises throughout this course.
The Forecasting Project is based on the following logical data

model:
Forecasting Project Logical Data Model
64 Exercises: Managing Project Schema 2011 MicroStrategy, Inc.

The Forecasting Project consists of several attributes in the

Time and Geography hierarchies. The attributes in both
hierarchies are indirectly related to each other through the
fact tables.
The attributes in the Time hierarchy are the following:

Attributes in the Time Hierarchy
The attributes in the Geography hierarchy are the following:

Attributes in the Geography Hierarchy
2011 MicroStrategy, Inc. Exercises: Managing Project Schema 65

The schema for this project consists of the following lookup

tables:
Lookup Tables
The schema for this project consists of the following fact

tables:
Fact Tables
The data warehouse for the Forecasting Project

contains additional tables. You will bring some of
those tables into the MicroStrategy Tutorial project
later in this course.

Overview
In this exercise, you will first create a

REGION_FORECAST_SALES aggregate table using the data
mart feature in the Forecasting Project. You will then bring
this table to the project and test how the Engine selects the
fact table based on the logical table size.
Later in the course, you will also bring this data mart
table into the MicroStrategy Tutorial project using
MultiSource option.
Before you create a data mart, you will first modify the
Forecast Revenue metric to use a custom Forecast_Revenue
column alias. You will then create a data mart report with
Region ID and Quarter ID attribute forms on the template
and the Forecast Revenue metric. Name the data mart table
REGION_FORECAST_SALES. Save the data mart report as
Regional Forecast Revenue in the Public Objects\Reports
folder.
Next, you will add the table to the Forecasting Project. Then,
you will create a new fact expression for the Forecast Revenue
fact that uses the Forecast_Revenue column in the
REGION_FORECAST_SALES table. You will also create
and run a Data Mart Test report with the Region attribute
and the Forecast Revenue metric on the template to
confirm that the Forecast Revenue fact uses the
REGION_FORECAST_SALES table.
Finally, you will change the logical table size for the
REGION_FORECAST_SALES table to 30 and run the Data
Mart Test report to view the impact of your change on the
report SQL.
You can use the detailed instructions if you want help.
Detailed Instructions
Modify metric alias
1 In MicroStrategy Desktop, log in to the MicroStrategy

Analytics Modules project source as Administrator and
leave the password blank.

2 Open the Forecasting Project.
3 In the Public Objects folder, in the Metrics folder, edit the

Forecast Revenue metric.
4 In the Metric Editor, on the Tools menu, point to

Advanced Settings and select Metric Column Options.
5 In the Metric Column Alias Options window, in the

Column Name used in table SQL creation box, type
Forecast_Revenue.
6 Click OK to close the Metric Column Alias Options

window.
Create the Data Mart report
8 In the Public Objects folder, in the Reports folder, create

the following report:
You can access the Region attribute from the

Geography hierarchy. You can access the Quarter
attribute from the Time hierarchy. The Forecast
Revenue metric is located in the Metrics folder.
Configure attribute display options
9 In the Report Editor, on the Data menu, select Attribute

Display.

drop-down list, ensure that Region is selected.



14 In the Displayed forms list, select the DESC form.
15 Click the upper < button to remove the DESC form from
the Displayed forms list.
16 In the Report objects forms list, select the DESC form.
17 Click the lower < button to remove the DESC form from
the Report objects forms list.

drop-down list, select Quarter.


22 In the Displayed forms list, select the DESC form.
23 Click the upper < button to remove the DESC form from
the Displayed forms list.
24 In the Report objects forms list, select the DESC form.
25 Click the lower < button to remove the DESC form from
the Report objects forms list.
26 Click OK.
Configure the data mart
27 In the Report Editor, on the Data menu, select Configure

Data Mart.
28 In the Report Data Mart Setup window, on the General

tab, in the Data mart database instance drop-down list,
ensure the Forecast Data database instance is selected.

29 In the Table name box, type

REGION_FORECAST_SALES.
30 Click OK.
Configure the data mart
31 Run the report.
After the report executes, you see a message that the

result data has been stored in the
REGION_FORECAST_SALES table, as shown below:
32 Save the report in the Public Objects\Reports folder as

Regional Forecast Revenue and close the report.
Incorporate the data mart table into the project

Warehouse Catalog.
34 In the Warehouse Catalog editor, in the Tables available

in the database instance list, double-click the
REGION_FORECAST_SALES table to include it into the
project.
35 On the toolbar, click Save and Close.
Update the Forecast Revenue fact
36 In the Schema Objects folder, in the Facts folder,

double-click the Forecast Revenue fact.

37 In the Fact Editor, create a new fact expression that uses

the Forecast_Revenue column in the
REGION_FORECAST_SALES table as a source table.
38 Use the Automatic mapping method and ensure that the

aggregate table is selected as the source table.
39 Save and close the fact.
Update the project schema
Ensure that the Recalculate Logical Table Size

checkbox is selected in the Schema Update
window.
Test the new fact mapping
41 In the Public Objects\Reports folder, create the following

report:
You can access the Region attribute from the

Geography hierarchy. The Forecast Revenue metric
is located in the Metrics folder.
42 Run the report. The result set should look like the
following:

43 Switch to the SQL View for the report. The SQL should
look like the following:
In the FROM clause, notice that the data is retrieved from

the new aggregate REGION_FORECAST_SALES table.
44 Save the report in the Reports folder as Data Mart Test

and close the report.
Change the logical table size for the aggregate table

Edit Logical Size.
Notice that the REGION_FORECAST_SALES tables

logical size is 10. The logical size for the
FORECAST_SALES table is 20. Therefore, when you
execute any report that aggregates the forecast revenue
data to the region or quarter level, the Engine chooses the
REGION_FORECAST_SALES table due to its lower
logical table size.
46 In the Logical Size Editor, for the

REGION_FORECAST_SALES table, in the Size value
box, type 30.
47 For the REGION_FORECAST_SALES table, select the

Size locked check box.
When you select this check box, when you update the
schema, the logical size for this table will not be
recalculated.
48 On the File menu, select Save.
49 On the File menu, select Close.

Update the project schema.
Ensure that the Recalculate Logical Table Size

checkbox is selected in the Schema Update
window.
Test the change of the logical table size on the report SQL
51 In the Reports folder, right-click the Data Mart Test

report and select View SQL. The SQL should look like the
following:
Notice that this time, the Engine picked the base

FORECAST_SALES table over the aggregate
REGION_FORECAST_SALES table because it has a
smaller logical table size.
52 Close the report without saving it.
Modify a Warehouse Table
Overview
In this exercise, you will modify a lookup table for the

Category attributeLU_CATEGORYin the MicroStrategy
Tutorial data warehouse to include an additional
PRODUCT_ID column.

The TUTORIAL_DATA_7200.mdb data warehouse is

located in the C:\Program
Files\MicroStrategy\Tutorial Reporting folder.
You will use the Number data type and type the following
values in the PRODUCT_ID column:
Finally, you will update the structure of the LU_CATEGORY

table using the Warehouse Catalog in the MicroStrategy
Tutorial project.
Modify the lookup table to include the PRODUCT_ID

column in the LU_CATEGORY table
1 Open Windows Explorer and navigate to the C:\Program

Files\MicroStrategy\Tutorial Reporting folder.
2 In the Tutorial Reporting folder, double-click

TUTORIAL_DATA_7200.mdb.
This file is the out-of-the-box data warehouse

database for the MicroStrategy Tutorial project.
The instructions in this exercise are for Microsoft

Access 2007.
3 In Microsoft Access, in the TUTORIAL_DATA_7200:

Database window, in the Tables list, double-click the
LU_CATEGORY table.
4 Right-click the Category_ID column header and select

Insert Column.

This action inserts a new column named Field1.

5 Double-click the Field1 column header.
6 Type PRODUCT_ID as the column name.
7 Press ENTER.
8 Type the following values in the Product_ID column:
9 Click Save.
10 On the toolbar, click View.
11 In the LU_CATEGORY table, next to PRODUCT_ID, in

the Data Type drop-down list, select Number.
12 Click Save.
13 In the warning window, click Yes.
14 Close the table.
15 Close Microsoft Access.
Update the LU_CATEGORY table structure
16 In MicroStrategy Desktop, in the MicroStrategy Analytics

Modules project source, open the MicroStrategy Tutorial
project.

17 Open the Warehouse Catalog.
18 In the Tables being used in the project list, right-click the

LU_CATEGORY table and select Update Structure.
19 To confirm that the structure has been updated,

right-click the LU_CATEGORY table and select Table
Structure.
In the Table Structure window, you should see the

PRODUCT_ID column.
20 In the Table Structure window, click Close.
21 Save and close the Warehouse Catalog.


Lesson Summary
The database instance you select during the project

creation process becomes this projects primary database
instance.
You can associate any number of secondary database

instances with a single project. You use secondary
database instances to create data marts, Freeform SQL,
Query Builder, and MDX reports. You associate secondary
database instances with a project using the Project
Configuration Editor.
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.
Base fact tables are tables that store a fact or set of facts at
the lowest possible level of detail. Aggregate fact tables are
tables that store a fact or set of facts at a higher, or
summarized, level of detail.
To use aggregate tables in the project, you first add the

table to the project using the Warehouse Catalog. If
necessary, you also map the existing attributes and facts
to the aggregate table.
MicroStrategy Architect assigns a logical table size to

every table in a project when you initially add them to the
project and stores these size assignments in the metadata.
It assigns sizes based on the columns in the tables and the
attributes to which those columns correspond.
Logical table size is the sum of the weight for each

attribute contained in the table. Attribute weight is
defined as the position of an attribute in its hierarchy
divided by the number of attributes in the hierarchy
multiplied by a factor of 10.
You can change the logical table size either in the Logical
Table Editor or in the Logical Size Editor.

A data mart is a relational table containing a report result

set. A data mart consists of two objects: the data mart
report and the data mart table.
You can use data marts to create aggregate tables and

tables based on large report result sets.
Data mart reports are created in the Report Editor of a

new or existing report. After you execute the data mart
report, the data mart table is created.
You can choose to create only attribute ID columns in the

data mart table by removing all non-ID forms from the
attribute display and report objects in the data mart
report.
For the columns in the data mart table that contain metric
calculations, you can use the existing metric name as the
column name or you can create a new column alias.
To use a data mart table in a project, you must add it to

the project using the Warehouse Catalog, update the
corresponding fact, and then update the project schema.

3
USING MICROSTRATEGY
MULTISOURCE OPTION
Lesson Description
This lesson describes how to use MicroStrategy MultiSource

Option to access heterogeneous data sources.
In this lesson, you will first learn how MultiSource Option

works, including the use of primary and secondary database
instances at the table level, support for duplicate tables, SQL
generation for multisource reports, and common use cases.
Then, you will learn how to configure a project for
heterogeneous data access, including associating tables with
multiple database instances, creating objects to use in
multisource reports, and creating multisource reports.

3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design
Lesson Objectives

heterogeneous data sources, associate tables in a project to
multiple database instances, create objects for multisource
reports, and create multisource reports.

heterogeneous data sources, including support for
duplicate tables, SQL generation for reports with multiple
data sources, and common use cases. (Page 81)
Associate tables with single or multiple data sources,

change the primary database instance for a table, and
remove a database instance from a table. (Page 96)
Create objects for use in multisource reports. (Page 115)
Create a report that contains objects from multiple data

sources and describe how the Engine processes the SQL
for such reports. (Page 119)

MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3
Introduction to MicroStrategy MultiSource

Option

heterogeneous data sources, including support for duplicate
tables, SQL generation for reports with multiple data sources,
and common use cases.
By default, the objects in a standard report have to come from

a single data source. However, you can use the MultiSource
Optionan add-on component to Intelligence Serverto
overcome this limitation. MultiSource Option enables you to
define a single project schema that uses multiple data
sources. As a result, you can create a standard report that
executes SQL against multiple data sources.
For example, consider the following scenario in which actual

revenue data is stored in one data warehouse, while forecast
revenue data is stored in a second data warehouse:
Report with Objects from Multiple Data Sources
2011 MicroStrategy, Inc. Introduction to MicroStrategy MultiSource Option 81

If you want to create a report that includes the revenue and

forecast revenue data for each region, you have to execute
SQL against both data warehouses to retrieve the result set.
You obtain the data for each of the metrics from their
respective data warehouses. You can obtain the region data
from either data warehouse since it exists in both databases.
MultiSource Option enables you to create a report to execute
a query like this one that crosses data sources.
Primary and Secondary Database Instances at the Table Level

When you associate a primary or secondary database
instance with a project when you initially create it, or when
you modify the project properties in the Project
Configuration Editor, you do this at the project level.
Without MultiSource Option, you can use secondary

database instances for standard reports only if you
implemented a database gateway. Starting with
MicroStrategy 9.0, MultiSource Option is the default
method for accessing multiple data sources. However,
you can configure the Multiple data source support
VLDB property if you want to use a gateway rather
than MultiSource Option.
With MultiSource Option, you have the ability to define

primary and secondary database instances at the table level
and connect to them directly within the MicroStrategy
platform. This capability enables you to define a project
schema across multiple relational data sources.
With MultiSource Option, you can define a project schema as

follows:
You select a primary database instance for the project.
You can add tables to the project from different database

instances, not just the primary database instance for the
project.
Any SQL database instance that exists within the

project source is available to the project as a
secondary database instance from which you can
select tables.
82 Introduction to MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.

You can associate a single project table with multiple

database instances, which essentially creates duplicate
tables.
However, keep in mind that MultiSource Option has the

following limitations:
You can use MultiSource Option to connect to any data

source that you access using an ODBC driver, including
Microsoft Excel files and text files. You cannot use
MultiSource Option to connect to MDX or other
non-relational data sources.
You can only create logical views using the primary

database instance for a project. You cannot create logical
views using secondary database instances or multiple
database instances.
For more information about logical views, refer to

the MicroStrategy Advanced Data Warehousing
course.
MultiSource Option does not support fact tables

partitioned across multiple data sources.
For more information about partitioning, see the

Partitioning lesson starting on page 221.
Support for Duplicate Tables

You have duplicate tables when you map the same project
table to more than one database instance. For example, you
saw in the earlier example that the LU_REGION table exists
in two data warehouses. You can bring both LU_REGION
tables to the project. Although the tables are two separate
physical tables in their respective data warehouses, they are
treated as one logical table in the MicroStrategy project.

You can have lookup, relationship, and fact tables duplicated

across multiple data sources. However, because of how the
Engine selects the data source for fact tables, there is benefit
to using duplicate tables only for lookup and relationship
tables.
For information on how the Engine selects the data

sources for tables, see Selecting the Optimal Data
Source for Fact Tables starting on page 87 and
Selecting the Optimal Data Source for Lookup
Tables starting on page 88.
When you bring duplicate tables to the project, you must

consider the following guidelines required by MultiSource
Option:
Duplicate tables must have identical table and column
names.
Corresponding columns in duplicate tables must either

have the same data type or compatible data types.
Todatamaintain data consistency, the Engine applies

type compatibility rules when it joins columns
in tables from different database instances. For
information on these rules, see Joining Data from
Different Data Sources starting on page 89.
The number of columns in the table associated with the
primary database instance has to be less than or equal
to the number of columns in the table associated with the
secondary database instance. Any extra columns in the
secondary table are not imported into the project.
Ideally, duplicate tables have the same number of

columns. However, if there are extra columns, they
can exist only in the table associated with the
secondary database instance. Otherwise, you must
treat the tables as two different tables.

If you have a logical table that maps to multiple database

instances, the icon for the table is different from the standard
icon used for logical tables within a project. The following
icon indicates a table with multiple data sources:
Table Icon for Multiple Data Sources
This icon is visible beside tables only in the Warehouse

Catalog and the Architect graphical interface.
SQL Generation for Multisource Reports

If you have a report that uses objects from multiple data
sources, the SQL generation for the report is handled a little
differently than for single-sourced reports.
With reports that use multiple data sources, much of the

work of the SQL Engine remains the same. However, the
Engine performs two additional tasks:
It determines the optimal database instance for each pass

of SQL.
It identifies when joins need to occur across database

instances.

Designating Primary and Secondary Tables
Every project table has a primary database instance. The

primary database instance is the first one to which it is
mapped. If you have duplicate tables, the same table can have
both primary and secondary database instances. The
primary table is the one that exists in the primary database
instance. The secondary table is the one that exists in the
secondary database instance.
You can change which database instance is the

primary one for a table. For information on changing
the primary database instance for a table, see
Changing the Primary Database Instance for a Table
starting on page 108.
You can have multiple secondary tables if the table is

mapped to more than one secondary database
instance.
For example, consider the scenario introduced previously:

Report with Objects from Multiple Data Sources
In this example, the two fact tables each map to only one
database. The primary database instance for the
REGION_SALES table is the Sales Data Warehouse. The
primary database instance for the FORECAST_SALES table
is the Forecast Data Warehouse.

However, the LU_REGION table exists in both data

warehouses, so you can map it to both database instances as
duplicate lookup tables. You can assign either data
warehouse as the primary or secondary database instance for
this table.
If you designate the Sales Data Warehouse as the primary

database instance for this table, the LU_REGION table from
that database is the primary table. The LU_REGION table
from the Forecast Data Warehouse is the secondary table.
If a table is available in a single data source, that source is the

only one the Engine can use in the report SQL to obtain the
necessary data. However, if a table is available in multiple
data sources, the Engine uses specific logic to select the
optimal data source.
Selecting the Optimal Data Source for Fact

Tables
SQL generation for reports is focused on metric data. When

the Engine needs to calculate a metric, it first has to
determine the best source for the underlying fact. After
taking into account attributes in the template, the metric's
dimensionality, and report or metric filters, the Engine uses
the following logic to select the optimal data source for a fact:
If the fact comes from a fact table that is available in the

primary database instance for the project, the Engine
calculates the metric using the primary database instance
for the project.
If the fact comes from a fact table that is not available in

the primary database instance for the project, the Engine
calculates the metric using a secondary database instance.
If the fact table is available in more than one secondary
database instance, the Engine selects the database
instance with the smallest GUID (alphabetically).
In essence, the Engine considers only the primary and

secondary database instance designation at the project level
when selecting the data source for a fact. When you have a
fact table available in multiple sources, it does not matter
which sources have primary versus secondary designation for
the table.

Selecting the Optimal Data Source for Lookup

Tables
After selecting the optimal data source for a fact, the Engine
also has to select the best source for any corresponding
attributes. The Engine uses the following logic to select the
optimal data source for an attribute:
If the attribute comes from a lookup table that exists in

the same data source as the one selected for the fact, the
Engine obtains the attribute data from this same database
instance.
If the attribute comes from a lookup table that does not

exist in the same data source as the one selected for the
fact, the Engine obtains the attribute data from the
primary database instance for the lookup table and
moves it to the database instance used as the fact source.
In essence, when you have a lookup table available in

multiple sources, it can matter which sources have primary
versus secondary designation for the table.
This same logic also applies if the Engine has to

retrieve attribute information from a relationship
table.
However, if you are just browsing attribute elements, the

Engine treats lookup tables for attributes like fact tables. If
the lookup table exists in the primary database instance for a
project, the Engine queries that database instance.
Otherwise, it uses the secondary database instance with the
smallest GUID (alphabetically).

Joining Data from Different Data Sources
When the Engine needs to join data from different data

sources, it selects data from the first data source to the
memory of the Intelligence Server. Then, it creates a
temporary table in the second data source and inserts the
data into this table to continue processing the result set.
You may have a data source that either does not

support the creation of temporary tables or in which
you do not want to create temporary tables. If so, you
can configure the CREATE and INSERT support
VLDB property for the corresponding database
instance to not support CREATE and INSERT
statements. This action makes the database instance
read only and forces the Engine to always move data
out of this source.
For more information on VLDB properties, refer to the

MicroStrategy Engine Essentials course.
To work with tables from different data sources, the Engine

joins table columns based on specific data type compatibility
rules. The following table lists these rules:
Data Type Compatibility Rules
Data Type Compatible Data Type
BigDecimal BigDecimal
Binary Binary
CellFormatData CellFormatData
Char Char, VarChar

Date Date, TimeStamp
Decimal Decimal, Integer with scale of 0,

Numeric
Double Double, Float, Real
Float Double, Float, Real
Integer Decimal with scale of 0, Integer,

Numeric with scale of 0
LongVarBin LongVarBin

Data Type Compatibility Rules
Data Type Compatible Data Type
LongVarChar LongVarChar
NChar NChar
Numeric Decimal, Numeric, Integer with
scale of 0
NVarChar NVarChar
Real Double, Float, Real
Time Time, TimeStamp
TimeStamp Date, Time, TimeStamp
Unsigned Unsigned
VarBin VarBin
VarChar Char, VarChar
IfEngine
two columns do not have compatible data types, the
cannot join data using those columns.
The data type of a column is based on the Engine data type

definition, not the data type definition in the physical
database.
These
same.
two data type definitions may not always be the
Often, different data sources are optimal for different passes

in the SQL for a report. For such queries, the Engine follows
the data type compatibility rules and moves data between the
different data sources until it finishes processing the result
set.

Supported Use Cases

MultiSource Option supports a variety of scenarios in which
you need to join data from multiple data sources. The
following examples show some common cases that are
supported.
These examples are not intended to be a

comprehensive list of all supported scenarios.
Split Fact Tables
It is common to store different facts in separate data sources.

Therefore, you may have a report that contains metrics that
use facts from different data sources.
The following image shows an example of split fact tables:

Split Fact Tables
You can obtain the region data from either data warehouse.
However, revenue data is available only in the Sales Data
Warehouse, and forecast revenue data is available only in the
Forecast Data Warehouse.

Split Lookup Tables
You can store lookup and relationship tables in a single data

source, but it is also common for lookup and relationship
tables to be split across data sources. Therefore, you may
have a report that requires you to join data in one data source
using relationships stored in another data source.
The following image shows an example of split lookup tables:

Split Lookup Tables
The lookup tables that relate the Category, Subcategory, and

Item attributes are stored in the Sales Data Warehouse.
Forecast revenue is stored at the item level in the Forecast
Data Warehouse. You need to aggregate this data to the
category level to calculate the forecast revenue for the report.
However, the Forecast Data Warehouse stores only the
relationship between Item and Subcategory. Therefore, this
aggregation requires you to join the item-level forecast
revenue data to the category data using the lookup tables in
the Sales Data Warehouse.

Filtering Qualifications
You may also have reports where you need to filter data from
one data source by qualifying on data that comes from
another data source.
The following image shows an example that involves a metric

qualification:
Metric Qualification
The report contains a filter based on the Forecast Revenue

metric. This fact data is stored in the Forecast Data
Warehouse. However, you use this filter to qualify on the
revenue for each category, which is stored in the Sales Data
Warehouse.

You can have this same scenario with other types of filter
qualifications. The following image shows an example that
involves an attribute qualification:
Attribute Qualification
The report contains a filter based on the Category attribute.

This attribute is stored in the Sales Data Warehouse.
However, you use this filter to determine which elements are
included in the result set for the Product attribute, which is
stored in the Forecast Data Warehouse.
These cases are just a few examples of how you can use
MultiSource Option to combine data from multiple sources in
a single report. You can use MultiSource Option to help meet
a variety of reporting needs, including the following:
Supporting conformed dimensions across different data

sources
Accessing aggregate-level and detail-level data in different

data sources
Integrating operational data with your data warehouse
Using separate data sources for simple versus more

complex queries
Accessing multiple MicroStrategy BI implementations

Now that you have learned how MultiSource Option works,

you are ready to learn how to configure a project for
heterogeneous data access.
Although you can use MultiSource Option with

standard reports, you cannot use it in conjunction with
Freeform SQL or Query Builder reports. The Engine
has to use multipass SQL to access multiple data
sources and move data between them. Since Freeform
SQL and Query Builder reports allow only a single pass
of SQL, they cannot take advantage of this feature.

Associating Tables to Database Instances

Associate tables with single or multiple data sources, change
the primary database instance for a table, and remove a
database instance from a table.
The first step in configuring a project to access heterogeneous

data sources is to add the necessary tables to the project and
associate them with the appropriate database instances.
For example, in the following scenario, you have two

databases that you want to use as data sources for the
Data Sources for the MicroStrategy Tutorial Project
Tutorial Data is the primary data warehouse for the project. It

contains a variety of lookup, relationship, and fact tables. It
stores the actual revenue data.
96 Associating Tables to Database Instances 2011 MicroStrategy, Inc.

Forecast Data is a data warehouse that contains some

duplicated information from Tutorial Data, including the
LU_COUNTRY and LU_REGION tables. It also contains the
FORECAST_SALES base fact table and the
REGION_FORECAST_SALES aggregate fact table, which are
not in Tutorial Data. These fact tables store forecast revenue
data.
Injoining
this lesson, you will analyze two scenarios for
data from multiple sources. One scenario uses
the aggregate fact table and generates a relatively
simple SQL statement. The second scenario uses the
base fact table, and therefore generates a more
complex SQL statement.
These scenarios focus on geography-related lookup

tables. Forecast Data also contains product-related
lookup tables that you will use later in the exercises for
this lesson.
For any report where you want to include information about

actual and forecast revenue, you need to access tables in both
of these data warehouses and join the data to produce the
result set. To make a report like this possible, you need to add
the tables from Forecast Data to the MicroStrategy Tutorial
project.
You can add tables to a project from other database instances

using either the Warehouse Catalog or the Architect graphical
interface.
Adding Tables with a Single Data Source

Adding tables that map only to a single data source is very
easy. For tables that are associated with the primary database
instance for the project, you simply add them as you normally
would in either the Warehouse Catalog or the Architect
graphical interface. However, you can also easily add tables
associated with secondary database instances.
In the sample scenario, there are many tables that map only
to Tutorial Data, which is the primary database instance for
the project. These tables are already part of the project.
2011 MicroStrategy, Inc. Associating Tables to Database Instances 97

However, there are two tables that map to a data source other
than Tutorial Data:
Table with a Single Data Source
FORECAST_SALES and REGION_FORECAST_SALES exist

only in Forecast Data, so you need to associate them with this
secondary database instance.
To add tables from a secondary database instance to a project

in the Warehouse Catalog:
1 In MicroStrategy Desktop, open the project to which you

want to add the tables.
3 In the Warehouse Catalog, in the Select current database

instance drop-down list, select the database instance that
contains the tables you want to add.
This drop-down list defaults to the primary

database instance for the project.
4 In the Tables available in the database instance list, select

the tables you want to add.
5 Click the > button to add the tables to the project.
The tables display in the Tables being used in the

project list, along with the primary database
instance for each table.

The following image shows the Warehouse Catalog with the

FORECAST_SALES table added to the project:
FORECAST_SALES Table Added to Project

REGION_FORECAST_SALES table added to the project:
REGION_FORECAST_SALES Table Added to Project
As you can see, the primary database instance for both of

these tables is Forecast Data, not Tutorial Data.

To add tables from a secondary database instance to a project

in the Architect graphical interface:

2 Open the Architect graphical interface.
3 In the Architect graphical interface, do one of the

following:
If the secondary database instance is already associated

with the project, continue to step 4.
OR
If the secondary database instance is not associated with

the project, in the Warehouse Tables pane, right-click
anywhere and select Select Database Instance.
In the Select Database Instance window, select the

database instance you want to associate with the project.
Click OK.
4 In the Warehouse Tables pane, expand the database

instance that contains the tables you want to add.
5 Select the tables you want to add.
6 Drag the selected tables to the Project Tables View tab.
The tables display on the Project Tables View tab.

The color mapping for the tables indicates their
association with the selected database instance.
Depending on how you have configured your

Architect settings, you may be automatically
prompted to update the project schema when you
close Architect.

The following image shows the Architect graphical interface

with the FORECAST_SALES and
REGION_FORECAST_SALES tables added to the project:
FORECAST_SALES and REGION_FORECAST_SALES
Tables Added to Project
The yellow color mapping shows that these tables are

associated with Forecast Data, not Tutorial Data.

Adding Tables with Multiple Data Sources

Adding tables that map to multiple data sources requires a
few additional steps. When you associate a table to more than
one database instance, you create a duplicate table.
In the sample scenario, there are two tables that map to both
data sources:
Tables with Multiple Data Sources
LU_COUNTRY and LU_REGION exist in both Tutorial Data

and Forecast Data, so you need to associate them to both
database instances.
These two tables are already part of the project and

associated with the Tutorial Data database instance.
However, you need to add them to the project for the
Forecast Data database instance as well.
To add duplicate tables to a project in the Warehouse Catalog:


instance drop-down list, select the database instance that
contains the tables you want to add.


the tables you want to add.
5 Click the > button to add the tables to the project.
When you add a table that is already mapped to

another database instance, a warning displays
asking if you want to create a duplicate table and
associate it with the selected database instance.
6 In the warning window, under Available options, keep the

Indicate that <Table Name> is also available from the
current DB Instance option selected.
IfName>
you click the Make no changes to <Table
option, the table is not mapped to the
selected database instance, and no duplicate table
is created.
7 Do one of the following:
If you want to view and respond to the warnings for each

duplicate table individually, click OK.
In each successive warning window, click OK until no

more warnings display.
OR
If you want to respond to the warnings for all duplicate

tables at the same time, click OK for All.
The tables display in the Tables being used in the

project list along with the primary database
instance for each table. The icons beside the tables
indicate that they are mapped to multiple data
sources.
You can verify the database instances to which a

table is mapped. In the Tables being used in the
project list, right-click the table you want to check
and select Table Database Instances. The
Available Database Instances window displays the
primary and secondary database instances for the
table.

The following image shows the warning you see when you
add duplicate tables:
Duplicate Tables Warning

LU_COUNTRY table mapped to multiple data sources:
LU_COUNTRY Mapped to Multiple Data Sources


LU_REGION table mapped to multiple data sources:
LU_REGION Mapped to Multiple Data Sources
The primary database instance for both of these tables is

Tutorial Data. However, the icons beside the tables indicate
that they are also mapped to another database instance.
To add duplicate tables to a project in the Architect graphical

interface:

3 In the Architect graphical interface, do one of the

following:
If the secondary database instance is already associated

with the project, continue to step 4.
OR
If the secondary database instance is not associated with

the project, in the Warehouse Tables pane, right-click
anywhere and select Select Database Instance.

In the Select Database Instance window, select the

database instance you want to associate with the project.
Click OK.
4 In the Warehouse Tables pane, expand the database

instance that contains the tables you want to add.
5 Drag the selected tables to the Project Tables View tab.
When you add a table that is already mapped to

another database instance, a warning displays
asking if you want to create a duplicate table and
associate it with the selected database instance.

Indicate that <Table Name> is also available from the
current DB Instance option selected.
IfName>
you click the Make no changes to <Table
option, the table is not mapped to the
selected database instance, and no duplicate table
is created.
7 Do one of the following:
If you want to view and respond to the warnings for each

duplicate table individually, click OK.
In each successive warning window, click OK until no

more warnings display.
OR
If you want to respond to the warnings for all duplicate

tables at the same time, click OK for All.
The tables display on the Project Tables View tab.

The color mapping for the tables indicates their
association with multiple database instances. The
color that corresponds to the primary database
instance is used for the table header, while the
color that corresponds to the secondary database
instance is used to shadow the table.

You can verify the database instances to which a

table is mapped. View the table in the Properties
pane. Under the Definition category, the Primary
DB Instance and Secondary DB Instances
properties display the primary and secondary
database instances for the table.

close Architect.
The following image shows the Architect graphical interface

with the LU_COUNTRY and LU_REGION tables mapped to
multiple data sources:
LU_COUNTRY and LU_REGION Mapped to Multiple Data
Sources
The primary database instance for these tables is Tutorial

Data. However, the color mapping behind the table indicates
that they are also mapped to the Forecast Data database
instance.

Changing the Primary Database Instance for a Table

When you have a table that maps to multiple data sources, by
default, the primary database instance is the first one you use
to add the table to the project. All subsequent database
instances you associate with the table are added as secondary
database instances. However, you may want to change which
database instance is associated as the primary one.
For example, in the sample scenario, there are two tables that
map to both data sources:
Tables with Multiple Data Sources
LU_COUNTRY and LU_REGION exist in both the Tutorial

Data and Forecast Data data warehouses. These tables were
first added to the project using Tutorial Data, so it is the
primary database instance for these tables. However, you can
change the primary database instance for either of these
tables from Tutorial Data to Forecast Data.
You can use either the Warehouse Catalog or the Architect

graphical interface to change the primary database instance
for a table.
To change the primary database instance for a table in the

Warehouse Catalog:
1 In MicroStrategy Desktop, open the appropriate project.

3 In the Warehouse Catalog, in the Tables being used in the

project list, right-click the table for which you want to
change the primary database instance and select Table
Database Instances.
4 In the Available Database Instances window, in the

Primary Database Instance drop-down list, select the
database instance you want to use as the primary
database instance.
The current primary database instance is moved to

the Secondary Database Instances list.
5 If you want to keep the former primary database instance

associated with the table, in the Secondary Database
Instances list, select this database instance.
6 Click OK.
7 In the Warehouse Catalog, click Save and Close.
The following image shows the option for accessing the

database instances for a table:
Option for Accessing the Database Instances for a Table

The following image shows the Available Database Instances

window with the default database instance configuration for
the LU_COUNTRY table:
LU_COUNTRY with Default Database Instance
Configuration
Tutorial Data is the primary database instance for the

LU_COUNTRY table, while Forecast Data is a secondary
database instance for the table.

The following image shows the Available Database Instances

window with the modified database instance configuration
for the LU_COUNTRY table:
LU_COUNTRY with Modified Database Instance
Configuration
Forecast Data is now the primary database instance for the

LU_COUNTRY table, and Tutorial Data is a secondary
database instance for the table.
To change the primary database instance for a table in the

Architect graphical interface:
1 In MicroStrategy Desktop, open the appropriate project.
3 In the Architect graphical interface, in the Properties

pane, click the Tables tab.
4 On the Tables tab, in the drop-down list, select the table

for which you want to change the primary database
instance.
5 Under the Definition category, select the Primary DB

Instance property.

6 Beside the database instance, click the following button:
7 In the Available Database Instances window, in the

Primary Database Instance drop-down list, select the
database instance you want to use as the primary
database instance.
The current primary database instance is moved to

the Secondary Database Instances list.
8 If you want to keep the former primary database instance

associated with the table, in the Secondary Database
Instances list, select this database instance.
9 Click OK.
Inyouthemade
Properties pane, you should see the changes
reflected in the database instances
associated with the Primary DB Instance and
Secondary DB Instances properties.

close Architect.

The following image shows the Primary DB Instance and

Secondary DB Instances properties on the Properties pane:
Primary DB Instance and Secondary DB Instances
Properties
The Secondary DB Instances property displays only if

a project is associated with multiple database
instances.
When you change the primary database instance for a table,

the color mapping in the Architect graphical interface also
changes to reflect the appropriate associations.
Removing a Database Instance from a Table

When a table maps to a single data source, you can remove
the association to a database instance by removing the table
from the project in either the Warehouse Catalog or the
Architect graphical interface.

However, when a table maps to multiple data sources, you

may want to remove one database instance, while still
keeping the table associated with other database instances.
Infromsuchthecases, you do not want to remove the table

project since that removes its association to
all database instances.
Instead, you can use the same functions in the Warehouse

Catalog or the Architect graphical interface to remove a
database instance from a table as you use to change the
primary database instance for a table.
Ifprimary
the database instance you want to remove is the
database instance, you have to change the
primary database instance first. This action removes
the association between the database instance and the
table.

Creating Objects for Multisource Reports

Create objects for use in multisource reports.
After you have associated tables with the appropriate

database instances, the next step in configuring a project to
access heterogeneous data sources is to create the necessary
objects for multisource reports. When you add tables from
other data sources, you may need to create additional
attributes, facts, or metrics that you can use in reports to
access that data.
For example, in the sample scenario, you have four tables in

the Forecast Data data warehouse that are used in the
project:
Forecast Data Tables Used in Project
Since the LU_COUNTRY and LU_REGION tables also exist

in the Tutorial Data data warehouse, the project already
contains the corresponding attributes. If these attributes use
the Automatic mapping method, Architect automatically
maps them to the duplicate tables from Forecast Data.
Ifmapping
you have attributes that do not use the Automatic
method, you have to manually map the
duplicate tables to the corresponding attributes.
2011 MicroStrategy, Inc. Creating Objects for Multisource Reports 115

However, the FORECAST_SALES and

REGION_FORECAST_SALES tables do not exist in the
Tutorial Data data warehouse.
The following image shows the structure of the

REGION_FORECAST_SALES table:
REGION_FORECAST_SALES Table
The following image shows the structure of the

FORECAST_SALES table:
FORECAST_SALES Table
The REGION_FORECAST_SALES and FORECAST_SALES

tables are fact tables that store forecast data at different levels
of aggregation. Attributes already exist in the project that
correspond to each of their attribute ID columns. However,
the fact columns are different from any existing facts in the
project because they reference forecast data rather than
actual sales. You need to create the appropriate facts and
metrics if you want to use these tables.
116 Creating Objects for Multisource Reports 2011 MicroStrategy, Inc.

Creating the Forecast Revenue Fact

The first step is to create the Forecast Revenue fact that
corresponds to the appropriate column in the aggregate fact
table. You will first create a fact expression that maps to the
REGION_FORECAST_SALES aggregate fact table and that
points to a single column:
Forecast_Revenue
The following image shows the Forecast Revenue fact

mapped to the REGION_FORECAST_SALES table:
Mapping of Forecast Revenue Fact
Later in this lesson, you will modify this fact to point to

the FORECAST_SALES base fact table instead of the
aggregate table.
2011 MicroStrategy, Inc. Creating Objects for Multisource Reports 117

Creating the Forecast Revenue Metric

The next step is to create the Forecast Revenue metric that
aggregates the Forecast Revenue fact. The following image
shows the Forecast Revenue metric definition:
Forecast Revenue Metric Definition
The Forecast Revenue metric is formatted as Currency

with 0 decimal places.
118 Creating Objects for Multisource Reports 2011 MicroStrategy, Inc.

Creating a Multisource Report

Create a report that contains objects from multiple data
sources and describe how the Engine processes the SQL for
such reports.
Now that you have created the necessary objects for

multisource reports, the final step in configuring a project to
access heterogeneous data sources is to create a report that
uses objects from multiple data sources.
As you learned earlier, MultiSource Option supports a variety

of scenarios in which you can combine data from different
data sources. The following report for the sample scenarios
contains metrics that use facts from different data sources:
Sample Multisource Report
In this report, you can obtain data for the Region attribute
from either the Tutorial Data or Forecast Data data
warehouses. You can obtain data for the Revenue metric only
from Tutorial Data. You can obtain data for the Forecast
Revenue metric only from Forecast Data.
2011 MicroStrategy, Inc. Creating a Multisource Report 119

Processing of SQL for Sample Report

When you create this sample report and execute it, the
Engine has to perform the following steps to obtain the result
set:
1 Aggregate the revenue for each region using Tutorial

Data.
2 Aggregate the forecast revenue for each region using

Forecast Data.
3 Obtain the region descriptions using either Tutorial Data

or Forecast Data.
4 Consolidate the region, revenue, and forecast revenue

data to produce the final result set.
Based on the logic the Engine uses to select the optimal data
source for each pass, it moves data between the two
databases to process the query.
Simple SQL ScenarioObtaining Forecast

Revenue from the Aggregate Table
In the first scenario, the Forecast Revenue fact maps to the

REGION_FORECAST_SALES aggregate table. The report
template contains the Region attribute and the Revenue and
Forecast Revenue metrics. Since the
REGION_FORECAST_SALES table stores the forecast
revenue already pre-aggregated to the region level, the
Engine generates fairly straightforward SQL to retrieve the
forecast data.
The following images show the primary SQL passes for the
sample report and explain what happens in each pass.
120 Creating a Multisource Report 2011 MicroStrategy, Inc.

This first image shows the SQL passes the Engine uses to
calculate the Revenue metric in the report:
SQL for Calculating the Revenue Metric
Since revenue data is stored only in Tutorial Data, the Engine

performs this calculation in that database. The first SQL pass
creates a temporary table in which to store the revenue for
each region. The second SQL pass aggregates the revenue for
each region using a fact table in Tutorial Data and inserts it
into the temporary table.
This second image shows the SQL passes the Engine uses to
calculate the Forecast Revenue metric in the report:
SQL for Calculating the Forecast Revenue Metric

Since forecast revenue data is stored only in Forecast Data,

the Engine performs this calculation in that database. The
first SQL pass calculates the forecast revenue for each region
using the aggregate fact table in Forecast Data. The second
SQL pass creates a temporary table in Tutorial Data in which
to store the forecast revenue for each region. The third SQL
pass inserts the forecast revenue data for each region into the
temporary table in Tutorial Data.
When data is moved from one data source to another,

the SQL view of a report does not show the entire
INSERT statement. Rather than showing all the values
that are inserted into a temporary table, it shows only
a single set of values. However, it does show the
number of rows inserted into the table above the
INSERT statement.
Now that the Engine has calculated all the metrics for the
report, it uses Tutorial Data to obtain the region descriptions
and consolidate the results of both metric calculations.
Toperforms
minimize the movement of data, the Engine
the final consolidation pass using the
database instance in which the most temporary tables
were created while processing the report. In this
example, both temporary tables were created in the
Tutorial Data database instance, so the Engine selects
the primary database instance.
Ifinstances,
there is a tie between two or more database
the Engine selects the primary database
instance for the project. If none of them are the
primary database instance for the project, the Engine
selects the database instance with the smallest GUID
(alphabetically).

This last image shows the SQL pass the Engine uses to
produce the final result set for the report:
SQL for Consolidating the Result Set
This SQL pass retrieves the region descriptions from a lookup

table in Tutorial Data. Then, it retrieves the region IDs and
revenue and forecast revenue for each region from the
appropriate temporary tables to produce the final result set.
After the consolidation pass, the Engine also generates

SQL to drop each temporary table created while
processing the query unless you configure the VLDB
properties to change this behavior.
The following image shows the result set for the report:
Result Set for Sample Report

Complex SQL ScenarioAggregating Forecast

Revenue from the Base Fact Table
In the first scenario, the forecast revenue data was readily

available in the secondary data source at the requested report
level. Both the Region attribute and the Forecast Revenue
fact were mapped to the same aggregate table. Therefore, the
report SQL was fairly straightforward.
But what happens if the relationship between the attribute on

the report template and the attributes at which the fact table
is stored are not defined in the secondary data source? This is
the case when you map the Forecast Revenue fact to the
FORECAST_SALES base fact table from the Forecast Data
database instance instead of the aggregate table. This base
fact table stores the forecast data at the employee, item, date,
and order levels. However, in the sample report, you want to
aggregate the forecast data to the region level.
To use the FORECAST_SALES fact table, you need to modify

the Forecast Revenue fact to map to that table. You need to
use the following expression that combines three fact
columns from this table:
FORECAST_QTY_SOLD * (FORECAST_UNIT_PRICE
- FORECAST_DISCOUNT)

You then have to remove the fact expression that points to the
REGION_FORECAST_SALES aggregate table from the fact
definition. The following image shows the Forecast Revenue
fact mapped to the FORECAST_SALES table:
Mapping of Forecast Revenue Fact
When you now run the sample report to retrieve the forecast
data, the Engine must aggregate the forecast data from the
employee level to the region level. The process of determining
the relationship between these two attributes takes place in
the report SQL.
After updating the project schema, you may have to

purge the report cache to view the new SQL.
The following images show the primary SQL passes for the
sample report and explain what happens in each pass.

This first image shows the SQL passes the Engine uses to
calculate the Revenue metric in the report:
SQL for Calculating the Revenue Metric
Since revenue data is stored only in Tutorial Data, the Engine

performs this calculation in that database. The first SQL pass
creates a temporary table in which to store the revenue for
each region. The second SQL pass aggregates the revenue for
each region using a fact table in Tutorial Data and inserts it
into the temporary table.
This second image shows the SQL passes the Engine uses to
determine the relationships between call centers and
employees:
SQL for Determining Call Center and Employee
Relationships

Call center and employee relationships are stored only in

Tutorial Data. The FORECAST_SALES fact table stores its
facts at the employee level. However, for this report, the
Engine has to calculate the Forecast Revenue metric at the
region level. Before the Engine can calculate this metric at the
region level, it first has to determine the relationships
between employees, call centers, and regions to accurately
aggregate the forecast revenue data. Since the forecast
revenue data is stored only in Forecast Data, the Engine
selects the necessary call center and employee data from
Tutorial Data and moves it to Forecast Data.
The first SQL pass selects the call centers and employees
from Tutorial Data. The second SQL pass creates a temporary
table in Forecast Data in which to store the call centers and
employees. The third SQL pass inserts the call centers and
employees from Tutorial Data into the temporary table in
Forecast Data.
This third image shows the SQL passes the Engine uses to
determine the relationships between regions and call centers:
SQL for Determining Region and Call Center Relationships
Region and call center relationships are also stored only in

Tutorial Data. Just as the Engine has to determine the
relationships between employees and call centers, it also has
to determine the relationships between call centers and
regions before aggregating the forecast revenue data to the
region level. Since the forecast revenue data is stored only in
Forecast Data, the Engine selects the necessary region and
call center data from Tutorial Data and moves it to Forecast
Data.

The first SQL pass selects the regions and call centers from
Tutorial Data. The second SQL pass creates a temporary table
in Forecast Data in which to store the regions and call
centers. The third SQL pass inserts the regions and call
centers from Tutorial Data into the temporary table in
Forecast Data.
Now, the Engine has all the information it needs to aggregate

the forecast revenue data from the employee level to the
region level.
This fourth image shows the SQL passes the Engine uses to
calculate the Forecast Revenue metric in the report:
SQL for Calculating the Forecast Revenue Metric
Since forecast revenue data is stored only in Forecast Data,

the Engine performs this calculation in that database. The
first SQL pass aggregates the forecast revenue for each region
using the appropriate fact table in Forecast Data. The second
SQL pass creates a temporary table in Tutorial Data in which
to store the forecast revenue for each region. The third SQL
pass inserts the forecast revenue data for each region into the
temporary table in Tutorial Data.
Now that the Engine has calculated all the metrics for the
report, it uses Tutorial Data to obtain the region descriptions
and consolidate the results of both metric calculations.

This last image shows the SQL pass the Engine uses to
produce the final result set for the report:
SQL for Consolidating the Result Set
This SQL pass retrieves the region descriptions from a lookup

table in Tutorial Data. Then, it retrieves the region IDs and
revenue and forecast revenue for each region from the
appropriate temporary tables to produce the final result set.
After the consolidation pass, the Engine also generates

SQL to drop each temporary table created while
processing the query unless you configure the VLDB
properties to change this behavior.
The following image shows the result set for the report:
Result Set for Sample Report


Exercises: Using MicroStrategy MultiSource
Option
You should complete the following exercises using the
MicroStrategy Tutorial project, which is found in the
MicroStrategy Analytics Modules project source.
The report you will create in these exercises builds on

some of the work you did in the MicroStrategy Tutorial
project during the lesson demonstrations. If you are
missing any objects that you need to complete the
exercises, ask your instructor for assistance.
Add Tables from a Secondary Database Instance
Overview
In this exercise, you will use the Warehouse Catalog to add

the following lookup tables from the Forecast Data database
instance to the MicroStrategy Tutorial project:
Lookup Table Name
LU_PRODUCT
LU_SUBCATEG
As you add these tables, you should configure them as

follows:
Make Forecast Data the primary database instance for

the LU_PRODUCT table
Add LU_SUBCATEG as a duplicate table with Forecast

Data as the secondary database instance
130 Exercises: Using MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.

After you have completed these tasks, save and close the
Warehouse Catalog and update the project schema.
Open the Warehouse Catalog for the MicroStrategy

Tutorial project
1 In the MicroStrategy Analytics Modules project source,

open the MicroStrategy Tutorial project.
Add the LU_PRODUCT table to the project

instance drop-down list, select the Forecast Data
database instance.

the LU_PRODUCT table.
5 Click the > button to add the table to the project.
The table displays in the Tables being used in the

project list. Forecast Data should display as the
primary database instance for the table.
2011 MicroStrategy, Inc. Exercises: Using MicroStrategy MultiSource Option 131

Add the LU_SUBCATEG table to the project

the LU_SUBCATEG table.
7 Click the > button to add the table to the project.

Indicate that LU_SUBCATEG is also available from
the current DB Instance option selected.
9 Click OK.
The table displays in the Tables being used in the

project list. The icon beside the table indicates it is
mapped to multiple data sources. Tutorial Data
should display as the primary database instance for
the table.
Save your project work

Create an Attribute for a Multisource Report
Overview
In this exercise, you will create the Product attribute. You

need this attribute for the multisource report you will create
later in these exercises.
You should create the Product attribute in the Schema

Objects\Attributes\Products folder. As part of creating the
Product attribute, you need to complete the following tasks:
Map the ID and DESC forms for the Product attribute as

shown in the following table:
Attribute Form Expressions Source Tables
Product ID: PRODUCT_ID LU_CATEGORY

LU_PRODUCT
DESC: PRODUCT_DESC LU_PRODUCT
The primary lookup table for the Product attribute

displays in bold text. You should use Automatic
mapping for both attribute form expressions.
Relate the Product attribute to the Category attribute as

shown in the following table:
Parent Attribute Child Attribute Relationship Table
Product Category (1:M) LU_CATEGORY
Add the Product attribute to the Products hierarchy,

which is in the Schema Objects\Hierarchies\Data
Explorer folder
After you have completed these tasks, update the project

schema.

Create the Product attribute
1 In the MicroStrategy Tutorial project, in the Schema

Objects\Attributes\Products folder, open the Attribute
Editor.
2 In the Attribute Editor, create the ID form for the Product

attribute and map it to the PRODUCT_ID column in the
LU_PRODUCT table.
3 Use Automatic as the mapping method.
This actions maps the ID form to the

LU_CATEGORY table as well.
4 Create the DESC form for the Product attribute and map
it to the PRODUCT_DESC column in the LU_PRODUCT
table.
5 Use Automatic as the mapping method.
6 Create a one-to-many relationship between the Product

and Category attributes with Product as the parent
attribute.
7 Keep LU_CATEGORY as the relationship table.
8 Save the attribute in the Schema

Objects\Attributes\Products folder as Product.
9 Close the Attribute Editor.
Add the Product attribute to the Products hierarchy
10 In the Schema Objects\Hierarchies\Data Explorer folder,

open the Products hierarchy.
11 In the Hierarchy Editor, add the Product attribute to the

hierarchy.

12 Set the Product attribute as an entry point.
13 Save and close the Products hierarchy.
Create a Multisource Report
Overview
In this exercise, you will create a multisource report. The

report should contain the following attributes and metrics:
Product, Category, Revenue, and Forecast Revenue. The
report should also contain an attribute element filter with the
following condition: Product In list (Entertainment).
Save the report in the Public Objects\Reports folder as

Revenue and Forecast Revenue for Entertainment
Categories.
Run the report. The result set should look like the following:
Switch to the SQL View of the report. Answer the follow-up

questions at the end of the detailed instructions for this
exercise. After you have answered the questions, close the
report.

Create the multisource report template
1 In the MicroStrategy Tutorial project, in the Public

Objects\Reports folder, create the following report:
You can access the Product and Category attributes

from the Products hierarchy.
You can find the Revenue metric in the Public

Objects\Metrics\Sales Metrics folder. You created
the Forecast Revenue metric during the lesson
demonstrations. If you have difficulty finding
where you saved this metric, ask your instructor for
assistance.
Create the multisource report filter
2 Create an attribute element filter with the following

condition:
Product In list (Entertainment)
You can create a local filter on the report. You do

not need to create the filter separately in the Filter
Editor.
The report filter should look like the following:
Save and run the multisource report

Revenue and Forecast Revenue for Entertainment
Categories.

4 Run the report.
5 Compare your results to the expected report in the

Overview section at the beginning of this exercise.
6 Switch to the SQL View for the report.
7 Answer the follow-up questions about this exercise. After

you have answered the questions, close the report.
Follow-up Questions
1 Which database does the Engine use to obtain the Product

description? Why?
_______________________________________
_______________________________________
_______________________________________
_______________________________________
2 Which database does the Engine use to obtain the

Category descriptions? Why?
_______________________________________
_______________________________________
_______________________________________
_______________________________________
3 Which table does the Engine use to apply the report filter
and determine which categories belong to Entertainment?
_______________________________________
_______________________________________
_______________________________________
_______________________________________

4 Which database does the Engine use to calculate the

Revenue metric? Why?
_______________________________________
_______________________________________
_______________________________________
_______________________________________
5 Which database does the Engine use to calculate the

Forecast Revenue metric? Why?
_______________________________________
_______________________________________
_______________________________________
_______________________________________
6 Which database does the Engine use for the final

consolidation pass? Why?
_______________________________________
_______________________________________
_______________________________________
_______________________________________
Answers to Follow-up Questions
1 The Engine uses Forecast Data because the

LU_PRODUCT table, which stores the Product
descriptions, exists only in this database.
2 The Engine uses Tutorial Data because the

LU_CATEGORY table, which stores the Category
descriptions, exists only in this database.
3 The Engine uses the LU_CATEGORY table in Tutorial

Data to apply the report filter because it stores the
relationship between the Product and Category attributes.

4 The Engine uses Tutorial Data because revenue data

exists only in this database.
5 The Engine uses Forecast Data because forecast revenue

data exists only in this database.
6 The Engine uses Tutorial Data for the final consolidation

pass because more temporary tables were created in this
database while processing the report. Three temporary
tables were created in Tutorial Data, and only two were
created in Forecast Data.


Lesson Summary
MultiSource Option is an add-on component to

Intelligence Server that enables you to define a single
project schema that uses multiple data sources.
With MultiSource Option, you can create a standard

report that executes SQL against multiple data sources.
With MultiSource Option, you can connect to any data

source that you access using an ODBC driver, including
Microsoft Excel and text files. You cannot connect to MDX
or non-relational data sources.
With MultiSource Option, you can define primary and

secondary database instances at the table level and
connect to them directly within the MicroStrategy
platform.
You create duplicate tables when you map the same

project table to more than one database instance.
MultiSource Option supports duplicate tables. You can

benefit from creating duplicate tables for lookup and
relationship tables.
When the Engine generates SQL for multisource reports,

it determines the optimal database instance for each SQL
pass and identifies when joins need to occur across
database instances.
If you have duplicate tables, the primary table is the one

that is mapped to the primary database instance. The
secondary table is the one that is mapped to the secondary
database instance.
The Engine uses specific logic to select the optimal data

source for fact and lookup tables.

When the Engine needs to join data from different data

sources, it moves data between them as it processes the
result set for a report. It joins table columns using specific
data type compatibility rules.
You can use MultiSource Option to support a variety of

scenarios in which you need to join data from different
sources.
The first step in configuring a project to access

heterogeneous data sources is to add the necessary tables
to a project and associate them with the appropriate
database instances.
You can add tables from primary or secondary database

instances to a project in both the Warehouse Catalog and
the Architect graphical interface.
You can add duplicate tables to a project in both the

Warehouse Catalog and the Architect graphical interface.
You can change the primary database instance for a table

in both the Warehouse Catalog and the Architect
graphical interface.
You can remove a database instance from a table in both

the Warehouse Catalog and the Architect graphical
interface.
The second step in configuring a project to access

heterogeneous data sources is to create the necessary
objects for multisource reports.
The final step in configuring a project to access

heterogeneous data sources is to create a report that uses
objects from multiple data sources.


4
FACT LEVEL EXTENSIONS
Lesson Description
This lesson describes the various ways you can extend fact
levels using MicroStrategy Architect.
In this lesson, you will first learn about the three types of fact
level extensionsdegradation, extension, and disallow. Then,
you will learn how to create each of these types of fact level
extensions.

4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design
Lesson Objectives

Describe the three types of fact level extensions available in
MicroStrategy Architect, create fact degradations to lower the
levels of facts, create fact extensions to extend the levels of
facts to other hierarchies, and disallow fact levels to prevent
unnecessary cross joins.
Describe how the level at which a fact is stored affects

reports and describe the three types of fact level extensions
available in MicroStrategy Architect. (Page 145)
Describe the purpose of fact degradations and create fact

degradations to lower the levels of facts. (Page 148)
Describe the purpose of fact extensions and create fact

extensions to extend the levels of facts to other
hierarchies. (Page 156)
Describe the purpose of fact disallows and disallow fact

levels to prevent unnecessary cross joins from
occurring. (Page 179)

MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4
Overview of Fact Level Extensions

Describe how the level at which a fact is stored affects reports
and describe the three types of fact level extensions available
in MicroStrategy Architect.
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.
For example, the following illustration shows a fact table in

which the Unit Sales fact is stored at the item and week level:
Fact Level
Itattribute
is possible for the same fact to be stored at different
levels within a hierarchy. For example, you
could have another fact table that stores unit sales by
item and date, rather than item and week. This fact
table would store unit sales for items at a lower level
within the Time hierarchy.
Based on this fact table, you can report on unit sales at the
item or week levels. You can also aggregate the unit sales data
to the month, quarter, or year levels within the Time
hierarchy and to the subcategory and category levels within
the Product hierarchy. 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.
2011 MicroStrategy, Inc. Overview of Fact Level Extensions 145

What if you want to report on unit sales by call center or

region? Since the fact is stored only at the item and week
levels and these two attributes have no direct relationship to
attributes in the Geography hierarchy, it is impossible to
perform this type of analysis.
You may also have a scenario in which a metric consists of

more than one fact. For example, the following illustration
shows a Sales metric that consists of the Unit Price and
Quantity Sold facts:
Different Fact Levels in a Metric Definition
The Unit Price fact is stored at the item and week levels, while
the Quantity Sold fact is stored at the item and day levels.
However, for these two facts to be used together in a metric
expression, they must be stored at the same level. Otherwise,
the calculation can cause errors, depending on the level at
which you need to report on the metric.
As you can see, the levels at which facts are stored limit the
levels at which you can report on facts. If you have a metric
that consists of multiple facts, they have to be stored at the
same level to correctly calculate the metric.
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.
Fact level extensions are not commonly applied to

facts, but they are very useful in special cases.
146 Overview of Fact Level Extensions 2011 MicroStrategy, Inc.

MicroStrategy Architect provides the following three types of

fact level extensions:
DegradationEnables you to extend the level of a fact to

a lower level within the same hierarchy.
ExtensionEnables you to extend the level of a fact to

include a level from a different hierarchy not currently
related to the fact
DisallowEnables you to disallow a specific fact level to

prevent unnecessary cross joins to lookup tables when
reporting on a fact
The remainder of this lesson describes each of these fact level

extensions in detail.
2011 MicroStrategy, Inc. Overview of Fact Level Extensions 147

Degrading Fact Levels

Describe the purpose of fact degradations and create fact
degradations to lower the levels of facts.
A fact degradation enables you to lower the level of a fact

within a hierarchy to which it is already related.
The following illustration shows a fact table with facts stored

at the month level and a report that requires one of these
facts to be displayed at the day level:
Fact Degradation Scenario
In this example, the report contains the Units Received

metric that uses the Units Received fact in its definition.
148 Degrading Fact Levels 2011 MicroStrategy, Inc.

The Units Received fact is stored at the item and month

levels. However, you need the Units Received fact to be
available at the day level. If you try to run this report, you
receive the following error message:
Report Error Without the Fact Degradation
The error message notifies users that the Units Received fact
is not available at the day and item levels. For this report to
work, you need to lower the level of the Units Received fact
from month to day using a fact degradation.
Ascouldan change
alternative to creating a fact degradation, you
the level of the fact table in the data
warehouse itself. However, changing the fact table is
not always an option. The fact data may not be
captured at that level in the source system, or there
may be other organizational or environmental
restrictions on changing the table structure.
2011 MicroStrategy, Inc. Degrading Fact Levels 149

Steps for Fact Degradation

Creating a fact degradation consists of the following steps:
1 Select the attribute level to which you want to lower the

fact.
2 Select the attribute the SQL Engine can use to join the fact
to the attribute to which you want to lower the fact.
3 Determine the join direction between the join attribute

and the fact.
4 If necessary, define an allocation expression.
The following topics describe each of these steps in more

detail.
Selecting the Attribute for the Fact Degradation
When you create a fact degradation, the fact is already stored

in a fact table at a higher level within the hierarchy than the
level at which you want to analyze the fact. Therefore, you
choose the lower-level attribute within the same hierarchy to
which you want to degrade the fact.
For the Units Received fact degradation, you need to lower

the level of the Units Received fact from month to day, so you
would select the Day attribute.
Selecting the Join Attribute
When you create a fact degradation, you have to do so

precisely because the fact is not related to the desired
attribute level within a hierarchy. Therefore, you need to
select an attribute that the SQL Engine can use to join the fact
to the desired attribute level. With a fact degradation, since
you are lowering a fact for a hierarchy to which it is already
related, the join attribute is always a higher-level attribute
from that hierarchy.

For the Units Received fact degradation, the Units Received

fact is stored at the item and month level, so it is related to
both the Item and Month attributes. Since you need to lower
the fact to the day level, you select Month as the join attribute
because it is directly related to the Day attribute. The Item
attribute is not directly related to the Day attribute, so you
would not use it as the join attribute.
Determining the Join Direction
After you select the join attribute you want to use to relate the
desired attribute and fact, you have to determine how you
want the SQL Engine to perform the join between the join
attribute and the fact. There are two possible join directions.
You can join to the fact using only the join attribute itself, or
you can allow the fact to also join to children of the join
attribute.
For the Units Received fact degradation, the Units Received

fact is stored only at the item and month level. It is not stored
at any other levels of time. Therefore, you would choose to
join only against the attribute itself (Month). However, if the
Units Received fact were stored at another level of time
between month and day, such as week, you may want to join
to the fact at the month or week level. In this case, you could
choose to allow the SQL Engine to join against the attribute
and its children (Month and Week). If you do not want to
allow the join at both levels, you could still choose to perform
the join only against the attribute itself.
Ifattribute
you allow the SQL Engine to join against the join
and any of its children, you need to ensure
that the allocation expression you use for the fact
degradation returns values that are valid at any of
those attribute levels.

Defining an Allocation Expression
Some facts are static and do not change value from one level
to another. Such facts do not require an expression to allocate
the fact at the lower level. Other facts do change from one
level to another, and you need to define an expression that
correctly allocates the fact data at the lower level. An
allocation expression can include attributes, facts, constants,
and any standard expression syntax, including mathematical
operators, pass-through functions, and so forth.
Although the Units Received fact is stored at the month level,

its value may be different depending on the level of time at
which you are reporting on the units received. The units
received on a particular day are different from units received
during a month. Therefore, you need an allocation expression
to translate units received at the month level into day-level
values. For the Units Received degradation, you could create
an allocation expression to divide the monthly units received
by the duration of the month to get a rough approximation of
units received at the day level:
([Units Received] / [Month Duration])
However, if you were creating a degradation for a fact like

Unit Price, its value might be the same regardless whether
you report on it at the month level or the day level since the
unit price does not change during a month. Therefore, you
would not need an allocation expression for this fact
degradation.
Creating a Fact Degradation

Now that you understand the steps involved in fact
degradation, you are ready to learn how to use the Level
Extension Wizard in the Fact Editor to create a fact
degradation.

To create a fact degradation:
1 Open the fact in the Fact Editor.
2 In the Fact Editor, click the Extensions tab.
3 On the Extensions tab, click New.
4 In the Level Extension Wizard, in the Introduction

window, click Next.
5 In the General Information window, in the Name box,

type a name for the extension.
6 In the Description box, type a description for the

extension.
7 Click Lower the fact entry level.
8 Click Next.
9 In the Extended Attributes window, in the Available

attributes list, select the attribute to which you want to
lower the fact and click the > button to add it to the
Selected attributes list.
10 Click Next.
11 In the Join Type window, in the Join attributes list, select

the check box for the attribute you want to use in the join.
12 Click Next.
13 In the Join Attributes Direction window, in the Join

attributes list, in the Join against column, click the arrow
icon to set the join direction for the join attribute.
14 Click Next.
15 In the Allocation window, do one of the following:
If you want to specify an allocation expression, select the

Specify an allocation expression check box.
In the box, type the expression.

Click Validate to validate the expression.
OR
If you do not want to specify an allocation expression,

continue to step 16.
16 Click Next.
17 In the Finish window, review the information and click

Finish.
You can click Back to go back through the Level

Extension Wizard and make changes.
18 In the Fact Editor, click Save and Close.
The following image shows a fact degradation in the

MicroStrategy Tutorial project that lowers the level of the
Units Received fact from Month to Day:
Fact Degradation from Month to Day Level

When you run a report with the Item and Day attributes and
the Units Received metric on the template, the report returns
the following result set:
Report Result Set with the Fact Degradation
The image above displays only the first few rows of the
result set for the report.
The report returns the same value for each day within the
same month for the Units Received metric.

Extending Fact Levels

Describe the purpose of fact extensions and create fact
extensions to extend the levels of facts to other hierarchies.
While a fact degradation enables you to lower the level of a

fact within a hierarchy to which it is already related, a fact
extension enables you to extend the level of a fact to a level in
a different hierarchy to which it is currently unrelated.
Consider the following simplified data model for the

Fact Extension Data Model
In this data model, you store the Freight fact at the employee,
order, and day level. However, freight data is not stored at the
item level. The Freight fact is not related to any attribute in
the Product hierarchy.
156 Extending Fact Levels 2011 MicroStrategy, Inc.

If you run a report that contains the Item attribute and a

Freight metric that uses the Freight fact, the result set looks
like the following:
Item and FreightReport Result Set
The image above displays only the first few rows of the
The report returns the same freight value for each item. This
result set is meaningless because of how the query joins the
lookup table for the Item attribute and the fact table for
Freight. The following image shows the SQL for this report:
Item and FreightReport SQL
2011 MicroStrategy, Inc. Extending Fact Levels 157

Because there is no relationship between Item and Freight,

the SQL Engine performs a cross join between the fact and
lookup tables to retrieve the data for the report.
Therefore, if you want to view freight information by item,

you have to extend the Freight fact to the item level. You
cannot use a fact degradation because Item is an attribute
from a different hierarchy than the attributes that are already
related to the Freight fact.
Ascouldan add
alternative to creating a fact extension, you
a new level to the fact table in the data
warehouse itself. However, changing the fact table is
not always an option. The fact data may not be
captured at that level in the source system, or there
may be other organizational or environmental
restrictions on changing the table structure.
MicroStrategy Architect provides three methods for creating

fact extensions. They enable different options for joining the
desired attribute and fact. You can create fact extensions
using the following three methods:
Table relationYou select a particular table to use for the

join. You should select this option if you always want the
SQL Engine to use the same table to join the desired
attribute and fact.
Fact relationInstead of selecting a single table, you

select a fact to use for the join. This option enables the
SQL Engine to use any table containing that fact to join
the desired attribute and fact. You should select this
option if you want to allow the SQL Engine to choose the
optimal table for a particular query.
Cross productYou choose to have the SQL Engine

perform a cross join between the lookup table of the
desired attribute and the fact table.
You should use the cross product option only as a

last resort. If there are no tables in your data
warehouse that you can use to join the desired
attribute and fact, then this is the only option you
have for creating a fact extension. However, keep
in mind that a cross join requires a great deal of
processing overhead, and the resulting data may
not be meaningful.

Steps for Fact Extension Using the Table Relation Method

Using the table relation method for a fact extension forces the
SQL Engine to always join the desired attribute and fact using
a particular table. Creating a fact extension using a table
relation consists of the following steps:
1 Select the attribute level to which you want to extend the

fact.
2 Select the table you want the SQL Engine to use to join the
fact to the attribute to which you want to extend the fact.
3 Select the attribute or set of attributes the SQL Engine can

use to join the fact to the attribute to which you want to
extend the fact.
4 Determine the join direction between the join attributes

and the fact.
The following topics describe each of these steps in more

detail.
Selecting the Attribute for the Fact Extension
When you create a fact extension, the fact is completely

unrelated to any attributes in the given hierarchy. The
attribute to which you want to extend the fact depends on
how you want to analyze the fact. If you want to report on the
fact at any level in the hierarchy, you should select the
lowest-level attribute in that hierarchy.
For the Freight fact extension, if you want to report on the

Freight fact at any attribute level in the Product hierarchy,
you select the Item attribute, which is the lowest-level
attribute in the hierarchy. Selecting a higher-level attribute
from the Product hierarchy, such as Subcategory, only
extends the fact to that attribute level or any attribute above it
in the hierarchy. Extending the Freight fact to the item level
enables you to create reports that analyze freight data using
any attribute from the Product hierarchy.

Selecting the Table for the Join
The SQL Engine needs to join the table that contains the fact
you are extending and the lookup table that stores the
attribute to which you are extending the fact. Because these
two tables are not related, you have to select another data
warehouse table to serve as a relationship table between the
fact and lookup tables.
After you select the attribute to which you want to extend the
fact, MicroStrategy Architect searches the project warehouse
catalog and returns a list of all tables that contain the ID
column of that attribute. Using this list of candidate tables,
you can then select the optimal table for the join. In selecting
a table, you should consider several factors, including the
number of possible join paths, the optimal join path for a
given allocation expression, and any other characteristics
specific to your data warehouse environment. For example,
you may want to use a table for the join that you know has
better indexes or is updated more frequently.
In the previous example, the Freight fact is stored in the

ORDER_FACT table. The following image shows the logical
view for the ORDER_FACT table:
ORDER_FACT TableLogical View

Notice that several attributes from multiple hierarchies map

to the ORDER_FACT table. Therefore, all these attributes
relate to the Freight fact and could possibly be used to relate
the Freight fact to the Item attribute.
The ORDER_FACT table is the only table in the data

warehouse that contains the Freight fact. Therefore,
you have to join the ORDER_FACT table to the
LU_ITEM table to relate the Freight fact to the Item
attribute.
When you extend the Freight fact to Item using a table

relation, MicroStrategy Architect returns the following list of
candidate tables:
List of Candidate Tables
The list of candidate tables includes the LU_ITEM and

REL_CAT_ITEM tables. These lookup and relationship
tables contain only product-related information. Therefore,
you can eliminate them as possible tables to use for the join
since no attributes from the Product hierarchy are related to
the Freight fact. In general, you can usually eliminate tables
from the hierarchy to which the attribute belongs since these
tables typically do not provide any way to join to other
hierarchies.

The remaining tables are all fact tables that contain the Item
attribute. However, most of them have only one or two
attributes in common with the ORDER_FACT table.
However, the ORDER_DETAIL table contains many of the
same attributes as the ORDER_FACT table, including
Employee, Day, Customer, and Order. The following image
shows the logical view for the ORDER_DETAIL table:
ORDER_DETAIL TableLogical View
You could use the ORDER_DETAIL table to join the

LU_ITEM and ORDER_FACT tables using any of the
common attribute columns. Because the ORDER_DETAIL
table provides multiple join paths, it is the best table to use to
join the Freight fact to the Item attribute.
The ORDER_DETAIL table is the optimal join table

provided you can use it in conjunction with the
allocation expression for the fact extension. You also
have to consider any characteristics of the table that
might render it less optimal because of factors
unrelated to its structure. For example, if this table is
only updated monthly and you want reports that
provide the most current data, it would not be the best
table to use for the join.

Selecting the Join Attribute or Set of Join

Attributes
After you select the table for the join, you then need to select
an attribute or set of attributes from that table on which the
SQL Engine should join. MicroStrategy Architect lists any
attributes whose ID columns are present in the join table.
You can either manually select the join attributes, or you can
allow the SQL Engine to select the join attributes dynamically
on a query-by-query basis.
For the Freight fact extension, you select Order as the join
attribute. You could use other attributes in the
ORDER_FACT table as the join attribute. These attributes
are listed in the Level Extension Wizard, as shown below:
Possible Join Attributes
However, the allocation expression for this fact extension

uses facts that are related to individual orders, so Order is the
optimal join attribute.

If you allow the SQL Engine to dynamically select the join

attributes, you do not perform this step. However, if you
manually select the join attributes, you have to determine
how you want the SQL Engine to perform the join between
the join attributes and the fact. Just as with fact degradations,
there are two possible join directions. You can join to the fact
using only the join attributes themselves, or you can allow the
fact to also join to the children of the join attributes.
If you allow the SQL Engine to join against the join attributes
and any of their children, you need to ensure that the
allocation expression you use for the fact extension returns
values that are valid at any of those attribute levels.
For the Freight fact extension, you allow the SQL Engine to
join only against the Order attribute itself. Since the Order
attribute is already the lowest-level attribute in the
Customers hierarchy, it does not have any child attributes
you could use to join to the fact.
Defining an Allocation Expression
Just as with fact degradations, when you create a fact

extension, you may need to define an expression to allocate
the fact data at the extended attribute level. Some facts are
static and do not change value from one attribute level to
another, while other facts have values that do change,
depending on the attribute level.
As with fact degradations, a valid allocation expression can

include attributes, facts, constants, and any standard
expression syntax, including mathematical operators,
pass-through functions, and so forth.
For the Freight fact extension, you could create the following
allocation expression:
(Freight * [Item-level Units Sold]) /
[Order-level Units Sold]

In the allocation expression, the value of the Freight fact at

the order level is proportionally distributed among items sold
in this particular order according to the units sold. If there
are 3 units of the same item in an order of 10 items total and
the freight for this order was $100, then the item-level freight
for that particular item is $30.
Creating a Fact Extension Using the Table Relation Method

extensions using the table relation method, you are ready to
learn how to use the Level Extension Wizard to create a fact
extension using a table relation.
To create a fact extension using a table relation:

window, click Next.


extension.
7 Click Extend the fact entry level.
8 Click Next.


extend the fact and click the > button to add it to the
10 Click Next.
11 In the Extension Type window, click Specify the

relationship table used to extend the fact.
12 Click Next.
13 In the Table Selection window, in the Available tables list,

select the table that you want to use to extend the fact.
14 Click Next.
15 In the Join Type window, do one of the following:
If you want the SQL Engine to select the optimal set of

attributes for the join based on the SQL query, click
Dynamically select the best set of attributes (Best Fit).
OR
If you want the SQL Engine to always use a particular

attribute or set of attributes for the join, click I will select
the set of attributes.
In the Join attributes list, select the check boxes for the
attributes you want to use in the join.
The list of attributes includes all attributes present

in the join table you selected.
16 Click Next.
IfAttributes
you chose to select the join attributes, the Join
Direction window opens. Continue to
step 17. If you chose to let the SQL Engine
determine the join attributes, the Allocation
window opens. Continue to step 19.

icon to set the join direction for each join attribute.
18 Click Next.


OR

20 Click Next.

Finish.


The following image shows a fact extension in the

MicroStrategy Tutorial project that extends the level of the
Freight fact to Item using the table relation method:
Fact Extension to Item Using a Table Relation
You can then run the following report that displays invoice
information for all items in a particular order:
Invoice ReportFreight at the Item Level

In this example, order 18307 includes 4 items. Since only one

unit of each item was sold, the Freight for each item is
calculated evenly as $2. This type of analysis would not be
possible without a fact extension.
Steps for Fact Extension Using the Fact Relation Method

Using the fact relation method for a fact extension allows the
SQL Engine to join the desired attribute and fact using any
table that contains the fact you select. The SQL Engine can
select the optimal table for a particular query. Creating a fact
extension using a fact relation consists of the following steps:

fact.
2 Select a fact that maps to the tables you want the SQL
Engine to use to join the fact to the attribute to which you
want to extend the fact.
3 Select the attribute or set of attributes the SQL Engine can

use to join the fact to the attribute to which you want to
extend the fact.
4 Determine the join direction between the join attributes

and the fact.
Some of the steps in creating a fact extension using a fact

relation are similar to the steps you perform when using a
table relation. However, some of the steps for this method are
different. The following topics describe the steps that differ in
more detail.

Selecting the Fact for the Join
The SQL Engine needs to join the table that contains the fact
you are extending and the lookup table that stores the
attribute to which you are extending the fact. Because these
two tables are not related, you have to use another data
warehouse table to serve as a relationship table between the
fact and lookup tables. The major difference between the
table and fact relation methods is that instead of directly
selecting a table to use for this join, you select a fact. The SQL
Engine can then select any table that contains that fact to use
for the join.
After you select the attribute to which you want to extend the
fact, MicroStrategy Architect returns a list of all facts that are
stored at that attribute level. Using this list of candidate facts,
you can then select the fact for the join. The fact may be
mapped to one table or to multiple tables. If the fact maps to
only one table, the SQL Engine always uses that table for the
join. In such cases, it makes no difference whether you create
the fact extension using the table relation or fact relation
method. However, if the fact maps to multiple tables, the SQL
Engine can select the optimal table to use for a particular
query based on logical size, report level, and so forth. In these
cases, selecting a fact essentially creates a list of tables the
SQL Engine can use for the join. You then allow the SQL
Engine to choose the optimal table for a given query.
Because the fact relation method allows the SQL

Engine to potentially use different tables for the join,
you need to ensure that the allocation expression for
the fact extension can be evaluated using any tables to
which the fact maps.

For example, when you extend the Freight fact to Item using
a fact relation, MicroStrategy Architect returns the following
list of candidate facts:
List of Candidate Facts
Each of these facts is related to the Item attribute. You select

the fact that maps to the tables you want to allow the SQL
Engine to use to join the Freight fact and Item attribute.
In this example, you can easily eliminate facts that are

mapped to tables that store data only at the item level, such
as Item Inventory or On Order Quantity. However, you can
use the Item-level Units Sold fact, because it maps to the
ORDER_DETAIL table that you ultimately want to use for
the join.
The ORDER_DETAIL table is the optimal join table

provided you can use it in conjunction with the
allocation expression for the fact extension.

Selecting the Join Attribute or Set of Join

Attributes
After you select the fact for the join, you then need to select
an attribute or set of attributes on which the SQL Engine
should join. MicroStrategy Architect lists any attributes
whose ID columns are present in tables that contain the
selected fact. As with the table relation method, you can
either manually select the join attributes, or you can allow the
SQL Engine to select the join attributes dynamically on a
query-by-query basis.
If you allow the SQL Engine to dynamically select the join

attributes, you do not perform this step. However, if you
manually select the join attributes, you have to determine
how you want the SQL Engine to perform the join between
the join attributes and the fact.
Since there can be many attribute levels represented in the

various fact tables available to the SQL Engine, there are four
possible join directions rather than just two. You can join to
the fact in the following ways:
Using only the join attributes themselves
Using the join attributes or any children of the join

attributes
Using the join attributes or any parents of the join

attributes
Using the join attributes or any attributes in same

hierarchy as the join attributes
Creating a Fact Extension Using the Fact Relation Method

Now that you understand the steps involved in creating fact
extensions using the fact relation method, you are ready to
extension using a fact relation.

To create a fact extension using a fact relation:

window, click Next.


extension.
8 Click Next.

10 Click Next.
11 In the Extension Type window, click Select the

relationship table dynamically. Specify an existing
fact to be used to extend the current one.
12 Click Next.
13 In the Fact Selection window, in the Available facts list,

select the fact that you want to use to extend the fact.
14 Click Next.

15 In the Join Type window, do one of the following:
If you want the SQL Engine to select the optimal set of

attributes for the join based on the SQL query, click
Dynamically select the best set of attributes (Best Fit).
OR
If you want the SQL Engine to always use a particular

attribute or set of attributes for the join, click I will select
the set of attributes.
In the Join attributes list, select the check boxes for the
attributes you want to use in the join.
The list of attributes includes all attributes present

in the tables that contain the fact you selected.
16 Click Next.
IfAttributes
you chose to select the join attributes, the Join
Direction window opens. Continue to
step 17. If you chose to let the SQL Engine
determine the join attributes, the Allocation
window opens. Continue to step 19.

icon to set the join direction for each join attribute.
18 Click Next.

OR

20 Click Next.


Finish.

The following image shows a fact extension in the

MicroStrategy Tutorial project that extends the level of the
Freight fact to Item using the fact relation method:
Fact Extension to Item Using a Fact Relation

When you run a report from the previous example, it returns

the same results set that it did when using the table relation
method for the Freight fact extension:
Invoice ReportFreight at the Item Level
Steps for Fact Extension Using the Cross Product Method

Using the cross product method for a fact extension allows
the SQL Engine to perform a cross join between the desired
attribute and fact. It forces the fact to relate to all the
elements of the attribute. You should use this option only if
you do not have any table that you can use to relate the
attribute and fact, and you do not have any way to create such
a table.
When you use the cross product method to relate a fact

to an attribute, you are creating a cross product of the
values in the attribute lookup table and the fact table.
Since this type of query is very inefficient,
MicroStrategy does not recommend using the cross
product method to create fact extensions.
Creating a fact extension using a cross product consists of the

following steps:

fact.
2 Select the cross product option to join the fact to the

attribute to which you want to extend the fact.

The primary steps for this method are selecting the attribute
to which you want to extend the fact and defining the
allocation expression. Both of these steps are the same as for
any other method of creating fact extensions.
Creating a Fact Extension Using the Cross Product Method

extensions using the cross product method, you are ready to
extension using a cross product.
To create a fact extension using a cross product:

window, click Next.


extension.
8 Click Next.

10 Click Next.

11 In the Extension Type window, click Perform the

extension through a cross product. This action can
be very inefficient (not recommended).
12 Click Next.

OR

14 Click Next.

Finish.


Disallowing Fact Levels

Describe the purpose of fact disallows and disallow fact levels
to prevent unnecessary cross joins from occurring.
A fact disallow functions very differently from other types of

fact level extensions. You use fact degradations and
extensions to relate the fact to additional attributes.
However, a fact disallow actually prevents unnecessary cross
joins between fact and lookup tables that would otherwise
occur by default.
For example, a project may contain the following hierarchies

and fact table:
Sample Data Model
This project contains Geography, Product, and Time

hierarchies. The INVENTORY_ORDERS fact table stores
data only at the level of item and month, so it is only related
to the Product and Time hierarchies.
2011 MicroStrategy, Inc. Disallowing Fact Levels 179

However, what if you want to run a report that displays a

Units Received metric (built from the Units Received fact) as
well as the Item and Call Center attributes? The Item
attribute is related to the Units Received fact since it is part of
the Product hierarchy, but the Call Center attribute is not
related to this fact since it is part of the Geography hierarchy.
By default, the result set for this report looks like the
following:
Report Result SetUnrelated Attribute and Fact
The image above only displays the first few rows of the
Because there is no way to relate call center data to units

received data, this report result displays the units received for
every item paired with every call center.
180 Disallowing Fact Levels 2011 MicroStrategy, Inc.

In an attempt to return data for the report, the SQL Engine

generates SQL that results in a cross join between the lookup
table for the Call Center attribute and the fact table that
contains the units received data. The SQL for this report
looks like the following:
Report SQLUnrelated Attribute and Fact
The report SQL includes the LU_CALL_CTR table in the

FROM clause, but it cannot join this table to the
INVENTORY_ORDERS fact table in the WHERE clause. The
cross join makes it possible for the report to return data, but
it can only produce a cross product, which does not yield a
meaningful result set.
If you have no need for this cross join and the result set it
produces, you can disallow the Call Center attribute for the
Units Received fact. This fact disallow prevents the SQL
Engine from executing the cross join.
To disallow a fact level:


window, click Next.


extension.
7 Click Disallow partially or completely the fact entry

level.
8 Click Next.

attributes list, select the attribute you want to disallow for
the fact and click the > button to add it to the Selected
attributes list.
10 Click Next.

Finish.

182 Disallowing Fact Levels 2011 MicroStrategy, Inc.

After disallowing the Call Center attribute for the Units

Received fact, if you run the same report, the report fails and
the following error message displays:
Report Error with the Fact Disallow
The error message basically notifies users that they cannot

extend the Units Received fact to the Call Center attribute
using a cross join.
You cannot use fact disallows to prevent normal joins

from occurring, only cross joins. For example, for the
fact table referenced in this topic, disallowing an
attribute from the Time or Product hierarchies for the
Units Received fact would not prevent you from
running a report with attributes from either hierarchy.
The Units Received fact is related to attributes from
each of these hierarchies, so a cross join to lookup
tables would not occur.


Exercise: Create a Fact Degradation
Overview
You will use the Forecasting Project for this exercise.
In this exercise, you will first create the following report:
Run the report. Add the Month attribute to the template and
run the report again. After reviewing the error message, save
the report as Degradation Example in the Public
Objects\Reports folder.
Next, you will create degradation for the Forecast Cost fact
to enable you to report on that fact at the Month level. In the
data warehouse, this fact exists only at the Quarter level. You
should use the following allocation expression for the fact
degradation: [Forecast Cost] / 3. After creating the fact
degradation, you should update the project schema.
184 Exercise: Create a Fact Degradation 2011 MicroStrategy, Inc.

Run the report. The result set should look like the following:
The image above only displays the first few rows of the
Create a report
1 In MicroStrategy Desktop, in the Forecasting Project, in

the Public Objects folder, in the Reports folder, create the
following report:
You can access the Quarter attribute from the Time

hierarchy. You can find the Forecast Cost metric in
the Metrics folder.
2011 MicroStrategy, Inc. Exercise: Create a Fact Degradation 185

Run the report
2 Run the report. The result set should look like the
following:
You can report on the Forecast Cost fact at the quarter

level.
Modify the report to include the Month attribute
3 Switch to Design View.
4 Add the Month attribute to the report template to the

right of Quarter.
You can access the Month attribute from the Time

hierarchy.

5 Run the report. You should see the following error

message:
The error message states that the Forecast Cost fact does
not exist at the month level in the data warehouse. If you
want to report on that fact at a level lower than quarter,
you must create a fact degradation.
Save the report

Degradation Example and close the report.
Create a fact degradation at the month level for the

Forecast Cost fact
8 In the Schema Objects, in the Facts folder, open the

Forecast Cost fact in the Fact Editor.

window, click Next.


type Degradation to Month as the name for the
extension.
13 Under What would you like to do?, click Lower the fact
entry level.
14 Click Next.
15 In the Extended Attributes window, select the Show all

attributes check box.
16 In the Available attributes list, select the Month attribute

and click the > button to add it to the Selected attributes
list.
You can add multiple attributes for a single fact

degradation. However, you must ensure that the
allocation expression returns correct results for all
attribute levels. For example, if you add a Day
attribute to the degradation definition, you have to
create a single allocation expression that returns
the correct results at both the month and day
levels.
17 Click Next.
18 In the Join Type window, select the Quarter check box.
19 Click Next.

attributes list, in the Join against column, keep the default
setting.
21 Click Next.
22 In the Allocation window, select the Specify an

allocation expression check box.
23 In the box, type the following expression: [Forecast

Cost] / 3.
This allocation expression returns correct values

only at the month level.
24 Click Validate to validate your expression.

25 Click Next.

Finish.

Run the report
29 Run the Degradation Example report. The result set

should look like the following:
The image above only displays the first few rows of

the result set for the report.
You can now report on the Forecast Cost fact at the month
level. The monthly values are only estimates based on the
allocation expression you provided in the definition of the
fact degradation. Notice that for each month within a
quarter, the forecast cost value is the same.
30 Close the report.


Lesson Summary
Fact level extensions enable facts stored in the data

warehouse at one level to be reported on at a different
level.
There are three types of fact level extensions: degradation,

extension, and disallow.
A fact degradation enables you to lower the level of a fact

within a hierarchy to which it is already related.
A fact extension enables you to extend the level of a fact to

a level in a different hierarchy to which it is currently
unrelated.
You can create a fact extension using the following three

methods: table relation, fact relation, and cross product.
Using the table relation method to create a fact extension

forces the SQL Engine to always join the desired attribute
and fact using a particular table.
Using the fact relation method to create a fact extension

allows the SQL Engine to join the desired attribute and
fact using any table that contains the fact you select.
Using the cross product method to create a fact extension
allows the SQL Engine to perform a cross join between the
desired attribute and fact.
Disallowing a fact level enables you to prevent

unnecessary cross joins between fact and lookup tables
that would otherwise occur by default.

5
TRANSFORMATIONS
Lesson Description
This lesson covers transformations, schema objects that

enable you to compare metric values across time periods.
You will learn about two different types of transformations,

and the different components of a transformation. You will
also learn how to create a transformation in MicroStrategy
Architect and how to use transformations in transformation
metrics. Finally, you will examine common uses for
transformations in reporting.

5 Transformations MicroStrategy Architect: Advanced Project Design
Lesson Objectives

Create different types of transformations, use
transformations in transformation metrics, and describe
common uses for transformations in reporting.
Describe the purpose of transformations, the two different

types of transformations, and the components of a
transformation. (Page 193)
Create a transformation in MicroStrategy Architect and

use a transformation in a transformation
metric. (Page 200)

MicroStrategy Architect: Advanced Project Design Transformations 5
What Is a Transformation?

Describe the purpose of transformations, the two different
types of transformations, and the components of a
transformation.
Transformations are schema objects most often used to

compare values at different timesfor 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 metricssimple metrics that
assume the properties of the transformation applied to them.
2011 MicroStrategy, Inc. What Is a Transformation? 193

For example, a report developer could create a metric to

calculate revenue. If the report developer adds a Last Years
transformation to this metriceffectively creating a Last
Years Revenue metric, this metric calculates last years
revenue as shown in the following image:
Current Versus Last Years Revenue
Any transformation can be included as part of the definition

of a metric, and multiple transformations can be applied to
the same metric.
194 What Is a Transformation? 2011 MicroStrategy, Inc.

Types of Transformations
There are two types of transformations:
Table-based transformationsYou implement these

transformations using a transformation table in the
warehouse.
Expression-based transformationsYou implement these

transformations using a mathematical formula.
Table-Based Transformations
Table-based transformations use transformation tables in the

warehouse to define the transformation from one time period
to another. These tables are often created during the ETL
process. Some transformation data can be easily incorporated
into the lookup tables for attributessuch as Dayby adding
the transformation columns. For example, the LU_DAY table
in the data warehouse for the MicroStrategy Tutorial project
has the following structure:
LU_DAY Lookup Table
This table also has columns for the parent IDs at all
levels. These columns are not displayed in the image
above.

Each date in the LU_DAY table has a transformed value for

the previous day, last months date, last quarters date, and
last years date. For example, for January 5, 2009, the
previous day was January 4, 2009, while the last quarters
date was October 5, 2008.
Other types of transformations may require separate

transformation tables. For example, the following image
shows the table that stores the values for the month to date
transformation, the MTD_DAY table:
Month to Date Transformation Table
In the MTD_DAY transformation table, each date has one or

more records for all dates within its month before and
including that date. For example, there is only one record for
the January 1, 2009 date, but there are three records for the
January 3, 2009 date.
This type of transformation data cannot be stored in

the lookup table for the Day attribute because lookup
tables store each unique date only once.

After you associate a transformation object with a metric, the

Engine uses the transformation to generate SQL for that
metric. The following illustration shows how transformation
tables act as intermediaries in the metric join path when you
use transformation metrics on a report:
Transformation Tables in Metric Join Path
Depending on the database you are using for your data

warehouse, a table-based transformation may be required
when performing a many-to-many transformation such as a
year-to-date calculation. Table-based transformations are
also required any time the business rules for a transformation
cannot be accounted for using in an expression.
Expression-Based Transformations
You define expression-based transformations using a

mathematical expression. 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,
respectively. You can also create expression-based
transformations using pass-through functions such as
ApplySimple. These types of expressions enable you to take
advantage of database-specific functions that you can use to
calculate certain types of transformations.

Expression-based transformations work only if you store

your data in a format conducive to calculation. For example,
if you store your month IDs in the format YYYYMM, the
MONTH_ID1 expression does not always work. If you apply
that expression to the month ID 201001 (January 2010) with
the desire to obtain information about 200912 (December
2009), you do not get any data because there is no 201000
month ID.
Transformation Components
All transformations have the following components:
Member attributes
Member expressions
Member tables
Mapping type
The following sections describe these components in more

detail.
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. On the other hand, if the transformation
is month to date, the member attribute would be Day.

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.
Atable-based
single transformation can use a combination of
and expression-based transformations.
For example, you could create a Last Year
transformation based on the Year, Month, and Day
attributes. Year could use an expression such as
YEAR_ID1.However, Month and Day could map to
columns in a transformation table because their IDs
are not conducive to expression-based transformation.
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-oneA typical one-to-one relationship is last year

versus this year. A year maps to exactly one other year.
Many-to-manyA 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.

Creating and Using Transformations

Create a transformation in MicroStrategy Architect and use a
transformation in a transformation metric.
Creating Transformations
You create expression-based and table-based
transformations using the Transformation Editor.
To create an expression-based transformation:

select the Transformations folder.
2 On the File menu, point to New and select

Transformation.
3 In the Select a Member Attribute window, select the

attribute for which you want to create a transformation.
4 Click Open.
5 In the Define a new member attribute expression window,

in the Table drop-down list, select the source table for the
attribute.
6 In the Available columns list, drag the column you want to

use for the transformation expression into the Member
attribute expression pane.
7 If you are creating a table-based transformation, proceed

to step 9. If you are creating an expression-based
transformation, in the Member attribute expression pane,
complete the expression as appropriate.
8 Click Validate to make sure the expression is valid.
200 Creating and Using Transformations 2011 MicroStrategy, Inc.

9 Click OK.
10 In the Transformation Editor, under Transformation

mapping type, select the appropriate mapping type.
12 Name and save the transformation.
The following image shows the Transformation Editor for the

Last Years transformation in the MicroStrategy Tutorial
project:
Last Years TransformationTransformation Editor
The Last Years transformation has four member attributes

mapped to the transformation columns in their respective
lookup tables. It has a one-to-many mapping type.
2011 MicroStrategy, Inc. Creating and Using Transformations 201

The following image shows the Transformation Editor for the

Month to Date transformation in the MicroStrategy Tutorial
project:
Month to Date TransformationTransformation Editor
The Month to Date transformation has a single Day member

attribute mapped to the MTD_DAY_DATE column in the
MTD_DAY table. It has a many-to-many mapping type.

Using Transformations in Metrics

After you create an expression-based or time-based
transformation, you can use the transformation object to
create transformation metrics.
To create a transformation metric:
1 In the Metric Editor, in the Definition pane, specify the

formula for the metric.
2 In the Metric is defined as pane, select Transformation.
3 Drag the transformation object you want to use from the

Object Browser to the Transformations pane.
You can add multiple transformations.

You can also create transformation metric as a derived

metric with MicroStrategy OLAP Services. For detailed
information on creating advanced metrics, see the
MicroStrategy Desktop: Advanced Reporting course.

The following image shows the Last Years Revenue metric

that uses the Last Years transformation:
Last Years Revenue Metric
The following image shows the MTD Revenue metric that

uses the Month to Date transformation:
MTD Revenue Metric

The following image shows the LY-MTD Revenue metric that

uses both the Last Years and the Month to Date
transformations:
LY-MTD Revenue Metric

Transformation Examples
Transformations are typically used to display time-based
trends.
A common use of transformation is to display a current

year/month/day data versus the last year/month/day data on
the same report. For example, consider a report that displays
this years revenue versus last years revenue, as shown
below:
Last Years Revenue for 2008

Recall that the Last Years transformation applied to the Last

Years Revenue metric is defined as follows:
Last Years Transformation
Notice that the Last Years transformation has multiple

member attributes, all from the Time hierarchy, and all
pointing to transformation tables for the last (or previous)
year. Creating a transformation that is very generic in nature
and encompasses multiple attributes from a single dimension
enables report developers to create a single transformation
metric to satisfy multitude of reporting needs. The
transformation applied to the metric is dynamically evaluated
at report run time to appropriate attribute level based on the
report definition.
For a time-based transformation to work correctly,

you must have some time-related element on the
template or in the filter of a report.

For example, if you modify the report from the previous

example to display only the December 2008 data, the Last
Years Revenue metric values reflect only the previous years
December data, and not the aggregated data for entire 2007
year. This is shown in the image below:
Last Years Revenue for December 2008
Recall that the Last Years Revenue value for The

Rugrats Movie was $12,115.

Another example of using transformations is displaying

month to date or year to date data. For example, consider the
Best Selling Items By Category report:
The Best Selling Items By Category Report
In this report, every metric is a transformation metric. Some

metrics are compound metrics that contain several
transformation metrics in their definition.
The MTD Revenue metric uses the Month to Date

transformation and therefore returns the revenue generated
in the current monthSeptember 2008.
The YTD Revenue metric uses the Year to Date

transformation. It returns the total revenue generated
between 1/1/2008 and 9/30/2008.
The LY-YTD Revenue metric uses two transformationsYear

to Date and Last Years. It returns the last years year-to-date
revenue generated between 1/1/2007 and 9/30/2007.
The YTD as % of LYTD metric is a compound metric

composed of the YTD Revenue and LY-YTD Revenue metrics.
It returns a comparison of this years year-to-date revenue to
the last years year-to-date revenue generated before and on
the same date (September 30). The year-to-date revenue on
9/30/2008 for all items exceeded the year-to-date revenue in
2007 for the same time period.
The BOH - QTD and EOH - QTD metrics are

beginning-on-hand and end-on-hand inventory counts for
the quarter ending on 9/30/2008. Both of these metrics use
the Quarter to Date transformation.

The MTD Units Sold and YTD Units Sold metrics returns the
number of units sold in the current month and year,
respectively. They use the Month to Date and Year to Date
transformations.
The YTD Average Inventory metric uses the Year to Date

transformation and returns the average inventory for the
1/1/2008 to 9/30/2008 time period.
The YTD Inventory Turnover metric is a compound metric

that returns the ratio between the number of units sold this
year to the average inventory count for the year.
Transformations are useful when you want to analyze data in

respect to time. However, transformation use is not limited to
time-based transformations. For example, you can use
transformations to compare current catalog or promotion
versus previous catalog or promotion, and so forth.


Exercise: Create the Last Years Transformation
Overview
You will use the Forecasting Project for this exercise.
In this exercise, you will first create a Last Years

transformation that has a Year member attribute with a
[YEAR_ID] - 1 expression defined on the LU_YEAR table.
After updating schema, you will then create the Last Years
Forecast Revenue transformation metric.
You will then create the following report:
Run the report. Add the Quarter attribute to the template

and run the report again. After reviewing the result set, save
the report as Transformation Example in the Public
Objects\Reports folder.
2011 MicroStrategy, Inc. Exercise: Create the Last Years Transformation 211
Next, you will modify the Last Years transformation by

adding three more member expressions. The transformation
should be defined as follows:
Finally, after updating schema, you will run the

Transformation Example report and drill from 2011 Q1 to
Day to test the new member expression.
Create the Last Years transformation
1 In the MicroStrategy Analytics Modules project source,

open the Forecasting Project.
2 In the Forecasting Project, expand the Schema Objects

folder.
3 In the Schema Objects folder, select the Transformations

folder.
4 On the File menu, point to New and select

Transformation.
5 In the Select a Member Attribute window, select Year.
212 Exercise: Create the Last Years Transformation 2011 MicroStrategy, Inc.
6 Click Open.

in the Table drop-down list, select the LU_YEAR table.
8 In the Member attribute expression pane, type

[YEAR_ID] - 1.
9 Click OK.
11 Save the transformation in the Schema

Objects\Transformations folder as Last Years.
Create a transformation metric
13 In the Public Objects folder, in the Metrics folder, open

the Metric Editor.
14 Define the metric as Sum(Forecast Revenue).
15 Format metric values as currency with 0 decimal places.
16 In the Metric: New Metric is defined as pane, select

Transformation = (nothing).
17 In the Object Browser, double-click the Last Years

transformation.
Your metric should resemble the following:
18 Save the metric in the Public Objects\Metrics folder as

Last Years Forecast Revenue and close it.
Create a report with a transformation metric
19 In the Public Objects\Reports folder, create the following

report:
You can access the Year attribute from the Time

hierarchy. You can find the Forecast Revenue
metric in the Metrics folder.
Run the report
20 Run the report. The report result set should look like the
following:
Only data for the 2011 and 2012 years is displayed, even
though there is Forecast Revenue data for 2010 in the
data warehouse. Notice that both metrics return different
values for each row, but the Forecast Revenue data for
2011 is identical to the Last Years Forecast Revenue for
2012, as expected.
Modify the report
22 Add the Quarter attribute to the report template to the

right of Year.
23 Place the Total subtotal on the report.
24 Run the report. The report result set should look like the
following:
Since the Last Years transformation is not defined for the

Quarter attribute, the transformation metric is not
evaluated correctly. The metric values are identical for
both metrics in each row. This data cannot be correct,
since you already know from the previous result set that
forecast revenue for each year is different.
Save the report

Transformation Example and close it.
Add the Quarter member attribute to the Last Years

transformation
26 In the Schema Objects folder, in the Transformations

folder, double-click the Last Years transformation.
27 In the Transformation Editor, click Add.
28 In the Select a Member Attribute window, select Quarter.
29 Click Open.

in the Table drop-down list, select the LU_QUARTER
table.
31 Double-click the LY_QUARTER_ID column to move it to

the Member attribute expression pane.
32 Click OK.
Add the Month member attribute to the Last Years

transformation
34 In the Select a Member Attribute window, select Month.
35 Click Open.

in the Table drop-down list, select the LU_MONTH table.
37 Double-click the LY_MONTH_ID column to move it to the

Member attribute expression pane.
38 Click OK.
Add the Day member attribute to the Last Years

transformation
40 In the Select a Member Attribute window, select Day.
41 Click Open.

in the Table drop-down list, select the LU_DAY table.
43 Double-click the LY_DAY_DATE column to move it to the

Member attribute expression pane.
44 Click OK.
Save and close the transformation
45 Save and close the transformation.
Run the report
47 Run the Transformation Example report. The report

result set should look like the following:
This result set is correct with the quarter-level

transformation. The Forecast Revenue total for 2011 is
identical to the Last Years Forecast Revenue total for
2012, as expected.
48 Right-click the 2011 Q1 quarter element, point to Drill,

point to Down, and select Day. The drill down report
result set should resemble the following:
The image above only displays the first few rows of

the result set for the report.
Close the reports
49 Close both reports without saving.

Lesson Summary
Transformations are schema objects most often used to

compare values at different times. They are useful for
discovering and analyzing time-based trends in your data.
You use transformations to define transformation

metrics. Transformation metrics are simple metrics that
assume the properties of the transformation applied to
them.
There are two types of transformations: table-based and

expression-based transformations.
Table-based transformations use transformation tables in

the warehouse to define the transformation from one time
period to another.
Expression-based transformations use mathematical

expressions.
All transformations include one or more member

attributes, member expressions, member tables, and a
mapping type.
The member attributes are attributes to which the

transformation applies, which is the lowest-level attribute
on the report to which you want to apply the
transformation.
Each member attribute has a corresponding expression

that needs to be resolved in the report SQL to obtain valid
data.
The member tables store the data for the member

attributes.
The mapping type determines the way the transformation

is created based on the nature of the data. You can use
either one-to-one or many-to-many mapping type.
You create expression-based and table-based

transformations using the Transformation Editor.

6
PARTITIONING
Lesson Description
This lesson covers the benefits of partitioning fact tables and

how you can support partitioned tables in MicroStrategy
Architect.
First, you will learn about the difference between the

server-level and the application-level partitioning. Then, you
will use warehouse and metadata partition mapping to
support partitioned fact tables in a MicroStrategy project.

6 Partitioning MicroStrategy Architect: Advanced Project Design
Lesson Objectives

Describe the purpose of partitioning, explain the difference
between the server-level and the application-level
partitioning, and use warehouse and metadata partition
mapping to support partitioned fact tables in a MicroStrategy
project.
Describe the purpose of partitioning tables in a data

warehouse and define server-level and application-level
partitioning. (Page 223)
Describe and use warehouse partition mapping to support

partitioned fact tables in a MicroStrategy
project. (Page 226)
Describe and use metadata partition mapping to support

partitioned fact tables in a MicroStrategy
project. (Page 234)

MicroStrategy Architect: Advanced Project Design Partitioning 6
Introduction to Partitioning Concepts

Describe the purpose of partitioning tables in a data
warehouse and define server-level and application-level
partitioning.
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.
Databases differ dramatically in the size of the data files and

physical tables they can manage effectively. Partitioning
support varies by database. Most database vendors today
provide some support for partitioning at the database level.
Regardless, the use of some partitioning strategy is essential
in designing a manageable data warehouse. Like all data
warehouse tuning techniques, you should periodically
re-evaluate your partitioning strategy.
2011 MicroStrategy, Inc. Introduction to Partitioning Concepts 223

There are two basic types of partitioning:
Server level
Application level
The following illustration shows the difference between these

two types of partitioning:
Two Types of Partitioning
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 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 the result set for a query.
224 Introduction to Partitioning Concepts 2011 MicroStrategy, Inc.

MicroStrategy supports application-level partitioning for fact

tables through one of two methods:
Warehouse partition mappingThis 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 mappingThis method is based on

rules logically defined in MicroStrategy Architect and
stored in the metadata.
2011 MicroStrategy, Inc. Introduction to Partitioning Concepts 225

Warehouse Partition Mapping

Describe and use warehouse partition mapping to support
partitioned fact tables in a MicroStrategy project.
Overview
With warehouse partition mapping, you do not include the
original fact table or the partition base tables in the project.
Rather, you create and maintain a partition mapping table,
which MicroStrategy Architect uses to identify the
partitioned base tables as part of a logical whole. You only
bring the partition mapping table to the project.
To understand how you can use warehouse partition

mapping to manage partitioned base tables, consider the
following example. To ease maintenance and improve query
performance, you have divided a multibillion-row fact table
by month into a few one-billion-row fact tables. The following
illustration shows a partition mapping table that describes
how the partitioned tables fit together as a whole:
Warehouse Partition Mapping
226 Warehouse Partition Mapping 2011 MicroStrategy, Inc.

The partition mapping table has several features that must be

included for it to work appropriately in MicroStrategy
Architect:
You can use any name for the partition mapping table.
It has a column for each attribute ID by which you

partitioned the table. These attribute IDs represent the
partitioning attributes.
You can use only ID columns to represent

partitioning attributes.
It must have an additional column whose name must be

PBTName and whose contents refer to the names of the
various partition base tables (PBTs). Partition base tables
are the actual physical partition tables that make up the
complete, logical fact table.
The PBTName column indicates to MicroStrategy

Architect that the table is a partition mapping
table.
There is a row for each of the partition base tables in the

logical whole.
When you follow these conventions, MicroStrategy Architect

automatically recognizes the partition mapping table, and
you can very easily add it to the project using the Warehouse
Catalog.
Implementing Warehouse Partition Mapping

When you use warehouse partition mapping, you add the
partition mapping table to the project in the Warehouse
Catalog. You do not add the partition base tables to the
project. When you add the partition mapping table, it
automatically associates this table with the underlying
partition base tables. After adding the partition mapping
table to the project, you also need to identify the attribute
used to partition the tables by creating a partition mapping.
2011 MicroStrategy, Inc. Warehouse Partition Mapping 227

To use warehouse partition mapping in a project:
1 In MicroStrategy Desktop, open the Warehouse Catalog.
2 In the Warehouse Catalog, in the Tables available in the

database instance list, select the partition mapping table
and click the > button to add it to the Tables being used in
the project list.
When you add the partition mapping table, the

number of base tables associated with the mapping
table displays in parentheses beside the partition
mapping table. You can right-click the table and
select View Partitions if you want to see the
partition base tables that are associated with the
partition mapping table.
When you add a partition mapping table to a

project and save the warehouse catalog, you see a
message window that reminds you to set the
partitioning attribute level in the partition
mapping. Click OK.

in the Partition Mappings folder, double-click the
partition mapping object that has the same name as the
partition mapping table you just added to the project.
5 In the Warehouse Partition Mapping Editor, on the

Logical View tab, click Add.
6 In the Partition Level Attributes Selection window, in the

Available attributes list, select the attribute by which the
tables are partitioned and click the > button to add it to
the Selected attributes list.
7 Click OK.
8 In the Warehouse Partition Mapping Editor, click Save

and Close.

The Warehouse Partition Mapping Editor has four tabs, each

displaying different information about the partition mapping.
The following image shows the Logical View tab of the

Warehouse Partition Mapping Editor:
Logical View of the Partition Mapping
The Logical View tab shows the attribute by which the base
tables are partitioned. In the image above, the base tables are
partitioned by the Quarter attribute.

The following image shows the Physical View tab of the

Physical View of the Partition Mapping
The Physical View tab shows the actual columns in the

partition mapping table. In this example, the partition
mapping table contains two columns, PBTNAME and
QUARTER_ID.

The following image shows the logical view of the associated

partition base tables on the Base Table(s) Logical View tab of
the Warehouse Partition Mapping Editor:
Logical View of the Partition Base Tables
The Base Table(s) Logical View tab shows the attributes

mapped to the base partition tables. In this example, the Item
and Month attributes are mapped to the base partition tables.

The following image shows the physical view of the base

partition tables on the Base Table(s) Physical View tab of the
Physical View of the Partition Base Tables
The Base Table(s) Physical View tab shows the actual

columns in the partition base tables. In this example, the
Month attribute is mapped to the MONTH_ID column, and
the Item attribute is mapped to the ITEM_ID column in the
base partition tables. In addition, you can map the Beginning
on Hand and End on Hand facts to the BOH_QTY and
EOH_QTY columns, respectively.

When you run a report that requires information from one of

the partition base tables, the Query Engine first runs a
prequery to the partition mapping table to determine which
partition to access to obtain the data for the report. The
prequery requests the partition base table names associated
with the attribute IDs from the filtering criteria. Next, the
SQL Engine generates SQL against the appropriate partition
base tables to retrieve the report results.
The partition base tables may contain either the same

column as the partitioning attribute or a column
corresponding to any child of the partitioning
attribute.
MicroStrategy Architect does not support

application-level partitioning for lookup tables. The
size of lookup tables usually makes this kind of
partitioning unnecessary. If you want, you can use
server-level partitioning on lookup tables.

Metadata Partition Mapping

Describe and use metadata partition mapping to support
partitioned fact tables in a MicroStrategy project.
Overview
In metadata partition mapping, the application running
against the database still manages the physically partitioned
fact tables, but the execution is different. Metadata partition
mapping does not require a partition mapping table in the
data warehouse. Instead, you define the data contained in
each partition base table in a partition mapping object in
MicroStrategy Architect. This object is stored in the
metadata. You update the partition mapping as new partition
base tables are created.
When you execute a report that runs against the partitioned

tables, the Query Engine sends the necessary prequeries to
the metadata to determine which partition base tables need
to be included in the report SQL. The SQL Engine then
generates SQL against the appropriate partition base tables
to retrieve the report results.
Implementing Metadata Partition Mapping

When you use metadata partition mapping, you add the
partition base tables to the project in the Warehouse Catalog.
After adding the partition base tables to the project, you
create the partition mapping and define the data slices for
each partition base table.
234 Metadata Partition Mapping 2011 MicroStrategy, Inc.

To use metadata partition mapping in a project:
1 In MicroStrategy Desktop, open the Warehouse Catalog.
2 In the Warehouse Catalog, in the Tables available in the

database instance list, select the partition base tables and
click the > button to add them to the Tables being used in
the project list.

select the Partition Mappings folder.
5 On the File menu, point to New and select Partition.
6 In the Partition Tables Selection window, in the Available

tables list, select the partition base tables and click the >
button to add them to the Selected tables list.
7 Click OK.
8 In the Metadata Partition Mapping Editor, in the Tables

defining the partition mapping list, select a partition base
table.
9 Click Define.
10 In the Data Slice Editor, in the Data Slice Definition pane,

define the data contained in the partition base table.
This step is similar to defining a filter condition.

11 In the Data Slice Editor, click Save and Close.
12 Repeat steps 8 to 11 for each partition base table in the

partition mapping.
13 If you want to define a logical size for the partition

mapping, in the Metadata Partition Mapping Editor, in
the Partition mapping logical size box, type a value.
Remember to lock the logical size if you want to

preserve it when updating the project schema.
2011 MicroStrategy, Inc. Metadata Partition Mapping 235

15 Name and save the partition mapping.
The following image shows the Metadata Partition Mapping

Editor:
Metadata Partition Mapping
This example shows 12 partition base tables partitioned by

quarter. You can see that Q1 2006 is the data slice defined for
the INVENTORY_Q1_2006 table. Similarly, the remaining
tables correspond to their respective quarters.
236 Metadata Partition Mapping 2011 MicroStrategy, Inc.


Lesson Summary
There are two types of partitioning: server level and

application level.
Server-level partitioning involves dividing one physical

table into logical partitions in the database environment.
Application-level partitioning involves dividing one large

table into several separate, smaller physical tables called
partition base tables.
MicroStrategy supports application-level partitioning for

fact tables through warehouse and metadata partition
mapping methods.
When you use warehouse partition mapping, rather than

bringing the original fact table or the partition base tables,
you bring the partition mapping table to the
MicroStrategy project.
The partition mapping table must have a column for each

attribute ID by which you partitioned the fact table. It
must also have an additional column named PBTName
whose contents refer to the names of the various partition
mapping tables.
When you execute a report that requires information from

one of the partition base tables, before the SQL Engine
generates the report SQL, the Query Engine first runs a
prequery to the partition mapping table to determine
which partition to access to obtain the data for the report.
When you use metadata partition mapping, you do not

need a partition mapping table in the data warehouse.
Instead, you define the data contained in each partition
base table in a partition mapping object in MicroStrategy
Architect.

When you use metadata partition mapping, you add the

partition base tables to the project in the Warehouse
Catalog.
When you execute a report that runs against the

partitioned tables, before the SQL Engine generates the
report SQL, the Query Engine first sends the necessary
prequeries to the metadata to determine which partition
base tables need to be included in the report SQL.

INDEX
A creating a fact extension using the cross

product method 177
adding aggregate fact tables to a creating a fact extension using the fact re-
project 41 lation method 172
adding tables with a single data source 97 creating a fact extension using the table re-
adding tables with multiple data lation method 165
sources 102 creating a multisource report 119
aggregate fact tables, using them in a creating objects for multisource
project 41 reports 115
aggregate-aware 41 creating table-based transformations 203
application-level partitioning 224 creating the project in MicroStrategy Ar-
Architect, basic schema objects 22 chitect, overview 20
associating tables to database cross product method for fact extension,
instances 96 steps 176
attributes 22 cross product method, creating a fact
extension 177
B
basic schema objects 22 D
data mart 46
C creating 53
database instances 48
changing logical table size 42
objects 48
changing the primary database instance
optimization 50
for a table 108
options 56
compatibility rules, data types 89
updating fact 61
creating a fact degradation 152
updating warehouse catalog 61

Index MicroStrategy Architect: Advanced Project Design
using in a project 60 method 172

data type compatibility rules 89 extension, creating using the table relation
database instance method 165
data mart 48 extension, fact 147
database instances, associating to
tables 96 F
database instances, removing from
tables 113 fact degradation 147, 148
database instances, table level 81, 82 fact degradation, creating 152
database partitioning 224 fact degradation, steps 150
degradation, creating 152 fact disallow 147, 179
degradation, fact 147 fact extension 147, 156
degradation, steps 150 fact extension using cross product method,
steps 176
degrading fact levels 148
fact extension using fact relation method,
designating primary and secondary
steps 169
tables 86
fact extension using table relation method,
designing the logical data model,
steps 159
overview 20
fact extension, creating using the cross
different data sources, joining data 89
product method 177
disallow, fact 147
fact extension, creating using the fact rela-
disallowing fact levels 179 tion method 172
duplicate tables 83 fact extension, creating using the table re-
lation method 165
E fact extensions, methods 158
fact level 145
Engine, data type compatibility rules 89
fact level extensions 146
exercises
fact level extensions, overview 145
data mart 64
fact level extensions, types 147
expression-based transformations 195
fact levels, degrading 148
extending fact levels 156
fact levels, disallowing 179
extending fact levels, methods 158
fact levels, extending 156
extension using cross product method,
fact relation method for fact extension,
steps 176
steps 169
extension using fact relation method,
fact relation method, creating a fact
steps 169
extension 172
extension using table relation method,
fact tables, selecting the optimal data
steps 159
source 87
extension, creating using the cross product
facts 22
method 177
filtering qualifications, MultiSource
extension, creating using the fact relation

MicroStrategy Architect: Advanced Project Design Index
Option 93 cases 91
multisource reports, creating 119
multisource reports, creating objects 115
H
multisource reports, data type compatibil-
hierarchies 22 ity rules 89
multisource reports, processing of
I SQL 120
multisource reports, SQL generation 85
introduction to MultiSource Option 81
O
J
objects, multisource reports 115
joining data from different data
optimal data source, fact tables 87
sources 89
optimal data source, lookup tables 88
overview, creating the project in Mi-
L croStrategy Architect 20
level, fact 145 overview, designing the logical data
Logical Size Editor 44 model 20
Logical Table Editor 42 overview, managing the project
schema 20
logical table size, changing 42
logical table size, role in SQL
generation 41 P
lookup tables, selecting the optimal data partition base tables 224, 227
source 88
partition mapping 23
partition mapping table 225, 227
M partition mapping, metadata 23, 225, 234
managing the project schema, partition mapping, warehouse 23, 225
overview 20 partitioning 223
metadata partition mapping 225, 234 partitioning attributes 227
methods, fact extensions 158 partitioning, application-level 224
multiple data sources, joining data 89 partitioning, database-level 224
multiple data sources, tables 102 partitioning, server-level 224
MultiSource Option, filtering PBTs 227
qualifications 93 PMT 225, 227
MultiSource Option, introduction 81 primary database instances, changing for
MultiSource Option, split fact tables 91 tables 108
MultiSource Option, split lookup primary database instances, table level 81,
tables 92 82
MultiSource Option, supported use primary tables 86

processing of SQL, multisource steps, fact extension using fact relation

reports 120 method 169
project design process, creating the project steps, fact extension using table relation
in MicroStrategy Architect 20 method 159
project design process, designing the logi- support for duplicate tables 83
cal data model 20 supported use case, filtering
project design process, managing the proj- qualifications 93
ect schema 20 supported use case, split fact tables 91
project, using aggregate fact tables 41 supported use case, split lookup tables 92
project-wide options, Warehouse supported use cases, MultiSource
Catalog 36 Option 91
R T
removing a database instance from a table relation method for fact extension,
table 113 steps 159
table relation method, creating a fact
extension 165
S
table-based transformations 195
schema objects 22
table-based transformations, creating 203
schema objects, basic 22
table-level database instances 81, 82
secondary database instances, table
tables 22
level 81, 82
tables, associating to database
secondary tables 86
instances 96
selecting the optimal data source, fact
tables, changing primary database
tables 87
instances 108
selecting the optimal data source, lookup
tables, multiple data sources 102
tables 88
tables, primary 86
server-level partitioning 224
tables, removing database instances 113
single data source, tables 97
tables, secondary 86
split fact tables, MultiSource Option 91
tables, single data source 97
split lookup tables, MultiSource
Option 92 transformation 193
SQL generation, data type compatibility transformation components 198
rules 89 transformation metrics 193, 203
SQL generation, logical table size 41 transformation types 195
SQL generation, multisource reports 85 transformations 23, 193
SQL, multisource reports 120 transformations, creating 200
steps, fact degradation 150 transformations, expression based 195
steps, fact extension using cross product transformations, table based 195
method 176 types of fact level extensions 147

MicroStrategy Architect: Advanced Project Design Index
U
use case, filtering qualifications 93
use case, split fact tables 91
use case, split lookup tables 92
use cases, MultiSource Option 91
W
Warehouse Catalog, project-wide
options 36
warehouse partition mapping 225


Microstrategy Architect - Advanced Project Design

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Microstrategy Architect - Advanced Project Design

Загружено:

Авторское право:

Доступные форматы

MICROSTRATEGY ARCHITECT: ADVANCED PROJECT DESIGN

MicroStrategy, MicroStrategy 6, MicroStrategy 7, MicroStrategy 7i, MicroStrategy 7i Evaluation Edition,

MicroStrategy Education Services MicroStrategy Incorporated

Preface Course Description...................................................................... 9

1. Introduction to Lesson Description ................................................................... 17

2. Managing Project Lesson Description ................................................................... 27

2011 MicroStrategy, Inc. 5

Maintaining Warehouse Catalog.................................................. 33

3. Using MicroStrategy Lesson Description ................................................................... 79

6 2011 MicroStrategy, Inc.

4. Fact Level Extensions Lesson Description ................................................................. 143

5. Transformations Lesson Description ................................................................. 191

6. Partitioning Lesson Description ................................................................. 221

2011 MicroStrategy, Inc. 7

Implementing Metadata Partition Mapping .......................... 234

Index ......................................................................................... 239

8 2011 MicroStrategy, Inc.

This 1-day course covers advanced features involved in the

First, students will learn how to manage project data sources

After taking this course, students will understand how to

2011 MicroStrategy, Inc. 9

Who Should Take this Course

MicroStrategy Desktop: Reporting Essentials

MicroStrategy Architect: Project Design Essentials

You should also have a basic knowledge of SQL.

MicroStrategy Advanced Data Warehousing

10 Who Should Take this Course 2011 MicroStrategy, Inc.

Describe the project design process and describe the basic

Define the primary and secondary database instance, use

Describe how you can use MultiSource Option to access

Describe the three types of fact level extensions available

Create different types of transformations, use

Describe the purpose of partitioning, explain the

2011 MicroStrategy, Inc. Course Objectives 11

About the Course Materials

CourseYou will achieve these overall objectives by

Main TopicYou will achieve this secondary objective by

12 About the Course Materials 2011 MicroStrategy, Inc.

Opportunities for Practice

The following sections within lessons provide you with

References to screen elements and keys that are the focus of

Click Select Warehouse.

2011 MicroStrategy, Inc. About the Course Materials 13

References to code, formulas, or calculations within

References to literal data you must type in an exercise or

References to a keyboard key or shortcut keys are in

The aggregation level is the level of calculation for the

14 About the Course Materials 2011 MicroStrategy, Inc.

Notes and Warnings

A note icon indicates helpful information.

The following heading icons are used to indicate specific

Precedes a Review section

Precedes a Case Study

Precedes a Business Scenario

2011 MicroStrategy, Inc. About the Course Materials 15

MicroStrategy Architect: Project Design Essentials

MicroStrategy Desktop: Advanced Reporting

MicroStrategy Desktop: Reporting Essentials

MicroStrategy Report Services: Document Essentials

MicroStrategy Report Services: Dynamic Dashboards

MicroStrategy Web for Professionals

MicroStrategy Web for Reporters and Analysts

16 About the Course Materials 2011 MicroStrategy, Inc.

This lesson introduces you to the MicroStrategy Architect: