Вы находитесь на странице: 1из 244

MICROSTRATEGY ARCHITECT: ADVANCED PROJECT DESIGN

Course Guide
Version: ADVPD-901-Jan11-CG
20002011 MicroStrategy Incorporated. All rights reserved.
This Course (course and course materials) and any Software are provided as is and without express or limited
warranty of any kind by either MicroStrategy Incorporated (MicroStrategy) or anyone who has been involved in the
creation, production, or distribution of the Course or Software, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the Course
and Software is with you. Should the Course or Software prove defective, you (and not MicroStrategy or anyone else
who has been involved with the creation, production, or distribution of the Course or Software) assume the entire cost
of all necessary servicing, repair, or correction.

In no event will MicroStrategy or any other person involved with the creation, production, or distribution of the Course
or Software be liable to you on account of any claim for damage, including any lost profits, lost savings, or other
special, incidental, consequential, or exemplary damages, including but not limited to any damages assessed against or
paid by you to any third party, arising from the use, inability to use, quality, or performance of such Course and
Software, even if MicroStrategy or any such other person or entity has been advised of the possibility of such damages,
or for the claim by any other party. In addition, MicroStrategy or any other person involved in the creation, production,
or distribution of the Course and Software shall not be liable for any claim by you or any other party for damages
arising from the use, inability to use, quality, or performance of such Course and Software, based upon principles of
contract warranty, negligence, strict liability for the negligence of indemnity or contribution, the failure of any remedy
to achieve its essential purpose, or otherwise.

The Course and the Software are copyrighted and all rights are reserved by MicroStrategy. MicroStrategy reserves the
right to make periodic modifications to the Course or the Software without obligation to notify any person or entity of
such revision. Copying, duplicating, selling, or otherwise distributing any part of the Course or Software without prior
written consent of an authorized representative of MicroStrategy are prohibited.

U.S. Government Restricted Rights. It is acknowledged that the Course and Software were developed at private
expense, that no part is public domain, and that the Course and Software are Commercial Computer Software and/or
Commmercial Computer Software Documentation provided with RESTRICTED RIGHTS under Federal Acquisition
Regulations and agency supplements to them. Use, duplication, or disclosure by the U.S. Government is subject to
restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at
DFAR 252.227-7013 et. seq. or subparagraphs (c)(1) and (2) of the Commercial Computer SoftwareRestricted Rights
at FAR 52.227-19, as applicable. The Contractor is MicroStrategy, 1850 Towers Crescent Plaza, Vienna, Virginia 22182.
Rights are reserved under copyright laws of the United States with respect to unpublished portions of the Software.

Trademark Information

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


MicroStrategy 7i Olap Services, MicroStrategy 8, MicroStrategy 9, MicroStrategy Distribution Services, MicroStrategy
MultiSource Option, MicroStrategy Command Manager, MicroStrategy Enterprise Manager, MicroStrategy Object
Manager, MicroStrategy Reporting Suite, MicroStrategy Power User, MicroStrategy Analyst, MicroStrategy Consumer,
MicroStrategy Email Delivery, MicroStrategy BI Author, MicroStrategy BI Modeler, MicroStrategy Evaluation Edition,
MicroStrategy Administrator, MicroStrategy Agent, MicroStrategy Architect, MicroStrategy BI Developer Kit,
MicroStrategy Broadcast Server, MicroStrategy Broadcaster, MicroStrategy Broadcaster Server, MicroStrategy
Business Intelligence Platform, MicroStrategy Consulting, MicroStrategy CRM Applications, MicroStrategy Customer
Analyzer, MicroStrategy Desktop, MicroStrategy Desktop Analyst, MicroStrategy Desktop Designer, MicroStrategy
eCRM 7, MicroStrategy Education, MicroStrategy eTrainer, MicroStrategy Executive, MicroStrategy Infocenter,
MicroStrategy Intelligence Server, MicroStrategy Intelligence Server Universal Edition, MicroStrategy MDX Adapter,
MicroStrategy Narrowcast Server, MicroStrategy Objects, MicroStrategy OLAP Provider, MicroStrategy SDK,
MicroStrategy Support, MicroStrategy Telecaster, MicroStrategy Transactor, MicroStrategy Web, MicroStrategy Web
Business Analyzer, MicroStrategy World, Application Development and Sophisticated Analysis, Best In Business
Intelligence, Centralized Application Management, Information Like Water, Intelligence Through Every Phone,
Intelligence To Every Decision Maker, Intelligent E-Business, Personalized Intelligence Portal, Query Tone, Rapid
Application Development, MicroStrategy Intelligent Cubes, The Foundation For Intelligent E-Business, The Integrated
Business Intelligence Platform Built For The Enterprise, The Platform For Intelligent E-Business, The Scalable
Business Intelligence Platform Built For The Internet, Industrial-Strength Business Intelligence, Office Intelligence,
MicroStrategy Office, MicroStrategy Report Services, MicroStrategy Web MMT, MicroStrategy Web Services, Pixel
Perfect, Pixel-Perfect, MicroStrategy Mobile, MicroStrategy Integrity Manager and MicroStrategy Data Mining
Services are all registered trademarks or trademarks of MicroStrategy Incorporated.

All other company and product names may be trademarks of the respective companies with which they are associated.
Specifications subject to change without notice. MicroStrategy is not responsible for errors or omissions.
MicroStrategy makes no warranties or commitments concerning the availability of future products or versions that
may be planned or under development.

Patent Information

This product is patented. One or more of the following patents may apply to the product sold herein: U.S. Patent Nos.
6,154,766, 6,173,310, 6,260,050, 6,263,051, 6,269,393, 6,279,033, 6,567,796, 6,587,547, 6,606,596, 6,658,093,
6,658,432, 6,662,195, 6,671,715, 6,691,100, 6,694,316, 6,697,808, 6,704,723, 6,741,980, 6,765,997, 6,768,788,
6,772,137, 6,788,768, 6,798,867, 6,801,910, 6,820,073, 6,829,334, 6,836,537, 6,850,603, 6,859,798, 6,873,693,
6,885,734, 6,940,953, 6,964,012, 6,977,992, 6,996,568, 6,996,569, 7,003,512, 7,010,518, 7,016,480, 7,020,251,
7,039,165, 7,082,422, 7,113,993, 7,181,417, 7,127,403, 7,174,349, 7,194,457, 7,197,461, 7,228,303, 7,260,577, 7,266,181,
7,272,212, 7,302,639, 7,324,942, 7,330,847, 7,340,040, 7,356,758, 7,356,840, 7,415,438, 7,428,302, 7,430,562,
7,440,898, 7,486,780, 7,509,671, 7,516,181, 7,559,048, 7,574,376, 7,617,201, 7,725,811, 7,801,967, 7,836,178, 7,861,161
and 7,861,253. Other patent applications are pending.

How to Contact Us

MicroStrategy Education Services MicroStrategy Incorporated


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

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


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

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


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

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


Schema Lesson Objectives ................................................................. 28
Review of Database Instances .................................................... 29
Primary and Secondary Database Instances at the Project
Level ...................................................................................... 30

2011 MicroStrategy, Inc. 5


Table of Contents MicroStrategy Architect: Advanced Project Design

Maintaining Warehouse Catalog.................................................. 33


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

3. Using MicroStrategy Lesson Description ................................................................... 79


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

6 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Table of Contents

4. Fact Level Extensions Lesson Description ................................................................. 143


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

5. Transformations Lesson Description ................................................................. 191


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

6. Partitioning Lesson Description ................................................................. 221


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

2011 MicroStrategy, Inc. 7


Table of Contents MicroStrategy Architect: Advanced Project Design

Implementing Metadata Partition Mapping .......................... 234


Lesson Summary....................................................................... 237

Index ......................................................................................... 239

8 2011 MicroStrategy, Inc.


PREFACE

Course Description

This 1-day course covers advanced features involved in the


creation and maintenance of a MicroStrategy project. The
course assumes an understanding of basic report
development concepts from the 2-day MicroStrategy
Desktop: Reporting Essentials course and the 2-day
MicroStrategy Architect: Project Design Essentials course.

First, students will learn how to manage project data sources


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

After taking this course, students will understand how to


maintain MicroStrategy projects and how to build advanced
schema objects.

2011 MicroStrategy, Inc. 9


Preface MicroStrategy Architect: Advanced Project Design

Who Should Take this Course


This course is designed for:

Project architects

Course Prerequisites
Before starting this course, you should know all topics
covered in the following courses:

MicroStrategy Desktop: Reporting Essentials

MicroStrategy Architect: Project Design Essentials

You should also have a basic knowledge of SQL.

Follow-up Courses
After taking this course, you might consider taking the
following courses:

MicroStrategy Advanced Data Warehousing

Related Certifications
This course does not have any recommended follow-up
certifications.

10 Who Should Take this Course 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Preface

Course Objectives
After completing this course, you will be able to:

Describe the project design process and describe the basic


and advanced schema objects you can create with
MicroStrategy Architect. (Page 18)

Define the primary and secondary database instance, use


the Warehouse Catalog to maintain project tables,
describe how the MicroStrategy SQL Engine is aggregate
aware, and create aggregate fact tables using data
marts. (Page 28)

Describe how you can use MultiSource Option to access


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

Describe the three types of fact level extensions available


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

Create different types of transformations, use


transformations in transformation metrics, and describe
common uses for transformations in
reporting. (Page 192)

Describe the purpose of partitioning, explain the


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

2011 MicroStrategy, Inc. Course Objectives 11


Preface MicroStrategy Architect: Advanced Project Design

About the Course Materials


This course is organized into lessons and reference
appendices. Each lesson focuses on major concepts and skills
that help you to better understand MicroStrategy products
and use them to implement MicroStrategy projects. The
appendices provide you with supplemental information to
enhance your knowledge of MicroStrategy products.

Content Descriptions
Each major section of this course begins with a Description
heading. The Description introduces you to the content
contained in that section.

Learning Objectives
Learning objectives enable you to focus on the key knowledge
and skills you should obtain by successfully completing this
course. Objectives are provided for you at the following three
levels:

CourseYou will achieve these overall objectives by


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

Main TopicYou will achieve this secondary objective by


successfully completing the main topic. The topic
objective is stated at the beginning of the topic text. You
can find a list of all the topic objectives in each lesson
under the Lesson Objectives heading at the beginning of
each lesson.

12 About the Course Materials 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Preface

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

Opportunities for Practice


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

The following sections within lessons provide you with


opportunities to reinforce important concepts, practice new
product and project skills, and monitor your own progress in
achieving the lesson and course objectives:

Review

Case Study

Business Scenario
Exercises

Typographical Standards
Following are explanations of the font style changes, icons,
and different types of notes that you see in this course.

Actions

References to screen elements and keys that are the focus of


actions are in bold Arial font style. The following example
shows this style:

Click Select Warehouse.

2011 MicroStrategy, Inc. About the Course Materials 13


Preface MicroStrategy Architect: Advanced Project Design

Code

References to code, formulas, or calculations within


paragraphs are formatted in regular Courier.New font style.
The following example shows this style:

Sum(Sales)/Number of Months

Data Entry

References to literal data you must type in an exercise or


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

Keyboard Keys

References to a keyboard key or shortcut keys are in


uppercase letters in bold Arial font style. The following
example shows this style:

Press CTRL+B.

New Terms

New terms to note are in regular italic font style. These terms
are defined when they are first encountered in the course.
The following example shows this style:

The aggregation level is the level of calculation for the


metric.

14 About the Course Materials 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Preface

Notes and Warnings

A note icon indicates helpful information.


Ainformation
warning icon calls your attention to very important
that you should read before continuing
the course.

Heading Icons

The following heading icons are used to indicate specific


practice and review sections:

Precedes a Review section

Precedes a Case Study

Precedes a Business Scenario

Precedes Exercises

2011 MicroStrategy, Inc. About the Course Materials 15


Preface MicroStrategy Architect: Advanced Project Design

MicroStrategy Courses

Core Courses
Implementing MicroStrategy: Development and
Deployment

MicroStrategy Administration

MicroStrategy Architect: Project Design Essentials

MicroStrategy Desktop: Advanced Reporting

MicroStrategy Desktop: Reporting Essentials

MicroStrategy Report Services: Document Essentials

MicroStrategy Report Services: Dynamic Dashboards

MicroStrategy Web for Professionals

MicroStrategy Web for Reporters and Analysts

All courses are subject to change. Please visit the MicroStrategy Web site for the lat-
est education offerings.

16 About the Course Materials 2011 MicroStrategy, Inc.


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.

2011 MicroStrategy, Inc. 17


1 Introduction to Advanced Project Design MicroStrategy Architect: Advanced Project Design

Lesson Objectives

After completing this lesson, you will be able to:


Describe the project design process and describe the basic
and advanced schema objects you can create with
MicroStrategy Architect.

After completing the topics in this lesson, you will be able to:

Describe the project design process and learn about the


tools and components that enable you to manage the
project schema. (Page 19)

Describe the basic schema objects that you can create in


MicroStrategy Architect and learn about additional
schema objects that enable you to perform advanced
functions. (Page 22)

18 Lesson Objectives 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Introduction to Advanced Project Design 1

Review of the Project Design Process

After completing this topic, you will be able to:


Describe the project design process and learn about the tools
and components that enable you to manage the project
schema.

In the MicroStrategy Architect: Project Design Essentials


course, you learned about the primary steps involved in the
project design process:
Project Design Process

Recall that project design involves more than just creating a


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

2011 MicroStrategy, Inc. Review of the Project Design Process 19


1 Introduction to Advanced Project Design MicroStrategy Architect: Advanced Project Design

Designing the Logical Data Model

When you design the logical data model, you need to


determine the information that users want to see in reports
and determine what information is actually available in the
source systems. Finally, you design the model that
incorporates both.

Designing the Data Warehouse Schema

When you design the data warehouse schema, you need to


first consider the advantages and disadvantages of various
structures for storing data in the data warehouse. You then
determine the optimal schema design that balances the
reporting requirements, performance requirements, and
maintenance overhead. Finally, you create the data
warehouse using this schema design or modify the existing
data warehouse to use this schema design.

Creating the Project in MicroStrategy Architect

You need to have a solid design for the logical data model and
data warehouse schema before you move on to creating the
actual project. Both of these components can directly affect
how you query data in a project, what data you can query,
how fast queries run, and so forth.

Managing the Project Schema

Managing the project schema is the final and ongoing step in


the project design process. Over the life of the project, your
logical data model or data warehouse may change, or your
reporting needs may change, which can necessitate changes
to schema objects.

20 Review of the Project Design Process 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Introduction to Advanced Project Design 1

In the MicroStrategy Architect: Advanced Project Design


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

Primary and secondary database instancesA database


instance is a logical object in the MicroStrategy metadata
that typically represents a connection to a data
warehouse. Each project must have a primary database
instance. You can associate any number of secondary
database instancesdata sourcesto a project.

Warehouse CatalogThe Warehouse Catalog enables you


to maintain the integrity of the logical tables with the data
warehouse structure by providing a variety of options that
apply to the project tables on an individual basis.

Aggregation awarenessMicroStrategy Architect assigns


each table a logical table size and uses it to query the
aggregate table rather than the base fact table in cases
where either table could provide the answer.

Data martsA data mart is a relational table containing


results of a report. Among other applications, you can use
data marts to create aggregate fact tables.

Multisource report executionBy default, the objects in a


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

2011 MicroStrategy, Inc. Review of the Project Design Process 21


1 Introduction to Advanced Project Design MicroStrategy Architect: Advanced Project Design

Review of Schema Objects

After completing this topic, you will be able to:


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:

TablesLogical objects that correspond to physical tables


stored in the data warehouse that you want to use in a
MicroStrategy project

FactsLogical objects that relate aggregatable data stored


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

AttributesLogical objects that relate descriptive


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

HierarchiesLogical objects that enable you to group


attributes to reflect their relationships or provide
convenient browsing and drilling paths in the
MicroStrategy reporting environment.

22 Review of Schema Objects 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Introduction to Advanced Project Design 1

The following illustration shows an example of each of these


types of schema objects:
Basic Schema Objects

In the MicroStrategy Architect: Advanced Project Design


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

You can also create other types of schema objects in


MicroStrategy Architect that you use for more advanced
functions:

TransformationsLogical objects most often used to


compare values at different timesfor example, this year
versus last year and today versus month to date.
Transformations are useful for discovering and analyzing
time-based trends in your data.

Partition mappingsPartitioning is the division of a


larger table into smaller tables in the data warehouse. You
can bring partitioned tables into a MicroStrategy project
through warehouse partition mapping or metadata
partition mapping.

2011 MicroStrategy, Inc. Review of Schema Objects 23


1 Introduction to Advanced Project Design MicroStrategy Architect: Advanced Project Design

The following illustration shows an example of each of these


types of schema objects. You will learn about these objects
later in the course:
Additional Schema Objects

24 Review of Schema Objects 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Introduction to Advanced Project Design 1


Lesson Summary
In this lesson, you learned:

The project design process involves the following steps:


designing the logical data model, designing the data
warehouse schema, creating the project in MicroStrategy
Architect, and managing the project schema.

As part of managing the project schema, you will learn


how to define primary and secondary database instances,
use the Warehouse Catalog, understand
aggregation-awareness, create data marts, and enable
multisource report execution.

The following basic schema objects form the foundation of


a MicroStrategy project: tables, facts, attributes, and
hierarchies.

You can also create other types of schema objects in


MicroStrategy Architectsuch as transformations and
partition mappingsthat you use for more advanced
functions.

2011 MicroStrategy, Inc. Lesson Summary 25


1 Introduction to Advanced Project Design MicroStrategy Architect: Advanced Project Design

26 Lesson Summary 2011 MicroStrategy, Inc.


2
MANAGING PROJECT SCHEMA

Lesson Description

This lesson covers a variety of advanced topics that enable


you to maintain a MicroStrategy project as it changes over
time and help you optimize performance within your project.

In this lesson, you will review the concept of primary and


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

2011 MicroStrategy, Inc. 27


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

Lesson Objectives

After completing this lesson, you will be able to:


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

After completing the topics in this lesson, you will be able to:

Describe the primary and secondary database instances


and their use in MicroStrategy project. (Page 29)

Describe how the Warehouse Catalog options in


MicroStrategy Architect can help you maintain a project
over time. (Page 33)

Describe how MicroStrategy Architect calculates logical


table size, and how the SQL Engine uses logical table size
to select the optimal table for a query. (Page 39)

Define a data mart, and list and define data mart objects;
create a data mart table by creating and executing a data
mart report; list and define data mart column creation
options; use a data mart table in a project. (Page 46)

28 Lesson Objectives 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

Review of Database Instances

After completing this topic, you will be able to:


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.

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

Although a project uses a single primary database instance to


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

Tohavecreate and configure database instances, you must


the appropriate administrative privileges.

For more information about Freeform SQL reports,


refer to the MicroStrategy Freeform SQL Essentials
course.

You also create and configure a database instance to


connect to an MDX data source. For more information
on MDX reports, refer to the MicroStrategy MDX
Cube Reporting Guide product manual.

2011 MicroStrategy, Inc. Review of Database Instances 29


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

Primary and Secondary Database Instances at the Project Level


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

Each MicroStrategy project must have a primary database


instance. However, you can associate any number of
secondary database instances with a single project.

If you want to use a secondary database instance in a project


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

You can also associate a secondary database instance


with a project automatically, when you add a table
from the secondary database instance to a project
using MultiSource Option. You will learn about
MultiSource Option later in this course.

To associate a secondary database instance with a project:

1 In MicroStrategy Desktop, log in to the project source that


contains your project.

2 Using the Database Instances manager, create the


database instance that points to the secondary data
source.

Tothelearn how to create database instances, refer to


MicroStrategy Architect: Project Design
Essentials or MicroStrategy Administration:
Configuration and Security courses.

3 Right-click the project name and select Project


Configuration.

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


expand the Database instances category.

30 Review of Database Instances 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

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


and non-primary warehouse database instances list, select
the database instance that you want to associate to the
project.

You can also create new database instance by


clicking New.

6 In the message window, click No.

This window asks you if you want to configure the


data mart optimization for the database instance.
You do not have to configure data mart
optimization if you do not plan to use that database
instance to create data marts. For information on
database optimization, see Data Mart
Optimization starting on page 50.

7 Click OK to close Project Configuration Editor.

The following image shows the Project Configuration Editor


with a single primary database instance and multiple
secondary database instances associated with the
MicroStrategy Tutorial project:
Primary and Secondary Database Instances

2011 MicroStrategy, Inc. Review of Database Instances 31


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

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


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

32 Review of Database Instances 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

Maintaining Warehouse Catalog

After completing this topic, you will be able to:


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

In the MicroStrategy Architect: Project Design Essentials


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

MicroStrategy also has a variety of administration


functionality designed to help you with project
maintenance. For more information, see the
MicroStrategy Administration: Application
Management and Tuning course.

You already learned how to use the Warehouse Catalog to


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

Maintaining Individual Tables


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

2011 MicroStrategy, Inc. Maintaining Warehouse Catalog 33


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

The Warehouse Catalog enables you to maintain the integrity


of the logical tables with the data warehouse structure by
providing a variety of options that apply to the project tables
on an individual basis. You access these options in the
Warehouse Catalog by right-clicking any table you have
added to a project. The following image displays these
individual table options:
Individual Table Options

The Warehouse Catalog provides the following options for


individual tables:

RemoveThis option enables you to remove a table from


the project.

Table StructureSelecting this option opens the Table


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

Update StructureThis option is a shortcut to the


Update Structure function available in the Table Structure
window.

34 Maintaining Warehouse Catalog 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

Show Sample DataThis option enables you to view the


first 100 rows of data in a table.

Calculate Table Row CountSelecting this option


enables you to calculate and display the row count for a
table.

You can also choose to automatically calculate the


row counts for all project tables using a
project-wide option in the Warehouse Catalog.

Table PrefixSelecting this option 0pens the Table Prefix


window, which enables you to add and remove prefixes
and assign a prefix to a table. Assigning a prefix to a table
means that any time the SQL Engine uses that table, it
includes the prefix when referencing the table.

Table Database InstancesSelecting this option opens


the Available Database Instances window, which enables
you to select the primary database instance for a table and
assign secondary database instances for a table. This
option enables you to choose additional database
instances in which you want to search for the table if you
cannot obtain it from the primary database instance.

The primary database instance is the database


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

Import PrefixSelecting this option enables you to


retrieve a prefix for a table.

There are no table prefixes for the MicroStrategy


Tutorial data warehouse.

You can also choose to automatically display the


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

2011 MicroStrategy, Inc. Maintaining Warehouse Catalog 35


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

Project-Wide Warehouse Catalog Options


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

These project-wide options are separated into a series of the


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

The Warehouse Connection subcategory of the


Catalog category is displayed in the image above.

36 Maintaining Warehouse Catalog 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

ViewThe options in this category enable you to specify


table viewing options, such as displaying table prefixes,
row counts, and name spaces by default.

The following image shows the Table Prefixes subcategory


in the View category:
View Category in the Warehouse Catalog

2011 MicroStrategy, Inc. Maintaining Warehouse Catalog 37


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

SchemaThe options in this category enable you to


configure the automatic mapping of schema objects to the
tables brought into the Warehouse Catalog and the
calculation of logical table sizes.

The following image shows the Automatic Mapping


subcategory in the Schema category:
Schema Category in the Warehouse Catalog

As you can see, the Warehouse Catalog has a host of options


that provide flexibility in maintaining your project over time.

For detailed information on the Warehouse Catalog


options, refer to the Project Design Guide product
manual.

38 Maintaining Warehouse Catalog 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

Aggregation Awareness

After completing this topic, you will be able to:


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


In the MicroStrategy Architect: Project Design Essentials
course, you learned that there are two types of fact tables that
you typically have in a data warehouse. Base fact tables are
tables that store a fact or set of facts at the lowest possible
level of detail. Aggregate fact tables are tables that store a
fact or set of facts at a higher, or summarized, level of detail.

For example, consider the following two fact tables:


Base and Aggregate Fact Tables

The FACT_SALES table stores dollar and unit sales data at


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

2011 MicroStrategy, Inc. Aggregation Awareness 39


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

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


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

In a data warehouse, you often have multiple aggregate fact


tables for the same fact or set of facts to enable you to more
quickly analyze fact data at various levels of detail.

For guidelines on building aggregate fact tables, refer


to the MicroStrategy Advanced Data Warehousing
course.

Using Aggregate Tables in a Project

There are two actions that you need to perform to integrate


an aggregate fact table into an existing project:

1 Add the table to the project using the Warehouse Catalog.

2 If necessary, map the existing attributes and facts to the


aggregate table.

If your aggregate fact table structure is consistent with your


base fact table structure, MicroStrategy Architect is
intelligent enough to automatically add the table to the
definitions of your existing attributes and facts. However, if
your aggregate fact table structure contains new columns that
have not been mapped to existing attribute form expressions
and fact expressions, you have to manually map the new table
to the desired attributes and facts.

Iffactthetable,
aggregate fact table structure matches the base
MicroStrategy Architect can automatically
map the new table to existing attributes and facts as
long as automatic mapping is used for the
corresponding attribute form expressions and fact
expressions.

40 Aggregation Awareness 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

How Is MicroStrategy Aggregate-Aware?


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

MicroStrategy Architect assigns a size to every table in a


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

The following illustration is a visual representation of the


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

2011 MicroStrategy, Inc. Aggregation Awareness 41


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

Logical table size is the sum of the weight for each attribute
contained in the table. Attribute weight is defined as the
position of an attribute in its hierarchy divided by the number
of attributes in the hierarchy multiplied by a factor of 10.
Therefore, using this formula, MicroStrategy Architect
calculates the respective weight of each attribute as shown in
the illustration above. Then, the logical table size of each fact
table is simply the sum of their respective attribute weights.

You can view the logical table size for each table in the Logical
Table Editor. When the SQL Engine can obtain data from two
or more tables in the warehouse, it looks at the logical table
size and generates SQL against the table with the smallest
logical table size. This process helps the SQL Engine select
the optimal table for a query.

Changing the Logical Table Size

At times, you may need to reassign the logical table size for a
table. For example, in the previous illustration for logical
table sizes, there are two aggregate fact tables that both have
the same logical table size of 15. However, one of these tables
contains item and region information, and the other one has
class and store information. Clearly, based on the attributes
they contain, the table with item and region information is
larger. There are many more items than classes to which
items belong. In this example, where the logical table size is
the same but the physical size is actually very different, you
can change the logical table size automatically assigned by
MicroStrategy Architect.

Generally, smaller logical size does equate to smaller physical


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

42 Aggregation Awareness 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

To change the logical table size for a table:

1 In MicroStrategy Desktop, in the Schema Objects folder,


in the Tables folder, double-click the table you want to
modify.

2 In the Table Editor, on the Logical View tab, in the Logical


size box, type the new value that you want to assign for the
logical size.

3 Select the Preserve this logical size when updating


Schema information (Lock Logical Table Size) check
box.

You should select this option if you want to ensure


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

4 Click Save and Close.

5 Update the project schema.

2011 MicroStrategy, Inc. Aggregation Awareness 43


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

The following image shows the Table Editor for the


CITY_CTR_SLS fact table with the logical size set to 15:
Changing Logical Size in the Table Editor

Using the Table Editor, you can change the logical size for an
individual table. This procedure works fine if you are
changing the logical size of just a few tables. However, it is
tedious if you have to change the logical size for a number of
tables. Alternatively, you can use the Logical Size Editor. This
editor provides a single interface for you to change the logical
size of any table in a project.

To change logical table sizes using the Logical Size Editor:

1 In MicroStrategy Desktop, on the Schema menu, select


Edit Logical Size.

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


modify, in the Size value box, type the new value you want
to assign for the logical size.

3 If you want to preserve the logical table size, select the


Size locked check box for the table.

4 Repeat steps 2 to 3 for each table that you want to modify.

44 Aggregation Awareness 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

5 When you have changed the logical sizes for all the
desired tables, on the File menu, select Save.

6 On the File menu, select Close.

7 Update the project schema.

The following image shows the Logical Size Editor:


Changing Logical Size in the Logical Size Editor

2011 MicroStrategy, Inc. Aggregation Awareness 45


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

Data Marts

After completing this topic, you will be able to:


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

What Is a Data Mart?


A data mart is a relational table containing results of a
report. You create the data mart report in MicroStrategy
Desktop and you save the data mart table in a warehouse of
your choice. After you create a data mart table, you can add it
to a project and then use it as a source table from which to
execute reports.

Some common applications for data marts are:

Creating aggregate fact tables

Creating tables for very large result sets and then using
other applications such as Microsoft Excel or Microsoft
Access to access the data

Creating tables for off-line analysis

In this lesson, you will use data marts to create aggregate fact
tables.

46 Data Marts 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

For example, consider the following scenario:


Base Fact Table

In this example, forecasting data is stored at the employee


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

2011 MicroStrategy, Inc. Data Marts 47


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

What if you could create an aggregate table that limits the


number of joins and the number of rows in the fact table? You
can achieve this with a data mart. You can then bring this
table into your project, map the forecast unit sales to it, and
have your region-level reports automatically use it, as shown
below:
Aggregate Fact Table Created as Data Mart

Data Mart Objects

Creating data marts involves creating two objects:

Data mart reportThis is a metadata object that you


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

Data mart tableThis is the relational table created after


the execution of a data mart report.

Data Mart Database Instances

When you create a data mart report, you must specify a


database instance in which to create the data mart table.

You create a data mart in a database instance in one of the


following ways:

Option 1Use the projects primary database instance.

48 Data Marts 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

Option 2Use a secondary project database instance that


exists in the same warehouse as the primary project
database instance.

Option 3Use a different database instance than the


project, and one that is in a different warehouse than the
primary project database instance.

The following figure illustrates each of these data mart


database instance options:
Data Mart Database Instance Options

If you use the primary project database instance, then you do


not need to take any additional steps to create a data mart.
You simply select the primary data mart database instance as
a target when you create the data mart report.

For more details on how to create data marts, see


Creating Data Marts starting on page 53.

2011 MicroStrategy, Inc. Data Marts 49


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

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.

50 Data Marts 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

To optimize a database instance:

1 In the Database Instances editor, on the Advanced tab,


under Data mart optimization, select the This database
instance is located in the same warehouse as check
box.

Ifinthe data mart database instance does not reside


the same warehouse as the project database
instance, do not select this check box.

2 In the list of database instances, select the primary project


database instance.

3 Click OK.

The following image shows the data mart optimization option


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

2011 MicroStrategy, Inc. Data Marts 51


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

Why Optimize?

When you create a data mart using the primary project


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

The following table displays sample SQL generated when


creating a data mart using a database instance in the same
data warehouse as the primary project database instance, and
when using a different data warehouse:
Sample SQL

Same Data Warehouse Different Data Warehouse

drop table Same_ Datamart _Instance select a11.Month_Id Month_Id,


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

insert into Different_ Datamart _Instance


values 201001, 'Jan 2010', 8817)

When you create the data mart in the same data warehouse,
MicroStrategy Intelligence Server creates the data mart table
in the project warehouse and then inserts the result data rows
directly into the table.

When you create the data mart in a different data warehouse,


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

52 Data Marts 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

Creating Data Marts


In MicroStrategy Desktop, you create a data mart report by
converting an existing report or by creating a new report.

To create a data mart:

1 In the Report Editor, on the Data menu, select Configure


Data Mart.

The report template must contain an attribute, a


metric, or some other object for this option to be
enabled.

2 In the Report Data Mart Setup window, on the General


tab, in the Data mart database instance drop-down list,
select the database instance in which you want to create
the data mart table.

3 In the Table name box, type the name of the data mart
table you want to create.

The table name you type is not validated by the


system at this point.

By default, the This table name contains placeholders


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

The following table lists placeholders available for naming


data mart tables.
Data Mart Placeholders

Placeholder Replacement Option

!U user name

!D date on which table was created

!O report name

??? temporary table name

!!! all column names

!a attribute column names

2011 MicroStrategy, Inc. Data Marts 53


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

Data Mart Placeholders

Placeholder Replacement Option

!j job ID

!r report GUID
!t timestamp

!p project name

!z project GUID

!s user session GUID

4 Select one of the following options:

Create a new table

Append to existing tableThis option enables you to


add the data mart report results to an existing table.
The name specified in the Table name box must be the
name of the existing table you want to append.

5 On the Advanced tab, specify data mart governors and


table creation properties.

6 On the SQL Statements tab, specify SQL statements that


can be inserted before and after the table is created or
before data is inserted in the table.

For information on the data mart governors, table


creation properties, and SQL statements refer to
the Advanced Reporting Guide product manual.

7 Click OK to close the Report Data Mart Setup window.

You may see a warning that data mart tables created in


common table spaces may overwrite someone elses
data mart table. If you want to proceed, click OK.

8 Save the report.

9 Execute the data mart report to create the data mart table.

54 Data Marts 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

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

2011 MicroStrategy, Inc. Data Marts 55


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

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.

56 Data Marts 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

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.

2011 MicroStrategy, Inc. Data Marts 57


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

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

58 Data Marts 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

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

2011 MicroStrategy, Inc. Data Marts 59


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

4 Click OK to close the Metric Column Alias Options


window.

5 Save and close the metric.

The following image shows a custom Total_Unit_Sales


column alias for the Forecast Units Sold metric:
Metric Column Alias Options Window

Using the same example, after you change the column alias
for the Forecast Revenue metric, and then execute the data
mart report, the data mart table contains the following
columns:

REGION_ID

YEAR_ID

Total_Unit_Sales

Using Data Marts in a Project


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

To use a data mart table as a source table in the project in


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

60 Data Marts 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

Updating Warehouse Catalog

To update the warehouse catalog:

1 In MicroStrategy Desktop, on the Schema menu, select


Warehouse Catalog.

2 In the Warehouse Catalog editor, in the Tables available


in the database instance list, select the data mart table and
click the upper > button.

3 On the toolbar, click Save and Close.

The following image shows the


REGION_YEAR_FORECAST_UNIT_SALES table added to
the projects warehouse catalog:
REGION_YEAR_FORECAST_UNIT_SALES Added to the
Project

Updating the Fact

To use the data mart table as a source table from which to


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

2011 MicroStrategy, Inc. Data Marts 61


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

To update the fact expression:

1 In MicroStrategy Desktop, edit the metric used in the data


mart table in the Metric Editor.

2 In the Metric Editor, determine the fact on which the


metric is based.

The relationship of the metric to the fact on which


it is based is referred to as a child dependency. You
can use MicroStrategy Object Manager to quickly
locate child dependencies for the metric.

3 In the Schema Objects folder, in the Facts folder, open the


fact on which the data mart metric is based.

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


the data mart table as a source table.

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

5 Save and close the fact.

62 Data Marts 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

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.

2011 MicroStrategy, Inc. Data Marts 63


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design


Exercises: Managing Project Schema

Create an Aggregate Table Using Data Mart

Forecasting Project Information

You should complete the following exercises using the


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

You will also use the Forecasting Project to complete


other exercises throughout this course.

The Forecasting Project is based on the following logical data


model:
Forecasting Project Logical Data Model

64 Exercises: Managing Project Schema 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

The Forecasting Project consists of several attributes in the


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

The attributes in the Time hierarchy are the following:


Attributes in the Time Hierarchy

The attributes in the Geography hierarchy are the following:


Attributes in the Geography Hierarchy

2011 MicroStrategy, Inc. Exercises: Managing Project Schema 65


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

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.

66 Exercises: Managing Project Schema 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

Overview

In this exercise, you will first create a


REGION_FORECAST_SALES aggregate table using the data
mart feature in the Forecasting Project. You will then bring
this table to the project and test how the Engine selects the
fact table based on the logical table size.

Later in the course, you will also bring this data mart
table into the MicroStrategy Tutorial project using
MultiSource option.

Before you create a data mart, you will first modify the
Forecast Revenue metric to use a custom Forecast_Revenue
column alias. You will then create a data mart report with
Region ID and Quarter ID attribute forms on the template
and the Forecast Revenue metric. Name the data mart table
REGION_FORECAST_SALES. Save the data mart report as
Regional Forecast Revenue in the Public Objects\Reports
folder.

Next, you will add the table to the Forecasting Project. Then,
you will create a new fact expression for the Forecast Revenue
fact that uses the Forecast_Revenue column in the
REGION_FORECAST_SALES table. You will also create
and run a Data Mart Test report with the Region attribute
and the Forecast Revenue metric on the template to
confirm that the Forecast Revenue fact uses the
REGION_FORECAST_SALES table.

Finally, you will change the logical table size for the
REGION_FORECAST_SALES table to 30 and run the Data
Mart Test report to view the impact of your change on the
report SQL.

You can use the detailed instructions if you want help.

Detailed Instructions

Modify metric alias

1 In MicroStrategy Desktop, log in to the MicroStrategy


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

2011 MicroStrategy, Inc. Exercises: Managing Project Schema 67


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

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.

7 Save and close the metric.

Create the Data Mart report

8 In the Public Objects folder, in the Reports folder, create


the following report:

You can access the Region attribute from the


Geography hierarchy. You can access the Quarter
attribute from the Time hierarchy. The Forecast
Revenue metric is located in the Metrics folder.

Configure attribute display options

9 In the Report Editor, on the Data menu, select Attribute


Display.

10 In the Attribute Display window, in the Attribute


drop-down list, ensure that Region is selected.

11 Under Select one of the display options below, click Use


the following attribute forms.

12 In the Available forms list, select the ID form.

68 Exercises: Managing Project Schema 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

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


Displayed forms list.

14 In the Displayed forms list, select the DESC form.

15 Click the upper < button to remove the DESC form from
the Displayed forms list.

16 In the Report objects forms list, select the DESC form.

17 Click the lower < button to remove the DESC form from
the Report objects forms list.

18 In the Attribute Display window, in the Attribute


drop-down list, select Quarter.

19 Under Select one of the display options below, click Use


the following attribute forms.

20 In the Available forms list, select the ID form.

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


Displayed forms list.

22 In the Displayed forms list, select the DESC form.

23 Click the upper < button to remove the DESC form from
the Displayed forms list.

24 In the Report objects forms list, select the DESC form.

25 Click the lower < button to remove the DESC form from
the Report objects forms list.

26 Click OK.

Configure the data mart

27 In the Report Editor, on the Data menu, select Configure


Data Mart.

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


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

2011 MicroStrategy, Inc. Exercises: Managing Project Schema 69


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

29 In the Table name box, type


REGION_FORECAST_SALES.

30 Click OK.

Configure the data mart

31 Run the report.

After the report executes, you see a message that the


result data has been stored in the
REGION_FORECAST_SALES table, as shown below:

32 Save the report in the Public Objects\Reports folder as


Regional Forecast Revenue and close the report.

Incorporate the data mart table into the project

33 In MicroStrategy Desktop, on the Schema menu, select


Warehouse Catalog.

34 In the Warehouse Catalog editor, in the Tables available


in the database instance list, double-click the
REGION_FORECAST_SALES table to include it into the
project.

35 On the toolbar, click Save and Close.

Update the Forecast Revenue fact

36 In the Schema Objects folder, in the Facts folder,


double-click the Forecast Revenue fact.

70 Exercises: Managing Project Schema 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

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


the Forecast_Revenue column in the
REGION_FORECAST_SALES table as a source table.

38 Use the Automatic mapping method and ensure that the


aggregate table is selected as the source table.

39 Save and close the fact.

Update the project schema

40 Update the project schema.

Ensure that the Recalculate Logical Table Size


checkbox is selected in the Schema Update
window.

Test the new fact mapping

41 In the Public Objects\Reports folder, create the following


report:

You can access the Region attribute from the


Geography hierarchy. The Forecast Revenue metric
is located in the Metrics folder.

42 Run the report. The result set should look like the
following:

2011 MicroStrategy, Inc. Exercises: Managing Project Schema 71


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

43 Switch to the SQL View for the report. The SQL should
look like the following:

In the FROM clause, notice that the data is retrieved from


the new aggregate REGION_FORECAST_SALES table.

44 Save the report in the Reports folder as Data Mart Test


and close the report.

Change the logical table size for the aggregate table

45 In MicroStrategy Desktop, on the Schema menu, select


Edit Logical Size.

Notice that the REGION_FORECAST_SALES tables


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

46 In the Logical Size Editor, for the


REGION_FORECAST_SALES table, in the Size value
box, type 30.

47 For the REGION_FORECAST_SALES table, select the


Size locked check box.

When you select this check box, when you update the
schema, the logical size for this table will not be
recalculated.

48 On the File menu, select Save.

49 On the File menu, select Close.

72 Exercises: Managing Project Schema 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

Update the project schema.

50 Update the project schema.

Ensure that the Recalculate Logical Table Size


checkbox is selected in the Schema Update
window.

Test the change of the logical table size on the report SQL

51 In the Reports folder, right-click the Data Mart Test


report and select View SQL. The SQL should look like the
following:

Notice that this time, the Engine picked the base


FORECAST_SALES table over the aggregate
REGION_FORECAST_SALES table because it has a
smaller logical table size.

52 Close the report without saving it.

Modify a Warehouse Table

Overview

In this exercise, you will modify a lookup table for the


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

2011 MicroStrategy, Inc. Exercises: Managing Project Schema 73


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

The TUTORIAL_DATA_7200.mdb data warehouse is


located in the C:\Program
Files\MicroStrategy\Tutorial Reporting folder.

You will use the Number data type and type the following
values in the PRODUCT_ID column:

Finally, you will update the structure of the LU_CATEGORY


table using the Warehouse Catalog in the MicroStrategy
Tutorial project.

You can use the detailed instructions if you want help.

Detailed Instructions

Modify the lookup table to include the PRODUCT_ID


column in the LU_CATEGORY table

1 Open Windows Explorer and navigate to the C:\Program


Files\MicroStrategy\Tutorial Reporting folder.

2 In the Tutorial Reporting folder, double-click


TUTORIAL_DATA_7200.mdb.

This file is the out-of-the-box data warehouse


database for the MicroStrategy Tutorial project.

The instructions in this exercise are for Microsoft


Access 2007.

3 In Microsoft Access, in the TUTORIAL_DATA_7200:


Database window, in the Tables list, double-click the
LU_CATEGORY table.

4 Right-click the Category_ID column header and select


Insert Column.

74 Exercises: Managing Project Schema 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2

This action inserts a new column named Field1.


5 Double-click the Field1 column header.

6 Type PRODUCT_ID as the column name.

7 Press ENTER.

8 Type the following values in the Product_ID column:

9 Click Save.

10 On the toolbar, click View.

11 In the LU_CATEGORY table, next to PRODUCT_ID, in


the Data Type drop-down list, select Number.

12 Click Save.

13 In the warning window, click Yes.

14 Close the table.

15 Close Microsoft Access.

Update the LU_CATEGORY table structure

16 In MicroStrategy Desktop, in the MicroStrategy Analytics


Modules project source, open the MicroStrategy Tutorial
project.

2011 MicroStrategy, Inc. Exercises: Managing Project Schema 75


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

17 Open the Warehouse Catalog.

18 In the Tables being used in the project list, right-click the


LU_CATEGORY table and select Update Structure.

19 To confirm that the structure has been updated,


right-click the LU_CATEGORY table and select Table
Structure.

In the Table Structure window, you should see the


PRODUCT_ID column.

20 In the Table Structure window, click Close.

21 Save and close the Warehouse Catalog.

Update the project schema

22 Update the project schema.

76 Exercises: Managing Project Schema 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Managing Project Schema 2


Lesson Summary
In this lesson, you learned:

The database instance you select during the project


creation process becomes this projects primary database
instance.

You can associate any number of secondary database


instances with a single project. You use secondary
database instances to create data marts, Freeform SQL,
Query Builder, and MDX reports. You associate secondary
database instances with a project using the Project
Configuration Editor.

The Warehouse Catalog enables you to maintain the


integrity of the logical tables with the data warehouse
structure by providing a variety of options that apply to
the project tables on an individual basis.

Base fact tables are tables that store a fact or set of facts at
the lowest possible level of detail. Aggregate fact tables are
tables that store a fact or set of facts at a higher, or
summarized, level of detail.

To use aggregate tables in the project, you first add the


table to the project using the Warehouse Catalog. If
necessary, you also map the existing attributes and facts
to the aggregate table.

MicroStrategy Architect assigns a logical table size to


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

Logical table size is the sum of the weight for each


attribute contained in the table. Attribute weight is
defined as the position of an attribute in its hierarchy
divided by the number of attributes in the hierarchy
multiplied by a factor of 10.

You can change the logical table size either in the Logical
Table Editor or in the Logical Size Editor.

2011 MicroStrategy, Inc. Lesson Summary 77


2 Managing Project Schema MicroStrategy Architect: Advanced Project Design

A data mart is a relational table containing a report result


set. A data mart consists of two objects: the data mart
report and the data mart table.

You can use data marts to create aggregate tables and


tables based on large report result sets.

Data mart reports are created in the Report Editor of a


new or existing report. After you execute the data mart
report, the data mart table is created.

You can choose to create only attribute ID columns in the


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

To use a data mart table in a project, you must add it to


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

78 Lesson Summary 2011 MicroStrategy, Inc.


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.

2011 MicroStrategy, Inc. 79


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Lesson Objectives

After completing this lesson, you will be able to:


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.

After completing the topics in this lesson, you will be able to:

Describe how you can use MultiSource Option to access


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

Associate tables with single or multiple data sources,


change the primary database instance for a table, and
remove a database instance from a table. (Page 96)

Create objects for use in multisource reports. (Page 115)

Create a report that contains objects from multiple data


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

80 Lesson Objectives 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

Introduction to MicroStrategy MultiSource


Option

After completing this topic, you will be able to:


Describe how you can use MultiSource Option to access
heterogeneous data sources, including support for duplicate
tables, SQL generation for reports with multiple data sources,
and common use cases.

By default, the objects in a standard report have to come from


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

For example, consider the following scenario in which actual


revenue data is stored in one data warehouse, while forecast
revenue data is stored in a second data warehouse:
Report with Objects from Multiple Data Sources

2011 MicroStrategy, Inc. Introduction to MicroStrategy MultiSource Option 81


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

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


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

Primary and Secondary Database Instances at the Table Level


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

Without MultiSource Option, you can use secondary


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

With MultiSource Option, you have the ability to define


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

With MultiSource Option, you can define a project schema as


follows:

You select a primary database instance for the project.

You can add tables to the project from different database


instances, not just the primary database instance for the
project.

Any SQL database instance that exists within the


project source is available to the project as a
secondary database instance from which you can
select tables.

82 Introduction to MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

You can associate a single project table with multiple


database instances, which essentially creates duplicate
tables.

However, keep in mind that MultiSource Option has the


following limitations:

You can use MultiSource Option to connect to any data


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

You can only create logical views using the primary


database instance for a project. You cannot create logical
views using secondary database instances or multiple
database instances.

For more information about logical views, refer to


the MicroStrategy Advanced Data Warehousing
course.

MultiSource Option does not support fact tables


partitioned across multiple data sources.

For more information about partitioning, see the


Partitioning lesson starting on page 221.

Support for Duplicate Tables


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

2011 MicroStrategy, Inc. Introduction to MicroStrategy MultiSource Option 83


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

You can have lookup, relationship, and fact tables duplicated


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

For information on how the Engine selects the data


sources for tables, see Selecting the Optimal Data
Source for Fact Tables starting on page 87 and
Selecting the Optimal Data Source for Lookup
Tables starting on page 88.

When you bring duplicate tables to the project, you must


consider the following guidelines required by MultiSource
Option:
Duplicate tables must have identical table and column
names.

Corresponding columns in duplicate tables must either


have the same data type or compatible data types.

Todatamaintain data consistency, the Engine applies


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

Ideally, duplicate tables have the same number of


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

84 Introduction to MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

If you have a logical table that maps to multiple database


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

This icon is visible beside tables only in the Warehouse


Catalog and the Architect graphical interface.

SQL Generation for Multisource Reports


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

With reports that use multiple data sources, much of the


work of the SQL Engine remains the same. However, the
Engine performs two additional tasks:

It determines the optimal database instance for each pass


of SQL.

It identifies when joins need to occur across database


instances.

2011 MicroStrategy, Inc. Introduction to MicroStrategy MultiSource Option 85


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Designating Primary and Secondary Tables

Every project table has a primary database instance. The


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

You can change which database instance is the


primary one for a table. For information on changing
the primary database instance for a table, see
Changing the Primary Database Instance for a Table
starting on page 108.

You can have multiple secondary tables if the table is


mapped to more than one secondary database
instance.

For example, consider the scenario introduced previously:


Report with Objects from Multiple Data Sources

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

86 Introduction to MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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.

2011 MicroStrategy, Inc. Introduction to MicroStrategy MultiSource Option 87


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

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

88 Introduction to MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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

2011 MicroStrategy, Inc. Introduction to MicroStrategy MultiSource Option 89


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Data Type Compatibility Rules

Data Type Compatible Data Type

LongVarChar LongVarChar

NChar NChar
Numeric Decimal, Numeric, Integer with
scale of 0

NVarChar NVarChar

Real Double, Float, Real

Time Time, TimeStamp

TimeStamp Date, Time, TimeStamp

Unsigned Unsigned

VarBin VarBin

VarChar Char, VarChar

IfEngine
two columns do not have compatible data types, the
cannot join data using those columns.

The data type of a column is based on the Engine data type


definition, not the data type definition in the physical
database.

These
same.
two data type definitions may not always be the

Often, different data sources are optimal for different passes


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

90 Introduction to MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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.

2011 MicroStrategy, Inc. Introduction to MicroStrategy MultiSource Option 91


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

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.

92 Introduction to MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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.

2011 MicroStrategy, Inc. Introduction to MicroStrategy MultiSource Option 93


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

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

94 Introduction to MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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.

2011 MicroStrategy, Inc. Introduction to MicroStrategy MultiSource Option 95


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Associating Tables to Database Instances

After completing this topic, you will be able to:


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.

96 Associating Tables to Database Instances 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

Forecast Data is a data warehouse that contains some


duplicated information from Tutorial Data, including the
LU_COUNTRY and LU_REGION tables. It also contains the
FORECAST_SALES base fact table and the
REGION_FORECAST_SALES aggregate fact table, which are
not in Tutorial Data. These fact tables store forecast revenue
data.

Injoining
this lesson, you will analyze two scenarios for
data from multiple sources. One scenario uses
the aggregate fact table and generates a relatively
simple SQL statement. The second scenario uses the
base fact table, and therefore generates a more
complex SQL statement.

These scenarios focus on geography-related lookup


tables. Forecast Data also contains product-related
lookup tables that you will use later in the exercises for
this lesson.

For any report where you want to include information about


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

You can add tables to a project from other database instances


using either the Warehouse Catalog or the Architect graphical
interface.

Adding Tables with a Single Data Source


Adding tables that map only to a single data source is very
easy. For tables that are associated with the primary database
instance for the project, you simply add them as you normally
would in either the Warehouse Catalog or the Architect
graphical interface. However, you can also easily add tables
associated with secondary database instances.

In the sample scenario, there are many tables that map only
to Tutorial Data, which is the primary database instance for
the project. These tables are already part of the project.

2011 MicroStrategy, Inc. Associating Tables to Database Instances 97


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

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

FORECAST_SALES and REGION_FORECAST_SALES exist


only in Forecast Data, so you need to associate them with this
secondary database instance.

To add tables from a secondary database instance to a project


in the Warehouse Catalog:

1 In MicroStrategy Desktop, open the project to which you


want to add the tables.

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.

98 Associating Tables to Database Instances 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

6 Click Save and Close.

7 Update the project schema.

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.

2011 MicroStrategy, Inc. Associating Tables to Database Instances 99


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

To add tables from a secondary database instance to a project


in the Architect graphical interface:

1 In MicroStrategy Desktop, 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.

7 Click Save and Close.

8 Update the project schema.

Depending on how you have configured your


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

100 Associating Tables to Database Instances 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

The following image shows the Architect graphical interface


with the FORECAST_SALES and
REGION_FORECAST_SALES tables added to the project:
FORECAST_SALES and REGION_FORECAST_SALES
Tables Added to Project

The yellow color mapping shows that these tables are


associated with Forecast Data, not Tutorial Data.

2011 MicroStrategy, Inc. Associating Tables to Database Instances 101


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Adding Tables with Multiple Data Sources


Adding tables that map to multiple data sources requires a
few additional steps. When you associate a table to more than
one database instance, you create a duplicate table.

In the sample scenario, there are two tables that map to both
data sources:
Tables with Multiple Data Sources

LU_COUNTRY and LU_REGION exist in both Tutorial Data


and Forecast Data, so you need to associate them to both
database instances.

These two tables are already part of the project and


associated with the Tutorial Data database instance.
However, you need to add them to the project for the
Forecast Data database instance as well.

To add duplicate tables to a project in the Warehouse Catalog:

1 In MicroStrategy Desktop, open the project to which you


want to add the tables.

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.

102 Associating Tables to Database Instances 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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.

IfName>
you click the Make no changes to <Table
option, the table is not mapped to the
selected database instance, and no duplicate table
is created.

7 Do one of the following:

If you want to view and respond to the warnings for each


duplicate table individually, click OK.

In each successive warning window, click OK until no


more warnings display.

OR

If you want to respond to the warnings for all duplicate


tables at the same time, click OK for All.

The tables display in the Tables being used in the


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

You can verify the database instances to which a


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

2011 MicroStrategy, Inc. Associating Tables to Database Instances 103


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

8 Click Save and Close.

9 Update the project schema.

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

The following image shows the Warehouse Catalog with the


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

104 Associating Tables to Database Instances 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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.

To add duplicate tables to a project in the Architect graphical


interface:

1 In MicroStrategy Desktop, 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.

2011 MicroStrategy, Inc. Associating Tables to Database Instances 105


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

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, keep the


Indicate that <Table Name> is also available from the
current DB Instance option selected.

IfName>
you click the Make no changes to <Table
option, the table is not mapped to the
selected database instance, and no duplicate table
is created.

7 Do one of the following:

If you want to view and respond to the warnings for each


duplicate table individually, click OK.

In each successive warning window, click OK until no


more warnings display.

OR

If you want to respond to the warnings for all duplicate


tables at the same time, click OK for All.

The tables display 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.

106 Associating Tables to Database Instances 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

You can verify the database instances to which a


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

8 Click Save and Close.

9 Update the project schema.

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

2011 MicroStrategy, Inc. Associating Tables to Database Instances 107


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Changing the Primary Database Instance for a Table


When you have a table that maps to multiple data sources, by
default, the primary database instance is the first one you use
to add the table to the project. All subsequent database
instances you associate with the table are added as secondary
database instances. However, you may want to change which
database instance is associated as the primary one.

For example, in the sample scenario, there are two tables that
map to both data sources:
Tables with Multiple Data Sources

LU_COUNTRY and LU_REGION exist in both the Tutorial


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

You can use either the Warehouse Catalog or the Architect


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

To change the primary database instance for a table in the


Warehouse Catalog:

1 In MicroStrategy Desktop, open the appropriate project.

2 Open the Warehouse Catalog.

108 Associating Tables to Database Instances 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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


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

4 In the Available Database Instances window, in the


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

The current primary database instance is moved to


the Secondary Database Instances list.

5 If you want to keep the former primary database instance


associated with the table, in the Secondary Database
Instances list, select this database instance.

6 Click OK.

7 In the Warehouse Catalog, click Save and Close.

8 Update the project schema.

The following image shows the option for accessing the


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

2011 MicroStrategy, Inc. Associating Tables to Database Instances 109


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

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.

110 Associating Tables to Database Instances 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

The following image shows the Available Database Instances


window with the modified database instance configuration
for the LU_COUNTRY table:
LU_COUNTRY with Modified Database Instance
Configuration

Forecast Data is now the primary database instance for the


LU_COUNTRY table, and Tutorial Data is a secondary
database instance for the table.

To change the primary database instance for a table in the


Architect graphical interface:

1 In MicroStrategy Desktop, open the appropriate project.

2 Open the Architect graphical interface.

3 In the Architect graphical interface, in the Properties


pane, click the Tables tab.

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


for which you want to change the primary database
instance.

5 Under the Definition category, select the Primary DB


Instance property.

2011 MicroStrategy, Inc. Associating Tables to Database Instances 111


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

6 Beside the database instance, click the following button:

7 In the Available Database Instances window, in the


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

The current primary database instance is moved to


the Secondary Database Instances list.

8 If you want to keep the former primary database instance


associated with the table, in the Secondary Database
Instances list, select this database instance.

9 Click OK.

Inyouthemade
Properties pane, you should see the changes
reflected in the database instances
associated with the Primary DB Instance and
Secondary DB Instances properties.

10 Click Save and Close.

11 Update the project schema.

Depending on how you have configured your


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

112 Associating Tables to Database Instances 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

The following image shows the Primary DB Instance and


Secondary DB Instances properties on the Properties pane:
Primary DB Instance and Secondary DB Instances
Properties

The Secondary DB Instances property displays only if


a project is associated with multiple database
instances.

When you change the primary database instance for a table,


the color mapping in the Architect graphical interface also
changes to reflect the appropriate associations.

Removing a Database Instance from a Table


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

2011 MicroStrategy, Inc. Associating Tables to Database Instances 113


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

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


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

Infromsuchthecases, you do not want to remove the table


project since that removes its association to
all database instances.

Instead, you can use the same functions in the Warehouse


Catalog or the Architect graphical interface to remove a
database instance from a table as you use to change the
primary database instance for a table.

Ifprimary
the database instance you want to remove is the
database instance, you have to change the
primary database instance first. This action removes
the association between the database instance and the
table.

114 Associating Tables to Database Instances 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

Creating Objects for Multisource Reports

After completing this topic, you will be able to:


Create objects for use in multisource reports.

After you have associated tables with the appropriate


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

For example, in the sample scenario, you have four tables in


the Forecast Data data warehouse that are used in the
project:
Forecast Data Tables Used in Project

Since the LU_COUNTRY and LU_REGION tables also exist


in the Tutorial Data data warehouse, the project already
contains the corresponding attributes. If these attributes use
the Automatic mapping method, Architect automatically
maps them to the duplicate tables from Forecast Data.

Ifmapping
you have attributes that do not use the Automatic
method, you have to manually map the
duplicate tables to the corresponding attributes.

2011 MicroStrategy, Inc. Creating Objects for Multisource Reports 115


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

However, the FORECAST_SALES and


REGION_FORECAST_SALES tables do not exist in the
Tutorial Data data warehouse.

The following image shows the structure of the


REGION_FORECAST_SALES table:
REGION_FORECAST_SALES Table

The following image shows the structure of the


FORECAST_SALES table:
FORECAST_SALES Table

The REGION_FORECAST_SALES and FORECAST_SALES


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

116 Creating Objects for Multisource Reports 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

Creating the Forecast Revenue Fact


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

Forecast_Revenue

The following image shows the Forecast Revenue fact


mapped to the REGION_FORECAST_SALES table:
Mapping of Forecast Revenue Fact

Later in this lesson, you will modify this fact to point to


the FORECAST_SALES base fact table instead of the
aggregate table.

2011 MicroStrategy, Inc. Creating Objects for Multisource Reports 117


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Creating the Forecast Revenue Metric


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

The Forecast Revenue metric is formatted as Currency


with 0 decimal places.

118 Creating Objects for Multisource Reports 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

Creating a Multisource Report

After completing this topic, you will be able to:


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

Now that you have created the necessary objects for


multisource reports, the final step in configuring a project to
access heterogeneous data sources is to create a report that
uses objects from multiple data sources.

As you learned earlier, MultiSource Option supports a variety


of scenarios in which you can combine data from different
data sources. The following report for the sample scenarios
contains metrics that use facts from different data sources:
Sample Multisource Report

In this report, you can obtain data for the Region attribute
from either the Tutorial Data or Forecast Data data
warehouses. You can obtain data for the Revenue metric only
from Tutorial Data. You can obtain data for the Forecast
Revenue metric only from Forecast Data.

2011 MicroStrategy, Inc. Creating a Multisource Report 119


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Processing of SQL for Sample Report


When you create this sample report and execute it, the
Engine has to perform the following steps to obtain the result
set:

1 Aggregate the revenue for each region using Tutorial


Data.

2 Aggregate the forecast revenue for each region using


Forecast Data.

3 Obtain the region descriptions using either Tutorial Data


or Forecast Data.

4 Consolidate the region, revenue, and forecast revenue


data to produce the final result set.

Based on the logic the Engine uses to select the optimal data
source for each pass, it moves data between the two
databases to process the query.

Simple SQL ScenarioObtaining Forecast


Revenue from the Aggregate Table

In the first scenario, the Forecast Revenue fact maps to the


REGION_FORECAST_SALES aggregate table. The report
template contains the Region attribute and the Revenue and
Forecast Revenue metrics. Since the
REGION_FORECAST_SALES table stores the forecast
revenue already pre-aggregated to the region level, the
Engine generates fairly straightforward SQL to retrieve the
forecast data.

The following images show the primary SQL passes for the
sample report and explain what happens in each pass.

120 Creating a Multisource Report 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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

2011 MicroStrategy, Inc. Creating a Multisource Report 121


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Since forecast revenue data is stored only in Forecast Data,


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

When data is moved from one data source to another,


the SQL view of a report does not show the entire
INSERT statement. Rather than showing all the values
that are inserted into a temporary table, it shows only
a single set of values. However, it does show the
number of rows inserted into the table above the
INSERT statement.

Now that the Engine has calculated all the metrics for the
report, it uses Tutorial Data to obtain the region descriptions
and consolidate the results of both metric calculations.

Toperforms
minimize the movement of data, the Engine
the final consolidation pass using the
database instance in which the most temporary tables
were created while processing the report. In this
example, both temporary tables were created in the
Tutorial Data database instance, so the Engine selects
the primary database instance.

Ifinstances,
there is a tie between two or more database
the Engine selects the primary database
instance for the project. If none of them are the
primary database instance for the project, the Engine
selects the database instance with the smallest GUID
(alphabetically).

122 Creating a Multisource Report 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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

2011 MicroStrategy, Inc. Creating a Multisource Report 123


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Complex SQL ScenarioAggregating Forecast


Revenue from the Base Fact Table

In the first scenario, the forecast revenue data was readily


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

But what happens if the relationship between the attribute on


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

To use the FORECAST_SALES fact table, you need to modify


the Forecast Revenue fact to map to that table. You need to
use the following expression that combines three fact
columns from this table:

FORECAST_QTY_SOLD * (FORECAST_UNIT_PRICE
- FORECAST_DISCOUNT)

124 Creating a Multisource Report 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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.

2011 MicroStrategy, Inc. Creating a Multisource Report 125


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

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

126 Creating a Multisource Report 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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.

2011 MicroStrategy, Inc. Creating a Multisource Report 127


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

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.

128 Creating a Multisource Report 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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

2011 MicroStrategy, Inc. Creating a Multisource Report 129


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design


Exercises: Using MicroStrategy MultiSource
Option
You should complete the following exercises using the
MicroStrategy Tutorial project, which is found in the
MicroStrategy Analytics Modules project source.

The report you will create in these exercises builds on


some of the work you did in the MicroStrategy Tutorial
project during the lesson demonstrations. If you are
missing any objects that you need to complete the
exercises, ask your instructor for assistance.

Add Tables from a Secondary Database Instance

Overview

In this exercise, you will use the Warehouse Catalog to add


the following lookup tables from the Forecast Data database
instance to the MicroStrategy Tutorial project:

Lookup Table Name

LU_PRODUCT

LU_SUBCATEG

As you add these tables, you should configure them as


follows:

Make Forecast Data the primary database instance for


the LU_PRODUCT table

Add LU_SUBCATEG as a duplicate table with Forecast


Data as the secondary database instance

130 Exercises: Using MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

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

You can use the detailed instructions if you want help.

Detailed Instructions

Open the Warehouse Catalog for the MicroStrategy


Tutorial project

1 In the MicroStrategy Analytics Modules project source,


open the MicroStrategy Tutorial project.

2 Open the Warehouse Catalog.

Add the LU_PRODUCT table to the project

3 In the Warehouse Catalog, in the Select current database


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

4 In the Tables available in the database instance list, select


the LU_PRODUCT table.

5 Click the > button to add the table to the project.

The table displays in the Tables being used in the


project list. Forecast Data should display as the
primary database instance for the table.

2011 MicroStrategy, Inc. Exercises: Using MicroStrategy MultiSource Option 131


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Add the LU_SUBCATEG table to the project

6 In the Tables available in the database instance list, select


the LU_SUBCATEG table.

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

8 In the warning window, under Available options, keep the


Indicate that LU_SUBCATEG is also available from
the current DB Instance option selected.

9 Click OK.

The table displays in the Tables being used in the


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

Save your project work

10 Click Save and Close.

Update the project schema

11 Update the project schema.

132 Exercises: Using MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

Create an Attribute for a Multisource Report

Overview

In this exercise, you will create the Product attribute. You


need this attribute for the multisource report you will create
later in these exercises.

You should create the Product attribute in the Schema


Objects\Attributes\Products folder. As part of creating the
Product attribute, you need to complete the following tasks:

Map the ID and DESC forms for the Product attribute as


shown in the following table:

Attribute Form Expressions Source Tables

Product ID: PRODUCT_ID LU_CATEGORY


LU_PRODUCT

DESC: PRODUCT_DESC LU_PRODUCT

The primary lookup table for the Product attribute


displays in bold text. You should use Automatic
mapping for both attribute form expressions.

Relate the Product attribute to the Category attribute as


shown in the following table:

Parent Attribute Child Attribute Relationship Table

Product Category (1:M) LU_CATEGORY

Add the Product attribute to the Products hierarchy,


which is in the Schema Objects\Hierarchies\Data
Explorer folder

After you have completed these tasks, update the project


schema.

You can use the detailed instructions if you want help.

2011 MicroStrategy, Inc. Exercises: Using MicroStrategy MultiSource Option 133


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Detailed Instructions

Create the Product attribute

1 In the MicroStrategy Tutorial project, in the Schema


Objects\Attributes\Products folder, open the Attribute
Editor.

2 In the Attribute Editor, create the ID form for the Product


attribute and map it to the PRODUCT_ID column in the
LU_PRODUCT table.

3 Use Automatic as the mapping method.

This actions maps the ID form to the


LU_CATEGORY table as well.

4 Create the DESC form for the Product attribute and map
it to the PRODUCT_DESC column in the LU_PRODUCT
table.

5 Use Automatic as the mapping method.

6 Create a one-to-many relationship between the Product


and Category attributes with Product as the parent
attribute.

7 Keep LU_CATEGORY as the relationship table.

8 Save the attribute in the Schema


Objects\Attributes\Products folder as Product.

9 Close the Attribute Editor.

Add the Product attribute to the Products hierarchy

10 In the Schema Objects\Hierarchies\Data Explorer folder,


open the Products hierarchy.

11 In the Hierarchy Editor, add the Product attribute to the


hierarchy.

134 Exercises: Using MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

12 Set the Product attribute as an entry point.

13 Save and close the Products hierarchy.

Update the project schema

14 Update the project schema.

Create a Multisource Report

Overview

In this exercise, you will create a multisource report. The


report should contain the following attributes and metrics:
Product, Category, Revenue, and Forecast Revenue. The
report should also contain an attribute element filter with the
following condition: Product In list (Entertainment).

Save the report in the Public Objects\Reports folder as


Revenue and Forecast Revenue for Entertainment
Categories.

Run the report. The result set should look like the following:

Switch to the SQL View of the report. Answer the follow-up


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

You can use the detailed instructions if you want help.

2011 MicroStrategy, Inc. Exercises: Using MicroStrategy MultiSource Option 135


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

Detailed Instructions

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.

136 Exercises: Using MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

4 Run the report.

5 Compare your results to the expected report in the


Overview section at the beginning of this exercise.

6 Switch to the SQL View for the report.

7 Answer the follow-up questions about this exercise. After


you have answered the questions, close the report.

Follow-up Questions

1 Which database does the Engine use to obtain the Product


description? Why?

_______________________________________

_______________________________________

_______________________________________

_______________________________________

2 Which database does the Engine use to obtain the


Category descriptions? Why?

_______________________________________

_______________________________________

_______________________________________
_______________________________________

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

_______________________________________

_______________________________________

_______________________________________

_______________________________________

2011 MicroStrategy, Inc. Exercises: Using MicroStrategy MultiSource Option 137


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

4 Which database does the Engine use to calculate the


Revenue metric? Why?

_______________________________________

_______________________________________

_______________________________________

_______________________________________

5 Which database does the Engine use to calculate the


Forecast Revenue metric? Why?

_______________________________________

_______________________________________

_______________________________________

_______________________________________

6 Which database does the Engine use for the final


consolidation pass? Why?

_______________________________________

_______________________________________

_______________________________________
_______________________________________

Answers to Follow-up Questions

1 The Engine uses Forecast Data because the


LU_PRODUCT table, which stores the Product
descriptions, exists only in this database.

2 The Engine uses Tutorial Data because the


LU_CATEGORY table, which stores the Category
descriptions, exists only in this database.

3 The Engine uses the LU_CATEGORY table in Tutorial


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

138 Exercises: Using MicroStrategy MultiSource Option 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

4 The Engine uses Tutorial Data because revenue data


exists only in this database.

5 The Engine uses Forecast Data because forecast revenue


data exists only in this database.

6 The Engine uses Tutorial Data for the final consolidation


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

2011 MicroStrategy, Inc. Exercises: Using MicroStrategy MultiSource Option 139


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design


Lesson Summary
In this lesson, you learned:

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.

140 Lesson Summary 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Using MicroStrategy MultiSource Option 3

When the Engine needs to join data from different data


sources, it moves data between them as it processes the
result set for a report. It joins table columns using specific
data type compatibility rules.

You can use MultiSource Option to support a variety of


scenarios in which you need to join data from different
sources.

The first step in configuring a project to access


heterogeneous data sources is to add the necessary tables
to a project and associate them with the appropriate
database instances.

You can add tables from primary or secondary database


instances to a project in both the Warehouse Catalog and
the Architect graphical interface.

You can add duplicate tables to a project in both the


Warehouse Catalog and the Architect graphical interface.

You can change the primary database instance for a table


in both the Warehouse Catalog and the Architect
graphical interface.

You can remove a database instance from a table in both


the Warehouse Catalog and the Architect graphical
interface.

The second step in configuring a project to access


heterogeneous data sources is to create the necessary
objects for multisource reports.

The final step in configuring a project to access


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

2011 MicroStrategy, Inc. Lesson Summary 141


3 Using MicroStrategy MultiSource Option MicroStrategy Architect: Advanced Project Design

142 Lesson Summary 2011 MicroStrategy, Inc.


4
FACT LEVEL EXTENSIONS

Lesson Description

This lesson describes the various ways you can extend fact
levels using MicroStrategy Architect.

In this lesson, you will first learn about the three types of fact
level extensionsdegradation, extension, and disallow. Then,
you will learn how to create each of these types of fact level
extensions.

2011 MicroStrategy, Inc. 143


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

Lesson Objectives

After completing this lesson, you will be able to:


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.

After completing the topics in this lesson, you will be able to:

Describe how the level at which a fact is stored affects


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

Describe the purpose of fact degradations and create fact


degradations to lower the levels of facts. (Page 148)

Describe the purpose of fact extensions and create fact


extensions to extend the levels of facts to other
hierarchies. (Page 156)

Describe the purpose of fact disallows and disallow fact


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

144 Lesson Objectives 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

Overview of Fact Level Extensions

After completing this topic, you will be able to:


Describe how the level at which a fact is stored affects reports
and describe the three types of fact level extensions available
in MicroStrategy Architect.

Facts are stored in data warehouse tables at particular levels.


The level of a fact is defined by the attribute IDs present in
the fact table. The level at which a fact is stored directly
affects how you can report on that fact. You can report on a
fact at the level at which it is stored, or you can aggregate it to
a higher level.

For example, the following illustration shows a fact table in


which the Unit Sales fact is stored at the item and week level:
Fact Level

Itattribute
is possible for the same fact to be stored at different
levels within a hierarchy. For example, you
could have another fact table that stores unit sales by
item and date, rather than item and week. This fact
table would store unit sales for items at a lower level
within the Time hierarchy.

Based on this fact table, you can report on unit sales at the
item or week levels. You can also aggregate the unit sales data
to the month, quarter, or year levels within the Time
hierarchy and to the subcategory and category levels within
the Product hierarchy. However, you cannot create a report
that shows unit sales by date because the fact is stored at the
higher level of week. You cannot determine the unit sales at
the date level using this fact table.

2011 MicroStrategy, Inc. Overview of Fact Level Extensions 145


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

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


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

You may also have a scenario in which a metric consists of


more than one fact. For example, the following illustration
shows a Sales metric that consists of the Unit Price and
Quantity Sold facts:
Different Fact Levels in a Metric Definition

The Unit Price fact is stored at the item and week levels, while
the Quantity Sold fact is stored at the item and day levels.
However, for these two facts to be used together in a metric
expression, they must be stored at the same level. Otherwise,
the calculation can cause errors, depending on the level at
which you need to report on the metric.

As you can see, the levels at which facts are stored limit the
levels at which you can report on facts. If you have a metric
that consists of multiple facts, they have to be stored at the
same level to correctly calculate the metric.

Sometimes, facts may not be available in the data warehouse


at the levels you want to analyze in reports. You may not be
able to change the levels at which they are stored in data
warehouse tables, but you can change the levels of facts in
MicroStrategy Architect by using fact level extensions. Fact
level extensions enable facts stored in the data warehouse at
one level to be reported on at a different level.

Fact level extensions are not commonly applied to


facts, but they are very useful in special cases.

146 Overview of Fact Level Extensions 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

MicroStrategy Architect provides the following three types of


fact level extensions:

DegradationEnables you to extend the level of a fact to


a lower level within the same hierarchy.

ExtensionEnables you to extend the level of a fact to


include a level from a different hierarchy not currently
related to the fact

DisallowEnables you to disallow a specific fact level to


prevent unnecessary cross joins to lookup tables when
reporting on a fact

The remainder of this lesson describes each of these fact level


extensions in detail.

2011 MicroStrategy, Inc. Overview of Fact Level Extensions 147


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

Degrading Fact Levels

After completing this topic, you will be able to:


Describe the purpose of fact degradations and create fact
degradations to lower the levels of facts.

A fact degradation enables you to lower the level of a fact


within a hierarchy to which it is already related.

The following illustration shows a fact table with facts stored


at the month level and a report that requires one of these
facts to be displayed at the day level:
Fact Degradation Scenario

In this example, the report contains the Units Received


metric that uses the Units Received fact in its definition.

148 Degrading Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

The Units Received fact is stored at the item and month


levels. However, you need the Units Received fact to be
available at the day level. If you try to run this report, you
receive the following error message:
Report Error Without the Fact Degradation

The error message notifies users that the Units Received fact
is not available at the day and item levels. For this report to
work, you need to lower the level of the Units Received fact
from month to day using a fact degradation.

Ascouldan change
alternative to creating a fact degradation, you
the level of the fact table in the data
warehouse itself. However, changing the fact table is
not always an option. The fact data may not be
captured at that level in the source system, or there
may be other organizational or environmental
restrictions on changing the table structure.

2011 MicroStrategy, Inc. Degrading Fact Levels 149


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

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.

150 Degrading Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

For the Units Received fact degradation, the Units Received


fact is stored at the item and month level, so it is related to
both the Item and Month attributes. Since you need to lower
the fact to the day level, you select Month as the join attribute
because it is directly related to the Day attribute. The Item
attribute is not directly related to the Day attribute, so you
would not use it as the join attribute.

Determining the Join Direction

After you select the join attribute you want to use to relate the
desired attribute and fact, you have to determine how you
want the SQL Engine to perform the join between the join
attribute and the fact. There are two possible join directions.
You can join to the fact using only the join attribute itself, or
you can allow the fact to also join to children of the join
attribute.

For the Units Received fact degradation, the Units Received


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

Ifattribute
you allow the SQL Engine to join against the join
and any of its children, you need to ensure
that the allocation expression you use for the fact
degradation returns values that are valid at any of
those attribute levels.

2011 MicroStrategy, Inc. Degrading Fact Levels 151


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

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.

152 Degrading Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

To create a fact degradation:

1 Open the fact in the Fact Editor.

2 In the Fact Editor, click the Extensions tab.

3 On the Extensions tab, click New.

4 In the Level Extension Wizard, in the Introduction


window, click Next.

5 In the General Information window, in the Name box,


type a name for the extension.

6 In the Description box, type a description for the


extension.

7 Click Lower the fact entry level.

8 Click Next.

9 In the Extended Attributes window, in the Available


attributes list, select the attribute to which you want to
lower the fact and click the > button to add it to the
Selected attributes list.

10 Click Next.

11 In the Join Type window, in the Join attributes list, select


the check box for the attribute you want to use in the join.

12 Click Next.

13 In the Join Attributes Direction window, in the Join


attributes list, in the Join against column, click the arrow
icon to set the join direction for the join attribute.

14 Click Next.

15 In the Allocation window, do one of the following:

If you want to specify an allocation expression, select the


Specify an allocation expression check box.

In the box, type the expression.

2011 MicroStrategy, Inc. Degrading Fact Levels 153


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

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.

19 Update the project schema.

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

154 Degrading Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

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.

2011 MicroStrategy, Inc. Degrading Fact Levels 155


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

Extending Fact Levels

After completing this topic, you will be able to:


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.

156 Extending Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

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


Freight metric that uses the Freight fact, the result set looks
like the following:
Item and FreightReport Result Set

The image above displays only the first few rows of the
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 FreightReport SQL

2011 MicroStrategy, Inc. Extending Fact Levels 157


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

Because there is no relationship between Item and Freight,


the SQL Engine performs a cross join between the fact and
lookup tables to retrieve the data for the report.

Therefore, if you want to view freight information by item,


you have to extend the Freight fact to the item level. You
cannot use a fact degradation because Item is an attribute
from a different hierarchy than the attributes that are already
related to the Freight fact.

Ascouldan add
alternative to creating a fact extension, you
a new level to the fact table in the data
warehouse itself. However, changing the fact table is
not always an option. The fact data may not be
captured at that level in the source system, or there
may be other organizational or environmental
restrictions on changing the table structure.

MicroStrategy Architect provides three methods for creating


fact extensions. They enable different options for joining the
desired attribute and fact. You can create fact extensions
using the following three methods:

Table relationYou select a particular table to use for the


join. You should select this option if you always want the
SQL Engine to use the same table to join the desired
attribute and fact.

Fact relationInstead of selecting a single table, you


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

Cross productYou choose to have the SQL Engine


perform a cross join between the lookup table of the
desired attribute and the fact table.

You should use the cross product option only as a


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

158 Extending Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

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.

2011 MicroStrategy, Inc. Extending Fact Levels 159


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

Selecting the Table for the Join

The SQL Engine needs to join the table that contains the fact
you are extending and the lookup table that stores the
attribute to which you are extending the fact. Because these
two tables are not related, you have to select another data
warehouse table to serve as a relationship table between the
fact and lookup tables.

After you select the attribute to which you want to extend the
fact, MicroStrategy Architect searches the project warehouse
catalog and returns a list of all tables that contain the ID
column of that attribute. Using this list of candidate tables,
you can then select the optimal table for the join. In selecting
a table, you should consider several factors, including the
number of possible join paths, the optimal join path for a
given allocation expression, and any other characteristics
specific to your data warehouse environment. For example,
you may want to use a table for the join that you know has
better indexes or is updated more frequently.

In the previous example, the Freight fact is stored in the


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

160 Extending Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

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.

2011 MicroStrategy, Inc. Extending Fact Levels 161


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

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

You could use the ORDER_DETAIL table to join the


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

The ORDER_DETAIL table is the optimal join table


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

162 Extending Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

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.

2011 MicroStrategy, Inc. Extending Fact Levels 163


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

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]

164 Extending Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

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


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

Creating a Fact Extension Using the Table Relation Method


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:

1 Open the fact in the Fact Editor.

2 In the Fact Editor, click the Extensions tab.

3 On the Extensions tab, click New.

4 In the Level Extension Wizard, in the Introduction


window, click Next.

5 In the General Information window, in the Name box,


type a name for the extension.

6 In the Description box, type a description for the


extension.

7 Click Extend the fact entry level.

8 Click Next.

2011 MicroStrategy, Inc. Extending Fact Levels 165


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

9 In the Extended Attributes window, in the Available


attributes list, select 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.

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

17 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 each join attribute.

18 Click Next.

166 Extending Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

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.

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

22 In the Fact Editor, click Save and Close.

23 Update the project schema.

2011 MicroStrategy, Inc. Extending Fact Levels 167


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

The following image shows a fact extension in the


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

You can then run the following report that displays invoice
information for all items in a particular order:
Invoice ReportFreight at the Item Level

168 Extending Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

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


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

Steps for Fact Extension Using the Fact Relation Method


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

1 Select the attribute level to which you want to extend the


fact.

2 Select a fact that maps to the tables you want the SQL
Engine to use to join the fact to the attribute to which you
want to extend the fact.

3 Select the attribute or set of attributes the SQL Engine can


use to join the fact to the attribute to which you want to
extend the fact.

4 Determine the join direction between the join attributes


and the fact.

5 If necessary, define an allocation expression.

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


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

2011 MicroStrategy, Inc. Extending Fact Levels 169


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

Selecting the Fact for the Join

The SQL Engine needs to join the table that contains the fact
you are extending and the lookup table that stores the
attribute to which you are extending the fact. Because these
two tables are not related, you have to use another data
warehouse table to serve as a relationship table between the
fact and lookup tables. The major difference between the
table and fact relation methods is that instead of directly
selecting a table to use for this join, you select a fact. The SQL
Engine can then select any table that contains that fact to use
for the join.

After you select the attribute to which you want to extend the
fact, MicroStrategy Architect returns a list of all facts that are
stored at that attribute level. Using this list of candidate facts,
you can then select the fact for the join. The fact may be
mapped to one table or to multiple tables. If the fact maps to
only one table, the SQL Engine always uses that table for the
join. In such cases, it makes no difference whether you create
the fact extension using the table relation or fact relation
method. However, if the fact maps to multiple tables, the SQL
Engine can select the optimal table to use for a particular
query based on logical size, report level, and so forth. In these
cases, selecting a fact essentially creates a list of tables the
SQL Engine can use for the join. You then allow the SQL
Engine to choose the optimal table for a given query.

Because the fact relation method allows the SQL


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

170 Extending Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

For example, when you extend the Freight fact to Item using
a fact relation, MicroStrategy Architect returns the following
list of candidate facts:
List of Candidate Facts

Each of these facts is related to the Item attribute. You select


the fact that maps to the tables you want to allow the SQL
Engine to use to join the Freight fact and Item attribute.

In this example, you can easily eliminate facts that are


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

The ORDER_DETAIL table is the optimal join table


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

2011 MicroStrategy, Inc. Extending Fact Levels 171


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

Selecting the Join Attribute or Set of Join


Attributes

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

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.

Since there can be many attribute levels represented in the


various fact tables available to the SQL Engine, there are four
possible join directions rather than just two. You can join to
the fact in the following ways:

Using only the join attributes themselves

Using the join attributes or any children of the join


attributes

Using the join attributes or any parents of the join


attributes

Using the join attributes or any attributes in same


hierarchy as the join attributes

Creating a Fact Extension Using the Fact Relation Method


Now that you understand the steps involved in creating fact
extensions using the fact relation method, you are ready to
learn how to use the Level Extension Wizard to create a fact
extension using a fact relation.

172 Extending Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

To create a fact extension using a fact relation:

1 Open the fact in the Fact Editor.

2 In the Fact Editor, click the Extensions tab.

3 On the Extensions tab, click New.

4 In the Level Extension Wizard, in the Introduction


window, click Next.

5 In the General Information window, in the Name box,


type a name for the extension.

6 In the Description box, type a description for the


extension.

7 Click Extend 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
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 Select the


relationship table dynamically. Specify an existing
fact to be used to extend the current one.

12 Click Next.

13 In the Fact Selection window, in the Available facts list,


select the fact that you want to use to extend the fact.

14 Click Next.

2011 MicroStrategy, Inc. Extending Fact Levels 173


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

15 In the Join Type window, do one of the following:

If you want the SQL Engine to select the optimal set of


attributes for the join based on the SQL query, click
Dynamically select the best set of attributes (Best Fit).

OR

If you want the SQL Engine to always use a particular


attribute or set of attributes for the join, click I will select
the set of attributes.

In the Join attributes list, select the check boxes for the
attributes you want to use in the join.

The list of attributes includes all attributes present


in the tables that contain the fact you selected.

16 Click Next.

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

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

174 Extending Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

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

22 In the Fact Editor, click Save and Close.

23 Update the project schema.

The following image shows a fact extension in the


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

2011 MicroStrategy, Inc. Extending Fact Levels 175


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

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


the same results set that it did when using the table relation
method for the Freight fact extension:
Invoice ReportFreight at the Item Level

Steps for Fact Extension Using the Cross Product Method


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

When you use the cross product method to relate a fact


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

Creating a fact extension using a cross product consists of the


following steps:

1 Select the attribute level to which you want to extend the


fact.

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


attribute to which you want to extend the fact.

3 If necessary, define an allocation expression.

176 Extending Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

The primary steps for this method are selecting the attribute
to which you want to extend the fact and defining the
allocation expression. Both of these steps are the same as for
any other method of creating fact extensions.

Creating a Fact Extension Using the Cross Product Method


Now that you understand the steps involved in fact
extensions using the cross product method, you are ready to
learn how to use the Level Extension Wizard to create a fact
extension using a cross product.

To create a fact extension using a cross product:

1 Open the fact in the Fact Editor.

2 In the Fact Editor, click the Extensions tab.

3 On the Extensions tab, click New.

4 In the Level Extension Wizard, in the Introduction


window, click Next.

5 In the General Information window, in the Name box,


type a name for the extension.

6 In the Description box, type a description for the


extension.

7 Click Extend 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
extend the fact and click the > button to add it to the
Selected attributes list.

10 Click Next.

2011 MicroStrategy, Inc. Extending Fact Levels 177


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

11 In the Extension Type window, click Perform the


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

12 Click Next.

13 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 14.

14 Click Next.

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

16 In the Fact Editor, click Save and Close.

17 Update the project schema.

178 Extending Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

Disallowing Fact Levels

After completing this topic, you will be able to:


Describe the purpose of fact disallows and disallow fact levels
to prevent unnecessary cross joins from occurring.

A fact disallow functions very differently from other types of


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

For example, a project may contain the following hierarchies


and fact table:
Sample Data Model

This project contains Geography, Product, and Time


hierarchies. The INVENTORY_ORDERS fact table stores
data only at the level of item and month, so it is only related
to the Product and Time hierarchies.

2011 MicroStrategy, Inc. Disallowing Fact Levels 179


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

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


Units Received metric (built from the Units Received fact) as
well as the Item and Call Center attributes? The Item
attribute is related to the Units Received fact since it is part of
the Product hierarchy, but the Call Center attribute is not
related to this fact since it is part of the Geography hierarchy.
By default, the result set for this report looks like the
following:
Report Result SetUnrelated Attribute and Fact

The image above only displays the first few rows of the
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.

180 Disallowing Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

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


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

The report SQL includes the LU_CALL_CTR table in the


FROM clause, but it cannot join this table to the
INVENTORY_ORDERS fact table in the WHERE clause. The
cross join makes it possible for the report to return data, but
it can only produce a cross product, which does not yield a
meaningful result set.

If you have no need for this cross join and the result set it
produces, you can disallow the Call Center attribute for the
Units Received fact. This fact disallow prevents the SQL
Engine from executing the cross join.

To disallow a fact level:

1 Open the fact in the Fact Editor.

2 In the Fact Editor, click the Extensions tab.

3 On the Extensions tab, click New.

2011 MicroStrategy, Inc. Disallowing Fact Levels 181


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

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 Disallow partially or completely the fact entry


level.

8 Click Next.

9 In the Extended Attributes window, in the Available


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

10 Click Next.

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

12 In the Fact Editor, click Save and Close.

13 Update the project schema.

182 Disallowing Fact Levels 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

After disallowing the Call Center attribute for the Units


Received fact, if you run the same report, the report fails and
the following error message displays:
Report Error with the Fact Disallow

The error message basically notifies users that they cannot


extend the Units Received fact to the Call Center attribute
using a cross join.

You cannot use fact disallows to prevent normal joins


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

2011 MicroStrategy, Inc. Disallowing Fact Levels 183


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design


Exercise: Create a Fact Degradation

Overview

You will use the Forecasting Project for this exercise.

In this exercise, you will first create the following report:

Run the report. Add the Month attribute to the template and
run the report again. After reviewing the error message, save
the report as Degradation Example in the Public
Objects\Reports folder.

Next, you will create degradation for the Forecast Cost fact
to enable you to report on that fact at the Month level. In the
data warehouse, this fact exists only at the Quarter level. You
should use the following allocation expression for the fact
degradation: [Forecast Cost] / 3. After creating the fact
degradation, you should update the project schema.

184 Exercise: Create a Fact Degradation 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

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.

You can use the detailed instructions if you want help.

Detailed Instructions

Create a report

1 In MicroStrategy Desktop, in the Forecasting Project, in


the Public Objects folder, in the Reports folder, create the
following report:

You can access the Quarter attribute from the Time


hierarchy. You can find the Forecast Cost metric in
the Metrics folder.

2011 MicroStrategy, Inc. Exercise: Create a Fact Degradation 185


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

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.

186 Exercise: Create a Fact Degradation 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

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

6 Switch to Design View.

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.

9 In the Fact Editor, click the Extensions tab.

10 On the Extensions tab, click New.

11 In the Level Extension Wizard, in the Introduction


window, click Next.

2011 MicroStrategy, Inc. Exercise: Create a Fact Degradation 187


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design

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.

20 In the Join Attributes Direction window, in the Join


attributes list, in the Join against column, keep the default
setting.

21 Click Next.

22 In the Allocation window, select the Specify an


allocation expression check box.

23 In the box, type the following expression: [Forecast


Cost] / 3.

This allocation expression returns correct values


only at the month level.

24 Click Validate to validate your expression.

188 Exercise: Create a Fact Degradation 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Fact Level Extensions 4

25 Click Next.

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

27 In the Fact Editor, click Save and Close.

Update the project schema

28 Update the project schema.

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.

2011 MicroStrategy, Inc. Exercise: Create a Fact Degradation 189


4 Fact Level Extensions MicroStrategy Architect: Advanced Project Design


Lesson Summary
In this lesson, you learned:

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.

190 Lesson Summary 2011 MicroStrategy, Inc.


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.

2011 MicroStrategy, Inc. 191


5 Transformations MicroStrategy Architect: Advanced Project Design

Lesson Objectives

After completing this lesson, you will be able to:


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

After completing the topics in this lesson, you will be able to:

Describe the purpose of transformations, the two different


types of transformations, and the components of a
transformation. (Page 193)

Create a transformation in MicroStrategy Architect and


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

192 Lesson Objectives 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Transformations 5

What Is a Transformation?

After completing this topic, you will be able to:


Describe the purpose of transformations, the two different
types of transformations, and the components of a
transformation.

Transformations are schema objects most often used to


compare values at different timesfor example, this year
versus last year and today versus month to date.
Transformations are useful for discovering and analyzing
time-based trends in your data.

Transformations are not placed on the template of a report or


a document. Instead, report developers use transformations
to define transformation metricssimple metrics that
assume the properties of the transformation applied to them.

2011 MicroStrategy, Inc. What Is a Transformation? 193


5 Transformations MicroStrategy Architect: Advanced Project Design

For example, a report developer could create a metric to


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

Any transformation can be included as part of the definition


of a metric, and multiple transformations can be applied to
the same metric.

194 What Is a Transformation? 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Transformations 5

Types of Transformations
There are two types of transformations:

Table-based transformationsYou implement these


transformations using a transformation table in the
warehouse.

Expression-based transformationsYou implement these


transformations using a mathematical formula.

Table-Based Transformations

Table-based transformations use transformation tables in the


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

This table also has columns for the parent IDs at all
levels. These columns are not displayed in the image
above.

2011 MicroStrategy, Inc. What Is a Transformation? 195


5 Transformations MicroStrategy Architect: Advanced Project Design

Each date in the LU_DAY table has a transformed value for


the previous day, last months date, last quarters date, and
last years date. For example, for January 5, 2009, the
previous day was January 4, 2009, while the last quarters
date was October 5, 2008.

Other types of transformations may require separate


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

In the MTD_DAY transformation table, each date has one or


more records for all dates within its month before and
including that date. For example, there is only one record for
the January 1, 2009 date, but there are three records for the
January 3, 2009 date.

This type of transformation data cannot be stored in


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

196 What Is a Transformation? 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Transformations 5

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.

2011 MicroStrategy, Inc. What Is a Transformation? 197


5 Transformations MicroStrategy Architect: Advanced Project Design

Expression-based transformations work only if you store


your data in a format conducive to calculation. For example,
if you store your month IDs in the format YYYYMM, the
MONTH_ID1 expression does not always work. If you apply
that expression to the month ID 201001 (January 2010) with
the desire to obtain information about 200912 (December
2009), you do not get any data because there is no 201000
month ID.

Transformation Components
All transformations have the following components:

Member attributes

Member expressions

Member tables

Mapping type

The following sections describe these components in more


detail.

Member Attributes

The member attributes are attributes to which the


transformation applies. In other words, it is the lowest-level
attribute on the report to which you want to apply the
transformation. For example, if you analyze the report at the
quarter level, you should add a Quarter member attribute to
the transformation. On the other hand, if the transformation
is month to date, the member attribute would be Day.

198 What Is a Transformation? 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Transformations 5

Member Expressions

Each member attribute has a corresponding expression that


needs to be resolved in the report SQL to obtain valid data.
For expression-based transformations, the member
expression is a mathematical expression. For table-based
transformations, it is a column from a transformation table in
the warehouse that points to the valid data.

Atable-based
single transformation can use a combination of
and expression-based transformations.
For example, you could create a Last Year
transformation based on the Year, Month, and Day
attributes. Year could use an expression such as
YEAR_ID1.However, Month and Day could map to
columns in a transformation table because their IDs
are not conducive to expression-based transformation.

Member Tables

The member tables store the data for the member attributes.
For expression-based transformations, the member tables
are generally lookup tables that correspond to the attribute
being transformed, such as LU_DAY, LU_QUARTER, and so
forth. For table-based transformations, it is the
transformation table that stores the relationship.

Mapping Type

The mapping type determines the way the transformation is


created based on the nature of the data. The mapping type
can be one of the following:

One-to-oneA typical one-to-one relationship is last year


versus this year. A year maps to exactly one other year.

Many-to-manyA typical many-to-many relationship is


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

2011 MicroStrategy, Inc. What Is a Transformation? 199


5 Transformations MicroStrategy Architect: Advanced Project Design

Creating and Using Transformations

After completing this topic, you will be able to:


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 MicroStrategy Desktop, 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.

200 Creating and Using Transformations 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Transformations 5

9 Click OK.

10 In the Transformation Editor, under Transformation


mapping type, select the appropriate mapping type.

11 Click Save and Close.

12 Name and save the transformation.

13 Update the project schema.

The following image shows the Transformation Editor for the


Last Years transformation in the MicroStrategy Tutorial
project:
Last Years TransformationTransformation Editor

The Last Years transformation has four member attributes


mapped to the transformation columns in their respective
lookup tables. It has a one-to-many mapping type.

2011 MicroStrategy, Inc. Creating and Using Transformations 201


5 Transformations MicroStrategy Architect: Advanced Project Design

The following image shows the Transformation Editor for the


Month to Date transformation in the MicroStrategy Tutorial
project:
Month to Date TransformationTransformation Editor

The Month to Date transformation has a single Day member


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

202 Creating and Using Transformations 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Transformations 5

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.


4 Save and close the metric.

You can also create transformation metric as a derived


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

2011 MicroStrategy, Inc. Creating and Using Transformations 203


5 Transformations MicroStrategy Architect: Advanced Project Design

The following image shows the Last Years Revenue metric


that uses the Last Years transformation:
Last Years Revenue Metric

The following image shows the MTD Revenue metric that


uses the Month to Date transformation:
MTD Revenue Metric

204 Creating and Using Transformations 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Transformations 5

The following image shows the LY-MTD Revenue metric that


uses both the Last Years and the Month to Date
transformations:
LY-MTD Revenue Metric

2011 MicroStrategy, Inc. Creating and Using Transformations 205


5 Transformations MicroStrategy Architect: Advanced Project Design

Transformation Examples
Transformations are typically used to display time-based
trends.

A common use of transformation is to display a current


year/month/day data versus the last year/month/day data on
the same report. For example, consider a report that displays
this years revenue versus last years revenue, as shown
below:
Last Years Revenue for 2008

206 Creating and Using Transformations 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Transformations 5

Recall that the Last Years transformation applied to the Last


Years Revenue metric is defined as follows:
Last Years Transformation

Notice that the Last Years transformation has multiple


member attributes, all from the Time hierarchy, and all
pointing to transformation tables for the last (or previous)
year. Creating a transformation that is very generic in nature
and encompasses multiple attributes from a single dimension
enables report developers to create a single transformation
metric to satisfy multitude of reporting needs. The
transformation applied to the metric is dynamically evaluated
at report run time to appropriate attribute level based on the
report definition.

For a time-based transformation to work correctly,


you must have some time-related element on the
template or in the filter of a report.

2011 MicroStrategy, Inc. Creating and Using Transformations 207


5 Transformations MicroStrategy Architect: Advanced Project Design

For example, if you modify the report from the previous


example to display only the December 2008 data, the Last
Years Revenue metric values reflect only the previous years
December data, and not the aggregated data for entire 2007
year. This is shown in the image below:
Last Years Revenue for December 2008

Recall that the Last Years Revenue value for The


Rugrats Movie was $12,115.

208 Creating and Using Transformations 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Transformations 5

Another example of using transformations is displaying


month to date or year to date data. For example, consider the
Best Selling Items By Category report:
The Best Selling Items By Category Report

In this report, every metric is a transformation metric. Some


metrics are compound metrics that contain several
transformation metrics in their definition.

The MTD Revenue metric uses the Month to Date


transformation and therefore returns the revenue generated
in the current monthSeptember 2008.

The YTD Revenue metric uses the Year to Date


transformation. It returns the total revenue generated
between 1/1/2008 and 9/30/2008.

The LY-YTD Revenue metric uses two transformationsYear


to Date and Last Years. It returns the last years year-to-date
revenue generated between 1/1/2007 and 9/30/2007.

The YTD as % of LYTD metric is a compound metric


composed of the YTD Revenue and LY-YTD Revenue metrics.
It returns a comparison of this years year-to-date revenue to
the last years year-to-date revenue generated before and on
the same date (September 30). The year-to-date revenue on
9/30/2008 for all items exceeded the year-to-date revenue in
2007 for the same time period.

The BOH - QTD and EOH - QTD metrics are


beginning-on-hand and end-on-hand inventory counts for
the quarter ending on 9/30/2008. Both of these metrics use
the Quarter to Date transformation.

2011 MicroStrategy, Inc. Creating and Using Transformations 209


5 Transformations MicroStrategy Architect: Advanced Project Design

The MTD Units Sold and YTD Units Sold metrics returns the
number of units sold in the current month and year,
respectively. They use the Month to Date and Year to Date
transformations.

The YTD Average Inventory metric uses the Year to Date


transformation and returns the average inventory for the
1/1/2008 to 9/30/2008 time period.

The YTD Inventory Turnover metric is a compound metric


that returns the ratio between the number of units sold this
year to the average inventory count for the year.

Transformations are useful when you want to analyze data in


respect to time. However, transformation use is not limited to
time-based transformations. For example, you can use
transformations to compare current catalog or promotion
versus previous catalog or promotion, and so forth.

210 Creating and Using Transformations 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Transformations 5


Exercise: Create the Last Years Transformation

Overview

You will use the Forecasting Project for this exercise.

In this exercise, you will first create a Last Years


transformation that has a Year member attribute with a
[YEAR_ID] - 1 expression defined on the LU_YEAR table.

After updating schema, you will then create the Last Years
Forecast Revenue transformation metric.

You will then create the following report:

Run the report. Add the Quarter attribute to the template


and run the report again. After reviewing the result set, save
the report as Transformation Example in the Public
Objects\Reports folder.

2011 MicroStrategy, Inc. Exercise: Create the Last Years Transformation 211
5 Transformations MicroStrategy Architect: Advanced Project Design

Next, you will modify the Last Years transformation by


adding three more member expressions. The transformation
should be defined as follows:

Finally, after updating schema, you will run the


Transformation Example report and drill from 2011 Q1 to
Day to test the new member expression.

You can use the detailed instructions if you want help.

Detailed Instructions

Create the Last Years transformation

1 In the MicroStrategy Analytics Modules project source,


open the Forecasting Project.

2 In the Forecasting Project, expand the Schema Objects


folder.

3 In the Schema Objects folder, select the Transformations


folder.

4 On the File menu, point to New and select


Transformation.

5 In the Select a Member Attribute window, select Year.

212 Exercise: Create the Last Years Transformation 2011 MicroStrategy, Inc.
MicroStrategy Architect: Advanced Project Design Transformations 5

6 Click Open.

7 In the Define a new member attribute expression window,


in the Table drop-down list, select the LU_YEAR table.

8 In the Member attribute expression pane, type


[YEAR_ID] - 1.

9 Click OK.

10 Click Save and Close.

11 Save the transformation in the Schema


Objects\Transformations folder as Last Years.

Update the project schema

12 Update the project schema.

Create a transformation metric

13 In the Public Objects folder, in the Metrics folder, open


the Metric Editor.

14 Define the metric as Sum(Forecast Revenue).

15 Format metric values as currency with 0 decimal places.

16 In the Metric: New Metric is defined as pane, select


Transformation = (nothing).

17 In the Object Browser, double-click the Last Years


transformation.

2011 MicroStrategy, Inc. Exercise: Create the Last Years Transformation 213
5 Transformations MicroStrategy Architect: Advanced Project Design

Your metric should resemble the following:

18 Save the metric in the Public Objects\Metrics folder as


Last Years Forecast Revenue and close it.

214 Exercise: Create the Last Years Transformation 2011 MicroStrategy, Inc.
MicroStrategy Architect: Advanced Project Design Transformations 5

Create a report with a transformation metric

19 In the Public Objects\Reports folder, create the following


report:

You can access the Year attribute from the Time


hierarchy. You can find the Forecast Revenue
metric in the Metrics folder.

Run the report

20 Run the report. The report result set should look like the
following:

Only data for the 2011 and 2012 years is displayed, even
though there is Forecast Revenue data for 2010 in the
data warehouse. Notice that both metrics return different
values for each row, but the Forecast Revenue data for
2011 is identical to the Last Years Forecast Revenue for
2012, as expected.

Modify the report

21 Switch to Design View.

22 Add the Quarter attribute to the report template to the


right of Year.

23 Place the Total subtotal on the report.

2011 MicroStrategy, Inc. Exercise: Create the Last Years Transformation 215
5 Transformations MicroStrategy Architect: Advanced Project Design

24 Run the report. The report result set should look like the
following:

Since the Last Years transformation is not defined for the


Quarter attribute, the transformation metric is not
evaluated correctly. The metric values are identical for
both metrics in each row. This data cannot be correct,
since you already know from the previous result set that
forecast revenue for each year is different.

Save the report

25 Save the report in the Public Objects\Reports folder as


Transformation Example and close it.

Add the Quarter member attribute to the Last Years


transformation

26 In the Schema Objects folder, in the Transformations


folder, double-click the Last Years transformation.

27 In the Transformation Editor, click Add.

28 In the Select a Member Attribute window, select Quarter.

29 Click Open.

216 Exercise: Create the Last Years Transformation 2011 MicroStrategy, Inc.
MicroStrategy Architect: Advanced Project Design Transformations 5

30 In the Define a new member attribute expression window,


in the Table drop-down list, select the LU_QUARTER
table.

31 Double-click the LY_QUARTER_ID column to move it to


the Member attribute expression pane.

32 Click OK.

Add the Month member attribute to the Last Years


transformation

33 In the Transformation Editor, click Add.

34 In the Select a Member Attribute window, select Month.

35 Click Open.

36 In the Define a new member attribute expression window,


in the Table drop-down list, select the LU_MONTH table.

37 Double-click the LY_MONTH_ID column to move it to the


Member attribute expression pane.

38 Click OK.

Add the Day member attribute to the Last Years


transformation

39 In the Transformation Editor, click Add.

40 In the Select a Member Attribute window, select Day.

41 Click Open.

42 In the Define a new member attribute expression window,


in the Table drop-down list, select the LU_DAY table.

43 Double-click the LY_DAY_DATE column to move it to the


Member attribute expression pane.

44 Click OK.

Save and close the transformation

45 Save and close the transformation.

2011 MicroStrategy, Inc. Exercise: Create the Last Years Transformation 217
5 Transformations MicroStrategy Architect: Advanced Project Design

Update the project schema

46 Update the project schema.

Run the report

47 Run the Transformation Example report. The report


result set should look like the following:

This result set is correct with the quarter-level


transformation. The Forecast Revenue total for 2011 is
identical to the Last Years Forecast Revenue total for
2012, as expected.

218 Exercise: Create the Last Years Transformation 2011 MicroStrategy, Inc.
MicroStrategy Architect: Advanced Project Design Transformations 5

48 Right-click the 2011 Q1 quarter element, point to Drill,


point to Down, and select Day. The drill down report
result set should resemble the following:

The image above only displays the first few rows of


the result set for the report.

Close the reports

49 Close both reports without saving.

2011 MicroStrategy, Inc. Exercise: Create the Last Years Transformation 219
5 Transformations MicroStrategy Architect: Advanced Project Design


Lesson Summary
In this lesson, you learned:

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.

220 Lesson Summary 2011 MicroStrategy, Inc.


6
PARTITIONING

Lesson Description

This lesson covers the benefits of partitioning fact tables and


how you can support partitioned tables in MicroStrategy
Architect.

First, you will learn about the difference between the


server-level and the application-level partitioning. Then, you
will use warehouse and metadata partition mapping to
support partitioned fact tables in a MicroStrategy project.

2011 MicroStrategy, Inc. 221


6 Partitioning MicroStrategy Architect: Advanced Project Design

Lesson Objectives

After completing this lesson, you will be able to:


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.

After completing the topics in this lesson, you will be able to:

Describe the purpose of partitioning tables in a data


warehouse and define server-level and application-level
partitioning. (Page 223)

Describe and use warehouse partition mapping to support


partitioned fact tables in a MicroStrategy
project. (Page 226)

Describe and use metadata partition mapping to support


partitioned fact tables in a MicroStrategy
project. (Page 234)

222 Lesson Objectives 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Partitioning 6

Introduction to Partitioning Concepts

After completing this topic, you will be able to:


Describe the purpose of partitioning tables in a data
warehouse and define server-level and application-level
partitioning.

Partitioning is the division of a larger table into smaller


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

Databases differ dramatically in the size of the data files and


physical tables they can manage effectively. Partitioning
support varies by database. Most database vendors today
provide some support for partitioning at the database level.
Regardless, the use of some partitioning strategy is essential
in designing a manageable data warehouse. Like all data
warehouse tuning techniques, you should periodically
re-evaluate your partitioning strategy.

2011 MicroStrategy, Inc. Introduction to Partitioning Concepts 223


6 Partitioning MicroStrategy Architect: Advanced Project Design

There are two basic types of partitioning:

Server level

Application level

The following illustration shows the difference between these


two types of partitioning:
Two Types of Partitioning

Server-level partitioning involves dividing one physical table


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

Application-level partitioning involves dividing one large


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

224 Introduction to Partitioning Concepts 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Partitioning 6

MicroStrategy supports application-level partitioning for fact


tables through one of two methods:

Warehouse partition mappingThis method is based on


a physical warehouse partition mapping table (PMT) that
resides in the data warehouse and describes the
partitioned base tables that are part of a conceptual
whole.

Metadata partition mappingThis method is based on


rules logically defined in MicroStrategy Architect and
stored in the metadata.

2011 MicroStrategy, Inc. Introduction to Partitioning Concepts 225


6 Partitioning MicroStrategy Architect: Advanced Project Design

Warehouse Partition Mapping

After completing this topic, you will be able to:


Describe and use warehouse partition mapping to support
partitioned fact tables in a MicroStrategy project.

Overview
With warehouse partition mapping, you do not include the
original fact table or the partition base tables in the project.
Rather, you create and maintain a partition mapping table,
which MicroStrategy Architect uses to identify the
partitioned base tables as part of a logical whole. You only
bring the partition mapping table to the project.

To understand how you can use warehouse partition


mapping to manage partitioned base tables, consider the
following example. To ease maintenance and improve query
performance, you have divided a multibillion-row fact table
by month into a few one-billion-row fact tables. The following
illustration shows a partition mapping table that describes
how the partitioned tables fit together as a whole:
Warehouse Partition Mapping

226 Warehouse Partition Mapping 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Partitioning 6

The partition mapping table has several features that must be


included for it to work appropriately in MicroStrategy
Architect:

You can use any name for the partition mapping table.

It has a column for each attribute ID by which you


partitioned the table. These attribute IDs represent the
partitioning attributes.

You can use only ID columns to represent


partitioning attributes.

It must have an additional column whose name must be


PBTName and whose contents refer to the names of the
various partition base tables (PBTs). Partition base tables
are the actual physical partition tables that make up the
complete, logical fact table.

The PBTName column indicates to MicroStrategy


Architect that the table is a partition mapping
table.

There is a row for each of the partition base tables in the


logical whole.

When you follow these conventions, MicroStrategy Architect


automatically recognizes the partition mapping table, and
you can very easily add it to the project using the Warehouse
Catalog.

Implementing Warehouse Partition Mapping


When you use warehouse partition mapping, you add the
partition mapping table to the project in the Warehouse
Catalog. You do not add the partition base tables to the
project. When you add the partition mapping table, it
automatically associates this table with the underlying
partition base tables. After adding the partition mapping
table to the project, you also need to identify the attribute
used to partition the tables by creating a partition mapping.

2011 MicroStrategy, Inc. Warehouse Partition Mapping 227


6 Partitioning MicroStrategy Architect: Advanced Project Design

To use warehouse partition mapping in a project:

1 In MicroStrategy Desktop, open the Warehouse Catalog.

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


database instance list, select the partition mapping table
and click the > button to add it to the Tables being used in
the project list.

When you add the partition mapping table, the


number of base tables associated with the mapping
table displays in parentheses beside the partition
mapping table. You can right-click the table and
select View Partitions if you want to see the
partition base tables that are associated with the
partition mapping table.

3 Click Save and Close.

When you add a partition mapping table to a


project and save the warehouse catalog, you see a
message window that reminds you to set the
partitioning attribute level in the partition
mapping. Click OK.

4 In MicroStrategy Desktop, in the Schema Objects folder,


in the Partition Mappings folder, double-click the
partition mapping object that has the same name as the
partition mapping table you just added to the project.

5 In the Warehouse Partition Mapping Editor, on the


Logical View tab, click Add.

6 In the Partition Level Attributes Selection window, in the


Available attributes list, select the attribute by which the
tables are partitioned and click the > button to add it to
the Selected attributes list.

7 Click OK.

8 In the Warehouse Partition Mapping Editor, click Save


and Close.

9 Update the project schema.

228 Warehouse Partition Mapping 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Partitioning 6

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.

2011 MicroStrategy, Inc. Warehouse Partition Mapping 229


6 Partitioning MicroStrategy Architect: Advanced Project Design

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.

230 Warehouse Partition Mapping 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Partitioning 6

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.

2011 MicroStrategy, Inc. Warehouse Partition Mapping 231


6 Partitioning MicroStrategy Architect: Advanced Project Design

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.

232 Warehouse Partition Mapping 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Partitioning 6

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.

2011 MicroStrategy, Inc. Warehouse Partition Mapping 233


6 Partitioning MicroStrategy Architect: Advanced Project Design

Metadata Partition Mapping

After completing this topic, you will be able to:


Describe and use metadata partition mapping to support
partitioned fact tables in a MicroStrategy project.

Overview
In metadata partition mapping, the application running
against the database still manages the physically partitioned
fact tables, but the execution is different. Metadata partition
mapping does not require a partition mapping table in the
data warehouse. Instead, you define the data contained in
each partition base table in a partition mapping object in
MicroStrategy Architect. This object is stored in the
metadata. You update the partition mapping as new partition
base tables are created.

When you execute a report that runs against the partitioned


tables, the Query Engine sends the necessary prequeries to
the metadata to determine which partition base tables need
to be included in the report SQL. The SQL Engine then
generates SQL against the appropriate partition base tables
to retrieve the report results.

Implementing Metadata Partition Mapping


When you use metadata partition mapping, you add the
partition base tables to the project in the Warehouse Catalog.
After adding the partition base tables to the project, you
create the partition mapping and define the data slices for
each partition base table.

234 Metadata Partition Mapping 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Partitioning 6

To use metadata partition mapping in a project:

1 In MicroStrategy Desktop, open the Warehouse Catalog.

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


database instance list, select the partition base tables and
click the > button to add them to the Tables being used in
the project list.

3 Click Save and Close.

4 In MicroStrategy Desktop, 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.

8 In the Metadata Partition Mapping Editor, in the Tables


defining the partition mapping list, select a partition base
table.

9 Click Define.

10 In the Data Slice Editor, in the Data Slice Definition pane,


define the data contained in the partition base table.

This step is similar to defining a filter condition.


11 In the Data Slice Editor, click Save and Close.

12 Repeat steps 8 to 11 for each partition base table in the


partition mapping.

13 If you want to define a logical size for the partition


mapping, in the Metadata Partition Mapping Editor, in
the Partition mapping logical size box, type a value.

Remember to lock the logical size if you want to


preserve it when updating the project schema.

2011 MicroStrategy, Inc. Metadata Partition Mapping 235


6 Partitioning MicroStrategy Architect: Advanced Project Design

14 Click Save and Close.

15 Name and save the partition mapping.

16 Update the project schema.

The following image shows the Metadata Partition Mapping


Editor:
Metadata Partition Mapping

This example shows 12 partition base tables partitioned by


quarter. You can see that Q1 2006 is the data slice defined for
the INVENTORY_Q1_2006 table. Similarly, the remaining
tables correspond to their respective quarters.

236 Metadata Partition Mapping 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Partitioning 6


Lesson Summary
In this lesson, you learned:

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.

2011 MicroStrategy, Inc. Lesson Summary 237


6 Partitioning MicroStrategy Architect: Advanced Project Design

When you use metadata partition mapping, you add the


partition base tables to the project in the Warehouse
Catalog.

When you execute a report that runs against the


partitioned tables, before the SQL Engine generates the
report SQL, the Query Engine first sends the necessary
prequeries to the metadata to determine which partition
base tables need to be included in the report SQL.

238 Lesson Summary 2011 MicroStrategy, Inc.


INDEX

A creating a fact extension using the cross


product method 177
adding aggregate fact tables to a creating a fact extension using the fact re-
project 41 lation method 172
adding tables with a single data source 97 creating a fact extension using the table re-
adding tables with multiple data lation method 165
sources 102 creating a multisource report 119
aggregate fact tables, using them in a creating objects for multisource
project 41 reports 115
aggregate-aware 41 creating table-based transformations 203
application-level partitioning 224 creating the project in MicroStrategy Ar-
Architect, basic schema objects 22 chitect, overview 20
associating tables to database cross product method for fact extension,
instances 96 steps 176
attributes 22 cross product method, creating a fact
extension 177
B
basic schema objects 22 D
data mart 46
C creating 53
database instances 48
changing logical table size 42
objects 48
changing the primary database instance
optimization 50
for a table 108
options 56
compatibility rules, data types 89
updating fact 61
creating a fact degradation 152
updating warehouse catalog 61

2011 MicroStrategy, Inc. 239


Index MicroStrategy Architect: Advanced Project Design

using in a project 60 method 172


data type compatibility rules 89 extension, creating using the table relation
database instance method 165
data mart 48 extension, fact 147
database instances, associating to
tables 96 F
database instances, removing from
tables 113 fact degradation 147, 148
database instances, table level 81, 82 fact degradation, creating 152
database partitioning 224 fact degradation, steps 150
degradation, creating 152 fact disallow 147, 179
degradation, fact 147 fact extension 147, 156
degradation, steps 150 fact extension using cross product method,
steps 176
degrading fact levels 148
fact extension using fact relation method,
designating primary and secondary
steps 169
tables 86
fact extension using table relation method,
designing the logical data model,
steps 159
overview 20
fact extension, creating using the cross
different data sources, joining data 89
product method 177
disallow, fact 147
fact extension, creating using the fact rela-
disallowing fact levels 179 tion method 172
duplicate tables 83 fact extension, creating using the table re-
lation method 165
E fact extensions, methods 158
fact level 145
Engine, data type compatibility rules 89
fact level extensions 146
exercises
fact level extensions, overview 145
data mart 64
fact level extensions, types 147
expression-based transformations 195
fact levels, degrading 148
extending fact levels 156
fact levels, disallowing 179
extending fact levels, methods 158
fact levels, extending 156
extension using cross product method,
fact relation method for fact extension,
steps 176
steps 169
extension using fact relation method,
fact relation method, creating a fact
steps 169
extension 172
extension using table relation method,
fact tables, selecting the optimal data
steps 159
source 87
extension, creating using the cross product
facts 22
method 177
filtering qualifications, MultiSource
extension, creating using the fact relation

240 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Index

Option 93 cases 91
multisource reports, creating 119
multisource reports, creating objects 115
H
multisource reports, data type compatibil-
hierarchies 22 ity rules 89
multisource reports, processing of
I SQL 120
multisource reports, SQL generation 85
introduction to MultiSource Option 81

O
J
objects, multisource reports 115
joining data from different data
optimal data source, fact tables 87
sources 89
optimal data source, lookup tables 88
overview, creating the project in Mi-
L croStrategy Architect 20
level, fact 145 overview, designing the logical data
Logical Size Editor 44 model 20
Logical Table Editor 42 overview, managing the project
schema 20
logical table size, changing 42
logical table size, role in SQL
generation 41 P
lookup tables, selecting the optimal data partition base tables 224, 227
source 88
partition mapping 23
partition mapping table 225, 227
M partition mapping, metadata 23, 225, 234
managing the project schema, partition mapping, warehouse 23, 225
overview 20 partitioning 223
metadata partition mapping 225, 234 partitioning attributes 227
methods, fact extensions 158 partitioning, application-level 224
multiple data sources, joining data 89 partitioning, database-level 224
multiple data sources, tables 102 partitioning, server-level 224
MultiSource Option, filtering PBTs 227
qualifications 93 PMT 225, 227
MultiSource Option, introduction 81 primary database instances, changing for
MultiSource Option, split fact tables 91 tables 108
MultiSource Option, split lookup primary database instances, table level 81,
tables 92 82
MultiSource Option, supported use primary tables 86

2011 MicroStrategy, Inc. 241


Index MicroStrategy Architect: Advanced Project Design

processing of SQL, multisource steps, fact extension using fact relation


reports 120 method 169
project design process, creating the project steps, fact extension using table relation
in MicroStrategy Architect 20 method 159
project design process, designing the logi- support for duplicate tables 83
cal data model 20 supported use case, filtering
project design process, managing the proj- qualifications 93
ect schema 20 supported use case, split fact tables 91
project, using aggregate fact tables 41 supported use case, split lookup tables 92
project-wide options, Warehouse supported use cases, MultiSource
Catalog 36 Option 91

R T
removing a database instance from a table relation method for fact extension,
table 113 steps 159
table relation method, creating a fact
extension 165
S
table-based transformations 195
schema objects 22
table-based transformations, creating 203
schema objects, basic 22
table-level database instances 81, 82
secondary database instances, table
tables 22
level 81, 82
tables, associating to database
secondary tables 86
instances 96
selecting the optimal data source, fact
tables, changing primary database
tables 87
instances 108
selecting the optimal data source, lookup
tables, multiple data sources 102
tables 88
tables, primary 86
server-level partitioning 224
tables, removing database instances 113
single data source, tables 97
tables, secondary 86
split fact tables, MultiSource Option 91
tables, single data source 97
split lookup tables, MultiSource
Option 92 transformation 193
SQL generation, data type compatibility transformation components 198
rules 89 transformation metrics 193, 203
SQL generation, logical table size 41 transformation types 195
SQL generation, multisource reports 85 transformations 23, 193
SQL, multisource reports 120 transformations, creating 200
steps, fact degradation 150 transformations, expression based 195
steps, fact extension using cross product transformations, table based 195
method 176 types of fact level extensions 147

242 2011 MicroStrategy, Inc.


MicroStrategy Architect: Advanced Project Design Index

U
use case, filtering qualifications 93
use case, split fact tables 91
use case, split lookup tables 92
use cases, MultiSource Option 91

W
Warehouse Catalog, project-wide
options 36
warehouse partition mapping 225

2011 MicroStrategy, Inc. 243


Index MicroStrategy Architect: Advanced Project Design

244 2011 MicroStrategy, Inc.