Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Course Guide
Version: ADVPD-941-MAR14-CG
U.S. Government Restricted Rights. It is acknowledged that the Course and Software were developed at private
expense, that no part is public domain, and that the Course and Software are Commercial Computer Software and/or
Commercial Computer Software Documentation provided with RESTRICTED RIGHTS under Federal Acquisition
Regulations and agency supplements to them. Use, duplication, or disclosure by the U.S. Government is subject to
restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at
DFAR 252.227-7013 et. seq. or subparagraphs (c)(1) and (2) of the Commercial Computer 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.
Copyright Information
Trademark Information
MicroStrategy Support, MicroStrategy Telecaster, MicroStrategy Transactor, MicroStrategy Web, MicroStrategy Web
Business Analyzer, MicroStrategy World, Application Development and Sophisticated Analysis, Best In Business
Intelligence, Centralized Application Management, Information Like Water, Intelligence Through Every Phone,
Intelligence To Every Decision Maker, Intelligent E-Business, Personalized Intelligence Portal, Query Tone, Rapid
Application Development, MicroStrategy Intelligent Cubes, The Foundation For Intelligent E-Business, The Integrated
Business Intelligence Platform Built For The Enterprise, The Platform For Intelligent E-Business, The Scalable
Business Intelligence Platform Built For The Internet, Office Intelligence, MicroStrategy Office, MicroStrategy Report
Services, MicroStrategy Web MMT, MicroStrategy Web Services, Pixel Perfect, Pixel-Perfect, MicroStrategy Mobile,
MicroStrategy Integrity Manager and MicroStrategy Data Mining Services are all registered trademarks or trademarks
of MicroStrategy Incorporated.
All other company and product names may be trademarks of the respective companies with which they are associated.
Specifications subject to change without notice. MicroStrategy is not responsible for errors or omissions.
MicroStrategy makes no warranties or commitments concerning the availability of future products or versions that
may be planned or under development.
Patent Information
This product is patented. One or more of the following patents may apply to the product sold herein: U.S. Patent Nos.
6,154,766, 6,173,310, 6,260,050, 6,263,051, 6,269,393, 6,279,033, 6,567,796, 6,587,547, 6,606,596, 6,658,093,
6,658,432, 6,662,195, 6,671,715, 6,691,100, 6,694,316, 6,697,808, 6,704,723, 6,741,980, 6,765,997, 6,768,788,
6,772,137, 6,788,768, 6,798,867, 6,801,910, 6,820,073, 6,829,334, 6,836,537, 6,850,603, 6,859,798, 6,873,693,
6,885,734, 6,940,953, 6,964,012, 6,977,992, 6,996,568, 6,996,569, 7,003,512, 7,010,518, 7,016,480, 7,020,251,
7,039,165, 7,082,422, 7,113,993, 7,127,403, 7,174,349, 7,181,417, 7,194,457, 7,197,461, 7,228,303, 7,260,577, 7,266,181,
7,272,212, 7,302,639, 7,324,942, 7,330,847, 7,340,040, 7,356,758, 7,356,840, 7,415,438, 7,428,302, 7,430,562,
7,440,898, 7,486,780, 7,509,671, 7,516,181, 7,559,048, 7,574,376, 7,617,201, 7,725,811, 7,801,967, 7,836,178, 7,861,161,
7,861,253, 7,881,443, 7,925,616, 7,945,584, 7,970,782, 8,005,870, 8,051,168, 8,051,369, 8,094,788, 8,130,918,
8,296,287, 8,321,411 and 8,452,755. Other patent applications are pending.
How to Contact Us
MicroStrategy University
1850 Towers Crescent Plaza
Tysons Corner, VA 22182
Phone: 877.232.7168
Fax: 703.848.8602
E-mail: education@microstrategy.com
http://www.microstrategy.com/training-events
MicroStrategy Incorporated
1850 Towers Crescent Plaza
Tysons Corner, VA 22182
Phone: 703.848.8600
Fax: 703.848.8610
E-mail: info@microstrategy.com
http://www.microstrategy.com
Table of Contents
TABLE OF CONTENTS
Preface
Course Description...................................................................... 9
Who Should Take this Course ............................................... 10
Course Prerequisites ............................................................. 10
Follow-up Courses ................................................................. 10
Related Certifications............................................................. 10
Course Objectives ................................................................. 11
About the Course Materials ......................................................... 12
Content Descriptions ............................................................. 12
Learning Objectives ............................................................... 12
Lessons ................................................................................. 12
Opportunities for Practice ...................................................... 13
Typographical Standards ....................................................... 13
MicroStrategy Courses .......................................................... 15
Core Courses......................................................................... 15
Advanced Courses ................................................................ 16
1. Introduction to
Advanced Project
Design
Table of Contents
2. Managing Project
Schema
3. Using MicroStrategy
MultiSource Option
Table of Contents
5. Transformations
6. Partitioning
Table of Contents
A. Warehouse Catalog
PREFACE
Course Description
This one day course covers advanced features involved in the
creation and maintenance of a MicroStrategy project. The
course assumes an understanding of basic report
development concepts from the two day MicroStrategy
Developer: Reporting Essentials course and the two day
MicroStrategy Architect: Project Design Essentials course.
First, students will learn how to manage project data sources
using primary and secondary database instances and how to
maintain a project schema with the Architect graphical
interface. Next, students will learn how the MicroStrategy
Engine is aggregate-aware and how to create aggregate tables
using data marts. Next, students will learn how to use
MicroStrategy MultiSource Option to configure projects to
access heterogeneous data sources. Finally, students will
learn about fact level extensions, transformations, and
partition mappings.
After taking this course, students will understand how to
maintain MicroStrategy projects and how to build advanced
schema objects.
Preface
Project architects
Course Prerequisites
Before starting this course, you should know all topics covered in the following
courses:
Follow-up Courses
After taking this course, you might consider taking the following courses:
Related Certifications
This course does not have any recommended follow-up certifications.
Preface
Course Objectives
After completing this course, you will be able to:
Describe the project design process, and describe the basic and advanced
schema objects you can create with MicroStrategy Architect. (Page 18)
Define the primary and secondary database instance, use the Architect
graphical interface to maintain project tables, describe how the
MicroStrategy SQL Engine is aggregate aware, and create aggregate fact
tables using data marts. (Page 28)
Describe how you can use MultiSource Option to access heterogeneous data
sources, associate tables in a project to multiple database instances, create
objects for multisource reports, and create multisource reports. (Page 74)
Course Objectives
11
Preface
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:
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.
Preface
Typographical Standards
Following are explanations of the font style changes, icons, and different types
of notes that you see in this course.
Actions
References to screen elements and keys that are the focus of actions are in bold
Arial font style. The following example shows this style:
Click Select Warehouse.
Code
References to code, formulas, or calculations within paragraphs are formatted
in regular Courier.New font style. The following example shows this style:
Sum(Sales)/Number of Months
13
Preface
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.
Preface
MicroStrategy Courses
Core Courses
15
Preface
Advanced Courses
All courses are subject to change. Please visit the MicroStrategy Web site for the latest education offerings.
1
INTRODUCTION TO ADVANCED
PROJECT DESIGN
Lesson Description
This lesson introduces you to the MicroStrategy Architect: Advanced Project
Design course.
In this lesson, you will first review the project design process and learn about
the tools and components that enable you to manage the project schema. Next,
you will review the basic schema objects that you can create in MicroStrategy
Architect. Finally, you will learn about additional schema objects that enable
you to perform advanced functions.
17
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
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.
19
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:
21
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:
In the MicroStrategy Architect: Advanced Project Design course, you will learn
about additional properties of facts. You will learn how to create different types
of fact extensions that will enable you to report on facts at additional levels,
beyond how they are stored in the data warehouse.
You can also create other types of schema objects in MicroStrategy that you use
for more advanced functions:
23
Column AliasThis tab enables you to modify the column alias for a fact.
All facts have a definition and column alias, but level extensions for facts are
optional. You already know about the first two tabs from the Project Design
Essentials course. You will learn more about extensions later in this course.
25
Lesson Summary
In this lesson, you learned:
The project design process involves the following steps: designing the
logical data model, designing the data warehouse schema, creating the
project in MicroStrategy Architect, and managing the project schema.
As part of managing the project schema, you will learn how to define
primary and secondary database instances, understand
aggregation-awareness, create data marts, enable multisource report
execution, and use fact editors.
You can also create other types of schema objects in MicroStrategy such
as transformations and partition mappingsthat you use for more
advanced functions.
The Fact Editor is one of the schema object editors available in Developer.
It enables you to create or modify any type of fact or fact expression and
configure a variety of fact-related settings.
26 Lesson Summary
2
MANAGING PROJECT SCHEMA
Lesson Description
This lesson covers a variety of advanced topics that enable you to maintain a
MicroStrategy project as it changes over time and help you optimize
performance within your project.
In this lesson, you will review the concept of primary and secondary database
instances. You will then learn about options that enable you to maintain
project tables. You will also learn how the MicroStrategy SQL Engine is
aggregate aware. Finally, you will learn how to create aggregate fact tables
using data marts. You will learn what a data mart is, how to create data mart
reports and data mart tables, and how to incorporate data mart tables into a
project.
27
Lesson Objectives
After completing this lesson, you will be able to:
Define the primary and secondary database instance, use the Architect
graphical interface to maintain project tables, describe how the MicroStrategy
SQL Engine is aggregate aware, and create aggregate fact tables using data
marts.
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 Tables pane options in the Architect graphical
interface can help you maintain a project over time. (Page 32)
Describe how MicroStrategy Architect calculates logical table size, and how
the SQL Engine uses logical table size to select the optimal table for a
query. (Page 35)
Define a data mart, and list and define data mart objects; create a data mart
table by creating and executing a data mart report; list and define data mart
column creation options, and use a data mart table in a project. (Page 40)
28 Lesson Objectives
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.
create and configure database instances, you must have the
Toappropriate
administrative privileges.
more information about Freeform SQL reports, refer to the
For
MicroStrategy Freeform SQL Essentials course.
also create and configure a database instance to connect to an MDX
You
data source. For more information on MDX reports, refer to the MDX
Cube Reporting Guide product manual.
29
31
Maintaining Warehouse
After completing this topic, you will be able to:
Describe how the Warehouse Tables pane options in the Architect graphical
interface can help you maintain a project over time.
You already learned how to use the Warehouse Tables pane in Architect
graphical interface to select the data warehouse tables you want to use in a
MicroStrategy project. Now, you will learn about other options available that
enable you to maintain a project.
Maintaining Tables
After you add warehouse tables to a project and create schema and application
objects, you may find that the warehouse schema changes over time. The
database administrator may alter the structure of a table, for example, by
adding additional columns. Some table sizes may grow over time, while others
remain the same, making them better candidates for aggregate queries. Some
tables may become obsolete and may be removed from the warehouse.
32 Maintaining Warehouse
The Warehouse Tables pane provides the following options for individual
tables:
Update StructureIf the table structure has changed since you added the
table to the project, you can click Update Structure to force MicroStrategy
Architect to recognize the changes.
Show Sample DataThis option enables you to view the first 100 rows of
data in a table.
Maintaining Warehouse
33
can view a tables structure before you add it to the project. To show
You
the columns in a table, click expand.
34 Maintaining Warehouse
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.
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.
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.
Aggregation Awareness
35
In a data warehouse, you often have multiple aggregate fact tables for the same
fact or set of facts to enable you to more quickly analyze fact data at various
levels of detail.
guidelines on building aggregate fact tables, refer to the
For
MicroStrategy Advanced Data Warehousing course.
36 Aggregation Awareness
MicroStrategy Architect assigns a size to every table when you initially add
them to a project. These size assignments are stored in the metadata.
MicroStrategy Architect assigns sizes based on the columns in the tables and
the attributes to which those columns correspond. Because MicroStrategy
Architect uses the logical attribute definitions to assign a size to each table in
the project, this measurement is referred to as logical table size.
The following illustration is a visual representation of the algorithm used by
MicroStrategy Architect in assigning logical table sizes:
Calculating the Logical Table Size
Logical table size is the sum of the weight for each attribute contained in the
table. Attribute weight is defined as the position of an attribute in its hierarchy
divided by the number of attributes in the hierarchy, multiplied by a factor of
10. Using this formula, MicroStrategy Architect calculates the respective
weight of each attribute as shown in the illustration above. The logical table
size of each fact table is simply the sum of its respective attribute weights.
You can view the logical table size for each table in the Logical Table Editor.
When the SQL Engine can obtain data from two or more tables in the
warehouse, it looks at the logical table size and generates SQL against the table
with the smallest logical table size. This process helps the SQL Engine select
the optimal table for a query.
Aggregation Awareness
37
1 On the Design tab, in the Editors section, click Edit logical size of tables
button.
38 Aggregation Awareness
2 In the Logical Size Editor, for the table you want to modify, in the Size value
box, type a new logical table size value.
3 If you want to preserve the logical table size of a table, select its Size locked
check box.
4 Click OK to close the Logical Size Editor.
The following image shows the Logical Size Editor:
Changing Logical Size in the Logical Size Editor
should select Size Locked option if you want to ensure that the
You
logical size you have selected is not overwritten by MicroStrategy
Aggregation Awareness
39
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, and use a data mart table in a project.
Creating tables for very large result sets and then using other applications
such as Microsoft Excel or Microsoft Access to access the data
In this lesson, you will use data marts to create aggregate fact tables.
can use data marts in other usage scenarios. Combining data marts
You
with MicroStrategy data mining features or with Freeform SQL reports
are two such scenarios.
40 Data Marts
In this example, forecasting data is stored at the employee and date level in the
FORECAST_SALES base fact table. However, you want to report on the
Forecast Unit Sold at the Region level. This requires three joins from the fact
table to the LU_REGION lookup table. In addition, the FORECAST_SALES
table may have millions of rows. This query may be very costly, especially if
users request it often.
What if you could create an aggregate table that limits the number of joins and
the number of rows in the fact table? You can achieve this by creating a data
mart table. You can then bring this table into your project, map the Forecast
Unit Sales and metric to it, and have your region-level reports automatically
use it, as shown below:
Aggregate Fact Table Created as Data Mart
Data Marts
41
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.
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.
42 Data Marts
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.
Data Marts
43
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.
instructions on how to associate a secondary database instance to a
For
project, see To associate a secondary database instance with a project:
starting on page 30.
When you click Yes, the Database Instances editor for the data mart database
instance opens with the Advanced tab automatically selected.
mart optimization occurs when you create a data mart in the
Data
primary project database instance or in a database instance that points
to the same data warehouse as the primary project 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.
44 Data Marts
the data mart database instance does not reside in the same
Ifwarehouse
as the project database instance, do not select this check
box.
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.
Data Marts
45
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
group by a11.Month_Id
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.
46 Data Marts
1 In the Report Editor, on the Data menu, select Configure Data Mart.
report template must contain an attribute, a metric, or some
The
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
!O
report name
???
!!!
!a
!j
job ID
!r
report GUID
!t
timestamp
!p
project name
!z
project GUID
!s
Data Marts
47
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.
information on the data mart governors, table creation
For
properties, and SQL statements refer to the Advanced Reporting
Guide product manual.
48 Data Marts
You can then convert this report into a data mart. The following image shows
the Report Data Mart Setup Window with data mart report configured as
REGION_YEAR_FORECAST_UNIT_SALES table in the Forecast Data
database instance:
Report Data Mart Setup Window
The following image shows a message displayed by the data mart report when
it is executed:
Data Mart Execution Complete Message
Data Marts
49
You can control what attribute columns are included in the data mart table.
You can determine the names for the columns that contain the metric
calculations.
Attribute Columns
A data mart table contains an attribute ID column for each attribute selected in
the data mart report. Additionally, depending on the default display for each
attribute in the data mart report, the data mart table can also include attribute
description columns.
you would remove any non-ID form descriptions from the
Generally,
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.
50 Data Marts
Data Marts
51
The following image shows the Attribute Display window with the Region
attribute configured to use only the ID form:
Attribute Display Options
52 Data Marts
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
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).
Data Marts
53
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
54 Data Marts
5 Click OK.
6 On the toolbar, click Save and Close.
The following image shows the REGION_YEAR_FORECAST_UNIT_SALES
table added to the project:
REGION_YEAR_FORECAST_UNIT_SALES Added to the Project
Data Marts
55
1 In Architect graphical interface, edit the fact that is used in the metric of the
data mart report.
relationship of the metric to the fact on which it is based is
The
referred to as a child dependency. In Developer, you can use
2 In the Project Tables view tab, locate the table that contains the fact and
right-click to edit the fact on which the data mart metric is based.
3 In the Fact Editor, create a new fact expression that uses the data mart table
as a source table.
the fact column in the data mart table is named the same as the
Ifunderlying
fact, you may select the Automatic mapping method for the
new fact expression. By default, when you create a data mart table, the
fact has a unique name that is different from the other facts in the
project.
4 Click OK.
56 Data Marts
The following image shows the Forecast Units Sold fact mapped to the data
mart aggregate table:
Mapping a Fact to a Data Mart Table
Data Marts
57
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.
Base fact tables are tables that store a fact or set of facts at the lowest
possible level of detail. Aggregate fact tables are tables that store a fact or
set of facts at a higher, or summarized, level of detail.
To use aggregate tables in the project, you first add the table to the project
using the Warehouse Tables pane in Architect graphical interface. If
necessary, you also map the existing attributes and facts to the aggregate
table.
Logical table size is the sum of the weight for each attribute contained in the
table. Attribute weight is defined as the position of an attribute in its
hierarchy divided by the number of attributes in the hierarchy multiplied by
a factor of 10.
You can change the logical table size either in the Logical Size Editor or
from the Properties pane in Architect graphical interface.
A data mart is a relational table containing a report result set. A data mart
consists of two objects: the data mart report and the data mart table.
You can use data marts to create aggregate tables and tables based on large
report result sets.
58 Lesson Summary
Data mart reports are created in the Report Editor of a new or existing
report. After you execute the data mart report, the data mart table is created
in the chosen warehouse.
You can choose to create only attribute ID columns in the data mart table by
removing all non-ID forms from the attribute display and report objects in
the data mart report.
For the columns in the data mart table that contain metric calculations, you
can use the existing metric name as the column name or you can create a
new column alias.
To use a data mart table in a project, you must add it to the project using the
Warehouse Tables pane in Architect graphical interface, update the
corresponding fact, and then update the project schema.
Lesson Summary
59
60 Lesson Summary
Exercises: Managing Project Schema
Forecasting Project Information
You should complete the following exercises using the Forecasting Project,
which is found in the MicroStrategy Analytics Modules project source. The
logical data model and schema for this project are included with the exercises.
You need to review this information before beginning the exercises.
will also use the Forecasting Project to complete other exercises
You
throughout this course.
The Forecasting Project is based on the following logical data model:
Forecasting Project Logical Data Model
61
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
63
Detailed Instructions
Modify metric alias
9 In the Public Objects folder, in the Reports folder, create the following
report:
Forecast Revenue and Forecast Units Sold metrics are located in the
Metrics folder.
65
18 Click the lower < button to remove the DESC form from the Report objects
forms list.
19 In the Attribute Display window, in the Attribute drop-down list, select
Quarter.
20 Under Select one of the display options below, click Use the following
attribute forms.
21 In the Available forms list, select the ID form.
22 Click the upper > button to move the ID form to the Displayed forms list.
23 In the Displayed forms list, select the DESC form.
24 Click the upper < button to remove the DESC form from the Displayed
forms list.
25 In the Report objects forms list, select the DESC form.
26 Click the lower < button to remove the DESC form from the Report objects
forms list.
27 Click OK.
Configure the data mart
28 In the Report Editor, on the Data menu, select Configure Data Mart.
29 In the Report Data Mart Setup window, on the General tab, in the Data
mart database instance drop-down list, ensure the Forecast Data database
instance is selected.
30 In the Table name box, type REGION_FORECAST_SALES.
31 Click OK.
32 In the Report Data Mart Setup window, click OK.
33 Save the report in the Public Objects\Reports folder as Regional Forecast
Revenue
34 Run the report.
After the report executes, you see a message that the result data has been
stored in the REGION_FORECAST_SALES table, as shown below:
43 In the Project Tables View tab, find the FORECAST_SALES table and select
the Forecast Revenue fact.
67
49 In the Project Tables View tab, find the FORECAST_SALES table and select
the Forecast Units Sold fact.
50 Right-click the Forecast Units Sold fact and select Edit.
51 In the Fact Editor, create a new fact expression that uses the
Total_Unit_Sales column in the REGION_FORECAST_SALES table as a
source table.
52 Under Mapping method, ensure Automatic is selected.
53 Click OK.
54 Click OK to close the Fact Editor.
Verify the attribute source tables
63 View the report in SQL View. The SQL should look like the following:
In the FROM clause, notice that the data is retrieved from the new
aggregate table REGION_FORECAST_SALES.
69
64 Save the report in the Public Objects/Reports folder as Data Mart Test and
close the report.
Change the logical table size for the aggregate table
Test the change of the logical table size on the report SQL
72 In Developer, in the Reports folder, right-click the Data Mart Test report
and select View SQL. The SQL should look like the following:
Notice that this time, the Engine picked the base FORECAST_SALES table
over the aggregate REGION_FORECAST_SALES table because it has a
smaller logical table size.
73 Close the report without saving it.
71
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.
73
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:
Associate tables with single or multiple data sources, change the primary
database instance for a table, and remove a database instance from a
table. (Page 88)
Create a report that contains objects from multiple data sources and
describe how the Engine processes the SQL for such reports. (Page 104)
74 Lesson Objectives
By default, the objects in a standard report 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
If you want to create a report that includes the revenue and forecast revenue
data for each region, you must execute SQL against both data warehouses to
retrieve the result set. You obtain the data for each of the metrics from their
respective data warehouses. And you can also obtain the region data from
either data warehouse, since it exists in both databases. MultiSource Option
enables you to create this type of report.
75
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 can add tables to the project from different database instances, not just
the primary database instance for the project.
SQL database instance that exists within the project source is
Any
available to the project as a secondary database instance from which
you can select tables.
You can associate a single project table with multiple database instances,
which essentially creates duplicate tables.
However, keep in mind that MultiSource Option has the following limitations:
You can use MultiSource Option to connect to any data source that you
access using an ODBC driver, including Microsoft Excel files and text
files. You cannot use MultiSource Option to connect to MDX or other
non-relational data sources.
MultiSource Option does not support fact tables partitioned across multiple
data sources.
more information about partitioning, see the Partitioning
For
lesson starting on page 199.
When you bring duplicate tables to the project, you must consider the
following guidelines required by MultiSource Option:
Corresponding columns in duplicate tables must either have the same data
type or compatible data types.
maintain data consistency, the Engine applies data type
Tocompatibility
rules when it joins columns in tables from different
database instances. For information on these rules, see Joining
Data from Different Data Sources starting on page 81.
The number of columns in the table associated with the primary database
instance has to be less than or equal to the number of columns in the table
associated with the secondary database instance. Any extra columns in the
secondary table are not imported into the project.
duplicate tables have the same number of columns.
Ideally,
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.
77
In this example, the two fact tables each map to only one database. The
primary database instance for the REGION_SALES table is the Sales Data
Warehouse. The primary database instance for the FORECAST_SALES table is
the Forecast Data Warehouse.
However, the LU_REGION table exists in both data warehouses, so you can
map it to both database instances as duplicate lookup tables. You can assign
either data warehouse as the primary or secondary database instance for this
table.
If you designate the Sales Data Warehouse as the primary database instance
for this table, the LU_REGION table from that database is the primary table.
The LU_REGION table from the Forecast Data Warehouse is the secondary
table.
79
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.
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.
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.
same logic also applies if the Engine has to retrieve attribute
This
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).
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.
81
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:
BigDecimal
BigDecimal
Binary
Binary
CellFormatData
CellFormatData
Char
Char, VarChar
Date
Date, TimeStamp
Decimal
Double
Float
Integer
LongVarBin
LongVarBin
LongVarChar
LongVarChar
NChar
NChar
Numeric
NVarChar
NVarChar
Real
Time
Time, TimeStamp
TimeStamp
Unsigned
Unsigned
VarBin
VarBin
VarChar
Char, VarChar
The data type of a column is based on the Engine data type definition, not the
data type definition in the physical database.
These two data type definitions may not always be the same.
Often, different data sources are optimal for different passes in the SQL for a
report. For such queries, the Engine follows the data type compatibility rules
and moves data between the different data sources until it finishes processing
the result set.
83
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.
The lookup tables that relate the Category, Subcategory, and Item attributes
are stored in the Sales Data Warehouse. Forecast revenue is stored at the item
level in the Forecast Data Warehouse. You need to aggregate this data to the
category level to calculate the forecast revenue for the report. However, the
Forecast Data Warehouse stores only the relationship between Item and
Subcategory. Therefore, this aggregation requires you to join the item-level
forecast revenue data to the category data using the lookup tables in the Sales
Data Warehouse.
Filtering Qualifications
You may also have reports where you need to filter data from one data source
by qualifying on data that comes from another data source.
The following image shows an example that involves a metric qualification:
Metric Qualification
The report contains a filter based on the Forecast Revenue metric. This fact
data is stored in the Forecast Data Warehouse. However, you use this filter to
qualify on the revenue for each category, which is stored in the Sales Data
Warehouse.
85
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:
Using separate data sources for simple versus more complex queries
Now that you have learned how MultiSource Option works, you are ready to
learn how to configure a project for heterogeneous data access.
you can use MultiSource Option with standard reports, you
Although
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.
87
Tutorial Data is the primary data warehouse for the project. It contains a
variety of lookup, relationship, and fact tables. It stores the actual revenue
data.
Forecast Data is a data warehouse that contains some duplicated information
from Tutorial Data, including the LU_COUNTRY and LU_REGION tables. It
also contains the FORECAST_SALES base fact table and the
REGION_FORECAST_SALES aggregate fact table, which are not in Tutorial
Data. These fact tables store forecast revenue data.
this lesson, you will analyze two scenarios for joining data from
Inmultiple
sources. One scenario uses the aggregate fact table and
For any report where you want to include information about actual and
forecast revenue, you need to access tables in both of these data warehouses
and join the data to produce the result set. To make a report like this possible,
you need to add the tables from Forecast Data to the MicroStrategy Tutorial
project.
You can add tables to a project from other database instances using the
Architect graphical interface.
89
1 In Developer, open the project to which you want to add the tables.
2 Open the Architect graphical interface.
3 In the Architect graphical interface, do one of the following:
If the secondary database instance is already associated with the project,
continue to step 4.
OR
If the secondary database instance is not associated with the project, in the
Warehouse Tables pane, right-click anywhere and select Select Database
Instance.
In the Select Database Instance window, select the database instance you
want to associate with the project.
Click OK.
4 In the Warehouse Tables pane, expand the database instance that contains
the tables you want to add.
5 Select the tables you want to add.
6 Drag the selected tables to the Project Tables View tab.
tables display on the Project Tables View tab. The color mapping
The
for the tables indicates their association with the selected database
instance.
The following image shows the Architect graphical interface with the
FORECAST_SALES and REGION_FORECAST_SALES tables added to the
project:
FORECAST_SALES and REGION_FORECAST_SALES Tables Added to
Project
The color mapping shows that these tables are associated with Forecast Data,
not Tutorial Data.
91
6 In the warning window, under Available options, ensure the Indicate that
<Table Name> is also available from the current DB Instance option is
selected.
you click the Make no changes to <Table Name> option, the
Iftable
is not mapped to the selected database instance, and no
duplicate table is created.
93
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.
95
For example, in the sample scenario, there are two tables that map to both data
sources:
Tables with Multiple Data Sources
LU_COUNTRY and LU_REGION exist in both the Tutorial Data and Forecast
Data data warehouses. These tables were first added to the project using
Tutorial Data, so it is the primary database instance for these tables. However,
you can change the primary database instance for either of these tables from
Tutorial Data to Forecast Data.
You can use either the Architect graphical interface to change the primary
database instance for a table.
To change the primary database instance for a table in the Architect graphical
interface:
6 Beside the current primary database instance, click the Browse button:
97
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.
you do not want to remove the table from the project
Insincesuchthatcases,
removes its association to all database instances.
The same Available Database Instance window that you used to change the
primary database instance of a table in Architect graphical interface can be
used to remove a database instance from a table.
the database instance you want to remove is the primary database
Ifinstance,
you must change the primary database instance first. This
action removes the association between the database instance and the
table.
99
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.
that do not use the Automatic mapping method,
Ifyouyouhavehavetoattributes
manually map the duplicate tables to the corresponding
attributes.
101
103
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.
105
This first image shows the SQL passes the Engine uses to calculate the Revenue
metric in the report:
SQL for Calculating the Revenue Metric
Since revenue data is stored only in Tutorial Data, the Engine performs this
calculation in that database. The first SQL pass creates a temporary table in
which to store the revenue for each region. The second SQL pass aggregates the
revenue for each region using a fact table in Tutorial Data and inserts it into the
temporary table.
This second image shows the SQL passes the Engine uses to calculate the
Forecast Revenue metric in the report:
SQL for Calculating the Forecast Revenue Metric
Since forecast revenue data is stored only in Forecast Data, the Engine
performs this calculation in that database. The first SQL pass calculates the
forecast revenue for each region using the aggregate fact table in Forecast Data.
The second SQL pass creates a temporary table in Tutorial Data in which to
store the forecast revenue for each region. The third SQL pass inserts the
forecast revenue data for each region into the temporary table in Tutorial Data.
data is moved from one data source to another, the SQL view of a
When
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.
minimize the movement of data, the Engine performs the final
Toconsolidation
pass using the database instance in which the most
are the primary database instance for the project, the Engine selects the
database instance with the smallest GUID (alphabetically).
This last image shows the SQL pass the Engine uses to produce the final result
set for the report:
SQL for Consolidating the Result Set
This SQL pass retrieves the region descriptions from a lookup table in Tutorial
Data. Then, it retrieves the region IDs and revenue and forecast revenue for
each region from the appropriate temporary tables to produce the final result
set.
107
the consolidation pass, the Engine also generates SQL to drop each
After
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
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.
updating the project schema, you may have to purge the report
After
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.
109
This first image shows the SQL passes the Engine uses to calculate the Revenue
metric in the report:
SQL for Calculating the Revenue Metric
Since revenue data is stored only in Tutorial Data, the Engine performs this
calculation in that database. The first SQL pass creates a temporary table in
which to store the revenue for each region. The second SQL pass aggregates the
revenue for each region using a fact table in Tutorial Data and inserts it into the
temporary table.
This second image shows the SQL passes the Engine uses to determine the
relationships between call centers and employees:
SQL for Determining Call Center and Employee Relationships
Call center and employee relationships are stored only in Tutorial Data. The
FORECAST_SALES fact table stores its facts at the employee level. However,
for this report, the Engine has to calculate the Forecast Revenue metric at the
region level. Before the Engine can calculate this metric at the region level, it
first has to determine the relationships between employees, call centers, and
regions to accurately aggregate the forecast revenue data. Since the forecast
revenue data is stored only in Forecast Data, the Engine selects the necessary
call center and employee data from Tutorial Data and moves it to Forecast
Data.
The first SQL pass selects the call centers and employees from Tutorial Data.
The second SQL pass creates a temporary table in Forecast Data in which to
store the call centers and employees. The third SQL pass inserts the call centers
and employees from Tutorial Data into the temporary table in Forecast Data.
This third image shows the SQL passes the Engine uses to determine the
relationships between regions and call centers:
SQL for Determining Region and Call Center Relationships
Region and call center relationships are also stored only in Tutorial Data. Just
as the Engine has to determine the relationships between employees and call
centers, it also has to determine the relationships between call centers and
regions before aggregating the forecast revenue data to the region level. Since
the forecast revenue data is stored only in Forecast Data, the Engine selects the
necessary region and call center data from Tutorial Data and moves it to
Forecast Data.
The first SQL pass selects the regions and call centers from Tutorial Data. The
second SQL pass creates a temporary table in Forecast Data in which to store
the regions and call centers. The third SQL pass inserts the regions and call
centers from Tutorial Data into the temporary table in Forecast Data.
111
Now, the Engine has all the information it needs to aggregate the forecast
revenue data from the employee level to the region level.
This fourth image shows the SQL passes the Engine uses to calculate the
Forecast Revenue metric in the report:
SQL for Calculating the Forecast Revenue Metric
Since forecast revenue data is stored only in Forecast Data, the Engine
performs this calculation in that database. The first SQL pass aggregates the
forecast revenue for each region using the appropriate fact table in Forecast
Data. The second SQL pass creates a temporary table in Tutorial Data in which
to store the forecast revenue for each region. The third SQL pass inserts the
forecast revenue data for each region into the temporary table in Tutorial Data.
Now that the Engine has calculated all the metrics for the report, it uses
Tutorial Data to obtain the region descriptions and consolidate the results of
both metric calculations.
This last image shows the SQL pass the Engine uses to produce the final result
set for the report:
SQL for Consolidating the Result Set
This SQL pass retrieves the region descriptions from a lookup table in Tutorial
Data. Then, it retrieves the region IDs and revenue and forecast revenue for
each region from the appropriate temporary tables to produce the final result
set.
the consolidation pass, the Engine also generates SQL to drop each
After
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
113
Lesson Summary
In this lesson, you learned:
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.
When the Engine generates SQL for multisource reports, it determines the
optimal database instance for each SQL pass and identifies when joins need
to occur across database instances.
If you have duplicate tables, the primary table is the one that is mapped to
the primary database instance. The secondary table is the one that is
mapped to the secondary database instance.
The Engine uses specific logic to select the optimal data source for fact and
lookup tables.
When the Engine needs to join data from different data sources, it moves
data between them as it processes the result set for a report. It joins table
columns using specific data type compatibility rules.
You can change the primary database instance for a table in the Architect
graphical interface.
You can remove a database instance from a table in the Architect graphical
interface.
Lesson Summary
115
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.
117
Detailed Instructions
Open the Architect for the MicroStrategy Tutorial project
Add the LU_REGION and LU_COUNTRY tables to the project and change the
Database Instance
5 In the Warehouse Tables pane, in the list of tables available in the Forecast
Data database instance, right-click the LU_REGION table and select Add
Table to Project.
6 In the Options window, under Available options, keep the Indicate that
LU_REGION is also available from the current DB Instance option
selected.
7 Click OK.
8 In the Architect graphical interface, in the Properties pane, click the Tables
tab.
9 On the Tables tab, in the drop-down list, select LU_REGION.
10 Under Definition category, select Primary DB Instance.
11 Beside the current primary database instance, click the Browse button:
13 Click OK.
color coding of the table indicates the tables is mapped to a
The
secondary database instance.
14 Repeat steps 5 to 13 for LU_COUNTRY.
Add the FORECAST_SALES table to the project
119
121
You will also add the LU_GROUP table from the Inventory Data database
instance. As you add these tables, you should configure them as follows:
You need the Product attribute for the multisource report you will create later
in these exercises.
You should save the Product attribute in the Schema
Objects\Attributes\Products folder. As part of creating the Product attribute,
you need to complete the following tasks:
Make sure the ID and DESC attribute forms for the Product attribute map
the following as source tables:
Attribute
Form Expressions
Source Tables
Product
ID: PRODUCT_ID
LU_GROUP
LU_PRODUCT
DESC: PRODUCT_DESC
LU_PRODUCT
Parent Attribute
Child Attribute
Relationship Table
Product
Category (1:M)
LU_GROUP
After you have completed these tasks, save and update project schema, and
close Architect.
You can use the detailed instructions if you want help.
Detailed Instructions
Add the LU_PRODUCT table to the project
123
14 In the Warehouse Tables pane, in the list of tables available in the Forecast
Data database instance, right-click the LU_SUBCATEG table and select
Add Table to Project.
15 In the Options window, under Available options, keep the Indicate that
LU_SUBCATEG is also available from the current DB Instance option
selected.
16 Click OK.
Create Product and Category relationship and update the Product user
hierarchy
17 On the Hierarchy View tab, select the Product attribute and drag it to
Category attribute. A one-to-many relationship is created with Product as
the parent attribute.
18 On the Properties pane, in the Location property click Browse and save the
Product attribute in the Schema Objects\Attribute\Products folder.
19 On the Home tab, in the Hierarchy section, in the drop-down list, select
Products.
125
Detailed Instructions
Create the multisource report template
127
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.
129
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 131)
Describe the purpose of fact extensions and create fact extensions to extend
the levels of facts to other hierarchies. (Page 143)
Describe the purpose of fact disallows and disallow fact levels to prevent
unnecessary cross joins from occurring. (Page 156)
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
Based on this fact table, you can report on unit sales at the item or week levels.
You can also aggregate the unit sales data to the month, quarter, or year levels
within the Time hierarchy and to the subcategory and category levels within
the Product hierarchy. However, you cannot create a report that shows unit
sales by date because the fact is stored at the higher level of week. You cannot
determine the unit sales at the date level using this fact table.
What if you want to report on unit sales by call center or region? Since the fact
is stored only at the item and week levels and these two attributes have no
direct relationship to attributes in the Geography hierarchy, it is impossible to
perform this type of analysis.
131
You may also have a scenario in which a metric consists of more than one fact.
For example, the following illustration shows a Sales metric that consists of the
Unit Price and Quantity Sold facts:
Different Fact Levels in a Metric Definition
The Unit Price fact is stored at the item and week levels, while the Quantity
Sold fact is stored at the item and day levels. However, for these two facts to be
used together in a metric expression, they must be stored at the same level.
Otherwise, the calculation can cause errors, depending on the level at which
you need to report on the metric.
As you can see, the levels at which facts are stored limit the levels at which you
can report on facts. If you have a metric that consists of multiple facts, they
have to be stored at the same level to correctly calculate the metric.
Sometimes, facts may not be available in the data warehouse at the levels you
want to analyze in reports. You may not be able to change the levels at which
they are stored in data warehouse tables, but you can change the levels of facts
in MicroStrategy Architect by using fact level extensions. Fact level extensions
enable facts stored in the data warehouse at one level to be reported on at a
different level.
Fact level extensions are not commonly applied to facts, but they are
very
useful in special cases.
133
You can create fact level extensions using this process. The remainder of this
lesson describes each of these fact level extensions in detail.
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.
135
The Units Received fact is stored at the item and month levels. However, you
need the Units Received fact to be available at the day level. If you try to run
this report, you receive the following error message:
Report Error Without the Fact Degradation
The error message notifies users that the Units Received fact is not available at
the day and item levels. For this report to work, you need to lower the level of
the Units Received fact from month to day using a fact degradation.
to creating a fact degradation, you could change the
Aslevelanofalternative
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.
137
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.
139
13 In the Join Attributes Direction window, in the Join attributes list, in the
Join against column, click the arrow icon to set the join direction for the
join attribute.
14 Click Next.
15 In the Allocation window, do one of the following:
If you want to specify an allocation expression, select the Specify an
allocation expression check box.
In the box, type the expression.
Click Validate to validate the expression.
OR
If you do not want to specify an allocation expression, continue to step 16.
16 Click Next.
17 In the Finish window, review the information and click Finish.
can click Back to go back through the Level Extension Wizard
You
and make changes.
18 In the Fact Editor, click Save and Close.
19 Update the project schema.
141
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
image above displays only the first few rows of the result set for the
The
report.
The report returns the same value for each day within the same month for the
Units Received metric.
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.
143
If you run a report that contains the Item attribute and a Freight metric that
uses the Freight fact, the result set looks like the following:
Item and FreightReport Result Set
image above displays only the first few rows of the result set for the
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
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.
to creating a fact extension, you could add a new level
Asto thean alternative
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.
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.
should use the cross product option only as a last resort. If there
You
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.
more about the fact relation and cross product methods, refer
Toto thelearnProject
Design Guide product manual.
145
147
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 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.
ORDER_DETAIL table is the optimal join table provided you can
The
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.
149
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.
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.
151
16 Click Next.
you chose to select the join attributes, the Join Attributes
IfDirection
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.
21 In the Finish window, review the information and click Finish.
can click Back to go back through the Level Extension Wizard
You
and make changes.
22 In the Fact Editor, click Save and Close.
23 Update the project schema.
153
You can then run the following report that displays invoice information for all
items in a particular order:
Invoice ReportFreight at the Item Level
In this example, order 148247 includes 4 items. Since only one unit of each
item was sold, the Freight for each item is calculated evenly as $5. This type of
analysis would not be possible without a fact extension.
155
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
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
image above only displays the first few rows of the result set for the
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.
157
In an attempt to return data for the report, the SQL Engine generates SQL that
results in a cross join between the lookup table for the Call Center attribute and
the fact table that contains the units received data. The SQL for this report
looks like the following:
Report 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:
159
The error message basically notifies users that they cannot extend the Units
Received fact to the Call Center attribute using a cross join.
cannot use fact disallows to prevent normal joins from occurring,
You
only cross joins. For example, for the fact table referenced in this topic,
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.
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.
Lesson Summary
161
Exercise: Fact Level Extensions
Create a Fact Degradation
Overview
You will use the Forecasting Project for this exercise.
In this exercise, you will first create the following report:
Run the report. Add the Month attribute to the template and run the report
again. After reviewing the error message, save the report as Degradation
Example in the Public Objects\Reports folder.
Next, you will create a degradation for the Forecast Cost fact to enable you to
report on that fact at the Month level. In the data warehouse, this fact exists
only at the Quarter level. You should use the following allocation expression for
the fact degradation: [Forecast Cost] / 3. After creating the fact degradation,
you should update the project schema.
163
Run the report. The result set should look like the following:
image above only displays the first few rows of the result set for the
The
report.
You can use the detailed instructions if you want help.
Detailed Instructions
Create a report
can access the Quarter attribute from the Time hierarchy. You
You
can find the Forecast Cost metric in the Metrics folder.
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
You can access the Month attribute from the Time hierarchy.
5 Run the report. You should see the following error message:
165
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
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.
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.
can add multiple attributes for a single fact degradation.
You
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.
166 Exercise: Fact Level Extensions
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.
allocation expression returns correct values only at the month
This
level.
24 Click Validate to validate your expression.
25 Click Next.
26 In the Finish window, review the information and click Finish.
can click Back to go back through the Level Extension Wizard
You
and make changes.
27 In the Fact Editor, click Save and Close.
Update the project schema
167
29 Run the Degradation Example report. The result set should look like the
following:
image above only displays the first few rows of the result set for
The
the report.
You can now report on the Forecast Cost fact at the month level. The
monthly values are only estimates based on the allocation expression you
provided in the definition of the fact degradation. Notice that for each
month within a quarter, the forecast cost value is the same.
30 Close the report.
5
TRANSFORMATIONS
Lesson Description
This lesson covers transformations, schema objects that enable you to compare
metric values across time periods.
You will learn about two different types of transformations, and the different
components of a transformation. You will also learn how to create a
transformation in MicroStrategy Architect and how to use transformations in
transformation metrics. Finally, you will examine common uses for
transformations in reporting.
169
Transformations
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:
Transformations
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.
What Is a Transformation?
171
Transformations
Transformations
Types of Transformations
There are two types of transformations:
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
table also has columns for the parent IDs at all levels. These
This
columns are not displayed in the image above.
Each date in the LU_DAY table has a transformed value for the previous day,
last months date, last quarters date, and last years date. For example, for
January 5, 2013, the previous day was January 4, 2013, while the last quarters
date was October 5, 2012.
What Is a Transformation?
173
Transformations
In the MTD_DAY transformation table, each date has one or more records for
all dates within its month before and including that date. For example, there is
only one record for the January 1, 2013 date, but there are three records for the
January 3, 2013 date.
type of transformation data cannot be stored in the lookup table for
This
the Day attribute because lookup tables store each unique date only
once.
Transformations
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.
What Is a Transformation?
175
Transformations
Transformation Components
All transformations have the following components:
Member attributes
Member expressions
Member tables
Mapping type
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.
Transformations
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.
single transformation can use a combination of table-based and
Aexpression-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:
What Is a Transformation?
177
Transformations
Creating Transformations
You create expression-based and table-based transformations using the
Transformation Editor.
To create an expression-based transformation:
Transformations
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.
179
Transformations
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.
Transformations
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.
181
Transformations
The following image shows the Last Years Revenue metric that uses the Last
Years transformation:
Last Years Revenue Metric
Transformations
The following image shows the MTD Revenue metric that uses the Month to
Date transformation:
MTD Revenue Metric
183
Transformations
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
Transformations
Transformation Examples
Transformations are typically used to display time-based trends.
A common use of transformations is to display a current year/month/day data
versus the last year/month/day data on the same report. For example, consider
a report that displays this years revenue versus last years revenue, as shown
below:
Last Years Revenue for 2012
185
Transformations
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 a multitude of
reporting needs. The transformation applied to the metric is dynamically
evaluated at report run time to the appropriate attribute level based on the
report definition.
a time-based transformation to work correctly, you must have some
For
time-related element on the template or in the filter of a report.
Transformations
For example, if you modify the report from the previous example to display
only the December 2012 data, the Last Years Revenue metric values reflect
only the previous years December data, and not the aggregated data for entire
2012 year. This is shown in the image below:
Last Years Revenue for December 2012
that the Last Years Revenue for all 2012 for The Rugrats Movie
Recall
was $16,450.
187
Transformations
Transformations
The MTD Units Sold and YTD Units Sold metrics returns the number of units
sold in the current month and year, respectively. They use the Month to Date
and Year to Date transformations.
The YTD Average Inventory metric uses the Year to Date transformation and
returns the average inventory for the 1/1/2012 to 09/30/2012 time period.
The YTD Inventory Turnover metric is a compound metric that returns the
ratio between the number of units sold this year to the average inventory count
for the year.
Transformations are useful when you want to analyze data in respect to time.
However, transformation use is not limited to time-based transformations. For
example, you can use transformations to compare current catalog or
promotion versus previous catalog or promotion, and so forth.
189
Transformations
Lesson Summary
In this lesson, you learned:
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.
Exercise: Transformation
Exercise: Transformation
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.
Exercise: Transformation
191
Exercise: Transformation
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
Exercise: Transformation
13 In the Public Objects folder, in the Metrics folder, create a new metric.
14 Define the metric as Sum(Forecast Revenue).
15 Format metric values as Currency with 0 decimal places.
16 In the Metric: New Metric is defined as pane, select Transformation =
(nothing).
17 In the Object Browser, double-click the Last Years transformation.
Exercise: Transformation
193
Exercise: Transformation
can access the Year attribute from the Time hierarchy. You can
You
find the Forecast Revenue metric in the Metrics folder.
Exercise: Transformation
21 Run the report. The report result set should look like the following:
Only data for the 2012 and 2013 years are displayed, even though there is
Forecast Revenue data for 2011 in the data warehouse. Notice that both
metrics return different values for each row, but the Forecast Revenue data
for 2012 is identical to the Last Years Forecast Revenue for 2013, as
expected.
Modify the report
Exercise: Transformation
195
Exercise: Transformation
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
Exercise: Transformation
48 Run the Transformation Example report. The report result set should look
like the following:
Exercise: Transformation
197
Exercise: Transformation
image above only displays the first few rows of the result set for
The
the report.
Close the reports
6
PARTITIONING
Lesson Description
This lesson covers the benefits of partitioning fact tables and
how you can support partitioned tables in MicroStrategy
Architect.
First, you will learn about the difference between server-level
and application-level partitioning. Then, you will use
warehouse and metadata partition mapping to support
partitioned fact tables in a MicroStrategy project.
199
Partitioning
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:
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.
201
Partitioning
Server level
Application level
The following illustration shows the difference between these two types of
partitioning:
Two Types of Partitioning
Partitioning
203
Partitioning
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
Partitioning
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.
There is a row for each of the partition base tables in the logical whole.
205
Partitioning
Partitioning
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.
207
Partitioning
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.
Partitioning
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.
209
Partitioning
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.
Partitioning
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.
partition base tables may contain either the same column as the
The
partitioning attribute or a column corresponding to any child of the
partitioning attribute.
211
Partitioning
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.
Partitioning
With metadata partition mapping, you can also add partition base tables from
multiple data sources for a single partition definition. This feature can improve
the performance immensely and can be cost effective, especially when you are
dealing with large amounts of data in a project. For example, all 2012 partition
base tables are in Tutorial Data, but the 2011 partition base tables are in
Archived Tutorial Data. You can add the 2011 and 2012 partition base tables
from both data sources to a project and define the data slice for each partition
base table. The following illustration shows a metadata partition mapping table
from multiple data sources:
213
Partitioning
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.
to lock the logical size if you want to preserve it when
Remember
updating the project schema.
14 Click Save and Close.
15 Name and save the partition mapping.
16 Update the project schema.
Partitioning
This example shows 12 partition base tables partitioned by quarter. You can see
that Q1 2012 is the data slice defined for the INVENTORY_Q1_2012 table.
Similarly, the remaining tables correspond to their respective quarters.
215
Partitioning
Lesson Summary
In this lesson, you learned:
There are two types of partitioning: server level and application level.
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.
Partitioning
When you use metadata partition mapping, you add the partition base
tables to the project using Architect graphical interface.
When you execute a report that runs against the partitioned tables, before
the SQL Engine generates the report SQL, the Query Engine first sends the
necessary prequeries to the metadata to determine which partition base
tables need to be included in the report SQL.
Lesson Summary
217
Partitioning
A
WAREHOUSE CATALOG
Appendix Description
This appendix provides information on how to use Warehouse Catalog to
maintain project schema.
219
Warehouse Catalog
The Warehouse Catalog provides the following options for individual tables:
220
Show Sample DataThis option enables you to view the first 100 rows of
data in a table.
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.
221
Warehouse Catalog
222
Warehouse Catalog
223
Warehouse Catalog
As you can see, the Warehouse Catalog has a host of options that provide
flexibility in maintaining your project over time.
detailed information on the Warehouse Catalog options, refer to the
For
Project Design Guide product manual.
224
Warehouse Catalog
1 In Developer, 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.
drop-down list defaults to the primary database instance for the
This
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.
tables display in the Tables being used in the project list, along
The
with the primary database instance for each table.
6 Click Save and Close.
7 Update the project schema.
225
Warehouse Catalog
As you can see, the primary database instance for both of these tables is
Forecast Data, not Tutorial Data.
Warehouse Catalog
1 In Developer, 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.
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.
you add a table that is already mapped to another database
When
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.
you click the Make no changes to <Table Name> option, the
Iftable
is not mapped to the selected database instance, and no
duplicate table is created.
227
Warehouse Catalog
The following image shows the warning you see when you add duplicate tables:
Duplicate Tables Warning
Warehouse Catalog
The following image shows the Warehouse Catalog with the LU_COUNTRY
table mapped to multiple data sources:
LU_COUNTRY Mapped to Multiple Data Sources
The following image shows the Warehouse Catalog with the LU_REGION table
mapped to multiple data sources:
LU_REGION Mapped to Multiple Data Sources
The primary database instance for both of these tables is Tutorial Data.
However, the icons beside the tables indicate that they are also mapped to
another database instance.
229
Warehouse Catalog
To change the primary database instance for a table in the Warehouse Catalog:
Warehouse Catalog
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.
231
Warehouse Catalog
The following image shows the Available Database Instances window with the
modified database instance configuration for the LU_COUNTRY table.
Forecast Data is now the primary database instance for the LU_COUNTRY
table, and Tutorial Data is a secondary database instance for the table.
LU_COUNTRY with Modified Database Instance Configuration
Index
INDEX
A
adding aggregate fact tables to a
project 36
adding tables with a single data source 89
adding tables with multiple data
sources 92
aggregate fact tables, using them in a
project 36
aggregate-aware 36
Aggregation Awareness 35
application-level partitioning 202
Architect, basic schema objects 22
associating tables to database
instances 88
attributes 22
B
basic schema objects 22
C
changing logical table size 38
changing the primary database instance
for a table 95
D
data mart 40
creating 46
database instances 42
objects 42
optimization 44
options 50
updating fact 55
using in a project 54
data type compatibility rules 82
database instance
data mart 42
database instances, associating to
233
Index
tables 88
database instances, removing from
tables 98
database instances, table level 75, 76
database partitioning 202
degradation, creating 139
degradation, fact 133
degradation, steps 133, 137
degrading fact levels 135
designating primary and secondary
tables 79
designing the logical data model,
overview 19
different data sources, joining data 81
disallow, fact 133
disallowing fact levels 156
duplicate tables 77
E
Engine, data type compatibility rules 82
exercises
data mart 64
expression-based transformations 173
extending fact levels 143
extending fact levels, methods 145
extension using table relation method,
steps 146
extension, creating using the table relation
method 151
extension, fact 133
F
fact degradation 133, 135
fact degradation, creating 139
fact degradation, steps 133, 137
fact disallow 133, 156
fact extension 133, 143
fact extension using table relation method,
234
steps 146
fact extension, creating using the table relation method 151
fact extensions, methods 145
fact level 131
fact level extensions 132
fact level extensions, overview 131
fact level extensions, types 133
fact levels, degrading 135
fact levels, disallowing 156
fact levels, extending 143
fact tables, selecting the optimal data
source 80
facts 22
filtering qualifications, MultiSource
Option 85
H
hierarchies 22
I
introduction to MultiSource Option 75
J
joining data from different data
sources 81
L
level, fact 131
Logical Table Editor 37
logical table size, changing 38
logical table size, role in SQL
generation 36
lookup tables, selecting the optimal data
source 81
M
managing the project schema,
overview 20
metadata partition mapping 203, 212
methods, fact extensions 145
multiple data sources, joining data 81
multiple data sources, tables 92
MultiSource Option, filtering
qualifications 85
MultiSource Option, introduction 75
MultiSource Option, split fact tables 83
MultiSource Option, split lookup
tables 84
MultiSource Option, supported use
cases 83
multisource reports, creating 104
multisource reports, creating objects 100
multisource reports, data type compatibility rules 82
multisource reports, processing of
SQL 105
multisource reports, SQL generation 78
O
objects, multisource reports 100
optimal data source, fact tables 80
optimal data source, lookup tables 81
overview, creating the project in MicroStrategy Architect 20
overview, designing the logical data
model 19
overview, managing the project
schema 20
P
partition base tables 202, 205
partition mapping 23
partition mapping table 203, 205
Index
R
removing a database instance from a
table 98
S
schema objects 22
schema objects, basic 22
secondary database instances, table
level 75, 76
secondary tables 79
selecting the optimal data source, fact
tables 80
selecting the optimal data source, lookup
235
Index
tables 81
server-level partitioning 202
single data source, tables 89
split fact tables, MultiSource Option 83
split lookup tables, MultiSource
Option 84
SQL generation, data type compatibility
rules 82
SQL generation, logical table size 36
SQL generation, multisource reports 78
SQL, multisource reports 105
steps, fact degradation 133, 137
steps, fact extension using table relation
method 146
support for duplicate tables 77
supported use case, filtering
qualifications 85
supported use case, split fact tables 83
supported use case, split lookup tables 84
supported use cases, MultiSource
Option 83
U
use case, filtering qualifications 85
use case, split fact tables 83
use case, split lookup tables 84
use cases, MultiSource Option 83
W
Warehouse Catalog, project-wide
options 222
warehouse partition mapping 203
236