In-memory Analytics

Guide

Version: 10.7
10.7, March 2017
Copyright 2017 by MicroStrategy Incorporated. All rights reserved.
If you have not executed a written or electronic agreement with MicroStrategy or any authorized MicroStrategy distributor (any such agreement, a
"Separate Agreement"), the following terms apply:
This software and documentation are the proprietary and confidential information of MicroStrategy Incorporated and may not be provided to any other person. Copyright
2001-2017 by MicroStrategy Incorporated. All rights reserved.
THIS SOFTWARE AND DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT EXPRESS OR LIMITED WARRANTY OF ANY KIND BY EITHER MICROSTRATEGY
INCORPORATED OR ANYONE WHO HAS BEEN INVOLVED IN THE CREATION, PRODUCTION, OR DISTRIBUTION OF THE SOFTWARE OR DOCUMENTATION,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE AND
NONINFRINGMENT, QUALITY OR ACCURACY. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE AND DOCUMENTATION IS WITH
YOU. SHOULD THE SOFTWARE OR DOCUMENTATION PROVE DEFECTIVE, YOU (AND NOT MICROSTRATEGY, INC. OR ANYONE ELSE WHO HAS BEEN INVOLVED
WITH THE CREATION, PRODUCTION, OR DISTRIBUTION OF THE SOFTWARE OR DOCUMENTATION) ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING,
REPAIR, OR CORRECTION. SOME STATES DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU.
In no event will MicroStrategy, Incorporated. or any other person involved with the creation, production, or distribution of the Software be liable to you on account of any claim
for damage, including any lost profits, lost savings, or other special, incidental, consequential, or exemplary damages, including but not limited to any damages assessed against
or paid by you to any third party, arising from the use, inability to use, quality, or performance of such Software and Documentation, even if MicroStrategy, Inc. or any such
other person or entity has been advised of the possibility of such damages, or for the claim by any other party. In addition, MicroStrategy, Inc. or any other person involved in
the creation, production, or distribution of the Software shall not be liable for any claim by you or any other party for damages arising from the use, inability to use, quality, or
performance of such Software and Documentation, based upon principles of contract warranty, negligence, strict liability for the negligence of indemnity or contribution, the
failure of any remedy to achieve its essential purpose, or otherwise. The entire liability of MicroStrategy, Inc. and your exclusive remedy, shall not exceed, at the option of
MicroStrategy, Inc., either a full refund of the price paid, or replacement of the Software. No oral or written information given out expands the liability of MicroStrategy, Inc.
beyond that specified in the above limitation of liability. Some states do not allow the limitation or exclusion of liability for incidental or consequential damages, so the above
limitation may not apply to you.
The information contained in this manual (the Documentation) and the Software are copyrighted and all rights are reserved by MicroStrategy, Inc. MicroStrategy, Inc. reserves
the right to make periodic modifications to the Software or the Documentation without obligation to notify any person or entity of such revision. Copying, duplicating, selling, or
otherwise distributing any part of the Software or Documentation without prior written consent of an authorized representative of MicroStrategy, Inc. are prohibited. U.S.
Government Restricted Rights. It is acknowledged that the Software and Documentation were developed at private expense, that no part is public domain, and that the
Software and Documentation are Commercial Computer Software provided with RESTRICTED RIGHTS under Federal Acquisition Regulations and agency supplements to
them. Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer
Software clause at DFAR 252.227-7013 et. seq. or subparagraphs (c)(1) and (2) of the Commercial Computer Software-Restricted Rights at FAR 52.227-19, as applicable.
Contractor is MicroStrategy, Incorporated., 1850 Towers Crescent Plaza, Tysons Corner, VA 22182. Rights are reserved under copyright laws of the United States with respect to
unpublished portions of the Software.
The following terms and notices apply regardless of whether you have executed a Separate Agreement:
Trademark Information
The following are either trademarks or registered trademarks of MicroStrategy Incorporated or its affiliates in the United States and certain other countries:
MicroStrategy, MicroStrategy 10, MicroStrategy 10 Secure Enterprise, MicroStrategy 9, MicroStrategy 9s, MicroStrategy Analytics, MicroStrategy Analytics Platform, MicroStrategy
Desktop, MicroStrategy Operations Manager, MicroStrategy Analytics Enterprise, MicroStrategy Evaluation Edition, MicroStrategy Secure Enterprise, MicroStrategy Web,
MicroStrategy Mobile, MicroStrategy Server, MicroStrategy Parallel Relational In-Memory Engine (MicroStrategy PRIME), MicroStrategy MultiSource, MicroStrategy OLAP
Services, MicroStrategy Intelligence Server, MicroStrategy Intelligence Server Universal, MicroStrategy Distribution Services, MicroStrategy Report Services, MicroStrategy
Transaction Services, MicroStrategy Visual Insight, MicroStrategy Web Reporter, MicroStrategy Web Analyst, MicroStrategy Office, MicroStrategy Data Mining Services,
MicroStrategy Narrowcast Server, MicroStrategy Health Center, MicroStrategy Analyst, MicroStrategy Developer, MicroStrategy Web Professional, MicroStrategy Architect,
MicroStrategy SDK, MicroStrategy Command Manager, MicroStrategy Enterprise Manager, MicroStrategy Object Manager, MicroStrategy Integrity Manager, MicroStrategy
System Manager, MicroStrategy Analytics App, MicroStrategy Mobile App, MicroStrategy Tech Support App, MicroStrategy Mobile App Platform, MicroStrategy Cloud,
MicroStrategy R Integration, Dossier, Usher, MicroStrategy Usher, Usher Badge, Usher Security, Usher Security Server, Usher Mobile, Usher Analytics, Usher Network Manager,
Usher Professional, MicroStrategy Services, MicroStrategy Professional Services, MicroStrategy Consulting, MicroStrategy Customer Services, MicroStrategy Education,
MicroStrategy University, MicroStrategy Managed Services, BI QuickStrike, Mobile QuickStrike, Transaction Services QuickStrike Perennial Education Pass, MicroStrategy Web
Based Training (WBT), MicroStrategy World, Best in Business Intelligence, Pixel Perfect, Global Delivery Center, Direct Connect, Enterprise Grade Security For Every Business,
Build Your Own Business Apps, Code-Free, Welcome to Ideal, The Worlds Most Comprehensive Analytics Platform, The Worlds Most Comprehensive Analytics Platform.
Period.
Other product and company names mentioned herein may be the trademarks of their respective owners.
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,474, 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,035,382, 8,051,168, 8,051,369, 8,094,788,
8,130,918, 8,296,287, 8,321,411, 8,452,755, 8,521,733, 8,522,192, 8,577,902, 8,606,813, 8,607,138, 8,645,313, 8,761,659, 8,775,807, 8,782,083, 8,812,490, 8,832,588, 8,943,044,
8,943,187. 8,958,537, 8,966,597, 8,983,440, 8,984,274, 8,984,288, 8,995,628, 9,027,099, 9,027,105, 9,037, 577, 9,038,152, 9,076,006, 9,086,837, 9,116,954, 9,124,630,
9,154,303, 9,154,486, 9,160,727, 9,166,986, 9,171,073, 9,172,699, 9,173,101, 9,183, 317, 9,195,814, 9,208,213, 9,208,444, 9,262,481, 9,264,415, 9,264,480, 9,269,358, 9,275,127,
9,292,571, 9,300,646, 9,311,683 9,313,206, 9,330,174, 9,338,157, 9,361,392, 9,378,386, 9,386,416, 9,391,782, 9,397,838, 9,397,980, 9,405,804, 9,413,710, 9,413,794, 9,430,629,
9,432,808, 9,438,597, 9,444,805, 9,450,942, 9,450,958, 9,454,594, 9,507,755, 9,513,770, 9,516,018, 9,529,850, 9,563,761, and 9,565,175. Other patent applications are
pending.
Third Party Software
Various MicroStrategy products contain the copyrighted technology or software of third parties ("Third Party Software"). Your use of MicroStrategy products is subject to all
applicable terms and conditions associated with any such Third Party Software
Datalogics, Inc.
Copyright 2000-2017 Datalogics, Inc.
Copyright 1984-2017 Adobe Systems Incorporated and its licensors. All rights reserved
Adobe, Adobe PDF Library, and The Adobe Logo are trademarks of Adobe Systems Incorporated.
CONTENTS
Overview and Additional Resources 1
Description of this guide 1
About this book 2
Resources 4
Feedback 11
1. About MicroStrategy OLAP Services 13
OLAP Services features 13
The benefits of using OLAP Services 16
Privileges required for Developer and Web users 17
Report types: Standard and OLAP reports 18
Standard OLAP analysis features 19
2. Sharing Sets of Data Among Reports: Intelligent Cubes 22
Sharing Intelligent Cubes 22
Updating Intelligent Cubes without re-processing: Incremental Refresh 43
Improving the performance of large Intelligent Cubes: Partitioning 50
3. Reporting on Intelligent Cubes 51
Reporting and analyzing data with OLAP Services features 51
Reporting and analyzing data with Intelligent Cubes 52
Reporting on Intelligent Cubes with dynamic sourcing 67
4. Importing Large Datasets into MicroStrategy 69
Overview: Large, in-memory datasets in MicroStrategy 69
Creating an application that uses a partitioned dataset 70
Editing and updating your dataset 74

2017, MicroStrategy Inc. iii

In-memory Analytics Guide

5. Derived Elements 78
Types of derived elements 80
Creating derived elements 88
Defining derived element functionality and formatting 121
Interaction with other reporting features 131
6. Derived Metrics 141
Creating a derived metric 142
Editing derived metrics 155
Formatting derived metrics 155
Deleting derived metrics 155
View filter effects on derived metrics 156
Derived element effects on derived metrics 156
7. View Filters 158
Comparing view filters to report filters and report limits 161
Creating a view filter 165
Deleting a view filter 186
View filter effects on reporting features 186
8. Dynamic Sourcing 198
Scenarios that benefit from dynamic sourcing 198
Best practices for supporting dynamic sourcing 200
Configuring dynamic sourcing 206
Using Cube Advisor to support dynamic sourcing 218
Tracking the use of dynamic sourcing 227
9. Dynamic Aggregation 243
Using dynamic aggregation 245
Functions used in dynamic aggregation 246
View filter effect on dynamic aggregation 257
A. Efficient Functions for Partitioned Datasets 258
Functions for partitioned datasets 258
B. Best Practice for MicroStrategy PRIME 264
Prerequisites 265
Parallel queries 270
Partitioning cubes 275
Sizing 278

iv 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Cube incremental refresh 279

Data source 280
Document / dashboard best practice 280
Concurrency 284
Web or mobile access 285
Index 286

2017, MicroStrategy Inc. v

OVERVIEW AND ADDITIONAL
RESOURCES

Description of this guide

This guide provides information on in-memory datasets that you create using
MicroStrategy OLAP Services and MicroStrategy PRIME.
This book assumes that you are familiar with the fundamental concepts about the
MicroStrategy product and that you have experience with the various features the
product offers. In addition, you should have basic knowledge of Multidimensional Online
Analytical Processing (MOLAP) and Relational OLAP (ROLAP) analyses.
This book includes the following chapters:
Chapter 1, About MicroStrategy OLAP Services: Includes introductory information
on the features available with MicroStrategy OLAP Services.
Chapter 2, Sharing Sets of Data Among Reports: Intelligent Cubes: Includes
information on Intelligent Cubes, a key component to implementing MicroStrategy
OLAP Services.
Chapter 3, Reporting on Intelligent Cubes: Includes information on how you can
report and analyze data from Intelligent Cubes.
Chapter 4, Importing Large Datasets into MicroStrategy: Includes information on
planning very large datasets for MicroStrategy PRIME, which allows you to analyze
data using your Intelligence Servers parallel computing features.
Chapter 5, Derived Elements: Includes information on derived elements, which
provide a new view of report data for analysis and formatting purposes.
Chapter 6, Derived Metrics: Includes information on derived metrics, which can
perform column math, that is, calculations on metrics included in the report
definition, without regenerating or re-executing SQL against the data warehouse.

2017, MicroStrategy Inc. 1

In-memory Analytics Guide

Chapter 7, View Filters: Includes information on view filters, which restrict the
amount of data displayed on the report, providing you with a different view of the
data.
Chapter 8, Dynamic Sourcing: Includes information on dynamic sourcing, which
extends the accessibility of Intelligent Cubes by allowing regular reports to
automatically access published Intelligent Cubes that can satisfy the data
requirements of the report.
Chapter 9, Dynamic Aggregation: Includes information on dynamic aggregation,
which allows you to change the level of report aggregation on the fly, while you are
reviewing the report results.
Efficient Functions for Partitioned Datasets: Includes a list of functions that work
most efficiently and faster with partitioned datasets.
Best Practice for MicroStrategy PRIME Includes a brief explanation of PRIME
(Parallel Relational In-Memory Engine), the next generation of OLAP cubes) and
configuration best practice recommendations.

About this book

The following sections provide the location of examples, list prerequisites for using this
book, and describe the user roles the information in this book was designed for.

The sample documents and images in this guide, as well as some example steps,
were created with dates that may no longer be available in the MicroStrategy
Tutorial project. If you are re-creating an example, replace the year(s) shown in
this guide with the most recent year(s) available in the software.

How to find business scenarios and examples

Within this guide, many of the concepts discussed are accompanied by business scenarios
or other descriptive examples. Many of the examples use the MicroStrategy Tutorial,
which is MicroStrategys sample warehouse and project. Information about the
MicroStrategy Tutorial can be found in the MicroStrategy Basic Reporting Guide.
Detailed examples of advanced reporting functionality can be found in the
MicroStrategy Advanced Reporting Guide.

Whats new in this guide

Analytics Enterprise
The name of MicroStrategy Desktop has been changed to MicroStrategy Developer.

2 2017, MicroStrategy Inc.

 In-memory Analytics Guide

MicroStrategy 10.6
l You can now merge multiple Intelligent Cubes to form a new dataset while
maintaining existing connections to the merged cubes. For steps, see Merging
Intelligent Cubes.

MicroStrategy 9.4
You can use one or more Intelligent Cubes as datasets in Report Services documents.
For steps, see Creating Report Services documents that connect to Intelligent
Cubes, page 55.
If you are using derived elements in Report Services documents with multiple
datasets, derived metrics in the document may evaluate incorrectly. For steps to
allow derived metrics to calculate correctly, see Derived element interactions with
derived metrics, page 131.
If you are using derived elements in Report Services documents with multiple
datasets, derived elements from all datasets may be combined, depending on their
definition. For examples and considerations when using derived elements in
documents with multiple datasets, see Derived elements in Report Services
documents with multiple datasets, page 138.
Best Practice for MicroStrategy PRIME has been added to help you configure
PRIME (Parallel Relational In-Memory Engine).

Prerequisites
Before working with this document, you should be familiar with:
MicroStrategy objects, including attributes, metrics, and filters
Project creation and configuration
Report creation and manipulation
MOLAP and ROLAP analyses
Structured Query Language (SQL)

Who should use this guide

This document is designed for:
Report Designers who will be using the OLAP Services to create advanced reports
and reporting objects such as metrics, filters, and so on
Analysts who will be performing advanced report manipulation

2017, MicroStrategy Inc. 3

In-memory Analytics Guide

Resources
This section provides details on how to access books, online help, MicroStrategy
Education and Consulting resources, and how to contact MicroStrategy Technical
Support.

Documentation
MicroStrategy provides both manuals and online help; these two information sources
provide different types of information, as described below:
Manuals: MicroStrategy manuals provide:
Introductory information and concepts
Examples and images
Checklists and high-level procedures to get started
The steps to access the manuals are described in Accessing manuals and other
documentation sources, page 9.
Most of these manuals are also available printed in a bound, soft cover format. To
purchase printed manuals, contact your MicroStrategy Account Executive with a
purchase order number.
Help: MicroStrategy online help provides:
Detailed steps to perform procedures
Descriptions of each option on every software screen

Additional formats
MicroStrategy manuals are available as electronic publications, downloadable on the
Apple iBooks Store or Google Play, and can be read on your iOS or Android device
respectively. To download a book, search for the books title in the iBookstore or Google
Play. To view a list of manuals that are currently available, scan the following QR codes
using your devices camera:
For iOS devices, scan the following QR code:

For Android devices, scan the following QR code:

4 2017, MicroStrategy Inc.

 In-memory Analytics Guide

For new MicroStrategy releases, it may take several days for the latest manuals to
be available on the iBookstore or Google Play.

Translations
For the most up-to-date translations of MicroStrategy documentation, refer to the
MicroStrategy Knowledge Base. Due to translation time, manuals in languages other than
English may contain information that is one or more releases behind. You can see the
version number on the title page of each manual.

Finding information
You can search all MicroStrategy books and Help for a word or phrase, with a simple
Google search at http://www.google.com. For example, type MicroStrategy derived
metric or MicroStrategy logical table into a Google search. As described above, books
typically describe general concepts and examples; Help typically provides detailed steps
and screen options. To limit your search to MicroStrategy books, on Googles main page
you can click More, then select Books.

Manuals for MicroStrategy overview and evaluation

Introduction to MicroStrategy: Evaluation Guide
Instructions for installing, configuring, and using the MicroStrategy Evaluation
Edition of the software. This guide includes a walkthrough of MicroStrategy features
so you can perform reporting with the MicroStrategy Tutorial project and its sample
business data.
MicroStrategy Evaluation Edition Quick Start Guide
Overview of the installation and evaluation process, and additional resources.

Resources for security

Usher Help
Steps to perform mobile identity validation using the Usher mobile security network
to issue electronic badges for identifying users.

2017, MicroStrategy Inc. 5

In-memory Analytics Guide

Manuals for query, reporting, and analysis

MicroStrategy Installation and Configuration Guide
Information to install and configure MicroStrategy products on Windows, UNIX,
Linux, and HP platforms, and basic maintenance guidelines.
MicroStrategy Upgrade Guide
Steps to upgrade existing MicroStrategy products.
MicroStrategy Project Design Guide
Information to create and modify MicroStrategy projects, and create the objects that
present your organizations data, such as facts, attributes, hierarchies,
transformations, advanced schemas, and project optimization.
MicroStrategy Basic Reporting Guide
Steps to get started with MicroStrategy Web, and how to analyze and format data in
a report. Includes the basics for creating reports, metrics, filters, and prompts.
MicroStrategy Advanced Reporting Guide: Enhancing Your Business
Intelligence Application
Steps to create Freeform SQL reports, Query Builder reports, complex filters and
metrics, use Data Mining Services, and create custom groups, consolidations, and
complex prompts.
Document and Dashboard Analysis Guide
Steps to execute, analyze, and format a dashboard in MicroStrategy Web.
MicroStrategy Report Services Document Creation Guide: Creating
Boardroom Quality Documents
Steps to create Report Services documents, add objects, and format the document
and its objects.
MicroStrategy Dashboards and Widgets Creation Guide: Creating
Interactive Dashboards for Your Data
Steps to create MicroStrategy Report Services dashboards and add interactive
visualizations.
MicroStrategy In-memory Analytics Guide
Information to use MicroStrategy OLAP Services features, including Intelligent
Cubes, derived metrics, derived elements, dynamic aggregation, view filters, and
dynamic sourcing.
MicroStrategy Office User Guide
Instructions to use MicroStrategy Office to work with MicroStrategy reports and
documents in Microsoft Excel, PowerPoint, and Word, to analyze, format, and
distribute business data.

6 2017, MicroStrategy Inc.

 In-memory Analytics Guide

MicroStrategy Mobile Analysis Guide: Analyzing Data with

MicroStrategy Mobile
Steps to use MicroStrategy Mobile to view and analyze data, and perform other
business tasks with MicroStrategy reports and documents on a mobile device.
MicroStrategy Mobile Design and Administration Guide: A Platform for
Mobile Intelligence
Information and instructions to install and configure MicroStrategy Mobile, as well
as steps for a designer working in MicroStrategy Developer or MicroStrategy Web to
create effective reports and documents for use with MicroStrategy Mobile.
MicroStrategy System Administration Guide: Tuning, Monitoring, and
Troubleshooting Your MicroStrategy Business Intelligence System
Steps to implement, deploy, maintain, tune, and troubleshoot a MicroStrategy
business intelligence system.
MicroStrategy Supplemental Reference for System Administration: VLDB
Properties, Internationalization, User Privileges, and other Supplemental
Information for Administrators
Steps for administrative tasks such as configuring VLDB properties and defining data
and metadata internationalization, and reference material for other administrative
tasks.
MicroStrategy Functions Reference
Function syntax and formula components; instructions to use functions in metrics,
filters, attribute forms; examples of functions in business scenarios.
MicroStrategy MDX Cube Reporting Guide
Information to integrate MicroStrategy with MDX cube sources. You can integrate
data from MDX cube sources into your MicroStrategy projects and applications.
MicroStrategy Operations Manager Guide
Instructions for managing, monitoring, and setting alerts for all of your
MicroStrategy systems from one console. This guide also includes instructions for
setting up and using Enterprise Manager to analyze your MicroStrategy system usage.

Manual for the Human Resources Analytics Module

Human Resources Analytics Module Reference

Software Development Kits

MicroStrategy Developer Library (MSDL)
Information to understand the MicroStrategy SDK, including details about
architecture, object models, customization scenarios, code samples, and so on.

2017, MicroStrategy Inc. 7

In-memory Analytics Guide

MicroStrategy Web SDK

The Web SDK is available in the MicroStrategy Developer Library, which is

part of the MicroStrategy SDK.

Documentation for MicroStrategy Portlets

Enterprise Portal Integration Help
Information to help you implement and deploy MicroStrategy BI within your
enterprise portal, including instructions for installing and configuring out-of-the-box
MicroStrategy Portlets for several major enterprise portal servers.
This resource is available from http://www.microstrategy.com/producthelp.

Documentation for MicroStrategy GIS Connectors

GIS Integration Help
Information to help you integrate MicroStrategy with Geospatial Information
Systems (GIS), including specific examples for integrating with various third-party
mapping services.
This resource is available from http://www.microstrategy.com/producthelp.

Help
Each MicroStrategy product includes an integrated help system to complement the
various interfaces of the product as well as the tasks that can be accomplished using the
product.
Some of the MicroStrategy help systems require a web browser to be viewed. For
supported web browsers, see the MicroStrategy Readme.
MicroStrategy provides several ways to access help:
Help button: Use the Help button or ? (question mark) icon on most software
windows to see help for that window.
Help menu: From the Help menu or link at the top of any screen, select
MicroStrategy Help to see the table of contents, the Search field, and the index for
the help system.
F1 key: Press F1 to see context-sensitive help that describes each option in the
software window you are currently viewing.

For MicroStrategy Web, MicroStrategy Web Administrator, and MicroStrategy

Mobile Server, pressing the F1 key opens the context-sensitive help for the
web browser you are using to access these MicroStrategy interfaces. Use the
Help menu or ? (question mark) icon to access help for these MicroStrategy
interfaces.

8 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Accessing manuals and other documentation sources

The manuals are available from http://www.microstrategy.com/producthelp, as well as
from your MicroStrategy disk or the machine where MicroStrategy was installed.

Adobe Reader is required to view these manuals. If you do not have Adobe Reader
installed on your computer, you can download it from
http://get.adobe.com/reader/.

The best place for all users to begin is with the MicroStrategy Basic Reporting Guide.
To access the installed manuals and other documentation sources, see the following
procedures:
To access documentation resources from any location, page 9
To access documentation resources on Windows, page 9
To access documentation resources on UNIX and Linux , page 9

To access documentation resources from any location

1 Visit http://www.microstrategy.com/producthelp.

To access documentation resources on Windows

1 From the Windows Start menu, choose Programs (or All Programs),
MicroStrategy Documentation, then Product Manuals. A page opens in your
browser showing a list of available manuals in PDF format and other documentation
sources.
2 Click the link for the desired manual or other documentation source.

If bookmarks are not visible on the left side of a product manual, from the View
menu click Bookmarks and Page. This step varies slightly depending on your
version of Adobe Reader.

To access documentation resources on UNIX and Linux

1 Within your UNIX or Linux machine, navigate to the directory where you installed
MicroStrategy. The default location is /opt/MicroStrategy, or
$HOME/MicroStrategy/install if you do not have write access to
/opt/MicroStrategy.
2 From the MicroStrategy installation directory, open the Help folder.
3 Open the Product_Manuals.htm file in a web browser. A page opens in your
browser showing a list of available manuals in PDF format and other documentation
sources.
4 Click the link for the desired manual or other documentation source.

2017, MicroStrategy Inc. 9

In-memory Analytics Guide

If bookmarks are not visible on the left side of a product manual, from the View
menu click Bookmarks and Page. This step varies slightly depending on your
version of Adobe Reader.

Documentation standards
MicroStrategy online help and PDF manuals (available both online and in printed
format) use standards to help you identify certain types of content. The following table
lists these standards.

These standards may differ depending on the language of this manual; some
languages have rules that supersede the table below.

Type Indicates

bold Button names, check boxes, options, lists, and menus that are the focus of
actions or part of a list of such GUI elements and their definitions
Example: Click Select Warehouse .
italic Names of other product manuals and documentation resources
When part of a command syntax, indicates variable information to be replaced by
the user
Example: Type copy c:\filename d:\foldername\filename

Courier Calculations
font Code samples
Registry keys
Path and file names
URLs
Messages displayed in the screen
Text to be entered by the user
Example: Sum(revenue)/number of months.

Example: Type cmdmgr -f scriptfile.scp and press Enter.

+ A keyboard command that calls for the use of more than one key (for example,
SHIFT+F1).
A note icon indicates helpful information for specific situations.

A warning icon alerts you to important information such as potential security risks;
these should be read before continuing.

10 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Education
MicroStrategy Education Services provides a comprehensive curriculum and highly
skilled education consultants. Many customers and partners from over 800 different
organizations have benefited from MicroStrategy instruction.
Courses that can help you prepare for using this manual or that address some of the
information in this manual include:
MicroStrategy Developer: Reporting Essentials
MicroStrategy Developer: Advanced Reporting
For the most up-to-date and detailed description of education offerings and course
curricula, visit http://www.microstrategy.com/Education.

Consulting
MicroStrategy Consulting Services provides proven methods for delivering leading-edge
technology solutions. Offerings include complex security architecture designs,
performance and tuning, project and testing strategies and recommendations, strategic
planning, and more. For a detailed description of consulting offerings, visit
http://www.microstrategy.com/services-support/consulting.

Technical Support
If you have questions about a specific MicroStrategy product, you should:
1 Consult the product guides, Help, and readme files. Locations to access each are
described above.
2 Consult the MicroStrategy Knowledge Base online at
https://resource.microstrategy.com/support.

A technical administrator in your organization may be able to help you resolve

your issues immediately.

3 MicroStrategy Technical Support can be contacted by your company's Support

Liaison. Contact information and the Technical Support policy information is
available at http://www.microstrategy.com/services-support/support/contact.

Feedback
Please send any comments or suggestions about user documentation for MicroStrategy
products to:
documentationfeedback@microstrategy.com
Send suggestions for product enhancements to:
support@microstrategy.com

2017, MicroStrategy Inc. 11

In-memory Analytics Guide

When you provide feedback to us, please include the name and version of the products
you are currently using. Your feedback is important to us as we prepare for future
releases.

12 2017, MicroStrategy Inc.

 1
ABOUT MICROSTRATEGY
OLAP SERVICES
This chapter is an overview of MicroStrategy OLAP Services, which extends the
capability and functionality of MicroStrategy Intelligence Server.
This chapter covers the following information on OLAP Services:
OLAP Services features, page 13
The benefits of using OLAP Services, page 16
Privileges required for Developer and Web users, page 17
Report types: Standard and OLAP reports, page 18
Standard OLAP analysis features, page 19

OLAP Services features

As an extension of MicroStrategy Intelligence Server, OLAP Services uses Intelligent
Cube Technologyan in-memory version of report data that can be manipulated by the
MicroStrategy Analytical Engine. MicroStrategy Developer, Web, and Office users can
slice and dice data in reports within Intelligent Cubes without having to re-execute SQL
against the data warehouse. Chapter 2, Sharing Sets of Data Among Reports: Intelligent
Cubes, describes the role of OLAP Services in the overall MicroStrategy architecture and
how you can take advantage of Intelligent Cubes to achieve the best efficiency and
performance in your application.
As a MicroStrategy user, you may already take advantage of the many standard OLAP
features that MicroStrategy provides out of the box, such as page-by, pivoting, sorting,
and subtotals.
With the OLAP Services feature, you can perform additional OLAP analysis, using the
following features:
Displaying data on the fly: dynamic aggregation, page 14
Creating metrics on the fly: derived metrics, page 15

2017, MicroStrategy Inc. 13

In-memory Analytics Guide

Defining attribute elements on the fly: derived elements, page 15

Filtering data on the fly: view filters and metric filters, page 15
Importing data as an Intelligent Cube, page 15

Providing MOLAP analysis with Intelligent Cubes

The main feature supporting MicroStrategy OLAP Services is MicroStrategy Intelligent
Cube Technology, which allows you to create multi-dimensional cubes (sets of data)
that are stored within MicroStrategy Intelligence Server.
Rather than returning data from the data warehouse for a single report, you can return
sets of data, called Intelligent Cubes, from your data warehouse, and save them directly
to Intelligence Servers memory. Intelligent Cubes can be shared as a single in-memory
copy, to be used by many different reports created by multiple users.
For detailed information on Intelligent Cubes, refer to Chapter 2, Sharing Sets of Data
Among Reports: Intelligent Cubes.

Displaying data on the fly: dynamic aggregation

When you create a non-OLAP Services report in MicroStrategy, data is retrieved from
the data warehouse and aggregated to the logical level determined by the objects on the
report.
Dynamic aggregation allows metric values to be aggregated at different levels, depending
on the attributes included on the report, without having to re-execute it against the data
warehouse. Dynamic aggregation occurs when the attributes included on the report
layout changesfor example, when you move an attribute or attribute form off of the
report layout to the Report Objects pane, or when you move an attribute or attribute
form from the Report Objects pane back onto the report layout. As the attributes
included on the report layout change, metric values are dynamically aggregated to the
new level of the report.
For example, a report with revenue data and attributes for year and region displays
revenue data for each region during each year. You can move the attribute for year from
the report layout to the Report Objects pane to display a regions revenue data for all
years rather than display each yearly revenue total separately.

Metrics can also be moved between the report layout and the Report Objects pane,
but this does not affect the level of aggregation for the report.

By default, the Analytical Engine selects the best aggregation function to use for each
metric. However, you can also specify the function for each metric. You can use any of
the standard predefined subtotal functions or define your own functions using user-
defined subtotals.
For more detailed information on dynamic aggregation, refer to Chapter 9, Dynamic
Aggregation.

14 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Creating metrics on the fly: derived metrics

Derived metrics perform calculations on the fly with the data available in a report. They
are an easy way to present data already available on the report in different ways,
providing further analysis of data. You can use derived metrics to quickly perform on-
the-fly analyses such as margins, contributions, and differences between metrics
included on the report.
These metrics are created based on existing metrics in the report. Since derived metrics
are evaluated in-memory, their computation does not require any SQL to execute in the
database.
Since derived metrics are created within a report, they can only be used for the report in
which they are created. They cannot be saved as individual objects in the project, and
therefore cannot be applied to other reports in the project.
For more detailed information on derived metrics, refer to Chapter 6, Derived Metrics.

Defining attribute elements on the fly: derived

elements
A derived element is a grouping of attribute elements on a report. These groups provide a
new view of report data for analysis and formatting purposes. For example, you can
group data for the months of December, January, and February into a single element
that combines and displays the data for the entire winter season.
Rather than having to define consolidations or custom groups, you can use derived
elements to create these groups on the fly while viewing a report. Derived elements are
evaluated on the report dataset without regenerating or re-executing SQL.
Derived elements are defined by using a list, filter, or calculation to combine attribute
element data.
For detailed information on derived elements, see Chapter 5, Derived Elements.

Filtering data on the fly: view filters and metric filters

A view filter dynamically restricts the data being displayed on the report without re-
executing the report against the warehouse. This is different from a report filter, which
restricts how much data is retrieved from the data warehouse. View filters improve the
response time of reports, and decrease database load.
It is important to note that you can use a report filter and view filter on the same report.
The report filter returns a set of data for the report, which the view filter then restricts
further. You should therefore avoid defining contradictory filtering criteria in both,
otherwise you many encounter situations where no data is displayed.
For detailed information on view filters, see Chapter 7, View Filters.

Importing data as an Intelligent Cube

You can use the Import Data feature in MicroStrategy Web to import data from sources
such as Microsoft Excel spreadsheets, comma-separated text files, and external databases

2017, MicroStrategy Inc. 15

In-memory Analytics Guide

into your project. This data is stored as Intelligent Cubes.

Some uses for this data include:
Quickly integrating data into MicroStrategy as part of a proof-of-concept
Importing and reporting on personalized data from various data sources
Immediately building reports and documents without having to model the data
source as part of the entire project
Modifying the data in your data source, then republishing the Intelligent Cube to
quickly update the data in your reports and documents
For detailed information on the Import Data feature, see the MicroStrategy Web Help.

The benefits of using OLAP Services

OLAP Services combines the benefits of both MOLAP and ROLAP analyses.
Generally speaking, MOLAP tools place data in multi-dimensional cubes and perform
consolidations in advance, allowing you to run queries fast. ROLAP tools allow you to use
complex SQL queries against relational tables to obtain multi-dimensional views of data
on the fly.
Each type of analysis has its own advantages and disadvantages. However, OLAP Services
provides MOLAP and ROLAP analysis on the same report, which offers many distinct
benefits, summarized below:
Analyze reports at the speed of thought, and manipulate them
in real time
Using OLAP Services, you can get fast response times for reports that use data
directly from in-memory Intelligent Cubes, instead of from the data warehouse. You
can create and analyze new reports in real time through interactive OLAP Services
manipulations.
Share Intelligent Cube data securely
MicroStrategys centralized metadata and Intelligence Server architecture allows
Intelligent Cube data to be shared in a secure fashion.
Schedule Intelligent Cube execution and maintenance
To reduce stress on the Intelligence Server, you can schedule when Intelligent Cubes
are executed. This allows you to take advantage of Intelligence Server down time to
execute Intelligent Cubes without affecting performance for your user community.
You can also schedule when Intelligent Cubes are re-executed to synchronize their
data with changes to the data in your data warehouse.
Drill from summary data to transaction-level details
You can drill from predefined reports to conduct advanced analysis and take full
advantage of the Intelligent Cube feature. Drilling is allowed within an Intelligent

16 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Cube for quick-response MOLAP analysis. Drilling can also be enabled outside of an
Intelligent Cube for full ROLAP analysis.
Use MicroStrategy Developer, Office, or Web
Using OLAP Services, you can perform the same multidimensional analysis whether
you use MicroStrategy Developer, Office, or Web.
Apply security restrictions on users and objects
Reporting with OLAP Services and Intelligent Cubes adhere to the same standards of
data access security as the rest of your MicroStrategy project.
Increase user self-service and productivity
Since accessing Intelligent Cubes for OLAP analysis does not require runtime
processing on the data warehouse and can use schedules to reduce IT management,
users have increased flexibility to create and modify their own reports to suit their
unique work environment.

Privileges required for Developer and Web users

You can assign related privileges to different user groups on Developer or Web to
perform specific tasks. The following list summarizes which privileges can be assigned
for which user groups:
Common privileges: The predefined MicroStrategy Web Reporter and Analyst
user groups are assigned the set of common privileges by default. Within the set of
common privileges, the following privilege is specific to OLAP Services:
Drill within Intelligent Cube: This privilege allows you to drill within an
Intelligent Cube, which means that the drill can be resolved through OLAP
Services and therefore does not need to generate and execute SQL against the
warehouse.
Use Dynamic Sourcing: This privilege lets you to use Dynamic Sourcing,
which allows non-OLAP Services reports use Intelligent Cubes that satisfy their
data requirements.
Use OLAP Services: This privilege lets you create and execute reports and
documents that use OLAP Services.
Web Analyst: The predefined MicroStrategy Web Analyst group is assigned the set
of Web Analyst privileges by default. This group also inherits all of the privileges
assigned to the Web Reporter group. Within the set of Web Analyst and Reporter
privileges, the following privileges are specific to OLAP Services users:
Web add/remove units to/from grid in document in View mode: This
privilege allows you to add to or remove report objects from an existing grid
report in a Report Services document.
Web create derived metrics: This privilege allows you to create new
calculations based on other metrics already on a base report.

2017, MicroStrategy Inc. 17

In-memory Analytics Guide

Web number formatting: This privilege allows you to change number

formats for all metrics on grid reports.
Web use Report Objects window: This privilege allows you to use the
Report Objects pane. With the Report Objects pane, you can use dynamic
aggregation to change the attributes available on the report layout.
Web use View Filter Editor: This privilege allows you to add or modify a
view filter for a report.
Analyst: The predefined MicroStrategy Analyst group is assigned this set of
privileges by default. Within the set of Analyst privileges, the following privileges are
specific to OLAP Services:
Create derived metrics: This privilege allows you to create new calculations
based on other metrics already on a base report.
Use Report Objects window: This privilege allows you to use the Report
Objects pane. With the Report Objects pane, you can use dynamic aggregation to
change the attributes available on the report layout.
Use view filter editor: This privilege allows you to add or modify a view filter
for a report.
For information on all user privileges, see the Supplemental Reference for System
Administration.

Report types: Standard and OLAP reports

During the report design process, if none of the OLAP Services features are applied on
the report, then the report remains a standard report. This is indicated by the word
Standard in the bottom right corner of the Report Editor, as shown below.

18 2017, MicroStrategy Inc.

 In-memory Analytics Guide

In Developer, the moment you use an OLAP Services feature, whether it is dynamic
aggregation, a derived metric, a derived element, or a view filter, the standard report
becomes an OLAP report, as shown in the following image. Notice that Standard is
replaced by OLAP after a view filter is applied.

The report type change from Standard to OLAP is displayed only in Developer. The
same indication is not shown on reports in MicroStrategy Web.

When a saved OLAP Services report is opened again, it remains an OLAP Services
reportwhile a Standard report can be turned into an OLAP Services report, but an
OLAP Services report cannot be turned into a Standard report.

Standard OLAP analysis features

Whether you use MicroStrategy Developer or Web, once you execute a report, you can
perform various OLAP manipulations on the report using features such as banding,
sorting, pivoting, page-by, and so on. These features do not cause the report to be re-
executed against the warehouse, and therefore have a much faster response time.
These standard OLAP features are different than the OLAP Services features covered in
this guide. Each standard OLAP feature is described briefly in the following sections
below. These features listed below are covered in detail in the Basic Reporting Guide and
Advanced Reporting Guide:
Aliasing , page 20
Banding , page 20
Outline mode, page 20
Page-by , page 20
Pivoting, page 20

2017, MicroStrategy Inc. 19

In-memory Analytics Guide

Sorting, page 21
Subtotals, page 21
Thresholds, page 21

Aliasing
When displaying a report, you can use the aliasing feature to rename any object on the
report grid, such as attribute names, consolidation names, custom group names, and
metric names. You can perform this task from both MicroStrategy Developer and Web.

Banding
Banding allows you to color groups of rows or columns so that they form bands of data
that are easy to locate and analyze. Banding can also make it easier to make sense of a
very large report, because the large amounts of data are broken up into visual groups. If
you need to keep track of values that mean different things in different columns (for
example, dollars in one column and inventory quantities in another column), banding
can help you avoid reading the wrong number.
Banding is a method of organizing or grouping data values in a grid report according to
certain criteria. You can band rows or columns in several ways. You can band based on
the number of rows or columns (for example, alternating color every 5 rows). You can
also band data based on the row and column headers (for example, sorting the Units Sold
column in order, then applying alternating colors to sets of values). For information on
applying banding to a report, see the Basic Reporting Guide.

Outline mode
Outline mode allows you to create an indented grouping of related attribute elements.
You can collapse and expand sections of related data. This function is particularly useful
in instances where the information displayed would otherwise involve repetitive entries.
For example, in the case of a grid report showing sales by year, each year is broken down
by month. With outline mode enabled, the data is organized into groups, with months of
each year nested below the years.

Page-by
Page-by is a way to segment data in a grid report by placing available attributes,
consolidations, or metrics on a third axis called the Page axis. Based on the varying
objects on the axis, you can view the report data in separate pages. This feature is most
useful when you have an extremely long report with many objects, and you need to scroll
to see all the data. You can page by many objects, such as attributes, metrics, hierarchies,
consolidations, custom groups, and so on.

Pivoting
Pivoting enables you to rearrange the columns and rows in a report to view data from
different perspectives. With data pivoting, you can do the following:
Move an object from the row header to the column header

20 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Move an object from the column header to the row header

Change the order of objects in the row header
Change the order of objects in the column header

Sorting
Sorting allows you to specify an ascending or descending order for a particular row or
column to present the report data. You can select what objects you want to sort, the
sorting criteria, and the sorting order. MicroStrategy Developer and Web offer quick sort,
advanced sort, and hierarchical sort.

Subtotals
Using the Subtotal feature, you can add, remove, and edit the subtotals at different levels
for metrics on the report. The subtotal functions available include sum, count, min, max,
average, mean, median, and so on. You might choose to display all subtotals, a grand
total only, or subtotals across levels where you select the object to be subtotaled.
Additionally, Developer allows you to construct custom subtotals that, for example, allow
you to enable subtotals for selected metrics only.

Thresholds
A threshold highlights data that meets conditions defined by you. Highlighting data can
include using different cell formats, symbols, images, or replacement text.

2017, MicroStrategy Inc. 21

 2
SHARING SETS OF DATA
AMONG REPORTS:
INTELLIGENT CUBES
Intelligent Cubes are multi-dimensional cubes (sets of data) that allow you to use OLAP
Services features on reports, as well as share sets of data among multiple reports.
MicroStrategy Intelligent Cube Technology allows you to create these Intelligent
Cubes, which operate within MicroStrategy Intelligence Server.
An Intelligent Cube is a set of data that can be shared as a single in-memory copy, among
many different reports created by multiple users. Rather than returning data from the
data warehouse for a single report, you can return sets of data from your data warehouse
and save them directly to Intelligence Server memory. The reports accessing Intelligent
Cubes can use all of the OLAP Services features for analysis and reporting purposes.

Sharing Intelligent Cubes

MicroStrategy 9.0 and later enhances the scalability and manageability of OLAP Services
with the addition of sharable Intelligent Cubes. Intelligent Cubes allow multiple reports
to retrieve data from a single shared in-memory set of data.
You create Intelligent Cubes and publish them as a shared data source for the users to
build reports from. Intelligent Cubes provide the fast response time and analytic
calculations that are often associated with Multidimensional Online Analytic Processing
(MOLAP) cubes, while also benefiting from the ability to use Relational Online Analytic
Processing (ROLAP) by drilling into the full set of data outside of the Intelligent Cube. In
addition, Intelligent Cubes are fully scalable, limiting excessive data consumption and
redundant data by allowing you to build only the sets of data you require.
With Intelligent Cubes you can return a specific set of data from your data warehouse.
Users can then create reports that display and analyze a subset of the set of data defined
in an Intelligent Cube. This process is different than the common approach of creating a
report that directly accesses the data warehouse.

2017, MicroStrategy Inc. 22

In-memory Analytics Guide

Intelligent Cubes act as a layer between your data warehouse and MicroStrategy reports
that analyze and display data, as illustrated below.

The abstraction that Intelligent Cubes provide between your data warehouse and reports
can improve the performance of your business intelligence application in the following
ways:
Reports that connect to an Intelligent Cube can perform reporting and analysis
manipulations within the Intelligent Cube without hitting the data warehouse. These
manipulations are executed much faster than running a new query against a data
warehouse.
The data that reports can access is restricted to the data within the Intelligent Cube.
Users can still perform a few ROLAP manipulations such as drilling that can access
the data warehouse. However, these types of manipulations that cause re-execution
against the data warehouse are not as accessible as they are when using standard
reports.
For example, when using a standard report, users can access any attribute defined for
the project and include it on the report. A manipulation of this type requires re-
execution against the data warehouse. Conversely, a user working in a report that
connects to an Intelligent Cube can only add attributes to the report grid if the
attributes are included in the Intelligent Cube.
Therefore, Intelligent Cubes help to limit the amount of processing done in the data
warehouse and improve performance.
Security filters are applied separately for each user at the level of the report
connecting to the Intelligent Cube, rather than having to create multiple Intelligent
Cubes for each security filter. For more information, see Maintaining data access
security, page 23.

Maintaining data access security

Reports that connect to Intelligent Cubes adhere to many of the same standards of data
access security as the rest of your MicroStrategy project. You can control users access to

23 2017, MicroStrategy Inc.

 In-memory Analytics Guide

data with security filters. For more information on security filters, see the System
Administration Guide.
User and group security filters are applied automatically on reports that connect to an
Intelligent Cube, as shown below:

This approach allows a single Intelligent Cube to be used by multiple security filters,
rather than having to create separate Intelligent Cubes for each security filter. By using a
single Intelligent Cube to support all the security filters for a project, data access security
is implemented automatically with minimal burden on Intelligence Server memory.
However, there are some differences in security filter resolution for reports that connect
to Intelligent Cubes as compared to reports that directly access the data warehouse. For
information on these differences, see Security filter resolution for reports connected to
Intelligent Cubes, page 24 below.

Security filter resolution for reports connected to Intelligent Cubes

Security filter resolution for reports that connect to Intelligent Cubes differs as compared
to reports that directly access the data warehouse. These differences relate to what
attributes are on a users security filter, and how these relate to the attributes and fact
entry levels of metrics available in the Intelligent Cube used for the report.
If all attributes in a users security filter are in the Intelligent Cube that is used for the
report, then security filters can be resolved using the standard process. However, if some
of the attributes in a users security filter are not in the Intelligent Cube used for the
report, security filter resolution can differ from the standard process.
While this scenario is uncommon, it can cause users of reports that access Intelligent
Cubes to experience one of the following results:
No data is returned for the report.
This could also be caused by the user creating a view filter that is too restrictive, or by
the users normal security filter resolution.
A metric or metrics are displayed with no data returned for the metric.

2017, MicroStrategy Inc. 24

In-memory Analytics Guide

Another possible cause of metrics not properly returning data on reports connected
to Intelligent Cubes is the use of dynamic aggregation (see Chapter 9, Dynamic
Aggregation). However, when this is caused by dynamic aggregation, null values are
displayed for the metric rather than not displaying any information at all. The image
below shows the difference between security filter resolution and dynamic
aggregation as the cause for metrics not displaying any data.

By default, null values are represented by dashes (--) on reports. For information
on changing the display of null values, see Changing the display of null values,
page 255.

For more specific scenarios and examples of when security filter resolution can occur,
see Security filter resolution when attributes in a users security filter are not in the
Intelligent Cube used for the report, page 26.
If a user is experiencing one of the two scenarios listed above due to security filter
resolution, the following resolutions can be considered:

Resolution Pros Cons

The user continues to Data access security is maintained. No Some data that may
use the report that additional resources are needed to be available to the
accesses the Intelligent modify the Intelligent Cube or to create a user by directly
Cube. new report. querying a data source
may not be available in
the report that
accessed an Intelligent
Cube.

25 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Resolution Pros Cons

The user creates or The user is able to verify the full results A new report that
views a report with the that can be returned for such a report. directly queries a data
same definition that source must be
directly queries a data created.
source rather than
accessing an Intelligent The new report cannot
Cube. take advantage of the
improved query
performance of
accessing an
Intelligent Cube.
Add the attributes used The security filter resolution for the user The Intelligent Cube
in a users security filter can use the standard process and return must be published
to the Intelligent Cube the same data as if the report were again to reflect the
and publish the directly querying a data source. This is new definition.
updated Intelligent also helpful if multiple users could benefit Publishing the
Cube. from the same change to the Intelligent Intelligent Cube can
Cube definition. require substantial
system resources.
Including additional
attributes requires
more memory for the
Intelligent Cube to be
stored on Intelligence
Server.

Security filter resolution when attributes in a users security filter are not in the
Intelligent Cube used for the report
When attributes in a users security filter are not in the Intelligent Cube used for the
report, the outcome depends on how the attributes are related to those in the Intelligent
cube, as described below:
Attributes in the security filter are related to attributes in the
Intelligent Cube: No data is returned, to maintain data access security.
For example, an Intelligent Cube includes the attributes Year and Region, and the
metric Revenue. A user creates a report that connects to this Intelligent Cube, and
includes Year and Revenue on the report. The users security filter is defined on the
attribute Quarter to return data only for the first quarter of 2008.
By including the Year attribute on the report, this report would return information
for all quarters in each year. However, the user is allowed to only see data for the
first quarter of 2008. To maintain this data access security, no data is returned for
the report.
Attributes in the security filter are not related to attributes in the
Intelligent Cube: The data returned depends on whether metrics in the Intelligent
Cube report fact data based on attributes related to those in the users security filter:

2017, MicroStrategy Inc. 26

In-memory Analytics Guide

A metric in the Intelligent Cube reports fact data based on an

attribute related to one in the security filter: The users security filter
prevents any data from being returned.
For example, an Intelligent Cube includes the attributes Year and Region, and
the metric Revenue, which is based on the fact Revenue. This fact, in turn, is
reported based on the attributes Item, Day, and Call Center. A user creates a
report that connects to this Intelligent Cube, and includes Year and Revenue on
the report. However, this users security filter is defined on the attribute Category
to return data only from Books.
Since Revenue is based on Item, Day and Call Center only, it cannot be reported
based on the Category attribute. In such a case, no data will be reported for the
Revenue metric.
A metric in the Intelligent Cube reports fact data based on an
attribute unrelated to those in the security filter: The security filter
does not apply any restriction, and displays the data for metrics based on the
fact.
The table below describes the security filter resolution for scenarios listed above:

A fact in the Intelligent Cube is reported A fact in the Intelligent Cube is not
based on an attribute in the security filter reported based on any of the
attributes in the security filter

Attributes in No data is returned, to maintain data access No data is returned, to maintain

the security security. data access security.
filter are
related to
attributes in
the Intelligent
Cube

Attributes in Data can be returned using the standard Data can be returned using the
the security security filter resolution. However, to maintain standard security filter resolution. In
filter are not
related to
data access security, no data is displayed for this scenario the security filter does
attributes in any metrics where fact data is reported based not need to restrict any data, and
the Intelligent on attributes related to those in the security the metric data can also be
Cube filter. displayed.

Data access security with connection mapping

In MicroStrategy, you can also use connection mapping to control the data that users
have access to when they run reports. You can also apply this security when users create
reports that connect to an Intelligent Cube. For information on maintaining data access
security with connection mapping to Intelligent Cubes, see the System Administration
Guide.

Setting permissions for individual Intelligent Cubes

You can use an Intelligent Cubes Access Control List (ACL) to set specific access
permissions for users. For example, you can restrict some users to only create reports
based on an Intelligent Cube, but not re-execute the Intelligent Cube.

27 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You can use the ACL Editor in -MicroStrategy Web to assign the following permission
groups to users, for each Intelligent Cube:

Group Description Permissions

granted

Consume Grants permission to create and execute reports based on this Browse
Intelligent Cube.
Read
Use
Add Grants permission to create and execute reports based on this Browse
Intelligent Cube, and republish/re-execute the Intelligent Cube to
update the data. Read
Use
Execute
Collaborate Grants permission to create and execute reports based on this Browse
Intelligent Cube, republish/re-execute the Intelligent Cube to update the
data, and modify the Intelligent Cube. Read
Write
Delete
Use
Execute

For information on ACLs and access permissions, see the System Administration Guide.

Creating Intelligent Cubes

Creating Intelligent Cubes is as easy as creating reports. This section covers the following
methods for creating Intelligent Cubes:
Prerequisites to creating Intelligent Cubes, page 29
Supporting various features with Intelligent Cubes, page 29
Building an Intelligent Cube, page 30
Converting reports into Intelligent Cubes, page 32
Updating Intelligent Cubes using schedules, page 33
You need the Use Intelligent Cube Editor privilege to create Intelligent Cubes. This
privilege is part of OLAP Services.
After you have created your Intelligent Cube, you can publish its set of data to be shared
by multiple reports. For more information on publishing an Intelligent Cube, see
Publishing Intelligent Cubes, page 39.

2017, MicroStrategy Inc. 28

In-memory Analytics Guide

Prerequisites to creating Intelligent Cubes

Make sure you review the following prerequisites before you create an Intelligent Cube in
MicroStrategy. They can save you time and make your Intelligent Cubes more effective
for your reporting environment:

While creating Intelligent Cubes, bear in mind that Intelligent Cubes can deplete
Intelligence Servers system resources. Create Intelligent Cubes for logical subsets
of your data, rather than using them as a reflection of your entire data warehouse.
For information on managing the size of Intelligent Cubes, see Managing
Intelligent Cubes in the System Administration Guide.

Define your business query: Before you can determine what objects to place on an
Intelligent Cube, you need to know what data you want to make available for reports
to access directly. To define your Intelligent Cube, make sure you consider the
following questions:
What subset of business queries does the Intelligent Cube need to provide data
for? Intelligent Cubes allow you to create sets of data that can support multiple
reports that answer variations to similar business queries.
Do you have reports that currently access your data warehouse that could benefit
from accessing an Intelligent Cube instead? To support this scenario, you can use
dynamic sourcing to connect these reports to Intelligent Cubes that you create.
You can also use MicroStrategy Cube Advisor to create Intelligent Cubes that
these reports can access. For information on using Cube Advisor to support
dynamic sourcing, see Using Cube Advisor to support dynamic sourcing, page
218.
Look for existing Intelligent Cubes: Before you create an Intelligent Cube, search
through MicroStrategy to see whether a similar Intelligent Cube already exists that
can serve the same purpose as the Intelligent Cube that you intend to create. This
can not only save you time, it can help you avoid unnecessary duplication in your
MicroStrategy project. You can search a project for Intelligent Cubes, or you can
view Intelligent Cubes created for your projects in the Intelligent Cube Monitor. For
information on using the Intelligent Cube Monitor, see the System Administration
Guide .
Review the feature support for Intelligent Cubes: The MicroStrategy features that are
available for Intelligent Cubes differ from those available for reports. To review this
list, see Supporting various features with Intelligent Cubes, page 29 below.

Supporting various features with Intelligent Cubes

Intelligent Cubes act as a set of data for other reports to connect to and use OLAP
Services to report, analyze, and display data. Since Intelligent Cubes function simply as a
set of data, Intelligent Cubes do not need to contain objects that modify the display of
data. The display of data is handled by the reports that access the Intelligent Cube.
For these reasons, the following objects and features cannot be included in Intelligent
Cubes in the same ways that they can be included for reports:

29 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Consolidations and custom groups: Consolidations and custom groups cannot

be included in Intelligent Cubes or in reports that access Intelligent Cubes. However,
you can include derived elements in reports that access Intelligent Cubes. Derived
elements combine the analysis features of consolidations and custom groups, while
executing against the Intelligent Cube rather than the data warehouse. For
information on derived elements, see Chapter 5, Derived Elements.
OLAP Services features: View filters, derived metrics, and derived elements
cannot be included in Intelligent Cubes, but these features are the main analysis tools
for reports that access Intelligent Cubes. For an overview of OLAP Services features
and how these can be created in reports, see Chapter 1, About MicroStrategy OLAP
Services.
Transformation shortcut metrics: These metrics can be created on reports
using a similar workflow as derived metrics that are created as shortcut metrics. For
information about the difference between transformation shortcut metrics and
shortcut metrics that are also derived metrics, see Using rank and percent-to-total
metric analysis , page 149. As an alternative, you can create transformation metrics
using the Metric Editor. Metrics that use transformations in this way can be included
in Intelligent Cubes. To create transformation metrics using the Metric Editor, see
the Advanced Reporting Guide.
Prompts: Prompts cannot be included in Intelligent Cubes. However, reports that
access Intelligent Cubes can use prompts that access only data included in the
Intelligent Cube. This saves processing time by ensuring that re-execution against the
data warehouse is not necessary.

Building an Intelligent Cube

Building an Intelligent Cube is similar to building a report. You can add data for your
Intelligent Cube by including objects such as attributes, metrics, filters, and so on as
report objects or report filters. For a list of objects and features that cannot be included
in the definition of Intelligent Cubes, see Supporting various features with Intelligent
Cubes, page 29.

2017, MicroStrategy Inc. 30

In-memory Analytics Guide

Since Intelligent Cubes are used simply to share a set of data, no data or report results are
displayed when you execute an Intelligent Cube. However, executing an Intelligent Cube
publishes the Intelligent Cube, which can then be accessed as a set of data for multiple
reports (see Publishing Intelligent Cubes, page 39).
Prerequisites
Review the information provided in Prerequisites to creating Intelligent Cubes, page
29.
You need the Use Intelligent Cube Editor privilege to create Intelligent Cubes. This
privilege is part of OLAP Services.

To build an Intelligent Cube

1 In Developer, from the File menu select New, and then Intelligent Cube. The
New Intelligent Cube dialog box opens.

If the New Intelligent Cube dialog box does not open, from the Tools menu,
select Developer Preferences. Expand the Object Templates category,
select General, and from the Show templates for the following objects list,
select Report. Click OK to accept your changes, and then repeat the previous
step to open the New Grid dialog box.

31 2017, MicroStrategy Inc.

 In-memory Analytics Guide

2 Select Empty Intelligent Cube and click OK. The Report Editor opens.
3 Add objects such as attributes, metrics, and so on for the Intelligent Cube, the same
way you would add report objects.
4 Create a filter for the Intelligent Cube as needed.

If you create a filter on an Intelligent Cube, any data that is restricted from the
Intelligent Cube is not available for any reports that connect to the Intelligent
Cube. While this can help reduce the size of the Intelligent Cube, it also
reduces the amount of data available in the Intelligent Cube.

5 Click Save and close to save the Intelligent Cube and close the Report Editor.
6 To publish an Intelligent Cube, see Publishing Intelligent Cubes, page 39.

Building Intelligent Cubes from MDX data sources, or using Freeform

SQL
You can create Intelligent Cubes with data from an MDX data source, such as SAP BW,
Hyperion Essbase, or Microsoft Analysis Services. To create an Intelligent Cube based on
MDX data in Developer, open the File menu, select New, and select Intelligent Cube.
In the New Intelligent Cube dialog box, select the MDX Sources tab. For instructions
on configuring MDX sources, refer to the MDX Cube Reporting Guide.
You can also create Intelligent Cubes by directly querying your data using SQL. You can
use Freeform SQL to write your own SQL statements, or Query Builder to create a query
using a graphical interface. These options are available in the New Intelligent Cube dialog
box, under the ODBC Sources tab. For information on using Freeform SQL and Query
Builder to connect to ODBC data sources, see the Advanced Reporting Guide.

Converting reports into Intelligent Cubes

If you have an existing report that contains a set of objects you want to use in an
Intelligent Cube, you can convert the report into an Intelligent Cube.
Creating an Intelligent Cube by converting a report allows you to view the set of data you
are including in your Intelligent Cube. This is an easy way to share a reports set of data
among multiple reports.
Intelligent Cubes do not display report results in the same way as reports can. Instead of
building an Intelligent Cube from the start, you can build a report; execute it; view the
report data in grid, graph, or grid and graph mode; and then convert the report to an
Intelligent Cube. With this method you can verify that you have the set of data you want,
rather than just the required report objects, before you publish it as an Intelligent Cube.
When you convert a report to an Intelligent Cube, some parts of the report are not
included in the resulting Intelligent Cube. Intelligent Cubes are not used for the same
display and analysis purposes as a report. Intelligent Cubes simply act as a sharable set of
data. Therefore, when a report is converted into an Intelligent Cube, some of the display
and analysis features are no longer necessary. For a list of features that are not included

2017, MicroStrategy Inc. 32

In-memory Analytics Guide

in an Intelligent Cube when converting a report to an Intelligent Cube, see Supporting

various features with Intelligent Cubes, page 29.
The procedure below explains the high-level steps for converting a report to an
Intelligent Cube. The procedure assumes you have already created a report.
Prerequisites
You need the Use Intelligent Cube Editor privilege to create Intelligent Cubes. This
privilege is part of OLAP Services.

To convert a report to an Intelligent Cube

1 Right-click the report and select Edit. The Report Editor opens.
2 From the Data menu, point to Intelligent Cube Options, and select Convert to
Intelligent Cube.
3 If the report contains objects that cannot be included in the Intelligent Cube, one of
the following messages is displayed:
If the report includes OLAP Services features such as view filters, derived
metrics, or dynamic aggregation, you are prompted to automatically remove
these features as part of the conversion process. Click Yes to have these features
automatically removed so that the report can be converted into an Intelligent
Cube.
If the report includes features such as consolidations, custom groups, or
prompts, a warning message is displayed that explains that these objects cannot
be included in the Intelligent Cube. Click OK to close the warning message and
then manually remove the objects from the report. You can then attempt to
convert the report to an Intelligent Cube again.
4 After the conversion process is completed successfully, save the Intelligent Cube.
5 You must publish an Intelligent Cube to make it available for multiple reports to
access and report on its set of data. To publish an Intelligent Cube, see Publishing
Intelligent Cubes, page 39.

Updating Intelligent Cubes using schedules

While you are creating or modifying an Intelligent Cube, you can schedule when an
Intelligent Cube should be re-executed against the data warehouse to update its data. For
example, you can schedule to re-execute and republish an Intelligent Cube when a
database load occurs.
The procedure below describes the steps to create a subscription that schedules the re-
execution and republication of a single Intelligent Cube. You can also schedule multiple
Intelligent Cubes to be updated using a single subscription, which is described in
Publishing Intelligent Cubes using a schedule, page 40.
Prerequisites
An Intelligent Cube has been created.

33 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You have created the schedule to subscribe the publication of an Intelligent Cube to.
For information on creating schedules, see the System Administration Guide.

To schedule an Intelligent Cube to be updated

1 In Developer, browse to an Intelligent Cube.

2 Right-click the Intelligent Cube, point to Schedule Delivery To, and then click
Refresh Cube. The Subscription Editor opens.
3 Select a schedule from the Schedule drop-down list.
4 Select other schedule options as required, and click OK. The Subscription Editor
closes and you are returned to Developer.
Once the schedule is triggered the Intelligent Cube is re-executed against the data
warehouse and published to the Intelligent Cube Monitor.

Enabling ROLAP drilling for reports accessing

Intelligent Cubes
Reports that access an Intelligent Cube can be granted full ROLAP access to the data
warehouse through drilling. This means that you can enable drilling outside of the
Intelligent Cube to access the full set of data available in the data warehouse.
While this extends the analysis and data access capabilities of reports that access
Intelligent Cubes, drilling outside of an Intelligent Cube can require additional load on
the Intelligence Server and data warehouse. This is because drilling outside of an
Intelligent Cube requires a new report to be executed against the data warehouse.
All reports that access Intelligent Cubes can drill within the data included in an
Intelligent Cube. This provides ROLAP-type analysis without having to re-execute against
the data warehouse. For example, an Intelligent Cube includes Year and Quarter. A
report accessing the Intelligent Cube only includes Year on the report. On the report, you
can drill down from Year to Quarter, which returns the results without any extra load on
the data warehouse or Intelligence Server.
The decision to enable or disable drilling outside of an Intelligent Cube depends on a few
factors. You should consider the size and complexity of your Intelligent Cubes when
deciding whether to enable drilling outside of an Intelligent Cube. While enabling drilling
outside of relatively small Intelligent Cubes can give the benefit of ROLAP analysis
through drilling, enabling this analysis on relatively large Intelligent Cubes has the
potential to cause increased load on your data warehouse and Intelligence Server.
By enabling drilling outside of an Intelligent Cube, reports that access the Intelligent
Cube have ROLAP access to data through drilling. For example, an Intelligent Cube
includes Year but not Quarter. A report accessing the Intelligent Cube includes Year and
drilling outside of the Intelligent Cube is enabled. On the report, you drill down from
Year to Quarter. This causes a new report to be created and executed against the data
warehouse.
The benefit of enabling this extra analysis can come with a performance cost. As
mentioned above, when you drill outside of an Intelligent Cube a new report is created

2017, MicroStrategy Inc. 34

In-memory Analytics Guide

and executed against the data warehouse. This action does not take advantage of the data
stored in the Intelligent Cube.
When this drilled-to report is created, only objects that were on the report layout of the
report you drilled from are included in the drilled-to report. Any objects that are only in
the Report Objects pane of the report you drilled from are not included in the drilled-to
report. This can help reduce the size of the drilled-to report. However, if you are drilling
from a report that accesses a large Intelligent Cube, it is possible that a user could include
all objects of an Intelligent Cube on a report. Drilling outside of the Intelligent Cube on
such a report could cause excessive load on the data warehouse and Intelligence Server.
The procedures below describe the steps to enable drilling outside of a specific Intelligent
Cube, or any Intelligent Cubes in a project:
To enable or disable drilling outside of an Intelligent Cube for reports accessing a
specific Intelligent Cube, page 35
To enable or disable drilling outside of an Intelligent Cube for reports accessing
any Intelligent Cubes in a project, page 36
Prerequisites
An Intelligent Cube has been created.
You need the Use Intelligent Cube Editor privilege. This privilege is part of OLAP
Services.

To enable or disable drilling outside of an Intelligent Cube for reports

accessing a specific Intelligent Cube

1 In Developer, browse to an Intelligent Cube.

2 Right-click the Intelligent Cube, and select Edit. The Intelligent Cube is opened in
the Report Editor.
3 From the Data menu, select Configure Intelligent Cube. The Intelligent Cube
Options dialog box opens.
4 From the Categories list, expand Options, and then select General.
5 In the Drilling area, clear the Use default settings check box.
6 Select the Allow reports to drill outside the Intelligent Cube check box.
You can clear this check box to disable drilling outside of an Intelligent Cube.
7 Click OK. The Intelligent Cube Options dialog box closes and you are returned to the
Intelligent Cube.
8 Click Save and Close to save your changes and close the Report Editor.
9 To make your changes available for reports accessing the Intelligent Cube, you must
publish the Intelligent Cube, which is described in Publishing Intelligent Cubes, page
39.

35 2017, MicroStrategy Inc.

 In-memory Analytics Guide

To enable or disable drilling outside of an Intelligent Cube for reports

accessing any Intelligent Cubes in a project

This procedure enables drilling outside of all Intelligent Cubes within a project.
Review the considerations in Enabling ROLAP drilling for reports accessing
Intelligent Cubes, page 34 before enabling drilling outside of all Intelligent Cubes
for a project.

1 In Developer, log in to a project with a user account with administrative privileges.

2 Right-click the project and select Project Configuration. The Project
Configuration Editor opens.
3 From the Categories list, expand Intelligent Cubes, and then select General.
4 Select the Allow reports to drill outside the Intelligent Cube check box.
You can clear this check box to disable drilling outside of Intelligent Cubes.
5 Click OK. The Project Configuration Editor closes.
6 To make your changes available for reports accessing the Intelligent Cubes, you must
publish the Intelligent Cubes, which is described in Publishing Intelligent Cubes,
page 39.

Localizing Intelligent Cubes in multiple languages

If your MicroStrategy project supports the localization of information into multiple
languages, you can also support this localization to provide Intelligent Cubes in multiple
languages.
When an Intelligent Cube is defined to support a language, data is available for the
Intelligent Cube in that language. When a user logs in to MicroStrategy in the locale for
that language and creates or views a report that accesses the Intelligent Cube, all data
that has been localized is returned.
For example, a report connected to an Intelligent Cube includes Region, Category, Profit,
and Discount. The Intelligent Cube is defined to include information for the English and
Italian locales. This report connected to the Intelligent Cube is executed by a user with
an English locale. This same report is also executed by a user with an Italian locale. The
report results displayed to the users in the two locales are shown below:

2017, MicroStrategy Inc. 36

In-memory Analytics Guide

The same report returns data that matches the users locale. This is because the
Intelligent Cube has been defined to include localized data.
The SQL view of these reports shown below demonstrates how the data is returned in
different languages:

Notice that different columns of data were returned for the report based on the locale
used to run the report. This demonstrates a column-based solution to localizing your
data. It is recommended that you use a column-based solution rather than a connection
mapping-based solution to localize your data for Intelligent Cubes. For information on
this recommendation, see the Supplemental Reference for System Administration.
Localizing an Intelligent Cube does not localize any data, it only returns data that has
already been configured in a MicroStrategy project as part of a localization solution. For

37 2017, MicroStrategy Inc.

 In-memory Analytics Guide

information on defining localization rules for your MicroStrategy projects, see the
Project Design Guide.
Providing localized data causes the Intelligent Cube size to be larger than if it supported
only a single locale. However, providing localized data in Intelligent Cubes is necessary if
users expect reports that return Intelligent Cube data to return localized data to reflect
their locale.
The steps below let you define Intelligent Cubes to support various languages.
Prerequisites
An Intelligent Cube has been created.
The project for the Intelligent Cube has been configured to support multiple
languages. For information on localizing projects, see the Project Design Guide.
You need the Use Intelligent Cube Editor privilege. This privilege is part of OLAP
Services.

To support multiple languages in an Intelligent Cube

1 In Developer, browse to an Intelligent Cube.

2 Right-click the Intelligent Cube and select Edit. The Intelligent Cube opens in the
Report Editor.
3 From the Data menu, select Configure Intelligent Cube. The Intelligent Cube
Options dialog box opens.
4 From the Categories list, expand Options, and then select Data Languages.
5 Select from the following localization options:
Use project default data language (Default): Select this option to provide
data only in the default language for the project. The default language for the
project is highlighted in blue.
All project data languages: Select this option to provide data for the
languages available for the project.
Select specific languages: Select this option to select from all languages
available for the project. Data is provided for the languages you select.
All of these options are based on the language options defined for the project, which
can be modified from the Project Configuration Editor. For information on
localizing projects, see the Project Design Guide.
6 Click OK. The Intelligent Cube Options dialog box closes and you are returned to the
Intelligent Cube.
7 Click Save and Close to save your changes and close the Report Editor.
8 To make your changes available for reports accessing the Intelligent Cube, you must
publish the Intelligent Cube, which is described in Publishing Intelligent Cubes, page
39.

2017, MicroStrategy Inc. 38

In-memory Analytics Guide

Enabling dynamic sourcing of Intelligent Cubes

The general workflow of reporting on data in Intelligent Cubes is to create a report that
is linked to a published Intelligent Cube. Dynamic sourcing extends the accessibility of
Intelligent Cubes by allowing standard reports to access any published Intelligent Cubes
that can satisfy the data requirements of the report. This connection is performed
automatically without the user having to explicitly connect their report to a published
Intelligent Cube. This allows users performing ROLAP analysis to work completely
within a pre-created set of data without having to manually find and select the Intelligent
Cube that fits their analysis.
For information on dynamic sourcing, see Chapter 8, Dynamic Sourcing.

Publishing Intelligent Cubes

Publishing an Intelligent Cube retrieves data from the data warehouse and stores this
data as an Intelligent Cube in Intelligence Server memory. Once an Intelligent Cube is
stored in Intelligence Server memory, multiple reports can be created to view and
analyze the set of published data.
When an Intelligent Cube is published, the Intelligent Cube Monitor displays the
Intelligent Cube. You can manage your published Intelligent Cubes from the Intelligent
Cube Monitor. For more information on managing Intelligent Cubes, see the System
Administration Guide.

Publishing or re-publishing an Intelligent Cube can require significant memory

resources. It is recommended that you use incremental refresh settings to add new
data to the Intelligent Cube. For information on setting up incremental refreshes,
see Updating Intelligent Cubes without re-processing: Incremental Refresh, page
43.

You can publish Intelligent Cubes manually, or you can schedule the publication of
Intelligent Cubes for a specific time, as described in:
Publishing Intelligent Cubes manually, page 39
Publishing Intelligent Cubes using a schedule, page 40
Unpublishing an Intelligent Cube, page 42

Publishing Intelligent Cubes manually

The procedure below provides the steps to manually publish an Intelligent Cube.

The act of publishing an Intelligent Cube can require memory resources

approximately two times greater than the size of an Intelligent Cube. This can
affect performance of your Intelligence Server as well as the ability to publish the
Intelligent Cube. To plan for these memory requirements, see the System
Administration Guide.

39 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Prerequisites
An Intelligent Cube has been created. For information on creating an Intelligent
Cubes, see Creating Intelligent Cubes, page 28.
You need the Publish Intelligent Cube (Developer) and/or Web Publish Intelligent
Cube (Web) privileges. These privileges are part of OLAP Services.

To publish an Intelligent Cube manually

The steps below show you how to publish an Intelligent Cube in Developer. You can
follow the same high-level steps in Web to browse to an Intelligent Cube, and then run
the Intelligent Cube to publish it.
1 In MicroStrategy Developer, browse to the location of the Intelligent Cube to
publish.

If you define Intelligent Cubes to use the connection mapping configured for
your project, the Intelligent Cubes are published with the connection mapping
defined for the user account employed to publish the Intelligent Cubes. For
information on defining Intelligent Cubes to support connection mapping, see
the System Administration Guide.

2 Right-click the Intelligent Cube, and select Run.

Rather than displaying report results, a message is displayed indicating that the
Intelligent Cube has been published. After the Intelligent Cube is published, the
Intelligent Cube appears in The Intelligent Cube Monitor, which you can use to
manage your published Intelligent Cubes.

Publishing Intelligent Cubes using a schedule

As an alternative manually publishing Intelligent Cubes, you can schedule the publication
of Intelligent Cubes to occur at a time when the load on your Intelligence Server and
data warehouse is low. This allows you to publish Intelligent Cubes without affecting
performance time of Intelligence Server during peak usage.
You can also schedule the publication of Intelligent Cubes to update Intelligent Cube data
when events occur that would make the Intelligent Cube data outdated. For example, you
can schedule to republish an Intelligent Cube when a database load occurs. The
procedure below creates a subscription that can schedule multiple Intelligent Cubes to be
updated. Alternatively, you can define an Intelligent Cube to be updated on a schedule
during Intelligent Cube creation, which is described in Updating Intelligent Cubes using
schedules, page 33.
You schedule an Intelligent Cube for publication by creating a subscription for the
Intelligent Cube. The procedure below provides steps to create a subscription to schedule
the publication of an Intelligent Cube.

2017, MicroStrategy Inc. 40

In-memory Analytics Guide

You cannot create subscriptions for Intelligent Cubes that have been created using
the Import Data feature in MicroStrategy Web. For information on the Import
Data feature, refer to the MicroStrategy Web Help.

The act of publishing an Intelligent Cube can require memory resources

approximately two times greater than the size of an Intelligent Cube. This can
affect performance of your Intelligence Server as well as the ability to publish the
Intelligent Cube. To plan for these memory requirements, see the System
Administration Guide.

Prerequisites
An Intelligent Cube has been created.
You have created the schedule to subscribe the publication of an Intelligent Cube to.
For information on creating schedules, see the System Administration Guide.

To schedule the publication of Intelligent Cubes

1 In MicroStrategy Developer, log in to a project source using administrative privileges.

2 From the Administration menu, point to Scheduling, and then select
Subscription Creation Wizard. The Subscription Creation Wizard opens.
3 If the welcome page is shown, review the information and click Next.
4 On the Subscription Wizard - Specify Characteristics page, begin defining the
subscription using the following drop-down lists:
Choose a schedule for this set of subscriptions: Select a schedule to
trigger the publication of Intelligent Cubes. A schedule can be time- or event-
triggered.
Choose a project from which reports/documents will be delivered
to the recipients: Select a project that contains Intelligent Cubes to schedule
for publication. When publishing Intelligent Cubes, the Intelligent Cubes are not
delivered to a specific recipient, they are instead published to the Intelligent
Cube Monitor.
Choose a Delivery Type: Select Cube Refresh. This delivery type publishes
Intelligent Cubes to the Intelligent Cube Monitor.
5 Click Next. The Subscription Wizard - Choose Reports/Documents page opens.
6 In the Available objects pane, browse to and select Intelligent Cubes to schedule
for publication. Once selected, click the right arrow (>) to move any selected
Intelligent Cubes to the Selected objects pane.
7 Click Next. The Subscription Wizard - Choose Recipients page opens.

41 2017, MicroStrategy Inc.

 In-memory Analytics Guide

8 Keep the default user that is selected or select a different user with administrative
privileges, and click Next. The Subscription Wizard - Specify Subscription Properties
page opens.
9 You can choose from the following subscription properties:
Run subscription immediately: Select this check box if the Intelligent Cube
should be published immediately. This causes any Intelligent Cubes included in
the subscription to be published immediately. The Intelligent Cubes will also be
re-published based on the schedule used in the subscription.
Expire subscription on: Select this check box if the subscription should
expire. If you select an expiration date, the subscription is deleted on that date
and Intelligent Cubes included in the subscription are no longer scheduled for
publication. The Intelligent Cubes can be published manually.
10 Click Next. The Subscription Wizard - Summary page opens.
11 Review the summary information, and click Finish to create the subscription. If you
selected to run the subscription immediately, the Intelligent Cubes are executed
against the data warehouse and published to the Intelligent Cube Monitor.
You can view and edit the new subscription from the Subscription Manager. For
example, you can select a different schedule to use for the subscription or modify the
expiration date for the subscription. For information on subscriptions and the
Subscription Manager, see the System Administration Guide.

Unpublishing an Intelligent Cube

You can remove a published Intelligent Cube so that its data is no longer accessible by
reports. This action does not delete the Intelligent Cube object saved in a MicroStrategy
project, it only removes the Intelligent Cube from the Intelligent Cube Monitor.
Unpublishing an Intelligent Cube prevents reports that access the Intelligent Cube from
being able to load the Intelligent Cube into Intelligence Server memory. This gives you
more administrative control of when to make an Intelligent Cube available to reports.
However, be aware that unpublishing an Intelligent Cube means that any reports that
access the Intelligent Cube cannot be executed.
This same administrative control can be enforced by de-activating an Intelligent Cube.
De-activating an Intelligent Cube saves the Intelligent Cube to secondary storage, such as
a hard disk. When you re-activate the Intelligent Cube, the copy in secondary storage is
loaded back into Intelligence Server memory. This option is ideal when an Intelligent
Cube should not be used for some length of time, but after that should be available again
in its current form. For information on de-activating an Intelligent Cube, see the System
Administration Guide.

To unpublish an Intelligent Cube

1 In MicroStrategy Developer, log in to a project source with administrative privileges.

2017, MicroStrategy Inc. 42

In-memory Analytics Guide

2 From the Folder List, expand Administration, then expand System Monitors,
then expand Caches, and select Intelligent Cubes. The Intelligent Cube Monitor
is displayed.
3 Right-click an Intelligent Cube and select Delete. The Intelligent Cube is
unpublished from the Intelligent Cube Monitor and its data cannot be accessed by
reports.

Reporting and analyzing data with Intelligent Cubes

Intelligent Cube Technology allows reports to use OLAP Services features to display and
analyze data using an in-memory copy of data rather than querying the data warehouse.
For information on reporting on Intelligent Cubes, see Chapter 3, Reporting on
Intelligent Cubes.

Updating Intelligent Cubes without re-

processing: Incremental Refresh
By default, if the data in an Intelligent Cube needs to be updated, it is re-executed. All the
data for the Intelligent Cube is loaded from the data warehouse into Intelligence Server's
memory, and the existing data for the Intelligent Cube is overwritten.
However, if the Intelligent Cube is updated based on one or more attributes, such as
Month or Region, you can set up incremental refresh settings to update the Intelligent
Cube with only new data. This can reduce the time and system resources necessary to
update the Intelligent Cube periodically.
For example, you have an Intelligent Cube that contains weekly sales data. At the end of
every week, this Intelligent Cube must be updated with the sales data for that week. You
can set up incremental refresh settings so that only data for one week is added to the
Intelligent Cube.
Prerequisites
For an Intelligent Cube to qualify for an incremental refresh, it must meet the following
requirements:
The updates to the Intelligent Cube must be according to attributes only.
For example, an Intelligent Cube that must be updated with data for a month or
region qualifies for an incremental refresh.
The Intelligent Cube must not be re-processed based on a metric.
For example, an Intelligent Cube that contains data for the top 200 stores by
Revenue does not qualify for an incremental refresh.

Defining an incremental refresh for an Intelligent Cube

Once you have defined an Intelligent Cube, you can use the following methods to define
the incremental refresh options, depending on your requirements:

43 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Define Intelligent Cube republish settings. This is recommended if the Intelligent

Cube must be updated along only one attribute, or if updates along multiple attributes
must be made simultaneously.
To define Intelligent Cube republish settings, see Defining Intelligent Cube refresh
settings, page 44.
Define an incremental refresh filter or report. This is recommended if the Intelligent
Cube must be updated along different dimensions at different times, or if you want to
use the results of a report to update the Intelligent Cube.
To define an incremental refresh filter or report, see Defining an incremental
refresh filter or report, page 46.

If you choose to define an incremental refresh filter or report, you should not
re-publish the Intelligent Cube by double-clicking, or by publishing it on a
schedule. Doing so will overwrite any changes made by the incremental
refresh filter or report.

Defining Intelligent Cube refresh settings

The refresh settings change the way the Intelligent Cube is updated when you re-execute
it manually, or when it is published on a schedule, as described in Publishing Intelligent
Cubes using a schedule, page 40.
This is recommended if the Intelligent Cube must be updated along only one attribute, or
if Intelligent Cube must be updated along multiple attributes simultaneously.
Prerequisites
The Intelligent Cubes definition must include a filter that qualifies on the attributes
for which the Intelligent Cube must be updated.
For example, if the Intelligent Cube must be updated with new data for the Store
attribute, the filter must qualify on Store.

To define Intelligent Cube refresh settings

1 In Developer, navigate to the Intelligent Cube you want to define republish settings
for.
2 Right-click on the Intelligent Cube, and select Edit. The Intelligent Cube Editor
opens.
3 From the Data menu, select Configure Intelligent Cube. The Intelligent Cube
Options dialog box opens.
4 Navigate to the Data Refresh category.
5 Choose one of the following options:

2017, MicroStrategy Inc. 44

In-memory Analytics Guide

Full Refresh: This is the default. The Intelligent Cubes SQL is re-executed,
and all the data is loaded from the data warehouse into Intelligence Server's
memory.
Use this option under the following conditions:
If the data in the Intelligent Cube is outdated.
If the Intelligent Cube must be re-processed based on a metric. For example,
an Intelligent Cube that contains data for the top 200 stores by Profit must
be re-calculated every time it is updated, and thus must use the Full Refresh
option.
Dynamic refresh: The Intelligent Cube's filter is evaluated. If new data is
returned, it is added to the Intelligent Cube, and data that no longer meets the
filters criteria is deleted from the Intelligent Cube. The dynamic refresh option
is illustrated in the image below.

Select this option for Intelligent Cubes that have a rolling set of datafor
example, an Intelligent Cube that always contains data for the past six months.

If the data to be added and deleted cannot be determined, the Full

Refresh option is used as a fallback.

Update: The Intelligent Cube's filter is evaluated. If new data is returned, it is

added to the Intelligent Cube, and if the data returned is already in the
Intelligent Cube, it is updated where applicable.
Select this option if your data is updated oftenfor example, an Intelligent Cube
that contains daily sales data, and is updated at the end of every day.
Insert: The Intelligent Cubes filter is evaluated. If new data is returned, it is
added to the Intelligent Cube. Data that is already in the Intelligent Cube is not
altered.
Select this option if old data does not change once it is saved to your data
warehouse.

45 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Defining an incremental refresh filter or report

For complex update requirements, such as updating an Intelligent Cube for different
dimensions at different intervals, you can define an incremental refresh filter or report
to update your Intelligent Cube.
For example, an Intelligent Cube contains monthly sales data for 2009 and 2010 for
year-on-year comparison. Once the year 2011 begins, you only need to keep the data for
2010, and the data for 2009 can be removed from the Intelligent Cube. You can define
one incremental refresh that runs at the end of every month, and adds that month's data
to the Intelligent Cube, and a second incremental refresh that deletes the previous year's
data at the end of every year.
You can also add incremental refreshes to add data for other dimensions, such as
Country. For example, you have an Intelligent Cube that contains data for the USA, UK
and France, and you want to add data for Germany. You can define an incremental
refresh that fetches all the data for Germany, and adds it to the cube.
You can define incremental refreshes using filters or reports, as described below:
Filter: The data returned by a filter is compared to the data that is already in the
cube. By default, the filter defined for the Intelligent Cube is used as the filter for the
incremental refresh. For information on defining an incremental refresh filter, see
Defining an incremental refresh filter, page 46.
Report: The results of a report are used to populate the Intelligent Cube. By default,
the report template used is the same as the Intelligent Cube's template. For
information on defining an incremental refresh report, see Defining an incremental
refresh report, page 48.

If you choose to define an incremental refresh filter or report, you should not re-
publish the Intelligent Cube by double-clicking it, or by publishing it on a schedule.
Doing so will overwrite any changes made by the incremental refresh filter or
report.

Defining an incremental refresh filter

You can define an incremental refresh filter to update the data in an Intelligent Cube.
This is the default option for both ROLAP and MDX Intelligent Cubes, and is unavailable
for Intelligent Cubes created using Freeform SQL queries or Query Builder.

To define an incremental refresh filter

1 In Developer, navigate to the Intelligent Cube for which you want to define the
incremental refresh.
2 Right-click the Intelligent Cube, and select Define Incremental Refresh
Report. The Incremental Refresh Options dialog box opens.
3 Under Refresh type, select one of the following options. The differences between
the options are illustrated in the image below.

2017, MicroStrategy Inc. 46

In-memory Analytics Guide

Update: The incremental refresh filter is evaluated. If new data is returned, it is

added to the Intelligent Cube, and if the data returned is already in the
Intelligent Cube, it is updated where applicable.
Insert: The incremental refresh filter is evaluated. If new data is returned, it is
added to the Intelligent Cube. Data that is already in the Intelligent Cube is not
altered.
Delete: The incremental refresh filter is evaluated. The data that is returned is
deleted from the cube. For example, if the Intelligent Cube contains data for
2008, 2009 and 2010, and the filter or report returns data for 2009, all the data
for 2009 is deleted from the cube.
Update only: The incremental refresh filter is evaluated. If the data returned is
already in the Intelligent Cube, it is updated where applicable. No new data is
added to the Intelligent Cube.

You can change these options at any time by opening the incremental refresh
in the Report Editor, and from the Data menu, selecting Configure
incremental refresh options.

4 Click OK. The Report Editor opens with a new incremental refresh. If the Intelligent
Cubes definition included a filter, it appears in the Report Filter pane.
5 In the Report Filter pane, edit the filter if applicable, or create a new filter.

The filter must only qualify on attributes that are present in the Intelligent
Cube.

47 2017, MicroStrategy Inc.

 In-memory Analytics Guide

6 To preview the data that will be updated in the Intelligent Cube, from the View
menu, select Preview Data. The data is displayed in a grid view.

If your security filter prevents you from viewing some data, the preview only
displays data that you can view. However, when the incremental refresh is
executed, all the data is updated in the Intelligent Cube, regardless of security
filters.

7 To execute the incremental refresh immediately, click the Run Report button.
8 To save and close the incremental refresh, click Save and Close.

Defining an incremental refresh report

You can define a report to update an Intelligent Cube. The results of a report are
compared to the data in the Intelligent Cube, and the Intelligent Cube is updated
accordingly.
If you are updating an Intelligent Cube based on a Freeform SQL or Query Builder
report, this is the only available option.
Prerequisites
The report must use all the attributes, and at least one metric from the Intelligent
Cube that is being updated. Note that for metrics that are not on the reports
template, data is not updated.
All attributes and metrics in the reports definition should be identical to the
attributes and metrics in the Intelligent Cube. You can verify this by checking the
Global Unique Identifiers (GUIDs), by right-clicking the attribute or metric, and
choosing Properties.

To define an incremental refresh report

1 Navigate to the Intelligent Cube for which you want to define the incremental
refresh.
2 Right-click the Intelligent Cube, and select Define Incremental Refresh
Report. The Incremental Refresh Options dialog box opens.
3 Under Refresh type, select one of the following options. The differences between the
options are illustrated in the image below.

2017, MicroStrategy Inc. 48

In-memory Analytics Guide

Update: The incremental refresh report is evaluated. If new data is returned, it

is added to the Intelligent Cube, and if the data returned is already in the
Intelligent Cube, it is updated where applicable.
Insert: The incremental refresh report is evaluated. If new data is returned, it is
added to the Intelligent Cube. Data that is already in the Intelligent Cube is not
altered.
Delete: The incremental refresh report is evaluated. The data that is returned is
deleted from the cube. For example, if the Intelligent Cube contains data for
2008, 2009 and 2010, and the filter or report returns data for 2009, all the data
for 2009 is deleted from the cube.

If you are using the Delete option, you can use a subset of attributes from
the Intelligent Cube on the reports template.

Update only: The incremental refresh report is evaluated. If the data returned
is already in the Intelligent Cube, it is updated where applicable. No new data is
added to the Intelligent Cube.

You can change these options at any time by opening the incremental refresh
in the Report Editor, and from the Data menu, selecting Configure
incremental refresh options.

4 Navigate to the Advanced category.

49 2017, MicroStrategy Inc.

 In-memory Analytics Guide

5 Select Report, and click OK. The Report Editor opens, with a new incremental
refresh report. By default, the reports template contains all the attributes and
metrics from the Intelligent Cube.
6 Edit the report, if necessary.
7 To preview the data that will be updated in the Intelligent Cube, from the View
menu, select Preview Data. The data is displayed in a grid view.

If your security filter prevents you from viewing some data, the preview only
displays data that you can view. However, when the incremental refresh is
executed, all the data is updated in the Intelligent Cube, regardless of security
filters.

8 To execute the incremental refresh immediately, click the Run Report button.
9 To save and close the incremental refresh, click Save and Close.

Improving the performance of large Intelligent

Cubes: Partitioning
If your Intelligent Cubes contain large quantities of data, you can improve their
performance by dividing the datasets into multiple segments, called partitions. The
partitions are processed simultaneously, distributed across the processor cores of your
Intelligence Server.

To partition an Intelligent Cube

1 In Developer, log in to your project and navigate to the Intelligent Cube.

2 Right-click the Intelligent Cube, and select Edit. The Intelligent Cube Editor opens.
3 From the Data menu, select Configure Intelligent Cube. The Intelligent Cube
Options dialog box opens.
4 Select the Data Partition category. The Data Partition options are displayed.
5 From the Partition Attribute drop-down, select the partition attribute for the
Intelligent Cube. For the criteria to determine an appropriate distribution key, see
Requirements for the partition attribute, page 72.
6 In the Number of Partitions field, type the number of partitions to create. The
number should be less than or equal to the number of processor cores on your
Intelligence Server machine.
7 If your data warehouse supports parallel SQL queries, enable the Fetch data slices
in parallel from the warehouse check box.
8 Click OK to save your changes.

2017, MicroStrategy Inc. 50

 3
REPORTING ON INTELLIGENT
CUBES
Intelligent Cube Technology allows reports to use OLAP Services features to report and
analyze data using an in-memory copy of data rather than querying the data warehouse.
This chapter discusses the various ways you can report on Intelligent Cubes:
Reporting and analyzing data with OLAP Services features, page 51
Reporting and analyzing data with Intelligent Cubes, page 52
Reporting on Intelligent Cubes with dynamic sourcing, page 67

Reporting and analyzing data with OLAP

Services features
While creating and viewing reports in MicroStrategy, you can use various OLAP Services
features to report and analyze data using an in-memory copy of data, rather than
querying the data warehouse.
This provides both OLAP Services features and full ROLAP analysis on your report with
no overhead to create or maintain an Intelligent Cube, or to link your report to an
Intelligent Cube.
Along with all of the standard reporting features available in MicroStrategy, the OLAP
Services features listed below can be used on reports:
Chapter 9, Dynamic Aggregation
Chapter 6, Derived Metrics
Chapter 7, View Filters
The chapters listed above describe how to use various OLAP Services features with
reports. For information on how to create reports and use all the standard reporting
features available in MicroStrategy, see the Basic Reporting Guide and the Advanced
Reporting Guide.

2017, MicroStrategy Inc. 51

In-memory Analytics Guide

Reporting and analyzing data with Intelligent

Cubes
You can perform all of your reporting and data analysis within an Intelligent Cube,
without executing any queries against the data warehouse. Once an Intelligent Cube is
created and then published so its data is available, multiple reports can be created to
connect to the Intelligent Cube (see Sharing Intelligent Cubes, page 22).
Reporting on an Intelligent Cube provides quick access to data, as the data has been pre-
aggregated. This returns results much faster than querying the data warehouse.
Reporting on Intelligent Cubes also allows you to use all of the OLAP Services features,
including derived elements, which allow you to group attribute elements in a report on
the fly, to provide a new view of report data for analysis and formatting (see Chapter 5,
Derived Elements).
Reports that connect to an Intelligent Cube are restricted to only the data available
within the Intelligent Cube. This ensures that report results are returned quickly, and it
also prevents full ROLAP analysis. Report filters, consolidations, and custom groups are
not available for reports that connect to Intelligent Cubes.

While reporting on Intelligent Cubes, there are a few scenarios that can produce
unexpected results. To troubleshoot these issues, see Troubleshooting reports
connected to Intelligent Cubes, page 65.

This section discusses the features available for reports that connect to Intelligent Cubes,
and how the reports utilize standard reporting features and OLAP Services features to
execute reporting and analysis manipulations completely within the Intelligent Cube.
This section includes information on the small differences in workflows and standards
when using standard reporting features in these reports:
Creating reports that connect to Intelligent Cubes, page 52
Creating Report Services documents that connect to Intelligent Cubes, page 55
Creating Visual Insight dashboards that connect to Intelligent Cubes, page 55
Analyzing data using standard OLAP Services features, page 61
Run-time reporting with prompts, page 61
Relational analysis with drilling, page 62
Troubleshooting reports connected to Intelligent Cubes, page 65

Creating reports that connect to Intelligent Cubes

To create a report that connects to an Intelligent Cube, you must choose an Intelligent
Cube to connect to when creating the report. The procedures below describe how to
create a report that connects to an Intelligent Cube:
Creating reports that connect to Intelligent Cubes, in Developer, page 53
Creating reports that connect to Intelligent Cubes, in Web, page 53

52 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Creating reports that connect to Intelligent Cubes, in Developer

Prerequisites
An Intelligent Cube has been created and published.
You need the Define Intelligent Cube Report privilege. This privilege is part of OLAP
Services.

To create a report that connects to an Intelligent Cube, in

MicroStrategy Developer

1 In Developer, log into a project.

2 From the File menu, point to New, and then select Report. The New Grid dialog
box opens.
3 Select the Intelligent Cubes tab.
4 Browse to an Intelligent Cube, select it, and then click OK.
The Report Editor opens with all of the objects of the Intelligent Cube included in the
Report Objects pane on the left. You can begin to create your report.

In Developer, you can also create a report that connects to an Intelligent Cube by
right-clicking an Intelligent Cube and selecting Create Report.

Creating reports that connect to Intelligent Cubes, in Web

Prerequisites
An Intelligent Cube has been created and published.
You need the Web Define Intelligent Cube Report privilege. This privilege is part of
OLAP Services.

To create a report that connects to an Intelligent Cube, in

MicroStrategy Web

1 In MicroStrategy Web, log in to a project.

2 Click the MicroStrategy icon, and select Create Report. A page with report
creation options is displayed.
3 Click Intelligent Cube Report. The Select Intelligent Cube dialog box opens.
4 Browse to an Intelligent Cube, select it, and then click OK.
The report opens with all of the objects of the Intelligent Cube included in the Report
Objects pane on the left. You can begin to create your report.

2017, MicroStrategy Inc. 53

In-memory Analytics Guide

Connecting to a different Intelligent Cube

You can modify the Intelligent Cube a report connects to for its data requirements. This
allows you to switch to an Intelligent Cube that fits your reporting requirements without
having to create a new report.
However, the Intelligent Cube you switch to for the report should have the same or at
least similar data as was previously available in the report. If the report contained some
objects that are not in the Intelligent Cube you switch to, this can cause the objects to be
unavailable for the report or have other unintended functionality. A warning message is
displayed for any mismatch in data between the report and the Intelligent Cube you want
to link the report to.

Changing the Intelligent Cube that a report points to is possible in Developer only.

Prerequisites
A report has been created that connects to a published Intelligent Cube.
A second Intelligent Cube has been created and published that has the same or
similar data as the report you want to link to it.
You need the Define Intelligent Cube Report privilege. This privilege is part of OLAP
Services.

To connect to a different Intelligent Cube

1 In Developer, browse to a report that is connected to an Intelligent Cube, right-click

the report, and select Edit. The report opens in the Report Editor.
2 From the Data menu, point to Intelligent Cube Options, and then select Point
grid to Intelligent Cube. The Select a cube dialog box opens.
3 Browse to the new Intelligent Cube you want to link the report to, select it, and then
click Open.
4 If there are data mismatches between the report and the Intelligent Cube you are
attempting to link it to, a warning message is displayed that lists the differences.
Attributes on the report that are not contained in the new Intelligent Cube will have
to be removed from the report to display valid report results. Missing metrics are
converted into derived metrics and may be able to display correct data, but they
should be removed if no data is returned.
If the differences are acceptable, click OK.
5 The report is updated to connect to the Intelligent Cube selected. You should remove
any attributes and metrics if they no longer return correct results.

54 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Creating Report Services documents that connect to

Intelligent Cubes
You can use one or more Intelligent Cubes as datasets in Report Services documents. The
steps to add Intelligent Cubes to Report Services documents are described below.
For detailed information on creating and using Report Services documents, refer to the
Document Creation Guide.
Prerequisites
An Intelligent Cube has been created and published.
You need the Define Intelligent Cube Report privilege. This privilege is part of OLAP
Services.
If you want to use multiple Intelligent Cubes as datasets for your document, you must
have the Execute Report that Uses Multiple Data Sources privilege.
If you want to use multiple Intelligent Cubes as datasets for your document, you must
have the Import Table from Multiple Data Sources privilege.

To create a Report Services document that connects to Intelligent

Cubes

1 In Web, click New Document. The Create Document page opens, showing
document templates that you can use.
2 Click a template for the document. A new document opens, in Design mode.
3 In the Dataset Objects pane, click Add Dataset. The Select Dataset dialog box
opens.
4 In the Select Dataset dialog box, navigate to the Intelligent Cube that you want to use
as a dataset.
5 Select the Intelligent Cube, and click OK. The Intelligent Cube is added to the
Dataset Objects pane.
6 To add another Intelligent Cube to the document, repeat the steps above.
For detailed information on using documents with multiple datasets, refer to the
Document Creation Guide.

Creating Visual Insight dashboards that connect to

Intelligent Cubes
A Visual Insight (VI) dashboard is a customized, interactive display that you can use to
explore your business data. For example, you can sort and rearrange data in an
interactive grid, perform manipulations on the data to display only the information you
are interested in, and display visual representations of the data in the VI dashboard to
make the data easier to interpret.

2017, MicroStrategy Inc. 55

In-memory Analytics Guide

The steps to create VI dashboards that connect to Intelligent Cubes are described below.
Prerequisites
An Intelligent Cube has been created and published.
You need the Define Intelligent Cube Report privilege. This privilege is part of OLAP
Services.
If you want to use multiple Intelligent Cubes as datasets for your dashboard, you
must have the Execute Report that Uses Multiple Data Sources privilege.
If you want to use multiple Intelligent Cubes as datasets for your dashboard, you
must have the Import Table from Multiple Data Sources privilege.

To create a Visual Insight dashboard that connects to Intelligent

Cubes

1 In Web, click New Dashboard. The Select Dataset dialog box opens.
2 In the Select Dataset dialog box, navigate to the Intelligent Cube that you want to use
for the dashboard.
3 Select the Intelligent Cube, and click Next. A new VI dashboard opens, with the
Intelligent Cube added to the Dataset Objects pane.
4 To add another Intelligent Cube to the dashboards datasets, in the toolbar, click
Add Dataset.
For steps to create visualizations and analyze data in VI dashboards, see the
MicroStrategy Web Help.

Merging Intelligent Cubes

MicroStrategy Web allows you to merge two or more Intelligent Cubes. This enables the
development of datasets via data importing, instead of creating and modifying each new
dataset from scratch. This option allows users to collaborate and develop an application
schema over time by merging smaller, independent datasets into one Intelligent Cube.
The attribute IDs for attributes in the cubes will remain intact so that any dashboards or
reports that were previously linked to the cubes will still execute correctly. The following
diagram shows how two cubes are merged.

56 2017, MicroStrategy Inc.

 In-memory Analytics Guide

For descriptions of scenarios involving duplicate data between cubes, see Handling
duplicate data when merging Intelligent Cubes, page 58.

Prerequisites
l User must have full control access rights to the cubes being merged.
l None of the cubes being merged are exclusive.
l Cubes must support the same access type. (For example, In-Memory only cubes cannot
merge with Direct Data Access only cubes.)

Merging cubes in MicroStrategy Web

For simplicity, the following steps refer to Cube A and Cube B, where Cube B will
be merged into Cube A.

1. From the MicroStrategy Web Home page navigate to the Intelligent Cube (Cube A)
you want to merge data into.

2017, MicroStrategy Inc. 57

In-memory Analytics Guide

Cube A must be selected here to maintain its attribute IDs after the merge. If
you select Cube B, any dashboards or reports linked to Cube A before the
merge may not function correctly.

2. Right-click on the cube and choose Edit.

3. In the Preview window select Add a new table.

4. From the Connect to Your Data window, choose MicroStrategy Datasets.

5. Navigate to the Intelligent Cube (Cube B) you want to add. Select the Cube and
click OK.
l To add another cube, repeat Steps 4 and 5.
l To save the updated Cube A, click Save Progress.
6. If you are finished adding to Cube A, click Update Dataset.
7. In the Data Access Mode window choose how you access the new cube by
selecting Connect Live or Import as an In-memory Dataset.
8. The Start your analysis window opens. You can choose from Create Dashboard,
Create Document, or Create Report.

Handling duplicate data when merging Intelligent Cubes

In some cases two Intelligent Cubes being merged will contain tables, attributes, or
metrics that are complete or partial duplicates. MicroStrategy will detect and resolve
these anomalies during the merge to preserve the original attribute IDs in the newly
merged cube. A warning message like the one pictured below will notify you of the
duplicate data and how it will be resolved.

58 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Schema comparisons for duplicate tables

l If the schema for the duplicate tables from Cube A and Cube B is the same, the table
from Cube A will be picked and the duplicate from Cube B will be skipped. The
attribute IDs from Cube A will be retained.
l If the schema is different on both of the duplicate tables, Cube A will map as many
attributes from the duplicate table as possible. These attributes will retain the IDs from
Cube A and the remaining attributes will retain their IDs from Cube B.
l Columns are paired using column names
l Derived columns are skipped.
l Matched pairs of columns are compared using their mapping information, including
object type, object name, data type, geo roles, etc.
l The schema will be treated as different if missing or redundant columns are found.

Source comparisons for duplicate tables

l If the data source table structure and schema for two identical tables is the same, they
will be considered duplicates, and the table from Cube B will be skipped.
l If the data source for two identical tables is different, both tables will be merged. The
name of the table from Cube B will be changed to "table name - Cube B".

2017, MicroStrategy Inc. 59

In-memory Analytics Guide

Attribute and metric comparisons

l Attributes can be manually linked between two cubes before the merge.
l For attributes and metrics, if the name is the same and the data type are compatible,
they will be linked automatically.
l If attributes or metrics have the same name, but are not data type compatible, the
attribute or metric being merged will be renamed "attribute/metric name - Cube B".

Multiform attributes follow the same rules as above. When multiform and single
form attributes are compared, the data types for the ID of the multiform
attribute and the name of the single form attribute are checked for
compatibility.

l GeoRole related attributes

n If Cube A and Cube B have duplicate attributes, where one is missing the
GeoRole, they will be linked and the GeoRole added to the attribute without
one.
n If Cube A and Cube B have duplicate attributes with different GeoRole values,
the attribute from Cube B will be renamed.

Partitioned Tables
l If Cube A and Cube B both have two partition tables, they will merge successfully. To
group the tables into a single table, select Yes in the reminder window. You can also
group them together manually on the table menu.

60 2017, MicroStrategy Inc.

 In-memory Analytics Guide

l If all the sub tables are the same, the newly added duplicate database table will be
removed.
l If the tables in Cube B are not a subset of the group tables in Cube A, but they can be
grouped, you will see the pop up window for the partition option. Click Yes to remove
duplicate tables. Click No to keep the tables separate. The tables can be grouped
manually on the table menu.

Analyzing data using standard OLAP Services features

Reports that connect to Intelligent Cubes make use of OLAP Services features to provide
a broad range of analysis capabilities. All OLAP Services analysis is executed against the
Intelligent Cube. The following reporting features are described in this section:
Run-time reporting with prompts, page 61
Relational analysis with drilling, page 62
Troubleshooting reports connected to Intelligent Cubes, page 65
For additional information on the different OLAP Services features available for reports
that connect to Intelligent Cubes, see the following chapters in this guide:
Chapter 5, Derived Elements
Chapter 9, Dynamic Aggregation
Chapter 6, Derived Metrics
Chapter 7, View Filters

Run-time reporting with prompts

In addition to including base attributes, metrics, and other objects to be displayed on
your reports, you can also determine how much of the report to display at run time.

2017, MicroStrategy Inc. 61

In-memory Analytics Guide

Prompts allow users to choose which objects and filtering criteria to apply to a report
during report execution.
Prompts serve the same purpose in any report, including reports that connect to
Intelligent Cubes. However, instead of modifying SQL at report run time, prompts allow
reports to select data within the Intelligent Cube, as illustrated below.

The image above shows standard run-time reporting with prompts, while using OLAP
Services to execute against the Intelligent Cube rather than against the data warehouse.
The performance of your business intelligence application is improved by reducing
execution against your data warehouse and maintaining only a single Intelligent Cube for
multiple prompted reports.
Prompts on reports that connect to Intelligent Cubes can only access data that is
available within the Intelligent Cube. These restrictions are applied automatically when
creating prompts. For example, the attributes Year and Region and the metrics Cost and
Revenue are included in the Intelligent Cube shown in the image above. If you create an
object prompt in your report that connects to this Intelligent Cube, then you can only
create prompts based on one of Year, Region, Cost, and Revenue.

You cannot use prompts that include objects or data that are not part of the
Intelligent Cube, or prompts that use hierarchies. If you try to use such prompts,
an error message is displayed.

Prompts in reports that access Intelligent Cubes can use the complete ROLAP schema of
a project. However, if a prompt retrieves data from outside the Intelligent Cube, re-
execution against the data warehouse is necessary.

Relational analysis with drilling

As with any MicroStrategy report, you can drill on reports that connect to Intelligent
Cubes to analyze data at different logical levels.
A report connected to an Intelligent Cube can drill within the data available in the
Intelligent Cube it is connected to. This means that you can drill from an attribute on the

62 2017, MicroStrategy Inc.

 In-memory Analytics Guide

report grid to an attribute that is not on the report grid, but available in the Report
Objects pane. If the attribute is not available in the Report Objects pane, it is not an
available drilling option by default. However, Intelligent Cubes can be defined to allow
drilling outside of an Intelligent Cube to the full relational data warehouse.
For example, your report includes the attribute Year. After analyzing data at the Year
level, you want to analyze data for each quarter. You can drill down from Year to the
attribute Quarter to view and analyze data at the new logical level. This drilling action is
performed within an Intelligent Cube. Following this example scenario, you want to drill
from year 2007 to quarters for that year. You have a report connected to an Intelligent
Cube that is defined as shown below:

Notice that Quarter is not on the report, but it is included in the Report Objects pane on
the left as it is a part of the Intelligent Cube that the report is connected to. As shown in
the report above, you right-click the 2007 attribute element for Year and drill down to
Quarter. The drilled-to report is shown below.

2017, MicroStrategy Inc. 63

In-memory Analytics Guide

This drilled-to report is executed within and connected to the same Intelligent Cube as
the original report. This is verifiable by looking at the Report Objects pane, which shows
that the report objects are being returned from the same Intelligent Cube (named
Drilling I Cube) as the original report. This provides relational analysis without having to
execute the report against the data warehouse.
In the scenario above, drilling is performed within the Intelligent Cube, which is
achievable through any report connected to an Intelligent Cube. However, if the
Intelligent Cube is defined to allow drilling outside it (see Enabling ROLAP drilling for
reports accessing Intelligent Cubes, page 34), you can also drill to any object not
included in the Intelligent Cube. While drilling outside of an Intelligent Cube requires
execution against the data warehouse, it provides access to the full ROLAP schema of the
project outside of the Intelligent Cube.
In the next example, the same scenario of drilling from Year to Quarter is used, except
that the Intelligent Cube does not contain the Quarter attribute. As shown in the report
below, you right-click the 2007 attribute element for Year and drill down to Quarter.

Notice in the report shown above that all the attributes in the Time hierarchy are
available drilling options even though they are not all included in the Intelligent Cube.
These attributes are available drilling options because the Intelligent Cube is defined to
enable drilling outside of the Intelligent Cube. As shown in the report above, you right-
click the 2007 attribute element for Year and drill down to Quarter. The drilled-to report
is shown below.

64 2017, MicroStrategy Inc.

 In-memory Analytics Guide

This drilled-to report is executed against the data warehouse, and it allows you to access
data outside of the Intelligent Cube for further relational analysis. Notice also that all
report objects that were not on the report grid are now removed from the Report Objects
pane, because this new, drilled-to report is not connected to the Intelligent Cube.
You should consider the execution time requirements for a report before drilling outside
of an Intelligent Cube.
For basics on how to drill on data, see the Basic Reporting Guide. For information on
creating drill maps, which are used to enable drilling techniques, see the Drill Maps
chapter in the Advanced Reporting Guide.

Troubleshooting reports connected to Intelligent Cubes

While reporting on Intelligent Cubes, a few scenarios can produce unexpected results. To
troubleshoot these issues, review the following sections:
No data is returned for the report, page 65
No data is returned for a metric or metrics on the report, page 66
The report fails due to the unavailability of Intelligent Cubes, page 67

No data is returned for the report

If no data is returned for a report that is connected to an Intelligent Cube, this can be
caused by the following scenarios:
The view filter for the report is too restrictive (see Chapter 7, View Filters). Modify
or remove the view filter to attempt to return data for the report. If removing the
view filter does not allow the report to return data, the cause may be due to your
security filter, as described below.

2017, MicroStrategy Inc. 65

In-memory Analytics Guide

Your security filter does not allow you to see the data available on the Intelligent
Cube. For information on how to resolve data availability due to security filter
resolution, see Resolving security filter resolution, page 66 below.

Resolving security filter resolution

If security filters are used to maintain data access security, this can cause data to not be
displayed for a report connected to an Intelligent Cube.
While this may be due to normal data access security, the data available on the Intelligent
Cube may prevent you from viewing all possible data in a data source (see Security filter
resolution for reports connected to Intelligent Cubes, page 24.) To verify whether there
is additional data that is not being returned, you can create or view a report that
connects directly to a data source rather than an Intelligent Cube. You can also contact
the designers of the Intelligent Cube to review whether additional data can be added to
the Intelligent Cube so that it supports your report.

No data is returned for a metric or metrics on the report

If no data is returned for a metric or metrics on a report connected to an Intelligent
Cube, this can be caused by either dynamic sourcing or your security filter.
When this is caused by your security filter resolution, no data is displayed for the metric
or metrics. However, when this is caused by dynamic aggregation, null values are
displayed for the metric rather than no information at all. The image below shows the
difference between security filter resolution and dynamic aggregation as the cause for
metrics not displaying any data.

By default, null values are represented by dashes (--) on reports. For information
on changing the display of null values, see Changing the display of null values,
page 255.

If dynamic aggregation is the cause for null values being displayed, resolutions for this
issue are described in Metrics that are not dynamically aggregated by default, page
248.

66 2017, MicroStrategy Inc.

 In-memory Analytics Guide

If your security filter is the cause for metric data not being displayed, see Resolving
security filter resolution, page 66.

The report fails due to the unavailability of Intelligent Cubes

An unavailable Intelligent Cube can cause your reports connected to this Intelligent Cube
to fail. This is because the report depends on the Intelligent Cube to provide the data for
the report.
The scenarios listed below cause reports to return error messages when Intelligent Cubes
are unavailable:
The Intelligent Cube is not published. This scenario can occur when an Intelligent
Cube is removed to:
Update it with new data available in the data warehouse.
Release its resources for more frequently used Intelligent Cubes.
Provide space for a new Intelligent Cube because Intelligent Cube storage limits
have been exceeded.
Contact your administrator to determine why an Intelligent Cube is no longer
published and whether there are plans to publish it again.
The Intelligent Cube is currently offline. In this scenario, the Intelligent Cube is
published but has been made unavailable for reporting. Contact the administrator of
Intelligent Cubes to determine why the Intelligent Cube has been made unavailable,
as well as if and when the Intelligent Cube will be made available again.
The Intelligent Cube is being published, but the publishing process is not complete.
This scenario can occur when an Intelligent Cube is first being published. If you wait
for the Intelligent Cube to publish, you should then be able to run your report
without experiencing this error.

Reporting on Intelligent Cubes with dynamic

sourcing
You can manually connect a report to an Intelligent Cube to perform all reporting and
analysis within the shared in-memory copy of data, as described in Reporting and
analyzing data with Intelligent Cubes, page 52. Even if you dont manually connect your
reports to an Intelligent Cube, the reports you create can also access Intelligent Cube
data rather than querying the data warehouse automatically. Enabling this automatic link
between reports and Intelligent Cubes is referred to as dynamic sourcing.
Dynamic sourcing extends the accessibility of Intelligent Cubes by allowing regular
reports to access published Intelligent Cubes, as long as the Intelligent Cubes can satisfy
the requirements of the report. For a detailed explanation of dynamic sourcing and
procedures to perform the project-wide configurations necessary to enable and support
dynamic sourcing, see Chapter 9, Dynamic Aggregation.

2017, MicroStrategy Inc. 67

In-memory Analytics Guide

While reporting on Intelligent Cubes, there are a few scenarios that can produce
unexpected results. To troubleshoot these issues, see Troubleshooting reports
connected to Intelligent Cubes, page 65

Supporting report execution through dynamic sourcing

When creating reports, you can enable and increase your chances that your report
utilizes dynamic sourcing by following the recommendations below.
First, you must enable dynamic sourcing for your report. This can add some overhead to
the execution of your report to check whether there are any Intelligent Cubes that meet
the data requirements of your report. This overhead usually has no effect on
performance. If an Intelligent Cube can be used, the report results can be returned
quickly from the in-memory copy of data rather than querying the data warehouse. To
enable dynamic sourcing for reports, see Enabling or disabling dynamic sourcing for
reports, page 208.
The simpler your report is, the more likely it is that an Intelligent Cube satisfies its data
requirements. This does not mean that you should create reports with minimal data
simply to take advantage of dynamic sourcing. However, the considerations listed below
can help you create a report that meets your reporting requirements and is well-suited
for dynamic sourcing:
Avoid the use of features that prevent the use of dynamic sourcing, which are
described in Features that prevent the use of dynamic sourcing, page 203.
Only add objects that are relevant to the analysis required for the report. When
creating a report, you should determine whether certain attributes, metrics,
advanced filtering techniques, and so on are required for the report or are extraneous
to the analysis requirements of a report.

68 2017, MicroStrategy Inc.

 4
IMPORTING LARGE DATASETS
INTO MICROSTRATEGY
This section describes the requirements and tasks to add large datasets to your
application, by importing the datasets as Intelligent Cubes and dividing them into
multiple segments, called partitions. The datasets can be on the order of multiple
terabytes.
The following topics are covered:
For an overview of using large datasets, including the benefits, see Overview: Large,
in-memory datasets in MicroStrategy, page 69.
For steps and considerations when creating an application that uses a partitioned
dataset, see Creating an application that uses a partitioned dataset, page 70.
For steps to modify and update your dataset after you import it, see Editing and
updating your dataset, page 74. For example, you can designate a data column as an
attribute or a metric. You can also add or remove data from your dataset, depending
on changes in your data source.

Overview: Large, in-memory datasets in

MicroStrategy
MicroStrategy allows you to load large datasets into your Intelligence Servers memory as
Intelligent Cubes, and divide the Intelligent Cubes into multiple segments. These
segments, called partitions, are processed simultaneously, distributed across the
processor cores of your Intelligence Server.
By storing your data in your Intelligence Servers memory and processing the data using
all the servers processor cores, you can analyze large and complex datasets with very fast
response times.
You divide your dataset based on an attribute, called a partition attribute. When you
choose a partition attribute, all the tables that contain that attribute are partitioned.

2017, MicroStrategy Inc. 69

In-memory Analytics Guide

Benefits of using partitioned datasets

The benefits of storing your data in your Intelligence Servers memory and processing
the data using all the servers processor cores partitioning your dataset include:
Improving the response time for your reports, documents, and dashboards.
Reducing the load on your data warehouse, because your dataset is stored in
Intelligence Servers memory instead of the data warehouse.
Analyzing large volumes of data in real time, since your datasets can contain up to 2
billion rows of data for every partition on the Intelligence Server.
Using the standard features of the MicroStrategy platform, such derived metrics,
custom groups, consolidations, and so on, on your dataset.

Creating an application that uses a partitioned

dataset
To create an application based on a partitioned dataset, you need to perform the
following high-level tasks:
Evaluate the needs of your application and whether your application is suitable for
partitioned datasets, as described in Evaluating your application, page 71.
Evaluate your dataset, and determine the number of partitions that you require, as
described in Preparing your MicroStrategy environment and dataset, page 72.
Ensure that you have the necessary hardware to support the partitions of your
dataset, as described in Requirements for your Intelligence Server machine, page 72
Design a logical data model of your dataset, similar to designing a project schema for
MicroStrategy. The logical model is a representation of your dataset as experienced
by your users. A logical data model depicts the flow and structure of your data,
providing a way of organizing data so that it can be analyzed from different
perspectives.
For steps and considerations for creating a logical data model, see the Project Design
Guide.
Select the attribute that will divide your dataset (the partition attribute). All the tables
that contain the partition attribute are split into partitions. The tables are analyzed in
parallel by the processor cores of your Intelligence Server machine. The guidelines
for choosing a partition attribute for your dataset are described in Requirements for
the partition attribute, page 72.
Create the dataset using Web, as described in Creating a partitioned dataset, page
73.
Use simple base metrics when you create the dataset, and then create derived metrics
for more complex metrics calculations after you import the dataset. For steps to
create derived metrics, see the MicroStrategy Web Help.

70 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Design your documents and dashboards using MicroStrategy Web. For steps to
design documents and dashboards, see the MicroStrategy Web Help.
Maintain and update your dataset, as described in Editing and updating your
dataset, page 74.

Evaluating your application

To evaluate your application, use the following sections as guidelines to determine
whether your application can benefit by implementing a partitioned dataset:
Features that make an application suitable for a partitioned dataset, page 71
Features that make an application unsuitable for partitioned datasets, page 71

Features that make an application suitable for a partitioned dataset

An application that meets at least one of the following criteria may be a suitable
candidate for a partitioned dataset:
Your documents and dashboards are centrally managed and allow your users to
analyze data from different perspectives.
All the data that you need for the application can be loaded in a single dataset.
All tables that have more than two billion rows of data can be split based on the
same attribute.
Your base Key Performance Indicators (KPIs) are calculated using basic aggregation
functions such as Sum, Average, Minimum, Maximum, Count, and so on. The KPIs
can be calculated individually for each partition and then combined.
Once you have created your dataset, you can create derived metrics that use any of
the standard MicroStrategy functions.
For a full list of the most efficient functions to use in partitioned datasets, see
Appendix A, Efficient Functions for Partitioned Datasets.
The dataset for your application needs to be incrementally updated on a schedule.
The dataset for your application is less than or equal to two terabytes (TB) in size.
Your data is structured, and an Extract, Transform, Load (ETL) process has been
performed on it.

Features that make an application unsuitable for partitioned datasets

An application that meets at least one of the following criteria may not be suitable for a
partitioned dataset:
Your dataset needs to support self-service analyses, where your users can create their
own reports, documents, or dashboards.
All of the data for the application cannot be loaded in a single dataset.

2017, MicroStrategy Inc. 71

In-memory Analytics Guide

Your application allows users to add or update data in your warehouse by using
Transaction Services.
All tables that have more than two billion rows of data cannot be partitioned based
on the same attribute.
The calculations for your KPIs require the entire dataset. For example, KPIs that use
functions such as First, Last, Standard Deviation, OLAP functions, and so on require
the entire dataset.
For a full list of the most efficient functions to use in partitioned datasets, see
Appendix A, Efficient Functions for Partitioned Datasets.
Your data is unstructured, and include data sources other than RDBMS or flat files.
Your dataset needs to be updated in real time.

Preparing your MicroStrategy environment and dataset

Before you create your partitioned dataset, you need to ensure that your Intelligence
Server machine meets the hardware requirements for loading a partitioned dataset into
its memory. Additionally, you must select an appropriate partition attribute that
maximizes the performance of your reports, documents, and dashboards.
Requirements for your Intelligence Server machine, page 72
Requirements for the metrics on your partitioned dataset, page 72
Requirements for the partition attribute, page 72

Requirements for your Intelligence Server machine

To determine whether your Intelligence Server can support your in-memory dataset,
note the following:
The number of partitions you divide your dataset into must be less than or equal to
the number of processor cores on your Intelligence Server machine.
The maximum size of a partition is 2 billion rows.
Ensure that your Intelligence Server machine has enough memory to handle the
data.

Requirements for the metrics on your partitioned dataset

Ensure that the metrics that you need to use can be calculated independently for each
partition, then combined.

Requirements for the partition attribute

The partition attribute is the attribute that will be used to divide your dataset. The
partition attribute must meet the following requirements:

72 2017, MicroStrategy Inc.

 In-memory Analytics Guide

The data type of the partition attribute must be one of the following:
Integer
BigDecimal
Text
Date
The partition attribute should be present on as many fact tables as possible, especially
your largest fact tables. This requirement ensures that the calculations that you need
to perform take full advantage of MicroStrategys parallel processing capabilities.
The partition attribute is not used to filter your dataset. This ensures that when users
analyze data in your application, the maximum number of partitions are involved in
the calculations, which leads to faster response times.
The partition attribute is on any tables that are larger than two billion rows.

Creating a partitioned dataset

To create a partitioned dataset, import tables from your data warehouse using Web, as
described in the steps below.

To create a partitioned dataset

1 In Web, log in to the project to import your dataset into.

2 On the home page, click Add External Data. The Connect to your Data dialog box
opens.
3 Click Database. The Select Import Options dialog box opens.
4 Select Pick Tables, and click Next. The Import from Tables dialog box opens.
5 From the Database Connections panel on the left, select the database connection
that contains the data to import. A list of the database tables in the selected database
is displayed in the Available Tables panel.
6 If your database supports multiple namespaces, you can display only the database
tables for a specific namespace. To do this, select the namespace from the drop-
down list. To search for a namespace, type the namespace in the field. The choices in
the drop-down list are filtered as you type.
7 To expand the name of a table and view a list of columns in the table, click the
Expand icon next to the table name. Each column in the table is displayed, along
with its data type. You can filter the list of database tables by typing the name of a
table in the search field.
8 To partition your data, click Prepare Data. The Preview dialog box opens,
displaying the attributes and metrics for your dataset, and the data tables that they
are based on.

2017, MicroStrategy Inc. 73

In-memory Analytics Guide

9 If you want to create search indexes to improve the performance of search-based

selectors, you must define relationships between attributes to specify how the
attributes are connected. For example, in a relationship between Year and Quarter,
Year is the parent attribute and Quarter is the child.
Hover the cursor over the name of a table, click the Menu icon, and select Define
Relationships. Click Add a New Relation, select the Parent Attribute, Child
Attribute, and Relationship. For detailed steps to define relationships between
attributes, see the MicroStrategy Web Help.
10 Click All Objects View. The All Objects View dialog box opens, showing all the
attributes and metrics in your dataset.
11 From the Partition Attribute drop-down list, select the attribute to use to divide
your dataset. For help in evaluating your dataset for an appropriate attribute, see
Requirements for the partition attribute, page 72.
12 In the Number of Partitions field, type the number of partitions to split the
dataset into. The number of partitions should be less than or equal to the number of
CPU cores on your Intelligence Server machine.
13 To improve the performance of search-based selectors, in the Search Index
column, enable the check box for the appropriate attributes. You must have defined
attribute relationships, as described above.

Turning on search indexes takes up additional space in your Intelligence

Servers memory.

14 To save your changes, click OK.

Editing and updating your dataset

Once you have imported your dataset, you can make modifications to it. For example,
you can manually designate a data column as an attribute or a metric. You can also add
or remove data from your dataset, depending on changes in your data source.
For steps to edit your dataset, see the MicroStrategy Web Help. Some examples of
editing your dataset are listed below; for a complete list, see the MicroStrategy Web
Help.
Add more data from the same data source or a different one.
Remove a table from the dataset.
Change the data type of a column.
Assign a geo role to a data column, to generate additional geographical data and
to allow for easier integration with map-based visualizations.
Designate a data column as an attribute or a metric.
For steps to update the data in your dataset, such as when new data is available in
your data source, see Updating the data in your dataset, page 75.

74 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Updating the data in your dataset

You can specify the schedule for data updates for your dataset. This ensures that when
new or updated data is available from the data source, your dataset and application are
updated.

To update your dataset using a schedule

1 In Web, navigate to the Intelligent Cube for your dataset.

2 Right-click the dataset, and choose Schedule. The Schedule dialog box opens for
your dataset, showing the tables in your dataset.
3 In the Data Source column, select the check boxes for the tables to update.
4 In the Refresh Policy column, choose one of the following options:
To replace all the data in your dataset with updated data from your data source,
select Replace existing data. Select this option if your dataset contains a
rolling set of datafor example, if your dataset always contains data for the last
six months.
To update the existing data in your dataset with any updated data in your data
source, select Update existing data. Select this option if the data in your data
source is updated regularly, but your dataset requires a specific subset of the data.
To update the existing data and add any new data, select Update existing data
and add new data. Select this option if your dataset is updated often, for
example, a sales dataset that records new transactions and tracks updates to
older transactions as applicable.
To add new data from your data source to your dataset, select Add new data.
Data that is already in the dataset is not altered. Select this option if old data is
not updated after it is saved to your data source.

To define a refresh filter for your dataset

For complex updates, or to only update your dataset with a subset of the data in your
data source, you can create a refresh filter. For example, you can update the tables in
your dataset at different intervals, depending on when the data in your data source is
updated. If you do not need to define a refresh filter, skip to To specify a different
source for data, page 76.
5 Click Show Advanced Update Options. The Set Refresh Filter and Alternate
Source columns are displayed.
6 Click Set Refresh Filter. The Select a filter dialog box opens.
7 Click Add Condition. A new attribute qualification is started, displaying a list of the
attributes in your dataset.
8 In the Based On list, select the attribute to filter by.
9 Define the qualification by doing one of the following:

2017, MicroStrategy Inc. 75

In-memory Analytics Guide

To create a qualification based on attribute elements in a list (an attribute

element is an individual characteristic of an attribute, such as USA or France for
the Country attribute):
a Under Select, do one of the following:
To include data only for elements that you select, click In. For example,
you can include data for the Books and Movies categories only.
To include data for all elements except those that you select, click Not
in. For example, you can include data for all product categories except
Books and Movies.
b Type the names of the attribute elements to select.
To create a qualification based on attribute form values:
a Under Qualification, select the attribute form to base the qualification on.
For example, you can filter based on the attribute elements ID form, one of
its description forms, or the DATE form if the attribute is time-based.
b From the list of operators to the right, select a comparison operator, such as
Greater Than or Less Than. Do one of the following:
To compare the attribute form to a specific value, type the value in the
field.
To compare the attribute form to another attribute form, select the
attribute that contains the second form. Select the second attribute form
from the list.
10 Click the Apply icon to create the qualification. The qualification is created and
displayed in the Select a filter dialog box.
11 Click Save to return to the Schedule dialog box.

To specify a different source for data

If the updated data for your tables is in a different data source than the original, you
can configure a different data source for each table. Ensure that the table in the new
data source contains columns with identical names to the columns in your original
data source. If you do not need to specify a difference source, click Finish to close
the Schedule dialog box.
12 If the Set Refresh Filter and Alternate Source columns are not displayed on the
Schedule dialog box, click Show Advanced Update Options.
13 In the Alternate Source column for the table to update, click Set Source. The
Select Alternate Source dialog box opens.
14 From the Database Sources panel on the left, select the database connection that
contains the data to import. A list of the database tables in the selected database is
displayed in the Available Tables panel.
15 Type the name of the table in the search field. The list of tables is updated
automatically as you type.

76 2017, MicroStrategy Inc.

 In-memory Analytics Guide

16 Click and drag the name of the table from the Available Tables panel to the panel on
the right.
17 Click Finish.

2017, MicroStrategy Inc. 77

 5
DERIVED ELEMENTS
Defining Attribute Elements On The Fly
A derived element is a grouping of attribute elements on a report. Derived element
groups are defined by a list, filter, or calculation. These groups provide a new view of
report data for analysis and formatting purposes.
For example, the reports below contain Region, Category, and Profit. The report on the
left does not display any derived elements. The report on the right displays derived
elements defined using groups of Region attribute elements:
East Coast: This derived element combines the data for the Mid-Atlantic, Northeast,
and Southeast regions.
West Coast: This derived element combines the data for the Northwest and
Southwest regions.
Central and South: This derived element combines the data for the Central and
South regions.
Web: This derived element displays the data for the Web attribute element, which is
not included in any of the derived elements listed above.

2017, MicroStrategy Inc. 78

In-memory Analytics Guide

You can do more than just simple combinations of attribute elements with derived
elements. For example, after you have defined the East Coast derived element, you can
determine the East Coast regions percent contribution to profit, as shown in the last row
of the report below.

79 2017, MicroStrategy Inc.

 In-memory Analytics Guide

This demonstrates only a fraction of the analysis and formatting capabilities of derived
elements. With derived elements you can also create custom sort orders for attribute
elements, use aggregation functions such as Average to combine attribute elements, and
perform other analysis and formatting tasks.

Derived elements are evaluated on the report dataset without regenerating or re-
executing SQL.

The following sections of this chapter cover derived element concepts, functionality, and
procedures:
Types of derived elements, page 80
Creating derived elements, page 88
Defining derived element functionality and formatting, page 121
Interaction with other reporting features, page 131

Types of derived elements

The different types of derived elements provide a wide range of reporting and analysis
features. The following sections describe each type of derived element and how they can
be used for reporting and analysis requirements:
Group derived element, page 81
Filter derived element, page 82

2017, MicroStrategy Inc. 80

In-memory Analytics Guide

Calculation derived element, page 85

All Other derived element, page 87

Group derived element

A Group derived element is a combination of attribute elements into a single derived
element. All attribute element data is added together to form the metric values for the
new Group derived element.
For example, you have a report with Region, Category, and Profit displayed on a report.
The report shown below includes the following derived elements defined using groups of
Region attribute elements:
East Coast: Groups the Mid-Atlantic, Northeast, and Southeast attribute elements.
West Coast: Groups the Northwest and Southwest attribute elements.
Central and South: Groups the Central and South attribute elements.

A procedure to create the report shown above is provided in Grouping attribute

elements to create a derived element, page 106.

Group derived elements are created by selecting attribute elements to include in each
derived element. The image below shows how the East Coast Group derived element is
created in the Derived Elements Editor:

81 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Group derived elements can only combine attribute elements, they cannot
combine other derived elements. If you want to create a derived element that is a
combination of other derived elements, you must use a Calculation derived
element (see Calculation derived element, page 85).

You can quickly create Group derived elements using right-click options (see Creating
quick groups, page 90), or you can use the Derived Elements Editor to access the full
functionality of derived elements (see Using the Derived Elements Editor, page 101).
You can also use this type of derived element to display the attribute elements in a
different order. This enables you to do more advanced attribute element sorting than
simple ascending or descending sorts. For information on using Group derived elements
to sort the display of attribute elements on a report, see Creating quick sorts, page 99.

Filter derived element

A Filter derived element uses a filter qualification to determine the combination of
attribute elements for a derived element.
For example, in a report with Region and Category attributes and a Profit metric, you can
filter the regions on the report into various geographical groups based on the region
names.
The report shown below includes the following derived elements defined using filters for
Region attribute elements:
Southern Regions: Returns attribute elements whose name begins with South.
Northern Regions: Returns attribute elements whose name begins with North.

2017, MicroStrategy Inc. 82

In-memory Analytics Guide

A procedure to create the report shown above is provided in Filtering attribute

elements to create a derived element, page 109.

Filter derived elements are created by filtering attribute elements to include in each
derived element. There are two methods to create Filter derived elements:
Create a Filter derived element using a filter qualification on a list of attribute
elements. This includes using the In list and Not in List operators.
In list: A filter qualification using In list returns data for all the attribute
elements you select. An In list filter qualification that returns all the southern
regions is shown below.

Not in List: A filter qualification using Not in List returns data for all the
attribute elements you do not select, for a given attribute. A Not in List filter
qualification that returns all the southern regions is shown below.

83 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Create a Filter derived element using a filter qualification on attribute forms. This
enables you to use various logical and mathematical operators to create filter
qualifications on attribute forms to return data. An attribute form qualification using
a Begins with operator that returns all southern regions is shown below.

You can use any of the following operators in attribute form qualifications, which are
described in detail in Appendix A, Logical and Mathematical Operators for Filtering
in the MicroStrategy Advanced Reporting Guide:

Operator Type Operator

Comparison Operators Exactly

Comparison operators compare values. The values can be Different
numbers, text strings, or expressions. from
Greater than
Less than
Greater than
or equal to
Less than or
equal to
Between

2017, MicroStrategy Inc. 84

In-memory Analytics Guide

Operator Type Operator

Pattern Operators Like

Pattern operators allow text strings to be compared. Not Like
Pattern operators are case-sensitive.
Contains
Does not
contain
Begins with
Does not
begin with
Ends with
Does not end
with

To create Filter derived elements, you must use the Derived Elements Editor (see Using
the Derived Elements Editor, page 101).

Calculation derived element

A Calculation derived element uses operators and functions to combine attribute
elements and derived elements into calculations that define a single derived element.
For example, in a report with Region and Category attributes and a Profit metric, you can
combine the regions on the report into various groups for profit analysis, as shown
below.

85 2017, MicroStrategy Inc.

 In-memory Analytics Guide

A procedure to create the report shown above is provided in Using calculations to

create derived elements, page 112.

Calculation derived elements are created by defining expressions with valid combinations
of operators, functions, attribute elements, and derived elements. An example of a valid
expression is shown below.

You can include the following when you create a Calculation derived element expression:
Attribute elements: You can include attribute elements in your expression by
selecting the attribute from the drop-down list, selecting attribute elements, and
dragging and dropping them into the expression area.
Derived elements: You can include other derived elements in your expression by
selecting derived elements from the Groups drop-down list, and dragging and
dropping them into the expression area. The example below shows a Calculation
derived element created by performing a division of two other derived elements.

Operators: You can include ( ), +, -, *, and /, which are all available on the toolbar.
Functions: You can include Average, Greatest, and Least by clicking f(x) on the
toolbar and completing the Insert Function Wizard. For information on these

2017, MicroStrategy Inc. 86

In-memory Analytics Guide

functions, see Creating quick calculations, page 92. For steps to use the Insert
Function Wizard, click Help in the wizard.
Clear: You can clear the expression to start creating a new expression.
Validate: You can check your expression to see if its syntax is valid. Any errors in
syntax are highlighted in red.
To create Calculation derived elements, you can either quickly create derived elements
with right-click options (see Creating quick calculations, page 92), or you can use the
Derived Elements Editor to access the full functionality of derived elements (see Using
the Derived Elements Editor, page 101).

All Other derived element

The All Other derived element collects all attribute elements that are not included in
other derived elements, and displays them on the report as individual attribute elements
by default. This derived element is created automatically when the first derived element
is created for an attribute. An All Other derived element can only be deleted by deleting
all derived elements.
Because it is created automatically, the All Other derived element is created and
implemented without having to take note of it at all. For example, recall the report
created with a Filter derived element (see Filter derived element, page 82) that included
Southern Regions and Northern Regions derived elements as shown below.

Central, Mid-Atlantic, and Web are all attribute elements that are not included in any
derived elements. The All Other derived element gathers these remaining attribute
elements, and displays them on a report as individual attribute elements.

87 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You can also include all of the attribute elements that are part of the All Other derived
element as one consolidated element on a report (see Displaying derived elements or
their attribute elements, page 123).
While this is the most common way the All Other derived element is used, you can
define attribute elements included in other derived elements to also be included as part
of the All Other derived element. For information on including attribute elements in the
All Other derived element, see Displaying derived elements and their attribute elements
simultaneously, page 125.

Creating derived elements

Derived elements require static report results so that they can be evaluated without
regenerating or re-executing SQL. Derived elements can be created in the following types
of reports and documents:
Standard reports
Intelligent Cube reports: An Intelligent Cube report is a report that is connected to
and retrieves its data from an Intelligent Cube.
Grid/Graphs in Report Services documents: A Grid/Graph is a control placed in a
document that displays information in the same way a MicroStrategy report does. In
other words, a Grid/Graph is a report that has been added to a section of a Report
Services document.

If a report containing derived elements is included as a dataset of a Report

Services document, derived elements are displayed for any associated
attributes added to the details or grouping sections. However, you cannot
create or modify derived elements for attributes added to the grouping or
details sections.

You can create derived elements with the following methods, which are all described in
this section:

Depending on the type of report you are creating a derived element on, you can
use either MicroStrategy Developer or Web. To see which interfaces you can use,
refer to the tables under each of the following methods.

Quickly creating groups, calculations, and sorts, page 89: While reviewing the data
on a report or document, you can quickly group attribute elements into derived
elements for further analysis of your data.
Using the Derived Elements Editor, page 101: Using the Derived Elements Editor
provides the full set of derived elements functionality when creating derived
elements.
Creating and using stand-alone derived elements, page 117: You can create stand-
alone derived elements that can be used in multiple reports and Grid/Graphs. You
use the Derived Elements Editor to create stand-alone derived elements, but you do
not have to create them from within a report or Grid/Graph.

2017, MicroStrategy Inc. 88

In-memory Analytics Guide

Quickly creating groups, calculations, and sorts

While reviewing the results on a report or document, you can quickly group attribute
elements into derived elements for further analysis of your data.
You can quickly create derived elements based on attribute elements and other derived
elements in reports and Grid/Graphs using right-click options. You can create the
following types of quick group derived elements:

Review the table following the list of quick group derived elements for a list of
when you can use these quick group options to create derived elements.

Creating quick groups, page 90: Creates a simple group of attribute elements.
Creating quick calculations, page 92: Creates a calculation on the attribute elements
or derived elements (or a combination of both).
Creating quick sorts, page 99: Creates a derived element that sorts the attribute
elements on the report or document in any order you want. This option is only
available if no derived elements are defined for the attribute on the report or
document.
These quick group options to create derived elements are quick and easy ways to create
derived elements. However, creating derived elements with these quick group techniques
is only available with the configurations listed in the table below:

Report Object Type View/Mode MicroStrategy Derived Element Quick

Groups
Developer/Web
Quick Quick Quick
Group Sort Calculation

Standard report Grid View Web Yes Yes Yes

Grid and Graph View Web Yes Yes Yes
Graph View Web No No No
Intelligent Cube Grid View Developer Yes Yes Yes
report and Web
Grid and Graph View Developer Yes Yes Yes
and Web
Graph View Developer No No No
and Web
Grid/Graph in a Design View Developer No Yes No
Report Services
document Design Mode Web No No No
Interactive Mode Web Yes No Yes
(Grid/Graph must be displayed
as a Grid or a Grid and Graph)
Editable Mode Web Yes No Yes
(Grid/Graph must be displayed
as a Grid or a Grid and Graph)

89 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Creating quick groups

Using right-click options, you can group attribute elements into a single derived element.
The derived element created by this action aggregates and displays all the data for the
attribute elements selected, into one set of data. For information on Group derived
elements, see Group derived element, page 81.
For example, you have a report that displays the number of sales orders, sales order
items, and sales order amounts for customer industry sectors. Your report displays this
information over a number of months. To get a more summarized view of the data, you
decide to group months into seasons. You group October and November 2008 into a
single derived element called Fall 08, by selecting the attribute elements, right-clicking
the selection, and selecting Create Group. This process is shown below.

You can then type a name for the group, such as Fall 08, and then click OK. A derived
element is created for the Fall 08 group, which displays and aggregates the data for
October and November 2008.
You can also group attributes elements to create derived elements for the winter, spring
and summer months. A report with a derived element for each season group is shown
below.

2017, MicroStrategy Inc. 90

In-memory Analytics Guide

As shown in the report above, data for each customer industry sector is aggregated for
the three months of each group. For example, Retail and Consumer Products had one
sales order in June 2009, three sales orders in July 2009, and one sales order in August
2009. This data is aggregated to a total of five sales orders for the Summer 09 time
period.

Creating a derived element on Intelligent Cube reports with a quick group

The steps below show you how to create a quick group on a report connected to an
Intelligent Cube.
Prerequisites
The report on which you create the derived element is connected to an active
Intelligent Cube.
You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To create a derived element with a quick group

1 In MicroStrategy Developer or Web, log in to a project that contains Intelligent Cube

reports.

91 2017, MicroStrategy Inc.

 In-memory Analytics Guide

2 Navigate to and run the Intelligent Cube report. View the report in either Grid View
or Grid and Graph View.
3 In the grid display of the report, hold down the CTRL key and select multiple
attribute elements within the same attribute.

Do not select derived elements for the attribute, as you cannot create quick
groups based on derived elements. To group derived elements, you must use
the Derived Elements Editor.

4 Right-click your selection and select Group. The Create Group dialog box opens.
5 Type a name for the derived element, and click OK.
The group is created as a derived element and displayed on the report. You can modify
the derived element using the Derived Elements Editor (see Using the Derived Elements
Editor, page 101).

Creating a derived element on standard reports with a quick group

You can create quick groups on standard reports in View Mode in MicroStrategy Web.
For steps to create quick groups on standard reports in MicroStrategy Web, see the
MicroStrategy Web Help.

Creating a derived element on Grid/Graphs with a quick group

You can create quick groups on Grid/Graphs in documents in Interactive or Editable
Mode in MicroStrategy Web. For steps to create quick groups on Grid/Graphs in
documents in MicroStrategy Web, see the MicroStrategy Web Help.

Creating quick calculations

Using right-click options, you can group attribute elements and derived elements into a
single derived element using the following quick calculations. Quick calculations enable
you to view various types of data and analysis on the same report.

Note the following:

If you select exactly two attribute elements, you can choose from all of the
calculations listed below.
If you select more than two attribute elements, Subtract and Divide are not
available calculations as they can only accept two operands. If you want to create
a subtraction or division including more than two attribute elements, you must
use the Derived Elements Editor.
The Greatest and Least calculations are best used when your report has only one
metric. These calculations operate on each metric individually, so if your report
has more than one metric, the values for the Greatest derived element will not
necessarily correspond to the same attribute element.

2017, MicroStrategy Inc. 92

In-memory Analytics Guide

Sum: Performs an addition of two or more attribute elements, derived elements, or

a combination of both.
Subtract: Performs a subtraction of two attribute elements, derived elements, or a
combination of both. The element that is at the higher position on the report is the
first operand of the subtraction, and the element at the lower position is the second
operand of the subtraction.
Average: Performs an average of two or more attribute elements, derived elements,
or a combination of both.
Divide: Performs a division of two attribute elements, derived elements, or a
combination of both. The element that is at the higher position is the first operand
of the division, and the element at the lower position is the second operand of the
division.
Greatest: Calculates and displays the greatest value of each metric for two or more
attribute elements, derived elements, or a combination of both.
The two tables below show an example of a creating a greatest calculation on the
books and electronics categories.

Category Revenue Profit

Books $1,000 $500

Electronics $2,000 $300
... ... ...

Category Revenue Profit

Greatest of Books and Electronics $2,000 $500

... ... ...

Least: Calculates and displays the least value of each metric for two or more
attribute elements, derived elements, or a combination of both.
Using the same example used to illustrate the Greatest calculation listed above, the
table below shows an example of a creating a least calculation on the books and
electronics categories.

Category Revenue Profit

Least of Books and Electronics $1,000 $300

... ... ...

93 2017, MicroStrategy Inc.

 In-memory Analytics Guide

A quick calculation is created as a Calculation derived element. For information on

Calculation derived elements, see Calculation derived element, page 85.

To illustrate quick calculations, consider the following example. You have a report that
displays the unit price, cost, and profit for all items sold in the Action movies
subcategory, as shown below.

You decide to do further analysis based on the unit cost of the various items listed. To
provide this analysis you begin to put the items into various groups that perform an
average of their data. You create the first group by selecting Vanishing Point, Godzilla,
Apollo 13, Le Mans, The African Queen, and Manhunter, then right-clicking the
selection, pointing to Create Calculation, and selecting Average. This process is
shown below.

2017, MicroStrategy Inc. 94

In-memory Analytics Guide

You then type a name for the group, such as Average Unit Costs $7.00-$9.99, and then
click OK. A derived element is created for the Average Unit Costs $7.00-$9.99 group,
which displays an average of the data for Vanishing Point, Godzilla, Apollo 13, Le Mans,
The African Queen, and Manhunter.

When you create the quick calculation, the resulting derived element appears at
the top of the report, and its attribute elements remain below it. To hide these
elements, use the Derived Elements Editor. To show or hide attribute elements
using the Derived Elements Editor, see Displaying derived elements and their
attribute elements simultaneously, page 125.

You can then group the rest of the items into two other groups, one for Average Unit
Costs $10.00-$13.99 and one for Unit Costs $14.00+. The resulting report is shown
below.

95 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You can now view your data at a new summarized level. The report shows a relatively
sizable average unit profit for items with unit costs greater than $14.00. You can
continue your analysis to see whether the higher prices are affecting the average number
of items sold, as shown below.

2017, MicroStrategy Inc. 96

In-memory Analytics Guide

As shown in the report above, the higher prices have no negative effect on the number
of items sold for the items you expect a higher profit margin on. This type of analysis can
lead you to update your pricing guidelines to maximize profits for items of varying values.

Creating a derived element on a report with a quick calculation

The steps below describe how to create a quick calculation on a report connected to an
Intelligent Cube.
Prerequisites
The report on which you create the derived element is connected to an active
Intelligent Cube.
You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To create a derived element with a quick calculation

1 In MicroStrategy Developer or Web, log in to a project that contains reports

connected to active Intelligent Cubes.

97 2017, MicroStrategy Inc.

 In-memory Analytics Guide

2 Navigate to and run the Intelligent Cube report. View the report in either Grid View
or Grid and Graph View.
3 In the grid display of the report, press the CTRL key and select multiple attribute
elements within the same attribute.
4 Right-click your selection, point to Create Calculation, and then select one of the
following calculations. Each is described in Creating quick calculations, page 92.

Note the following:

If you selected exactly two attribute elements, you can choose from all of the
calculations listed below.
If you select more than two attribute elements, Subtract and Divide are not
available calculations as they can only accept two operands.
If you want to create a subtraction or division including more than two attribute
elements, you must use the Derived Elements Editor.
Sum
Subtract
Average
Greatest
Least
Divide
The Defining Group dialog box opens.
5 Type a name for the derived element and click OK.
The calculation is created as a derived element and displayed on the report. You can
modify the derived element using the Derived Elements Editor (see Using the Derived
Elements Editor, page 101).

Creating a derived element on standard reports with a quick calculation

You can create quick calculations on standard reports in View Mode in MicroStrategy
Web. For steps to create quick calculations on standard reports in MicroStrategy Web,
see the MicroStrategy Web Help.

Creating a derived element on Grid/Graphs with a quick calculation

You can create quick calculations on Grid/Graphs in documents in Interactive or
Editable Mode in MicroStrategy Web. For steps to create quick calculations on
Grid/Graphs in documents in MicroStrategy Web, see the MicroStrategy Web Help.

2017, MicroStrategy Inc. 98

In-memory Analytics Guide

Creating quick sorts

Using right-click options, you can group attribute elements into a single derived element
that sorts the attribute elements in any order you choose. This enables you to do more
advanced attribute element sorting than simple ascending or descending sorts.
For example, you have a report that lists the vendors with the ten largest open accounts
payable amounts, as shown below.

After reviewing the list of vendors with the largest open payable amounts from highest to
lowest, you can sort the vendors into any order that meets your requirements. You can
achieve this by right-clicking the Vendor attribute, pointing to Sort, and then selecting
List (custom). The Derived Elements Editor opens with all of the attribute elements
listed as selected objects.

A quick sort is created as a Group derived element. For information on Group

derived elements, see Group derived element, page 81.

You can move the elements up and down in the Selected objects list to re-order them on
the report. When you are ready, click OK to accept the changes and return to the report.
Notice the new order of Vendor attribute elements in the report shown below.

99 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Creating a derived element on Intelligent Cube reports with a quick sort

The steps below show you how to create a quick sort on a report connected to an
Intelligent Cube.
Prerequisites
The report on which you create the derived element is connected to an active
Intelligent Cube.
The attribute you select to create a quick sort for cannot have any existing derived
elements defined on it for the report.
You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To create a derived element with a quick sort

1 In MicroStrategy Developer or Web, log in to a project that contains reports

connected to active Intelligent Cubes.
2 Navigate to and run the Intelligent Cube report. View the report in either Grid View
or Grid and Graph View.
3 Right-click an attribute in the grid display, point to Sort, and then select Custom.
The Derived Elements Editor opens with all of the attribute elements listed as
selected objects.

If Custom is not an option in the Sort options, this means that the attribute
has a derived element defined for it on the report. You must remove any
derived elements defined for the attribute before you can create a quick sort to
re-order the attribute elements.

4 In the Selected objects list, move the attribute elements to the order you want
them displayed on the report.
5 Once the attribute elements are ordered appropriately, click OK. The Derived
Elements Editor closes and you are returned to the report.
The report displays the attribute elements in the new order. You can modify the derived
element using the Derived Elements Editor (see Using the Derived Elements Editor,
page 101).

Creating a derived element on standard reports with a quick sort

You can create quick sorts on standard reports in View Mode in MicroStrategy Web. For
steps to create quick sorts on standard reports in MicroStrategy Web, see the
MicroStrategy Web Help.

2017, MicroStrategy Inc. 100

In-memory Analytics Guide

Creating a derived element on Grid/Graphs with a quick sort

The steps below show you how to create a quick sort on a Grid/Graph included in a
Report Services document from MicroStrategy Developer.
You can create quick sorts on Grid/Graphs in documents in Interactive or Editable Mode
in MicroStrategy Web. For steps to create quick sorts on Grid/Graphs in MicroStrategy
Web, see the MicroStrategy Web Help.
Prerequisites
The Report Services document with a Grid/Graph included in one of the document
sections, on which you create the derived element.
The attribute you select to create a quick sort for cannot have any existing derived
elements defined on it for the report.
You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To create a derived element with a quick sort

1 In MicroStrategy Developer, log in to a project that contains Grid/Graphs in Report

Services documents.
2 Open the document in Design View and expand the document section that contains
the Grid/Graph.
3 Right-click the Grid/Graph and select Edit Grid.
4 Right-click an attribute, point to Sort, and then select List (custom). The Derived
Elements Editor opens with all of the attribute elements listed as selected objects.

If List (custom) is not an option in the Sort options, this means that the
attribute has a derived element defined for it on the source report. You must
remove any derived elements defined for the attribute before you can create a
quick sort to re-order the attribute elements.

5 In the Selected objects list, re-order the attribute elements as you want to view
them on the report.
6 Once the attribute elements are ordered appropriately, click OK. The Derived
Elements Editor closes and you are returned to the report.
The document displays the attribute elements in the new order. You can modify the
derived element using the Derived Elements Editor (see Using the Derived Elements
Editor, page 101).

Using the Derived Elements Editor

While the quick groups features described in Quickly creating groups, calculations, and
sorts, page 89 enable you to quickly create derived elements using right-click menu
options while reviewing report results, the Derived Elements Editor provides the full set

101 2017, MicroStrategy Inc.

 In-memory Analytics Guide

of derived elements functionality when creating derived elements. The Derived Elements
Editor is shown in the image below.

For example, if you use right-click menu options create a quick calculation on a report
connected to an Intelligent Cube, the expression can only include one type of function or
operand such as +, /, and Average. However, in the Derived Elements Editor, you can
create expressions with a valid combination of different functions. You can create a
derived element from the Derived Elements Editor with an expression of the following
form:
(AttributeElement1 + AttributeElement2) / Sum
(AllAttributeElements)
You can modify derived elements in the following ways using the Derived Elements
Editor:
Applying derived element values to subtotals, page 121
Displaying derived elements or their attribute elements, page 123
Displaying derived elements and their attribute elements simultaneously, page 125
Formatting derived elements, page 128
Creating and using stand-alone derived elements, page 117
Creating Filter derived elements with Not in List and Where filter qualifications (see
Filtering attribute elements to create a derived element, page 109)

2017, MicroStrategy Inc. 102

In-memory Analytics Guide

Creating advanced Calculation derived elements (see Using calculations to create

derived elements, page 112)
Deleting derived elements

Sample report
The report shown below is used in the procedures and examples that follow for creating
derived elements with the Derived Elements Editor.

Accessing the Derived Elements Editor

Using the Derived Elements Editor, you can create derived elements with groups, filters,
and calculations. These derived elements can be created from the Derived Elements

103 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Editor in MicroStrategy Developer and Web in the reporting objects listed below:
A standard report. To access the Derived Elements Editor from standard reports, see
To access the Derived Elements Editor in standard reports, page 105.
A report which is connected to an active Intelligent Cube. The table below lists the
views you can access the Derived Elements Editor from, in MicroStrategy Developer
and Web. To access the Derived Elements Editor from reports, see To access the
Derived Elements Editor in reports connected to an active Intelligent Cube, page
105.
A Grid/Graph in a Report Services document. The table below lists the modes you
can access the Derived Elements Editor from, in MicroStrategy Developer and Web.
To access the Derived Elements Editor from Grid/Graphs, see To access the Derived
Elements Editor in Grid/Graphs , page 105.

Report Object Type View/Mode MicroStrategy Can Access Derived

Element Editor
Developer/Web

Standard report Grid View Web Yes

Report connected to an Grid View Developer Yes
active Intelligent Cube and Web
Grid and Graph View Developer Yes
and Web
Design View Developer Yes
Design View Web No

Grid/Graph in a Report Design View Developer Yes

Services document
Design Mode Web No
Interactive Mode Web Yes
(Grid/Graph must be displayed as
a Grid or a Grid and Graph)
Editable Mode Web Yes
(Grid/Graph must be displayed as
a Grid or a Grid and Graph)

You can also create stand-alone derived elements by accessing the Derived Elements
Editor from outside reports or Grid/Graphs. Stand-alone derived elements can be used
by multiple reports and Grid/Graphs. For information on using a derived element in
multiple reports and accessing the Derived Elements Editor to create stand-alone derived
elements, see Creating and using stand-alone derived elements, page 117.

2017, MicroStrategy Inc. 104

In-memory Analytics Guide

To access the Derived Elements Editor in reports connected to an

active Intelligent Cube

1 In MicroStrategy Developer or Web, log in to a project that contains reports

connected to active Intelligent Cubes.
2 Open a report and run it. View it in either Grid View, Grid and Graph View, or
Design View.
3 In the grid display of the report, right-click the attribute you want to create or
modify derived elements for, and click Derived Elements. The Derived Elements
Editor opens.

To access the Derived Elements Editor in standard reports

1 In MicroStrategy Web, log in to a project that contains the report.

2 Open the report in View Mode, in either Grid View or Grid and Graph View.
3 In the grid display of the report, right-click the attribute you want to create or
modify derived elements for, and click Derived Elements. The Derived Elements
Editor opens.

To access the Derived Elements Editor in Grid/Graphs

1 In MicroStrategy Developer or Web, log in to a project that contains Grid/Graphs in

Report Services documents.
2 Open the document. Accessing the Derived Elements Editor depends on what mode
you are viewing the document in. Follow the steps below depending on which view
or mode you are using:
Design View in MicroStrategy Developer only:
a Expand the document section that contains the Grid/Graph.
b Right-click the Grid/Graph and select Edit Grid.
c Right-click the attribute to create or modify derived elements for, and click
Derived Elements. The Derived Elements Editor opens.
Interactive Mode or Editable Mode in MicroStrategy Web only:
a In the grid display of the Grid/Graph, right-click the attribute to create or
modify derived elements for, and click Derived Elements. The Derived
Elements Editor opens.

105 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Grouping attribute elements to create a derived element

When viewing a report you can combine attribute elements into a single group of
aggregated data. This combined set of attribute elements is called a Group derived
element. This derived element enables you to view and analyze the attribute elements
data as a single, distinct group.
For example, in a report with Region and Category attributes and a Profit metric (see the
image in Sample report, page 103), you can combine the regions on the report into
various geographical groups. The final report you create with attribute elements grouped
based on geography is shown below.

The steps below show you how to create a Group derived element on a report, as well as
specific instructions to create the sample report shown above.
Prerequisites
The report on which you create the derived element is connected to an active
Intelligent Cube, or the Report Services document with a Grid/Graph included in
one of the document sections, on which you create the derived element.
You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To create a Group derived element

While this procedure creates only Group derived elements, you can create any
combination of Group, Filter, and Calculation derived elements on a report or
Grid/Graph.
1 Log in to a project in MicroStrategy Developer. For steps to use the Derived
Elements Editor to create derived elements in MicroStrategy Web, see the
MicroStrategy Web Help.

2017, MicroStrategy Inc. 106

In-memory Analytics Guide

To access the Derived Elements Editor in reports and Grid/Graphs

2 Open the report or Grid/Graph (the example scenario uses a report connected to an
Intelligent Cube), as follows:
To access the Derived Elements Editor for a report connected to an Intelligent
Cube:
a Execute the report and run it in Grid View or Grid and Graph View.
b Right-click the attribute to create or modify derived elements for, and click
Derived Elements. The Derived Elements Editor opens.
For the example scenario, right-click the Region attribute, and click Derived
Elements.
To access the Derived Elements Editor for a Grid/Graph in a Report Services
document:
a Expand the document section that contains the Grid/Graph.
b Double-click the Grid/Graph to edit it.
c Right-click the attribute to create or modify derived elements for, and click
Derived Elements. The Derived Elements Editor opens.
For the example scenario, right-click the Region attribute, and click Derived
Elements.

To create a Group derived element

3 To create a new Group derived element, from the New drop-down list select
Group.
Two new derived elements are created, a blank Group derived element and an All
Other derived element. The All Other derived element is a collection of all attribute
elements that are not included in any of the other derived elements for the attribute.
For further explanation of the All Other derived element, see All Other derived
element, page 87.
4 Select the new Group derived element. This displays the available attribute elements
in the Definition tab.
For the example scenario, the Region attribute elements are displayed.
5 From the left pane, select attribute elements to include in the derived element, and
then click the right arrow (>) to add your selections to the Selected objects pane.
For the example scenario, select the Mid-Atlantic, Northeast, and Southeast
attribute elements.
6 To rename the Group derived element, from the Change Group drop-down list,
select Rename Group. Type a name for the derived element.
For the example scenario, rename the group as East Coast.

107 2017, MicroStrategy Inc.

 In-memory Analytics Guide

To make derived element modifications

7 From the Property tab, you can make various modifications to the new derived
element such as:
Displaying derived elements or their attribute elements, page 123
Applying derived element values to subtotals, page 121
Displaying derived elements and their attribute elements simultaneously, page
125
8 From the Change Group drop-down list, you can format derived element headers
and values. For information on these formatting techniques, see Formatting derived
elements, page 128.
9 You can change the order in which the derived elements are displayed on the report
using the up ( ) and down ( ) arrows.

To complete derived element creation

10 You can continue to create more derived elements, or you can click OK to close the
Derived Elements Editor and return to the report. The steps below continue the
example scenario.
11 From the New drop-down list, select Group. A blank group is created.
12 Select the new derived element. This displays the available attribute elements in the
Definition tab.
13 From the left pane, select the Northeast and Southeast attribute elements, and
then click the right arrow (>) to add your selections to the Selected objects pane.
14 From the Change Element drop-down list, select Rename Group. Type West
Coast to rename the Group derived element.
15 From the New drop-down list, select Group. A blank group is created.
16 Select the new derived element. This displays the available attribute elements in the
Definition tab.
17 From the left pane, select the Central and South attribute elements, and then click
the right arrow (>) to add your selections to the Selected objects pane.
18 From the Change Group drop-down list, select Rename Group. Type Central
and South to rename the derived element group.
19 You can save your derived element for the report or Grid/Graph, or save the derived
element as a stand-alone object that can be used by multiple reports and
Grid/Graphs:
To save the derived element for the report or Grid/Graph, click OK. The
Derived Elements Editor closes and you are returned to the report or document.
To save the derived element as a stand-alone object that can be used by multiple
reports and Grid/Graphs, click Save Groups. Choose a location to save the

2017, MicroStrategy Inc. 108

In-memory Analytics Guide

derived element to, type a name, and click Save. Click OK. The Derived
Elements Editor closes and you are returned to the report or document.
Stand-alone derived elements can only be modified by editing the stand-alone
object; you cannot modify them from within reports or Grid/Graphs. For
information stand-alone derived elements, see Creating and using stand-alone
derived elements, page 117.
If you used the steps above to create the sample report, the report is displayed with the
regions grouped into East Coast, West Coast, Central and South, and Web.

Filtering attribute elements to create a derived element

While viewing a report, you can combine attribute elements into a single group of
aggregated data using filter qualifications. This group of attribute elements is called a
Filter derived element. This derived element enables you to view and analyze the
attribute elements data as a single distinct group by utilizing various filter qualifications.
For example, in a report with Region and Category attributes and a Profit metric (see the
image in Sample report, page 103), you can filter the regions on the report into various
geographical groups based on the region names. The final report you create with Filter
derived elements is shown below.

The steps below show you how to create a Filter derived element on a report, as well as
specific instructions to create the report shown above.
Prerequisites

109 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To create a Filter derived element

While this procedure creates only Filter derived elements, you can create any
combination of Group, Filter, and Calculation derived elements on a report or
Grid/Graph.

1 Log in to a project in MicroStrategy Developer. For steps to use the Derived

Elements Editor to create derived elements in MicroStrategy Web, see the
MicroStrategy Web Help.

To access the Derived Elements Editor in reports and Grid/Graphs

2 Open the report or Grid/Graph (the example scenario uses a report connected to an
Intelligent Cube), as follows:
To access the Derived Elements Editor for a report connected to an Intelligent
Cube:
a Execute the report. Then view it in either Grid View or Grid and Graph
View.
b Right-click the attribute to create or modify derived elements for, and click
Derived Elements. The Derived Elements Editor opens.
For the example scenario, right-click the Region attribute, and click Derived
Elements.
To access the Derived Elements Editor for a Grid/Graph in a Report Services
document:
a Expand the document section that contains the Grid/Graph.
b Double-click the Grid/Graph to edit it.
c Right-click the attribute to create or modify derived elements for, and click
Derived Elements. The Derived Elements Editor opens.
For the example scenario, right-click the Region attribute, and click Derived
Elements.

To create a Filter derived element

3 To create a new Filter derived element, from the New drop-down list, select Filter.
Two new derived elements are created, a blank Filter derived element and an All
Other derived element. The All Other derived element is a collection of all attribute
elements that are not included in any of the other derived elements for the attribute.
For further explanation of the All Other group, see All Other derived element, page
87.
4 Select the new Filter derived element.

2017, MicroStrategy Inc. 110

In-memory Analytics Guide

5 From the Definition tab, click Click here to start a new qualification.
6 Click Field, and then select an attribute.
For the example scenario, select Region.
7 Click Operator, and then select one of the following operators to create a filter
qualification (for the example scenario, select Where):
In list: Returns attribute data for the list of attribute elements you select. Click
Value, and then select the attribute elements to return data for.
Not in List: Returns attribute data for the list of attribute elements that are not
in the list of attribute elements you select. Click Value, and then select the
attribute elements to exclude data for.
Where: Returns attribute data based on a filter qualification of an attribute
form. Proceed to the next step to select an attribute form and complete the filter
qualification.
8 For filter qualifications that use the operator Where, new Field, Operator, and Value
fields appear. Follow the steps below to complete the filter qualification:
a Click Field, and then select an attribute form. For the example scenario, select
DESC.
b Click Operator, and then select the operator for the filter qualification on the
attribute form. For the example scenario, select Begins with.
c Click Value, and use one of the options to enter in the required value. For the
example scenario, select Type a value, and then type South.
9 To rename the derived element group, from the Change Group drop-down list,
and select Rename Group. Type a name for the Filter derived element.
For the example scenario, rename the derived element as Southern Regions.

To make derived element modifications

10 From the Property tab, you can make various modifications to the new derived
element such as:
Displaying derived elements or their attribute elements, page 123
Applying derived element values to subtotals, page 121
Displaying derived elements and their attribute elements simultaneously, page
125
11 From the Change Group drop-down list, you can format derived element headers
and values. For information on these formatting techniques, see Formatting derived
elements, page 128.
12 You can change the order in which the derived elements are displayed on the report
using the up ( ) and down ( ) arrows.

111 2017, MicroStrategy Inc.

 In-memory Analytics Guide

To complete derived element creation

13 You can continue to create more derived elements, or you can click OK to close the
Derived Elements Editor and return to the report. The steps below continue the
example scenario.
14 From the New drop-down list, select Filter. A blank Filter derived element is
created.
15 Select the new derived element.
16 From the Definition tab, click Click here to start a new qualification.
17 Click Field, and then select Region.
18 Click Operator, and then select Where.
19 Click Field, and then select the DESC attribute form.
20 Click Operator, and then select Begins with.
21 Click Value, and then select Type a value, and then type North.
22 To rename the derived element group, from the Change Group drop-down list,
and select Rename Group. Type Northern Regions to rename the derived
element.
23 You can save your derived element for the report or Grid/Graph, or save the derived
element as a stand-alone object that can be used by multiple reports and
Grid/Graphs:
To save the derived element for the report or Grid/Graph, click OK. The
Derived Elements Editor closes and you are returned to the report or document.
To save the derived element as a stand-alone object that can be used by multiple
reports and Grid/Graphs, click Save Groups. Choose a location to save the
derived element to, type a name, and click Save. Click OK. The Derived
Elements Editor closes and you are returned to the report or document.
Stand-alone derived elements can only be modified by editing the stand-alone
object; you cannot modify them from within reports or Grid/Graphs. For
information on using derived elements, see Creating and using stand-alone
derived elements, page 117.
If you used the steps above to create the sample report, the report is displayed with the
regions grouped into Southern Regions and Northern Regions, along with the Central,
Mid-Atlantic, and Web regions.

Using calculations to create derived elements

When viewing a report you can combine attribute elements into a single set of aggregated
data using calculations. This combined set of attribute elements is called a Calculation
derived element. This derived element enables you to view and analyze the attribute
elements data as a single, distinct group by utilizing various calculation functions and
operators.

2017, MicroStrategy Inc. 112

In-memory Analytics Guide

For example, in a report with Region and Category attributes and a Profit metric (see the
image in Sample report, page 103), you can combine the regions on the report into
various groups for profit analysis. The final report you create with Calculation derived
elements is shown below.

The steps below show you how to create a Calculation derived element on a report, as
well as specific instructions to create the sample report shown above.
Prerequisites
You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To create a Calculation derived element

While this procedure creates only Calculation derived elements, you can create any
combination of Group, Filter, and Calculation derived elements on a report or
Grid/Graph.
1 Log in to a project in MicroStrategy Developer. For steps to use the Derived
Elements Editor to create derived elements in MicroStrategy Web, see the
MicroStrategy Web Help.

To access the Derived Elements Editor in reports and Grid/Graphs

2 Open the report or Grid/Graph (the example scenario uses a report connected to an
Intelligent Cube), as follows:
To access the Derived Elements Editor for a report connected to an Intelligent
Cube:
a Execute the report. The view it in either Grid View or Grid and Graph View.

113 2017, MicroStrategy Inc.

 In-memory Analytics Guide

b Right-click the attribute to create or modify derived elements for, and click
Derived Elements. The Derived Elements Editor opens.
For the example scenario, right click the Region attribute, and click Derived
Elements.
To access the Derived Elements Editor for a Grid/Graph in a Report Services
document:
a Expand the document section that contains the Grid/Graph.
b Double-click the Grid/Graph to edit it.
c Right-click the attribute to create or modify derived elements for, and click
Derived Elements. The Derived Elements Editor opens.
For the example scenario, right click the Region attribute, and click Derived
Elements.

To create a Calculation derived element

3 To create a new Calculation derived element, from the New drop-down list, select
Calculation.
Two new derived elements are created, a blank Calculation derived element and an
All Other derived element. The All Other derived element is a collection of all
attribute elements that are not included in any of the other derived elements for the
attribute. For further explanation of the All Other derived element, see All Other
derived element, page 87.
4 Select the new Calculation derived element. This displays the available attribute
elements in the Definition tab.
For the example scenario, the Region attribute elements are displayed.
5 From the left pane, select attribute elements to include in the Calculation derived
element, and add them to the expression area on the right (shown below). You can
also use the toolbar above the expression to include operators and functions, as well
as validate or clear the expression.
For the example scenario, select all the attribute elements available and drag the
entire selection to the expression area. This adds all the attribute elements to the
expression area, and automatically use the addition operator to combine the attribute
elements, as shown below.

2017, MicroStrategy Inc. 114

In-memory Analytics Guide

6 To rename the derived element, from the Change Group drop-down list, select
Rename Group. Type a name for the derived element.
For the example scenario, rename the group as Total Profit.

To modify derived elements

7 From the Property tab, you can make various modifications to the new derived
element, such as:
Displaying derived elements or their attribute elements, page 123
Applying derived element values to subtotals, page 121
Displaying derived elements and their attribute elements simultaneously, page
125
8 From the Change Group drop-down list, you can format derived element headers
and values. For information on these formatting techniques, see Formatting derived
elements, page 128.
9 You can change the order in which the derived elements are displayed on the report
using the up ( ) and down ( ) arrows.

To complete creating a derived element

10 You can continue to create more derived elements, or you can click OK to close the
Derived Elements Editor and return to the report. The steps below continue the
example scenario.

To create an average calculation of attribute elements

11 From the New drop-down list, select Calculation. A blank Calculation derived
element is created.
12 Select the new derived element.
13 On the Definition tab, click f(x). The Insert Function Wizard opens.
14 Select the Average function, and click Next. The Arguments page opens.

115 2017, MicroStrategy Inc.

 In-memory Analytics Guide

15 Click ... (browse) next to Argument 1, and in the Select an Object dialog box, select
Central. Then click OK. Repeat this step for each successive argument, selecting
the following regions:
Mid-Atlantic
Northeast
Northwest
South
Southeast
Southwest
Web
16 Click Finish.
17 From the Change Group drop-down list, select Rename Group. Type Average
Profit to rename the derived element.

To create a greatest calculation of attribute elements

18 From the New drop-down list, select Calculation. A blank Calculation derived
element is created.
19 Select the new derived element.
20 On the Definition tab, click f(x). The Insert Function Wizard opens.
21 Select the Greatest function, and click Next. The Arguments page opens.
22 Click ... (browse) next to Argument 1, and in the Select an Object dialog box, select
Central. Then click OK. Repeat this step for each successive argument, selecting
the following regions:
Mid-Atlantic
Northeast
Northwest
South
Southeast
Southwest
Web
23 From the Change Group drop-down list, select Rename Group. Type Greatest
Regional Profit to rename the derived element.

2017, MicroStrategy Inc. 116

In-memory Analytics Guide

To create a percent contribution from a division of derived elements

24 From the New drop-down list, select Calculation. A blank Calculation derived
element is created.
25 Select the new derived element.
26 On the Definition tab, from the drop-down list select Groups.
27 From the left pane, select Greatest Regional Profit and drag and drop it into the
expression area on the right.
28 Click /.
29 From the left pane, select Total Profit and drag and drop it into the expression area
on the right. Your final expression should appear as shown below:

30 From the Change Group drop-down list, select Rename Group. Type Greatest
Regional Profit % Contribution to rename the derived element.
31 You can save your derived element for the report or Grid/Graph, or save the derived
element as a stand-alone object that can be used by multiple reports and
Grid/Graphs:
To save the derived element for the report or Grid/Graph, click OK. The
Derived Elements Editor closes and you are returned to the report or document.
To save the derived element as a stand-alone object that can be used by multiple
reports and Grid/Graphs, click Save Groups. Choose a location to save the
derived element to, type a name, and click Save. Click OK. The Derived
Elements Editor closes and you are returned to the report or document.
Stand-alone derived elements can only be modified by editing the stand-alone
object; you cannot modify them from within reports or Grid/Graphs. For
information on sharing derived elements, see Creating and using stand-alone
derived elements, page 117.
If you used the steps above to create the sample report, the report is displayed with the
regions grouped into Total Profit, Average Profit, Greatest Regional Profit, and Greatest
Regional Profit % Contribution.

Creating and using stand-alone derived elements

A stand-alone derived element can be connected to matching attributes in reports
connected to Intelligent Cubes and Grid/Graphs. This enables you to use a derived
element in multiple reports and Grid/Graphs.

117 2017, MicroStrategy Inc.

 In-memory Analytics Guide

To use a derived element in multiple reports and Grid/Graphs, you must create a stand-
alone derived element. There are two methods with to create a stand-alone derived
element:
Create a derived element from within a report or Grid/Graph and then save it as a
stand-alone object. You can use the Derived Elements Editor to create and save the
derived element as a stand-alone derived element. You can use this method in
MicroStrategy Developer and Web. For information on creating a derived element
within a report or Grid/Graph using the Derived Elements Editor, see Using the
Derived Elements Editor, page 101.
Once you save a derived element as a stand-alone derived element, it can no longer
be modified from within the report or Grid/Graph. For information on how to
modify a stand-alone derived element, see Editing stand-alone derived elements,
page 120.
Create a stand-alone derived element outside of any report or Grid/Graph. You can
use this method only in MicroStrategy Developer. To used this method, see Creating
a stand-alone derived element, page 118.
Once created, a stand-alone derived element has the following functionality:
All Group, Calculation, Filter, and All Other derived elements are saved as part of the
derived element. You cannot select a subset of the derived elements; you must save
and share the entire collection of derived elements.
A stand-alone derived element can only be connected to the attribute that was used
to define the derived element. For information on how to connect derived elements
to attributes in other reports and Grid/Graphs, see Using a derived element in
multiple reports or Grid/Graphs, page 119.
The stand-alone derived element itself can be modified, but you cannot modify it
from within a report or Grid/Graph. Any modifications for the derived element are
applied to the derived element in all of the reports and Grid/Graphs that it is used in.
For information on how to modify a stand-alone derived element, see Editing stand-
alone derived elements, page 120.
The stand-alone derived element can only be deleted if it is not used in any report or
Grid/Graph. A list of reports and Grid/Graphs that use the derived element is
displayed when you attempt to delete a stand-alone derived element.

Creating a stand-alone derived element

The steps below show you how to create a stand-alone derived element.
Prerequisites
You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To create a stand-alone derived element

1 In MicroStrategy Developer, log in to a project.

2017, MicroStrategy Inc. 118

In-memory Analytics Guide

2 From the File menu, point to New, and then select Derived Element. The Select
Attribute dialog box opens.
3 Browse to and select the attribute you want to base your derived element on, and
then click Open. The Derived Element Editor opens.
4 You can create Group, Filter, and Calculation derived elements to define your stand-
alone derived element. With the exception any steps to access or close the Derived
Elements Editor, you can use the same processes and techniques described in the
following sections to create derived elements for a stand-alone derived element:
Grouping attribute elements to create a derived element, page 106
Filtering attribute elements to create a derived element, page 109
Using calculations to create derived elements, page 112
5 Click Save and Close, the Save Derived Element As dialog box opens.
6 Type a name and click Save. The Derived Elements Editor closes and the derived
element is saved as a stand-alone object.
You can now use your derived element in reports connected to Intelligent Cubes and
Grid/Graphs in Report Services documents, as described in Using a derived element in
multiple reports or Grid/Graphs, page 119.

Using a derived element in multiple reports or Grid/Graphs

You can use a stand-alone derived element in multiple reports and Grid/Graphs in
documents. To use a stand-alone derived element, you can connect the derived element
to an attribute in a report connected to an Intelligent Cube or to an attribute in a
Grid/Graph in a Report Services document. However, a derived element can only be
connected to the attribute used to define the derived element.
For example, if a derived element is created on the Year attribute, this derived element
can only be connected to the Year attribute in reports and Grid/Graphs. You cannot
connect this derived element to any other attributes such as Quarter, Month, Category,
Customer, and so on.
The steps below show you how to apply a stand-alone derived element to an attribute in a
report or Grid/Graph.
Prerequisites
You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To connect a stand-alone derived element to an attribute in a report

or Grid/Graph

1 Log in to a project in MicroStrategy Developer or Web.

119 2017, MicroStrategy Inc.

 In-memory Analytics Guide

To access the Derived Elements Editor in a report or a Grid/Graph in a

document
2 Open the report or Grid/Graph, as follows:
To access the Derived Elements Editor for a report:
a Execute the report. Then view it in either Grid View or Grid and Graph
View.
b Right-click the attribute to apply a stand-alone derived element to, and click
Derived Elements. The Derived Elements Editor opens.
For the example scenario, right-click the Region attribute, and click
Derived Elements.
To access the Derived Elements Editor for a Grid/Graph in a Report Services
document:
a Expand the document section that contains the Grid/Graph.
b Double-click the Grid/Graph to edit it.
c Right-click the attribute to apply a stand-alone derived element to, and click
Derived Elements. The Derived Elements Editor opens.
For the example scenario, right-click the Region attribute, and click
Derived Elements.

To connect a stand-alone derived element to an attribute

If an attribute already has a derived element defined for it in the report or

Grid/Graph, connecting a stand-alone derived element overwrites the existing
definition.

3 Click Link Derived Elements. The Select Derived Elements dialog box opens.
4 Browse to and select the derived element to connect to the attribute, and then click
Open.
5 Click OK to save your changes and close the Derived Elements Editor.

Editing stand-alone derived elements

Editing a stand-alone derived element updates the derived element in all reports and
Grid/Graphs it is used in. Since these modifications are applied to multiple reporting
objects, you can only update the stand-alone derived element itself, you cannot update it
from a report or Grid/Graph that it is used in.
The steps below show you how to modify a stand-alone derived element.
Prerequisites

2017, MicroStrategy Inc. 120

In-memory Analytics Guide

You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To edit a stand-alone derived element

1 In MicroStrategy Developer, log in to a project.

2 Browse to and right-click a stand-alone derived element, and then select Edit. The
Derived Element Editor opens.
3 You can create and modify Group, Filter, and Calculation derived elements to define
your stand-alone derived element. With the exception of any steps to access or close
the Derived Elements Editor, you can use the same processes and techniques
described in the following sections to create and modify derived elements for a
stand-alone derived element:
Grouping attribute elements to create a derived element, page 106
Filtering attribute elements to create a derived element, page 109
Using calculations to create derived elements, page 112
4 Click Save and Close to save your changes and close the Derived Elements Editor.

Defining derived element functionality and

formatting
Derived elements provide a wealth of reporting and analysis functionalities that can be
defined to achieve your specific requirements. The sections listed below cover various
derived elements functionalities and formatting techniques:
Applying derived element values to subtotals, page 121
Displaying derived elements or their attribute elements, page 123
Displaying derived elements and their attribute elements simultaneously, page 125
Formatting derived elements, page 128

Applying derived element values to subtotals

You can define how each derived element value is applied to all subtotals included on a
report or Grid/Graph. The simple report below is used as an example of how you can
apply derived element values to subtotals.

121 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You have the following options in the Derived Elements Editor for applying derived
element values to subtotals. The examples below are all based on the basic report above.

Option Name Subtotal Behavior Example

Use this (default behavior) The derived element In a report with Category and Profit, you
element values are applied to all subtotals. This create a derived element defined as
when means that a derived elements aggregated Electronics - Books. Applying the derived
calculating data is applied to all subtotals for the element value to the subtotal means
subtotals report, rather than the values for the that subtotals uses the value resulting
individual items that are part of a derived from the subtraction of the Electronics
element. and Books attribute elements, as shown
below.

Use the The values of the separate items that In a report with Category and Profit, you
individual make up the derived element are applied create a derived element defined as
items that to all subtotals. For Group and Filter Electronics - Books. Applying the
make up derived elements, only attribute elements individual item values to the subtotal
this can be included as items of derived means that the subtotal uses the
element elements. Calculation derived elements individual values of the Electronics and
when can include attribute elements as well as Books attribute elements, as shown
calculating other derived elements. below.
subtotals

Notice that the subtotal in this report is

the same value as the original report.
Do not use This option excludes the derived element In a report with Category and Profit, you
this values and separate item values from all create a derived element defined as
element subtotals. Electronics - Books. The derived element
when values as well as the individual attribute
calculating You can use this option to avoid double element values are excluded from the
subtotals counting when an attribute element is subtotal, as shown below.
included in more than one derived
element.

2017, MicroStrategy Inc. 122

In-memory Analytics Guide

Option Name Subtotal Behavior Example

The steps below show you how to define subtotal behavior for derived elements.
Prerequisites
A standard report, a report connected to an active Intelligent Cube, a Grid/Graph in
a Report Services document, or a stand-alone derived element.
This procedure also assumes you have created derived elements for the report,
Grid/Graph, or stand-alone derived element.
You have the Derived Elements Editor open. For information on accessing the
Derived Elements Editor, see Accessing the Derived Elements Editor , page 103.
You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To define subtotal behavior for derived elements

1 In the Derived Elements Editor, select a derived element.

2 Select the Property tab.
3 From the Subtotal behavior drop-down list, select one of the following options:
Use this element when calculating subtotals
Use the individual items that make up this element when
calculating subtotals
Do not use this element when calculating subtotals
These options are described in Applying derived element values to subtotals, page
121.
4 Click OK to save your changes and close the Derived Elements Editor.

Displaying derived elements or their attribute elements

Derived elements can be displayed on reports and Grid/Graphs as a single, consolidated
element with aggregated data, or as the separate attribute elements that are items of the
derived element. The simple report shown below is used to demonstrate how you can
apply derived elements to subtotals.

123 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You have the following options for displaying derived elements:

Consolidate items into one element (default behavior, except for the All Other
derived element): The derived elements components are displayed as a single entry
with the data of all of its items combined as determined by the derived element.
For example, in a report with Category and Profit, you create a Group derived
element that combines the Books and Electronics attribute elements. By keeping the
default option, the derived element is displayed as a single entry on the report, as
shown below.

Keep individual items separate (default behavior for the All Other derived element):
The attribute elements included as items of a derived element are displayed
individually instead of the derived element.
For example, in a report with Category and Profit, you create a Group derived
element that combines the Books and Electronics attribute elements. You choose to
keep the individual options separate, which displays the separate attribute elements
in the report, as shown below.

This is the default for an All Other derived element because it displays all attribute
elements (that were not included in any other derived elements) as separate attribute
elements. This gives the appearance on the report that these attribute elements are
not part of any derived element.

This option is not recommended for Calculation derived elements. The

purpose of Calculation derived elements is to use a calculation expression to
combine values of attribute elements or derived elements (or a combination of
both). Using this option with a Calculation derived element means that these
values are not combined using the calculation expression. This does not reflect
the purpose of Calculation derived elements.

2017, MicroStrategy Inc. 124

In-memory Analytics Guide

The steps below show you how to define whether derived elements are displayed as one
consolidated entry, or all of the attribute elements that are items of the derived element
are displayed individually.
Prerequisites
A standard report, a report connected to an active Intelligent Cube, a Grid/Graph in
a Report Services document, or a stand-alone derived element.
This procedure also assumes you have created derived elements for the report,
Grid/Graph, or stand-alone derived element.
You have the Derived Elements Editor open. For information on accessing the
Derived Elements Editor, see Accessing the Derived Elements Editor , page 103.
You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To display derived elements as consolidated or individual attribute

elements

1 In the Derived Elements Editor, select a derived element.

2 Select the Property tab.
3 Select one of the following Element behavior options:
Consolidate items into one element
Keep individual items separate
These options are described in Displaying derived elements or their attribute
elements, page 123.
4 Click OK to save your changes and close the Derived Elements Editor.

Displaying derived elements and their attribute

elements simultaneously
You can analyze attribute elements with derived elements, while also including the
attribute element on the report. You can accomplish this by selecting which attribute
elements are included in the All Other derived element.
By default, the All Other derived element only collects attribute elements that are not
included in derived elements, and includes them on the report as individual attribute
elements. For an introduction to the All Other derived element, see All Other derived
element, page 87.
The simple report below is used as an example of how you can display derived elements
and their attribute elements simultaneously.

125 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You have the following options in the Derived Elements Editor to display derived
elements and their attribute elements simultaneously:
Do not include individual items in the All Other element (default behavior): The
attribute elements that are used to define the derived element are excluded from the
All Other derived element. This means that the attribute elements are not displayed,
only their combined data for the derived element is displayed.
For example, in a report with Category and Profit, you create a Group derived
element that combines the Books and Electronics attribute elements. By selecting to
keep the default option, the derived element is displayed on the report but the
attribute elements that makes up these derived elements are not, as shown below.

Include individual items in the All Other element: The attribute elements that are
used to define the derived element are also included in the All Other derived
element. This means that the attribute elements are displayed along with the derived
elements they are a part of.
For example, in a report with Category and Profit, you create a Group derived
element that combines the Books and Electronics attribute elements. You select to
include the Books attribute element and the Electronics attribute element in the All
Other derived element. This displays the derived element, as well as the individual
Books and Electronics attribute elements, as shown below.

For an attribute element to be included in the All Other derived element, all derived
elements that the attribute element is included in must be defined to include their
attribute elements in the All Other derived element. This can cause unexpected
behavior when an attribute element is included in multiple derived elements.
For example, in a report with Category and Profit, you create a Group derived
element that combines the Books and Electronics attribute elements. You create a

2017, MicroStrategy Inc. 126

In-memory Analytics Guide

second Group derived element that combines Electronics and Movies. The report is
shown below.

You select to include the attribute elements of the Books and Electronics derived
element in the All Other derived element. Notice that Books is displayed but
Electronics is not displayed, as shown below.

This is because the Electronics attribute element is also a part of the Electronics and
Movies derived element, which is defined to exclude its attribute elements in the All
Other calculation. To display the Electronics attribute element along with both
derived elements, you must define both derived elements to include their attribute
elements in the All Other derived element.
The steps below show how to define whether derived elements are displayed with their
attribute elements simultaneously.
Prerequisites
A standard report, a report connected to an active Intelligent Cube, a Grid/Graph in
a Report Services document, or a stand-alone derived element.
This procedure also assumes you have created derived elements for the report,
Grid/Graph, or stand-alone derived element.
You have the Derived Elements Editor open. For information on accessing the
Derived Elements Editor, see Accessing the Derived Elements Editor , page 103.
You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To include or exclude attribute elements in an All Other derived

element

1 In the Derived Elements Editor, select a derived element.

2 Select the Property tab.
3 Select one of the following Apply element to all other calculation options:
Do not include individual items in the All Other element

127 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Include individual items in the All Other element

These options are described in Displaying derived elements and their attribute
elements simultaneously, page 125.
4 Click OK to save your changes and close the Derived Elements Editor.

Formatting derived elements

Formatting derived elements lets you highlight important or unique data as well as
correctly reflect value and character formats for your derived elements. For example, you
may require the values of a derived element to be displayed as a percentage.
Standard formatting of attributes and metrics lets you format all data for an attribute or
metric. Formatting an attribute applies formatting to the attribute name and all of its
attribute elements. Formatting a metric applies formatting to the metric name and all of
its values across all attribute elements.
Formatting derived elements extends these features to allow you to format individual
attribute elements as well format metric values associated with individual attribute
elements.
For example, the report shown below has derived elements created for the Region
attribute.

A procedure to create the report shown above is provided in Using calculations to

create derived elements, page 112.

Notice that the derived element Greatest Regional Profit % Contribution uses derived
element formatting to apply a percentage format to the profit values for the derived
element. If you used metric formatting to apply a percentage format to profit values, the
percentage format applies to all profit values across all derived elements. But this formats
data incorrectly for the derived elements Total Profit, Average Profit, and Greatest
Regional Profit.

2017, MicroStrategy Inc. 128

In-memory Analytics Guide

In addition to applying formatting to metric values to correctly represent data for

different derived elements, you can also format the names of each derived element
individually. This gives you more flexibility than formatting attributes, which applies
formatting to all the attribute elements. This is shown in the same sample report below
with additional formatting on individual derived elements, and formatting on the
Category attribute.

Notice that each derived element name has a different format but the attribute elements
for the Category attribute all share the same format.
Formatting derived elements is only available from the Derived Elements Editor. The
procedure below describes how to format derived elements.
Prerequisites
A standard report, a report connected to an active Intelligent Cube, a Grid/Graph in
a Report Services document, or a stand-alone derived element.
This procedure also assumes you have created derived elements for the report,
Grid/Graph, or stand-alone derived element.
You have the Derived Elements Editor open. For information on accessing the
Derived Elements Editor, see Accessing the Derived Elements Editor , page 103.
You need the Define Derived Elements (Developer) and/or the Web Define Derived
Elements (Web) privileges. These privileges are part of OLAP Services.

To format derived elements

1 In the Derived Elements Editor, select a derived element.

2 From the toolbar, from the Change Group drop-down list, point to Format, and
then select from the following options:

129 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Values: Formatting the values of a derived element applies formatting to all

metric values associated with a derived element. You can use this to apply value
formats for derived elements that use formulas that return different types of data
such as percentages, fractions, or other unique formats. In the report shown
below, the derived element values for the various derived elements are
highlighted with a solid red box, for the purpose of this example.
Be aware that formatting a derived elements values only applies to the metric
values associated with the derived element. For example, the first four profit
values are associated with the Total Profit derived element.
Headers: Formatting the headers of a derived element applies formatting to the
derived element name. You can use this to highlight or visually distinguish the
various derived elements on the report.
In the report shown below, the derived element headers for the various derived
elements are highlighted with a dashed black box, for the purpose of this
example. Be aware that formatting a derived elements header only applies to the
derived element you are formatting, not all derived elements for an attribute.

The Format Cells dialog box opens.

3 Apply number, alignment, font, border, and background formatting for the derived
element values or headers. For steps to use the Format Cells dialog box, click the
Help on the Format Cells dialog box.
4 When you are finished formatting derived elements headers or values, click OK. You
are returned to the Derived Elements Editor.
5 Click OK to save your changes and close the Derived Elements Editor.

2017, MicroStrategy Inc. 130

In-memory Analytics Guide

Interaction with other reporting features

The derived elements feature is just one of the many reporting and analysis features
available with MicroStrategy. How you use derived elements in combination with other
reporting and analysis features can affect the behavior and results of your reports and
documents. For information on how derived elements interact with other MicroStrategy
features, see the following sections:
Derived element interactions with view filters, page 131
Derived element interactions with derived metrics, page 131
Derived element interactions with page-by, page 133
Derived element interactions with thresholds, page 135
Derived elements and drilling on reports, page 136
Derived element interactions with subtotals, page 138
Derived elements in Report Services documents with multiple datasets, page 138
Derived elements in Report Services documents with multiple datasets, page 138

Derived element interactions with view filters

View filters restrict the amount of data displayed on the report, providing you with a
different view of the data. For information on the full set of view filter functionality, see
Chapter 7, View Filters.
View filters restrict the same data which is used by derived elements to analyze and
display data to meet your reporting needs. Since both of these OLAP Services features
use the same data, it is important to understand how the two features can be used
together to return desired report results. For information on view filter effects on derived
elements and other reporting features, see View filter effects on reporting features, page
186.

Derived element interactions with derived metrics

Most derived metrics are represented correctly when used with derived elements.
However, some derived metrics can be calculated incorrectly when using derived
elements, due to the order in which derived elements and derived metrics are calculated.
For example, a derived metric that uses a division, such as Profit/Revenue, is
calculated incorrectly when using derived elements. This is because, by default, derived
metrics are evaluated before derived elements. You must change the evaluation order to
evaluate derived elements before this type of derived metric.
For example, the report shown below includes the Region attribute with East Coast, West
Coast, and Central and South derived elements defined on it. The metrics are Revenue,
Profit, and Profit Margin.

131 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Profit Margin is a derived metric, with the definition Profit/Revenue. Notice that the
values for Profit Margin are much higher than they should be for the derived elements,
but the value for the Web attribute element is correct. This is because Profit Margin is
calculated for the individual attribute elements, before the attribute elements are
combined to display the derived elements.
By evaluating the derived elements before the Profit Margin derived metric, the correct
Profit Margin values are displayed for all derived elements and attribute elements.

The following procedures show you how to modify the evaluation order of derived
elements:
To modify the evaluation order of derived elements in reports, page 132
To modify the evaluation order of derived elements in Grid/Graphs in Report
Services documents, page 133

To modify the evaluation order of derived elements in reports

1 In Developer, log in to a project that includes a report with derived elements and
derived metrics.
2 Browse to and right-click a report, and select Run. The report is executed in the
Report Editor.
3 From the Data menu, select Report Data Options. The Report Data Options
dialog box opens.
4 Expand the Calculations category, and then select Evaluation Order.
5 Clear the Use default evaluation order check box. This displays all objects on
the report that can have their evaluation order modified.
6 In the Evaluation Order column, select the evaluation orders for each object in
the report.

2017, MicroStrategy Inc. 132

In-memory Analytics Guide

Objects are evaluated from lowest evaluation order number to highest. However, if
you define an object to use Default as its evaluation order, it may be evaluated before
an object with an evaluation order of 1.
For example, if you define a derived element with an evaluation order of 1 and a
derived metric with an evaluation order of Default, the derived metric is evaluated
first. This is because derived metrics are evaluated before derived elements by default.
To evaluate a derived element before a derived metric, define the derived metric to
have a higher evaluation order than the derived element.
7 Click OK to save your changes and close the Report Data Options dialog box. The
changes to the evaluation order are displayed in the report. To view the evaluation
order of the various objects on the report, display the report in SQL View.

To modify the evaluation order of derived elements in Grid/Graphs in

Report Services documents

1 In Developer, log in to a project that includes a report with derived elements.

2 Browse to and right-click a document, and select Edit. The document opens in the
Document Editor.
3 Double-click the Grid/Graph that contains the derived element to enter Edit mode.
4 From the Data menu, select Grid Data Options. The Grid Data Options dialog
box opens.
5 Expand the Calculations category, and then select Evaluation Order.
6 Clear the Use default evaluation order check box. This displays all objects on
the report that can have their evaluation order modified.
7 In the Evaluation Order column, select the evaluation orders for each object in
the report.
Objects are evaluated from lowest evaluation order number to highest. However, if
you define an object to use Default as its evaluation order, it may be evaluated before
an object with an evaluation order of 1.
For example, if you define a derived element with an evaluation order of 1 and a
derived metric with an evaluation order of Default, the derived metric is evaluated
first. This is because derived metrics are evaluated before derived elements by default.
To evaluate a derived element before a derived metric, define the derived metric to
have a higher evaluation order than the derived element.
8 Click OK to save your changes to close the Grid Data Options dialog box.
9 To view the updated Grid/Graph, run the document.

Derived element interactions with page-by

To group data into subsets, you can use the page-by feature. The subsets you separate
your business data into are called pages, and you then page your way through the report,

133 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Page-by makes viewing a large report easier than scrolling through long lists of data.
Attributes are one of the most common objects included in the page-by area of a report.
When an attribute is included in the page-by area, you can select which attribute element
to view data for.
For example, the report below on the left includes the attributes Region and Category,
along with the Profit metric. The Region attribute is included in the page-by area, and
Central is selected by default. The report below on the right displays all the attribute
elements available in the page-by area.

If you create derived elements for an attribute included in the page-by area, the derived
elements are available from the page-by field to display their associated data.
For example, the report below shows East Coast, West Coast, and Central and South
derived elements based on the Region attribute.

If Region is moved to the page-by area, the derived elements are available for selection
from the page-by field, along with the Web attribute element, as shown below.

2017, MicroStrategy Inc. 134

In-memory Analytics Guide

You must move attributes from the page-by area to the grid of the report to create
or modify derived elements for the attribute. You can then move the attribute back
to the page-by area once all derived element modifications are complete.

Page-by is covered in greater detail in the MicroStrategy Basic Reporting Guide.

Derived element interactions with thresholds

Thresholds highlight particular data in a report by displaying special cell formats,
symbols, images, or replacement text.
Thresholds are created using conditions on attributes or metrics. Thresholds created
using conditions on individual attributes are not displayed for derived element data.
However, the more commonly used thresholds created using conditions on metrics are
applied to derived element data.
For example, the report below shows East Coast, West Coast, and Central and South
derived elements based on the Region attribute.

You create two thresholds, the first defined on a metric and the second defined on an
attribute, as shown in the following image.

135 2017, MicroStrategy Inc.

 In-memory Analytics Guide

When the report is executed, only the Profit > 400000 threshold is displayed, as shown
below.

The Profit > 400000 threshold uses the derived element data to determine when to
display the defined formatting.
However, the formatting for the Central and South threshold is not displayed. This is due
to the fact that the separate Central and South attribute elements are not on the report,
and are instead replaced with a Central and South derived element. While you cannot
display this type of threshold formatting for derived elements, you can still apply
formatting to the data for each derived element, as described in Formatting derived
elements, page 128.
Thresholds are covered in greater detail in the MicroStrategy Basic Reporting Guide.

Derived elements and drilling on reports

Drilling allows you to view displayed report data at levels other than that returned in the
original grid or graph report. You can investigate the data in your report quickly and

2017, MicroStrategy Inc. 136

In-memory Analytics Guide

easily with the help of drilling. It allows you to execute another report based on the
original report to get more detailed or supplemental information.
When you drill on attribute elements in a report, the resulting report restricts the results
to data only for the attribute elements used when drilling. For example, if you drill from
the Year 2007 attribute element down to Quarter, the resulting report only includes
quarters that are within 2007.
The same standard applies to drilling on derived elements. Drilling on a derived element
restricts the resulting report to only data for the attribute elements used to define the
derived element.
For example, the report below shows East Coast, West Coast, and Central and South
derived elements based on the Region attribute.

If you drill down from the East Coast derived element to Call Center, the resulting report
shown below returns data for Call Centers within the East Coast regions (Northeast, Mid-
Atlantic, Southeast).

137 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Drilling is covered in greater detail in the MicroStrategy Basic Reporting Guide.

Derived element interactions with subtotals

You can define how derived elements are applied to subtotals, which is described in
Applying derived element values to subtotals, page 121.

Derived elements in Report Services documents with

multiple datasets
A Report Services document may contain multiple datasets. The dataset reports that you
use may contain derived elements on the same attribute. If the attribute is added to a
Grid/Graph in the document, derived elements from all reports are displayed on the
Grid/Graph, as well as any elements that are not part of the derived elements, as
described in the example below.

Example: derived elements in documents with multiple datasets

A document uses two reports as datasets, defined as follows:

2017, MicroStrategy Inc. 138

In-memory Analytics Guide

Dataset 1 is a Regional Profit report, containing the Region attribute and the Profit
metric. The derived element Western Regions is defined on Region, with the
following elements:
Northwest
Southwest
The dataset is shown in the image below.

Dataset 2 is a Regional Revenue report, containing the Region attribute and the
Revenue metric. The following derived elements are defined on Region:
Northern Regions, containing the Northwest and Northeast elements.
Central and Mid-Atlantic, containing the Central and Mid-Atlantic elements.
The dataset is shown in the image below.

In the document, a Grid/Graph is created, and the following objects are added to it:
Region
Profit
Revenue

139 2017, MicroStrategy Inc.

 In-memory Analytics Guide

When the document is executed, the data from both datasets is combined, and derived
elements from both datasets are displayed on the combined Grid/Graph, as shown in the
image below:

For attribute elements that are not part of a derived element, such as South and
Southeast, data from both datasets is combined and displayed.
If your datasets contain derived elements with the same name, and containing the same
attribute elements, the data for the derived elements is combined and displayed in a
single row.
For detailed instructions to use documents with multiple datasets, refer to the Document
Creation Guide.

2017, MicroStrategy Inc. 140

 6
DERIVED METRICS
Creating Metrics On The Fly
A derived metric is a calculation based on the data included in the report definition. You
can use derived metrics to perform column math, for example, calculations on metrics
included in the report definition, without regenerating or re-executing SQL against the
data warehouse.
Derived metrics are easy to create and can be made on the fly when you are viewing a
report. A typical case is to create a derived metric to perform calculations between
columns of metric data. For example, a derived metrics can subtract the data of one
metric by the data of another metric (Metric1 - Metric2) to obtain a new metric
calculation.
To see how derived metrics can be used in reports, consider the Derived Metric report
from the MicroStrategy Tutorial project. The report includes a derived metric that is
defined as Revenue/1000, which returns the Revenue values in thousands of dollars, as
shown below.

Notice that in the Report Objects pane to the left of the report (and shown below), the
derived metric is preceded by an fx symbol, instead of the usual metric symbol, meaning
this is a new metric based on the existing metrics in the report.

2017, MicroStrategy Inc. 141

In-memory Analytics Guide

Since derived metrics are created within a report, they can only be used for the report in
which they are created. Derived metrics cannot be saved as individual objects in the
project, and therefore cannot be applied to other reports in the project.
This chapter discusses the following topics on derived metrics:
Creating a derived metric, page 142
Editing derived metrics, page 155
Formatting derived metrics, page 155
Deleting derived metrics, page 155
View filter effects on derived metrics, page 156
Derived element effects on derived metrics, page 156

Creating a derived metric

Derived metrics can be created in the following:
As part of the design or analysis of a report. This allows you to create these metrics
while focusing on a given report.
You can create a derived metric in any report. This includes reports connected to an
Intelligent Cube, reports returning information directly from a data warehouse,
Freeform SQL reports returning information from an Excel spreadsheet, and so on.
In Report Services documents. You can define a derived metric based on one or
more metrics from the documents datasets. For instructions to create derived
metrics in Report Services documents, refer to the Document Creation Guide.
In Visual Insight dashboards. You can quickly and easily add simple derived metrics
to a Visual Insight (VI) dashboard on the fly. For instructions to create derived
metrics in VI dashboards, see the MicroStrategy Web Help.

Best practices
Follow the guidelines below when creating derived metrics:

142 2017, MicroStrategy Inc.

 In-memory Analytics Guide

In reports, you can define derived metrics with objects in the Report Objects pane.
The Report Objects are the components included in the report definition, even if
they are not displayed on the report grid.
A derived metric can be defined with the metrics in the report definition. The Input
Metric Formula dialog box where you create derived metrics allows you to choose
only from objects included in the report definition, as shown below.

Attributes included in the report definition are also available to use in the definition
of a derived metric. If you use an attribute as part of the metric definition, the metric
calculation requires new report SQL to be executed against the data warehouse. This
re-execution is not required for derived metrics that only use metrics in their
definitions.
You can use one or more functions or operators in the formula of the derived metric.
Click the fx button to access available functions and operators.
You can use numeric prompts in the formula of the derived metric, which allows
users to determine part of the value of the metric. For example, if the value of your
metric depends on the current tax rate, you can prompt users to type the current tax
rate.
For steps to create prompts, see the Basic Reporting Guide.
You can change the level at which a derived metric is calculated. For example, the
derived metric sum(M1) {Attribute1} is calculated at the Attribute1 level. For
information on metric levels, see the Advanced Reporting Guide.
Any user can modify a derived metric after report execution, since its formula is
visible to all users. If a derived metric should not be modified by end users, create the
metric in the Metric Editor and add it to the report as a normal metric.
Transformation objects cannot be used with derived metrics because they require
SQL to be re-executed against the data warehouse.
View filters can filter the results of a derived metric. A view filter is an additional
filter applied in memory to the report results to restrict the amount of data displayed
on the report. For more information on view filters, see Chapter 7, View Filters.

2017, MicroStrategy Inc. 143

In-memory Analytics Guide

A derived metric is dependent on any report objects that are included in the derived
metrics definition. Because of this dependency, you cannot remove an object from
the report that is used in a derived metric definition.
If you try to remove an object from the report, a message is displayed that indicates
you cannot remove the object because it is being used by the derived metric. You can
however move an object off the report grid so that it only appears in the Report
Objects pane. This allows you to hide the object from the report grid and still support
any derived metrics that are dependent on it.
In Report Services documents that use multiple datasets, you can create derived
metrics that use metrics from different datasets. If you do so, note the following:
The metrics you use may be calculated at different levels, depending on the
definition of the datasets. For example, one dataset contains the Subcategory
attribute and the Revenue metric, and another dataset contains the Category
attribute and the Profit metric. If you create a derived metric based on Revenue
and Profit, note that Revenue is calculated at the Subcategory level, and Profit is
calculated at the Category level. This can be useful to create percent-to-total
metrics.
If the derived metric is to be used in a data field, it is recommended that you use
a calculated expression instead.
For information and examples of using derived metrics in documents with multiple
datasets, refer to the Document Creation Guide.
You can create derived metrics with the following methods described in this section:
Quickly creating a derived metric in Web, page 144: You can create a derived metric
based on often-used functions, such as Average, by using the Insert Metric feature in
Web.
Creating a derived metric using the Input Metric Formula dialog box, page 145:
You can create any type of derived metric by defining derived metric expressions
using the Input Metric Formula dialog box.
Using rank and percent-to-total metric analysis , page 149: You can quickly create
derived metrics that display the percent in relation to a selected total of each item
affected by the metric or display a ranking number to the metric values for a given
attribute. These can be quickly created using shortcut metrics.

Quickly creating a derived metric in Web

You can quickly create a derived metric based on an attribute or metric, using the Insert
Metric function in MicroStrategy Web. For example, Customer is an attribute, and you
want to create a metric that counts the number of distinct customers.
You can use the Insert Metric function to create a derived metric that uses one of the
following functions:
Average
Count
Maximum

144 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Minimum
Sum
For steps to create a derived metric using any other function, see Creating a derived
metric using the Input Metric Formula dialog box, page 145.

To quickly create a derived metric in Web

1 Open a report or document in MicroStrategy Web.

2 In the Report Objects or Dataset Objects pane, as applicable, right-click the object
that you want to base the metric on. For example, if you want to create a metric that
counts the number of customers, right-click Customer.
3 Select Insert Metric, and click the function that you want to use for the metric.
The metric is created, and is shown in the Report Objects or Dataset Objects pane, as
applicable.
4 Drag the metric on to the report or document, as applicable.
5 Click Save to save your changes.

Creating a derived metric using the Input Metric

Formula dialog box
The Input Metric Formula dialog box allows you to use functions, operators, and report
objects to create derived metrics. You can create any type of derived metric by defining
derived metric expressions using the Input Metric Formula dialog box. This includes
shortcut metrics that are described in Using rank and percent-to-total metric analysis ,
page 149.
The procedure below describes the high-level steps for creating a derived metric with the
Input Metric Formula dialog box. For an example of creating a derived metric, see
Example: Average profit per customer with transactions, page 146.
Prerequisites
You need the Create Derived Metrics (Developer) and/or the Web Create Derived
Metrics (Web) privileges. These privileges are part of OLAP Services.

To create a derived metric with the Input Metric Formula dialog box

For details on each option for any of the steps below, click Help.
1 Open a report in MicroStrategy Developer or Web.
2 Open the Input Metric Formula dialog box to create a new metric by performing one
of the following steps:
In Developer: From the Insert menu, select New Metric.
In Web: From the Data menu, select Insert New Metric.

2017, MicroStrategy Inc. 145

In-memory Analytics Guide

3 The pane on the left displays the Report Objects, which shows the components
(attributes, attribute forms, metrics, custom groups, consolidations, and so on)
included in the report, even if the components are not displayed in the report grid.
In Developer: Double-click or drag-and-drop an object to use it to define the
derived metric.
In Web: Select an object and click the arrow to use it to define the derived
metric. This moves the object to the window on the right.
4 Add functions and operators by typing their syntax or characters. You can also click
the fx button to open the Insert Function Wizard, which guides you through adding
functions and operators.
5 Continue to add report components, functions, operators, constant values, and other
valid metric formula objects to complete your formula.
6 To add the level at which to calculate the metric, enclose the metric formula in
parentheses. Type the attribute name between curly braces {} after the metric
formula. If the attribute name contains a space, enclose the name within brackets
[]. For example, ([Unit Cost] * [Units Sold]) {[Customer Name]},
where Unit Cost and Units Sold are metrics and Customer Name is an attribute. This
is a valid expression.

For more information on metric levels, see the Advanced Reporting Guide.

7 After you have created the expression, you can determine whether the expression is
valid by performing one of the following steps:
In Developer: Click Validate. An error is displayed if the expression is invalid.
In Web: Click Apply. An error is displayed if the expression is invalid.
8 In the Metric Name (Developer) or Name (Web) field, enter a name for the new
metric.
When naming a MicroStrategy object, you must follow the naming convention rules
for your particular database platform. Using a word reserved by your database
platform can result in an error when the report is executed. Refer to your database
documentation for a list of these database-reserved words.
9 Click OK to create the new derived metric for your report. The Input Metric
Formula dialog box closes and the derived metric is added to the report.
To format the values or headers of a derived metric, see Formatting derived metrics,
page 155.

Example: Average profit per customer with transactions

In this example, a derived metric is created for the Customer Profitability - By
Tenure report from the Customer Analysis Module. This report provides monthly
trends in customer information based on tenure, as shown below.

146 2017, MicroStrategy Inc.

 In-memory Analytics Guide

A derived metric is created to display the average profit generated per customer with
transactions. The procedure below describes how to create and format this derived
metric for the report shown above.
Prerequisites
You need the Create Derived Metrics (Developer) and/or the Web Create Derived
Metrics (Web) privileges. These privileges are part of OLAP Services.

To create an average profit per customer with transactions derived

metric

1 In MicroStrategy Developer, log in to the Customer Analysis Module.

2 Browse to the Customer Profitability - By Tenure report, right-click the report,
and then select Run Report. The Choose from all elements of Quarter
prompt opens.
3 Keep the default prompt answer of 2007 Q4, and click Finish. The Customer
Profitability - By Tenure report opens in Grid View.
4 From the Insert menu in the Report Editor, select New Metric. The Input Metric
Formula dialog box opens.
5 In the Metric Name field, type Average Profit Per Customer with
Transactions.

To create the expression for the derived metric

You create this expression using the following steps:

2017, MicroStrategy Inc. 147

In-memory Analytics Guide

(Profit / [Customers with Transactions])

6 Drag-and-drop the Profit metric from the list of Report Objects in the left pane to
the metric definition area on the right.
7 Click the division sign (/) on the operators and functions toolbar. The division sign
should be inserted to the right of the Profit metric.
8 Drag-and-drop the Customer with Transactions metric from the list of Report
Objects to the metric definition area on the right. It should be placed on the right
side of the division sign (/).
9 Click Validate. A green check is displayed in the right-hand corner below the
metric definition area, indicating that the metric definition is valid.
10 Click OK to return to the report. The new metric column for the derived metric is
displayed in the report.

To format the values of the new derived metric

The metric is included without any value formatting. Follow the steps below to
format the metric values to be displayed with a currency format.
11 Right-click the Average Profit per Customer with Transactions derived
metric, point to Formatting, and select Average Profit per Customer with
Transactions Values. The Format Cells dialog box opens.
12 On the Number tab, from the Category pane, select Currency.
13 Keep all defaults for the Currency format and click OK. You are returned to the
report, which is shown below.

148 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Using rank and percent-to-total metric analysis

You can create derived metrics that display the percent in relation to a selected total of
each item affected by the metric or display a ranking number to the metric values for a
given attribute.
These can be quickly created using shortcut metrics. Shortcut metrics are a set of quick
metrics you can create on the fly for a given report, based on the metrics already in the
report. Shortcut metrics include:
Percent-to-total shortcut metrics, which display the percent in relation to a selected
total of each item affected by the metric. To create this type of shortcut metric, see
Creating a percent-to-total shortcut metric, page 149.
Rank shortcut metrics, which apply a ranking number to the metric values for a
given attribute. To create this type of shortcut metric, see Creating a rank shortcut
metric, page 152.
Transformation shortcut metrics, which apply offset values, such as four months
ago, to an attribute that you select.
All the shortcut metrics are derived metrics, except for transformation shortcut metrics.
Transformation shortcut metrics must be calculated in SQL and are therefore only
available to users that have the Modify the List of Report Objects (Use Object Browser)
privilege. Because they must be calculated, the report re-executes to display the new
metric. Transformation metrics are not covered in this guide, see the Advanced
Reporting Guide. Reports are not re-executed when other shortcut metrics are created.

Creating a percent-to-total shortcut metric

A percent-to-total shortcut metric displays the percent in relation to a selected total of
each item affected by the metric. Use a percent-to-total shortcut metric to show cell-level
values as percents of an accumulated row or column total. The metric can also show a
total by page, show a total for each value of the attribute, or show the grand total.
For example, a report contains Sales Region, Sales Representative, and the Revenue by
Sales Representative metric as shown below.

2017, MicroStrategy Inc. 149

In-memory Analytics Guide

Along with revenue totals for each sales representative, you can also highlight a sales
representatives percent contribution to revenue for their sales region, as well as
company-wide. You insert two percent-to-total shortcut metrics to display this
information, as shown in the report below:

This report provides analysis into sales representatives performances at both the regional
and company-wide level.

150 2017, MicroStrategy Inc.

 In-memory Analytics Guide

The following rules apply to percent-to-total shortcut metrics:

Row and column percent-to-totals refer to the extreme-left and topmost positions,
respectively.
Page percent-to-totals affect all attributes on a page.
Percent to All -> A1, where A1 is an attribute, indicates that the calculation is
performed across all elements of that attribute. An example is percent to all stores.
If a report does not contain attributes at a given percent-to-total level, the level is
unavailable for that report.
In some cases, two or more percent-to-total calculations at different logical levels
yield the same result. For example, Percent-to-Page Total data can be the same as
Percent-to-Grand Total data in a single-page report.
The level of a percent-to-total shortcut metric remains constant once the metric has
been calculated; subsequent manipulation of objects on the report does not affect it.
The steps below show you how to create a percent-to-total shortcut metric.
Prerequisites
You need the Create Derived Metrics (Developer) and/or the Web Create Derived
Metrics (Web) privileges. These privileges are part of OLAP Services.

To create a percent-to-total shortcut metric

1 Open a report in MicroStrategy Developer or Web.

2 Right-click the metric to see data displayed as percents of a total, point to Insert
(Developer) or Insert Metric (Web), point to Percent to Total, and then select
the portions of the report for which percent-to-total data is to be calculated. Options
are:
Over Rows: Displays values in each row of the report as percents of an
attribute row total. Row percent-to-totals refer to the attribute in the extreme-
left position. This option is best suited for reports that display attributes in the
rows and metrics in the columns.
Over Columns: Displays values in each column as percents of an attribute
column total. Column percent-to-totals refer to the attribute in the topmost
position. This option is best suited for reports that display attributes in the
columns and metrics in the rows.
Page Total: Displays all values on a page as percents of that page's total. This
option is available only on reports that include an object in the page-by area.
Grand Total: Displays all values in a report as percents of the grand total for
that report.
Total for each: Displays all values pertaining to a given report component (an
attribute, for example) as percents of the total accumulated for that component.

2017, MicroStrategy Inc. 151

In-memory Analytics Guide

The report is updated showing your new shortcut metric that displays the percent-to-
totals for the components selected. To edit a shortcut metric, see Editing derived
metrics, page 155. To format the values or headers of a derived metric, see Formatting
derived metrics, page 155.

Creating a rank shortcut metric

A rank shortcut metric applies a ranking number to the metric values for a given
attribute. Use the rank function to show the relative position of a given cell content in
relation to other values for a report component. The rank shortcut metric provides
break-by options for each attribute on the report.
For example, a report contains Sales Region, Sales Representative, and the Revenue by
Sales Representative metric as shown below.

Along with revenue totals for each sales representative, you can also highlight sales
representatives relative performances company-wide. You insert a rank shortcut metric
to display this information, as shown in the report below:

152 2017, MicroStrategy Inc.

 In-memory Analytics Guide

This report provides analysis into sales representatives relative performances company-
wide. If you use Sales Region as a break-by, employees would be ranked within their sales
regions.
By default, a rank shortcut metric ranks values from low to high in ascending order.
Therefore, the lowest value has a rank of 1 and the highest value has a rank equal to the
total number of items being ranked within a given break-by grouping. You can change
the metric to rank in descending order by editing the metric.
Refer to the procedure below for steps to create a rank shortcut metric.
Prerequisites
You need the Create Derived Metrics (Developer) and/or the Web Create Derived
Metrics (Web) privileges. These privileges are part of OLAP Services.

To create a rank shortcut metric

1 Open a report in MicroStrategy Developer or Web.

2 Right-click the metric to rank, point to Insert (Developer) or Insert Metric
(Web), point to Rank, and then select the break by value from the list. You have the
following options:
Break by None: No break by is used and the rank is calculated accounting for
each separate item on the report.
Break by Object: A break by on Object is used to calculate the rank. For
example, a report contains Region, Employee, and the Revenue metric. You

2017, MicroStrategy Inc. 153

In-memory Analytics Guide

select to Break by Region. Each employee is ranked within their region; that
is, each region has a separate ranking.
3 If you are creating a rank shortcut metric in MicroStrategy Web, you must choose
from the following sort orders:
Ascending: Values are ranked from least to greatest in ascending order.
Therefore, the smallest value has a rank of 1 and the largest value has a rank
equal to the total number of items being ranked within a given break-by
grouping.
Descending: Values are ranked from greatest to least in descending order.
Therefore, the largest value has a rank of 1 and the smallest value has a rank
equal to the total number of items being ranked within a given break-by
grouping.
In Developer, by default, a rank shortcut metric ranks values from low to high in
ascending order. You can change the metric to rank in descending order by editing
the metric, as described in To change the ranking order of a rank shortcut metric,
page 154.
The report is updated showing your new shortcut metric that displays the ranking for the
components selected. To edit a shortcut metric, see Editing derived metrics, page 155.
To format the values or headers of a derived metric, see Formatting derived metrics,
page 155.

To change the ranking order of a rank shortcut metric

When creating rank shortcut metrics in Developer, a rank shortcut metric ranks values
from low to high in ascending order. You can change the metric to rank in descending
order by editing the metric, as described in the steps below.
Prerequisites
You need the Create Derived Metrics (Developer) and/or the Web Create Derived
Metrics (Web) privileges. These privileges are part of OLAP Services.

To change the ranking order of a rank shortcut metric

1 In MicroStrategy Developer, open a report that contains a rank shortcut metric.

2 Right-click the rank shortcut metric and select Edit. The Input Metric Formula
dialog box opens and displays the metric formula.
3 Modify the ranking order by modifying the ASC=ranking_order parameter, as
described below:
ASC=True: (Default) Values are ranked from least to greatest in ascending
order. Therefore, the smallest value has a rank of 1 and the largest value has a
rank equal to the total number of items being ranked within a given break-by
grouping.

154 2017, MicroStrategy Inc.

 In-memory Analytics Guide

ASC=False: Values are ranked from greatest to least in descending order.

Therefore, the largest value has a rank of 1 and the smallest value has a rank
equal to the total number of items being ranked within a given break-by
grouping.
4 Click Validate to confirm that the metric definition is valid for use by the
MicroStrategy engine.
5 Click OK to return to the Report Editor or Report Viewer. Any rank ordering
changes are displayed in the report.

Editing derived metrics

To change the definition of a derived metric after the metric is applied to a report, right-
click the derived metric and select Edit. The Input Metric Formula dialog box is
displayed. From this dialog box, you can modify the metrics definition as needed. For
details on any option, click Help. Click OK after you finish, and the modified metric
definition is calculated and displayed on the report instantly without having to re-execute
the report against the data warehouse.
For an example using the Input Metric Formula dialog box, see Creating a derived
metric using the Input Metric Formula dialog box, page 145.

Formatting derived metrics

The same formatting options for regular metrics are available for derived metrics.
You can format the metric headers and values for a derived metric included on the report
grid. To format a derived metric, right-click the derived metric on the grid, point to
Formatting, and select the derived metrics headers or values. The Format Cells dialog
box opens to modify the derived metric formatting. For details on each formatting
option, click Help. For an example of creating and formatting a derived metric, see
Example: Average profit per customer with transactions, page 146.
You can also use thresholds with derived metrics in the same ways you can use
thresholds with standard metrics created with the Metric Editor. Thresholds are used to
create conditional formatting for metric values. To open the Threshold dialog box for a
derived metric, right-click the derived metric on the report grid and select Thresholds.
For more information on thresholds, see the MicroStrategy Basic Reporting Guide.

Deleting derived metrics

Once a derived metric is created, it becomes part of the report and is saved with the
other objects in the report. If you do not want the derived metric to be on the grid but
want to keep it in the report definition, you can right-click it in the grid and select
Remove from Grid. This action is shown in the image below. The metric is taken off
the grid and is no longer bold in the Report Objects pane.

2017, MicroStrategy Inc. 155

In-memory Analytics Guide

If you do not want the derived metric to be saved as part of the report, you can delete it
from the report completely by right-clicking the derived metric and selecting Remove
from Report.
If the derived metric is included in the definition of another derived metric on the
report, an error message is displayed. To delete the derived metric from the report, you
must remove or modify any derived metrics that are dependent on the derived metric
you are attempting to delete.

View filter effects on derived metrics

Derived metrics calculate their values using the results in a report. Since view filters
restrict the report results, view filters can have an effect on derived metrics. For
information on view filter effects on derived metrics and other reporting features, see
View filter effects on reporting features, page 186.

Derived element effects on derived metrics

Most derived metrics are represented correctly by derived elements. However, note the
following:
In reports, a derived metric that uses division, such as Profit/Revenue, is initially
calculated incorrectly when using derived elements. This is because, by default,
derived metrics are evaluated before derived elements. You must change the
evaluation order to evaluate derived elements before this type of derived metric. For
information on derived element effects on derived metrics and how to evaluate them
correctly, see Derived element interactions with derived metrics, page 131.
In Report Services documents that use multiple datasets, if you create a derived
metric that uses metrics from two or more datasets, the derived metric may display
unexpected results for derived elements on Grid/Graphs. To ensure that such derived
metrics are evaluated correctly, you must change the evaluation order to evaluate
derived elements before this type of derived metric. For information on derived

156 2017, MicroStrategy Inc.

 In-memory Analytics Guide

element effects on derived metrics and how to evaluate them correctly, see Derived
element interactions with derived metrics, page 131.

2017, MicroStrategy Inc. 157

 7
VIEW FILTERS
Filtering Data On The Fly
A view filter restricts the amount of data displayed on the report, providing you with a
different view of the data. This new view can provide a new business perspective for
analysis, without having to re-execute the reports SQL against the data warehouse.
For example, you have a report with Region, Category, and Profit displayed, as shown in
the report below.

2017, MicroStrategy Inc. 158

In-memory Analytics Guide

After a view filter is applied, the resulting report below includes the following view filter
qualifications:
Region In list {Northwest, Southwest}: This qualification restricts the report results
to display data only for the Northwest and Southwest regions.
Profit Greater than 15000: This qualification restricts the report results to display
data only for product categories in the Northwest or Southwest regions that had
greater than $15,000 in profits.
The view filters definition is displayed above the report, as shown below.

159 2017, MicroStrategy Inc.

 In-memory Analytics Guide

The following table lists scenarios where you can use view filters to best support your
business model and enhance the analysis of your reports.

Analysis Capability Example

Modify the data displayed without re- Adding, deleting, or modifying view filters are all
executing SQL against the data warehouse. executed against a report in memory.
Allow multiple users to create separate Multiple users can define individual view filters to
views of data on a single report in memory. further restrict the data of a report connected to a
shared Intelligent Cube.
Filter on attributes included in the report. With the attribute Year on a report, you can use a view
filter to determine which years of data to display on the
report.
Perform attribute-to-attribute comparisons. With the attributes Customer City and Store City on a
report, you can specify that Customer City be the same
as the Store City. This can give a view of how a store is
performing with local customers.
Filter on metrics included in the report. The With the metric Profit on a report, you can filter on Profit
output level for the filter can be applied at greater than or equal to $1,000,000.
the report level or the level of the attributes
displayed on the report.
Perform metric-to-metric comparisons. With Revenue and Operating Cost metrics on a report,
you can specify that Revenue be greater than or equal
to Operating Cost.
Filter on attributes or metrics that are not You can drag-and-drop the Profit metric from the report
displayed on the report. grid to the Report Objects pane. This removes the Profit
metric from the display, but any view filters based on
that object are still calculated.

This chapter discusses the following topics related to view filters:

Comparing view filters to report filters and report limits, page 161
Creating a view filter, page 165
Deleting a view filter, page 186

2017, MicroStrategy Inc. 160

In-memory Analytics Guide

View filter effects on reporting features, page 186

Comparing view filters to report filters and

report limits
Filtering reports restricts the data displayed to highlight the data that is of greatest
interest or is most applicable to the area of analysis. In addition to view filters, you can
also use report filters and report limits to filter data on reports. To decide when to use a
view filter, report filter, or report limit, you must understand the advantages and
implications of each feature. For a detailed comparison between view filters and other
standard MicroStrategy features, see the following sections:
View filters versus report filters , page 161
View filters versus report limits, page 164

View filters versus report filters

While they both share some filtering capabilities, view filters and report filters also offer
their own unique filtering features that fit different filtering requirements.
The main difference between report filters and view filters is how they are evaluated by
the system.
Report filters are a standard MicroStrategy reporting feature that enable you to filter the
data retrieved from the data source. Since report filters are evaluated by querying the
data source, report filters can perform various types of advanced qualifications, use
prompts in qualifications, filter on objects not included in the report, and so on. For
more information on report filters in general, refer to the Basic Reporting Guide and
Advanced Reporting Guide.
View filters are an OLAP Services feature that enable you to filter the data available on a
report after its data has been retrieved from a data source. View filters are evaluated
without having to query the data source. While this enables view filters to be evaluated
without the overhead of querying the data source, it also means that view filters only
have access to the data available on the report. Due to this limited access to data, view
filters cannot perform all of the advanced qualifications possible with report filters.
The table below compares the available features and feature requirements of view filters
and report filters:

Features and Feature Requirements Available in Available in

View Filters Report Filters

Attribute element and attribute form qualifications Yes Yes

Simple metric qualifications Yes Yes
Relationship qualifications No Yes

161 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Features and Feature Requirements Available in Available in

View Filters Report Filters

Joint element list qualifications No Yes

Custom expression qualifications No Yes
Can define filtering at report run time by including a prompt in a No Yes
qualification
Can filter on objects not included in the Report Objects pane No Yes
(See Example: Report filter on an attribute not in the report, page185)
Can filter on objects included in the Report Objects pane, but not Yes Yes
included in the report
(See Example: Report filter on an attribute not in the report, page185)
Evaluated without re-executing SQL and querying the data source Yes No

Can be saved as a stand alone object and used in multiple reports No Yes
Can quickly switch the level at which the qualification is evaluated from Yes No
report level to the level of attributes displayed on the report
Can be modified while viewing the report data Yes No

Design considerations
The decision to use a view filter or a report filter to answer your business questions relies
on two key factors, functionality and system management.
View filters and report filters both provide a rich set of filtering functionalities, which
can be used to answer your business questions. However, since report filters are executed
against the data warehouse, more advanced filtering is supported. You may need to use a
report filter to implement some of your more advanced business questions. For example,
you can define a report filter at report run time by including a prompt in the filter
definition. For a list of features supported by report filters that are not supported for view
filters, see View filters versus report filters , page 161.
From a system management perspective, report filters and view filters provide two
alternatives that affect memory and data warehouse usage.
Report filters help to reduce the memory size of reports by returning less data from the
data warehouse. These results can be stored in a cache that decreases the time it takes to
access and run the report. The drawback to this approach is that any modifications to
the report filter cause the system to access the data source again to create a new report
definition, which must be stored in the cache in place of the old definition. The cache
still provides quick access to the new report, but this process causes an extra load on the
system.
View filters can help reduce memory used by reports, by utilizing Intelligent Cubes.
Intelligent Cubes are sets of data that can be shared as a single in-memory copy, among
many different reports created by multiple users. Filtering on reports connected to
Intelligent Cubes is only achievable with view filters. View filters provide much of the

2017, MicroStrategy Inc. 162

In-memory Analytics Guide

same filtering functionality as report filters, while allowing multiple users to perform
analysis on a single Intelligent Cube.

Example: Report filter on an attribute not in the report

For this example, run the Employee Headcount by Region report in the
MicroStrategy Tutorial project; the report is shown below. This report does not have a
report filter.

Add a report filter (Country = U.S.) that qualifies on the attribute Country, which is not
part of the reports definition. The result is the report shown below, which contains data
for the regions in the U.S. only, as defined in the report filter.

Although the report filter is based on an attribute not in the report itself, the report data
is still affected because of the relationships among the objects in the report, which are all
part of the same attribute hierarchy.
In contrast, a view filter can be created only on objects that are part of the reports
definition. (The objects in a reports definition are displayed in the Report Objects pane.)
This is because view filters only have access to data in the Report Objects pane of the
report, rather than the entire data warehouse.
To provide the same type of analysis used in the first report that uses a report filter,
include Country in the Report Objects pane of the report, but remove it from the grid.
With Country in the Report Objects pane, you can create a view filter to restrict data to
Regions in the US, as shown below.

163 2017, MicroStrategy Inc.

 In-memory Analytics Guide

View filters versus report limits

View filters and report limits are similar filtering features, as they can both be used to
restrict the final result set by setting criteria on the report metrics.
You can define report limits on the value, rank, or percent of the metric value returned.
For example, if you set a report limit of Employee Headcount greater than (>)
5 in the Employee Headcount by Region report in the MicroStrategy Tutorial
project, the report returns the following results.

An important aspect of report limits is that they are processed by the SQL Engine after
metrics are aggregated. In the report SQL, the report limit definition is included in the
Having clause, instead of the Where clause as for the report filter. You can observe this
in the reports SQL statement, shown in the image below.

In addition to this functionality, the following features supported for report limits are not
supported for view filters:

2017, MicroStrategy Inc. 164

In-memory Analytics Guide

Prompts within report limit

Break By
The table below compares the available features and feature requirements of view filters
and report limits:

Features and Feature Requirements Available in Available in

View Filters Report Filters

Attribute qualifications Yes No

Simple metric qualifications Yes Yes
Can define filtering at report run time by including a prompt in a No Yes
qualification
Can define Break By filtering parameters No Yes
Evaluated without re-executing SQL and querying the data source Yes No

Can quickly switch the level at which the qualification is evaluated from Yes No
report level to the level of attributes displayed on the report

For general information on report limits, see the Basic Reporting Guide.

Design considerations
A view filter is similar to a report limit in that it can also be applied at the report level.
However, the report limit and the view filter are not interchangeable. A report limit
restricts the size of the report data set that is returned from the data warehouse. In
contrast, the view filter is applied to the report dataset without altering its size, allowing
you to view a subset of that information. A view filter retrieves information quickly
because Intelligence Server dynamically accesses the data already in the report results.
Report designers must consider how to balance the memory usage and the processing
power between the data warehouse and Intelligence Server. A report limit is more
efficient in terms of report data size because it does not return unnecessary information
from the data warehouse. Therefore, the report limit can be used to save space on the
Intelligence Server memory. However, if a report limit is too restrictive, you may need to
frequently redefine the data definition to yield the information users want to see.
On the other hand, a view filter is more flexible, allowing you to refine your analysis after
the report is executed. A view filter gives you more control over the subset of data
retrieved from the database you want to see. The view filter may be more useful for
analysts because it allows analysts to conduct further investigation and refinement of the
report results after the report is executed against the data warehouse.

Creating a view filter

You can create a view filter by defining a condition that is based on any attribute or
metric on your report. While attribute and metric qualifications both restrict the data

165 2017, MicroStrategy Inc.

 In-memory Analytics Guide

displayed on the report, they are created and defined in slightly different ways.
You can create a view filter in any report. This includes reports connected to an
Intelligent Cube, reports returning information directly from a data warehouse, Freeform
SQL reports returning information from an Excel spreadsheet, and so on.

The following sections provide examples of using view filters on reports returning
information directly from a data warehouse.

Refer to the following sections to create a view filter that contains attribute and/or
metric qualifications:
Filtering data based on business attributes, page 166: Using view filters based on
business attributes, you can view a subset of report data that focuses on the business
data you are interested in.
When creating an attribute qualification for a view filter, you can either qualify on a
list of attribute elements, or you can qualify on attribute forms:
Qualifying on a list of attribute elements is achievable by using the In list or Not
in list operators and selecting from a list of attribute elements. For basic steps to
filter on a list of attribute elements, see the procedure To create a view filter
with an attribute qualification, page 168.
Qualifying on attribute forms is achievable by using the Where operator and
selecting from available attribute forms. For information on qualifying on
attribute forms, see Filtering based on attribute form qualifications, page 169.
Filtering data based on metrics, page 170: Using view filters based on metrics, you
can view a subset of report data that focuses on the data values and ranges you are
interested in.
Combining view filter qualifications with operators, page 185: When a view filter
has multiple qualifications at the same output level, they are always joined by
operators. When qualifications are joined, operators govern the interaction between
the different filtering conditions.

Filtering data based on business attributes

Using a view filter based on business attributes, you can view a subset of report data that
focuses on the business data you are interested in. Narrowing the focus of a report to the
business data that is of interest of you enables another level of report analysis that can
highlight business trends and figures.
For example, the TOP 5 Materials by Net Sales Amount and Quarter report
from the Sales and Distribution Analysis Module is used for this example. The year 2007
has been selected to answer the prompt on year. The resulting report is shown below.

2017, MicroStrategy Inc. 166

In-memory Analytics Guide

The report identifies, for each quarter, the top five materials by net sales order amount.
Once you review the top 5 materials for each quarter in 2007, you decide to focus on the
UC PCEconomy 100 and UC PCEconomy 200 by creating a view filter that includes
these two materials. The view filter along with the resulting report is shown below.

The report shown above focuses on the UC PCEconomy 100 and UC PCEconomy 200
materials to show when these two materials had net sales order amounts in the top 5 for
a given quarter.

167 2017, MicroStrategy Inc.

 In-memory Analytics Guide

The steps below show you how to create a view filter with an attribute qualification, as
well as how to create the example scenario above.
Prerequisites
You need the Use View Filter Editor (Developer) and/or the Web Use View Filter
Editor (Web) privileges. These privileges are part of OLAP Services.

To create a view filter with an attribute qualification

1 Log in to a project in MicroStrategy Developer. For steps to create a view filter in

MicroStrategy Web, see the MicroStrategy Web Help.
For the example scenario, log in to the Sales and Distribution Analysis Module
project.
2 Run the report in Grid View.
For the example scenario, browse to and run the TOP 5 Materials by Net Sales
Amount and Quarter report. Select the 2007 attribute element to answer the
prompt.
3 If the View Filter area is not displayed, from the View menu, select View Filter.
4 In the View Filter area, click Click here to start a new qualification.
5 Click Field, and then select an attribute.
For the example scenario, select Material.
6 Click Operator, and then select one of the following operators to create a filter
qualification (for the example scenario, select In list):
In list: Restricts attribute data to the list of attribute elements you select. Click
Value, and then select the attribute elements to restrict attribute data to.
For the example scenario, select UC PCEconomy 100 and UC PCEconomy
200.
Not in List: Restricts attribute data to the list of attribute elements that are not
in the list of attribute elements you select. Click Value, and select the attribute
elements to exclude data for.
Where: Restricts attribute data based on a filter qualification of an attribute
form. For information on how to define this type of filter qualification for a view
filter, see Filtering based on attribute form qualifications, page 169.
7 Click OK to complete the view filter qualification.
8 If the Auto-Apply Changes check box is cleared, click Apply to apply the view filter
to the report.
The report is updated. The report data is restricted as defined by the view filter. If you
define multiple view filter qualifications at the same output level, you can modify the
logical operator used to join the qualifications, as described in Combining view filter

2017, MicroStrategy Inc. 168

In-memory Analytics Guide

qualifications with operators, page 185. For information on the output level of view
filter qualifications, see Evaluating qualifications at the report or grid level, page 181.

Filtering based on attribute form qualifications

You can qualify on attribute forms using the Where operator. Once you select an
attribute form, you can use various logical and mathematical operators to create a view
filter qualification based on an attribute form, to restrict data. An attribute form
qualification using a Contains operator that restricts data to materials that contain
Economy in their DESC form is shown below.

If you use this view filter with the TOP 5 Materials by Net Sales Amount and
Quarter report, the resulting report is the same as the example scenario in
Filtering data based on business attributes, page 166, which uses the attribute
element qualification Material In list {UC PCEconomy 100, UC
PCEconomy 200}.

You can use any of the following operators in attribute form qualifications. These
operators are described in detail in Appendix A, Logical and Mathematical Operators
for Filtering in the MicroStrategy Advanced Reporting Guide:

Operator Type Operator

Comparison Operators Exactly

Comparison operators compare values. The values can be Different

numbers, text strings, or expressions. from
Greater than
Less than
Greater than
or equal to
Less than or
equal to
Between
Is Null
Is Not Null

169 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Operator Type Operator

Pattern Operators Like

Pattern operators allow text strings to be compared. Not Like

Pattern operators are case-sensitive.
Contains
Does not
contain
Begins with
Does not
begin with
Ends with
Does not end
with

Filtering data based on metrics

Using view filters based on metrics, you can view a subset of report data that focuses on
the data values and ranges you are interested in. Narrowing the focus of a report to the
data that is of interest of you enables another level of report analysis that can highlight
business trends and figures.
For example, review the 16 View Filter - Metric Qualification report from the
Tutorial project, shown below.

This report returns revenue, cost, and profit data for employees, while also displaying the
region the employee is in. The view filter restricts the report results to only return data
for those employees who generated less than $500,000 in revenue. This reduces the
large number of employee results to a smaller set of employees that are generating a
relatively low amount of revenue.
When creating metric qualifications in a view filter, you can use various logical and
mathematical operators. You can use any of the following operators in metric
qualifications. These are described in detail in Appendix A, Logical and Mathematical
Operators for Filtering in the MicroStrategy Advanced Reporting Guide:
Exactly

2017, MicroStrategy Inc. 170

In-memory Analytics Guide

Different from
Greater than
Less than
Greater than or equal to
Less than or equal to
Between
Not Between
Is Null
Is Not Null
Once you select an operator, you can either type in a value or select a metric to return
the value to qualify on.
You can also qualify on the rank or percentage of a metric value for a given report. For
example, you can restrict the report shown above to display all data for employees in the
bottom 20% of revenue. For information on using view filters to restrict report results
based on ranks or percentages of metric data, see Filtering metrics on rank and
percentage ranges, page 174.
The steps below show you how to create a view filter with a metric qualification, as well
as how the example scenario above was created.
Prerequisites
You need the Use View Filter Editor (Developer) and/or the Web Use View Filter
Editor (Web) privileges. These privileges are part of OLAP Services.

To create a view filter with a metric qualification

1 Log in to a project in MicroStrategy Developer. For steps to create a view filter in

MicroStrategy Web, see the MicroStrategy Web Help.
For the example scenario, log in to the MicroStrategy Tutorial project.
2 Run the report in Grid View.
For the example scenario, browse to and run the 16 View Filter - Metric
Qualification report.
3 If the View Filter area is not displayed, from the View menu, select View Filter.
4 In the View Filter area, click Click here to start a new qualification.

You can also create a new view filter qualification on a metric by right-clicking
a metric, pointing to Filter On, and selecting Add Condition.

5 Click Field, and then select a metric.

For the example scenario, select Revenue.

171 2017, MicroStrategy Inc.

 In-memory Analytics Guide

6 Click Operator, and then select an operator.

For the example scenario, select Less than.
7 Click Value, and then select Type a value, or select a metric to return the value to
qualify on. Selecting a metric allows you to create a metric-to-metric qualification,
which are described in Filtering based on metric-to-metric comparisons, page 172.
For the example scenario, select Type a value, and then type 500000.
8 If the Auto-Apply Changes check box is cleared, click Apply to apply the view filter
to the report.
The report is updated. The report data is restricted as defined by the view filter. If you
define multiple view filter qualifications at the same output level, you can modify the
logical operator used to join the qualifications, as described in Combining view filter
qualifications with operators, page 185. For information on the output level of view
filter qualifications, see Evaluating qualifications at the report or grid level, page 181.

Filtering based on metric-to-metric comparisons

You can compare values of two metrics to filter the results of a report by creating metric-
to-metric qualifications. This type of metric qualification can provide analysis such as
comparing metric values over time.
For example, you can create a report that restricts the data to profit margins greater than
last years profit margins. The report shown below includes Year, Region, Profit Margin,
and Profit Margin (Last Year), and was created in the MicroStrategy Tutorial project.

You can create a view filter to then restrict the data on the report to profit margins
greater than last years profit margins. The metric-to-metric qualification and resulting
report are shown below.

2017, MicroStrategy Inc. 172

In-memory Analytics Guide

You can now review when regions had increases in profit margins. For example, from
the report above you can determine that the Northwest and Southeast regions have
shown increases in profit margins from 2006 to 2007.
You can take advantage of view filters ability to update the report results without having
to re-execute SQL against the data warehouse to perform further quick analysis. For
example, you can switch the operator from Greater Than to Less Than to quickly switch
to a view of data for profit margins that are less than the previous years profit margins.
The metric-to-metric qualification in the view filter and resulting report are shown
below.

The steps below show you how to create a view filter with a metric-to-metric
qualification, as well as how the example scenario above was created.
Prerequisites
You need the Use View Filter Editor (Developer) and/or the Web Use View Filter
Editor (Web) privileges. These privileges are part of OLAP Services.

173 2017, MicroStrategy Inc.

 In-memory Analytics Guide

To create a view filter with a metric-to-metric qualification

1 Log in to a project in MicroStrategy Developer. For steps to create a view filter in

MicroStrategy Web, see the MicroStrategy Web Help.
For the example scenario, log in to the MicroStrategy Tutorial project.
2 Run the report in Grid View.
For the example scenario, create a report with Year, Region, and Profit Margin on
the report. Create a metric that returns a transformation of last years profit margin
values, and name the metric Profit Margin (Last Year). For details to create a
transformation metric, see the Advanced Reporting Guide.
3 If the View Filter area is not displayed, from the View menu, select View Filter.
4 In the View Filter area, click Click here to start a new qualification.

You can also create a new view filter qualification on a metric by right-clicking
a metric, pointing to Filter On, and selecting Add Condition.

5 Click Field, and then select a metric.

For the example scenario, select Profit Margin.
6 Click Operator, and then select an operator.
For the example scenario, select Greater than.
7 Click Value, and then select a metric to return the value to qualify on.
For the example scenario, select Profit Margin (Last Year).
8 If the Auto-Apply Changes check box is cleared, click Apply to apply the view filter
to the report.
The report is updated. The report data is restricted as defined by the view filter. If you
define multiple view filter qualifications at the same output level, you can modify the
logical operator used to join the qualifications, as described in Combining view filter
qualifications with operators, page 185. For information on the output level of view
filter qualifications, see Evaluating qualifications at the report or grid level, page 181.

Filtering metrics on rank and percentage ranges

In addition to restricting report results based on metric qualifications, you can also
restrict report results based on the rank or percentage range of a metric value for a given
report. This enables you to display reports with data such as products in the top 40% of
profit. You could also create a report to return the top 10 employees in terms of average
performance score.
It is important to understand the operators that are available for these types of view
filters. When creating view filter qualifications on the rank or percentage ranges of

2017, MicroStrategy Inc. 174

In-memory Analytics Guide

operators, which are described as they relate to rank and percent metric qualifications in
the table below:

In Developer, all of the operators listed below can be used to create rank and
percent metric qualifications as part of a view filter. Rank and percent metric
qualifications using any of these operators can be viewed in MicroStrategy Web.
However, only the Is Highest (referred to as Highest or Highest% in Web) and Is
Lowest (referred to as Lowest or Lowest% in Web) can be used to create or modify
rank and percent metric qualifications in Web.

Operator Functionality and considerations

Exactly Identifies a specific value, as described below:

For rank ranges, this restricts a report to data for only one specific rank. For example,
a rank range defined as Exactly 1 returns data for only the highest value of a given
metric. This scenario produces the same results as using the Is Highest operator
described below in this table.
For percent ranges, this operator has limited value. This is because it restricts a report
to data that is exactly a specific percentage. Percentages are not always integer
values and therefore it is difficult to predict what percentage would return meaningful
results.
Different Identifies values that are other than the specific value indicated:
from
For rank ranges, this restricts a report to data for only ranks that are different from the
given value. For example, a rank range defined as different from 1 returns data for all
ranks except the highest value of a given metric.
For percent ranges, this operator has limited value. This is because it restricts a report
to data that is different from a specific percentage. Percentages are not always integer
values and therefore it is difficult to predict what percentage would return meaningful
results. In most cases, using this operator with percent metric qualifications does not
restrict any data.
Between Identifies values in a range that has both a lower and an upper limit:
For rank ranges, you can provide a lower and upper rank limit. For example, you can
display only ranks 20 through 40.
For percent ranges, you can provide a lower and upper percentage limit. For example,
you can display only data with metric values between 20% and 40% of all values.
Not Identifies values in a range that has both a lower and an upper limit. Data is restricted for
Between any values outside of this range:
For rank ranges, you can provide a lower and upper rank limit. For example, you can
display only ranks not between 20 through 40. This displays ranks 1 through 19 and
41 and down.
For percent ranges, you can provide a lower and upper percentage limit. For example,
you can display only data with metric values not between 20% and 40% of all values.
This displays data with metric values between 1% and 19% and between 41% and
100%.
Is Null Identifies values that are null. Using the rank or percent metric qualifications is not
necessary with this operator. To return all data where metric values are Null, you can
simply create a view filter metric qualification on the metric that uses the Is Null function.

175 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Operator Functionality and considerations

Is Not Identifies values that are not null. Using the rank or percent metric qualifications is not
Null necessary with this operator. To return all data where metric values are not null, you can
simply create a view filter metric qualification on the metric that uses the Is Not Null
function.
Top Identifies the topmost value range in a given set:
For rank ranges, you can provide a topmost rank range. For example, you can display
only data within the top 20 rank range.
For percentage ranges, you can provide a topmost percentage range. For example,
you can display only data within the top 20% range.
Bottom Identifies the lowest set of values in a given set:
For rank ranges, you can provide a lowest rank range. For example, you can display
only data within the bottom 20 rank range.
For percentage ranges, you can provide a lowest percentage range. For example, you
can display only data within the bottom 20% range.
Exclude Identifies a value range that is not in the topmost value range in a given set:
top
For rank ranges, you can provide a topmost rank range to exclude from the report
results. For example, you can display only data that excludes the top 20 rank range.
For percentage ranges, you can provide a topmost percentage range to exclude from
the report results. For example, you can display only data that excludes the top 20%
range.
Exclude Identifies a value range that is not in the lowest set of values in a given set:
bottom
For rank ranges, you can provide a lowest rank range to exclude from the report
results. For example, you can display only data that excludes the bottom 20 rank
range.
For percentage ranges, you can provide a lowest percentage range to exclude from
the report results. For example, you can display only data that excludes the bottom
20% range.
Is Identifies the highest value. This operator should only be used with rank ranges. For rank
Highest ranges, this restricts report results to display data for only the highest value of a given
metric.
Is Lowest Identifies the lowest value. This operator should only be used with rank ranges. For rank
ranges, this restricts report results to display data for only the lowest value of a given
metric.

The rank and percentage ranges view filters are discussed in the sections listed below:
Creating a view filter on a rank range of metric values, page 177: You can create a
view filter that restricts report results based on a rank range of metric values for a
given report. This can allow you to view analysis such as the bottom 20 products in
terms of profit margin.
Creating a view filter on a percentage range of metric values, page 179: You can
create a view filter that restricts report results based on a percent range of metric
values for a given report. This can allow you to view analysis such as employees
between 30% and 60% of tenure length with the company.

2017, MicroStrategy Inc. 176

In-memory Analytics Guide

Creating a view filter on a rank range of metric values

You can create a view filter that restricts report results based on a rank range of metric
values for a given report. This can allow you to view analysis such as the bottom 20
products in terms of profit margin. Further analysis can be explored on this rank range
of products to determine how to increase profit margins for these products, or decide
which products should be discontinued.
This type of report and analysis can be created in the MicroStrategy Tutorial project. You
first create a report with Item, Revenue, Profit, and Profit Margin on the report, as
shown below.

Only a subset of the report results are shown above, but notice that data for 360 items
have been returned. To narrow the analysis of the report, you create a view filter to
restrict the report results to the bottom 20 products in terms of profit margin. The view
filter and resulting report are shown below.

177 2017, MicroStrategy Inc.

 In-memory Analytics Guide

With this updated report, you can now perform further analysis on each item to
determine a strategy to improve your profit margins.
Notice that the view filter above uses the Bottom operator. For a description of each
operator available when creating view filters with rank ranges, see Filtering metrics on
rank and percentage ranges, page 174.
The steps below show you how to create a view filter with a rank metric qualification, as
well as how the example scenario above was created.
Prerequisites
You need the Use View Filter Editor (Developer) and/or the Web Use View Filter
Editor (Web) privileges. These privileges are part of OLAP Services.

To create a view filter with a rank metric qualification

1 Log in to a project in MicroStrategy Developer. For steps to create a view filter in

MicroStrategy Web, see the MicroStrategy Web Help.
For the example scenario, log in to the MicroStrategy Tutorial project.
2 Run a report in Grid View.

2017, MicroStrategy Inc. 178

In-memory Analytics Guide

For the example scenario, create a report with Item, Revenue, Profit, and Profit
Margin on the report, as shown in Creating a view filter on a rank range of metric
values, page 177.
3 If the View Filter area is not displayed, from the View menu, select View Filter.
4 In the View Filter area, click Click here to start a new qualification.
5 To create a rank metric qualification, click Field, point to Rank, and then select a
metric.
For the example scenario, select Profit Margin.
6 Click Operator, and then select an operator.
For the example scenario, select Bottom.
7 Click Value, and then select Type a value. Type the value for the rank number you
want to restrict data to.
For the example scenario, type 20.
8 If the Auto-Apply Changes check box is cleared, click Apply to apply the view filter
to the report.
The report is updated. The report data is restricted as defined by the view filter. If you
define multiple view filter qualifications at the same output level, you can modify the
logical operator used to join the qualifications, as described in Combining view filter
qualifications with operators, page 185. For information on the output level of view
filter qualifications, see Evaluating qualifications at the report or grid level, page 181.

Creating a view filter on a percentage range of metric values

You can create view filters that restrict report results based on a percent range of metric
values for a given report. This can allow you to view analysis such as employees between
30% and 60% of tenure length with the company. You can then explore performance
metrics within this percentage range of employees and determine where promotions and
other actions are necessary.
For example, you create a report with Year, Region, Category, Revenue, and Profit on the
report, with Category not displayed on the report grid, as shown below.

179 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You decide to analyze this report to show only the data that is within the top 10% of
profit. The view filter and resulting report are shown below.

With this analysis, you can now perform further analysis to determine why profit was at
its highest during these years and within these regions.
Notice that the view filter above uses the Top operator. For a description of each
operator available when creating view filters with percent ranges, see Filtering metrics
on rank and percentage ranges, page 174.
The steps below show you how to create a view filter with a percent metric qualification,
as well as how the example scenario above was created.
Prerequisites

2017, MicroStrategy Inc. 180

In-memory Analytics Guide

You need the Use View Filter Editor (Developer) and/or the Web Use View Filter
Editor (Web) privileges. These privileges are part of OLAP Services.

To create a view filter with a percent metric qualification

1 Log in to a project in MicroStrategy Developer. For steps to create a view filter in

MicroStrategy Web, see the MicroStrategy Web Help.
For the example scenario, log in to the MicroStrategy Tutorial project.
2 Run the report in Grid View.
For the example scenario, create a report with Year, Region, Category, Revenue, and
Profit on the report with Category not displayed on the report grid, as shown in
Creating a view filter on a percentage range of metric values, page 179.
3 If the View Filter area is not displayed, from the View menu, select View Filter.
4 In the View Filter area, click Click here to start a new qualification.
5 To create a percent metric qualification, click Field, point to Percent, and then
select a metric.
For the example scenario, select Profit.
6 Click Operator, and then select an operator.
For the example scenario, select Top.
7 Click Value, and then select Type a value.Type the value for the rank number you
want to restrict data to.
For the example scenario, type 20.

Valid numbers for percent metric qualifications are 1 to 100.

8 If the Auto-Apply Changes check box is cleared, click Apply to apply the view filter
to the report.
The report is updated. The report data is restricted as defined by the view filter. Further
analysis on this report is performed to demonstrate how you can change the level of
evaluation for view filter metric qualifications. This analysis is provided in Evaluating
qualifications at the report or grid level, page 181.
If you define multiple view filter qualifications at the same output level, you can modify
the logical operator used to join the qualifications, as described in Combining view filter
qualifications with operators, page 185. For information on the output level of view
filter qualifications, see Evaluating qualifications at the report or grid level, page 181.

Evaluating qualifications at the report or grid level

When a metric qualification in a view filter is evaluated by the system, the evaluation can
be performed for all data that is returned for the report, or only the view of data that is

181 2017, MicroStrategy Inc.

 In-memory Analytics Guide

currently available on the report grid. These two options can produce different report
results when using the OLAP Services feature called dynamic aggregation.
Dynamic aggregation enables you to remove attributes from the report grid, but keep
them as part of the report definition. The action of moving attributes on or off of the
report grid aggregates the metric values at the new level of the report. For information
on dynamic aggregation, see Chapter 9, Dynamic Aggregation.
By default, metric qualifications in a view filter are evaluated at the level of data that is
available on the report grid. This means that any attributes that are included in the
Report Objects pane but not on the report grid are not used to determine the level of the
metric qualification.
For example, you create a report with Year, Region, Category, Revenue, and Profit on the
report, with Category not displayed on the report grid, as shown below.

This report can be created in the MicroStrategy Tutorial project.

You can use dynamic aggregation to drag and drop the Category attribute from the report
grid to the Report Objects pane. This allows Category to affect the report level without
being displayed on the grid.
You decide to analyze this report to show only the data that is within the top 10% of
profit. The view filter and resulting report are shown below.

2017, MicroStrategy Inc. 182

In-memory Analytics Guide

Steps to create the report shown above is described in Creating a view filter on a
percentage range of metric values, page 179.
Notice that only two rows of data are returned. The metric qualification has been
evaluated at the level of the report grid, which is Year and Region. This gives you a view
of data within the top 10% of profit for the data displayed on the report grid.
However, this report also includes the Category attribute in the Report Objects pane.
Since this attribute is available on the report, you can also view data within the top 10%
of profit at the Category, Region, and Year level. Evaluating the metric qualification at
this level returns the report results shown below.

Notice that there are many more rows of data that are within the top 10% of profit. This
is because Category is now included in the calculation of the metric qualification. While
this evaluation option for metric qualifications returns a different type of analysis, the
same analysis can be achieved by simply adding all attributes from the Report Objects
pane onto the report grid, so that all attributes are then present on the report grid.
The following information should be taken into consideration when choosing an
evaluation level for a metric qualification. This information assumes you are familiar with
report levels as explained in the Advanced Reporting Guide:
Evaluation at the report grid level: Evaluating metric qualifications at the level
present on the report grid allows the view filter to dynamically display analysis that
reflects the data available on the report grid. If all attributes are on the report grid,
then this level is used to calculate the metric qualification. Additionally, anytime an
attribute is moved between the Report Objects pane and the report grid, the view
filter dynamically recalculates the metric qualification to reflect the new level of data
on the report grid.

183 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You can join metric qualifications evaluated at the grid level to any other metric
qualifications evaluated at the grid with logical operators, as described in Combining
view filter qualifications with operators, page 185.
If derived metrics are also on this report, evaluating metric qualifications at the grid
level also causes the metric qualifications to be evaluated after derived metrics by
default. This means that these qualifications filter the results of any derived metric
calculations. For more information, see View filter effects on derived metrics, page
187.
Evaluation at the report level: Evaluating metric qualifications at the report
level, regardless of what attributes are on the report grid or the Report Objects pane,
provides a consistent level of analysis during dynamic aggregation.
You can also join metric qualifications evaluated at the report level to attribute
qualifications or other metric qualifications evaluated at the report level with logical
operators, as described in Combining view filter qualifications with operators, page
185.
If derived metrics are also on this report, evaluating metric qualifications at the
report level also causes the metric qualifications to be evaluated before derived
metrics by default. This means that these qualifications filter data before any derived
metric calculations are applied. For more information, see View filter effects on
derived metrics, page 187.
Metric-to-metric qualifications: The evaluation level of metric-to-metric
qualifications cannot be modified. All metric-to-metric qualifications are evaluated at
the report level. For information on metric-to-metric qualifications, see Filtering
based on metric-to-metric comparisons, page 172.
The steps below show you how to modify the evaluation of metric qualifications in a view
filter.
Prerequisites
You need the Use View Filter Editor (Developer) and/or the Web Use View Filter
Editor (Web) privileges. These privileges are part of OLAP Services.
A report with a metric qualification in the view filter that is not a metric-to-metric
qualification.
To observe how this modification can affect report results, the report should also
have some attributes in the Report Objects pane, but not on the report grid.

You cannot modify the evaluation level of metric-to-metric qualifications. All

metric-to-metric qualifications are evaluated at the report level.

To modify the evaluation level of metric qualifications in a view filter

1 Log in to a project in MicroStrategy Developer. For steps to modify the evaluation

level of metric qualifications in a view filter in MicroStrategy Web, see the
MicroStrategy Web Help.
2 Run the report in Grid View.

2017, MicroStrategy Inc. 184

In-memory Analytics Guide

3 If the View Filter area is not displayed, from the View menu, select View Filter.
4 In the View Filter area, right-click a metric qualification and select one of the
following options, which you can switch between:
Apply Condition at the Grid Level (default): Evaluates the metric
qualification only for the attributes included on the report grid. Attributes in the
Report Objects pane but not on the report grid are not included in the metric
qualification evaluation.
Apply Condition at the {attributes in Report Objects} Level: Evaluates the
metric qualification for all attributes included in the Report Objects pane,
regardless of whether they are displayed on the report grid.

You can choose different evaluation options for separate metric qualifications
in the same view filter.

5 If the Auto-Apply Changes check box is cleared, click Apply to apply the view filter
to the report.
The report is updated. The report data is restricted as defined by the view filter.

Combining view filter qualifications with operators

When a view filter has multiple qualifications at the same output level, they are always
combined by operators. When qualifications are combined, operators govern the
interaction between different filtering conditions. Whenever you have more than one
qualification in a view filter at the same output level, you can define the operator as any
of the following:
AND
OR
OR NOT
AND NOT
For information and examples on how each of these operators govern interaction
between filter qualifications, see the Basic Reporting Guide.

You cannot change the logical operator between two metric qualifications if all of
the following are true:

The metric qualifications use two different metrics (for example, Revenue in
Qualification 1 and Profit in Qualification 2).
The metric qualifications are not metric-to-metric qualifications, but instead
compare the metrics to numeric values.
The metric qualifications are evaluated at the grid level.
Because the output level of view filter qualifications determines which qualifications can
be joined with logical operators, by default all attribute qualifications are at the same
output level as other attribute qualifications, and all metric qualifications are at the same

185 2017, MicroStrategy Inc.

 In-memory Analytics Guide

output level as other metric qualifications. This mean that an attribute qualification can
be joined with other attribute qualifications, and metric qualifications can be joined with
other metric qualifications, but attribute and metric qualifications cannot be joined.
However, you can modify the output level of metric qualifications. If you modify a metric
qualification to be evaluated at the report level, the metric qualification can be joined
with attribute qualifications and with any other metric qualifications that have been
defined to be evaluated at the report level. Metric qualifications evaluated at the report
level cannot be joined with metric qualifications evaluated at the grid level. For
information on the benefits of evaluating metric qualifications at the report level versus
the grid level, see Evaluating qualifications at the report or grid level, page 181.

Deleting a view filter

When deleting a view filter, you have the option of deleting all of the qualifications of a
view filter at once, or deleting the qualifications individually. The basic steps to perform
both options are given below.

To delete all view filter qualifications

1 In an opened report with a view filter, in the View Filter pane, click Clear.
2 If you do not have Auto-Apply changes selected, click Apply. If you only perform
Clear without Apply, the view filter appears in the report the next time you open it.

To delete a view filter qualification individually

1 In an opened report with a view filter, right-click the qualification and select
Remove qualification.
2 If you do not have Auto-Apply changes selected, click Apply. If you only perform
Clear without Apply, the view filter appears in the report the next time you open it.

View filter effects on reporting features

Applying a view filter to a report restricts the data that is displayed on the report grid.
However, unlike report filters, data restricted from display by a view filter is still available
for a report. This difference has an effect on how view filters interact with various
reporting features. This section discusses:
View filter effects on derived metrics, page 187
View filter effects on metrics with relative functions, page 191
View filter effects on dynamic aggregation, page 193
View filter effects on derived elements, page 196

2017, MicroStrategy Inc. 186

In-memory Analytics Guide

View filter effects on derived metrics

For most derived metrics, view filters have the same effects as they do on standard
metrics created with the Metric Editor. When data is restricted from view, the derived
metric values along with any related data is hidden from the view of the report. For
example, if a view filter restricts data to the year 2007, then any derived metrics and
standard metrics included on the report only display data for the year 2007.
However, derived metrics created with relative functions (OLAP functions and Rank and
Ntile functions) are affected by the evaluation of view filters in a unique way.
A derived metric uses the data available on a report to calculate its values. Since view
filter qualifications restrict the data displayed on the report, this can also restrict the data
available for derived metrics, depending on the evaluation order of the two objects. This
restriction of data, combined with derived metrics with relative functions that depend on
other values on the report, can effect the display of report results.
The view filter effects on derived metrics with relative functions depends on how view
filters are used in such reports, as described in the sections listed below:
Using view filters that affect derived metrics with relative functions, page 187:
Derived metrics with relative functions such as RunningSum or Rank return values
that are relative to other values on a report. When data is restricted by view filter
qualifications on other objects of a report, you can allow the values of derived
metrics with relative functions to calculate their relative values based on the new
view of report data.
Using derived metrics with relative functions in view filters, page 189: Derived
metrics with relative functions such as RunningSum or Rank return values that are
relative to the data on a report. When derived metrics with relative functions are
used to define view filters, you can allow the relative values to reflect the new view of
data or retain the relative values for all report data.

Using view filters that affect derived metrics with relative functions
Derived metrics with relative functions such as RunningSum or Rank return values that
are relative to other values on a report. When data is restricted by view filter
qualifications on other objects of a report, you can allow the values of derived metrics
with relative functions to calculate their relative values based on the new view of report
data.
For example, consider a report created in the MicroStrategy Tutorial project with Year,
Category, Profit, Profit Margin, and a rank shortcut derived metric named Rank (Profit
Margin) as shown below.

187 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Notice that the 12 rows are ranked in ascending order from 1 to 12 by their profit margin
values. You then create a view filter qualification to display data only when profit is less
than $1,000,000. The view filter and resulting report are shown below.

Notice that while some data no longer appears on the report, the values of the Rank
(Profit Margin) derived metric remain the same. This allows you to view the rank of
profit margins as applied over all the data for the report, including the data that has been
filtered from view.
Since the Rank (Profit Margin) metric is a derived metric, you can modify the report so
that the metrics values are relative to the new view of data supplied by the view filter, as
shown in the report below.

2017, MicroStrategy Inc. 188

In-memory Analytics Guide

You can apply this type of analysis in one of two ways:

Evaluate the view filter qualification at the report level. This causes the view filter to
be evaluated before any derived metrics. The derived metrics then calculate their data
using the view of data created by the view filter. For information on evaluating view
filter qualifications at the report level, see Evaluating qualifications at the report or
grid level, page 181.
Evaluate the view filter qualification at the grid level and change the evaluation order
of derived metrics to be calculated after the view filter. For information on changing
the evaluation order of individual report objects such as view filter qualifications and
derived metrics, see the Advanced Reporting Guide.

Using derived metrics with relative functions in view filters

Derived metrics with relative functions such as RunningSum or Rank return values that
are relative to the data on a report. When data is restricted by view filter qualifications on
derived metrics with relative functions, you can allow the relative values to reflect the
new view of data, or retain the relative values for all report data.
When derived metrics with relative functions are used to define view filters, you can
allow the relative values to reflect the new view of data or retain the relative values for all
report data.
For example, consider a report created in the MicroStrategy Tutorial project with Year,
Category, Profit, Profit Margin, and a percent-to-total shortcut derived metric named
Percent to Total Over Rows (Profit Margin), as shown below.

189 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Notice that the percent-to-total values display the distribution of profits over all 12 rows
of data. You then create a view filter qualification based on the percent-to-total derived
metric to display data only when the percent-to-total profit is less than two percent (.02).
The view filter and resulting report are shown below.

While it appears that data is being shown for percent-to-totals greater than two percent,
this is because the Percent to Total Over Rows (Profit) derived metric values have
dynamically changed to reflect the new view of data displayed on the report. A grand
total is displayed to show that the derived metric values add up to 100%, even though
these rows of data combined account for less than four percent of the profits of the
original report. This analysis is applied because the view filter qualification is evaluated at
the report level by default.
The report above provides a view of percent-to-total profit data as displayed on the
report. However, view filter qualifications on derived metrics can also be evaluated at the

2017, MicroStrategy Inc. 190

In-memory Analytics Guide

grid level so that the derived metrics retain their values that reflect all data available for
the report, as shown in the report below.

Notice that the percent-to-total profit values now appear to be less than two percent and
reflect the values of the original report that included all report data. This is also reflected
in the grand total of 3.28%.
As these scenarios illustrate, you have two options to evaluate view filter qualifications
based on derived metrics with relative functions, summarized below:
Evaluate the view filter qualification at the report level (default). This causes the
derived metric values to dynamically reflect the new view of data on the report after
the view filter qualification is applied.
Evaluate the view filter qualification at the grid level. This causes the derived metric
to retain its values that reflect all data available for the report.
For information on evaluating view filter qualifications at the report level versus the grid
level, see Evaluating qualifications at the report or grid level, page 181.

View filter effects on metrics with relative functions

Metrics with relative functions (OLAP functions and Rank and Ntile functions) such as
RunningSum or Rank return values that are relative to other values on a report. When
data is restricted by view filter qualifications, some of the report data is hidden from view
while the data available is not changed. This can cause the values returned by metrics
with relative functions to appear to have incorrect values for the data displayed on the
report.
For example, consider a report with Customer Group, Year, Average Net Sales Order
Amount per Customer, and RunningAvg (Average Net Sales Order Amount per
Customer), as shown below.

191 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You then create a view filter to restrict data to only years 2007 and 2008. The view filter
qualification and resulting report are shown below.

Notice that the values for the RunningAvg (Average Net Sales Order Amount per
Customer) metric do not change, only the 2006 values are hidden. The values displayed
do not accurately reflect the view of data and instead reflect the data available for the
entire report, including the 2006 data hidden from view.
This is because the view filter is calculated without re-executing SQL against the data
warehouse, and is evaluated after calculating the metrics on the report. Therefore, the
metric is not recalculated to reflect the view of data shown on the report as restricted by
the view filter.

2017, MicroStrategy Inc. 192

In-memory Analytics Guide

If you plan to use metrics with relative functions and require them to reflect the data
displayed on the report, you can use one of the options summarized below:
Use report filters rather than view filters. A report filter causes a report to re-execute
its SQL against the data warehouse, which can cause more processing time than a
view filter. However, this allows a metric with a relative function to recalculate its
values based on the filtering criteria.
Use derived metrics with relative functions rather than standard metrics. Derived
metrics can be evaluated after view filters and thus reflect the view of data on a
report without having to re-execute SQL. However, derived metrics cannot be saved
for use in multiple reports and can require modification to work as intended with
view filters. For information on the interaction between view filters and derived
metrics, see View filter effects on derived metrics, page 187.

View filter effects on dynamic aggregation

Dynamic aggregation occurs when an attribute is moved between the report layout and
the Report Objects pane. This type of aggregation dynamically affects the data returned
for the report. For more information on dynamic aggregation, refer to Chapter 9,
Dynamic Aggregation.
A view filter also dynamically affects the data returned for a report, by restricting the
report data using various types of qualifications. You can use both view filters and
dynamic aggregation to return different analyses of report data, as described in the
sections listed below:
Using attribute qualifications on hidden attributes, page 193: When report data is
restricted using a view filter attribute qualification, this can affect the data displayed
on the report even if the attribute it qualifies on is not displayed on the report grid.
Using metric qualifications at the report or grid level, page 194: When report data is
restricted using a view filter metric qualification, this can affect the data displayed on
the report in various ways depending on when the view filter metric qualification is
evaluated.

Using attribute qualifications on hidden attributes

When report data is restricted using a view filter attribute qualification, this can affect
the data displayed on the report even if the attribute it qualifies on is not displayed on the
report grid.
For example, consider the View Filter - Dynamic Aggregation report in the MicroStrategy
Tutorial project, as shown below.

193 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Notice that dynamic aggregation has been used to remove the Employee attribute from
the report grid. However, there is also a view filter attribute qualification on the
Employee attribute. Even though Employee is not shown on the report, the data
displayed is restricted by the view filter to only display data for the employees Caitlin Bell,
Beatrice Conner, Andrew Johnson, Laura Kelly, and Jack Kieferson. This can be verified
by using dynamic aggregation to drag and drop Employee on the report grid, as shown
below.

Data is dynamically aggregated to be displayed at the region and employee level. A

subtotal has been added to the report above to show that the original report was only
displaying data for the employees listed in the view filter attribute qualification. For
example, notice that the revenue, cost, and profit data for the Northeast region of the
original report matches the values for the Northeast subtotal values of the report above.

Using metric qualifications at the report or grid level

When report data is restricted using a view filter metric qualification, this can affect the
data displayed on the report in various ways depending on when the view filter metric
qualification is evaluated.
For example, consider the View Filter - Dynamic Aggregation report in the MicroStrategy
Tutorial project, as shown below.

2017, MicroStrategy Inc. 194

In-memory Analytics Guide

Notice that dynamic aggregation has been used to remove the Employee attribute from
display on the report grid. You then create a view filter metric qualification to restrict the
report data for profits greater than $300,000. The view filter qualification and resulting
report are shown below.

The view filter metric qualification is evaluated at the grid level by default. This means
that the dynamic aggregation of removing Employee from the report layout is evaluated
first, and then the view filter metric qualification restricts data based on the remaining
data displayed on the report.
With this evaluation order, the view filter metric qualification returns regions with
profits greater than $300,000.
However, you can also evaluate view filter metric qualifications at the report level. You
can right-click the Profit Greater than $300,000 qualification, and select Apply
Condition at the {Employee, Region} level. Evaluating the metric qualification at
the report level returns the report results shown below.

195 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Notice that only data for the Northeast region is returned, and all metric values are
lower. This is because a view filter metric qualification evaluated at the report level
includes all attributes, in the calculation to restrict data from the report.
Data is first restricted to employees with profits greater than $300,000, and then this
data is aggregated and displayed at the region level. In the first report the Southwest
region included two employees who combined to have more than $300,000 in profit,
but neither employee had more than $300,000 alone. These employees are restricted by
the view filter and are not included when aggregating the data at the region level.
These two options provide two different types of analysis on report data, summarized
below:
Evaluating view filter metric qualifications at the grid level: When view
filter metric qualifications are evaluated at the grid level and dynamic aggregation is
used, only the attributes displayed on the report grid are used to determine the data
restricted from the report.
In the example above, any regions with profits greater than $300,000 for the
included employees are displayed on the report.
Evaluating view filter metric qualifications at the report level: When
view filter metric qualifications are evaluated at the report level and dynamic
aggregation is used, all attributes in the Report Objects pane are used to determine
the data restricted from the report. This includes attributes that are not on the report
grid.
In the example above, any employees with profits greater than $300,000 for the
included employees are displayed on the report. The data for any remaining
employees is then aggregated and displayed at the region level.
For information on evaluating view filter qualifications at the report level versus the grid
level, see Evaluating qualifications at the report or grid level, page 181.

View filter effects on derived elements

View filters restrict data on reports by enabling users to create qualifications on attributes
and metrics. These qualifications then determine what data is shown on the report, as
well as what data is available to analyze and format with derived elements.
Derived elements cannot be selected in a view filter, and therefore cannot be a part of a
view filter qualification that restricts the report results. View filters can only include
qualifications on attributes and metrics.
However, derived elements are associated with attribute elements. Due to this
association, any view filter qualifications that restrict the data for a derived elements
associated attribute elements also restricts data returned for the derived element.
For example, a report includes a Group derived element defined to combine profit values
for the Music and Movies elements of the Category attribute. This report is shown below.

2017, MicroStrategy Inc. 196

In-memory Analytics Guide

The Music and Movies derived element combines the profit values for the Music
attribute element and Movies attribute element. You then create a view filter
qualification that restricts the report data to the individual Movies attribute element and
Electronics attribute element. The report results are shown below.

Notice that the Music and Movies derived element is still displayed, but the profit value
has decreased. This is because the view filter has restricted the data to only Movies and
Electronics. The Music and Movies derived element can only return profit values for the
available Movies attribute element data. When using view filters and derived elements on
the same report, be aware that any view filter qualifications restrict the data available to
analyze and format with derived elements.

197 2017, MicroStrategy Inc.

 8
DYNAMIC SOURCING
The general goal of reporting on data in Intelligent Cubes is to create reports that are
linked to a published Intelligent Cube. Dynamic sourcing makes Intelligent Cubes more
accessible by allowing regular reports to automatically access published Intelligent Cubes
that can satisfy the data requirements of the report.
This can improve the performance of reports, which get executed against an Intelligent
Cube, without having to manually find and select the Intelligent Cube that fits the
analysis of the report. If the data requirements for the report change, or cannot be
satisfied by an available Intelligent Cube, the reports automatically access the data
warehouse to return the required information.
To support dynamic sourcing, you will need to configure your projects, Intelligent Cubes,
reports, attributes, metrics, and any aggregate tables you use. This appendix describes the
benefits of dynamic sourcing, the necessary steps to support dynamic sourcing, and how
to track how successful dynamic sourcing is for your project. This chapter assumes you
are familiar with the information in Chapter 2, Sharing Sets of Data Among Reports:
Intelligent Cubes.
The sections listed below describe the following information:
Scenarios that benefit from dynamic sourcing, page 198
Best practices for supporting dynamic sourcing, page 200
Configuring dynamic sourcing, page 206
Using Cube Advisor to support dynamic sourcing, page 218
Tracking the use of dynamic sourcing, page 227

Scenarios that benefit from dynamic sourcing

Dynamic sourcing can greatly improve the performance of your projects, because it
allows reports to automatically detect an Intelligent Cube that can satisfy its data
requirements, and execute against the Intelligent Cube rather than the data warehouse.
This section also discusses how you can tune your project to better support dynamic
sourcing for these features, as described in Tuning your project for dynamic sourcing,
page 199.

2017, MicroStrategy Inc. 198

In-memory Analytics Guide

Dynamic sourcing complements the ability to create reports that are connected to a
specific Intelligent Cube. This feature gives you the following performance benefits:
Report designers do not need to know whether an Intelligent Cube includes the
information they need, or which Intelligent Cube they should use. With dynamic
sourcing, an Intelligent Cube that can satisfy the reports data requirements is
detected automatically, without the report designer having to consider which
Intelligent Cubes are available.
The performance of pre-existing reports can be improved without having to modify
the report to access a specific Intelligent Cube. Dynamic sourcing can allow these
reports to automatically detect an Intelligent Cube that satisfies the reports data
requirements.
The performance of prompted reports can be greatly improved. Prompted reports
can cause performance issues, because it is difficult to use report caches with them.
When different prompt answers are chosen, a report cache cannot return
information for the report and the report request must be submitted through the
data warehouse again.
With dynamic sourcing, Intelligent Cubes can provide a set of data that can satisfy
the data requirements of reports executed with different prompt answers.
Reports can drill from one Intelligent Cube to another Intelligent Cube.

Tuning your project for dynamic sourcing

You can tune your project to provide a reporting environment that is more likely to be
able to take advantage of dynamic sourcing, as described in the sections listed below:
Tuning Intelligent Cubes for dynamic sourcing, page 199
Tracking the success of dynamic sourcing, page 200
For information on the various features that are supported for dynamic sourcing, see
Best practices for supporting dynamic sourcing, page 200.

Tuning Intelligent Cubes for dynamic sourcing

One of the most important aspects in providing dynamic sourcing for as many reports as
possible in your project is the creation and availability of Intelligent Cubes. Once
Intelligence Server determines which Intelligent Cubes can satisfy a reports needs, it
automatically selects the Intelligent Cube that offers the best performance for the report.
You can improve the chances that a report will use dynamic sourcing by making more
Intelligent Cubes available to it. When creating additional Intelligent Cubes, however, you
must consider that Intelligent Cubes can consume a significant amount of Intelligence
Servers memory. If you can determine the objects and type of analysis most commonly
used in reports, you can use this information to tailor the Intelligent Cubes to these
requirements.
Be aware that enabling dynamic sourcing requires some system overhead to determine
whether a report can access an Intelligent Cube rather than the data warehouse. This
overhead increases as the number of Intelligent Cubes enabled for dynamic sourcing

199 2017, MicroStrategy Inc.

 In-memory Analytics Guide

increases. However, the overhead only affects Intelligence Servers performance if there
are over a thousand Intelligent Cubes, which is an unlikely business scenario.

Tracking the success of dynamic sourcing

If you enable dynamic sourcing for a project, you can track various information related
to dynamic sourcing that can help determine why dynamic sourcing succeeded or failed
for reports. By determining why dynamic sourcing failed for a given report, you can
modify your reports, Intelligent Cubes, and other objects to allow reports in your project
to use dynamic sourcing. Tracking dynamic sourcing information is described in
Tracking the use of dynamic sourcing, page 227.

Best practices for supporting dynamic sourcing

For a report to successfully retrieve its information from an Intelligent Cube, various
conditions must be met. The considerations and steps required to fully support dynamic
sourcing are listed below:
While many MicroStrategy features can be used with dynamic sourcing, some
features prevent the use of dynamic sourcing between reports and Intelligent Cubes.
Refer to the following sections for a list of features that can and cannot be used with
dynamic sourcing:
Features that can be used with dynamic sourcing, page 202
Features that prevent the use of dynamic sourcing, page 203
You can use Cube Advisor to create Intelligent Cubes that will allow as many reports
as possible to use dynamic sourcing. For steps to use Cube Advisor to support
dynamic sourcing, see Using Cube Advisor to support dynamic sourcing, page 218.
For an Intelligent Cube to satisfy the data requirements of a report, the Intelligent
Cube and report must have matching settings for VLDB properties that can affect the
data that is returned.
If you use dynamic sourcing, you must keep your Intelligent Cubes up to date with
any changes to the data in your data warehouse, otherwise reports can return
outdated data. You can use schedules and subscriptions to update the data of
Intelligent Cubes. For information on these techniques, see Updating Intelligent
Cubes using schedules, page 33 and Publishing Intelligent Cubes using a schedule,
page 40.
In general, you should not create restrictive filter qualifications on Intelligent Cubes.
The more restrictive the filter, the less likely it is that the Intelligent Cube can satisfy
the data requirements of reports. Restrictive filters can be applied to the reports that
access Intelligent Cubes.
Reports cannot combine the data from multiple Intelligent Cubes to use dynamic
sourcing. All the data requirements of a report must be satisfied by a single
Intelligent Cube.

2017, MicroStrategy Inc. 200

In-memory Analytics Guide

Dynamic sourcing must be enabled for projects, reports, and Intelligent Cubes; this is
described in the sections listed below:
Enabling or disabling dynamic sourcing for projects, page 206
Enabling or disabling dynamic sourcing for reports, page 208
Enabling or disabling dynamic sourcing for Intelligent Cubes, page 210
To ensure that correct data is available in an Intelligent Cube for a report, you must
verify that the following objects can support dynamic sourcing:
Attributes are available for dynamic sourcing by default. You should disable
dynamic sourcing for attributes if:
Attribute data in fact and lookup tables contains NULL values.
The attribute elements in fact and lookup tables are not identical.
For steps to disable dynamic sourcing for attributes, see Disabling dynamic
sourcing for attributes, page 211.
Metrics are available for dynamic sourcing by default. You should disable
dynamic sourcing for metrics if metric data in fact tables contains NULL values.
For steps to disable dynamic sourcing for metrics, see Disabling dynamic
sourcing for metrics, page 215.
Aggregate tables are available for dynamic sourcing by default. You should disable
dynamic sourcing for aggregate tables if:
Aggregation functions other than Sum are used.
The aggregate table includes different data than is available in lookup and
fact tables. For example, an aggregate table with years 2006, 2007, and 2008
should not be used for dynamic sourcing if your lookup and fact tables only
include the years 2007 and 2008.
For steps to disable dynamic sourcing for aggregate tables, see Disabling
dynamic sourcing for aggregate tables, page 216.
If the report is based on an MDX data source, such as an SAP BW Cube, it can also
use dynamic sourcing, and retrieve data from an Intelligent Cube that is also based
on an MDX data source.
In such a scenario, the following additional conditions apply:
The report and Intelligent Cube must be based on the same source MDX cube.
Filters on the report must meet the following criteria:
Attributes used in the filter should also be on the Intelligent Cubes
definition.
The report filter must include at least the same restrictions as the Intelligent
Cubes filter, if present. For example, if the Intelligent Cube restricts data to
only the year 2010, the report must include the same restriction.

201 2017, MicroStrategy Inc.

 In-memory Analytics Guide

For additional information on creating reports that access MDX sources, refer to the
MicroStrategy MDX Cube Reporting Guide.

Features that can be used with dynamic sourcing

Features that can be supported by dynamic sourcing include, but are not limited to, the
list below:
Security filters
Compound attributes and joint element lists
Conditional metrics
Prompts in a report
Transformation metrics, under the following conditions:
A metric with the same formula and transformation exists in the Intelligent
Cube.
For the hierarchy used for the transformation, the report must be calculated at
the same level as the Intelligent Cube. For example, if the transformation is
along the Time hierarchy and the Intelligent Cube is calculated at the Month
level, the report must also be calculated at the Month level.
Metrics that include Count, Sum, Min, or Max in their formulas
Metrics that include Count Distinct in their formula for reports and Intelligent Cubes
that share the same level of attribute data
Nested metrics for which the inner metric and all attributes used for aggregation are
available in the Intelligent Cube
Non-aggregatable metrics for which the non-aggregation attribute is available in the
Intelligent Cube
Filter qualifications including the functions Exactly, Different from, In list, Not in
list, Greater than, Less than, Greater than or equal to, Less than or equal to,
Between, Not Between, Is Null, and Is Not Null for data types Numeric, BigDecimal,
DateTime, and String
OLAP Services features in the report, including:
View filters
Derived metrics
Dynamic aggregation
OLAP features used in a report, such as:
Pivoting
Banding
Thresholds
Page-by

2017, MicroStrategy Inc. 202

In-memory Analytics Guide

Outline mode
Sorting
Subtotals

Features that prevent the use of dynamic sourcing

Some features prevent the use of dynamic sourcing between Intelligent Cubes and report,
as described in the sections listed below:
Features that prevent reports from using dynamic sourcing, page 203
Features that prevent Intelligent Cubes from being available for dynamic sourcing,
page 204
In addition to these features, if you use filter qualifications on attribute forms in reports
and Intelligent Cubes, a mismatch in the attribute forms used in the qualifications can
prevent dynamic sourcing between the report and Intelligent Cube. For example, a report
includes a filter qualification on the ID form of the Customer attribute. An Intelligent
Cube includes a filter qualification on the Description form of the Customer attribute.
Since different attribute forms are used to restrict the data, a direct relationship between
the data cannot be verified and dynamic sourcing cannot be used to connect the report
to the Intelligent Cube.
You can track various information related to dynamic sourcing that can help determine
why dynamic sourcing succeeded or failed for reports, as described in Tracking the use
of dynamic sourcing, page 227.

Features that prevent reports from using dynamic sourcing

If any of the features listed below are present in reports, the reports are not able to use
dynamic sourcing:
Consolidations
Custom groups
Query Builder or Freeform SQL reports cannot use dynamic sourcing.
Set qualifications in the report filter or metric conditions:
Metric qualifications
Relationship qualifications that do not include a filter in their definition, or that
use a Relate By option other than Use System Default.
OR logical operator used in the report filter to combine qualifications which include
different attributes or attribute forms.
AND NOT or OR NOT logical operators
Metrics that use passthrough functions such as ApplySimple. Alternatively, facts can
be defined using passthrough functions such as ApplySimple. These facts can then be

203 2017, MicroStrategy Inc.

 In-memory Analytics Guide

used to create metrics, which can be used on reports that can support dynamic
sourcing.
Freeform MDX metrics. On reports based on MDX data sources, these are analogous
to metrics with passthrough functions.
Metrics that use facts with extensions or degradations
Data marts
Report as filter used in the report filter
Using any of the options listed below for the following VLDB properties:

VLDB property Options that prevent report from using dynamic sourcing

Downward outer Preserve all rows for metrics higher than template level without report filter
join
Do not do downward outer join for database that support full outer join

OLAP function Preserve backward compatibility with 8.1.x and earlier

support
Note: This setting prevents the report from using dynamic sourcing only under
the following conditions:
The report has metrics that use Rank or NTile functions
The report has metrics that use functions with a SortBy parameter
For information on functions and function parameters, refer to the Functions
Reference.

Features that prevent Intelligent Cubes from being available for

dynamic sourcing
If the features listed below are present in an Intelligent Cube, the Intelligent Cube cannot
be used for dynamic sourcing:
Set qualifications in the Intelligent Cube filter:
Metric qualifications
Relationship qualifications
OR logical operator used in the Intelligent Cube filter to combine qualifications
which include different attributes or attribute forms
AND NOT or OR NOT logical operators used in the Intelligent Cube filter
Passthrough functions such as ApplySimple
Report as filter used in the Intelligent Cube filter
Report limits
For Intelligent Cubes based on MDX data sources, dynamic sourcing is not supported
if the Intelligent Cube uses incremental refresh settings. For information on

2017, MicroStrategy Inc. 204

In-memory Analytics Guide

incremental refresh, see Updating Intelligent Cubes without re-processing:

Incremental Refresh, page 43.
If the features listed below are present in an Intelligent Cube the features may not be
available for dynamic sourcing, but the rest of the Intelligent Cube may be able to
support dynamic sourcing:
Metrics that use facts with fact extensions or degradations are not available for
dynamic sourcing.
Conditional metrics are not available for dynamic sourcing. Conditional metrics are
described in the Advanced Reporting Guide.
Compound metrics that are not defined as smart metrics in an Intelligent Cube are
not available for dynamic sourcing.

Dynamic sourcing for incrementally refreshed

Intelligent Cubes
Apart from the best practices listed above, additional considerations apply when you are
using Intelligent Cubes that are incrementally refreshed. For information on
incrementally refreshing Intelligent Cubes, see Updating Intelligent Cubes without re-
processing: Incremental Refresh, page 43.

Intelligent Cube refresh options supported for dynamic sourcing

The following Intelligent Cube refresh options are supported for dynamic sourcing:
Full refresh
Dynamic refresh
Insert and Update, only if data is being updated for one attribute form
For information on Intelligent Cube refresh settings, see Defining Intelligent Cube
refresh settings, page 44.

Incremental refresh types supported for dynamic sourcing

You can create an incremental refresh filter or report to refresh the data in an Intelligent
Cube. If the Intelligent Cube is refreshed using a filter, the following increment types are
supported:
Update Only
Insert, Update and Delete, only if the data is being updated for one attribute form
If the Intelligent Cube is refreshed using an incremental refresh report, it cannot be used
for dynamic sourcing. For information on incremental refresh filters and reports, see
Defining an incremental refresh filter or report, page 46.

205 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Configuring dynamic sourcing

To enable reports to dynamically connect to an Intelligent Cube for their data
requirements, you must enable various aspects of the MicroStrategy system for dynamic
sourcing.
In general, you must enable projects, reports, and Intelligent Cubes for dynamic
sourcing. Depending on the objects available in or accessed by the reports and Intelligent
Cubes, you may also need to define other objects as available for dynamic sourcing. The
sections listed below describe the requirements and considerations for configuring
dynamic sourcing for various aspects of the MicroStrategy system:
Enabling or disabling dynamic sourcing for projects, page 206
Enabling or disabling dynamic sourcing for reports, page 208
Enabling or disabling dynamic sourcing for Intelligent Cubes, page 210
Disabling dynamic sourcing for attributes, page 211
Disabling dynamic sourcing for metrics, page 215
Disabling dynamic sourcing for aggregate tables, page 216
Accessing the dynamic sourcing VLDB properties for a project, page 207

Enabling or disabling dynamic sourcing for projects

By default, dynamic sourcing is enabled for projects. However, you can disable it for a
project to prevent reports from connecting to Intelligent Cubes through the use of
dynamic sourcing. This allows project administrators to have project-wide control over
the use of dynamic sourcing.
The steps below show you how to enable or disable dynamic sourcing for projects as well
as define default dynamic sourcing behavior for Intelligent Cubes.
For information on defining default dynamic sourcing behavior for reports, Intelligent
Cubes, attributes, metrics, and aggregate tables, see Accessing the dynamic sourcing
VLDB properties for a project, page 207.

Prerequisite
A project has been created in MicroStrategy.

Enabling or disabling dynamic sourcing for a project

1 In MicroStrategy Developer, log in to a project source with a user account that has
administrative privileges.
2 Right-click a project and select Project Configuration. The Project Configuration
Editor opens.
3 In the Categories list, expand Intelligent Cubes, and then select General.

2017, MicroStrategy Inc. 206

In-memory Analytics Guide

4 Perform one of the following to either enable or disable dynamic sourcing:

To enable dynamic sourcing for the project, select the Enable dynamic
sourcing check box.
To disable dynamic sourcing for the project, clear the Enable dynamic
sourcing check box.
5 You can define a default dynamic sourcing behavior for all Intelligent Cubes in a
project using the check boxes described below:
Make Intelligent Cubes available for dynamic sourcing by default:
Select this check box to enable dynamic sourcing for all Intelligent Cubes in a
project. You can clear this check box to disable dynamic sourcing as the default
behavior for all Intelligent Cubes in a project.
You can enable and disable dynamic sourcing for individual Intelligent Cubes, as
described in Enabling or disabling dynamic sourcing for Intelligent Cubes, page
210.
Allow dynamic sourcing even if outer join properties are not set:
Select this check box to allow reports to connect to Intelligent Cubes using
dynamic sourcing even when some outer join properties are not defined.
However, this can cause reports to return incorrect data in scenarios when outer
joins would be helpful.
For example, a report includes the attribute Day and the metric Revenue. It
connects to an Intelligent Cube that includes the attribute Day, and the metrics
Revenue and Cost. For some days there is data for Revenue, but no data for Cost.
If the Intelligent Cube does not support any outer joins, then the data for
Revenue for which there is no data for Cost is not included in the final result. In
this scenario, the report cannot return complete information from the
Intelligent Cube without outer joins.
It is recommended that you define your Intelligent Cube to support and use
outer joins when necessary, as described in Enabling or disabling dynamic
sourcing for Intelligent Cubes, page 210. This ensures that all data is returned.
Be aware that outer joins can cause additional load on your database and may
require larger Intelligent Cubes.
6 Click OK to save your changes to the project and close the Project Configuration
Editor.
You can track various information related to dynamic sourcing that can help determine
why dynamic sourcing succeeded or failed for reports, as described in Tracking the use
of dynamic sourcing, page 227.

Accessing the dynamic sourcing VLDB properties for a project

A number of VLDB properties control whether dynamic sourcing is enabled for reports,
attributes, metrics, and aggregate tables. Defining these VLDB properties at the project
level allows you to define a default dynamic sourcing behavior for these objects. While
this defines the default behavior, any modifications to the VLDB properties for a specific
report, attribute, or metric take precedence over the project-wide default.

207 2017, MicroStrategy Inc.

 In-memory Analytics Guide

The steps below show you how to access the dynamic sourcing VLDB properties for a
project to define project-wide defaults, and includes links to information on how to set
VLDB properties for each object type.

To define dynamic sourcing VLDB properties for a project

1 In MicroStrategy Developer, log in to a project source with a user account with

administrative privileges.
2 Right-click a project and select Project Configuration. The Project Configuration
Editor opens.
3 In the Categories list, expand Project definition, and then select Advanced.
4 In the Analytical Engine VLDB Properties area, click Configure. The VLDB
Properties Editor opens.
5 From the Tools menu, select the Show Advanced Settings option, if it is not
already selected.
6 In the VLDB Settings list, expand Dynamic Sourcing. The dynamic sourcing
VLDB properties are displayed. For information on how each VLDB property can be
used to enable or disable dynamic sourcing, refer to the sections listed below:
Enable Dynamic Sourcing for Report: Enabling or disabling dynamic
sourcing for reports, page 208
Attribute Validation: Disabling dynamic sourcing for attributes, page 211
Metric Validation: Disabling dynamic sourcing for metrics, page 215
Aggregate Table Validation: Disabling dynamic sourcing for aggregate
tables, page 216
String Comparison Behavior: Supporting filtering on attributes for
dynamic sourcing, page 213
7 Click Save and Close to save your changes to the VLDB properties and close the
VLDB Properties Editor.
8 Click OK to save your changes to the project and close the Project Configuration
Editor.

Enabling or disabling dynamic sourcing for reports

By default, dynamic sourcing is enabled for reports. You can enable dynamic sourcing for
a report so that active Intelligent Cubes (that are also enabled for dynamic sourcing) are
checked to see if the report can retrieve its data from an Intelligent Cube. If an
Intelligent Cube fits the data requirements of a report, the report can be run without
executing against the data warehouse.
You can enable dynamic sourcing for reports by modifying the Enable Dynamic
Sourcing for Report VLDB property. This VLDB property has the following options:

2017, MicroStrategy Inc. 208

In-memory Analytics Guide

Disable dynamic sourcing for report: Dynamic sourcing is disabled for

reports.
Enable dynamic sourcing for report: Dynamic sourcing is enabled for reports.
You can enable dynamic sourcing for reports individually or you can enable dynamic
sourcing for all reports within a project. While the definition of the VLDB property at
the project level defines a default for all reports in the project, any modifications at the
report level take precedence over the project level definition. For information on
accessing the VLDB Properties Editor for a project to define a default dynamic sourcing
option for all reports, see Accessing the dynamic sourcing VLDB properties for a
project, page 207.
You can track various information related to dynamic sourcing that can help determine
why dynamic sourcing succeeded or failed for reports, as described in Tracking the use
of dynamic sourcing, page 227.
The procedure below describes how to enable or disable dynamic sourcing for an
individual report.
Prerequisite
A report has been created in MicroStrategy.

To enable or disable dynamic sourcing for a report

1 In MicroStrategy Developer, browse to a report, and then right-click the report and
select Edit. The report opens in the Report Editor.
2 From the Data menu, select VLDB Properties. The VLDB Properties Editor
opens.
3 From the Tools menu, select the Show Advanced Settings option if it is not
already selected.
4 In the VLDB Settings list, expand Dynamic Sourcing, and then select Enable
Dynamic Sourcing for Report.
5 Clear the Use default inherited value check box.
6 Select one of the following options, depending on whether you want to disable or
enable dynamic sourcing for the report:
To disable dynamic sourcing for the report, select Disable dynamic sourcing
for report.
To enable dynamic sourcing for the report, select Enable dynamic sourcing
for report.
7 Click Save and Close to save your changes to VLDB properties and close the VLDB
Properties Editor.
8 Click Save and Close to save the report and close the Report Editor.

209 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Enabling or disabling dynamic sourcing for Intelligent

Cubes
You can enable dynamic sourcing for all Intelligent Cubes in a project, as described in
Enabling or disabling dynamic sourcing for projects, page 206, or you can enable
dynamic sourcing for each Intelligent Cube individually.
By default, dynamic sourcing is disabled for Intelligent Cubes, and they are therefore
unavailable for reports checking whether Intelligent Cubes can satisfy their data
requirements.
While enabling dynamic sourcing for Intelligent Cubes at the project level defines a
default for all Intelligent Cubes in the project, any modifications for individual Intelligent
Cubes take precedence over the project level definition.
The steps below show you how to enable or disable dynamic sourcing for an individual
Intelligent Cube.

Prerequisite
An Intelligent Cube has been created in a project.

To enable or disable dynamic sourcing for an Intelligent Cube

1 In MicroStrategy Developer, browse to an Intelligent Cube, and then right-click the

Intelligent Cube and select Edit. The Intelligent Cube opens in the Report Editor.
2 From the Data menu, select Configure Intelligent Cube. The Intelligent Cube
Options dialog box opens.
3 In the Dynamic Sourcing area, use the Make Intelligent Cubes available for
dynamic sourcing by default options to enable or disable dynamic sourcing for
the Intelligent Cube:
To enable dynamic sourcing for the Intelligent Cube, select Enabled.
To disable dynamic sourcing for the Intelligent Cube, select Disabled.
To specify that the Intelligent Cube inherits its dynamic sourcing behavior from
the project settings, select Use Default Project-Level Behavior.
4 In the Dynamic Sourcing area, use the Allow dynamic sourcing even if
outer join properties are not set options to determine if reports can connect to
Intelligent Cubes using dynamic sourcing even when some outer join properties are
not defined:
Enabled: Select this option to allow reports to connect to Intelligent Cubes
using dynamic sourcing even when some outer join properties are not defined.
However, this can cause incorrect data to be returned in scenarios when outer
joins would be helpful.

2017, MicroStrategy Inc. 210

In-memory Analytics Guide

For example, a report includes the attribute Day and the metric Revenue. It
connects to an Intelligent Cube that includes the attribute Day and the metric
Revenue, and it also includes the metric Cost. For some days there is data for
Revenue, but there is no data for Cost. If the Intelligent Cube does not support
any outer joins, then the values for Revenue which do not have corresponding
values for Cost arent returned. In this scenario, the report cannot return
complete information from the Intelligent Cube without outer joins.
Disabled: Select this option to prohibit reports from connecting to Intelligent
Cubes using dynamic sourcing when some outer join properties are not defined.
Selecting this option avoids the possibility of displaying incorrect data in reports.
You can define your Intelligent Cube to support and use outer joins when
necessary. This ensures all data is returned. However, outer joins can cause
additional load on your database and require larger Intelligent Cubes. You can
enable this support by defining the Metric Join Type, described below.
Metric Join Type: Any metrics included in the Intelligent Cube that are to
be available for dynamic sourcing must be defined to use outer joins in the
Intelligent Cube. With the Intelligent Cube open, from the Data menu,
select Report Data Options. In the Report Data Options dialog box,
expand Calculations, and select Metric Join Type. For each metric to
make available for dynamic sourcing, change the Join Type to Outer.
Click OK to save your changes.
For details and examples of VLDB properties, see the Supplemental Reference
for System Administration.
Use Default Project-Level Behavior: Select this option to define the
Intelligent Cube to inherit its dynamic sourcing behavior from the project
settings discussed in Enabling or disabling dynamic sourcing for projects, page
206.
5 Click OK. The Intelligent Cube Options dialog box closes and you are returned to the
Intelligent Cube.
6 Click Save and Close to save your changes and close the Report Editor.
You can track various information related to dynamic sourcing that can help determine
why dynamic sourcing succeeded or failed for reports, as described in Tracking the use
of dynamic sourcing, page 227.

Disabling dynamic sourcing for attributes

Attributes are available for dynamic sourcing by default, but there are some data
modeling conventions that should be considered when using dynamic sourcing.
In general, if attributes use outer joins, accurate data can be returned to reports from
Intelligent Cubes through dynamic sourcing. However, if attributes use inner joins,
which is more common, the resulting data set may be incomplete. In such cases, you
should verify that the attribute data can be correctly represented through dynamic
sourcing.
Two scenarios can cause attributes that use inner joins to return incorrect or incomplete
data when dynamic sourcing is used:

211 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Attribute information in lookup and fact tables includes NULL values.

All attribute elements in fact tables are not also present in lookup tables.
These scenarios are uncommon.
If some attributes fit these scenarios, you can disable dynamic sourcing when these
attributes are used in reports and Intelligent Cubes. You can enable and disable dynamic
sourcing for attributes by modifying the Attribute Validation VLDB property. This
VLDB property has the following options:
Attribute columns in fact tables and lookup tables do not contain
NULLs and all attribute elements in fact tables are present in lookup
tables: This is the default option for attributes, which enables attributes for dynamic
sourcing.
Attribute columns in fact tables and lookup tables may contain NULLs
and/or some attribute elements in fact tables are not present in lookup
tables: This option disables dynamic sourcing for attributes. This setting should be
used if your attribute data is not modeled to support dynamic sourcing. The inclusion
of NULLs in your attribute data, or a mismatch between available attribute data in
your fact and lookup tables, can cause incorrect data to be returned to reports from
Intelligent Cubes through dynamic sourcing.
You can disable dynamic sourcing for attributes individually or you can disable dynamic
sourcing for all attributes within a project. While the definition of the VLDB property at
the project level defines a default for all attributes in the project, any modifications at the
attribute level take precedence over the project level definition. For information on
accessing the VLDB Properties Editor for a project to define a default dynamic sourcing
option for all attributes, see Accessing the dynamic sourcing VLDB properties for a
project, page 207.
The steps below show you how to disable or enable dynamic sourcing for an individual
attribute. If your database is case-sensitive, you should also review Supporting filtering
on attributes for dynamic sourcing, page 213 to ensure that dynamic sourcing can
correctly return data for your attributes.
Prerequisite
An attribute has been created in a project.

To enable or disable dynamic sourcing for an attribute

1 In MicroStrategy Developer, browse to an attribute, right-click on it, and select Edit.

The attribute opens in the Attribute Editor.
2 From the Tools menu, select VLDB Properties. The VLDB Properties Editor
opens.
3 From the Tools menu, select the Show Advanced Settings option if it is not
already selected.
4 In the VLDB Settings list, expand Dynamic Sourcing, and then select
Attribute Validation.
5 Clear the Use default inherited value check box.

2017, MicroStrategy Inc. 212

In-memory Analytics Guide

6 Select one of the options depending on whether you want to disable or enable
dynamic sourcing for an attribute:
To enable attributes to use dynamic sourcing (the default option), select
Attribute columns in fact tables and lookup tables do not contain
NULLs and all attribute elements in fact tables are present in
lookup tables.
To disable dynamic sourcing for attributes unless outer joins are used for the
attribute, select Attribute columns in fact tables and lookup tables
may contain NULLs and/or some attribute elements in fact tables
are not present in lookup tables. This setting should be used if your
attribute data is not modeled to support dynamic sourcing.
7 Click Save and Close to save your changes to VLDB properties and close the VLDB
Properties Editor.
8 Click Save and Close to save the attribute and close the Attribute Editor.
You can track various information related to dynamic sourcing that can help determine
why dynamic sourcing succeeded or failed for reports, as described in Tracking the use
of dynamic sourcing, page 227.

Supporting filtering on attributes for dynamic sourcing

To ensure that dynamic sourcing can return the correct results for attributes, you must
also verify that filtering on attributes achieves the same results when executed against
your database, versus an Intelligent Cube.
A filter on attributes can potentially return different results when executing against the
database, compared to using dynamic sourcing to execute against an Intelligent Cube.
This can occur if your database is case-sensitive and you create filter qualifications that
qualify on the text data of attribute forms.
If your database is case-sensitive, this is enforced for the filter qualification. However,
filtering for an Intelligent Cube is handled by the Analytical Engine which does not
enforce case sensitivity.
Consider a filter qualification that filters on customers that have a last name beginning
with the letter h. If your database is case-sensitive and uses uppercase letters for the first
letter in a name, a filter qualification using a lowercase h is likely to return no data.
However, this same filter qualification on the same data stored in an Intelligent Cube
returns all customers that have a last name beginning with the letter h, uppercase or
lowercase.
You can define attributes to either allow filter qualifications to be completed without
enforcing case sensitivity, or to disable dynamic sourcing if these types of filters are used
on attributes. You can configure this dynamic sourcing behavior for attributes by
modifying the String Comparison Behavior VLDB property. This VLDB property has the
following options:
Use case insensitive string comparison with dynamic sourcing: This is
the default option for attributes. When attempting to use dynamic sourcing, filter

213 2017, MicroStrategy Inc.

 In-memory Analytics Guide

qualifications can qualify on the text data of attribute forms without enforcing case
sensitivity.
This is a good option if your database does not enforce case sensitivity. In this
scenario, dynamic sourcing returns the same results that would be returned by the
filter qualification if the report was executed against the database.
Do not allow any string comparison with dynamic sourcing: This option
disables dynamic sourcing for attributes when a filter qualification is used to qualify
on the text data of attribute forms.
This is a good option if your database is case sensitive. In this scenario, dynamic
sourcing could return different results than what would be returned by the filter
qualification if the report was executed against the database.
You can modify this VLDB property for attributes individually or you can modify it for all
attributes within a project. While the definition of the VLDB property at the project level
defines a default for all attributes in the project, any modifications at the attribute level
take precedence over the project level definition. For information on accessing the
VLDB Properties Editor for a project to define a default dynamic sourcing option for all
attributes, see Accessing the dynamic sourcing VLDB properties for a project, page 207.
The procedure below describes how to modify the String Comparison Behavior
VLDB property for an individual attribute.
Prerequisites
An attribute has been created in a project.

To modify the String Comparison Behavior VLDB property for an

attribute

1 In MicroStrategy Developer, browse to an attribute, then right-click the attribute and

select Edit. The attribute opens in the Attribute Editor.
2 From the Tools menu, select VLDB Properties. The VLDB Properties Editor
opens.
3 From the Tools menu, select the Show Advanced Settings option if it is not
already selected.
4 In the VLDB Settings list, expand Dynamic Sourcing, and then select String
Comparison Behavior.
5 Clear the Use default inherited value check box.
6 Select one of the options depending on whether you want to disable or enable
dynamic sourcing for an attribute:
Use case insensitive string comparison with dynamic sourcing: This
is the default option for attributes. When dynamic sourcing is used, it allows
filter qualifications to qualify on the text data of attribute forms without
enforcing case sensitivity.

2017, MicroStrategy Inc. 214

In-memory Analytics Guide

Do not allow any string comparison with dynamic sourcing: This

option disables dynamic sourcing for attributes when a filter qualification is used
to qualify on the text data of attribute forms.
7 Click Save and Close to save your changes to VLDB properties and close the VLDB
Properties Editor.
8 Click Save and Close to save the attribute and close the Attribute Editor.
You can track various information related to dynamic sourcing that can help determine
why dynamic sourcing succeeded or failed for reports, as described in Tracking the use
of dynamic sourcing, page 227.

Disabling dynamic sourcing for metrics

Metrics are available for dynamic sourcing by default, but some data modeling
conventions should be considered when using dynamic sourcing.
In general, if metrics use outer joins, accurate data can be returned to reports from
Intelligent Cubes through dynamic sourcing. However, if metrics use inner joins, which
is more common, you should verify that the metric data can be correctly represented
through dynamic sourcing.
If the fact table that stores data for metrics includes NULL values for metric data, this
can cause metrics that use inner joins to return incomplete data when dynamic sourcing
is used. This scenario is uncommon.
If some metrics do fit this scenario, you can disable dynamic sourcing when these
metrics are used in reports and Intelligent Cubes. You can enable and disable dynamic
sourcing for metrics by modifying the Metric Validation VLDB property. This VLDB
property has the following options:
Enable dynamic sourcing for metric: This is the default option for metrics,
which enables metrics for dynamic sourcing.
Disable dynamic sourcing for metric: This option disables dynamic sourcing
for metrics. This setting should be used if your metric data is not modeled to support
dynamic sourcing. For example, the inclusion of NULLs in fact tables that contain
your metric data can cause incorrect data to be returned to reports from Intelligent
Cubes through dynamic sourcing.
You can disable dynamic sourcing for metrics individually or you can disable dynamic
sourcing for all metrics within a project. While the definition of the VLDB property at
the project level defines a default for all metrics in the project, any modifications at the
metric level take precedence over the project level definition. For information on
accessing the VLDB Properties Editor for a project to define a default dynamic sourcing
option for all metrics, see Accessing the dynamic sourcing VLDB properties for a
project, page 207.
The procedure below describes how to disable or enable dynamic sourcing for an
individual metric.
Prerequisite
A metric has been created in a project.

215 2017, MicroStrategy Inc.

 In-memory Analytics Guide

To enable or disable dynamic sourcing for a metric

1 In MicroStrategy Developer, browse to a metric, then right-click the metric and

select Edit. The metric opens in the Metric Editor.
2 From the Tools menu, point to Advanced Settings, and then select VLDB
Properties. The VLDB Properties Editor opens.
3 From the Tools menu, select the Show Advanced Settings option if it is not
already selected.
4 In the VLDB Settings list, expand Dynamic Sourcing, and then select Metric
Validation.
5 Clear the Use default inherited value check box.
6 Select one of the options depending on whether you want to disable or enable
dynamic sourcing for a metric:
Enable dynamic sourcing for metric: This is the default option, which
enables dynamic sourcing for the metric.
Disable dynamic sourcing for metric: This option disables dynamic
sourcing for the metric. This setting should be used if your metric data is not
modeled to support dynamic sourcing.
7 Click Save and Close to save your changes to VLDB properties and close the VLDB
Properties Editor.
8 Click Save and Close to save the attribute and close the Attribute Editor.
You can track various information related to dynamic sourcing that can help determine
why dynamic sourcing succeeded or failed for reports, as described in Tracking the use
of dynamic sourcing, page 227.

Disabling dynamic sourcing for aggregate tables

Reports that use aggregate tables are available for dynamic sourcing by default, but there
are some data modeling conventions that should be considered when using dynamic
sourcing.
In general, aggregate tables allow accurate data to be returned to reports from Intelligent
Cubes through dynamic sourcing. However, if the aggregate tables use an aggregation
other than Sum, or there is different data between aggregate tables and other tables in
the data warehouse, this can cause aggregate tables to return incorrect data when
dynamic sourcing is used. An example of an aggregate table not containing the same data
is if an aggregate table includes data for years 2006, 2007, and 2008 but the lookup table
for Year only includes data for 2007 and 2008.
These scenarios are uncommon.
If some aggregate tables do fit these scenarios, you can disable dynamic sourcing when
these aggregate tables are used in reports and Intelligent Cubes. You can enable and

2017, MicroStrategy Inc. 216

In-memory Analytics Guide

disable dynamic sourcing for aggregate tables by modifying the Aggregate Table
Validation VLDB property. This VLDB property has the following options:
Aggregate tables contain the same data as corresponding detail tables
and the aggregation function is SUM: This is the default option for aggregate
tables, which enables aggregate tables for dynamic sourcing.
Aggregate tables contain either less data or more data than their
corresponding detail tables and/or the aggregation function is not
SUM: This option disables dynamic sourcing for aggregate tables. This setting should
be used if your aggregate tables are not modeled to support dynamic sourcing. The
use of an aggregation function other than Sum or the mismatch of data in your
aggregate tables with the rest of your data warehouse can cause incorrect data to be
returned to reports from Intelligent Cubes through dynamic sourcing.
You can disable dynamic sourcing individually for reports that use aggregate tables or you
can disable dynamic sourcing for all reports that use aggregate tables within a project.
While the definition of the VLDB property at the project level defines a default for all
reports in the project, any modifications at the report level take precedence over the
project level definition. For information on accessing the VLDB Properties Editor for a
project to define a default dynamic sourcing option for all metrics, see Accessing the
dynamic sourcing VLDB properties for a project, page 207.
The procedure below describes how to disable or enable dynamic sourcing for an
individual report that uses an aggregate table.
Prerequisite
A report has been created in a project.

To enable or disable dynamic sourcing for a report that uses an

aggregate table

1 In MicroStrategy Developer, browse to a report, then right-click the report and select
Edit. The report opens in the Report Editor.
2 From the Data menu, select VLDB Properties. The VLDB Properties Editor
opens.
3 From the Tools menu, select the Show Advanced Settings option if it is not
already selected.
4 In the VLDB Settings list, expand Dynamic Sourcing, and then select
Aggregate Table Validation.
5 Clear the Use default inherited value check box.
6 Select one of the options depending on whether you want to disable or enable
dynamic sourcing for a report that uses aggregate tables:
Aggregate tables contain the same data as corresponding detail
tables and the aggregation function is SUM: This is the default option for
aggregate tables, which enables aggregate tables for dynamic sourcing.

217 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Aggregate tables contain either less data or more data than their
corresponding detail tables and/or the aggregation function is not
SUM: This option disables dynamic sourcing for aggregate tables. This setting
should be used if your aggregate tables are not modeled to support dynamic
sourcing.
7 Click Save and Close to save your changes to VLDB properties and close the VLDB
Properties Editor.
8 Click Save and Close to save the report and close the Report Editor.

Using Cube Advisor to support dynamic

sourcing
MicroStrategy Cube Advisor allows you to create and support a dynamic sourcing strategy
that can best support the reports in your projects. Cube Advisor provides the following
features for creating and supporting a dynamic sourcing strategy:
Analyzes reports to determine if their report definitions can support the use of
dynamic sourcing.
Recommends and creates Intelligent Cubes that could provide data to reports using
dynamic sourcing. This includes the following:
Recommends Intelligent Cube definitions for Intelligent Cubes that could
provide data to reports via dynamic sourcing. This includes providing the
number of reports that could connect to the Intelligent Cube using dynamic
sourcing, as well as the names and locations of these reports.
You can also supply a MicroStrategy Enterprise Manager report to include more
information on the performance benefits of each Intelligent Cube as part of your
dynamic sourcing strategy. For information on locating and using this Enterprise
Manager report, see Enterprise Manager report for Cube Advisor, page 220.
Creates the Intelligent Cubes you select to create to support your dynamic
sourcing strategy. These Intelligent Cubes are created in a folder along with
shortcuts to all the reports that can connect to the Intelligent Cube using
dynamic sourcing. For information on creating Intelligent Cubes using Cube
Advisor, see Reviewing and creating recommended Intelligent Cubes, page 222.

Prerequisites for using Cube Advisor

You must complete a few prerequisites before using Cube Advisor to recommend and
create Intelligent Cubes to support a dynamic sourcing strategy. These prerequisites
include:
Enable dynamic sourcing for the project and other aspects of the MicroStrategy
system. For steps to configure and enable dynamic sourcing, see Configuring
dynamic sourcing, page 206.
Create the metric levels log file used to track the use of dynamic sourcing. For steps
to create this log file, see Creating the metric levels log, page 219.

2017, MicroStrategy Inc. 218

In-memory Analytics Guide

Locate and execute the MicroStrategy Enterprise Manager report to provide

additional performance benefit information on each Intelligent Cube recommended
by Cube Advisor. This is an optional prerequisite. For information on this report, see
Enterprise Manager report for Cube Advisor, page 220.

Creating the metric levels log

The metric levels log file is one of the files that can be used to track the use of dynamic
sourcing (see Tracking the use of dynamic sourcing, page 227).
Cube Advisor uses this log file to help recommend and create Intelligent Cubes to support
dynamic sourcing. The steps below show you how to create this log file using the
MicroStrategy Diagnostics and Performance Logging tool.
If you install and use Cube Advisor on the same machine that hosts Intelligence Server,
the metric levels log is created automatically. In this scenario, you do not have to
perform the steps provided below.

To create the metric levels log file

1 From the Windows Start menu, point to Programs, then point to

MicroStrategy Tools, and select Diagnostics Configuration. The
MicroStrategy Diagnostics and Performance Logging tool opens.
2 In the Select Configuration drop-down list, select from one of two configurations
to see the current default setup, as follows:
Machine Default: The components and counters that are displayed reflect the
client machine.
CastorServer instance: The components and counters that are displayed
reflect server-specific features.

When you select the CastorServer instance, you can select whether to use the
default configuration. On the Diagnostics Configuration tab, this check
box is named Use Default Diagnostics Configuration; on the
Performance Configuration tab, this check box is called Use Default
Performance Configuration. This check box refers to the Machine Default
settings. No matter what you have changed and saved on either tab when
CastorServer instance is selected, if you check the Use Default
Configuration box, the system logs whatever information is configured for
Machine Default at run time.

3 On the Diagnostics tab, locate the Dynamic Sourcing component.

4 For the Metric Levels Log dispatcher, select the check box in the Console Log
column.
5 For the Metric Levels Log dispatcher, in the File Log column, click the drop-
down list and select <New>. The Log Destination Editor opens.

219 2017, MicroStrategy Inc.

 In-memory Analytics Guide

6 In the File name field, type a name for the metric levels log. In later examples, the
log file is named MetricLevelsLog.
7 You can leave the default settings for the other options, and then click Save. Click
Close to close the Log Destination Editor.
8 For the Metric Levels Log dispatcher, in the File Log column, click the drop-
down list and select the metrics level log file that you created in the previous steps.
9 From the File menu, select Save. The metric levels log is created in the Log
directory within the MicroStrategy common files. The default directory is
C:\Program Files\Common Files\MicroStrategy\ Log.

Enterprise Manager report for Cube Advisor

You can also use a MicroStrategy Enterprise Manager report to include more
information on the performance benefits of each Intelligent Cube as part of your
dynamic sourcing strategy. When using this Enterprise Manager report, the information
that can be returned for each potential Intelligent Cube includes:
Jobs: The number of jobs that would not have to be executed against the data
warehouse if the Intelligent Cube is created to support your dynamic sourcing
strategy.
Result Rows: The number of rows of data for all reports that could be returned
from the Intelligent Cube rather than the data warehouse if the Intelligent Cube is
created to support your dynamic sourcing strategy.
Users: The number of users that execute the reports that could connect to the
Intelligent Cube using dynamic sourcing if the Intelligent Cube is created to support
your dynamic sourcing strategy.
Database Time: The amount of time to execute SQL statements and retrieve the
results from the data warehouse that is saved if the Intelligent Cube is created to
support your dynamic sourcing strategy.
This report is available with MicroStrategy Enterprise Manager. Search the Enterprise
Manager project for the report named Report Request Statistics per Project.
To use this report with Cube Advisor, you must execute the report and export it as a
Microsoft Excel file or a text file. The steps below show you how to execute and export
this report in MicroStrategy Developer or Web:
Executing and exporting the Enterprise Manager report in Developer, page 220
Executing and exporting the Enterprise Manager report in MicroStrategy Web,
page 221

Executing and exporting the Enterprise Manager report in Developer

The steps below show you how to execute and export this report in MicroStrategy
Developer.

2017, MicroStrategy Inc. 220

In-memory Analytics Guide

To execute and export the Enterprise Manager report in Developer

1 In Developer, log in to the Enterprise Manager project.

2 Locate the Enterprise Manager report for Cube Advisor, by searching the Enterprise
Manager project for the report named Report Request Statistics per Project.
3 Right-click the Report Request Statistics per Project report and select Run.
The Report Editor opens and the report is executed.
4 From the Data menu, select Export Options. The Excel Options dialog box opens.
5 In the Application drop-down list, select MS Excel Worksheet.
6 On the Appearance tab, select the following export options:
In the Exported fields area, select the Report Data check box. All other
check boxes must be cleared.
In the Formatting area, select the Apply formatting and Use 6.x layout
check boxes.
7 Click OK to save your changes and return to the Report Editor.
8 From the Data menu, point to Export To, and then select MS Excel.
9 Once the export is complete, the exported report is displayed in Microsoft Excel.
10 Save the Excel file as a tab delimited text file (.txt).
11 If you use an internationalized MicroStrategy environment that uses various
character sets for your data, you must open the tab delimited text file in a text editor
and save the file with a UTF-8 encoding.

Executing and exporting the Enterprise Manager report in MicroStrategy Web

The steps below show you how to execute and export this report in MicroStrategy Web.

To execute and export the Enterprise Manager report in MicroStrategy

Web

1 In MicroStrategy Web, log in to the Enterprise Manager project.

2 Locate the Enterprise Manager report for Cube Advisor. Search the Enterprise
Manager project for the report named Report Request Statistics per Project.
3 Click the Report Request Statistics per Project report to execute it.
4 From the Home menu, point to Export, and then select Plain text. The Export
Options page opens.
5 In the Delimiter drop-down list, select Tab.
6 Clear all available check boxes.

221 2017, MicroStrategy Inc.

 In-memory Analytics Guide

7 In the Remove extra column drop-down list, select Yes.

8 Click Export. The File Download dialog box opens.
9 Click Save. The Save As dialog box opens.
10 Type a name and select a location for the text file, and click Save to save the text
file.
11 If you use an internationalized MicroStrategy environment that uses various
character sets for your data, you must open the tab delimited text file in a text editor
and save the file with a UTF-8 encoding.

Reviewing and creating recommended Intelligent

Cubes
After you have completed the prerequisites for using Cube Advisor, you can begin using
Cube Advisor to create Intelligent Cubes.
The steps below show you how to use Cube Advisor to create Intelligent Cubes to support
dynamic sourcing for the reports in your project.
Prerequisites
You must complete the prerequisites described in Prerequisites for using Cube
Advisor, page 218 before using Cube Advisor to recommend and create Intelligent
Cubes to support a dynamic sourcing strategy.
In order to use Cube Advisor, you must log in to a project using a MicroStrategy user
account with the following privileges:
Privileges required to execute reports and documents.
Privileges required to create folders in a MicroStrategy project.
Privileges required to create Intelligent Cubes.

You can use Integrity Manager to perform a before and after test to identify which
reports actually connect to a suggested Intelligent Cube and also to test data
integrity.

To review and create recommended Intelligent Cubes using Cube

Advisor

1 From the Windows Start menu, point to Programs, then point to

MicroStrategy Tools, and select Cube Advisor. Cube Advisor opens.
2 You can analyze a new set of reports using Cube Advisor or use the results of a
previous Cube Advisor analysis:
To use Cube Advisor to analyze a new set of reports, from the Tools menu,
select Options. The Options dialog box opens. Continue to step 3 in this
procedure and complete all of the steps provided.

2017, MicroStrategy Inc. 222

In-memory Analytics Guide

If you have previously used Cube Advisor to create Intelligent Cubes to support
dynamic sourcing for the reports in your project, you can use the results file of
this analysis. From the File menu, select Open. In the Open dialog box, select
the Cube Advisor results file to use and click Open.
The results of a Cube Advisor analysis are stored in the MicroStrategy common
files folder (the default is C:\Program Files\
Common Files\MicroStrategy). The name of the file is in the format
ProjectName.details.txt. For example, analyzing the MicroStrategy
Tutorial project creates a Cube Advisor results file named MicroStrategy
Tutorial.details.txt.
To complete the Cube Advisor analysis to review and create Intelligent Cubes,
complete the steps beginning with To review Cube Advisor analysis, page 224.
3 Click ... (browse) to supply the following files to support Cube Advisor and define the
following options:
Metric Level File: The metric levels log file is one of the files that can be used
to track the use of dynamic sourcing. Cube Advisor uses this log file to help
recommend and create Intelligent Cubes to support dynamic sourcing.
If you install and use Cube Advisor on the same machine that hosts Intelligence
Server, the metric levels log file is automatically created by Cube Advisor. In this
scenario you do not need to create the metric levels log file or provide the
location for the file. Otherwise, you must create this file manually and provide
the directory it is stored in.
When manually creating the metric levels log file, the file is created in the Log
directory within the MicroStrategy common files. The default directory is
C:\Program Files\Common Files\ MicroStrategy\Log. For steps on
how to create this file, see Creating the metric levels log, page 219.
Enterprise Manager File: You can also supply a MicroStrategy Enterprise
Manager report to include more information on the performance benefits of
each Intelligent Cube as part of your dynamic sourcing strategy. For information
on locating, executing, and exporting this report as well as the information
provided by supplying the report, see Enterprise Manager report for Cube
Advisor, page 220.
Ignore Reports That Are Covered By Existing Cubes: Select this option
to exclude reports that already connect to an Intelligent Cube from the Cube
Advisor analysis. This prevents Cube Advisor from analyzing and recommending
Intelligent Cubes for reports that already connect to Intelligent Cubes.
Ignore Reports Not In Enterprise Manager File: Select this option to
exclude reports that are not included in the Enterprise Manager report from
Cube Advisor analysis. This allows Cube Advisor to focus only on the reports that
were included in the Enterprise Manager report for further performance
analysis.
4 Click OK to close the Options dialog box and return to Cube Advisor.
5 Provide the following connection information:

223 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Computer Name: Type the name of the machine on which Intelligence Server
is hosted.
Port: Type the port number used for Intelligence Server. The default is 34952.
User: Type the MicroStrategy users user name to connect to a MicroStrategy
project. The MicroStrategy user must have the privileges listed in the
prerequisites for these steps.
Password: Type the password for the MicroStrategy user.
6 Click Connect. MicroStrategy projects are displayed.
7 Select a project, and then click Connect To Project. The Report Selection page
opens.

If you supplied the Enterprise Manager report, you must select the project that
was analyzed using the Enterprise Manager report.

8 Expand the folders of the project to locate the reports to analyze with Cube Advisor.
Selecting a check box for a report includes the report in the analysis. Selecting a
check box for a folder includes all reports in that folder and all reports in folders
within the folder in the analysis.
9 Once you have selected all the reports to analyze with Cube Advisor, click Get Cube
Recommendations. The Analyzing Reports page opens and report analysis begins.
To analyze reports, only the report SQL is analyzed, which allows a large number of
reports to be analyzed without having to execute the report SQL against the database.

If the analysis completes with a message that no reports can use dynamic
sourcing, this can be caused by various scenarios:

The features used in the reports prevent the reports from being able to
use dynamic sourcing. To review a list of features that prevent the use of
dynamic sourcing, see Features that prevent the use of dynamic
sourcing, page 203.
The metric levels log file was not created properly. Review the steps to
create a metrics level log file (see Creating the metric levels log, page
219) and attempt the Cube Advisor analysis again.
Dynamic sourcing is not enabled for the project, reports, or other objects
and features in the project. For information on configuring dynamic
sourcing, see Configuring dynamic sourcing, page 206.

To review Cube Advisor analysis

10 Once analysis is complete, the Cube Recommendations page opens. This page allows
you to review the recommended Intelligent Cubes, and select which Intelligent Cubes
to create. Depending on whether you supplied an Enterprise Manager report, you
can review Intelligent Cubes as described below:

2017, MicroStrategy Inc. 224

In-memory Analytics Guide

If you did not supply an Enterprise Manager report, the information on the
recommended Intelligent Cubes that is displayed includes the number of reports
that could connect to the Intelligent Cube using dynamic sourcing.
You can select a recommended Intelligent Cube to display the attributes and
metrics that would be included in the Intelligent Cube, as well as a list of reports
that could connect to the Intelligent Cube using dynamic sourcing.
If you supplied an Enterprise Manager report, a Flash visualization provides
detailed information on the recommended Intelligent Cubes, an example of
which is shown below:

Some of the benefits of the Flash visualization include:

You can click Jobs, Result Rows, Users, and DB Time to sort the
Intelligent Cubes by these various usage and performance statistics. These
usage and performance statistics are displayed as microcharts, which are
aligned with the report coverage microcharts provided for each Intelligent
Cube. For information on these usage and performance statistics, see
Enterprise Manager report for Cube Advisor, page 220.
You can select an Intelligent Cube to see how creating it affects various
performance statistics.
The area at the top of the Flash visualization provides a summary of the
estimated performance improvements that would come from building the
selected set of Intelligent Cubes.
You can expand an Intelligent Cube to review more information on the
attributes and metrics that would be included in the Intelligent Cube, as well

225 2017, MicroStrategy Inc.

 In-memory Analytics Guide

as a list of reports that could connect to the Intelligent Cube using dynamic
sourcing.
This also includes information on how many reports that could connect to
the Intelligent Cube require certain attributes and metrics. This analysis
allows you to determine the benefit of including each attribute and metric in
an Intelligent Cube.
Each Intelligent Cube includes a microchart, which represents the subset of
reports that could connect to the Intelligent Cube using dynamic sourcing. A
bar in the microchart represents that the report is covered by the Intelligent
Cube and no bar means that report is not covered by the Intelligent Cube. By
moving the cursor over the microchart, a tooltip is displayed that lists the
various reports that could connect to the Intelligent Cube using dynamic
sourcing.
Once you select a specific Intelligent Cube, the bars for all reports covered by
that Intelligent Cube become blue. This color coding also helps to visually
analyze the overlap of reports across Intelligent Cubes. If you see two
Intelligent Cubes have a very similar report coverage distribution, then only
one of the two Intelligent Cubes should be created.
11 Once you have reviewed the information, select the check boxes for the Intelligent
Cubes to create using Cube Advisor, and then click Create Cube Design. The
Browse for Folder dialog box opens.
12 Select a folder to create the Intelligent Cubes in. Each Intelligent Cube is created in a
separate folder that is created within the folder you select. Click OK. The Cube
Design Options dialog box opens.
13 Select one of the following options:
Design Intelligent Cubes with outer join properties: Select this option
to enable outer joins on all Intelligent Cubes to be created. This ensures that all
warehouse data is captured; however, this can potentially increase the size of the
Intelligent Cubes.
Allow Dynamic Sourcing without enabling outer join properties:
Select this option to allow reports to connect to Intelligent Cubes using dynamic
sourcing even when some outer join properties are not defined. However, this
can cause incorrect data to be returned in certain scenarios.
For additional information on enabling dynamic sourcing for Intelligent Cubes, see
Enabling or disabling dynamic sourcing for Intelligent Cubes, page 210.
Click OK to begin creating the Intelligent Cubes. The Creating Cubes dialog box
opens.
14 Once the Intelligent Cubes are created, click OK.
Each Intelligent Cube is created in a separate folder. Each folder also contains shortcuts
to all the reports that can connect to the Intelligent Cube using dynamic sourcing. This
provides easy recognition of the reports that can connect to each Intelligent Cube using
dynamic sourcing. You must publish the Intelligent Cubes to allow the reports to connect
to the new Intelligent Cubes using dynamic sourcing. For information on how to publish
Intelligent Cubes, see Publishing Intelligent Cubes, page 39.

2017, MicroStrategy Inc. 226

In-memory Analytics Guide

The results of the Cube Advisor analysis are stored in the MicroStrategy common files
folder (the default is C:\Program Files\Common Files\ MicroStrategy). The
name of the file is in the format ProjectName.details.txt. For example, analyzing
the MicroStrategy Tutorial project creates a Cube Advisor results file named
MicroStrategy Tutorial.details.txt. You can use this file with Cube Advisor
to review and create Intelligent Cubes at another time. This scenario is described in the
procedure To review and create recommended Intelligent Cubes using Cube Advisor,
page 222.

Tracking the use of dynamic sourcing

If you enable dynamic sourcing for a project, you can track various information related
to dynamic sourcing that can determine why dynamic sourcing succeeds or fails for
reports. By determining why dynamic sourcing fails for a given report, you can modify
your reports, Intelligent Cubes, and other objects to allow reports to utilize dynamic
sourcing.
You can track the use of dynamic sourcing with the MicroStrategy Diagnostics and
Performance Logging tool. For information on how to use the Diagnostics and
Performance Logging tool, see the System Administration Guide.
This tool allows you to enable or disable various logs related to dynamic sourcing, which
record various information about dynamic sourcing, including why dynamic sourcing
cannot be used in different scenarios. The sections listed below describe the dynamic
sourcing log files and error codes that can be tracked using the Diagnostics and
Performance Logging tool:
Dynamic sourcing log files, page 227
Dynamic sourcing error codes and explanations, page 233

Dynamic sourcing log files

In the Diagnostics and Performance Logging tool, all of the dynamic sourcing log files
are available on the Diagnostics Configuration tab as part of the Dynamic Sourcing
component, as shown in the image below. For information on accessing the Diagnostics
and Performance Logging tool, see the System Administration Guide.

227 2017, MicroStrategy Inc.

 In-memory Analytics Guide

With the Diagnostics and Performance Logging tool, you can enable the following
dynamic sourcing log files to track information about the use of dynamic sourcing:
Intelligent Cube parse log, page 228
Report parse log, page 229
Mismatch log, page 230
Extended mismatch log, page 231
Metric levels log, page 232
Fact levels log, page 233

Intelligent Cube parse log

Information about an Intelligent Cube is included in the Intelligent Cube parse log when
the Intelligent Cube is published and made available by Intelligence Server.
This log displays whether an Intelligent Cube has been defined to be available for
dynamic sourcing. It also lists any metrics included in the Intelligent Cube that are
disabled for dynamic sourcing, and other issues that may prevent the Intelligent Cube
from being available for dynamic sourcing. For explanations of various error codes that
can be included in this log, see Dynamic sourcing error codes and explanations, page
233.
If the entries in this log for an Intelligent Cube end with CMI_NO_ERROR, this means
the Intelligent Cube is available to reports for dynamic sourcing. Be aware that some of
the metrics in an Intelligent Cube still may not be available for dynamic sourcing. You
can review this log to determine whether any metrics for the Intelligent Cube are not
available for dynamic sourcing.
You can also display this log in the SQL View of Intelligent Cubes. This can help
determine which reports use dynamic sourcing to connect to the Intelligent Cube, as well

2017, MicroStrategy Inc. 228

In-memory Analytics Guide

as why some reports cannot use dynamic sourcing to connect to the Intelligent Cube.
The steps below show you how to include this log for Intelligent Cubes in a project.

To display the Intelligent Cube parse log in Intelligent Cubes

1 In Developer, log in to a project.

2 Right-click the project and select Project Configuration. The Project
Configuration Editor opens.
3 Expand the Project definition category, and select the Advanced category.
4 Within the Analytical Engine VLDB properties area, click Configure. The
VLDB Properties Editor opens.

The VLDB property defined using the steps below can also be defined for
individual Intelligent Cubes. To access the VLDB Properties Editor for an
Intelligent Cube, with the Intelligent Cube open, from the Data menu, select
VLDB Properties.

5 From the Tools menu, ensure that the Show Advanced Settings option is
selected.
6 In the VLDB Settings list, expand Dynamic Sourcing, and then select Enable
Cube Parse Log in SQL View.
7 Clear the Use default inherited value check box.
8 Select Enable Cube Parse Log in SQL View.
9 Click Save and Close to save your changes and close the VLDB Properties Editor.
10 Click OK to close the Project Configuration Editor.

Report parse log

When a report is executed, information about the report is included in the report parse
log.

Reports connected to a specific Intelligent Cube do not send information to the

report parse log.

This log lists any reasons why a report cannot use dynamic sourcing. For explanations of
various error codes that can be included in this log, see Dynamic sourcing error codes
and explanations, page 233.
If the entries in this log for a report end with CMI_NO_ERROR, this means the report
can use dynamic sourcing. However, this does not necessarily mean that dynamic
sourcing is used; an Intelligent Cube that meets the data requirements for the report
must be available. To review information on whether the report was able to find a
matching Intelligent Cube, you can review the mismatch log described in Mismatch log,
page 230.

229 2017, MicroStrategy Inc.

 In-memory Analytics Guide

The report parse log can increase in size quickly and thus is best suited for
troubleshooting purposes.

You can also display this log in the SQL View of reports. This log helps determine
whether a report can use dynamic sourcing to connect to an Intelligent Cube. The steps
below show you how to include this log for reports in a project.

To display the report parse log in reports

1 In Developer, log in to a project.

2 Right-click the project and select Project Configuration. The Project
Configuration Editor opens.
3 Expand the Project definition category, and select the Advanced category.
4 Within the Analytical Engine VLDB properties area, click Configure. The
VLDB Properties Editor opens.

The VLDB property defined using the steps below can also be defined for
individual reports. To access the VLDB Properties Editor for a report, with the
report open, from the Data menu, select VLDB Properties.

5 From the Tools menu, ensure that the Show Advanced Settings option is
selected.
6 In the VLDB Settings list, expand Dynamic Sourcing, and then select Enable
Report Parse Log in SQL View.
7 Clear the Use default inherited value check box.
8 Select Enable Report Parse Log in SQL View.
9 Click Save and Close to save your changes and close the VLDB Properties Editor.
10 Click OK to close the Project Configuration Editor.

Mismatch log
When a report that can use dynamic sourcing is executed, which can be verified with the
report parse log (Report parse log, page 229), and Intelligent Cubes are available for
dynamic sourcing, information about whether a matching Intelligent Cube can be found
for the report is included in the mismatch log.

The mismatch log can increase in size quickly and thus is best suited for
troubleshooting purposes.

This log lists any reasons why a report cannot use a specific Intelligent Cube to satisfy its
data requirements. For explanations of various error codes that can be included in this
log, see Dynamic sourcing error codes and explanations, page 233.

2017, MicroStrategy Inc. 230

In-memory Analytics Guide

If the entries in this log for a report and Intelligent Cube combination end with CMI_
NO_ERROR, this means the report can use dynamic sourcing to access the Intelligent
Cube.
If dynamic sourcing cannot be used because of a metric (CMI_NO_GOOD_METRIC_
FOUND), information on why the metric prevents the use of dynamic sourcing is
provided in the extended mismatch log. For information on this log, see Extended
mismatch log, page 231 below.
You can also display this log in the SQL View of reports. This log helps determine why a
report that can use dynamic sourcing cannot connect to a specific Intelligent Cube. The
steps below show you how to include this log for reports in a project.

To display the mismatch log in reports

1 In Developer, log in to a project.

2 Right-click the project and select Project Configuration. The Project
Configuration Editor opens.
3 Expand the Project definition category, and select the Advanced category.
4 Within the Analytical Engine VLDB properties area, click Configure. The
VLDB Properties Editor opens.

The VLDB property defined using the steps below can also be defined for
individual reports. To access the VLDB Properties Editor for a report, with the
report open, from the Data menu, select VLDB Properties.

5 From the Tools menu, ensure that the Show Advanced Settings option is
selected.
6 In the VLDB Settings list, expand Dynamic Sourcing, and then select Enable
Mismatch Log in SQL View.
7 Clear the Use default inherited value check box.
8 Select Enable Mismatch Log in SQL View.
9 Click Save and Close to save your changes and close the VLDB Properties Editor.
10 Click OK to close the Project Configuration Editor.

Extended mismatch log

When a report that can use dynamic sourcing is executed, which can be verified with the
report parse log (Report parse log, page 229), and Intelligent Cubes are available for
dynamic sourcing, information about whether a matching Intelligent Cube can be found
for the report is included in the mismatch log (Mismatch log, page 230).
However, if dynamic sourcing cannot be used because of a metric (CMI_NO_GOOD_
METRIC_FOUND), information on why the metric prevents the use of dynamic sourcing

231 2017, MicroStrategy Inc.

 In-memory Analytics Guide

is provided in the extended mismatch log. This information is listed for every metric that
prevents the use of dynamic sourcing.

The extended mismatch log can increase in size quickly and thus is best suited for
troubleshooting purposes.

You can also display this log in the SQL View of reports. This log helps determine why a
metric prevents the use of dynamic sourcing is provided in the extended mismatch log.
The steps below show you how to include this log for reports in a project.

To display the extended mismatch log in reports

1 In Developer, log in to a project.

2 Right-click the project and select Project Configuration. The Project
Configuration Editor opens.
3 Expand the Project definition category, and select the Advanced category.
4 Within the Analytical Engine VLDB properties area, click Configure. The
VLDB Properties Editor opens.

The VLDB property defined using the steps below can also be defined for
individual reports. To access the VLDB Properties Editor for a report, with the
report open, from the Data menu, select VLDB Properties.

5 From the Tools menu, ensure that the Show Advanced Settings option is
selected.
6 In the VLDB Settings list, expand Dynamic Sourcing, and then select Enable
Extended Mismatch Log in SQL View.
7 Clear the Use default inherited value check box.
8 Select Enable Extended Mismatch Log in SQL View.
9 Click Save and Close to save your changes and close the VLDB Properties Editor.
10 Click OK to close the Project Configuration Editor.

Metric levels log

When a report that can use dynamic sourcing is executed, which can be verified with the
report parse log (Report parse log, page 229), information about the report is included in
this log, including:
The lowest level attributes on a report, which defines the report level
The formulas of metrics on the report
This information can help determine what attributes and metrics need to be included in
an Intelligent Cube for the report to be able to connect to it through dynamic sourcing.

2017, MicroStrategy Inc. 232

In-memory Analytics Guide

This log file can also be used with MicroStrategy Cube Advisor to recommend and create
Intelligent Cubes that could be connected to by reports using dynamic sourcing. For
information on how Cube Advisor allows you to create and support a dynamic sourcing
strategy that can best support the reports in your projects, see Using Cube Advisor to
support dynamic sourcing, page 218.

Fact levels log

When a report that can use dynamic sourcing is executed, which can be verified with the
report parse log (Report parse log, page 229), information about the report is included in
this log. This log tracks the same information as the metrics levels log (Metric levels log,
page 232). The only difference is that the fact levels log lists the facts used for metrics
rather than the metric formulas.

Dynamic sourcing error codes and explanations

There are various reasons for why a report cannot use dynamic sourcing. To help
determine why reports in your projects are not able to use dynamic sourcing, the table
below provides explanations of all of the error codes that can be triggered for dynamic
sourcing scenarios. These error codes are included in the dynamic sourcing log files,
which are described in Dynamic sourcing log files, page 227.

Error Code Explanation

CMI_AGG_METRIC_ Dynamic sourcing cannot be used because a metric included in the

BRANCH_WITH_ Intelligent Cube uses zero checking, which is enabled with the Zero Check
VLDB property. Using zero checking on metrics in Intelligent Cubes causes
ZERO_CHECKING
the Intelligent Cubes to be unavailable for dynamic sourcing.

CMI_AGGREGATION_ Dynamic sourcing cannot be used because a transformation metric is

ON_ included in the Intelligent Cube and it cannot be aggregated to the level
required on the report.
ATTRIBUTES_
RELATED_TO_
TRANSFORMATION_
ATTRIBUTES

CMI_ALL_METRICS_ The Intelligent Cube included metrics, but the metrics were later removed
REMOVED_ or no longer enable dynamic sourcing. This Intelligent Cube cannot be used
for dynamic sourcing.
FROM_CUBE

CMI_ANDNOT_OR_ Dynamic sourcing cannot be used because filter qualifications are

ORNOT_IN_ combined with AND NOT or OR NOT logical operators.
FILTER

CMI_ATTRIBUTE_ Dynamic sourcing cannot be used because an attribute form present in the
UNAVAILABLE report is not available in the Intelligent Cube.

CMI_BAD_OR_IN_ Dynamic sourcing cannot be used because two filter qualifications on

FILTER different attributes or attribute elements are combined with the logical
operator OR.

233 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Error Code Explanation

CMI_CG_OR_ A custom group or consolidation is used on the report. Dynamic sourcing

CONSOLIDATION cannot be used for reports that include custom groups or consolidations.

CMI_COMPLEX_ Dynamic sourcing cannot be used for the Intelligent Cube because a
METRIC_ metrics formula is too complex. Metrics that are too complex include
compound metrics that are not defined as smart metrics, and simple
EXPRESSION_ON_
metrics that use a formula other than a single aggregation function of a
CUBE single fact. You can remove the metric or modify the metrics formula so
that dynamic sourcing can be supported for the Intelligent Cube. For
information on simple and compound metrics, see the Advanced
Reporting Guide.

CMI_COUNT_ Dynamic sourcing cannot be used because the Count Distinct function is
DISTINCT_FOUND used.

CMI_CSI_OR_ The report cannot use dynamic sourcing because it is connected to a

ELEMENT_BROWSING specific Intelligent Cube, or the user is browsing the elements of an
attribute from within the report.

CMI_CUBE_ Dynamic sourcing cannot be used because an attribute form used in the
TEMPLATE_ reports filter qualifications is not available in the Intelligent Cube.
MISSING_
FILTER_
ATTRIBUTE_FORM

CMI_CUBES_FOR_ Dynamic sourcing is disabled for the report. To enable dynamic sourcing for
AD_HOC_ a report, see Enabling or disabling dynamic sourcing for reports, page
208.
DISABLED_FOR_
REPORT

CMI_CUBES_FOR_ Dynamic sourcing is disabled for the project. To enable dynamic sourcing
AD_HOC_ for a project, see Enabling or disabling dynamic sourcing for projects,
page 206.
DISABLED_
MASTERSWITCH

CMI_DB_ONLY_ Dynamic sourcing cannot be used because a passthrough or database

FUNCTION_IN_ function such as ApplySimple is used in the filter.
FILTER

CMI_DB_ONLY_ Dynamic sourcing cannot be used because a passthrough or database

FUNCTION_IN_ function such as ApplySimple is used in a metrics formula.
METRIC_FORMULA

2017, MicroStrategy Inc. 234

In-memory Analytics Guide

Error Code Explanation

CMI_DIFFERENT_ Dynamic sourcing cannot be used because of one of the following

AGG_TABLE_HIT scenarios:
A metric retrieves its data from different aggregate tables for the report
and Intelligent Cube.
The metric uses an aggregation function other than Sum for the
aggregate table.
The metric uses the Sum aggregation function, but the aggregate table
is disabled for dynamic sourcing.
For information on disabling dynamic sourcing for aggregate tables, see
Disabling dynamic sourcing for aggregate tables, page 216.

CMI_DIFFERENT_ Dynamic sourcing cannot be used because the report and Intelligent Cube
DB_ROLES use different database instances.

CMI_DIFFERENT_ This error signifies that, due to differing metric formulas, a metric in an
METRIC_FORMULA Intelligent Cube is not a match for a metric on a report. All metrics on an
Intelligent Cube are checked to determine if they are a match for a metric
on a report. This process is done until a match is found, or no match is
found and dynamic sourcing is not used (finding no matches for a metric
returns the error CMI_NO_GOOD_CANDIDATE_METRICS_
FOUND).

CMI_DIFFERENT_ Dynamic sourcing cannot be used because a metric on the report and a
TRANSFORMATIONS_ metric on the Intelligent Cube use different transformations.
USED

CMI_DIMMETRIC_ This error commonly occurs because a compound metric is included in the
BRANCH_IN_CUBE Intelligent Cube, which is preventing the Intelligent Cube from being
available for dynamic sourcing. Only compound metrics that are defined as
smart metrics can be included in Intelligent Cubes.

CMI_DISTINCT_ Dynamic sourcing cannot be used because the Distinct parameter is used
FOUND_ON_ in the aggregation of a metric and the level of data does not match
between the report and the Intelligent Cube. To support dynamic sourcing
AGGREGATION_
when a Distinct parameter is used in an aggregation, the Intelligent Cube
FUNCTION and report must contain the exact same level of data.

CMI_DISTINGUISH_ The report cannot connect to the Intelligent Cube using dynamic sourcing
DUPLICATED_ because the Distinguish Duplicated Rows VLDB property is not defined the
same in the report and the Intelligent Cube. For information on this and
ROWS_MISMATCH_
other VLDB properties, see the Supplemental Reference System
FOR_CUBE_AND_ Administration.
REPORT

CMI_FACT_ENTRY_ Dynamic sourcing cannot be used because a metric uses a fact with a fact
LVL_ERROR extension or degradation. For information on fact level extensions, see the
Facts chapter in the Project Design Guide.

235 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Error Code Explanation

CMI_FACT_ENTRY_ Dynamic sourcing cannot be used because the fact entry level of a metric
LVL_GREATER_ on the report and the filtering criteria of the report cannot be satisfied by
the Intelligent Cube. For example, a report includes a metric that has a fact
THAN_A_FILTER_
entry level of Year, and the filter includes a qualification on the Month
LEVEL attribute, which is at a lower logical level. If the lower level attribute used in
the filter (for this example, Month) is not included in the Intelligent Cube,
dynamic sourcing cannot be used. To support dynamic sourcing, the lower
level attribute must be included in the Intelligent Cube.

CMI_FACT_NOT_ The report cannot connect to the Intelligent Cube using dynamic sourcing
SUPPORTED_AT_ because a metric on the report is at a higher level than what is available on
the Intelligent Cube. For example, a report requires metric data to be
REQUIRED_CUBE_
displayed at a yearly level, but the Intelligent Cube can only display metric
LEVEL data at the quarterly level. Dynamic sourcing cannot be used to connect
the report to this Intelligent Cube.

CMI_FILTER_FACT_ Dynamic sourcing cannot be used because a fact is included in a filter. This
NODE_NOT_ can only occur if you use one of the SQL optimization options available with
the SQL Global Optimization VLDB property.
SUPPORTED

CMI_FILTER_KEY_ Dynamic sourcing cannot be used because an attribute form is used in a

ATTRIBUTE_ conditional metric included on the report or in the report filter, and the
attribute form is not included in the Intelligent Cube.
UNAVAILABLE

CMI_FILTER_ Dynamic sourcing cannot be used because a metric qualification is used in

METRIC_EXPR_ the report or Intelligent Cube.
NODE_NOT_
SUPPORTED

CMI_FILTER_ Dynamic sourcing cannot be used because a metric qualification is used in

METRIC_NODE_NOT_ the report or Intelligent Cube.
SUPPORTED

CMI_FILTER_NOT_ The Intelligent Cube cannot be used for dynamic sourcing for the report
RESTRICTIVE_ because it cannot be verified that the Intelligent Cube filter on a particular
metric is less restrictive than the report filter.
ENOUGH

CMI_FILTER_PRED_ Dynamic sourcing cannot be used because a metric qualification is used in

NODE_NOT_ the report or Intelligent Cube.
SUPPORTED

CMI_FILTER_ Dynamic sourcing cannot be used because a relationship qualification that

RELATIONSHIP_ cannot be supported is used in the report or Intelligent Cube.
NODE_NOT_
SUPPORTED

CMI_FILTER_ Dynamic sourcing cannot be used because a relationship qualification that

TABLE_NODE_NOT_ cannot be supported is used in the report or Intelligent Cube.
SUPPORTED

2017, MicroStrategy Inc. 236

In-memory Analytics Guide

Error Code Explanation

CMI_FILTER_UNIT_ Dynamic sourcing cannot be used because a report is used as a filter of the
ROOT_NODE_ report or Intelligent Cube.
NOT_SUPPORTED

CMI_FILTERING_ Dynamic sourcing cannot be used because an attribute form is used in a

KEY_ conditional metric included on the report or in the report filter, and the
attribute form is not included in the Intelligent Cube.
ATTRIBUTE_
UNAVAILABLE

CMI_FILTERS_ The Intelligent Cube cannot be used for dynamic sourcing for the report
CANNOT_ENSURE_ because it cannot be verified that the Intelligent Cube filter is less
restrictive than the report filter.
ALL_DATA_NEEDED_
IS_IN_CUBE

CMI_FULL_OUTER_ Dynamic sourcing cannot be used because full outer joins are not
JOIN_NOT_ supported or enabled in the project or by the database.
SUPPORTED

CMI_GROUP_BY_ Dynamic sourcing cannot be used because an attribute form used to

ATTRIBUTE_ define the level for a level metric is not included in the Intelligent Cube.
UNAVAILABLE

CMI_IF_NO_ Dynamic sourcing cannot be used for the report because the report
METRIC_REPORT_ contains no metrics, and the Intelligent Cube does not use the same level
as the report. For reports with no metrics, Intelligent Cubes must have the
AND_CUBE_LOWEST_
same level as these reports to use dynamic sourcing.
LVL_MUST_BE_THE_
SAME

CMI_ Dynamic sourcing cannot be used because a filter qualification includes

INCOMPATIBLE_ two incompatible data types. One scenario in which this can occur is when
identity forms are used to filter data, and smaller identity numbers use an
DATA_
integer type, while larger identity numbers use big decimal.
TYPES_IN_FILTER

CMI_INCOMPLETE_ The report or Intelligent Cube includes an attribute that is defined as

HIERARCHY_ possibly containing null values, which disables dynamic sourcing for the
report or Intelligent Cube. For information on how to disable or enable
DANGEROUS_
dynamic sourcing for an attribute, see Disabling dynamic sourcing for
ATTRIBUTE attributes, page 211.

CMI_INVALID_ Dynamic sourcing cannot be used because an invalid filter qualification

BETWEEN_IN_ that uses the Between operator is used. The first value must be less than
or equal to the second value.
FILTER

CMI_JOINT_ Joint child relationships and many-to-many relationships are not supported
PARENT_OR_JOINT_ for dynamic sourcing.
CHILD_OR_MANY_
TO_MANY_NOT_
SUPPORTED

237 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Error Code Explanation

CMI_METRIC_AND_ The metric in an Intelligent Cube cannot be used for dynamic sourcing
TEMPLATE_ because it is a level metric. For information on level metrics, see the
Advanced Reporting Guide.
LVL_NOT_
MATCHING_IN_CUBE

CMI_METRIC_ Dynamic sourcing cannot be used because the break by parameter for a
BREAK_BY_NOT_ON_ metric on the Intelligent Cube is not included in the Intelligent Cube. The
break by parameter determines when calculations such as running
CUBE_TEMPLATE
summations or moving averages restart their calculations. For example, a
running sum of revenue uses a break by parameter of the Year attribute.
Without the Year attribute on the Intelligent Cube, the metric cannot be
calculated correctly.

CMI_METRIC_ Dynamic sourcing cannot be used because a cross join is used for a metric.
CROSS_JOINED_NO_
GROUP_BY

CMI_METRIC_ Dynamic sourcing cannot be used because an attribute form is used in a

FITLER_KEY_NOT_ conditional metric included on the report or the report filter, and the
attribute form is not included in the Intelligent Cube.
IN_TEMPLATE

CMI_METRIC_ Dynamic sourcing cannot be used because an attribute form used to

GROUP_BY_KEY_ define the level for a level metric is not included in the Intelligent Cube.
This can also be caused by defining the filtering of a target for a level
NOT_IN_TEMPLATE
metric to be absolute or ignore.

CMI_METRIC_NOT_ The Intelligent Cube cannot be used for dynamic sourcing because it
OJ includes a metric that does not use outer joins.
Intelligent Cubes of this type can be made available for dynamic sourcing
by using outer joins for all metrics in the Intelligent Cube, or selecting the
Allow dynamic sourcing even if outer join properties are
not set option for the Intelligent Cube (see Enabling or disabling dynamic
sourcing for Intelligent Cubes, page 210).

CMI_METRIC_NOT_ The metric has been disabled for dynamic sourcing, as described in
SAFE Disabling dynamic sourcing for metrics, page 215.

CMI_METRIC_WITH_ The Intelligent Cube cannot be used for dynamic sourcing because it
CONDITIONALITY_ includes a conditional metric. For information on conditional metrics, see
the Advanced Reporting Guide.
IN_CUBE

CMI_METRICS_ Dynamic sourcing cannot be used because nested aggregation is used for
WITH_NESTED_ a metric. Nested aggregation is not supported for dynamic sourcing.
AGGREGATION_NOT_
SUPPORTED

CMI_NO_ERROR No error occurred, the report can use dynamic sourcing if an Intelligent
Cube with the correct data requirements can be found.

2017, MicroStrategy Inc. 238

In-memory Analytics Guide

Error Code Explanation

CMI_NO_GOOD_ Dynamic sourcing cannot be used because no suitable metric can be found
CANDIDATE_ in the Intelligent Cube for a metric included in the report.
METRICS_FOUND

CMI_NON_AGG_ Dynamic sourcing cannot be used because a non-aggregation function

FUNCTION_FOUND such as First is used, and the metric level in the report is different than the
metric level in the Intelligent Cube.

CMI_NON_AGG_NOT_ Dynamic sourcing cannot be used because a metric uses a function that
REPORT_ cannot use dynamic aggregation by default. This prevents the metric from
being able to display data at the level defined for the Intelligent Cube. For
LEVEL_METRIC_
information on functions that are not dynamically aggregated by default,
FOUND see Metrics that are not dynamically aggregated by default, page 248.

CMI_NON_HDA_ Dynamic sourcing cannot be used because the Intelligent Cube uses
USER_CANNOT_USE_ MultiSource Option to connect to multiple data sources, but the user
running the report dose not have the privileges to use the MultiSource
HDA_CUBE
Option. For information on MultiSource Option, see the Project Design
Guide.

CMI_ Dynamic sourcing cannot be used because a metric that cannot be

NONAGGREGATABLE_ aggregated is used, and the metric level in the report is different than the
metric level in the Intelligent Cube.
METRIC

CMI_ The Intelligent Cube cannot be used for dynamic sourcing because it
NONAGGREGATION_ includes a metric that cannot be aggregated, and the metric level in the
report is different than the metric level in the Intelligent Cube.
IN_METRIC

CMI_NULL_ Dynamic sourcing cannot be used because the option selected for the Null
CHECKING_FOR_ checking for Analytical Engine VLDB Property is different for the report and
Intelligent Cube. The same option must be used to match a report and
ANAL_
Intelligent Cube for dynamic sourcing.
ENGINE_MISMATCH

CMI_OLD_OLAP_ Dynamic sourcing cannot be used because old OLAP Services behavior is
FUNCTION_IN_ enabled.
METRIC To use the new OLAP Services behavior, select the Use OLAPs new
behavior option for the OLAP New Behavior VLDB Property.

CMI_PERFORM_OR_ Dynamic sourcing cannot be used because filtering qualifications could not
FAILED be combined correctly with the logical operator OR. To support dynamic
sourcing you can remove or modify filter qualifications. For information on
how filter qualifications can be used with dynamic sourcing, see Best
practices for supporting dynamic sourcing, page 200.

CMI_REPORT_IS_ The report is either a:

XDA OLAP cube report connected to SAP BI, Microsoft Analysis Services, or
Hyperion Essbase
Query Builder report
Freeform SQL report
These types of reports cannot use dynamic sourcing.

239 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Error Code Explanation

CMI_REPORT_ A report limit is present on the Intelligent Cube. Intelligent Cubes with
LIMIT_ON_CUBE_ report limits cannot be used for dynamic sourcing.
FOUND

CMI_REPORT_OLAP_ Dynamic sourcing cannot be used because the break by parameter for a
METRIC_ metric on a report is not included in the Intelligent Cube. The break by
parameter determines when calculations such as running summations or
BREAK_BY_
moving averages restart their calculations. For example, a running sum of
MISSING_FROM_ revenue uses a break by parameter of the Year attribute. Without the Year
CUBE_ attribute on the Intelligent Cube, the metric cannot be calculated correctly.
TEMPLATE

CMI_REPORT_OLAP_ Dynamic sourcing cannot be used because the sort by parameter for a
METRIC_SORT_BY_ metric is not included in the Intelligent Cube. The sort by parameter
determines the order in which calculations such as running summations or
MISSING_FROM_
moving averages perform their calculations. For example, a running sum of
CUBE_ revenue uses a sort by parameter of the Quarter attribute. Without the
TEMPLATE Quarter attribute on the Intelligent Cube, the metric cannot be calculated
correctly.

CMI_REPORT_ Dynamic sourcing cannot be used because an attribute included in the

TEMPLATE_ report is not included in the Intelligent Cube.
ATTRIBUTE_
MISSING_FROM_
CUBE_TEMPLATE

CMI_REPORTS_ Dynamic sourcing cannot be used because the report uses metrics that are
WITH_ZERO_RL_ not at the report level. To support dynamic sourcing for these types of
reports, Intelligent Cubes must support outer joins. For information on
METRICS_CAN_
outer join support with Intelligent Cubes, see Enabling or disabling
ONLY_HIT_CUBE_ dynamic sourcing for Intelligent Cubes, page 210.
WITH_FOJ_SUPPORT

CMI_SECURITY_ Dynamic sourcing cannot be used because an attribute used to define the
FILTER_KEY_ security filter of the user executing the report is not included in the
Intelligent Cube.
ATTRIBUTE_
UNAVAILABLE

CMI_SECURITY_ Dynamic sourcing cannot be used because an attribute used to define the
FILTER_LEVEL_ security filter of the user executing the report is not included in the
Intelligent Cube.
ATTRIBUTE_
UNAVAILABLE

CMI_STRING_ Dynamic sourcing cannot be used because the report uses a filter
COMPARISON_NOT_ qualification that qualifies on the text data of an attribute form, and these
types of qualifications have been disabled for dynamic sourcing. For
ALLOWED
information on the String Comparison Behavior VLDB property
which defines this functionality, see Supporting filtering on attributes for
dynamic sourcing, page 213.

2017, MicroStrategy Inc. 240

In-memory Analytics Guide

Error Code Explanation

CMI_STRING_ Dynamic sourcing cannot be used because the report uses a sort on the
COMPARISON_NOT_ text data of an attribute form, and these types of sorts have been disabled
for dynamic sourcing. For information on the String Comparison
ALLOWED_IN_SORT_
Behavior VLDB property which defines this functionality, see Supporting
BY filtering on attributes for dynamic sourcing, page 213.

CMI_UNEXPECTED_ The report is of a type that cannot use dynamic sourcing, which includes:
REPORT_TYPE MDX cube report
Query Builder report
Freeform SQL report
Data marts

CMI_ Dynamic sourcing cannot be used because an unsupported condition is

UNSATISFIABLE_ included in the filter. For a list of features that are not supported for
dynamic sourcing, see Features that prevent the use of dynamic sourcing,
CONDITION_IN_
page 203.
FILTER

CMI_UNSUPPORTED_ Dynamic sourcing cannot be used because an element that is not

ELEMENT_IN_ supported for dynamic sourcing is included in the filter. For a list of
features that are not supported for dynamic sourcing, see Features that
FILTER
prevent the use of dynamic sourcing, page 203.

CMI_UNSUPPORTED_ Dynamic sourcing cannot be used because an unsupported expression is

EXPR_TYPE_ included in a filter. For a list of features that are not supported for dynamic
sourcing, see Features that prevent the use of dynamic sourcing, page
IN_FILTER
203.

CMI_UNSUPPORTED_ Dynamic sourcing cannot be used because an unsupported filter type is

FILTER_NODE used. For a list of features that are not supported for dynamic sourcing, see
Features that prevent the use of dynamic sourcing, page 203.

CMI_UNSUPPORTED_ Dynamic sourcing cannot be used because an unsupported function is

FUNCTION_IN_ included in a filter. Supported functions in filters are listed in Features that
can be used with dynamic sourcing, page 202.
FILTER

CMI_USER_LOCALE_ The report cannot connect to the Intelligent Cube using dynamic sourcing
NOT_ because the Intelligent Cube is not available for the locale of the user
viewing the report. For MicroStrategy projects that support multiple
SUPPORTED_IN_
languages and character sets, users can view reports that display data for
CUBE their locale. To use dynamic sourcing, an Intelligent Cube must be available
for the users locale.

CMI_USER_DOESNT_ The report cannot connect to the Intelligent Cube using dynamic sourcing
HAVE_ because the user account being used does not have the Use Dynamic
Sourcing privilege. This privilege is required to use dynamic sourcing.
DYNAMIC_
SOURCING_
PRIVILEGE

CMI_VLDB_ The report cannot connect to the Intelligent Cube using dynamic sourcing
SETTING_ because the options used for various VLDB properties do not match

241 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Error Code Explanation

MISMATCH_ between these two objects. For a list of VLDB properties that prevent
FOR_CUBE_AND_ reports from using dynamic sourcing, see Features that prevent reports
from using dynamic sourcing, page 203. For information on VLDB
REPORT
properties, see the Supplemental Reference for System Administration.

CMI_ZERO_ The report cannot use dynamic sourcing because it does not contain any
METRICS_NEEDED metrics, and no matching Intelligent Cube with no metrics can be found.

CMI_UNSUPPORTED_ The Intelligent Cube cannot be used for dynamic sourcing due to an
INCREMENTAL_ unsupported incremental refresh that modifies the data in the Intelligent
Cube.
REFRESH

CMI_RAGGED_ The report cannot be used for dynamic sourcing because it has no metrics,
HIERARCHY_NO_ and attributes from ragged hierarchies. For more information, see the MDX
Cube Reporting Guide.
METRICS_NOT_
SUPPORTED

CMI_NONAGG_BY_ The Intelligent Cube cannot be used for dynamic sourcing because it uses
LKP_ON_INCR_ non-aggregation by lookup and is incrementally refreshed
REFR_CUBE_NOT_
SUPPORTED

CMI_DIFFERENT_ The MDX-based Intelligent Cube cannot be used for dynamic sourcing
MDX_SOURCE_ because the report and Intelligent Cube point to different MDX data
sources.
TABLE_USED

2017, MicroStrategy Inc. 242

 9
DYNAMIC AGGREGATION
Displaying Data On The Fly
Dynamic aggregation is an OLAP Services feature that allows you to change the level of
report aggregation on the fly, while you are reviewing the report results. This feature
allows metric values to be aggregated at different levels based on the attributes included
on the report without having to re-execute the report against the data warehouse.
Dynamic aggregation occurs when you move attributes and metrics between the Report
Objects pane and the report grid.
To better understand dynamic aggregation, consider a report that includes two attributes,
Region and Category, and two metrics, Revenue and Units Sold. A subset of the report
results are shown below.

To remove an attribute from the report without using dynamic aggregation, right-clicking
it (the Category attribute is used for this example) and select Remove from Report.
The data for Revenue and Units Sold is aggregated to the Region level, resulting in the
report below.

2017, MicroStrategy Inc. 243

In-memory Analytics Guide

Notice that the Category attribute is not in the Report Objects pane, and the report
remains a Standard report as indicated in the bottom right corner.
When you remove an attribute or metric from the report, a message is displayed that
indicates the manipulation causes the report to be re-executed. This is because standard
metric aggregation needs to be re-executed against the data warehouse, and therefore
requires new report SQL to be generated.
Now consider the same report, but this time you use dynamic aggregation to return a
different view of the data. Instead of removing Category from the report, Category is
moved to the Report Objects pane, as shown in the image below.

Although the report data is exactly the same as the previous report with standard
aggregation, dynamic aggregation has the following differences:
No re-execution and no new SQL required: Dynamic aggregation does not
require re-execution against the data warehouse. Aggregating data within the report
can improve the performance of your system by reducing the load on the data
warehouse. Dynamic aggregation also improves performance by returning the new
report results as soon as the attribute or metric is moved to Report Objects, instead
of having to wait for the results to be returned from the data warehouse.
Attributes remain in Report Objects: Category is now in the Report Objects
pane and is no longer displayed with bold formatting. Since Category is part of the
report definition, it can be used to define the view of the report. For example, you
can build a view filter to return Revenue only for the electronics category. A standard

244 2017, MicroStrategy Inc.

 In-memory Analytics Guide

report would have to use the report filter to filter on an attribute not on the report,
which would also require re-execution against the data warehouse.
With attributes available in the Report Objects pane, you can easily add them back
onto the report grid.
OLAP report: The report is marked as OLAP (as indicated in the bottom right
corner of the Report Editor) because of the dynamic aggregation performed.
This chapter discusses the following aspects of dynamic aggregation:
Using dynamic aggregation, page 245
Functions used in dynamic aggregation, page 246
View filter effect on dynamic aggregation, page 257

Using dynamic aggregation

To change the aggregation level of a report, you must either remove an attribute from a
report entirely, or use dynamic aggregation to remove the attribute from the report grid
only. With dynamic aggregation, the attribute is still a part of the report definition and is
included in the Report Objects.
To use dynamic aggregation, right-click an attribute on a report grid and select Remove
from Grid, as shown below.

Be careful not to select Remove from Report. If you select this option, the
attribute is completely removed from the report definition, and the report is re-
executed against the data warehouse.

You need the Use Report Objects Window (Developer) and/or the Web Use Report
Objects Window (Web) privileges to use dynamic aggregation. These privileges are part of
OLAP Services.

2017, MicroStrategy Inc. 245

In-memory Analytics Guide

Another benefit of using dynamic aggregation is that the attributes removed from the
report grid can be easily included back onto the report grid or page-by area. To do this,
right-click an attribute in the Report Objects pane and select Add to Column, Add to
Row, or Add to Page-by to add an attribute from the Report Objects pane onto the
report. The options to move an attribute to the report are shown in the image below.

You can also move attribute forms between the Report Objects pane and the report grid.
If you only move an attribute form and not the attribute itself, dynamic aggregation is
not triggered. For example, if the attribute forms Last Name and First Name for the
attribute Customer are displayed on a report, you can move First Name to the Report
Objects pane without triggering dynamic aggregation. The same First Name attribute
form can be moved back to the report grid without triggering dynamic aggregation.

An attribute must have at least one attribute form displayed to be on the report
grid.

Functions used in dynamic aggregation

The dynamic aggregation feature of a metric dictates what function to use when the
Analytical Engine must dynamically aggregate the metric. You can modify the dynamic
aggregation function from the Subtotals / Aggregation tab of the Metric Editor. A
metric has a default aggregation function if the metric is defined with certain functions,
as described below:
A metric defined with one or more of the functions Sum, Count, Minimum,
Maximum, and Product has a default aggregation function. For more information on
metrics that have a default dynamic aggregation function, see Metrics with default
dynamic aggregation functions, page 247.
A metric defined with any other functions than the ones listed above does not have a
default aggregation function. No aggregation function is used as the default and the
dynamic aggregation of one of these metrics returns a null value. The null value is
replaced with dashes (--) to indicate that the metric cannot be calculated at the

246 2017, MicroStrategy Inc.

 In-memory Analytics Guide

higher level. For more information on metrics that do not have a default dynamic
aggregation function, see Metrics that are not dynamically aggregated by default,
page 248.

The exception is a shortcut metric defined in a report, document, or Visual Insight

quick dashboard created in MicroStrategy Web. Dynamic aggregation and subtotals
are calculated correctly for these shortcut metrics, even if they do not contain the
functions listed above. For instructions to create shortcut metrics, which are a type
of derived metric, see the MicroStrategy Web Help.

By default, the level of the dynamic aggregation is defined by the metric that is being
aggregated. You can define the Subtotal Dimensionality Use VLDB property so that the
dynamic aggregation uses the level of the metrics dynamic aggregation function instead.
For a more detailed description of this VLDB property, along with an example of its use,
see the MicroStrategy Supplemental Reference for System Administration.

Metrics with default dynamic aggregation functions

A metric defined with functions such as Sum or Product can be dynamically aggregated
because these functions can be calculated at a higher level than the initial calculation.
Any metric defined with one of the following functions has a default dynamic
aggregation function that allows the data for the metric to be aggregated at different
levels on the fly:
Sum or Count: Sum is used as the aggregation function.

If the Count function is set to count distinct entries, it cannot use Sum as its
dynamic aggregation function and returns null values instead. The exception is
for a count distinct function in a shortcut metric defined in a report,
document, or Visual Insight quick dashboard created in MicroStrategy Web.
For instructions to create a shortcut metric, which is a type of derived metric,
see the MicroStrategy Web Help.

Minimum: Minimum (Min) is used as the aggregation function.

Maximum: Maximum (Max) is used as the aggregation function.
Product: Product is used as the aggregation function.
For example, consider the Dynamic Aggregation - Region - Employee report from
the MicroStrategy Tutorial project. To focus only on those metrics that have default
dynamic aggregation functions, move the metrics Standard Deviation of Revenue and
Count Distinct (Items Sold) to the Report Objects pane (for steps, see Using dynamic
aggregation, page 245). The report results for the Central and Mid-Atlantic regions are
shown below.

2017, MicroStrategy Inc. 247

In-memory Analytics Guide

A custom subtotal has been included on this report to display subtotals for the
different revenue calculations. For information on creating custom subtotals, see
the Advanced Reporting Guide.

The Revenue, Max Revenue, and Min Revenue metrics use total, maximum, and
minimum subtotals respectively. These are the same default dynamic aggregation
functions that are used for these three metrics because they are built with the Sum, Max,
and Min functions respectively. You can verify that this is true by moving Employee to
the Report Objects pane, which triggers dynamic aggregation, causing the metrics to be
aggregated at the regional level.

Notice that the values for the Northeast and Mid-Atlantic regions are the same values as
the regional subtotals in the report prior to triggering dynamic aggregation. When the
three metrics are aggregated at the regional level, each metric uses its default dynamic
aggregation function to perform the calculation.

Metrics that are not dynamically aggregated by default

The ability to aggregate data at a higher level in memory is useful for quick report
interaction and analysis. However, due to their aggregation function, some metrics
cannot be dynamically aggregated. For certain metric aggregation functions, recalculating

248 2017, MicroStrategy Inc.

 In-memory Analytics Guide

the data at the higher level would yield erroneous or null values if using only the data in
the report. The metrics would need to be re-executed against the data warehouse to
return correct values.
Metrics that cannot be calculated correctly using a dynamic aggregation function have
the default dynamic aggregation function set to none. Metrics have their default
aggregation function set to none if they are defined with the following functions:
Average (Avg): Sum of input values divided by number of input values.
Count (Distinct=true): Number of distinct input values.
Geometric mean (Geomean): Square root of the product of input values.
Median: Middle value when input values are sorted.
Mode: Most frequently found input value.
Standard Deviation (Stdev): Statistical distribution of input
values.
Variance (Var): Square of the standard deviation of input values.
Non-group functions or arithmetic operators: Metrics defined in this way
are called compound metrics.
For information on supporting dynamic aggregation for compound metrics, see
Dynamic aggregation for compound metrics, page 253. Dynamic aggregation is
supported for a shortcut metric defined in a report, document, or Visual Insight
quick dashboard created in MicroStrategy Web. Dynamic aggregation and subtotals
are calculated correctly for these shortcut metrics, even if they contain the functions
listed above. For instructions to create shortcut metrics, which are a type of derived
metric, see the MicroStrategy Web Help.
When you use dynamic aggregation at a level the Analytical Engine considers erroneous
for a metric defined with one or more of the functions listed above, null values,
represented by dashes (--), are displayed on the report. For information on changing the
display of null values, see Changing the display of null values, page 255.
This section provides the following information related to functions and metrics that do
not support dynamic aggregation by default:
Example of exceptions to dynamic aggregation, page 250
Returning correct metric values by accessing the data warehouse, page 251
Estimating dynamic aggregation values with different aggregation functions, page
252
Dynamic aggregation for compound metrics, page 253
Changing the display of null values, page 255

2017, MicroStrategy Inc. 249

In-memory Analytics Guide

Example of exceptions to dynamic aggregation

This example uses the Dynamic Aggregation - Region - Employee report from the
MicroStrategy Tutorial project. To look at only those metrics that do not have default
dynamic aggregation functions, move the metrics Revenue, Max Revenue, and Min
Revenue to the Report Objects pane. To use dynamic aggregation, the Employee attribute
is also moved to the Report Objects pane. The report results are shown below.

By default, the Standard Deviation of Revenue and Count Distinct (Items Sold) metrics
would return null values because they use the Standard Deviation and Count Distinct
functions in their metric definitions, respectively. The default dynamic aggregation
functions have instead been set to the functions used for their metric definitions.
Now compare these values to the values returned by executing against the data
warehouse instead of using dynamic aggregation to calculate the values from the data
within the report.

You can see that the Count Distinct (Items Sold) value is 360 for the Northeast region,
which is far different from the 2,160 value returned for the Northeast region in the
report that uses dynamic aggregation. The report above is able to query the data
warehouse and show the distinct items sold by all employees in the Northeast region. For
example, if Employee A, Employee B, and Employee C all sell one or more wrenches, the
item is only counted as one distinct item for the Northeast region.
Dynamic aggregation uses the data available in the report. In this example, all the values
for each employee in a given region are simply added together. When the calculation is

250 2017, MicroStrategy Inc.

 In-memory Analytics Guide

performed, there is no way of relating which distinct items each employee sold. The
calculation results in double-counting distinct items sold by two or more different
employees. Rolling up data to a higher level for metrics defined with functions such as
Standard Deviation and Average also perform erroneous calculations. For this reason, by
default, metrics defined with certain functions return null values instead of erroneous
results.

Returning correct metric values by accessing the data warehouse

If using dynamic aggregation in a report returns null or erroneous data, you can force the
report to re-execute against the data warehouse instead of triggering dynamic
aggregation.
For example, move the Employee attribute to the Report Objects pane in the Dynamic
Aggregation - Region - Employee report in the MicroStrategy Tutorial project. If
you have not changed how the report displays null values, you get the results shown
below.

Notice that Employee is still a part of the Report Objects pane.

To execute the report against the data warehouse, right-click the Employee attribute and
select Remove from Report. The report is re-executed against the data warehouse,
and returns the data shown below.

2017, MicroStrategy Inc. 251

In-memory Analytics Guide

The report is re-executed against the warehouse without using dynamic

aggregation only if all the attributes in the Report objects pane are on the report.

Note that taking Employee off the report changes the data definition of the report,
instead of the view definition. While you get the correct results, you are no longer taking
advantage of dynamic aggregation to perform the calculations. The SQL must be
regenerated and executed against the data warehouse to retrieve the results.

Estimating dynamic aggregation values with different aggregation

functions
If you use a function that does not support dynamic aggregation, you can use a different
function to estimate the values using dynamic aggregation. This tactic depends greatly on
the function used and the amount of error that is allowable for your report results. For
steps on how to change the default aggregation function, see Changing the default
dynamic aggregation function, page 255.
The Dynamic Aggregation - Region - Employee from the MicroStrategy Tutorial
project is used as the base report to illustrate this tactic. Move all the attributes and
metrics to the Report Objects pane except for the attribute Region and the metric
Standard Deviation of Revenue. When you run this report, null values are displayed for
the metric because the metrics function does not support dynamic aggregation.
You can estimate these values by using the Average function as the dynamic aggregation
function. This estimation is possible because the Standard Deviation and Average
formulas are similar in this situation.
You can change the dynamic aggregation function in the Subtotals / Aggregation tab of
the Metric Editor. The report below shows the results for the metric using the Average
dynamic aggregation function on the left, compared to the Standard Deviation function
on the right, run against the data warehouse.

Using the average function to perform the dynamic aggregation estimates the metric
values to within $1,000 for all but two regions.
The accuracy of data returned when using a different dynamic aggregation function than
the function used to define the metric depends on the similarity of the functions. For

252 2017, MicroStrategy Inc.

 In-memory Analytics Guide

example, you cannot expect an accurate estimation of values if you use Sum as the
dynamic aggregation function for a metric defined with the Standard Deviation function.
You can use any function as the dynamic aggregation function of a metric. However, be
aware that not all functions are well suited for dynamic aggregation (see Metrics that are
not dynamically aggregated by default, page 248).
You can also create your own subtotal to use as the dynamic aggregation function. You
cannot directly use a function as the dynamic aggregation function of a metric, you must
create a subtotal that uses the function in its definition. For steps to create a subtotal,
refer to the Report Designer Help.

Dynamic aggregation for compound metrics

A compound metric is any metric defined by a formula based on arithmetic operators
and non-group functions. Arithmetic operators are +, -, *, and /; non-group functions
are OLAP and scalar functions such as RunningSum or Rank. The operators and
functions can be applied to facts, attributes, or metrics.
This section covers compound metrics as they are used with dynamic aggregation. For
complete information on compound metrics, see the Advanced Reporting Guide.
For example, a metric defined with the formula Sum(Revenue) - Sum(Cost) is a
compound metric because of the minus (-) operator. Another example of a compound
metric is one defined with the formula RunningSum(Revenue) because of the
RunningSum function.
By default, dynamic aggregation causes compound metrics to return null values. One
reason for this is that the calculation of the formula is performed before it is dynamically
aggregated, which can cause erroneous or null results depending on the formula (see
Functions used in dynamic aggregation, page 246). Another possible reason is that
when a metric has a complex formula for its definition, there is no way to assume the
aggregation function that should be performed on the data. Rather than returning
possibly erroneous results by default, you can decide how the metric handles dynamic
aggregation.
For example, consider the Dynamic Aggregation report from the MicroStrategy
Tutorial project, which contains the metrics Revenue, Cost, and Profit as well as the
attributes Region and Employee. The report is shown below, with Employee off the
report grid, but still in the Report Objects pane.

2017, MicroStrategy Inc. 253

In-memory Analytics Guide

The Profit metric in this case is based on a profit fact stored in the data warehouse.
Suppose that your data warehouse only has facts for revenue and cost, but you want to
create a metric that calculates profit. One way you can achieve this is by creating a profit
metric called Compound Profit that combines the two metrics Revenue and Cost. The
metric can be defined as Sum(Revenue) - Sum(Cost).
You can also see a comparison of profit margins by including a Profit Margin metric on
the report. The definition for Profit Margin is Sum(Profit) / Sum(Revenue).
When you add these two metrics to the Dynamic Aggregation report, the report returns
the results shown below.

With Employee in the Report Objects pane and not on the report grid, the metrics are
dynamically aggregated to the regional level. The Profit metric is a simple sum of the
Profit fact. This calculation can be aggregated from the Employee level to the Region
level. By default, the metrics Compound Profit and Profit Margin do not use a dynamic
aggregation function.
For Compound Profit to be dynamically aggregated correctly, you change the dynamic
aggregation function to Sum. In this case the Sum function can be used to aggregate the
data after the subtraction because the order of operations does not matter in a formula
with only sum and subtract. For more information on changing the default dynamic
aggregation function, see Changing the default dynamic aggregation function, page 255.
For Profit Margin, you cannot choose Sum as the dynamic aggregation function, because
the definition of the metric includes a division. If Sum is chosen, the division is
performed first and then these values are added together, which would use the formula
Sum(Profit/Revenue). Recall that the definition of the metric is Sum(Profit) /
Sum(Revenue), performing the sum aggregations first and then dividing the sums.
To return valid results in this case, you can calculate the subtraction after dynamic
aggregation. You can achieve this functionality by defining the compound metric as a
smart metric. After you define both of the compound metrics as smart metrics, the
correct results are returned, as shown below.

254 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You can define a metric as a smart metric using the procedure below. For an
introduction to smart metrics, see Derived elements in Report Services documents with
multiple datasets, page 138.

To define a metric as a smart metric

1 In MicroStrategy Developer, right-click a metric and select Edit. The Metric Editor
opens.
2 On the Subtotals / Aggregation tab, select the Allow Smart Metric check box.
3 Click Save and Close to save your changes and close the Metric Editor.

Changing the display of null values

You can change the default display of null values caused by incorrect aggregation for your
reports.

To change the display of aggregation null values

1 Open a report.
2 From the Data menu, select Report Data Options. The Report Data Options
dialog box opens.
3 Expand the Display category, and then select Null Values. The Display - Null
Values tab opens.
4 Under Aggregation null values, clear Use Default.
5 Replace -- with the symbol you want to use for null values, for example, 00, null,
blank, and so on.

Changing the default dynamic aggregation function

The dynamic aggregation function is used to aggregate the data whenever the metric is
dynamically aggregated, regardless of what function is used in the metric definition. You

2017, MicroStrategy Inc. 255

In-memory Analytics Guide

can change the default function used for dynamic aggregation in the Subtotals /
Aggregation tab of the Metric Editor, as shown below.

The validity of the data depends on whether the function can correctly calculate the data
within the report. For this reason, it is recommended that you evaluate your report
requirements and consider the report results before you make the function selection for
dynamic aggregation.
The functions that can be used as the dynamic aggregation function are:
Average
Count (Distinct=true)
Geometric Mean
Maximum
Median
Minimum
Mode
Product
Standard Deviation
Sum
Variance
User-defined function

256 2017, MicroStrategy Inc.

 In-memory Analytics Guide

You cannot directly use a function as the dynamic aggregation function of a

metric. You must use or create a subtotal that uses the function in its definition.
For information on creating a subtotal, search the online help for Creating user-
defined subtotals.

Metrics defined with certain functions use a default dynamic aggregation function that
returns the correct results in most situations. For example, a metric defined with the
Sum function uses the Sum function to dynamically aggregate its data. You can change
the dynamic aggregation function for this type of metric, but it is recommended that you
do not change these default functions as this can cause erroneous or null results for the
metrics in a report. For more information on metrics with default dynamic aggregation
functions, see Metrics with default dynamic aggregation functions, page 247.
Aggregating data from a report with certain functions can return erroneous or null
results, and therefore the default dynamic aggregation function is set to none. You can
set the default dynamic aggregation function so that these metrics return data instead of
null values. For example, if a metric is defined with Standard Deviation, you can change
the function used for dynamic aggregation from Default to Standard Deviation.
You can, however, use a function that does not match the function or functions used to
define the metric. To see an example that uses this technique, see Estimating dynamic
aggregation values with different aggregation functions, page 252.

To change the default dynamic aggregation function

1 In MicroStrategy Developer, right-click a metric and select Edit. The Metric Editor
opens.
2 On the Subtotals / Aggregation tab, select a function from the Dynamic
aggregation function drop-down list.
3 Click Save and Close to save your changes and close the Metric Editor.

View filter effect on dynamic aggregation

Dynamic aggregation can be affected by the use of view filters used in a report. For
information on view filter effects on dynamic aggregation and other reporting features,
see View filter effects on reporting features, page 186.

2017, MicroStrategy Inc. 257

 A
EFFICIENT FUNCTIONS FOR
PARTITIONED DATASETS
The table in this appendix lists the functions that work most efficiently and faster with
partitioned datasets. Functions that are not listed work on an unpartitioned copy of the
data to calculate results, which is less efficient and slower.
For additional information on any of the functions listed, such as how the functions are
processed, see the Functions Reference.

Functions for partitioned datasets

Function type Functions that perform efficiently in partitioned datasets

Basic functions Add

Average
Avg (average)
Count
GeoMean (geometric mean)
Greatest
Least
Max (maximum)
Min (minimum)
Multiply
Product
StDevP (standard deviation of a population)
StDev (standard deviation of a sample)

2017, MicroStrategy Inc. 258

In-memory Analytics Guide

Function type Functions that perform efficiently in partitioned datasets

Sum
VarP (variance of a population)
Var (variance of a sample)
Date and time functions All date and time functions
Internal functions Banding
BandingC
BandingP
Case
CaseV
Null and Zero functions IsNotNull
IsNull
NullToZero
ZeroToNull
String functions Concat (concatenate)
ConcatBlank (concatenate plus blank space)
InitCap (initial capitalization)
LeftStr (left string selection)
Length (length of string)
Lower (lower case)
LTrim (left trim)
Position (position of substring)
RightStr (right string selection)
RTrim (right trim)
SubStr (substring selection)
Trim
Upper (upper case)
Arithmetic operators All arithmetic functions
Comparison operators <
<=
<>
=
>

259 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Function type Functions that perform efficiently in partitioned datasets

>=
Begins With
Between
Contains
Ends With
In
Like
Not Begins With
Not Between
Not Contains
Not Ends With
Not In
Not Like
Comparison operators for *<=
rank
*<>
*=
*>=
*Between
Not*Between
Logical operators AND
IF
Not
Or
Data mining functions All data mining functions
Financial functions Accrint (accrued interest)
Accrintm (accrued interest at maturity)
Coupdaybs (coupon period, beginning to settlement)
Coupdays (coupon period, number of days with settlement)
Coupdaysnc (coupon period, settlement to next coupon)
Coupncd (next date after settlement)
Coupnum (coupon, number payable between settlement and
maturity)
Couppcd (coupon date, previous)

2017, MicroStrategy Inc. 260

In-memory Analytics Guide

Function type Functions that perform efficiently in partitioned datasets

Cumipmt (cumulative interest paid)

Cumprinc (cumulative principal paid)
Db (fixed-declining balance (asset depreciation))
Ddb (double-declining balance (asset depreciation))
Disc (discount rate for a security)
Dollarde (dollar price, converted from fraction to decimal)
Dollarfr (dollar price, converted from decimal to fraction)
Duration
Effect (effective annual interest rate)
Fv (future value)
Intrate (interest rate)
Ipmt (interest payment)
Mduration (modified duration)
Nominal (nominal annual interest rate)
Nper (number of investment periods)
Oddfprice (odd-first-period price)
Oddfyield (odd-first-period yield)
Oddlprice (odd-last-period price)
Oddlyield (odd-last-period yield)
Pmt (payment)
Ppmt (principal payment)
Price (price per $100 face value)
Pricedisc (price, discounted)
Pricemat (price at maturity)
PV (present value)
Rate (interest rate per period)
Received (amount received at maturity)
Sln (straight-line depreciation)
Syd (sum of years digits depreciation)
Tbilleq (T-bill equity)
Tbillprice (T-bill price)
Tbillyield (T-bill yield)
Vdb (variable declining balance)

261 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Function type Functions that perform efficiently in partitioned datasets

Yield
Yielddisc (yield on a discounted security)
Yieldmat (yield at maturity)
Mathematical functions All mathematical functions can be used in partitioned datasets.
Statistical functions AvgDev (average deviation)
BetaDistribution
BinomialDistribution
ChiSquareDistribution
Confidence (confidence interval)
Correlation
Covariance
CritBinomial (criterion binomial)
ExponentialDistribution
Fisher (fisher transformation)
FDistribution (f-probability distribution)
Forecast
ForecastV (forecast, vector input)
GammaDistribution
Growth
GrowthV (growth, vector input)
HypergeometricDistribution
Intercept
InverseBetaDistribution (inverse of the beta distribution)
InverseChiDistribution (inverse of chi-squared distribution)
InverseFisher (inverse of the Fisher transformation)
InverseFDistribution (inverse of F-probability distribution)
InverseGammaDistribution (inverse of gamma distribution)
InverseLognormalDistribution (inverse of lognormal distribution)
InverseNormDistribution (inverse of normal cumulative
distribution)
InverseTDistribution (inverse of T-distribution)
Kurtosis
LognormalDistribution

2017, MicroStrategy Inc. 262

In-memory Analytics Guide

Function type Functions that perform efficiently in partitioned datasets

NegativeBinomialDistribution
NormalDistribution (normal cumulative distribution)
Pearson (Pearson product moment correlation coefficient)
Permut (permutation)
PoissonDistribution
RSquare (square of pearson product moment correlation
coefficient)
Skew
Slope (of a linear regression)
Standardize
StandardNormalDistribution (standard normal cumulative
distribution)
SteYX (standard error of estimates)
TDistribution
Trend
TrendV (trend, vector input)
WeibullDistribution

263 2017, MicroStrategy Inc.

 B
BEST PRACTICE FOR
MICROSTRATEGY PRIME
MicroStrategy 10.0 introduced the next generation of in-memory analytics, also referred
to as in-memory partitioning or PRIME (Parallel Relational In-Memory Engine). In-
memory analytics enables you to create in-memory cubes through Multi-Table Data
Import (MTDI).
Before MicroStrategy 10.0, the only way to create an intelligent cube (also known as an
ROLAP cube or an OLAP cube) was from a report (which is a single table dataset).
Starting in MicroStrategy 10.0, you have the option to use Data Import to create an in-
memory dataset (sometimes referred to as an MTDI cube) containing data from multiple
tables. For easy reference, the following lists a comparison between Online Analytical
Processing (OLAP) and Multi-Table Data Import (MTDI) cubes.

OLAP MTDI
Version Existed before MicroStrategy 10.0 New in MicroStrategy 10.0

Data Volume In 9.x, limited to 2 billion rows Each partition can have up to 2 billion rows

Schema A single table dataset, pre-joined Multiple tables, not pre-joined

Closer to raw data staged in-memory;
Multiple in-memory fact tables, including
varying grains, many-to-many relationship
tables, and entity-relation model semantics

Definition User specifies the definition of the cube User specifies the tables to load into
on a Report Template with Attributes, memory; Attributes/Metrics are mapped to
Metrics, and Filter these tables

Query Intelligence Server generates the SQL to Queries submitted to the RDBMS are simple
Generation execute against the data source (can use SELECT statements against the tablesno
Multi-Source) joins among tables
By default, final pass of SQL joins lookup
tables to fact table and/or metric temp
tables to retrieve attribute descriptions

Partition Available Available

Parallel Parallel Data Fetch Option set at Maximum Parallel Queries Per Report set
Intelligent Cube level at Project level

2017, MicroStrategy Inc. 264

In-memory Analytics Guide

In-memory cubes are perfect for use when creating visually-rich and interactive
dashboard applications. Most in-memory analytics dashboard applications are built using
the MicroStrategy Report Services Document interface. In-memory cubes can also be
used as a dataset within Visual Insight dashboards.
For a brief explanation of PRIME and for configuration best practice recommendations,
see the following sections:
Prerequisites
Parallel queries
Partitioning cubes
Sizing
Cube incremental refresh
Data source
Document / dashboard best practice
Concurrency
Web or mobile access

Prerequisites
Administrators should verify that all environment settings are tuned to accommodate the
cube to be published. The settings are dependent on data volume. For more information
about the environment settings, see the following sections:
Hardware configuration settings
Intelligence Server level settings
Project configuration

For information about MSIFileTables, see

http://community.microstrategy.com/t5/Architect/TN12093-How-to-enable-and-
use-the-MsiFileTable-Log-file-for/ta-p/172722. (The information in the knowledge
base article is applicable to Intelligence Server 10.x.)

Hardware configuration settings

Turn Off NUMA. For optimum performance with PRIME in-memory cubes, you must
turn off NUMA. For more information about NUMA, see
https://queue.acm.org/detail.cfm?id=2513149.

Intelligence Server level settings

The Intelligence Server level settings are:
Number of connections by priority

265 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Query execution time

Number of connections by priority

All Data Import cube publishing jobs are currently initiated as low-priority jobs. The
Number of connections by priority setting controls the number of processes that
are available to in-parallel fetch data from external locations and read into memory. This
setting specifies the total pool of processes available at the server level for the specific
type of Data Import.
For OLAP and MTDI: Database, Hadoop, OLAP, Search index
1 In MicroStrategy Developer, expand Administration, expand Configuration
Managers, and select Database Instances.
2 Right-click the database instance for which you want to define job prioritization and
choose Edit.
3 In the Database Instance editor, select the Job Prioritization tab.
4 In the Number of connections by priority section, enter the number of connections
in the Low field.

For more information about the Job Prioritization tab. click Help.
5 Click OK.
For MTDI: File from URL

2017, MicroStrategy Inc. 266

In-memory Analytics Guide

1 In MicroStrategy Developer, from the Administration menu, select Server, and

then select Configure MicroStrategy Intelligence Sever.
2 In the MicroStrategy Intelligence Server Configuration editor, expand Governing
Rules, expand Default, and select ImportData.
3 In the Number of connections by priority section, enter the number of connections
in the Low field.

4 Click OK.
Other external sources: Facebook, Google Analytics, Google Big Query,
Drop Box, Google Drive, Salesforce, Twitter
Each pool of Data Import processes can have up to 20 threads.

Query execution time

The Query execution time setting needs to be set appropriately to ensure that each
process trying to fetch data in-parallel has enough time to fetch data completely. Values
of 0 or -1 indicate infinite time (no limit).
For OLAP and MTDI: Database, Hadoop, OLAP, Search index
1 In MicroStrategy Developer, expand Administration, expand Configuration
Managers, and select Database Instances.
2 Right-click the database instance for which you want to define job prioritization and
choose Edit.
3 In the Database Instance editor, select the database connection and click Modify
4 In the Database Connections dialog box, click the Advanced tab.
5 Set the Maximum query execution time (sec) field. This field defines the
maximum amount of time a single pass of SQL can execute on the database.

267 2017, MicroStrategy Inc.

 In-memory Analytics Guide

6 Click OK to close the Database Connections dialog box.

7 Click OK to close the Database Instance editor.
For other sources
The Query execution timeout is internally set to 0 (infinite).

Project configuration
For project configuration, see
Result sets
Data import specific
User specific (if needed)

Result sets
1 In MicroStrategy Developer, right-click on the project and choose Project
Configuration
2 In the Project Configuration editor, expand Governing Rules, expand Default,
and choose Result sets.
3 Verify that the fields are set appropriately. The following figure shows a sample from
a standard project.

2017, MicroStrategy Inc. 268

In-memory Analytics Guide

Data import specific

1 In MicroStrategy Developer, right-click on the project and choose Project
Configuration
2 In the Project Configuration editor, expand Governing Rules, expand Default,
and choose Import Data.
3 Verify that the fields are set appropriately. The following figure shows a sample from
a standard project.

269 2017, MicroStrategy Inc.

 In-memory Analytics Guide

User specific (if needed)

Parallel queries
You can improve the speed of cube publication for MTDI with the Maximum Parallel
Queries Per Report setting.

To configure parallel data loading

1 In MicroStrategy Developer, perform one of the following:

Right-click the project and select Project Configuration
From the Administration menu, choose Project Configuration
2 In the Project Configuration window, under Project definition categories, select
Advanced.
3 In Project definition - Advanced, under Project-Level VLDB settings, click
Configure

2017, MicroStrategy Inc. 270

In-memory Analytics Guide

4 In the VLDB Properties window, on the Tools menu, select Show Advanced
Settings.

5 In the VLDB Properties window, under VLDB settings, expand Query

Optimizations.
6 Under Query Optimizations, select Maximum Parallel Queries Per Report.
7 Clear the Use default inherited value - (Default Setting ) check box.
8 In the Maximum Parallel Queries Per Report field, specify the maximum
number of parallel queries per report.

271 2017, MicroStrategy Inc.

 In-memory Analytics Guide

The Network Transfer Rate depends on the theoretical limit between the data source and
Intelligence Server. However, if the data source is from a database, the Network Transfer
Rate depends on the number of concurrent database threads that can be handled by the
database. Each imported table is executed over a single thread. Therefore, to parallelize a
big table in MTDI, you may want to build multiple views representing slices to be fetched
over an independent connection.

The parallel data fetch option

Increases speed of Publishing for OLAP Cubes built using the MicroStrategy
Developer.
This is an add-on option and not to be confused with Parallel Query Execution
option.
Allows for SQL Select Pass for Metrics (typically the last pass) to be fetched over
multiple ODBC connections.

Users are allowed to switch between Permanent Table (for Generic) and Derived
Table syntax (optimal for Single Select). See below.
Number of maximum parallel queries for Parallel Data Fetch is governed by
Number of Partitions setting in the screenshot above.

2017, MicroStrategy Inc. 272

In-memory Analytics Guide

VLDB settings compatibility for OLAP cubes

For some of the VLDB settings, Parallel Data Fetch does not take effect, as described in
the following sections:
Pre/post statements
Query optimizations
Partition attribute ID form type

273 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Pre/post statements

Parallel Data Fetch for OLAP Cubes does not work if the following is set:
Insert Mid Statements

Query optimizations
Parallel Data Fetch for OLAP Cubes does not work if any of the options below are
chosen for the VLDB setting Data population for IntelligentCubes:
Normalize Intelligent Cube data in the database (can provide improved performance
in scenarios where Intelligent Cube data includes a large ratio of repeating data,
dimensions include a large number of attributes, and fact tables have been used to
attribute lookup tables as well)
Normalize Intelligent Cube data in the database using relationship tables (can provide
improved performance in scenarios where Intelligent Cube data includes a large ratio
of repeating data, dimensions include a large number of attributes, and attribute
lookp tables are much small than fact tables)
Direct loading of dimensional data and filtered fact data (can provide improved
performance when majority of the attribute elements are used by the cube. In this
method, lookup tables will not be joined to fact tables)

2017, MicroStrategy Inc. 274

In-memory Analytics Guide

Partition attribute ID form type

If ID form (or first form if ID form is compound) of the Partition attribute is String (or
related) data type, Parallel Data Fetch for OLAP cubes does not take effect.

Partitioning cubes
Note: Before MicroStrategy 10.0, all datasets were non-partitioned. Starting in
MicroStrategy 10.0, partitioning is optional. If you are not partitioning the data,
the published cube consists of one table.

A major advantage of MicroStrategy 10.0 cubes is the ability to partition cubes. While
OLAP cubes were limited to 2 billion rows, PRIME OLAP cubes can be divided into
partitions and each partition can contain up 2 billion rows. This advantage allows
PRIME OLAP cubes to increase in capacity and scalability through partitions.
For more information, see the following sections:
Number of cube partitions
Selection of partition key (distribution key)
Notes about partitioning
Where to define the partition

Number of cube partitions

The number of partitions that can be defined for a single cube depends on the number of
cores used by Intelligence Server. If Intelligence Server is restricted to a certain number
of cores, through CPU affinity, then the PRIME OLAP cube is restricted by the limit.
Also note that partitioning is performed on a single attribute.

275 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Selection of partition key (distribution key)

MicroStrategy PRIME currently supports only one partitioning key/attribute for the
entire dataset. All tables that have the partition attribute will have their data
distributed along the elements of that attribute.
MicroStrategy PRIME supports the following data types for partitioning:
Numeric
STRING/TEXT
DATE
All data is distributed using HASH schemes.
The partition attribute is typically dictated by specific application needs. Below are
some general guidelines for identifying a good partition attribute.
Some of the largest fact tables in the application are typically good candidates for
partitioning and thus influence the choice of the partition attribute. They need
to be partitioned to accommodate large data sizes and to take advantage of the
PRIME parallel processing architecture.
Data should be partitioned in such a way that it allows for the most number of
partitions to be involved in any question that is asked of the application.
Attributes that are frequently used for filtering or selections do not make for
good partition attributes, as they tend to push the analysis towards specific sets
of partitions thus minimizing the benefits of parallel processing.
The partition attribute should allow for near uniform distribution of data across
the partitions, so that the workload on each partition is evenly distributed.
To support best dashboard execution and concurrency performance,
MicroStrategy has chosen to limit the number of logical CPUs engaged for any
single grid evaluation to 4.
Columns on which some of the larger tables in the application are joined make
for good partition attributes.
Typically, the number of partitions should be equal to half the number of
logical cores available to the PRIME server. This maximizes CPU usage to
offer the best possible performance during cube publishing. Setting the number
of partitions larger than the total number of CPUs will hinder performance.
Each partition can hold a maximum of 2 billion rows. Define the number of
partitions accordingly.
The minimum number of partitions is dictated by the number of rows in the
largest table divided by 2 billion, since each partition can hold up to 2 billion
records. The maximum number of partitions is dictated by the number of cores
on the box. The number of partitions should typically be between the minimum
and maximum, and closer to half the number of logical cores.
In some cases, it is possible that a single column does not meet these criteria, in
which case either the dataset/application is not a good fit for partitioning or a

2017, MicroStrategy Inc. 276

In-memory Analytics Guide

new column needs to be added to the largest table. Such an approach can
generally be applied to partition only the single largest fact table in the dataset.

Notes about partitioning

Partitioning limits the types of aggregations that can be quickly performed on the
raw data. Functions that can be handled include distributive functions (such as SUM,
MIN, MAX, COUNT, PRODUCT), or semi-distributive functions (such as STD DEV,
VARIANCE) that can be re-written using distributive functions.
Scalar functions (such as Add, Greatest Date/Time Functions, String manipulation
functions) are supported.
DISTINCT COUNTs on the partition attribute are supported.
Derived metrics using any of the MicroStrategy 250+ functions are supported.
For non-distributive functions, you may encounter high CPU and memory
consumption.
MicroStrategy 10.2 supports automatic in-memory partitioning for MTDI cubes.

Where to define the partition

MicroStrategy 10.0 supports one partitioning key (attribute) for the entire dataset.
The minimum number of partitions is dictated by the number of rows in the largest table
divided by 2 billion, since each partition can hold up to 2 billion records. The maximum
number of partitions is dictated by the number of cores used by Intelligent Server.
Defining the partition is dependent on cube type:
For OLAP cubes:
a In MicroStrategy Developer, right-click on the intelligent cube and select Edit.
b In the Intelligent Cube Editor, click the Data menu and select Configure
Intelligent Cube
c In the Intelligent Cube Options dialog box, expand Options and select Data
Partition.

For MTDI cubes:

a Select the data set click Prepare Data.

277 2017, MicroStrategy Inc.

 In-memory Analytics Guide

b Click All Objects View.

By default, the Partition Attribute pull-down menu is set to Automatic, which

allows MicroStrategy Web to set the number of partitions.

Sizing
Ensure that the Intelligence Server has the capacity to support all PRIME cubes in
memory. Additionally, ensure that the server meets all the system requirements, and has
enough capacity for both hard drive space and RAM.
As a general estimation of memory consumption, RAM can consume up to three times as
much as the MSI Table size.
Use the following table as a reference.

Warehouse MSI Table

datatype datatype Bytes per row

FLOAT FLOAT 4

INTEGER INTEGER 4

SMALLINT SHORT 2

DECIMAL (10,0) DOUBLE 8

2017, MicroStrategy Inc. 278

In-memory Analytics Guide

Warehouse MSI Table

DECIMAL (21,3) Big Decimal 21

DATE 'YYYY/MM/DD' DATE(short-short-short) 6

CHAR / VARCHAR / NCHAR / NVARCHAR (m) UTF8_STRING(m) X*(m+1)

If it is Linux, X = 1 or more

CHAR / VARCHAR / NCHAR / NVARCHAR (m) STRING(m) Y*(m+1)

If it is Windows/AIX, Y = 2 or more

In the case where the cube has multiple tables, the MSIFile Table size of each cube can
be combined to estimate the peak memory requirement.
In-memory partitioning generally results in more memory requirement as compared to
no partitioning.
For a better understanding of the PRIME cube structure, enable Engine -> CSI logs
before publishing cubes.

Cube incremental refresh

For OLAP cubes, MicroStrategy 10.0 functionality is the same as version 9.5.1 and
earlier.
For MTDI cubes, MicroStrategy 10.0 provides a flexible way to update all or some of the
imported tables at different schedules.
In MicroStrategy Web, right-click the MTDI Cube, point to Schedule, and select Show
Advanced Options.

279 2017, MicroStrategy Inc.

 In-memory Analytics Guide

More information about advanced options is available at:

http://www2.microstrategy.com/producthelp/10/WebUser/WebHelp/Lang_
1033/MicroStrategy_Web_Help.htm#scheduling_updates_for_Intelligent_Cube_
imported_data.htm

Data source
All MicroStrategy Certified Data Sources are compatible with PRIME Cubes.
If sourcing from File, MTDI is the better approach
Network Browser allows files to be loaded from the file systems that Intelligence
Server can access.

Document / dashboard best practice

The following sections describe some best practices when using PRIME cubes:
Document or dashboard reusabulity with PRIME cube
Relationships with MTDI
Metric guide
Use PRIME cube as dataset vs view report as dataset

2017, MicroStrategy Inc. 280

In-memory Analytics Guide

Super-fast search-style selectors

Document or dashboard reusabulity with PRIME cube

Dashboards have replaced dataset functionality. This allows better reconciliation and
reusability of dashboard definitions when switching between an OLAP and an MTDI
cube.

Note: By default, joins on unrelated attributes across datasets differ between

documents and dashboards:

Documents follow a Project level setting

1. In MicroStrategy Developer, right-click on the project and select Project
Configuration
2. In the Project Configuration editor, expand Project definition, and choose
Advanced.
3. Under Project-Level VLDB settings, click Configure
4. In the VLDB Properties dialog box, expand Metrics, and choose Join
Across Datasets.

Dashboards have individual settings.

1. In a MicroStrategy Web dashboard, from the File menu, choose Dashboard
Properties.
2. Select/clear the Join Behavior option - Allow joins across datasets
based on unrelated common attributes.

281 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Relationships with MTDI

Generally, to increase the speed of aggregation and filtering, a one-to-many relationship
is best.
In the MTDI workflow, auto relationship detection (using the first 1000 rows) can
sometimes cause unnecessary overhead during cube publishing and introduce unwanted
relationships. Be sure to check the relationships detected for each imported table to
ensure that the relationships are not unwanted.

Relationships are global in nature. When defined on one table, they create a relationship
table with composite information from all tables.

Metric guide
Available under Function Parameters when Use Lookup for Attribute = False.

2017, MicroStrategy Inc. 282

In-memory Analytics Guide

Some metrics can be calculated in multiple ways. This setting allows the designer to
suggest which uploaded table should be considered for calculating a certain metric.
In special circumstances, it can also help resolve performance issues introduced by
what may be considered in-efficient joins.

Row Count #Imported Table Name# is the best way for a designer to
control which table a particular metric gets evaluated from.

Use PRIME cube as dataset vs view report as dataset

Working Set/View/Normal Reports, used as datasets in documents, currently cannot
support multi pass analytics for document grids.
Benefit of using View reports currently is allowing customers to drag and drop more
default derived metrics into different dashboards that can be built and saved in
view reports. We are looking to reduce that gap for Cubes. Another benefit is to be
able to use a much smaller dataset by filtering data, which can be personalized by
using prompts in View reports.

Note: Derived metrics in View Reports would be aggregated two times: once from
Cube to View Report and then from View Report to document grid.

Super-fast search-style selectors

For MTDI cubes, consider using Search Index to speed up Search Box style search on
text fields. The Selector as Search Box is available in both documents and dashboards.

283 2017, MicroStrategy Inc.

 In-memory Analytics Guide

Concurrency
Memory consumption / CPU utilization during PRIME
cube publication concurrency
Expect peak memory usage to be up to three times the raw data size.

2017, MicroStrategy Inc. 284

In-memory Analytics Guide

For Intelligence Server to stay responsive, a maximum of 50% of the logical CPU cores
should normally engaged in populating a cube into memory after raw data is fetched.

Web or mobile access

Considerations for accessing dashboards/documents from Web or Mobile:
No new suggestion for PRIME OLAP cubes. All considerations for MicroStrategy
9.4.1 cubes still apply.

285 2017, MicroStrategy Inc.

INDEX

A attribute form qualification

accessing in a view filter 169
Derived Elements Editor 103 in dynamic sourcing 213
Intelligent Cube with a report 52 attribute qualification in a view
filter 166
aggregate table in dynamic
sourcing 201, 216 average in a derived element 93
aliasing 20
B
All Other derived element 87, 125
banding 20
attribute
in dynamic sourcing 202
compound, in dynamic
sourcing 202 best practices
disabling dynamic sourcing 211 derived metric creation 142
in a derived metric 143 dynamic sourcing 200
in dynamic sourcing 201 break by
inner join in dynamic sourcing 211 in a rank shortcut metric 153
outer join in dynamic sourcing 211 in a report limit 165
attribute element
C
derived element, not included in 87
cache
in dynamic sourcing 201, 212
Intelligent Cube 39
report, displaying names in 123

2017, MicroStrategy Inc. 286

In-memory Analytics Guide

Calculation derived element 85 quick group using a derived

element 90
display 124
rank range view filter 178
example 85
rank shortcut metric 152
comparing
report to use an Intelligent Cube 52
metric values over time 172
shortcut metric 149
text strings 170
smart metric 255
values 169
stand-alone derived element 117
comparison operator 169
view filter 165
compound attribute in dynamic
sourcing 202 Cube Advisor. See MicroStrategy Cube
Advisor. 218
compound metric 253
custom group
dynamic aggregation and 253
alternatives to 30
example 253
in dynamic sourcing 203
connecting a report to an Intelligent
Cube 52 in Intelligent Cube 30
connection mapping 27
D
consolidation
data mart report in dynamic
alternative to 30 sourcing 204
in an Intelligent Cube 30 data warehouse
in dynamic sourcing 203 forcing a report to execute
creating against 251

Calculation derived element 113 naming conventions 146

derived metric 142 dataset partitioning 69

Filter derived element 110 deleting

Group derived element 106 derived metric 155

Intelligent Cube from an existing view filter 186

report 32 derived element 78
Intelligent Cube from scratch 30 All Other derived element 87, 125
percent-to-total shortcut metric 149 attribute element names,
percent range view filter 181 displaying 123, 125-126

quick calculation derived calculating average in 93

element 92 calculating with 112
Calculation derived element 113

287 2017, MicroStrategy Inc.

 In-memory Analytics Guide

character format 130 editing 155

consolidation and custom group 30 example 141, 146
Derived Elements Editor 101 formatting 155
derived metric effect on 156 function 143
example 106, 109, 113 in dynamic sourcing 202
Filter derived element 110 in Intelligent Cube 30
formatting 128 level 143
Group derived element 106 operator 143
in Intelligent Cube 30 rank shortcut metric 152
quick calculation 92 removing from a report layout 155
quick group 90 threshold 155
quick sort 99 troubleshooting 146
stand-alone 118 view filter effect on 187
subtotals 121 Diagnostics and Performance Logging
Tool 227
value format 130
disabling
view filter effect on 196
drilling in an Intelligent Cube 34
Derived Elements Editor 101
dynamic sourcing 206
accessing 103
displaying attribute element names in a
creating a derived element 110 report 123
example 102 division in a derived element 93
formatting with 128 drilling
derived metric 141, 187 derived element interaction
as an object 142 with 136

attribute in 143 example for a report connected to an

Intelligent Cube 63
best practices 142-143
in a report connected to an
creating 142 Intelligent Cube 34, 63
creating a shortcut metric 149 dynamic aggregation 243
creating using Insert Metric 144 compound metric in 253
creating with the Input Metric data warehouse 251
Formula dialog box 145
data warehouse access 251
deleting 155
estimating values 252
derived element effect on 131, 156

2017, MicroStrategy Inc. 288

In-memory Analytics Guide

example 243, 250-251 null values in 201, 212

function 246 operator in 203
function, editing the 255 outer join in 211, 215
functions that are not supported outline mode in 203
by 248
page-by in 202
functions that are supported by 247
pivoting in 202
in dynamic sourcing 202
project tuning 199
null values 250
prompt in 202
troubleshooting 253
Query Builder report in 203
view filter effect on 193, 257
report limit in 204
dynamic sourcing 39, 198, 227
report preparation 199, 229
aggregate table in 201, 216
security filter in 202
attribute element in 201
sorting 203
attribute in 201
subtotals in 203
banding in 202
threshold in 202
best practices 200
tracking use of 227
compound attribute in 202
transformation in 202
consolidation in 203
troubleshooting 200, 203, 211, 227
custom group in 203
view filter in 202
data mart report in 204
VLDB properties in 207, 212-213
derived metric in 202
disabling 206 E
dynamic aggregation in 202 editing
enabling 206 derived metric 155
filter in 200, 202-204, 213 dynamic aggregation function 255
Freeform SQL report in 203 evaluation order of a derived
element in a document 133
functions in 201-202, 204
evaluation order of a derived
inner join in 211, 215 element in a report 132
Intelligent Cube tuning 199 evaluation order of a smart metric in
joint element list in 202 a document 133

metric in 203, 205, 215, 232 evaluation order of a smart metric in

a report 132
MicroStrategy Cube Advisor 218

289 2017, MicroStrategy Inc.

 In-memory Analytics Guide

null values 255 percent-to-total shortcut metric 149

rank order in a rank shortcut percent range view filter 179
metric 154
rank range view filter 177
stand-alone derived element 120
rank shortcut metric 152
enabling
sorting using a derived element 99
drilling in an Intelligent Cube 34
subtotals with a derived element 121
dynamic sourcing 206
threshold interaction with a derived
error message 67 element 135
evaluation order view filter effect on derived
element 196
for view filters and derived
metrics 184 view filter on a metric 170, 172, 194
example view filter on an attribute 166, 169,
193
Calculation derived element 86, 113
view filter vs. report filter 163
compound metric in dynamic
aggregation 253 view filter, basic 158
Derived Elements Editor 102 expression
derived metric 141, 146 Calculation derived element 86, 114
displaying a derived element as a derived metric 146
single item 123, 125
drilling in a report connected to an F
Intelligent Cube 63
filter
drilling interaction with a derived
element 137 in dynamic sourcing 200, 202-203,
213
dynamic aggregation 243, 250-251
in Intelligent Cube 32
evaluation order for view filters and
derived metrics 182 view filter compared to 161

evaluation order with a derived Filter derived element 82, 109

element 131 example 82
evaluation order with a derived formatting
metric 131
characters in a derived element
Filter derived element 83, 109 name 130
Group derived element 81, 106 derived element 128
OLAP Services 18 derived metric 155
page-by interaction with a derived metric values 128
element 134
values in a derived element 129

2017, MicroStrategy Inc. 290

In-memory Analytics Guide

Freeform SQL report in dynamic caching 39

sourcing 203
changing for a report 54
function
connecting to a report 52
derived metric 143
consolidation in 30
dynamic sourcing 201, 203
creating a report that uses 53
function, dynamic aggregation 247
creating from an existing report 32
changing 255
creating from scratch 30
functions
creating using Cube Advisor 222
view filter effect 187
custom group in 30

G derived element in 30

greatest function (derived element) 93 derived metric in 30

Grid/Graph 88 disabling dynamic sourcing 210

Group derived element 81 drilling 34

example 81 drilling in a report connected to 62

dynamic sourcing, tuning for 199
I
enabling dynamic sourcing 210
incremental refresh for an Intelligent
failure of the report connection 67
Cube 43
filter in 32
defining 43
incremental refresh 43
defining a filter 46
localizing 36
defining a report 48
memory resources 39, 41
filter 46
partitioning 69
prerequisites 43
prompt in 30
report 46, 48
publishing manually 39
republish settings 44
publishing on a schedule 40
inner join
scheduling an update 33
for a metric in dynamic
sourcing 215 security 23
for an attribute in dynamic shared 22
sourcing 211
troubleshooting 67
Input Metric Formula dialog box 145
unpublishing 42
Intelligent Cube 14, 22
updating 33, 43
accessing with a report 52

291 2017, MicroStrategy Inc.

 In-memory Analytics Guide

view filter in 30, 162 N

Intelligent Cube Monitor 41 null values
dynamic aggregation 250
J
dynamic sourcing, in 212
joint element list in dynamic
sourcing 202 editing 255
in a view filter 171, 175
L
in dynamic sourcing 201, 212, 215
least function (derived element) 93
troubleshooting 212, 215
level
derived metric 143 O

percent-to-total shortcut metric 151 OLAP Services 13

view filter 182 benefits 16

localizing an Intelligent Cube 36 example 18

log file for dynamic sourcing 227 standard features 19

operator
M
comparison 169
memory resources and Intelligent
Cubes 39, 41 in a derived metric 143

metric in a Filter derived element 86

dynamic aggregation in a joined view filter

functionality 246 qualification 185

in dynamic sourcing 215, 232 in a metric qualification for a view

filter 170
inner join in dynamic sourcing 215
in a percent metric view filter 175
metric to metric qualification 172
in a rank metric view filter 174
outer join in dynamic sourcing 215
in an attribute form qualification for
shortcut metric 149 a view filter 169
smart metric 255 in dynamic sourcing 203, 217
values, comparing over time 172 pattern 170
view filter effect on 191 order in a rank shortcut metric 154
metric qualification in a view filter 170 outer join for dynamic sourcing 211,
215
MicroStrategy Cube Advisor 218
outline mode 20
creating an Intelligent Cube 222
in dynamic sourcing 203
prerequisites 218

2017, MicroStrategy Inc. 292

In-memory Analytics Guide

P pivoting 20
page-by 20, 134 in dynamic sourcing 202
derived element interaction PRIME
with 133
best practices
example 134
concurrency 284
in dynamic sourcing 202
cube incremental refresh 279
percent-to-total metric 151
data source 280
partitioned dataset 69
documents and dashboards 280
benefits of 70
introduction 264
creating 73
parallel queries 270
high-level tasks 70
partitioning cubes 275
editing 74
sizing 278
partition attribute 72
web or mobile access 285
requirements
privileges
application 71
OLAP Services 17
Intelligence Server machine 72
project
metrics 72
disabling for dynamic sourcing 206
partition attribute 72
enabling for dynamic sourcing 206
scheduling a data update 75
tuning for dynamic sourcing 199
updating 75
prompt
pattern operator 170
in a report accessing an Intelligent
percent-to-total shortcut metric Cube 61
creating 149 in a report limit 165
example 149 in dynamic sourcing 202
level 151 in Intelligent Cube 30
page-by 151 publishing an Intelligent Cube 39
rules 151 manually 39
percent range view filter 174 on a schedule 40
creating 181
Q
example 179
Query Builder report in dynamic
sourcing 203

293 2017, MicroStrategy Inc.

 In-memory Analytics Guide

quick calculation using a derived S

element 92
scheduling
quick group using a derived element 90
Intelligent Cube publication 40
quick sort using a derived element 99
Intelligent Cube update 33
R security

rank range view filter 174 connection mapping and 27

creating 178 Intelligent Cube 23

example 177 permission groups for Intelligent

Cubes 27
rank shortcut metric
security filter
break by 153
in dynamic sourcing 202
creating 152
Intelligent Cube 24
example 152
shortcut metric 149
order 154
creating 149
troubleshooting 153
percent-to-total 149
report
rank 149
accessing an Intelligent Cube 52
transformation 149
changing the Intelligent Cube 54
smart metric
connecting to an Intelligent
Cube 52 creating 255

connection failure to Intelligent sorting 21

Cube 67
attribute elements using a derived
converting to an Intelligent Cube 32 element 99

creating to use an Intelligent in dynamic sourcing 203

Cube 52
stand-alone derived element 117
disabling for dynamic sourcing 209
adding to a report or
drilling in an Intelligent Cube 34 Grid/Graph 118

dynamic sourcing 200 editing 120

enabling for dynamic sourcing 209 Subscription Manager 42

in dynamic sourcing 229 subtotals 21

report limit derived element value, applying

to 121
in dynamic sourcing 204
example 122
view filter compared to 164

2017, MicroStrategy Inc. 294

In-memory Analytics Guide

in dynamic sourcing 203 attribute qualification in 166

subtraction in a derived element 93 creating with a metric
qualification 170
sum in a derived element 93
creating with an attribute
support. See technical support. 11 qualification 168
deleting 186
T
derived element effect on 131, 196
technical support 11
derived metric effect on 156, 187
text string comparison 170
design considerations 162, 165
threshold 21, 135
dynamic aggregation effect on 193,
derived element effect on 135 257
in a derived metric 155 example
in dynamic sourcing 202 attribute qualification 166
transformation in dynamic attribute qualification on a hidden
sourcing 202 attribute 193
transformation shortcut metric 149 basic view filter 158
troubleshooting 227 business scenario 160
derived metric 146 metric qualification 170, 172, 194
dynamic aggregation 253 view filter vs. report filter 163
dynamic sourcing 200, 203, 211 in dynamic sourcing 202
Intelligent Cube 67 in Intelligent Cube 30
null values 212, 215, 255 Intelligent Cube interaction
rank shortcut metric order 153 with 162
joining qualification 185
U
metric effect on 191
unpublishing an Intelligent Cube 42 operator 174, 185
updating Intelligent Cube against the percent metric qualification 175
data source 33
rank metric qualification 174
V report filter compared to 161
value comparison 169 report limit compared to 164
values, null 250 VLDB properties in dynamic
sourcing 207, 212-213
view filter 15
attribute form qualification in 169

295 2017, MicroStrategy Inc.