ADVPD 941 Mar14 Color PDF

MICROSTRATEGY ARCHITECT: ADVANCED PROJECT DESIGN
Course Guide
Version: ADVPD-941-MAR14-CG
© 2000–2014 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
Commercial 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 Software—Restricted 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.
Copyright Information
All Contents Copyright © 2014 MicroStrategy Incorporated. All Rights Reserved.
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, 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,127,403, 7,174,349, 7,181,417, 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,
7,861,253, 7,881,443, 7,925,616, 7,945,584, 7,970,782, 8,005,870, 8,051,168, 8,051,369, 8,094,788, 8,130,918,
8,296,287, 8,321,411 and 8,452,755. Other patent applications are pending.
How to Contact Us
MicroStrategy University MicroStrategy Incorporated

1850 Towers Crescent Plaza 1850 Towers Crescent Plaza
Tysons Corner, VA 22182 Tysons Corner, 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/training-events http://www.microstrategy.com
MicroStrategy Architect: Advanced Project Design Table of Contents
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 ................................................................................. 12
Opportunities for Practice ...................................................... 13
Typographical Standards ....................................................... 13
MicroStrategy Courses .......................................................... 15
Core Courses......................................................................... 15
Advanced 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
Using the Fact Editor ............................................................. 24
Lesson Summary......................................................................... 26
© 2014 MicroStrategy Inc. 5

Table of Contents MicroStrategy Architect: Advanced Project Design
2. Managing Project Lesson Description ................................................................... 27

Schema Lesson Objectives ................................................................. 28
Review of Database Instances .................................................... 29
Primary/Secondary Database Instances at the Project Level 30
Maintaining Warehouse ............................................................... 32
Maintaining Tables................................................................. 32
Aggregation Awareness............................................................... 35
Review of Base and Aggregate Fact Tables.......................... 35
How Is MicroStrategy Aggregate-Aware?.............................. 36
Data Marts ................................................................................... 40
What Is a Data Mart? ............................................................. 40
Creating Data Marts............................................................... 46
Using Data Marts in a Project ................................................ 54
Lesson Summary......................................................................... 58
Exercises: Managing Project Schema ......................................... 61
Forecasting Project Information ............................................. 61
3. Using MicroStrategy Lesson Description ................................................................... 73

MultiSource Option Lesson Objectives ................................................................. 74
Introduction to MicroStrategy MultiSource Option ....................... 75
Primary/Secondary Database Instances at the Table Level .. 76
Support for Duplicate Tables ................................................. 77
SQL Generation for Multisource Reports............................... 78
Supported Use Cases............................................................ 83
Associating Tables to Database Instances.................................. 88
Adding Tables with a Single Data Source.............................. 89
Adding Tables with Multiple Data Sources ............................ 92
Changing the Primary Database Instance for a Table ........... 95
Removing a Database Instance from a Table........................ 98
Creating Objects for Multisource Reports.................................. 100
Creating the Forecast Revenue Fact ................................... 102
Creating the Forecast Revenue Metric ................................ 103
Creating a Multisource Report ................................................... 104
Processing of SQL for Sample Report................................. 105
Lesson Summary....................................................................... 114
Exercises: Using MicroStrategy MultiSource Option ................. 117
(Provisional) Demonstration Exercises ................................ 117
Add Tables from a Secondary Database Instance and Create an
Attribute and Metric for a Multisource Report ...................... 121
Create a Multisource Report ................................................ 126
6 © 2014 MicroStrategy Inc.

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

Lesson Objectives ............................................................... 130
Overview of Fact Level Extensions............................................ 131
Creating Fact level Extensions in Fact Editor ...................... 133
Degrading Fact Levels............................................................... 135
Steps for Fact Degradation .................................................. 137
Creating a Fact Degradation................................................ 139
Extending Fact Levels ............................................................... 143
Steps for Fact Extension Using the Table Relation Method 146
Creating Fact Extensions Using the Table Relation Method 151
Disallowing Fact Levels ............................................................. 156
Lesson Summary....................................................................... 161
Exercise: Fact Level Extensions................................................ 163
Create a Fact Degradation .................................................. 163
5. Transformations Lesson Description ................................................................. 169

What Is a Transformation? ........................................................ 171
Types of Transformations .................................................... 173
Transformation Components ............................................... 176
Creating and Using Transformations ......................................... 178
Creating Transformations .................................................... 178
Using Transformations in Metrics ........................................ 181
Transformation Examples .................................................... 185
Lesson Summary....................................................................... 190
Exercise: Transformation........................................................... 191
Create the Last Year’s Transformation ................................ 191
6. Partitioning Lesson Description ................................................................. 199

Introduction to Partitioning Concepts......................................... 201
Warehouse Partition Mapping ................................................... 204
Overview .............................................................................. 204
Implementing Warehouse Partition Mapping ....................... 205
Metadata Partition Mapping....................................................... 212
Overview .............................................................................. 212
Implementing Metadata Partition Mapping .......................... 212
Lesson Summary....................................................................... 216

Table of Contents MicroStrategy Architect: Advanced Project Design
A. Warehouse Catalog Maintaining Individual Tables............................................... 220

Project-Wide Warehouse Catalog Options .......................... 222
Adding tables with Multisource Option....................................... 225
Index ......................................................................................... 233

PREFACE
Course Description
This one 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 two day MicroStrategy
Developer: Reporting Essentials course and the two 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 Architect graphical
interface. 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 Developer: 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 © 2014 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 Architect
graphical interface 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 74)
• 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 130)
• Create different types of transformations, use transformations in

transformation metrics, and describe common uses for transformations in
reporting. (Page 170)
• 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 200)
© 2014 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:
• Course—You 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.
• Lesson—You 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 Topic—You 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.
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.
12 About the Course Materials © 2014 MicroStrategy Inc.

Opportunities for Practice

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.
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
© 2014 MicroStrategy Inc. About the Course Materials 13

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.

Ayouwarning icon calls your attention to very important information that
should read before continuing the course.

MicroStrategy Courses
Core Courses
• Implementing MicroStrategy: Development and Deployment
• MicroStrategy Web Essentials
• MicroStrategy Web for Reporters and Analysts
• MicroStrategy Web for Professionals
• MicroStrategy Visual Insight Essentials
• MicroStrategy Report Services: Documents and Dashboards
• MicroStrategy Mobile for App Developers
• MicroStrategy Architect: Project Design Essentials
• MicroStrategy Developer: Reporting Essentials
• MicroStrategy Developer: Advanced Reporting
• MicroStrategy Office Essentials
© 2014 MicroStrategy Inc. About the Course Materials 15

Advanced Courses
• MicroStrategy Administration: Configuration and Security
• MicroStrategy Administration: Application Management
• MicroStrategy Engine Essentials
• MicroStrategy Architect: Advanced Project Design
• MicroStrategy Advanced Data Warehousing
• MicroStrategy Data Mining and Advanced Analytics
• MicroStrategy Developer: Advanced Reporting Case Studies
• MicroStrategy Freeform SQL Essentials
• MicroStrategy Transaction Services for Mobile App and Dashboard

Developers
• MicroStrategy Web SDK: Customization Essentials
• MicroStrategy Web SDK: Customizing Security
• MicroStrategy Web SDK: Portal Integration

All courses are subject to change. Please visit the MicroStrategy Web site for the latest 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 © 2014 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.
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.
© 2014 MicroStrategy Inc. Review of the Project Design Process 19

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 © 2014 MicroStrategy Inc.

In the MicroStrategy Architect: Advanced Project Design course, you will learn
about different strategies and tools that help you manage your project’s
schema. In particular, you will learn about the following:
• Primary and secondary database instances—A 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 instances—data
sources—to a project.
• Aggregation awareness—MicroStrategy 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 marts—A 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 execution—By default, the objects in a standard report

have to come from a single data source. However, you can use the
MultiSource Option—an add-on component to Intelligence Server—to
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.
© 2014 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.
In the MicroStrategy Architect: Project Design Essentials course you learned

how to create the following basic schema objects that form the foundation of a
MicroStrategy project:
• Tables—Logical objects that correspond to physical tables stored in the data

warehouse that you want to use in a MicroStrategy project
• Facts—Logical 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.
• Attributes—Logical 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.
• Hierarchies—Logical 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 © 2014 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 that you use
for more advanced functions:
• Transformations—Logical objects most often used to compare values at

different times—for example, this year versus last year and today versus
month to date. Transformations are useful for discovering and analyzing
time-based trends in your data.
• Partition mappings—Partitioning 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.
© 2014 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
Using the Fact Editor

You created basic facts in the Architect graphical interface. However, if you
want to create individual facts, modify existing facts, or add complexity to facts
you initially created in Architect, you use the Fact Editor. The Fact Editor is
one of the schema object editors available in Developer. It enables you to create
or modify any type of fact or fact expression and configure a variety of
fact-related settings.
To access the Fact Editor:
1 Open the desired project.
2 Do one of the following:

If you are creating a new fact, on the File menu, point to New and select
Fact.
OR
If you are modifying an existing fact, in the Schema Objects folder, select
the Facts folder.
In the Facts folder, double-click the fact you want to modify.
24 Review of Schema Objects © 2014 MicroStrategy Inc.

The following image shows the Fact Editor:

Fact Editor
The Fact Editor has the following tabs:
• Definition—This tab enables you to create, modify, and delete fact

expressions.
• Column Alias—This tab enables you to modify the column alias for a fact.
• Extensions—This tab enables you to create, modify, and delete level
extensions for a fact.
All facts have a definition and column alias, but level extensions for facts are
optional. You already know about the first two tabs from the Project Design
Essentials course. You will learn more about extensions later in this course.
© 2014 MicroStrategy Inc. Review of Schema Objects 25


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, understand
aggregation-awareness, create data marts, enable multisource report
execution, and use fact editors.
• 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 —such
as transformations and partition mappings—that you use for more
advanced functions.
• The Fact Editor is one of the schema object editors available in Developer.
It enables you to create or modify any type of fact or fact expression and
configure a variety of fact-related settings.
26 Lesson Summary © 2014 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 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 Architect
graphical interface 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 Tables pane options in the Architect graphical
interface can help you maintain a project over time. (Page 32)
• 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 35)
• 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, and use a data mart table in a project. (Page 40)

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 MicroStrategy

Architect: Project Design Essentials course.
Ifconnection
you are using security features such as warehouse authentication or
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.
Toappropriate
create and configure database instances, you must have the
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 MDX
Cube Reporting Guide product manual.
© 2014 MicroStrategy Inc. Review of Database Instances 29

Primary/Secondary Database Instances at the Project Level

By default, the database instance you select during the project creation process
becomes the project’s primary database instance. All standard reports in a
project execute against the data source defined in the primary database
instance by default.
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, by adding a table from the secondary database instance
to a project using MultiSource Option. MultiSource Option is only
available with three tier projects. You will learn about MultiSource
Option later in this course.
To associate a secondary database instance with a project:
1 In Developer, 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.
ToArchitect:
learn how to create database instances, refer to the MicroStrategy
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.
5 In the Available Data Mart, Query Builder, Freeform 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.

30 Review of Database Instances © 2014 MicroStrategy Inc.
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 44.
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
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.
© 2014 MicroStrategy Inc. Review of Database Instances 31

Maintaining Warehouse

Describe how the Warehouse Tables pane options in the Architect graphical
interface can help you maintain a project over time.

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

designed to help you with project maintenance. For more information,
see the MicroStrategy Administration: Application Management course.
You already learned how to use the Warehouse Tables pane in Architect
graphical interface to select the data warehouse tables you want to use in a
MicroStrategy project. Now, you will learn about other options available that
enable you to maintain a project.
Maintaining Tables
After you add warehouse tables to a 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.
32 Maintaining Warehouse © 2014 MicroStrategy Inc.

The Warehouse Tables pane in Architect graphical interface enables you to

maintain the integrity of the logical tables with the data warehouse structure. It
provides a variety of options that apply to the project tables on an individual
basis. You access these options in the Warehouse Tables pane by right-clicking
any table you have added to a project. The following image displays these table
options:
Table Options
The Warehouse Tables pane provides the following options for individual
tables:
• Update Structure—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.
• Show Sample Data—This option enables you to view the first 100 rows of
data in a table.
• Select Database Instance—This option enables you to add additional

database instances associated with the project.
© 2014 MicroStrategy Inc. Maintaining Warehouse 33

You can view a table’s structure before you add it to the project. To show
the columns in a table, click expand.
34 Maintaining Warehouse © 2014 MicroStrategy Inc.

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

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 detail—by 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 detail—by category, region, and month. Therefore, it is
an aggregate fact table for these two facts.
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.
© 2014 MicroStrategy Inc. Aggregation Awareness 35

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 Tables pane in Architect
graphical interface.
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 will 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 must manually map the
new table to the desired attributes and facts.
IfMicroStrategy
the aggregate fact table structure matches the base fact table,
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.
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 can provide the answer.
36 Aggregation Awareness © 2014 MicroStrategy Inc.

MicroStrategy Architect assigns a size to every table when you initially add
them to a project. These size assignments are stored in the metadata.
MicroStrategy Architect 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. Using this formula, MicroStrategy Architect calculates the respective
weight of each attribute as shown in the illustration above. The logical table
size of each fact table is simply the sum of its 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 Architect graphical interface, on the Project Tables view tab, select a

table.
2 In the Properties pane, in the Definition section, click the Logical Size box,
type the new logical table size value.
ToEditor.
lock the logical size of the table you need to access Logical Size
You cannot lock the size of the table from the Properties pane.
To change logical table sizes and lock the table sizes using the Logical Size
Editor:
1 On the Design tab, in the Editors section, click Edit logical size of tables
button.
38 Aggregation Awareness © 2014 MicroStrategy Inc.

2 In the Logical Size Editor, for the table you want to modify, in the Size value
box, type a new logical table size value.
3 If you want to preserve the logical table size of a table, select its Size locked
check box.
4 Click OK to close the Logical Size Editor.
The following image shows the Logical Size Editor:

Changing Logical Size in the Logical Size Editor
You should select Size Locked 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.
5 Click Save and Close.
6 Update the project schema.

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, and 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 Developer and 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
use it as a source table.
Common applications for data marts include:
• 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.
You can use data marts in other usage scenarios. Combining data marts
with MicroStrategy data mining features or with Freeform SQL reports
are two such scenarios.
40 Data Marts © 2014 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 Sold at 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
users request it often.
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 by creating a data
mart table. You can then bring this table into your project, map the Forecast
Unit Sales and metric to it, and have your region-level reports automatically
use it, as shown below:
Aggregate Fact Table Created as Data Mart
© 2014 MicroStrategy Inc. Data Marts 41

Data Mart Objects
Creating data marts involves creating two objects:
• Data mart report—This 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 table—This 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 1—Use the project’s primary database instance.
• Option 2—Use a secondary project database instance that exists in the same
warehouse as the primary project database instance.
• Option 3—Use 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.

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.

Ifwarehouse
the data mart database instance does not reside in the same
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 Forecast
Data database instance residing 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 201201, 'Jan 2012', 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
machine’s memory. It then creates the data mart table in the different data
warehouse and inserts the results.
Creating Data Marts

In Developer, 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
!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 table—This 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 else’s 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.
10 Update project schema.
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 add the table to the project, then update the
appropriate fact, and finally update the project schema.

Adding the Data Mart table to the Project:
1 In Developer, on the Schema menu, select Architect.
2 On the Warehouse Tables pane, expand the Forecast Data. You can now see
the data mart table.
3 Right-click the data mart table and select Add Table to Project.
4 The Results Preview window shows attributes and facts that will be created.
In the Results Preview window, in the Fact tab, clear the check box for the
facts.
There might be scenarios where you want to keep the facts. If you want
to create facts, ensure you select the appropriate fact check box in the
Fact tab of the Results Preview window.
5 Click OK.
6 On the toolbar, click Save and Close.
The following image shows the REGION_YEAR_FORECAST_UNIT_SALES

table added to the project:
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 Architect graphical interface, edit the fact that is used in the metric of the
data mart report.
The relationship of the metric to the fact on which it is based is

referred to as a child dependency. In Developer, you can use
MicroStrategy Object Manager to quickly locate child dependencies
for the metric.
2 In the Project Tables view tab, locate the table that contains the fact and
right-click to edit the fact on which the data mart metric is based.
3 In the Fact Editor, create a new fact expression that uses the data mart table
as a source table.
Ifunderlying
the fact column in the data mart table is named the same as the
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 from the other facts in the
project.
4 Click OK.

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.


Lesson Summary
• The database instance you select during the project creation process
becomes this project’s 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 Tables pane in Architect graphical interface 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 Tables pane in Architect graphical interface. 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 Size Editor or
from the Properties pane in Architect graphical interface.
• 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
in the chosen warehouse.
• 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 Tables pane in Architect graphical interface, update the
corresponding fact, and then update the project schema.
© 2014 MicroStrategy Inc. Lesson Summary 59


MicroStrategy Architect: Advanced Project Design Exercises: Managing Project Schema 2

Exercises: Managing Project Schema
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
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.
© 2014 MicroStrategy Inc. Exercises: Managing Project Schema 61

2 Exercises: Managing Project Schema MicroStrategy Architect: Advanced Project Design
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
62 Exercises: Managing Project Schema © 2014 MicroStrategy Inc.

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.

Create an Aggregate Table Using Data Mart
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.
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 and the
Forecast Revenue and Forecast Units Sold metrics on the template. 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 Developer, 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.
8 If you did not edit Forecast Units Sold during the lesson with your
instructor, repeat steps 3 to 7 for the Forecast Units Sold metric so the
Column Name used in table SQL creation box is Total_Units_Sales.
Create the Data Mart report
9 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 and Forecast Units Sold metrics are located in the
Metrics folder.
Configure attribute display options
10 In the Report Editor, on the Data menu, select Attribute Display.
11 In the Attribute Display window, in the Attribute drop-down list, ensure

that Region is selected.
attribute forms.
15 In the Displayed forms list, select the DESC form.
16 Click the upper < button to remove the DESC form from the Displayed
forms list.
17 In the Report objects forms list, select the DESC form.

18 Click the lower < button to remove the DESC form from the Report objects
forms list.
19 In the Attribute Display window, in the Attribute drop-down list, select

Quarter.
attribute forms.
23 In the Displayed forms list, select the DESC form.
24 Click the upper < button to remove the DESC form from the Displayed
forms list.
25 In the Report objects forms list, select the DESC form.
26 Click the lower < button to remove the DESC form from the Report objects
forms list.
27 Click OK.
Configure the data mart
28 In the Report Editor, on the Data menu, select Configure Data Mart.
29 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.
30 In the Table name box, type REGION_FORECAST_SALES.
31 Click OK.
32 In the Report Data Mart Setup window, click OK.
33 Save the report in the Public Objects\Reports folder as Regional Forecast

Revenue
34 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:
35 Close the report.
Incorporate the data mart table into the project
36 In Developer, on the Schema menu, select Architect.
37 In the Read Only window, select Edit: This will lock all schema objects in
this project from other users.
38 Open the Architect graphical interface, click Project Tables View tab.
39 Disable automatic metric creation.
Automatic metric creation can be changed by clicking Architect button,

selecting Settings, clicking the Metric Creation tab, and clearing Sum
check box.
40 In the Warehouse Tables pane, in the Forecast Data database instance,

right-click the REGION_FORECAST_SALES table and select Add Table
to Project.
41 In the Results Preview window, in the Fact tab, clear the Forecast Revenue
and Total Unit Sales check boxes.
42 Click OK.
Update the Forecast Revenue fact
43 In the Project Tables View tab, find the FORECAST_SALES table and select
the Forecast Revenue fact.

44 Right-click the Forecast Revenue fact and select Edit.
45 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.
46 Under Mapping method, ensure Automatic is selected.
47 Click OK.
48 Click OK to close the Fact Editor.
Update the Forecast Units Sold fact
49 In the Project Tables View tab, find the FORECAST_SALES table and select
the Forecast Units Sold fact.
50 Right-click the Forecast Units Sold fact and select Edit.
51 In the Fact Editor, create a new fact expression that uses the
Total_Unit_Sales column in the REGION_FORECAST_SALES table as a
source table.
52 Under Mapping method, ensure Automatic is selected.
53 Click OK.
54 Click OK to close the Fact Editor.
Verify the attribute source tables
55 In the REGION_FORECAST_SALES table, right-click the Quarter attribute

ID form and select Edit.
56 In the Modify Form Expression window, click OK.
57 In the Modify Attribute Form window, ensure the

REGION_FORECAST_SALES table is selected as source tables.
58 Click OK.
59 Repeat steps 55 to 58 for Region attribute.
Update the project schema
60 Update the project schema and exit Architect.

Ensure that the Recalculate table logical sizes check box is selected
in the Schema Update window.
Test the new fact mapping
61 In Developer, 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.
62 Run the report. The result set should resemble like the following:
63 View the report in SQL View. The SQL should look like the following:
In the FROM clause, notice that the data is retrieved from the new
aggregate table REGION_FORECAST_SALES.

64 Save the report in the Public Objects/Reports folder as Data Mart Test and
close the report.
Change the logical table size for the aggregate table
65 Go to Architect graphical interface.
66 In Architect graphical interface, on the Design tab, click Edit logical size
of tables button as shown below:
Notice that the REGION_FORECAST_SALES table’s 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.
67 In the Logical Size Editor, for the REGION_FORECAST_SALES table, in

the Size value box, type 30.
68 For the REGION_FORECAST_SALES table, select the Size locked check

box.
When you select this check box, the logical size for the table will not be
recalculated when you update the schema.
69 Click OK.
70 Save and close Architect.
Update the project schema.
Ensure that the Recalculate table logical sizes check box is selected
in the Schema Update window.

Test the change of the logical table size on the report SQL
72 In Developer, 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.
73 Close the report without saving it.


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

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.
• Describe how MultiSource Option accesses heterogeneous data sources,

supports duplicate tables, generates SQL for reports with multiple data
sources, and common MultiSource option use cases. (Page 75)
• 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 88)
• Create objects for use in multisource reports. (Page 100)
• Create a report that contains objects from multiple data sources and
describe how the Engine processes the SQL for such reports. (Page 104)

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

Option

Describe how MultiSource Option accesses heterogeneous data sources,
supports duplicate tables, generates SQL for reports with multiple data
sources, and common MultiSource option use cases.
By default, the objects in a standard report come from a single data source.
However, you can use the MultiSource Option—an add-on component to
Intelligence Server—to 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
If you want to create a report that includes the revenue and forecast revenue
data for each region, you must 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. And you can also obtain the region data from
either data warehouse, since it exists in both databases. MultiSource Option
enables you to create this type of report.
© 2014 MicroStrategy Inc. Introduction to MicroStrategy MultiSource Option 75

Primary/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.
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.
• 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.
• MultiSource Option does not support fact tables partitioned across multiple
data sources.
For more information about partitioning, see the “Partitioning”

lesson starting on page 199.
76 Introduction to MicroStrategy MultiSource Option © 2014 MicroStrategy Inc.

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 80 and “Selecting the Optimal Data Source for Lookup Tables”
starting on page 81.
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.
Tocompatibility
maintain data consistency, the Engine applies data type
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 81.
• 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.

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 95.
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
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
Ifjointwodatacolumns do not have compatible data types, the Engine cannot

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 two data type definitions may not always be the same.
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 MicroStrategy Tutorial project:
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.
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.
Inmultiple
this lesson, you will analyze two scenarios for joining data from
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.
88 Associating Tables to Database Instances © 2014 MicroStrategy Inc.

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 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 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.
However, there are two tables that map to a data source other than Tutorial
Data:
Table with a Single Data Source
© 2014 MicroStrategy Inc. Associating Tables to Database Instances 89

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 Architect

graphical interface:
1 In Developer, open the project to which you want to add the tables.
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 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 Architect graphical interface:
1 In Developer, open the project.

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.
6 In the warning window, under Available options, ensure the Indicate that
<Table Name> is also available from the current DB Instance option is
selected.
Iftable
you click the Make no changes to <Table Name> option, the
is not mapped to the selected database instance, and no
duplicate table is created.

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.
Totableverify the database instances to which a table is mapped, view the

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.


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 used 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 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 Architect graphical interface to change the primary
database instance for a table.
To change the primary database instance for a table in the Architect graphical
interface:
1 In Developer, 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 Definition category, select Primary DB Instance.

6 Beside the current primary database instance, click the Browse 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 To keep the current primary database instance as a secondary database

instance, in the Primary Database Instance drop-down, select a new
database instance. Then in the Secondary Database Instances list, ensure
the check box for the former primary database instance is selected.
9 Click OK.
The changes you made are reflected in the Properties pane, in the
database instances associated with the Primary DB Instance and
Secondary DB Instances properties.


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 the Architect

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.
Insincesuchthatcases, you do not want to remove the table from the project
removes its association to all database instances.
The same Available Database Instance window that you used to change the
primary database instance of a table in Architect graphical interface can be
used to remove a database instance from a table.
Ifinstance,
the database instance you want to remove is the primary database
you must 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.
Ifyouyouhavehavetoattributes that do not use the Automatic mapping method,

manually map the duplicate tables to the corresponding
attributes.
However, the FORECAST_SALES and REGION_FORECAST_SALES tables

do not exist in the Tutorial Data data warehouse.
100 Creating Objects for Multisource Reports © 2014 MicroStrategy Inc.

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.
© 2014 MicroStrategy Inc. Creating Objects for Multisource Reports 101

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 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.
102 Creating Objects for Multisource Reports © 2014 MicroStrategy Inc.

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 zero

decimal places.
© 2014 MicroStrategy Inc. Creating Objects for Multisource Reports 103

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.
104 Creating a Multisource Report © 2014 MicroStrategy Inc.

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 Scenario—Obtaining 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.
© 2014 MicroStrategy Inc. Creating a Multisource Report 105

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.
Toconsolidation
minimize the movement of data, the Engine performs the final
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.
Ifselects
there is a tie between two or more database instances, the Engine
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 Scenario—Aggregating 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


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 the Architect graphical interface.
• You can add duplicate tables to a project in the Architect graphical

interface.
• You can change the primary database instance for a table in the Architect
• You can remove a database instance from a table in 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.


MicroStrategy Architect: Advanced Project Design Exercises: Using MicroStrategy MultiSource Option 3

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.
(Provisional) Demonstration Exercises
Overview
You may have already completed the exercise depicted below if you followed
along with your instructor during the demonstration for this chapter. If you
already brought the FORECAST_SALES, REGION_FORECAST_SALES,
LU_REGION, and LU_COUNTRY tables to the Tutorial project from the
Forecast Project, and created the Forecast Revenue fact and metric, you may
skip this exercise. The subsequent exercises are dependent upon
accomplishing these tasks first.
In this exercise, you will use the Warehouse Tables pane in Architect graphical
interface to add the following tables from the Forecast Data database instance
to the MicroStrategy Tutorial project:
Lookup Table Name
FORECAST_SALES
LU_COUNTRY
LU_REGION
As you add these tables, you should configure them as follows:
• Make Forecast Data the primary database instance for the

FORECAST_SALES table
© 2014 MicroStrategy Inc. Exercises: Using MicroStrategy MultiSource Option 117

3 Exercises: Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design
• Add LU_REGION and LU_COUNTRY as duplicate tables with Forecast

Data as the primary database instance
• Create the Forecast Revenue metric
Open the Architect for the MicroStrategy Tutorial project
1 In the MicroStrategy Analytics Modules project source, open the

MicroStrategy Tutorial project.
2 Go to Schema menu and select Architect.
3 In the Architect graphical interface, click Project Tables View tab.
4 Disable automatic metric creation.
Automatic metric creation can be changed by clicking Architect button,

selecting Settings, clicking the Metric Creation tab, and clearing the
Sum check box.
Add the LU_REGION and LU_COUNTRY tables to the project and change the
Database Instance
5 In the Warehouse Tables pane, in the list of tables available in the Forecast
Data database instance, right-click the LU_REGION table and select Add
Table to Project.
6 In the Options window, under Available options, keep the Indicate that
LU_REGION is also available from the current DB Instance option
selected.
7 Click OK.
8 In the Architect graphical interface, in the Properties pane, click the Tables
tab.
9 On the Tables tab, in the drop-down list, select LU_REGION.
10 Under Definition category, select Primary DB Instance.
11 Beside the current primary database instance, click the Browse button:
118 Exercises: Using MicroStrategy MultiSource Option © 2014 MicroStrategy Inc.


Instance drop-down list, select Forecast Data. Ensure the check box for
Tutorial Data is selected.
13 Click OK.
The color coding of the table indicates the tables is mapped to a

secondary database instance.
14 Repeat steps 5 to 13 for LU_COUNTRY.
Add the FORECAST_SALES table to the project
15 In the Warehouse Tables pane, expand the Forecast Data database

instance.
16 In the list of tables available in the database instance, right-click the

FORECAST_SALES table and select Add Table to Project.
17 In the Results Preview window, in the Fact tab, keep Forecast Unit Price
only and clear all other facts. On the Attribute tab, keep the default
selection.
18 Click OK.
19 Right-click the ID columns for all the attributes mapped in the

FORECAST_SALES table, select Edit to verify all the source tables available
are mapped and click OK.

Creating Forecast Revenue fact
20 Right-click Forecast_Sales table and select Create Fact.
21 In the Create New Fact Expression window, in the Source table list, select
FORECAST_SALES.
22 Create the following fact expression:

FORECAST_QTY_SOLD * (FORECAST_UNIT_PRICE
- FORECAST_DISCOUNT)
23 Ensure Automatic mapping is selected.
24 Click OK.
25 Right-click fact column you just created and select Rename.
26 In the MicroStrategy Architect window, type Forecast Revenue.
27 Click OK.
28 Save and update schema and close Architect.
Create the Forecast Revenue metric
29 In Developer, in the MicroStrategy Tutorial project, in the Public

Objects\Metrics\Sales Metrics folder, in the File menu, select New, and
select Metric.

30 Use the Forecast Revenue fact to create the following metric:
32 Save the metric as Forecast Revenue.
Add Tables from a Secondary Database Instance and Create an

Attribute and Metric for a Multisource Report
Overview
In this exercise, you will use the Warehouse Tables pane in Architect graphical
interface to add the following tables from the Forecast Data database instance
to the MicroStrategy Tutorial project:

Lookup Table Name
LU_PRODUCT
LU_SUBCATEG
You will also add the LU_GROUP table from the Inventory Data database
instance. As you add these tables, you should configure them as follows:
• Make Forecast Data as the primary database instance for the

LU_PRODUCT table
• Add LU_SUBCATEG as a duplicate table with Forecast Data as the

secondary database instance
• Add LU_GROUP as a primary database instance for the LU_GROUP table
• Create the Product attribute
You need the Product attribute for the multisource report you will create later
in these exercises.
You should save the Product attribute in the Schema

Objects\Attributes\Products folder. As part of creating the Product attribute,
you need to complete the following tasks:
• Make sure the ID and DESC attribute forms for the Product attribute map
the following as source tables:
Attribute Form Expressions Source Tables
Product ID: PRODUCT_ID LU_GROUP
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_GROUP
• Add the Product attribute to the Products hierarchy.
After you have completed these tasks, save and update project schema, and
close Architect.
Add the LU_PRODUCT table to the project

MicroStrategy Tutorial project.
2 On the schema menu, select Architect.
3 In the Architect graphical interface, click Project Tables View tab.
4 In the list of tables available in the Forecast Data database instance,

right-click the LU_PRODUCT table and select Add Table to Project.
5 In the Result Preview window, click OK.
Product attribute has been created with ID:PRODUCT_ID and

DESC:PRODUCT_DESC.
6 In LU_PRODUCT table, right-click the ID:PRODUCT_ID column and

select Edit.
8 In the Modify Attribute Form window, ensure that the LU_PRODUCT

source table is selected and click OK.

Add the LU_GROUP table to the project
9 In the list of tables available in the Inventory Data database instance,

right-click the LU_GROUP table and select Add Table to Project.
10 In the Result Preview window, click OK.
Product attribute has been created with ID:PRODUCT_ID. Category

attribute has been created with ID:CATEGORY_ID and
DESC:CATEGORY_DESC.
11 In LU_GROUP table, right-click the ID:PRODUCT_ID column and select

Edit.
13 In the Modify Attribute Form window, ensure that the LU_PRODUCT and
LU_GROUP source tables are selected and click OK.
Verify that CATEGORY_ID in LU_GROUP is mapped to the Category

attribute.
Add the LU_SUBCATEG table to the project
14 In the Warehouse Tables pane, in the list of tables available in the Forecast
Data database instance, right-click the LU_SUBCATEG table and select
Add Table to Project.
15 In the Options window, under Available options, keep the Indicate that
LU_SUBCATEG is also available from the current DB Instance option
selected.
16 Click OK.
Create Product and Category relationship and update the Product user
hierarchy
17 On the Hierarchy View tab, select the Product attribute and drag it to
Category attribute. A one-to-many relationship is created with Product as
the parent attribute.
18 On the Properties pane, in the Location property click Browse and save the
Product attribute in the Schema Objects\Attribute\Products folder.

19 On the Home tab, in the Hierarchy section, in the drop-down list, select
Products.
20 In the Hierarchy View tab, right-click an empty area and select

Add/Remove attributes in Hierarchy.
21 In the Select Objects window under Available objects, select the Product
attribute and click the > button to move Product to the Selected objects list.
22 Click OK.
23 Right-click the Product attribute and select Define Browse Attributes. In

the Select Objects window, add the Category attribute to the Selected
Objects list.
24 Click OK.
25 Set the Product attribute as an entry point.
Save and Update the project schema
26 Save and update the project schema.
27 Close Architect.

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:
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
3 Save the report in the Public Objects\Reports folder as 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.


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
extensions—degradation, 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 131)
• Describe the purpose of fact degradations and create fact degradations to

lower the levels of facts. (Page 135)
• Describe the purpose of fact extensions and create fact extensions to extend
the levels of facts to other hierarchies. (Page 143)
• Describe the purpose of fact disallows and disallow fact levels to prevent
unnecessary cross joins from occurring. (Page 156)

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
Itwithin
is possible for the same fact to be stored at different attribute levels
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.
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.
© 2014 MicroStrategy Inc. Overview of Fact Level Extensions 131

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.
very
Fact level extensions are not commonly applied to facts, but they are
useful in special cases.
132 Overview of Fact Level Extensions © 2014 MicroStrategy Inc.

MicroStrategy Architect provides the following three types of fact level

extensions:
• Degradation—Enables you to extend the level of a fact to a lower level

within the same hierarchy.
• Extension—Enables you to extend the level of a fact to include a level from

a different hierarchy not currently related to the fact
• Disallow—Enables you to disallow a specific fact level to prevent

unnecessary cross joins to lookup tables when reporting on a fact
Creating Fact level Extensions in Fact Editor

You can access fact level extensions using the following options:
To create Fact level extensions in Fact Editor:
1 In Developer, select the fact, and double-click the fact to edit.
OR
In Developer, on the File menu, point to New and select Fact.
In the New Fact-Create New Fact Expression window, create the fact
expression and click OK.
2 In the Fact Editor, click the Extensions tab.
© 2014 MicroStrategy Inc. Overview of Fact Level Extensions 133

3 On the Extensions tab, click New.

Fact Editor Extensions tab
You can create fact level extensions using this process. The remainder of this
lesson describes each of these fact level extensions in detail.
134 Overview of Fact Level Extensions © 2014 MicroStrategy Inc.

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.
© 2014 MicroStrategy Inc. Degrading Fact Levels 135

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.
Aslevelanofalternative to creating a fact degradation, you could change the

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.
136 Degrading Fact Levels © 2014 MicroStrategy Inc.

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.
Ifitsyou allow the SQL Engine to join against the join attribute and any of
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.
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 MicroStrategy Tutorial
project:
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.
© 2014 MicroStrategy Inc. Extending Fact Levels 143

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 Freight—Report Result Set
The image above displays only the first few rows of the result set for the
report.
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 Freight—Report SQL
144 Extending Fact Levels © 2014 MicroStrategy Inc.

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.
Asto thean alternative to creating a fact extension, you could add a new level
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 relation—You 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 relation—Instead 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 product—You 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.
Toto thelearnProject
more about the fact relation and cross product methods, refer
Design Guide product manual.

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.
5 If necessary, define an allocation expression.
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 Table—Logical 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 Table—Logical 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.
Determining the Join Direction
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 Fact Extensions Using the Table Relation Method

Now that you understand the steps involved in fact 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:

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

the attribute to which you want to extend the fact and click the > button to
add it to the Selected attributes list.
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.
IfDirection
you chose to select the join attributes, the Join Attributes
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.
Join against column, click the arrow icon to set the join direction for each
join attribute.
18 Click Next.
19 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 20.
20 Click Next.
and make changes.

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 Report—Freight at the Item Level

In this example, order 148247 includes 4 items. Since only one unit of each
item was sold, the Freight for each item is calculated evenly as $5. This type of
analysis would not be possible without a fact extension.

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.
156 Disallowing Fact Levels © 2014 MicroStrategy Inc.

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 Set—Unrelated Attribute and Fact
The image above only displays the first few rows of the result set for the
report.
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.
© 2014 MicroStrategy Inc. Disallowing Fact Levels 157

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 SQL—Unrelated 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:
extension.

7 Click Disallow partially or completely the fact entry level.
8 Click Next.

the attribute you want to disallow for the fact and click the > button to add
it to the Selected attributes list.
10 Click Next.
and make changes.
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
© 2014 MicroStrategy Inc. Disallowing Fact Levels 159

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.


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.


MicroStrategy Architect: Advanced Project Design Exercise: Fact Level Extensions 4

Exercise: Fact Level Extensions
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 a 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.
© 2014 MicroStrategy Inc. Exercise: Fact Level Extensions 163

4 Exercise: Fact Level Extensions MicroStrategy Architect: Advanced Project Design
Run the 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.
Create a report
1 In Developer, in the Forecasting Project, in the Public Objects\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.
164 Exercise: Fact Level Extensions © 2014 MicroStrategy Inc.

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
7 Save the report in the Public Objects\Reports folder as 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.
12 In the General Information window, in the Name box, 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.

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.
and make changes.

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.

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 171)
• Create a transformation in MicroStrategy Architect and use a

transformation in a transformation metric. (Page 178)

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 times—for example, this year versus last year and today versus month
to date. Transformations are useful for discovering and analyzing time-based
trends in your data.
Transformations are not placed on the template of a report or a document.

Instead, report developers use transformations to define transformation
metrics—simple metrics that assume the properties of the transformation
applied to them.
© 2014 MicroStrategy Inc. What Is a Transformation? 171

For example, a report developer could create a metric to calculate revenue. If

the report developer adds a Last Year’s transformation to this
metric—effectively creating a Last Year’s Revenue metric, this metric calculates
last year’s revenue as shown in the following image:
Current Versus Last Year’s Revenue
Any transformation can be included as part of the definition of a metric, and

multiple transformations can be applied to the same metric.
172 What Is a Transformation? © 2014 MicroStrategy Inc.

Types of Transformations
There are two types of transformations:
• Table-based transformations—You implement these transformations using

a transformation table in the warehouse.
• Expression-based transformations—You 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 attributes—such as Day—by 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 month’s date, last quarter’s date, and last year’s date. For example, for
January 5, 2013, the previous day was January 4, 2013, while the last quarter’s
date was October 5, 2012.

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, 2013 date, but there are three records for the
January 3, 2013 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_ID–1 expression does not always work. If you
apply that expression to the month ID 201101 (January 2011) with the desire to
obtain information about 201012 (December 2010), you do not get any data
because there is no 201100 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.
Aexpression-based
single transformation can use a combination of table-based and
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_ID–1.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-one—A typical one-to-one relationship is last year versus this year.

A year maps to exactly one other year.
• Many-to-many—A typical many-to-many relationship is year to date. A

date maps to itself and any other dates that came before it in the given year.

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:
1 In Developer, in the Schema Objects folder, 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.
9 Click OK.
178 Creating and Using Transformations © 2014 MicroStrategy Inc.

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 Year’s
transformation in the MicroStrategy Tutorial project:
Last Year’s Transformation—Transformation Editor
The Last Year’s transformation has four member attributes mapped to the
transformation columns in their respective lookup tables. It has a one-to-many
mapping type.
© 2014 MicroStrategy Inc. Creating and Using Transformations 179

The following image shows the Transformation Editor for the Month to Date
transformation in the MicroStrategy Tutorial project:
Month to Date Transformation—Transformation 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 a transformation metric as a derived metric with

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

The following image shows the Last Year’s Revenue metric that uses the Last
Year’s transformation:
Last Year’s 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 Year’s 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 transformations 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 year’s revenue versus last year’s revenue, as shown
below:
Last Year’s Revenue for 2012

Recall that the Last Year’s transformation applied to the Last Year’s Revenue
metric is defined as follows:
Last Year’s Transformation
Notice that the Last Year’s 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 a multitude of
reporting needs. The transformation applied to the metric is dynamically
evaluated at report run time to the 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 2012 data, the Last Year’s Revenue metric values reflect
only the previous year’s December data, and not the aggregated data for entire
2012 year. This is shown in the image below:
Last Year’s Revenue for December 2012
Recall that the Last Year’s Revenue for all 2012 for The Rugrats Movie
was $16,450.

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 month—September
2012.
The YTD Revenue metric uses the Year to Date transformation. It returns the
total revenue generated between 1/1/2012 and 9/30/2012.
The LY-YTD Revenue metric uses two transformations—Year to Date and Last
Year’s. It returns the last year’s year-to-date revenue generated between
1/1/2012 and 9/30/2012.
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 year’s
year-to-date revenue to the last year’s year-to-date revenue generated before
and on the same date (September 30). The year-to-date revenue on
09/30/2012 for all items exceeded the year-to-date revenue in 2012 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 09/30/2012. 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/2012 to 09/30/2012 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.


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.

MicroStrategy Architect: Advanced Project Design Exercise: Transformation 5

Exercise: Transformation
Create the Last Year’s Transformation
Overview
You will use the Forecasting Project for this exercise.
In this exercise, you will first create a Last Year’s 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 Year’s 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.
© 2014 MicroStrategy Inc. Exercise: Transformation 191

5 Exercise: Transformation MicroStrategy Architect: Advanced Project Design
Next, you will modify the Last Year’s 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 Year’s transformation

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.
6 Click Open.
192 Exercise: Transformation © 2014 MicroStrategy Inc.


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 Year’s.
Create a transformation metric
13 In the Public Objects folder, in the Metrics folder, create a new metric.
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 Year’s transformation.

Your metric should resemble the following:
18 Save the metric in the Public Objects\Metrics folder as Last Year’s

Forecast Revenue and close it.
Create a report with a transformation metric
20 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
21 Run the report. The report result set should look like the following:
Only data for the 2012 and 2013 years are displayed, even though there is
Forecast Revenue data for 2011 in the data warehouse. Notice that both
metrics return different values for each row, but the Forecast Revenue data
for 2012 is identical to the Last Year’s Forecast Revenue for 2013, as
expected.
Modify the report
23 Add the Quarter attribute to the report template to the right of Year.
24 Place the Total subtotal on the report.
25 Run the report. The report result set should look like the following:

Since the Last Year’s 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
26 Save the report in the Public Objects\Reports folder as Transformation

Example and close it.
Add the Quarter member attribute to the Last Year’s transformation
27 In the Schema Objects folder, in the Transformations folder, double-click

the Last Year’s transformation.
28 In the Transformation Editor, click Add.
29 In the Select a Member Attribute window, select Quarter.
30 Click Open.

drop-down list, select the LU_QUARTER table.
32 Double-click the LY_QUARTER_ID column to move it to the Member

attribute expression pane.
33 Click OK.
Add the Month member attribute to the Last Year’s transformation
35 In the Select a Member Attribute window, select Month.
36 Click Open.

drop-down list, select the LU_MONTH table.
38 Double-click the LY_MONTH_ID column to move it to the Member

39 Click OK.

Add the Day member attribute to the Last Year’s transformation
41 In the Select a Member Attribute window, select Day.
42 Click Open.

drop-down list, select the LU_DAY table.
44 Double-click the LY_DAY_DATE column to move it to the Member

45 Click OK.
Save and close the transformation
46 Save and close the transformation.
Run the report
48 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 2012 is identical to the Last Year’s Forecast
Revenue total for 2013, as expected.
49 Right-click the 2012 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
50 Close both reports without saving.

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 server-level

and 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 201)
• Describe and use warehouse partition mapping to support partitioned fact

tables in a MicroStrategy project. (Page 204)
• Describe and use metadata partition mapping to support partitioned fact

tables in a MicroStrategy project. (Page 212)

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.
© 2014 MicroStrategy Inc. Introduction to Partitioning Concepts 201

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.
202 Introduction to Partitioning Concepts © 2014 MicroStrategy Inc.

MicroStrategy supports application-level partitioning for fact tables through

one of two methods:
• Warehouse partition mapping—This method is based on a physical

warehouse partition mapping table (PMT) that resides in the data
warehouse and describes the partitioned base tables that are part of a
conceptual whole.
• Metadata partition mapping—This method is based on rules logically

defined in MicroStrategy Architect and stored in the metadata.
© 2014 MicroStrategy Inc. Introduction to Partitioning Concepts 203

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
204 Warehouse Partition Mapping © 2014 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 Architect graphical interface.
Implementing Warehouse Partition Mapping

When you use warehouse partition mapping, you add the partition mapping
table to the project in the Architect graphical interface. 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.
© 2014 MicroStrategy Inc. Warehouse Partition Mapping 205

To use warehouse partition mapping in a project:
1 In Developer, open the Architect graphical interface.
2 In the Architect graphical interface, in the Warehouse Tables pane, in the

list of tables in the database instance, select the partition mapping table and
right-click to select Add Table to Project.
When you add a partition mapping table to a project, you see a

message window that reminds you to set the partitioning attribute
level in the partition mapping. Click OK.
4 In Developer, in the Schema Objects folder, in the Partition Mappings

folder, double-click the partition mapping object with 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 Warehouse Partition
Mapping Editor:
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 Warehouse Partition Mapping Editor:
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 Architect graphical interface. After adding the partition base
tables to the project, you create the partition mapping and define the data
slices for each partition base table.
212 Metadata Partition Mapping © 2014 MicroStrategy Inc.

With metadata partition mapping, you can also add partition base tables from
multiple data sources for a single partition definition. This feature can improve
the performance immensely and can be cost effective, especially when you are
dealing with large amounts of data in a project. For example, all 2012 partition
base tables are in Tutorial Data, but the 2011 partition base tables are in
Archived Tutorial Data. You can add the 2011 and 2012 partition base tables
from both data sources to a project and define the data slice for each partition
base table. The following illustration shows a metadata partition mapping table
from multiple data sources:
To use metadata partition mapping in a project:
1 In Developer, open the Architect graphical interface.
2 In the Architect graphical interface, in the Warehouse Tables pane, in the

list of tables available in the database instance, select all the partition base
tables. Right-click your selection and select Add Table to Project.
4 In Developer, in the Schema Objects folder, 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.
© 2014 MicroStrategy Inc. Metadata Partition Mapping 213

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.
15 Name and save the partition mapping.
214 Metadata Partition Mapping © 2014 MicroStrategy Inc.

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 2012 is the data slice defined for the INVENTORY_Q1_2012 table.
Similarly, the remaining tables correspond to their respective quarters.
© 2014 MicroStrategy Inc. Metadata Partition Mapping 215


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 using Architect graphical interface.
• 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.


A
WAREHOUSE CATALOG
Appendix Description
This appendix provides information on how to use Warehouse Catalog to

maintain project schema.

A Warehouse Catalog
Maintaining Individual Tables

The Warehouse Catalog enables you to maintain the integrity of the logical
tables with the data warehouse structure by providing a variety of options that
apply to the project tables on an individual basis. You access these options in
the Warehouse Catalog by right-clicking any table you have added to a project.
The following image displays these individual table options:
Individual Table Options
The Warehouse Catalog provides the following options for individual tables:
• Remove—This option enables you to remove a table from the project.
• Table Structure—Selecting this option opens the Table Structure window

and enables you to view the columns and data types stored in a logical table.
If the table structure has changed since you added the table to the project,
you can click Update Structure to force MicroStrategy Architect to
recognize the changes.
• Update Structure—This option is a shortcut to the Update Structure

function available in the Table Structure window.
• Show Sample Data—This option enables you to view the first 100 rows of
data in a table.

Warehouse Catalog A
• Calculate Table Row Count—Selecting this option enables you to calculate

and display the row count for a table.
You can also choose to automatically calculate the row counts for all
project tables using a project-wide option in the Warehouse Catalog.
• Table Prefix—Selecting this option 0pens the Table Prefix window, which
enables you to add and remove prefixes and assign a prefix to a table.
Assigning a prefix to a table means that any time the SQL Engine uses that
table, it includes the prefix when referencing the table.
• Table Database Instances—Selecting this option opens the Available

Database Instances window, which enables you to select the primary
database instance for a table and assign secondary database instances for a
table. 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
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 Prefix—Selecting 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.

A 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:
• Catalog—The 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.

Warehouse Catalog A
• View—The 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

A Warehouse Catalog
• Schema—The 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.

Warehouse Catalog A
Adding tables with Multisource Option

You can add tables associated with secondary database instances using the
Warehouse Catalog. The following steps illustrate how you can add tables
associated with secondary database instance using the Warehouse Catalog.
To add tables from a secondary database instance to a project in the Warehouse

Catalog:
2 Open the Warehouse Catalog.
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.
© 2014 MicroStrategy Inc. Adding tables with Multisource Option 225

A Warehouse Catalog
The following image shows the Warehouse Catalog with the

FORECAST_SALES table added to the project:
FORECAST_SALES Table Added to Project
The following image shows the Warehouse Catalog with the

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.
226 Adding tables with Multisource Option © 2014 MicroStrategy Inc.

Warehouse Catalog A
To add duplicate tables to a project in the Warehouse Catalog:
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.
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.
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.
Iftable
you click the Make no changes to <Table Name> option, the
is not mapped to the selected database instance, and no
duplicate table is created.
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.

A Warehouse Catalog
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

Warehouse Catalog A
The following image shows the Warehouse Catalog with the LU_COUNTRY
table mapped to multiple data sources:
LU_COUNTRY Mapped to Multiple Data Sources
The following image shows the Warehouse Catalog with the 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.

A Warehouse Catalog
To change the primary database instance for a table in the Warehouse Catalog:
1 In Developer, 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.

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

Database Instances list.
5 To keep the current primary database instance as a secondary database

instance, in the Primary Database Instance drop-down, select a new
database instance. Then in the Secondary Database instance list, ensure the
former primary database instance is selected.
6 Click OK.

Warehouse Catalog A
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.

A Warehouse Catalog
The following image shows the Available Database Instances window with the
modified database instance configuration for the LU_COUNTRY table.
Forecast Data is now the primary database instance for the LU_COUNTRY
table, and Tutorial Data is a secondary database instance for the table.
LU_COUNTRY with Modified Database Instance Configuration

MicroStrategy Architect: Advanced Project Design Index
INDEX
A compatibility rules, data types 82

creating a fact degradation 139
adding aggregate fact tables to a
project 36 creating a fact extension using the table re-
lation method 151
adding tables with a single data source 89
creating a multisource report 104
adding tables with multiple data
sources 92 creating objects for multisource
reports 100
aggregate fact tables, using them in a
project 36 creating table-based transformations 181
aggregate-aware 36 creating the project in MicroStrategy Ar-
chitect, overview 20
Aggregation Awareness 35
application-level partitioning 202
Architect, basic schema objects 22 D
associating tables to database data mart 40
instances 88 creating 46
attributes 22 database instances 42
objects 42
B optimization 44
basic schema objects 22 options 50
updating fact 55
using in a project 54
C data type compatibility rules 82
changing logical table size 38 database instance
changing the primary database instance data mart 42
for a table 95 database instances, associating to

Index MicroStrategy Architect: Advanced Project Design
tables 88 steps 146

database instances, removing from fact extension, creating using the table re-
tables 98 lation method 151
database instances, table level 75, 76 fact extensions, methods 145
database partitioning 202 fact level 131
degradation, creating 139 fact level extensions 132
degradation, fact 133 fact level extensions, overview 131
degradation, steps 133, 137 fact level extensions, types 133
degrading fact levels 135 fact levels, degrading 135
designating primary and secondary fact levels, disallowing 156
tables 79 fact levels, extending 143
designing the logical data model, fact tables, selecting the optimal data
overview 19 source 80
different data sources, joining data 81 facts 22
disallow, fact 133 filtering qualifications, MultiSource
disallowing fact levels 156 Option 85
duplicate tables 77
H
E hierarchies 22
Engine, data type compatibility rules 82
exercises I
data mart 64
introduction to MultiSource Option 75
expression-based transformations 173
extending fact levels 143
extending fact levels, methods 145 J
extension using table relation method, joining data from different data
steps 146 sources 81
extension, creating using the table relation
method 151
extension, fact 133 L
level, fact 131
F Logical Table Editor 37

logical table size, changing 38
fact degradation 133, 135 logical table size, role in SQL
fact degradation, creating 139 generation 36
fact degradation, steps 133, 137 lookup tables, selecting the optimal data
fact disallow 133, 156 source 81
fact extension 133, 143
fact extension using table relation method,

MicroStrategy Architect: Advanced Project Design Index
M partition mapping, metadata 23, 203, 212

partition mapping, warehouse 23, 203
managing the project schema,
overview 20 partitioning 201
metadata partition mapping 203, 212 partitioning attributes 205
methods, fact extensions 145 partitioning, application-level 202
multiple data sources, joining data 81 partitioning, database-level 202
multiple data sources, tables 92 partitioning, server-level 202
MultiSource Option, filtering PBTs 205
qualifications 85 PMT 203, 205
MultiSource Option, introduction 75 primary database instances, changing for
MultiSource Option, split fact tables 83 tables 95
MultiSource Option, split lookup primary database instances, table level 75,
tables 84 76
MultiSource Option, supported use primary tables 79
cases 83 processing of SQL, multisource
multisource reports, creating 104 reports 105
multisource reports, creating objects 100 project design process, creating the project
in MicroStrategy Architect 20
multisource reports, data type compatibil-
ity rules 82 project design process, designing the logi-
cal data model 19
multisource reports, processing of
SQL 105 project design process, managing the proj-
ect schema 20
multisource reports, SQL generation 78
project, using aggregate fact tables 36
project-wide options, Warehouse
O Catalog 222
objects, multisource reports 100
optimal data source, fact tables 80 R
optimal data source, lookup tables 81 removing a database instance from a
overview, creating the project in Mi- table 98
croStrategy Architect 20
overview, designing the logical data
model 19 S
overview, managing the project schema objects 22
schema 20 schema objects, basic 22
secondary database instances, table
P level 75, 76
secondary tables 79
partition base tables 202, 205
selecting the optimal data source, fact
partition mapping 23 tables 80
partition mapping table 203, 205 selecting the optimal data source, lookup

Index MicroStrategy Architect: Advanced Project Design
tables 81 tables, single data source 89

server-level partitioning 202 transformation 171
single data source, tables 89 transformation components 176
split fact tables, MultiSource Option 83 transformation metrics 171, 181
split lookup tables, MultiSource transformation types 173
Option 84 transformations 23, 171
SQL generation, data type compatibility transformations, creating 178
rules 82 transformations, expression based 173
SQL generation, logical table size 36 transformations, table based 173
SQL generation, multisource reports 78 types of fact level extensions 133
SQL, multisource reports 105
steps, fact degradation 133, 137
steps, fact extension using table relation U
method 146 use case, filtering qualifications 85
support for duplicate tables 77 use case, split fact tables 83
supported use case, filtering use case, split lookup tables 84
qualifications 85 use cases, MultiSource Option 83
supported use case, split fact tables 83
supported use case, split lookup tables 84
supported use cases, MultiSource W
Option 83 Warehouse Catalog, project-wide
options 222
T warehouse partition mapping 203
table relation method for fact extension,

steps 146
table relation method, creating a fact
extension 151
table-based transformations 173
table-based transformations, creating 181
table-level database instances 75, 76
tables 22
tables, associating to database
instances 88
tables, changing primary database
instances 95
tables, multiple data sources 92
tables, primary 79
tables, removing database instances 98
tables, secondary 79

ADVPD 941 Mar14 Color PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ADVPD 941 Mar14 Color PDF

Încărcat de

Drepturi de autor:

Formate disponibile

MICROSTRATEGY ARCHITECT: ADVANCED PROJECT DESIGN

All Contents Copyright © 2014 MicroStrategy Incorporated. All Rights Reserved.

MicroStrategy, MicroStrategy 6, MicroStrategy 7, MicroStrategy 7i, MicroStrategy 7i Evaluation Edition,

MicroStrategy University MicroStrategy Incorporated

Preface Course Description...................................................................... 9

1. Introduction to Lesson Description ................................................................... 17

© 2014 MicroStrategy Inc. 5

2. Managing Project Lesson Description ................................................................... 27

3. Using MicroStrategy Lesson Description ................................................................... 73

6 © 2014 MicroStrategy Inc.

4. Fact Level Extensions Lesson Description ................................................................. 129

5. Transformations Lesson Description ................................................................. 169

6. Partitioning Lesson Description ................................................................. 199

© 2014 MicroStrategy Inc. 7

A. Warehouse Catalog Maintaining Individual Tables............................................... 220

Index ......................................................................................... 233

8 © 2014 MicroStrategy Inc.

This one 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

© 2014 MicroStrategy Inc. 9

Who Should Take this Course

• MicroStrategy Developer: 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 © 2014 MicroStrategy Inc.

• Describe the three types of fact level extensions available in MicroStrategy

• Create different types of transformations, use transformations in

• Describe the purpose of partitioning, explain the difference between the

© 2014 MicroStrategy Inc. Course Objectives 11

About the Course Materials

• Course—You will achieve these overall objectives by successfully

• Main Topic—You will achieve this secondary objective by successfully

12 About the Course Materials © 2014 MicroStrategy Inc.

Opportunities for Practice

Click Select Warehouse.

References to code, formulas, or calculations within paragraphs are formatted

© 2014 MicroStrategy Inc. About the Course Materials 13

Type copy c:\filename d:\foldername\filename.

References to a keyboard key or shortcut keys are in uppercase letters in bold

The aggregation level is the level of calculation for the metric.

Notes and Warnings

A note icon indicates helpful information.

14 About the Course Materials © 2014 MicroStrategy Inc.

• MicroStrategy Web Essentials

• MicroStrategy Web for Reporters and Analysts

• MicroStrategy Web for Professionals

• MicroStrategy Visual Insight Essentials

• MicroStrategy Report Services: Documents and Dashboards

• MicroStrategy Mobile for App Developers

• MicroStrategy Architect: Project Design Essentials

• MicroStrategy Developer: Reporting Essentials

• MicroStrategy Developer: Advanced Reporting

• MicroStrategy Office Essentials

© 2014 MicroStrategy Inc. About the Course Materials 15

• MicroStrategy Administration: Application Management

• MicroStrategy Engine Essentials

• MicroStrategy Architect: Advanced Project Design

• MicroStrategy Advanced Data Warehousing

• MicroStrategy Data Mining and Advanced Analytics

• MicroStrategy Developer: Advanced Reporting Case Studies

• MicroStrategy Freeform SQL Essentials